Lower layer triggered mobility handover procedures

Abstract

An apparatus, which may be a current gNB or a user equipment, stores a local counter and, responsive to determining 510 that a key for ciphering and / or deciphering communications between a user equipm

Description

Field Example embodiments may relate to apparatuses and / or methods for Lower Layer Triggered Mobility (LTM) handover procedures. Background There remains a need for improved handover procedures for handovers of devices between cells of a cellular network. Summary The scope of protection sought for various embodiments of the invention is set out by the independent claims. The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention. According to a first aspect, there is provided an apparatus, comprising: means for storing a local counter; and means for, responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to 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. Some example embodiments further comprise means for storing a second local counter, wherein updating the local counter according to the predetermined algorithm comprises incrementing the local counter by an amount based on the second local counter. Example embodiments may further comprise: means for obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs; means for obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; and means for determining whether to generate a key using horizontal or vertical key derivation based at least in part upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs. In some embodiments the means for determining whether to generate a key using horizontal or vertical key derivation Is configured to determine that horizontal key derivation should be used when the current and previous handovers are handovers between cells associated with the same gNB. In some embodiments the means for determining whether to generate a key using horizontal 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 means for updating the local counter is configured to reset the second local counter to zero in response to updating the local counter. In some embodiments the means for determining whether to generate a key using horizontal or vertical key derivation 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 comprises means for incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs. The apparatus may be a current gNB in some embodiments, and further comprise: means for providing an indication of the value of the local counter to a user equipment. This apparatus may be a current gNB and further comprise: means for obtaining a list of candidate cells; means for executing a handover between cells associated with the current gNB; means for indicating to one or more gNBs associated with cells of the list of candidate cells that a handover between cells associated with the current gNB has taken place; means for generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; and means for sending, for each gNB of the one or more gNBs, the generated keys for use in the event of a cell switch to a cell associated with that gNB. The apparatus may be a current gNB and further comprise: means for obtaining a list of candidate cells; means for completing a handover from a cell associated with a different gNB to a cell associated with the current gNB; means for indicating to one or more gNB associated with cells of the list of candidate cells that a handover between cells associated with different gNBs has taken place; means for generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; and means for sending, for each network node of the one or more gNBs, generated keys for use in the event of a cell switch to a cell associated with that gNB. The apparatus may be a current gNB in some example embodimetns, and further comprise: means for storing a current cell ID corresponding to a cell associated with the user equipment; means for obtaining a target cell ID corresponding to a target cell to which the user equipment is to be handed over from the current cell; and means for determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. The apparatus may be a user equipment in some example embodiments, and further comprise: means for generating a key using the determined key derivation, wherein the generated key is based at least in part on the local counter If vertical key derivation Is selected. The apparatus may be a user equipment in some example embodiments, and further comprise: means for storing a current cell ID; means for receiving from a gNB a target cell ID; and means for determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. A second aspect provides a method comprising: storing a local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to 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. The method, in some example embodiments, further comprises: storing a second local counter, wherein updating the local counter according to the predetermined algorithm comprises incrementing the local counter by an amount based on the second local counter. In some examples, the method may further comprise: obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs; obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; and determining whether to generate a key using horizontal or vertical key derivation based upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs. In some embodiments determining whether to generate a key using horizontal or vertical key derivation comprises determining that horizontal key derivation should be used when the current and previous handovers are handovers between cells associated with the same gNB. In some embodiments determining whether to generate a key using horizontal or vertical key derivation comprises 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 is a handover between cells associated with different gNBs, and further comprising resetting the second local counter to zero in response to updating the local counter. In some embodiments determining whether to generate a key using horizontal or vertical key derivation comprises 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 comprises incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs. The method may in some example embodiments further comprise providing an indication of the value of the local counter to a user equipment. The method may further comprise: obtaining a list of candidate cells; executing a handover between cells associated with a current gNB; indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with the current gNB has taken place; generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; and sending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB. The method may additionally or alternatively further comprise: obtaining a list of candidate cells; completing a handover from a cell associated with a different gNB to a cell associated with a current gNB; indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with different gNBs has taken place; generating, for each cell of the list of candidate cells associated with a gNB other than the current gNB, a key using horizontal key derivation for use in the event of a cell switch to that cell; and sending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB. In some example embodiments, the method may further comprise: storing a current cell ID corresponding to a cell associated with the user equipment; obtaining a target cell ID corresponding to a target cell to which the user equipment is to be handed over from the current cell; and determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. The method may in some example embodiments further comprise: generating a key using the determined key derivation, wherein the generated key is based at least in part on the local counter if vertical key derivation is selected. The method may also further comprise: storing a current cell ID; receiving from a gNB a target cell ID; and determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. A third aspect of provides a computer program comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out a method comprising: storing a local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to 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. In some example embodiments, the third aspect may include any other feature mentioned with respect to the method of the second aspect. A fourth aspect of the invention provides a non-transitory computer-readable medium having stored thereon computer-readable code, which, when executed by at least one processor, causes the at least one processor to perform a method, comprising: storing a local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to 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. The fourth aspect may include any other feature mentioned with respect to the method of the second aspect. A fifth aspect of the invention provides an apparatus, the apparatus having at least one processor and at least one memory having computer-readable code stored thereon which when executed controls the at least one processor to: store a local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, update the local counter according to 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. The fifth aspect may include any other feature mentioned with respect to the method of the second aspect. A sixth aspect provides a user equipment comprising: means for storing a local counter; means for storing a second local counter; means for, responsive to determining that a key for ciphering and / or deciphering communications between the user equipment and a next generation Node B, gNB, is to be generated using a 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 it will align with a corresponding counter in a network node; and means for generating the key using vertical key derivation based at least in part on the updated local counter. In some example embodiments, the user equipment may further comprise: means for obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs; means for obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; and means for determining whether to generate a key using horizontal or vertical key derivation based at least in part upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs. The means for determining whether to generate a key using horizontal or vertical key derivation may be configured to determine that horizontal key derivation should be used when the current and previous handovers are handovers between cells associated with the same gNB. The means for determining whether to generate a key using horizontal or vertical key derivation may 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 is a handover between cells associated with different gNBs, and the means for updating the local counter may be configured to reset the second local counter to zero in response to updating the local counter. The means for determining whether to generate a key using horizontal or vertical key derivation may 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 further comprise means for incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs. In some example embodiments, the user equipment may further comprise: means for storing a current cell ID; means for receiving from a gNB a target cell ID; and means for determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. The means for receiving from the gNB the target cell ID may receive the target cell ID in a medium access control command element, MAC CE, command in some embodiments. In some example embodiments the user equipment may further comprise means for ciphering and / or deciphering communications between the user equipment and a gNB using a key generated by the means for generating a key using vertical key generation. A seventh aspect provides a method comprising: storing a local counter; storing a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and generating the key using vertical key derivation based at least in part on the updated local counter. In some example embodiments, the method may further comprise: obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs; obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; and determining whether to generate a key using horizontal or vertical key derivation based upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the Indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs. Determining whether to generate a key using horizontal or vertical key derivation may comprise determining that horizontal key derivation should be used when the current and previous handovers are handovers between cells associated with the same gNB. Determining whether to generate a key using horizontal or vertical key derivation may comprise 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 is a handover between cells associated with different gNBs; and the method may further comprise resetting the second local counter to zero In response to updating the local counter. Determining whether to generate a key using horizontal or vertical key derivation may comprise determining that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and the method may further comprise incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs. In some example embodiments, the method may further comprise: obtaining a list of candidate cells; executing a handover between cells associated with a current gNB; indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with the current gNB has taken place; generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; and sending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB. In some example embodiments, the method may further comprise: obtaining a list of candidate cells; completing a handover from a cell associated with a different gNB to a cell associated with a current gNB; indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with different gNBs has taken place; generating, for each cell of the list of candidate cells associated with a gNB other than the current gNB, a key using horizontal key derivation for use in the event of a cell switch to that cell; and sending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB. Sending generated keys may comprise sending the keys over the Xn interface. In some example embodiments, the method further comprises: storing a current cell ID; receiving from a gNB a target cell ID; and determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. Receiving from the gNB the target cell ID may comprise receiving the target cell ID in a medium access control command element, MAC CE, command. The method may, in some example embodiments, further comprise ciphering and / or deciphering communications between a user equipment and a gNB using the key generated using vertical key generation. An eighth aspect of provides a computer program comprising a set of instructions which, when executed on an apparatus, is configured to cause the apparatus to carry out a method comprising: to be completed when claims finalised. In some example embodiments, the eighth aspect may include any other feature mentioned with respect to the method of the seventh aspect. A ninth aspect of the invention provides a non-transitory computer-readable medium having stored thereon computer-readable code, which, when executed by at least one processor, causes the at least one processor to perform a method, comprising: storing a local counter; storing a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and generating the key using vertical key derivation based at least in part on the updated local counter. The ninth aspect may include any other feature mentioned with respect to the method of the seventh aspect. A tenth aspect of the invention provides an apparatus, the apparatus having at least one processor and at least one memory having computer-readable code stored thereon which when executed controls the at least one processor to: store a local counter; store a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, update the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and generate the key using vertical key derivation based at least in part on the updated local counter. The tenth aspect may include any other feature mentioned with respect to the method of the seventh aspect. An eleventh aspect provides a next generation node B, gNB, comprising: means for storing a local counter; means for storing a second local counter; means for, responsive to determining that a user equipment is to generate a key for ciphering and / or deciphering communications between the user equipment and the gNB using vertical key derivation, updating the local counter according to a predetermined algorithm by incrementing the local counter by an amount based on the second local counter such that it will align with a corresponding counter in a network node; and means for sending an indication of the local counter to the user equipment. In some example embodiments, the gNB may further comprise: means for obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs; means for obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; and means for determining whether to generate a key using horizontal or vertical key derivation based at least in part upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs. The means for determining whether to generate a key using horizontal or vertical key derivation may be configured to determine that horizontal key derivation should be used when the current and previous handovers are handovers between cells associated with the same gNB. The means for determining whether to generate a key using horizontal or vertical key derivation may 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 is a handover between cells associated with different gNBs, and the means for updating the local counter may be configured to reset the second local counter to zero in response to updating the local counter. The means for determining whether to generate a key using horizontal or vertical key derivation may 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 further comprise means for incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs. In some example embodiments, the gNB may further comprise: means for obtaining a current cell ID; means for obtaining a target cell ID; and means for determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs. The means for receiving from the gNB the target cell ID may in some embodiments receive the target cell ID in a medium access control command element, MAC CE, command. In some example embodiments, the gNB comprises a distributed unit, DU, and a centralised unit, CU, and the DU comprises: the means for storing the local counter; the means for determining whether a user equipment is to generate a key using horizontal or vertical key derivation; and the means for updating the local counter. The DU may further comprise the means for sending an indication of the local counter value to the user equipment. In some example embodiments the DU comprises the means for storing the second counter and the DU further comprises: means for updating the second counter after the means for sending an indication of the local counter to the user equipment has sent the indication; and means for indicating to the CU the updated local counter value and the updated second local counter value. In some example embodiments, the CU comprises means for forwarding the updated local counter value and the updated second local counter value to CUs of gNBs associated with candidate cells. A twelfth aspect provides a method comprising: storing a local counter; storing a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and sending an indication of the local counter to the user equipment. In some example embodiments, the method further comprises: determining by a user equipment whether a key for ciphering and / or deciphering communications between the user equipment and a gNB is to be generated using horizontal or vertical key derivation based on at least in part on the sent indication of the local counter. In some example embodiments, the method further comprises: obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs; obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; and determining whether a key is to be generated using horizontal or vertical key derivation based upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs. Determining whether a key is to be generated using horizontal or vertical key derivation may comprise determining that horizontal key derivation should be used when the current and previous handovers are handovers between cells associated with the same gNB. Determining whether a key is to be generated using horizontal or vertical key derivation may comprise 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 Is a handover between cells associated with different gNBs; and the method may further comprise resetting the second local counter to zero in response to updating the local counter. Determining whether a key is to be generated using horizontal or vertical key derivation may comprise determining that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; and the method may further comprise incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs. In some example embodiments, the method further comprises: obtaining a list of candidate cells; executing a handover between cells associated with a current gNB; indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with the current gNB has taken place; generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; and sending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB. In some example embodiments, the method additionally or alternatively comprises: obtaining a list of candidate cells; completing a handover from a cell associated with a different gNB to a cell associated with a current gNB; indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with different gNBs has taken place; generating, for each cell of the list of candidate cells associated with a gNB other than the current gNB, a key using horizontal key derivation for use in the event of a cell switch to that cell; and sending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB. Sending generated keys may comprisee sending the keys over the Xn interface. In example embodiments, a gNB distributed unit, DU, associated with a gNB performs the storing of the local counter, the determining of whether a user equipment is to generate a key using horizontal or vertical key derivation, the updating of the local counter, and the sending of an indication of the local counter to the user equipment. In some example embodiments the DU further: performs the storing of the second counter; updates the second counter after the sending of the indication of the local counter to the user equipment; and indicates to a gNB centralized unit, CU, associated with the same gNB as the DU, the updated local counter value and the updated second local counter value. In some example embodiments the CU may forward the updated local counter value and the updated second local counter value to CUs of gNBs associated with candidate cells. In some example embodiments CUs of gNBs associated with candidate cells may forward the updated local counter value and the updated second local counter value to DUs of gNBs associated with candidate cells. A thirteenth aspect of provides a computer program comprising a set of instructions which, when executed on an apparatus, Is configured to cause the apparatus to carry out a method comprising: storing a local counter; storing a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and sending an indication of the local counter to the user equipment. In some example embodiments, the thirteenth aspect may include any other feature mentioned with respect to the method of the twelfth aspect. A fourteenth aspect of the invention provides a non-transitory computer-readable medium having stored thereon computer-readable code, which, when executed by at least one processor, causes the at least one processor to perform a method, comprising: storing a local counter; storing a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and sending an indication of the local counter to the user equipment. The fourteenth aspect may include any other feature mentioned with respect to the method of the twelfth aspect. A fifteenth aspect of the invention provides an apparatus, the apparatus having at least one processor and at least one memory having computer-readable code stored thereon which when executed controls the at least one processor to: store a local counter; store a second local counter; responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, update the local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node; and send an indication of the local counter to the user equipment. The fifteenth aspect may include any other feature mentioned with respect to the method of the twelfth aspect. Brief Description of the Drawings Example embodiments will now be described by way of non-limiting example, with reference to the accompanying drawings, in which: FIG. 1 is a diagram illustrating a model 100 of sequentially generating keys using horizontal and vertical key generation; FIG. 2 is a schematic diagram of radio access network 200; FIGS. 3 and 4 are message flow sequence diagrams illustrating an example message flow sequence 300; FIG. 5 is a block diagram illustrating an apparatus 400 in accordance with some example embodiments; FIG. 6 is a flow diagram illustrating a method 500 in accordance with example embodiments; FIG. 7 is a flow diagram of an example algorithm 600 for updating a local Next Hop Chaining Counter value; FIG. 8 is a block diagram illustrating a user equipment 700 in accordance with some example embodiments; FIG. 9 is a flow diagram illustrating a method 800 in accordance with example embodiments; FIG. 10 is a block diagram of a system 900 according to an example embodiment; FIGS. 11 to 15 are message flow sequence diagrams illustrating message flow sequences 1000, 1100, and 1200 in accordance with example embodiments; FIG. 16 is a block diagram illustrating a gNB 1300 in accordance with some example embodiments; FIG. 17 is a flow diagram illustrating a method 1400 in accordance with example embodiments; FIGS. 18 to 22 are message flow sequence diagrams illustrating message flow sequences 1500, 1600, and 1700 in accordance with example embodiments; FIG. 23 is a block diagram 1800 illustrating subsequent key derivation steps in the context of elements of model 100; FIG. 24 is a block diagram of components of a system in accordance with an example embodiment; and FIG. 25 shows an example of tangible media for storing computer-readable code which when run by a computer may perform methods according to example embodiments described above. Detailed Description To improve the security of communications between user equipment and network nodes, messages between user equipment and network nodes may be ciphered by the transmitting device or apparatus using a key and deciphered by the receiving device or apparatus using a matching or corresponding key. Generating the keys at the devices at which they are to be used may reduce the need to transmit keys. Matching keys may be generated using matching key derivation algorithms having matching inputs. Two methods by which matching keys may be derived are horizontal key derivation and vertical key derivation. These key derivation methods may be used to generate new keys upon a handover of a user equipment between cells, to provide forward security / secrecy. Figure 1 is a diagram illustrating a model 100 of sequentially generating keys using horizontal and vertical key generation. Horizontal key derivation 110 generates a new key 112, referred to as K9nb in this instance, as the key generated in this example Is a key for use in communication between a gNB and a user equipment. Horizontal key derivation uses as inputs a preceding key, a downlink (DL) frequency of the cell to which the user equipment is being handed over, and a physical cell ID (PCI) of the cell to which the user equipment is being handed over. Vertical key derivation 114 generates a new key using as inputs a next hop parameter (NH) value, a downlink (DL) frequency of the cell to which the user equipment is being handed over, and a physical cell ID (PCI) of the cell to which the user equipment is being handed over. Therefore, in both horizontal and vertical key derivation PCI and DL frequency is used. Horizontal key derivation makes use of the previous key. Vertical key derivation effectively refreshes the key through use of the NH value. Vertical key derivation is used to separate the key space of each radio access network (RAN) node. The NH value may be provided to the RAN node by the access and mobility function (AMF). The vertical keys generated by each RAN node use a fresh NH value provided by the AMF. Thus, the security domain will be detached from the previous RAN node. In short, horizontal key derivation uses the following inputs: • The current active key (e.g., K9nb); and • The PCI and DL frequency for the next cell, to produce the following output: • A new key (e.g., K9nb). Vertical key derivation uses the following inputs: • A fresh NH value (which may be provided by the AMF to the serving gNB / RAN node after a path switch, or may be determined by the UE using the same algorithm as is used by the AMF); and • The PCI and DL frequency for the next cell, to produce the following output: • A new key (e.g., K9nb). Figure 2 is a schematic diagram of radio access network 200. The network comprises device 210. Device 210 may be configured to communicate with network node 220 though a particular cell, cell 215, which may be associated with a particular location and particular network node 220 resources. Network node 220 Is in communication with other network nodes, Illustrated schematically by network node 235 (the network may comprise further network nodes, but these are not illustrated). Network nodes 220 and 235 may be gNBs in some examples. Network nodes 220 and 235 are in communication with a core network 205. Core network 205 may comprise an access and mobility function (AMF). Network node 220 may determine that device 210 should communicate with the network through a cell other than cell 215. For example, this may be decided on the basis of measurements received by network node 220 indicating that a different cell would provide a better connection. The preferred cell may be a cell such as cell 225, associated with the same network node 220, or the preferred cell may be a cell such as cell 230, associated with a different network node 235. Reconfiguring the device to communicate through a different cell to the current cell may be referred to as a handover. Reconfiguring the device to communicate through a different cell that is associated with the same network node as the current cell may be referred to as an intra-node handover. Reconfiguring the device to communicate though a different cell that is associated with a different network node to the current cell may be referred to as an inter-node handover. Figures 3 and 4 are message flow sequence diagrams illustrating an example message flow sequence 300. Figure 3 illustrates a first part of the message flow sequence. Figure 4 illustrates a second part of the message flow sequence. Figure 3 illustrates steps 320 -350, while figure 4 illustrates steps 350 - 376. Message flow sequence 300 does not use a lower layer triggered mobility (LTM) procedure. Sequence 300 includes messages between user equipment (UE) 310, first gNB (gNBl) 312, second gNB (gNB2) 314, and access and mobility function (AMF) 316. At step 320 first gNB 312 stores an NH and Next Hop Chaining Counter (NCC) value for the next handover. In this example, it is assumed that UE 310 initially has an NCC value of "0", and that the preceding handover that UE 310 underwent was an intra-gNB handover, so the NCC value was not incremented after the handover. It is assumed that the key that UE 310 initially uses is "KgNB-A". At step 322, gNB 312 sends a measurement control message to UE 310. At step 324, UE 310 sends a measurement report message to gNB 312. At step 326, using the measurement report received at step 324, gNB 312 decides that an inter-gNB handover should take place (i.e., because the measurement report indicates a target cell at second gNB 314). First gNB 312 generates the target key KgNB as "KgNB-B". At step 328, first gNB 312 sends the current NCC value "0" and the new key "KgNB-B" to second gNB 314, along with a handover request. At step 330, second gNB 314 stores the new key "KgNB-B" for later use. Second gNB 314 embeds the received NCC value "0" in the target cell configuration. At step 332, second gNB 314 sends the target cell configuration to first gNB 312 with a handover (HO) request acknowledge (ACK) message. At step 334, first gNB 312 forms the handover command, encapsulating the target cell configuration (which includes the NCC value) and sends this to UE 310. UE 310 receives and decodes the handover command. This handover command takes the form of a radio resource control (RRC) message. At step 336, UE 310 sees that the NCC value has stayed the same 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 frequency of the target cell to generate "KgNB-B". Because the algorithm for generating "KgNB-B" at the UE side and the network side is the same, "KgNB-B" is independently generated by UE 310 and the network and they match. At steps 338 and 340, UE 310 establishes a connection with second gNB 314 (using the random access channel) and sends an RRC reconfiguration complete message to second gNB 314. UE 310 ciphers its message using "KgNB-B". At step 342, second gNB 314 sends a path switch request to AMF 316. At step 344, AMF 316 increments the NCC value for the UE (by one). At step 346, AMF 316 generates a fresh "NH" value. At step 348, AMF 316 sends the incremented NCC value and the new NH value to second gNB 314 as part of a path switch request acknowledgement message. At step 350, second gNB 314 stores the NH and the NCC value, and does not use them at this stage. Second gNB 314 has at this point become the serving gNB of UE 310. After time has passed, UE 310 may send another measurement report. This subsequent measurement report may in some examples be triggered by an amount of time having passed since a previous measurement report was sent, but the particular trigger for sending this measurement report is not essential to the handover procedure that follows. This report may indicate that another target cell, this time in the same gNB has become a strong candidate for handover. At step 352, second gNB 314 may decide to trigger an intra-gNB handover in response to receiving the measurement report. At step 354, second gNB 314 determines that a key should be generated using vertical key derivation, as the stored NCC value has been incremented (at step 344). Second gNB 314 uses the stored NH value along with the target cell PCI and DL frequency to generate the "KgNB-C". Second gNB 314 stores the "KgNB-C". Second gNB 314 puts the incremented NCC value "1" in the target cell configuration and compiles the handover command. At step 356, second gNB 314 then sends the HO Command to UE 310 (as part of an RRC reconfiguration message). The NCC value is embedded in the handover command. At step 358 UE 310 decodes the HO command and sees that the NCC value is incremented to "1". UE 310 determines that it is to use vertical key generation, as the NCC value has been incremented. UE 310 generates a fresh NH value using an algorithm preconfigured by AMF 316 to UE 310. The NH value generated by UE 310 and AMF 316 map to each other as the same algorithm is used. UE 310 then uses the NH value, PCI and DL frequency to generate target key - "KgNB-C". At step 360, UE 310 establishes a connection with second gNB 314 over a random access channel. At step 362, UE 310 sends a RRCReconfigutation complete message to second gNB 314. UE 310 ciphers the message with the newly generated key, and UE 310 then sends this message to second gNB 314, and second gNB 314 uses the stored KgNB-C to decipher the message of UE 310. At step 364, no new NH value is received from the AMF by second gNB 314, the handover of steps 352 - 362 is an intra-gNB handover. Because no new NH value is received at step 364, the next handover taking place from step 366 to 376 uses horizontal key generation. In the illustrated example this handover is also an intra-gNB handover. Steps 366, 368, 370, 372, 374, and 376 respectively correspond to steps 352, 354, 356, 358, 360, and 362. This method relies on communicating a new NCC value to the UE using an RRC reconfiguration message. In this method the key derivation method to use is indicated with the NCC value after each cell change in handover command to the UE. Lower layer triggered mobility (LTM) dynamic switching is method by which a UE stores a plurality of RRC configurations and may be instructed to change configurations using a lower (than RRC) layer message. For example, a medium access control (MAC) control element (MAC CE) may be used to instruct a UE to use a different configuration, configured in advance for use with a particular cell. In some examples, keys generated using horizontal key derivation may be generated and communicated to each candidate gNB, for use in the event that a UE is handed over to a cell associated with that gNB. The list of keys may be indicated to the UE (for example, the list of candidate cell PCIs and DL frequencies could be indicated to the UE), and the UE may use the list to determine the next key for the target gNB. However, if candidate cell configurations are re-used 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. LTM dynamic switching may therefore be incompatible with vertical key derivation if RRC reconfiguration is required to update the NCC value. LTM dynamic switching provides faster handovers between cells, and vertical key derivation provides separation between the security domains of different network nodes, so it may be desirable to allow vertical key derivation to be used with LTM dynamic switching. A method to enable vertical key generation by the UE for subsequent cell switching is therefore proposed. The UE may determine the next key derivation to be used after a cell switch command either internally based on awareness of whether source and target cells belongs to the same gNB or not, or based on indication from the source GNB in the LTM switching command. Using suitable methods at the UE and the Network side, the generation of an updated key for Inter-gNB LTM may be achieved without RRC-Reconfiguration between cell-switch commands. In some example embodiments an updated NCC value may be derived by the UE or gNB without relying on an updated NCC value indicated by the AMF by updating a locally stored NCC value using an appropriate algorithm. The locally stored NCC value may therefore be aligned with the AMF NCC value or aligned with the AMF NCC value during vertical key derivation. By aligning the locally stored NCC value with an NCC value stored at the AMF at least during vertical key derivation, the locally stored NCC value may be used to generate a key that corresponds to a key generated by network devices using an AMF provided NCC and or NH. Figure 5 is a block diagram illustrating an apparatus 400 in accordance with some example embodiments. Apparatus 400 comprises memory 405 and processor 410. Memory 405 may store a local counter. Processor 410 may update the local counter stored in memory 405 according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node (for example, the network node may be an AMF). This updating step may be performed in response to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation. Figure 6 is a flow diagram illustrating a method 500 in accordance with example embodiments. Steps of method 500 may be carried out by apparatus 400. At step 510, It is determined that vertical key generation is to be used to generate a key. At step 512, a stored local counter is updated according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node (for example, the network node may be an AMF). The stored local counter may be stored on memory 405, and the updating may be performed by processor 410. The apparatus that determines that vertical key derivation Is to be used may be apparatus 400, but the updating step 512 may be performed by a different apparatus to step 510 (for example, step 510 may be performed by an apparatus other than apparatus 400. By aligning the local counter with the value at a network node, the local counter and the counter at the network node may be used in the generation of corresponding keys, without the need to communicate the counter at the network node to apparatus 400. In examples in which apparatus 400 is a user equipment this may allow for a local counter to be updated without RRC reconfiguration. In examples in which apparatus 400 is a network node, this may reduce the amount of signaling between network nodes required to provide the value of the counter to a user equipment. In some examples, apparatus 400 maintains a second local counter, and updating the local counter at step 512 according to the predetermined algorithm comprises incrementing the local counter by an amount based on the second local counter. The second local counter may for example track differences between the value of the local counter and the value of the corresponding counter. In some examples, step 510 comprises determining whether to generate a key using horizontal or vertical key derivation, and this step is performed by apparatus 400 (by processor 410 in some examples). This determination may be based at least in part on obtained indications of whether a current handover of a user equipment from one cell to another is a handover between cells associated with the same gNB or different gNBs, and whether a previous handover is a handover between cells associated with the same gNB or different gNBs. If current and previous handovers are between cells associated with the same gNB, it may be determined at step 510 that horizontal key derivation is to be used. The corresponding network node counter (which may in some examples be an NCC counter maintained at an AMF) may be unchanged after such handovers, so there may be no updates to the correpsonding network node counter to track, and alignment of the local counter at a user equipment with a corresponding counter at the network side may be unnecessary if the key derivation is horizontal. If the current handover between cells Is a handover between cells associated with the same gNB, and the previous handover between cells is a handover between cells associated with different gNBs, it may be determined at step 510 that vertical key derivation is to be used. As discussed above, the local counter may 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 may be reset to zero. Using vertical key derivation provides separation between the security domains of a previous gNB (the serving gNB before the previous handover) and a 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 corresponding key to key derivation based on the corresponding counter. The second local counter being reset to zero may reflect the alignment between the local counter and the corresponding counter. If the current handover between cells Is a handover between cells associated with different gNBs, it may be determined at step 510 that horizontal key derivation should be used, and the second local counter may be incremented. The second local counter being incremented may reflect an increase in the corresponding network node counter in response to the handover between cells associated with different gNBs without an increase in the local counter. Determining whether a handover between cells is a handover between cells associated with the same gNB or different gNBs may be performed in some embodiments by processor 410 based at least in part on current and target cell IDs stored in memory 405. In some examples the current and target cell IDs may be mapped to key update groups, and the current and target cell IDs being mapped to the same key update group may be indicative of the current and target cells being associated with the same gNB, while current and target cells being mapped to different key update groups may be indicative of the current and target cells being associated with different gNBs. In embodiments in which apparatus 400 is a user equipment, current and / or target cell IDs may be obtained by apparatus 400 via MAC CE. At step 514, the local counter is used to generate a key using vertical key derivation. If apparatus 400 is a user equipment, apparatus 400 may generate the key at this step. In other embodiments, the local counter may be sent to, or the value of the local counter may be indicated to, a different apparatus for use in key derivation. User equipment methods In some examples, a user equipment may be configured to generate security keys for one or more target cells based on an internally maintained, or local, NCC count value. The UE may generate a key using vertical key derivation for use after handover to the target cell, target K-GNB*, based on an NH value derived from the local NCC count value and target cell PCI and DL-Frequency. If the local NCC count is unchanged, the UE may generate a key using horizontal key derivation based on a previous key and a target cell PCI and DL-Frequency. The UE may determine that it is to generate a new key based on vertical key derivation if a Key update group-ID of the current cell and the new cell are different. A key update group may correspond to a group of cells associated with the same gNB. The AMF NCC value may be incremented after handovers between cells of the different key update groups. In some example embodiments, a user equipment may be configured to generate security keys for target cells based on an NCC value received in an LTM switching command (via a MAC CE command for example). The user equipment may generate the target K-GNB* based on the NCC value provided in the cell-switching command. Where an NCC value is provided to the user equipment (for example in the LTM switching command), the user equipment maintaining and updating an internal NCC count may be unnecessary. Network methods If LTM mobility is configured for inter-gNB scenarios, the new serving gNB may update each of the candidate-cells with an NH value generated from the NCC value received from the AMF via a path-switch message. Each candidate gNB may provide a Key-Update group-ID and Its association with candidate cells to an initial serving gNB during a preparation procedure for LTM. This may allow a UE or other devices to determine whether a handover is between cells associated with different gNBs and decide when to use horizontal or vertical key derivation to generate a new K-gNB based on NH / NCC. Key update algorithm As discussed above, the local NCC value may be updated according to an algorithm to align it with the NCC value stored by an AMF, and / or with the NCC value used to determine the key at the network side. The below table illustrates three cases addressed by an example algorithm for updating an NCC value. Case Current Handover type Previous Handover type Key generation NCC value NCC_Delta value A Intra-gNB Intra-gNB Horizontal Same Same B Intra-gNB Inter-gNB Vertical Increment Reset C Inter-gNB Intra- and Inter-gNB Horizontal Same Increment Table 1: Summary of decision logic for key generation The algorithm may not be used if a configuration indicates that a UE is not to update keys. The algorithm may use the previous and / or the current handover type, or an indication of previous and / or current handover types as inputs to determine the key generation type to be used. In the example algorithm, an NCC_Delta value is stored locally in addition to the local NCC value. For each inter-gNB handover, the NCC value may not incremented, but the NCC Delta is incremented to align the total of the local NCC and NCC_Delta with the NCC value maintained at the AMF. In some example embodiments the NCC_Delta value tracks a number of inter-gNB handovers between vertical key generations. The AMF NCC value is incremented after being informed of an inter-gNB handover, and an NCC Delta value may track the incrementing of this AMF NCC value. Case A: The current handover is "intra-gNB" handover (a handover of a user equipment between cells associated with the same gNB), and the previous handover is also "intra-gNB". In this case, the key generation is horizontal. The NCC value remains the same for this case. Also the NCC Delta value is not incremented. An "intra-gNB" handover may be indicated by a NCC Delta value of zero in some cases. Case B: The current handover is an "intra-gNB" handover and the previous handover is an "inter-gNB" handover (a handover of user equipment from a cell associated with a first gNB to a second gNB). In this case, the key generation is vertical. Vertical key generation may keep the security domains of separate gNBs separate. In this case the NCC value may be incremented by the value of NCC_Delta. The NCC_Delta value may now be reset to 0 (the difference between the locally stored NCC and AMF stored NCC should be zero). An "inter-gNB" previous handover may be indicated by a non-zero NCC_Delta value, or otherwise. Case C: The current handover is an "inter-gNB" handover. In this case the key generation is horizontal. This may be irrespective of the previous handover type (i.e., the previous handover could be an Intra-gNB handover or Inter-gNB handover). The NCC value is unchanged in this case. The NCC_Delta value is incremented (because the local NCC value is unchanged, and the AMF stored NCC value may be incremented upon receiving a path switch request, the difference between the AMF stored NCC value and the local NCC value may be incremented). Figure 7 is a flow diagram of an example algorithm 600 for updating the local NCC value. At step 610, indications of whether current and previous handovers are handovers between cells associated with different network nodes are obtained. For example, whether the current handover is a handover between cells associated with the same network node may be determined based on a target cell ID and a current cell ID, or an indication of said cell IDs. A previous handover type may be explicitly indicated or may be inferred, based on the stored NCC_Delta value for example. At 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 may proceed to step 614. If the current handover is not between cells associated with different network nodes, the algorithm may proceed to step 616. At step 614, NCC_Delta is incremented, and the local NCC value Is unchanged. Horizontal key generation is determined. At step 616, it is determined whether the previous handover is between cells associated with different network nodes. If the previous handover was not between cells associated with different network nodes the algorithm may proceed to step 618. If the previous handover was between cells associated with different network nodes the algorithm may proceed to step 620. At step 618, horizontal key generation is determined. The local NCC value may be unchanged. NCC_Delta may also be unchanged (and may be zero). At step 620, vertical key generation is determined. The local NCC value is incremented by NCC delta. The method them proceeds to step 622. At step 622, NCCDelta is reset. The local NCC value and the NCC value stored at the AMF may be aligned at this stage. Algorithm 600, or other example algorithms, may be performed at different devices of a network. In some example embodiments, algorithm 600 may be executed by apparatus 400. Memory 405 may store the local NCC value and the NCC_Delta, while processor 410 may execute the algorithm based on obtained indications of whether the current and previous handovers are handovers between cells associated with different network nodes. At the network side, the previous handover type may not be known if a user equipment switches cell to a cell associated with a different gNB having already preformed an inter-gNB handover. In some example embodiments each candidate gNB (e.g., each gNB corresponding to one or more candidate cells to which a user equipment may be handed over from a serving gNB) may be informed of preceding inter-gNB handovers by a serving gNB. The candidate gNBs may receive a potential key generated using horizontal key derivation from that serving gNB for use if the user equipment is handed over to that candidate gNB. In embodiments in which apparatus 400 is a gNB, these keys may be generated using processor 410. In some examples, sending one or more keys from one gNB to one or more other gNBs may be performed using the Xn interface. In the case of subsequent horizontal key generation, it may be sufficient that the candidate gNBs are informed about the PCI and DL frequency of the current serving cell of the UE. Using this information candidate gNBs can generate the subsequent key. A current serving gNB may however indicate to candidate gNBs that handover between cells associated with the current serving gNB has taken place, generate keys for use in the event of a cell switch to candidate gNBs using horizontal key derivation, and send the generated keys. In embodiments in which apparatus 400 is a gNB, these keys may be generated using processor 410. Figure 8 is a block diagram of a user equipment 700 according to an example embodiment. User equipment 700 comprises memory 705 and processor 710. User equipment 700 may comprise features of apparatus 400 in some embodiments. Memory 705 may store a local counter and a second local counter. In some examples the local counter and second local counter correspond to the NCC value and the NCC_Delta value. Processor 710 may update the local counter stored in memory 705 by incrementing the local counter by an amount based on the second local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node (for example, the network node may be an AMF). This updating step may be performed in response to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation. Processor 710 may generate a key using vertical key derivation based at least in part on the updated local counter. Figure 9 is a flow diagram of a method 800 according to an example embodiment. Some or all steps of method 800 may be executed by user equipment 700. Method 800 may comprise steps of method 500 in some embodiments. At step 810, it is determined that vertical key generation is to be used to generate a key. At step 812, a stored local counter is updated by incrementing the local counter by an amount based on a second local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node (for example, the network node may be an AMF). The stored local counter and second local counter may be stored on memory 705, and the updating may be performed by processor 710. At step 814, the local counter is used to generate a key using vertical key derivation. This step may be performed by processor 710. In the example embodiments of user equipment 700 and method 800, a local NCC and NCC_Delta are maintained at the user equipment side. Keys are generated at the network side and the user equipment side based on current and previous handover types. Figure 10 is a block diagram of a system 900 according to an example embodiment. System 900 comprises a user equipment 905 (which may comprise the features of user equipment 700), a first gNB 910, a second gNB 920, and AMF 930. First gNB 910 may comprise first centralized unit (CUI) 912 and first distributed unit (DU1) 914. Second gNB may likewise comprise second centralized unit (CU2) 922 and second distributed unit (DU2) 924. User equipment 905 is shown to be in communication with first gNB 910, through first distributed unit 912. User equipment 905 may communicate with other gNBs, such as second gNB 920 via a handover procedure. gNBs 910 and 920 are illustrated as comprising one centralised unit and one distributed unit each. In some embodiments gNBs 910 and 920 may comprise multiple distributed units in communication with a centralised unit. Figure 11 shows a message flow sequence 1000 according to an example embodiment. Message flow sequence 1000 may take place between elements of system 900. At step 1010, UE 905 sends a measurement report to DU1 914. At step 1012, DU1 914 sends a measurement report to CUI 912. At step 1014, in response to receiving the measurement report, CUI 912 triggers the LTM preparation procedure. CUI 912 may generate a key using horizontal key derivation for all candidate cells. CUI 912 may create a key update group. Candidate cells may be mapped to a key update group corresponding to an associated gNB. Using the mapping, an indication of a key update group may be determined from an indication of a candidate cell (e.g., a candidate cell ID may map to a key update group ID), and candidate cells mapping to different key update groups may indicate that the candidate cells are associated with different gNBs. At step 1016 the LTM preparation request is sent to the target gNB 920. The keys generated using horizontal key derivation and configured group(s) / mapping may be embedded in this request. At step 1018 the target gNB 920 / CU2 922 prepares the LTM configuration by embedding the key update group / mapping in an LTM configuration. At steps 1020 and 1022, CU2 922 fetches context from DU2 924 by sending a UE context setup request message to DU2 924 and receiving a UE context setup response message from DU2 924. At step 1024 CUI 912 is informed about the LTM preparation from the CU2 922 side In an acknowledgement message. At steps 1026 and 1028, CUI 912 contacts DU1 914 to prepare the 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. At step 1030, UE 905 is configured with a set of rules for key generation. The rules for key generation may comprise algorithm 600. UE 905 stores these configured rules for further key generations during handover procedures. UE 905 also stores the key update groups, so that whether a handover is intra-gNB may be determined. UE 905 may be provided with the rules for key generation and key update groups in an R.R.C reconfiguration message. At step 1032, UE 905 sends a reconfiguration complete message. Message flow sequence 1000 may therefore prepare UE for an LTM procedure. One or more key update groups may be associated with one or more candidate cells, such that cells within the same key update group are associated with the same gNB. Keys generated using horizontal key derivation may have been generated for each candidate cell. Figures 12 and 13 show first and second parts of a message flow sequence 1100. In this message flow sequence, a UE maintains a local NCC value. This message flow sequence contains two handovers, both between cells associated with different gNBs. Message flow sequence 1100 may take place between elements of system 900. At step 1110, UE 905 sends an LI (Physical layer) measurement report to DU1 914. At step 1112, and in response to receiving the measurement report, DU1 914 sends a cell switch command to UE 905. The cell switch command may be a MAC CE command indicating a target cell ID. The cell switch command may also indicate whether the cell switch corresponds to a handover between cells associated with different gNBs. At step 1114, DU1 914 notifies CUI 912 of the change in cell serving UE 905. At step 1116, UE 905 performs the cell switch. UE 905 determines from the indicated target cell ID whether the handover Is between cells associated with different gNBs. In other embodiments it may be indicated in the MAC CE command whether the handover Is between cells associated with different gNBs or not. UE 905 may at this stage use an algorithm such as algorithm 600 to determine an updated NCC value and an updated NCC Delta value. UE 905 may also determine whether to use horizontal or vertical key derivation at this stage, also using a key derivation algorithm such as algorithm 600. In this example, the handover is between cells associated with different gNBs, so NCC_Delta is incremented by 1, the local NCC value is not updated, and horizontal key derivation is used. Using horizontal key derivation, UE 905 may derive a key corresponding to a key derived at the network side. CU2 922 may have been provided with a corresponding key generated using horizontal key derivation for use after an inter-gNB handover during an LTM preparation procedure, such as at step 1016 of message flow sequence 1000, or after an LTM handover procedure. At step 1118 UE 905 sends an RRC reconfiguration complete message to DU2 924 and CU2 922. At step 1120, DU2 924 sends an access notification to CU2 922. At step 1122, the serving node CU2 922 notifies CUI 912 of the next key(s) generated using horizontal key derivation for use in the event of an inter-gNB handover to a cell of CUI 912. If the network and / or UE 905 Is configured for LTM handovers between cells associated with further gNBs, the further gNBs may be informed of the next key generated using horizontal key derivation. The current serving node CU2 922 may send the next key(s) via the Xn interface. At step 1124, the previous serving node CUI 912 may calculate the next key using horizontal key derivation from the previous key. Because CUI 912 is the previous serving node, it will have the necessary information to calculate the next key using horizontal key derivation. This step is optional, and CU2 922 may instead send the next key generated using horizontal key derivation to CUI (e.g., via the Xn interface). If optional step 1124 takes place, it may be unnecessary to send the next key to the previous serving node CUI 912, but other nodes for which LTM Is configured may still need to receive a next key generated using horizontal key derivation. At step 1126, the new current serving node sends a path switch request to AMF 930, informing AMF 930 of an inter-gNB handover. AMF 920 will Increment its NCC counter. At step 1128, the AMF 930 sends a path switch acknowledgement message to the current serving node CU2 922. This includes the incremented NCC value and an updated NCC value, for use in generating a key at the network side for use after the next handover, if the next handover Is vertical. At step 1130, CU2 922 calculates a next key using vertical key derivation (using the NCC and NH value). At this stage, keys generated using horizontal key derivation have been communicated to or otherwise obtained by candidate gNBs other than 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 causes a change in serving gNB, if the next handover is not between cells associated with the current serving gNB, then the next key will be horizontal. At step 1132, UE 905 sends another LI measurement report to the current serving gNB (in this example to DU2 924 of the current serving gNB). This measurement report may contain measurements from which the serving gNB may determine that a second handover is desirable. At step 1134, DU2 924 sends a cell switch command in response. The cell switch command may be a MAC CE command indicating a target cell ID. The cell switch command may also indicate whether the cell switch corresponds to a handover between cells associated with different gNBs. In this case, the cell switch does correspond to a handover between cells associated with different gNBs. At 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., from an indication in the serving cell change notification). At step 1138, CU2 922 may delete the NH value received at step 1128, and / or the key generated using vertical key derivation, as vertical key derivation will not be used in the event of an inter-gNB handover. At step 1140, in response to the cell switch command of step 1134, UE 905 performs an LTM cell change procedure. UE 905 may determine from an indication in the cell switch command that the handover is a handover between cells associated with different gNBs, and that horizontal key derivation is therefore to be used. UE 905 may therefore not align its locally maintained NCC value with the AMF NCC value and may increment its NCC_Delta value again. UE 905 may then use horizontal key derivation to generate a key corresponding to the key generated at the network side (at step 1122 or 1124). At step 1142, UE 905 sends an RRC Reconfiguration complete message to the new serving CU and DU of the new serving gNB, CUI 912 and DU1 914. At step 1144, CUI 912 uses the key obtained at step 1122 or 1124 to decipher a message from UE 905. At step 1146, similar to step 1122, the new serving node CUI 912 notifies CU2 922 of the next key(s) generated using horizontal 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 handovers between cells associated with further gNBs, the further gNBs may be informed of the next key generated using horizontal key derivation. The current serving node CUI 912 may send the next key(s) via the Xn interface. Steps 1148 and 1150 correspond to steps 1126 and 1128. Figures 14 and 15 show first and second parts of a message flow sequence 1200. In this message flow sequence, a UE maintains a local NCC value. This message flow sequence contains three handovers, the first being between cells associated with different gNBs, the second being between cells associated with the same gNB, and the third being between cells associated with different gNBs. Message flow sequence 1200 may take place between elements of system 900. At step 1210, UE 905 sends an LI (Physical layer) measurement report to DU1 914. At step 1212, and in response to receiving the measurement report, DU1 914 sends a cell switch command to UE 905. The cell switch command may be a MAC CE command indicating a target cell ID. The cell switch command may also Indicate whether the cell switch corresponds to a handover between cells associated with different gNBs. At step 1214, DU1 914 notifies CUI 912 of the change in cell serving UE 905. At step 1216, UE 905 performs the cell switch. UE 905 determines from the indicated target cell ID whether the handover Is between cells associated with different gNBs. In other embodiments it may be indicated in the MAC CE command whether the handover is between cells associated with different gNBs or not. UE 905 may at this stage use an algorithm such as algorithm 600 to determine an updated NCC value and an updated NCC_Delta value. UE 905 may also determine whether to use horizontal or vertical key derivation at this stage, also using a key derivation algorithm such as algorithm 600. In this example, the handover is between cells associated with different gNBs, so NCC_Delta is Incremented by 1, the local NCC value is not updated, and horizontal key derivation is used. Using horizontal key derivation, UE 905 may derive a key corresponding to a key derived at the network side. CU2 922 may have been provided with a corresponding key generated using horizontal key derivation for use after an inter-gNB handover during an LTM preparation procedure, such as at step 1014 of message flow sequence 1000, or after an LTM handover procedure. At step 1218 UE 905 sends an R.R.C reconfiguration complete message to DU2 924 and CU2 922. At step 1220, DU2 924 sends an access notification to CU2 922. At step 1222, the serving node CU2 922 notifies CUI 912 of the next key(s) generated using horizontal key derivation for use in the event of an inter-gNB handover to a cell of CUI 912. If the network and / or UE 905 is configured for LTM handovers between cells associated with further gNBs, the further gNBs may be informed of the next key generated using horizontal key derivation. The current serving node CU2 922 may send the next key(s) via the Xn interface. At step 1224, the new current serving node sends a path switch request to AMF 930, informing AMF 930 of an inter-gNB handover. AMF 920 will increment its NCC counter. At step 1226, the AMF 930 sends a path switch acknowledgement message to the current serving node CU2 922. This includes the incremented NCC value and an updated NCC value, for use in generating a key at the network side for use after the next handover, if the next handover is vertical. At step 1228, CU2 922 calculates a next key using vertical key derivation (using the NCC and NH value). At this stage, keys generated using horizontal key derivation have been communicated to or otherwise obtained by candidate gNBs other than the serving gNB, and the serving gNB has 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 causes a change in serving gNB, if the next handover is not between cells associated with the current serving gNB, then the next key will be horizontal. At step 1232, UE 905 sends another LI measurement report to the current serving gNB (in this example to DU2 924 of the current serving gNB). This measurement report may contain measurements from which the serving gNB may determine that a second handover is desirable. At step 1234 DU2 924 sends a cell switch command in response. The cell switch command may be a MAC CE command indicating a target cell ID. The cell switch command may also indicate whether the cell switch corresponds to a handover between cells associated with different gNBs. In this case, the cell switch corresponds to a handover between cells associated with the same gNB (i.e., CU2 922 will remain the centralised unit serving UE 905). At 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., from an indication in the serving cell change notification). At step 1238, in response to the cell switch command of step 1234, UE 905 performs an LTM cell change procedure. In the course of the LTM cell change procedure, algorithm 600 may be used to determine the key generation type to be used and updated NCC value. UE 905 may determine from an indication in the cell switch command that the handover is a handover between cells associated with the same gNB, and UE 905 may determine that a previous handover was a handover between cells associated with different gNBs (for example from the non-zero NCC_Delta value incremented at step 1216), so vertical key derivation is therefore to be used. UE 905 may therefore align its locally maintained NCC value with the AMF NCC value and by Incrementing the local NCC value by the NCCDelta value and reset the NCC Delta value to zero. UE 905 may then use vertical key derivation to generate a key corresponding to the key generated at the network side (at step 1228). At step 1240, UE 905 sends an RRC Reconfiguration complete message to the serving CU and DU of the serving gNB, CU2 922 and DU2 924. At step 1242, similar to step 1222, CU2 922 notifies CUI 912 of the next key(s) generated using horizontal key derivation for use in the event of an inter-gNB handover to a cell of CUI 912. If the network and / or UE 905 is configured for LTM handovers between cells associated with further gNBs, the further gNBs may be informed of the next key generated using horizontal key derivation. The current serving node CU2 922 may send the next key(s) via the Xn interface. At step 1244, UE 905 sends another LI measurement report to the current serving gNB (in this example to DU2 924 of the current serving gNB). This measurement report may contain measurements from which the serving gNB may determine that a third handover is desirable. At step 1246, DU2 924 sends a cell switch command in response. The cell switch command may be a MAC CE command indicating a target cell ID. The cell switch command may also indicate whether the cell switch corresponds to a handover between cells associated with different gNBs. In this case, the cell switch corresponds to a handover between cells associated with the different gNBs (i.e., CU2 922 will not remain the centralised unit serving UE 905 after the handover). Steps 1248 - 1254 correspond to steps 1214 - 1218 and 1222. Steps 1248, 1250, 1252, and 1254 correspond to steps 1214, 1216, 1218, and 1222 respectively, with the direction of the handover from one gNB to the other being reversed. Figure 16 is a block diagram of a gNB 1300 according to an example embodiment. gNB 1300 comprises memory 1305, processor 1310, and transmitter 1315. gNB 1300 may comprise features of apparatus 400 in some embodiments. Memory 1305 may store a local counter and a second local counter. In some examples the local counter and second local counter correspond to the NCC value and the NCC Delta value. Processor 1310 may update the local counter stored in memory 1305 by incrementing the local counter by an amount based on the second local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node (for example, the network node may be an AMF). This updating step may be performed in response to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation. Transmitter 1315 may send the value of the updated local counter determined by processor 1310 to a user equipment. The user equipment may use the value of the updated local counter to determine whether to use horizontal and / or vertical key derivation. The user equipment may additionally or alternatively use the value of the updated local counter as part of key derivation. Figure 17 is a flow diagram of a method 1400 according to an example embodiment. Some or all steps of method 1400 may be executed by gNB 1300. Method 1400 may comprise steps of method 500 in some embodiments. At step 1410, it is determined that vertical key generation is to be used to generate a key. At step 1412, a stored local counter is updated by incrementing the local counter by an amount based on a second local counter according to a predetermined algorithm such that the local counter will align with a corresponding counter in a network node (for example, the network node may be an AMF). The stored local counter and second local counter may be stored on memory 1305, and the updating may be performed by processor 1310. At step 1414, the value of the local counter, or an indication of the value of the local counter, is sent to a user equipment. This step may be performed by transmitter 1315. In the example embodiments of gNB 1300 and method 1400, a local NCC and NCCDelta are maintained at the gNB side. Keys are generated at the network side and the user equipment side based on current and previous handover types. gNB 1300 may have the features of gNB 910 or 920 of system 900. In some example embodiments, the local NCC and NCC Delta are maintained by a DU of a gNB. Figure 18 shows a message flow sequence 1500 according to an example embodiment. Message flow sequence 1500 may take place between elements of system 900. At step 1510, UE 905 sends a measurement report to DU1 914. At step 1512, DU1 914 sends a measurement report to CUI 912. At step 1514, in response to receiving the measurement report, CUI 912 triggers the LTM preparation procedure. CUI 912 may generate a key generated using horizontal key derivation for all candidate cells. CUI 912 may create a key update group. Candidate cells may be mapped to a key update group corresponding to an associated gNB. Using the mapping, an indication of a key update group may be determined from an indication of a candidate cell (e.g., a candidate cell ID may map to a key update group ID), and candidate cells mapping to different key update groups may indicate that the candidate cells are associated with different gNBs. At step 1516 the LTM preparation request is sent to the target gNB 920. The keys generated using horizontal key derivation and configured key update group(s) / configured mapping may be embedded in this request. At step 1518 the target gNB 920 / CU2 922 prepares the LTM configuration by embedding the key update group / mapping in an LTM configuration. At steps 1520 and 1522, CU2 922 fetches context from DU2 924 by sending a UE context setup request message to DU2 924 and receiving a UE context setup response message from DU2 924. At step 1520, DU2 924 is provided with the key update group configuration / mapping. CU2 922 may additionally or alternatively configure DU2 924 with a set of rules for key generation, which may comprise algorithm 600. At step 1524 CUI 912 is informed about the LTM preparation from the CU2 922 side in an acknowledgement message. At steps 1526 and 1528, CUI 912 contacts DU1 914 to prepare the 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. At step 1526, CUI 912 provides DU1 914 with the key update group configuration / mapping. CUI 912 may additionally or alternatively configure DU1 914 with a set of rules for key generation, which may comprise algorithm 600. At step 1530, UE 905 is sent an RR.C reconfiguration message, configuring UE 905 for the LTM procedure. UE 905 may additionally be provided with the key update group configuration / mapping. At step 1532, UE 905 sends a reconfiguration complete message. Message flow sequence 1500 may therefore prepare UE for a LTM procedure. Using a mapping between candidate cells and a key update group, DUs may determine whether a handover is between cells associated with the same or different gNBs based on the mapping and an identifier of a current cell and a target / next cell. Using this determination and rules for key generation, a DU may indicate to a UE the key derivation method to use for the next key, for example by communicating a changed or unchanged NCC value to the UE. An NCC value may be indicated to a UE by a DU without sending the NCC value explicitly, for example by mapping the NCC value to another indicator. Figures 19 and 20 show first and second parts of a message flow sequence 1600. In this message flow sequence, the network maintains a local NCC value at the serving DU. This message flow sequence contains two handovers, both between cells associated with different gNBs. Message flow sequence 1600 may take place between elements of system 900. At step 1610, DU1 is storing a local NCC and NCC_Delta value. The NCC_Delta value may be zero (for example, because a preceding handover was an intra-gNB handover), and the NCC value may be aligned with the AMF NCC value. At step 1612, UE 905 sends an LI (Physical layer) measurement report to DU1 914. At step 1614, and in response to receiving the measurement report, DU1 914 determines that the cell serving UE 905 is to change to a different cell (a "target" cell). DU1 914 determines using the mapping configured during an LTM preparation procedure a key update group mapping to the cell ID of the target cell. In this case, the target cell corresponds to a different key update group to 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 a key derivation type and an updated NCC value. In this case, because the handover is inter-gNB, the key derivation type is horizontal, and the updated NCC value Is unchanged. The NCCDelta value is incremented by 1. At step 1616, DU1 914 sends a cell switch command to UE 905. The cell switch command indicates a target cell ID and indicates the updated NCC value. The cell switch command may be a MAC CE command. At step 1618, DU1 914 notifies CUI 912 of the change in cell serving UE 905. At step 1618, DU1 914 may also notify CUI 912 of the updated local NCC and NCC Delta values, so that these may be provided to the next serving DU. At step 1620, UE 905 performs the cell switch. Based on the updated NCC value, UE 905 may determine whether horizontal or vertical key derivation is to be used, so the key derivation used at UE 905 may match the key derivation used at the network side (e.g., at CU2 922, the CU of the new serving gNB). In this case, horizontal key derivation may be determined based on the updated NCC value being the same as the previous NCC value. Using horizontal key derivation, UE 905 may derive a key corresponding to a key derived at the network side. CU2 922 may have been provided with a corresponding key generated using horizontal key derivation for use after an inter-gNB handover during an LTM preparation procedure, such as at step 1516 of message flow sequence 1500, or after an LTM handover procedure. At step 1622, UE 905 sends an RRC reconfiguration complete message to DU2 924 and CU2 922. At step 1624, DU2 924 sends an access notification to CU2 922. At step 1626, the serving node CU2 922 notifies CUI 912 of the next key(s) generated using horizontal key derivation for use in the event of an inter-gNB handover to a cell of CUI 912. If the network and / or UE 905 Is configured for LTM handovers between cells associated with further gNBs, the further gNBs may be informed of the next key generated using horizontal key derivation. The current serving node CU2 922 may send the next key(s) via the Xn interface. CUI 912 also shares the local NCC and NCC_Delta values with CU2 922 (i.e., with other CU(s) of gNBs corresponding to candidate cells). At step 1628, the new current serving node sends a path switch request to AMF 930, informing AMF 930 of an inter-gNB handover. AMF 920 increments its NCC counter. At step 1630, AMF 930 sends a path switch acknowledgement message to the current serving node CU2 922. This includes the incremented NCC value and an updated NCC value, for use in generating a key at the network side for use after the next handover, if the next handover is vertical. At step 1632, CU2 922 calculates a next key using vertical key derivation (using the NCC and NH value). At this stage, keys generated using horizontal key derivation have been communicated to or otherwise obtained by candidate gNBs other than the serving gNB, and the serving gNB has generated a key using vertical key derivation. As 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. As horizontal key generation is used when a handover causes a change in serving gNB, if the next handover is not between cells associated with the current serving gNB, then the next key will be horizontal. At step 1634, UE 905 sends another LI measurement report to the current serving gNB (in this example to DU2 924 of the current serving gNB). This measurement report may contain measurements from which the serving gNB (or in this example DU2 924 of the current serving gNB) may determine that a second handover is desirable. At step 1636, and in response to receiving the measurement report, DU2 924 determines that the cell serving UE 905 is to change to a different cell (a "target" cell). DU2 924 determines using the mapping configured during an LTM preparation procedure a key update group mapping to the cell ID of the target cell. In this case, the target cell corresponds to a different key update group to 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 a key derivation type and an updated NCC value. In this case, because the handover is inter-gNB, the key derivation type is horizontal, and the updated NCC value is unchanged. The NCC Delta value is incremented by 1 (to 2, presuming that the NCC Delta was zero at step 1610). At step 1638, DU2 914 sends a cell switch command to UE 905. The cell switch command indicates a target cell ID and indicates the updated NCC value. The cell switch command may be a MAC CE command. At step 1640, DU2 914 notifies CU2 912 of the change in cell serving UE 905. At step 1618, DU2 914 may also notify CU2 912 of the updated local NCC and NCC_Delta values, so that these may be provided to the next serving DU. At step 1642, UE 905 performs the cell switch, similar to the cell switch of step 1620. As with step 1620, the updated NCC value is the same as the previous NCC value, so the key derivation used is horizontal. At step 1644, UE 905 sends an RRC Reconfiguration complete message to the new serving CU and DU of the new serving gNB, CUI 912 and DU1 914. At step 1648, CUI 912 uses the key generated using horizontal key derivation obtained at step 1626 to decipher a message from UE 905. At step 1650, similar to step 1626, CU2 922 provides the updated local NCC and NCC_Delta values to CUI 912, and CUI 912 provides the next key generated using horizontal key derivation to CU2 922. At steps 1652 and 1654, similar to steps 1628 and 1630, CUI 912 sends a path switch request to ANF 930, AMF 930 increments an NCC value, and AMF returns an updated NCC value and NH value in a path switch acknowledgement message. The updated NH and NCC value may be used at the network side to derive keys using vertical key derivation. Figures 21 and 22 show first and second parts of a message flow sequence 1700. In this message flow sequence, a UE maintains a local NCC value. This message flow sequence contains three handovers, the first being between cells associated with different gNBs, the second being between cells associated with the same gNB, and the third being between cells associated with different gNBs. Message flow sequence 1700 may take place between elements of system 900. Steps 1710 - 1732 relate to the first intra-gNB handover, and therefore correspond to comparable steps 1610 - 1632 of method 1600. At step 1734, UE 905 sends another LI measurement report to the current serving gNB (in this example to DU2 924 of the current serving gNB). This measurement report may contain measurements from which the serving gNB (or in this example DU2 924 of the current serving gNB) may determine that a second handover is desirable. At step 1736, and In response to receiving the measurement report, DU2 924 determines that the cell serving UE 905 is to change to a different cell (a "target" cell). DU2 924 determines using the mapping configured during an LTM preparation procedure a key update group mapping to the cell ID of the target cell. Unlike at 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 a key derivation type and an updated local NCC value. In this case, because the handover is intra-gNB, and the previous handover was inter-gNB (as may be inferred in some examples from a non-zero NCC_Delta value, the NCC value is incremented by the NCC Delta value and the key derivation type is vertical. If we take the initial local NCC value at step 1710 to be 0, the updated local NCC would be 1, as the NCC_Delta value is 1. After updating the local NCC value, the NCC_Delta value is reset to zero, and the local NCC value is now aligned with the AMF NCC value. At step 1738, similar to step 1638, DU2 914 sends a cell switch command to UE 905. The cell switch command indicates a target cell ID and indicates the updated NCC value. The cell switch command may be a MAC CE command. At step 1740, DU2 914 notifies CU2 912 of the change in cell serving UE 905. At step 1618, DU2 914 may also notify CU2 912 of the updated local NCC and NCC_Delta values, so that these may be provided to the next serving DU. At step 1742, UE 905 performs the cell switch, similar to the cell switch of step 1620 and 1720. Unlike at steps 1620 and 1720, the updated NCC value is not the same as the previous NCC value, so the key derivation used is vertical. At step 1744, UE 905 sends an RR.C reconfiguration complete message to DU2 924 and CU2 922. At step 1746, similar to step 1626, the previous serving CU (which is also the current serving CU, CU2 922, in this case) sends the updated local NCC and the NCCJelta to the other CUs configured for LTM (in this case just CUI 912), and the current serving CU, CU2 922, sends the next key generated using horizontal key derivation, to the other CUs configured for LTM. At step 1748, UE 905 sends another LI measurement report to the current serving gNB. Steps 1750 - 1760 correspond to steps 1714 - 1722 and 1726, showing a subsequent inter-gNB handover, which will use horizontal key derivation. Figure 23 is a block diagram 1800 Illustrating subsequent key derivation steps In the context of elements of model 100. Block diagram 1800 illustrates vertical 1810 and horizontal 1812 key derivation steps based on initial NH values and previous keys respectively, and shows the progression of NCC values and keys as handovers to cells of different key update groups occur. An initial key K9nb 1820 may be generated by a UE served by a cell corresponding to a first key update group, Key Update Group 1, for use in ciphering and / or deciphering communications between the UE and a gNB. K9nb 1820 is generated using vertical key derivation 1810 based on an NH value (and a cell ID and downlink frequency, which are not illustrated). The NCC value stored at the AMF and a local NCC value may initially be 1 in this example (the initial value is not significant for the purposes of this example). In a first handover, the UE is handed over to be served by a cell corresponding to a second key update group, Key Update Group 2. The key update group has changed, and this handover is therefore an inter-gNB / inter-CU handover, so horizontal key derivation 1812 is used, to derive a second key, K9nb 1822. The local NCC value is unchanged, but NCC_Delta is incremented, by 1, to 1. K9nb 1822 is messaged to other gNBs / CUs for subsequent horizontal key derivation (for use in inter-gNB / inter-CU handovers). In a second handover, the UE is handed over to be served by a cell corresponding to a third key update group, Key Update Group 3. The key update group has changed again, and this handover is therefore an inter-gNB / inter-CU handover, so horizontal key derivation 1812 is used, to derive a third key, K9nb 1824. The local NCC value is unchanged, but NCC_Delta is incremented, by 1, to 2. K9nb 1824 is messaged to other gNBs / CUs for subsequent horizontal key derivation (for use in inter-gNB / inter-CU handovers). In a third handover, the UE is handed over to be served by a cell corresponding to Key Update Group 3. The key update group Is unchanged, and this handover is therefore an intra-gNB / intra-CU handover. The previous handover was inter-gNB / inter-CU, and vertical key derivation 1810 is therefore used, to derive a fourth key, K9nb 1826. The NCC value is incremented by the NCC_Delta value (in this case by 2), to 3. The NCC_Delta value is reset. The updated NCC value and an NH value are used in deriving the key. K9nb 1826 is messaged to other gNBs / CUs for subsequent horizontal key derivation (for use in inter-gNB / inter-CU handovers). In a fourth handover, the UE is again handed over to be served by a cell corresponding to Key Update Group 3. The key update group is unchanged, and this handover is therefore an intra-gNB / intra-CU handover. The previous handover was also an intra-gNB / intra-CU handover, and horizontal key derivation is therefore used to derive a fifth key, K9nb 1828, from K9nb 1826. K9nb 1828 is messaged to other gNBs / CUs for subsequent horizontal key derivation (for use in inter-gNB / inter-CU handovers). For completeness, Figure 24 is a schematic diagram of components of one or more of the example embodiments described previously, which hereafter are referred to generically as a processing system 1900. The processing system 1900 may, for example, be comprised by the device referred to in the claims below. The processing system 1900 may have a processor 1902, a memory 1904 closely coupled to the processor and comprised of a RAM 1914 and a ROM 1912, and, optionally, a user input 1910 and a display 1918. The processing system 1900 may comprise one or more network / apparatus interfaces 1908 for connection to a network / apparatus, e.g. a modem which may be wired or wireless. The network / apparatus interface 1908 may also operate as a connection to other apparatus such as device / apparatus which is not network side apparatus. Thus, direct connection between devices / apparatus without network participation is possible. The processor 1902 is connected to each of the other components in order to control operation thereof. The memory 1904 may comprise a non-volatile memory, such as a hard disk drive (HDD) or a solid state drive (SSD). The ROM 1912 of the memory 1904 stores, amongst other things, an operating system 1915 and may store software applications 1916. The RAM 1914 of the memory 1904 is used by the processor 1902 for the temporary storage of data. The operating system 1915 may contain code which, when executed by the processor implements aspects of the methods 500, 800, and 1400 described above, along with aspects of the message flow sequences 300, 1000, 1100, 1200, 1500, 1600, and 1700, and algorithm 600. Note that in the case of small device / apparatus the memory can be most suitable for small size usage i.e. not always a hard disk drive (HDD) or a solid state drive (SSD) is used. The processor 1902 may take any suitable form. For instance, it may be a microcontroller, a plurality of microcontrollers, a processor, or a plurality of processors. The processing system 1900 may be a standalone computer, a server, a console, or a network thereof. The processing system 1900 and needed structural parts may be all inside device / apparatus such as loT device / apparatus i.e. embedded to very small size. 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 / apparatus and may run partly or exclusively on the remote server device / apparatus. These applications may be termed cloud-hosted applications. The processing system 1900 may be in communication with the remote server device / apparatus in order to utilize the software application stored there. FIG. 25 shows a tangible media, in the form of a removable memory unit 2010, storing computer-readable code which when run by a computer may perform methods according to example embodiments described above. The removable memory unit 2010 may be a memory stick, e.g. a USB memory stick, having internal memory 2030 storing the computer-readable code. The internal memory 2030 may be accessed by a computer system via a connector 2020. Of course, other forms of tangible storage media may be used, as will be readily apparent to those of ordinary skilled in the art. Tangible media can be any device / apparatus capable of storing data / information which data / information can be exchanged between devices / apparatus / network. Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and / or hardware may reside on memory, or any computer media. In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a "memory" or "computer-readable medium" may be any non-transitory media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer. Reference to, where relevant, "computer-readable medium", "computer program product", "tangibly embodied computer program" etc., or a "processor" or "processing circuitry" etc. should be understood to encompass not only computers having differing architectures such as single / multi-processor architectures and sequencers / parallel architectures, but also specialised circuits such as field programmable gate arrays FPGA, application specify circuits ASIC, signal processing devices / apparatus and other devices / apparatus. References to computer program, instructions, code etc. should be understood to express software for a programmable processor firmware such as the programmable content of a hardware devlce / apparatus as instructions for a processor or configured or configuration settings for a fixed function device / apparatus, gate array, programmable logic device / apparatus, etc. If desired, the different functions discussed herein may be performed in a different order and / or concurrently with each other. Furthermore, if desired, one or more of the abovedescribed functions may be optional or may be combined. Similarly, it will also be appreciated that the algorithms and flow and signalling diagrams of Figures 3, 4, 6, 7, 9, 11, 12, 13, 14, 15, 17, 18, 19, 20, 21, and 22 are examples only and that various operations depicted therein may be omitted, reordered and / or combined. It will be appreciated that the above-described example embodiments are purely illustrative and are not limiting on the scope of the invention. Other variations and modifications will be apparent to persons skilled in the art upon reading the present specification. Moreover, the disclosure of the present application should be understood to include any novel features or any novel combination of features either explicitly or implicitly disclosed herein or any generalization thereof and during the prosecution of the present application or of any application derived therefrom, new claims may be formulated to cover any such features and / or combination of such features. Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described example embodiments and / or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims. It is also noted herein that while the above describes various examples, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. An apparatus, comprising:means for storing a local counter;means for, responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to 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.

2. The apparatus of claim 1, further comprising means for storing a second local counter,wherein updating the local counter according to the predetermined algorithm comprises incrementing the local counter by an amount based on the second local counter.

3. The apparatus of claim 2, further comprising:means for obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs;means for obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; andmeans for determining whether to generate a key using horizontal or vertical key derivation based at least in part upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs.

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

5. The apparatus of any of claims 3 or 4, wherein the means for determining whether to generate a key using horizontal 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 ahandover between cells associated with different gNBs, and wherein the means 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 of any of claims 3-5, wherein:the means for determining whether to generate a key using horizontal or vertical key derivation is configured to determine that horizontal key derivation should be used when the current handover is a handover between cells associated with different gNBs; andthe apparatus further comprises means for incrementing the second local counter in response to the current handover being a handover between cells associated with different gNBs.

7. The apparatus of any of claims 1-6, wherein the apparatus is a current gNB, and further comprises:means for providing an indication of the value of the local counter to a user equipment.

8. The apparatus of claim 7, further comprising:means for obtaining a list of candidate cells;means for executing a handover between cells associated with the current gNB;means for indicating to one or more gNBs associated with cells of the list of candidate cells that a handover between cells associated with the current gNB has taken place;means for generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; andmeans for sending, for each gNB of the one or more gNBs, the generated keys for use in the event of a cell switch to a cell associated with that gNB.

9. The apparatus of claim 7 or claim 8, further comprising:means for obtaining a list of candidate cells;means for completing a handover from a cell associated with a different gNB to a cell associated with the current gNB;means for indicating to one or more gNB associated with cells of the list of candidate cells that a handover between cells associated with different gNBs has taken place;means for generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; andmeans for sending, for each network node of the one or more gNBs, generated keys for use in the event of a cell switch to a cell associated with that gNB.

10. The apparatus of any of claims 7-9, further comprising:means for storing a current cell ID corresponding to a cell associated with the user equipment;means for obtaining a target cell ID corresponding to a target cell to which the user equipment is to be handed over from the current cell; andmeans for determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs.

11. The apparatus of any of claims 1-6, wherein the apparatus is a user equipment, and further comprising:means for generating a key using the determined key derivation, wherein the generated key is based at least in part on the local counter if vertical key derivation is selected.

12. The apparatus of claim 11, further comprising:means for storing a current cell ID;means for receiving from a gNB a target cell ID; andmeans for determining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs.

13. A method comprising:storing a local counter;responsive to determining that a key for ciphering and / or deciphering communications between a user equipment and a next generation Node B, gNB, is to be generated using a vertical key derivation, updating the local counter according to 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.

14. The method of claim 13, further comprising:storing a second local counter, wherein updating the local counter according to the predetermined algorithmcomprises incrementing the local counter by an amount based on the second local counter.

15. The method of claim 14, further comprising:obtaining an indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs;obtaining an indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs; anddetermining whether to generate a key using horizontal or vertical key derivation based upon one or both of the indication of whether a current handover is a handover between cells associated with the same gNB or different gNBs and the indication of whether a previous handover is a handover between cells associated with the same gNB or different gNBs.

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

17. The method of claim 15 or 16, wherein determining whether to generate a key using horizontal or vertical key derivation comprises 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 is a handover between cells associated with different gNBs, and further comprising resetting the second local counter to zero in response to updating the local counter.

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

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

20. The method of claim 19, further comprising:obtaining a list of candidate cells;executing a handover between cells associated with a current gNB;indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with the current gNB has taken place;generating, for each cell of the list of candidate cells, a key using horizontal key derivation for use in the event of a cell switch to that cell; andsending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB.

21. The method of claim 19 or 20, further comprising:obtaining a list of candidate cells;completing a handover from a cell associated with a different gNB to a cell associated with a current gNB;indicating to one or more gNBs other than the current gNB associated with cells of the list of candidate cells that a handover between cells associated with different gNBs has taken place;generating, for each cell of the list of candidate cells associated with a gNB other than the current gNB, a key using horizontal key derivation for use in the event of a cell switch to that cell; andsending, to each gNB of the one or more gNBs other than the current gNB, one or more generated keys for use in the event of a cell switch to a cell associated with that gNB.

22. The method of any of claims 19 - 21, further comprising:storing a current cell ID corresponding to a cell associated with the user equipment;obtaining a target cell ID corresponding to a target cell to which the user equipment is to be handed over from the current cell; anddetermining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the same gNB or different gNBs.

23. The method of any of claims 13 - 18, further comprising:generating a key using the determined key derivation, wherein the generated key is based at least in part on the local counter if vertical key derivation is selected.

24. The method of claim 23, further comprising:storing a current cell ID;receiving from a gNB a target cell ID; anddetermining from the target cell ID and the current cell ID whether a handover from the current cell to the target cell is a handover between cells associated with the5 same gNB or different gNBs.

Images