Prefetching of security information for inter-CU ltm

Abstract

Methods and apparatus for performing mobility in a wireless communication network. An example method, performed by a network node configured to provide a serving cell to a user equipment, UE, and comprises the step of requesting (6001), from a second network node, security information for potential use by the UE after a mobility procedure to the second network node. The example method further comprises receiving (6002) one or more security parameters from the second network node, in response to the request, and forwarding (6003) the one or more security parameters to the UE, for its use in deriving keys for communication with the second node after performing mobility towards the second node.

Description

[0001] PREFETCHING OF SECURITY INFORMATION FOR INTER-CU LTM

[0002] TECHNICAL FIELD

[0003] The present application relates generally to the field of wireless networks, and more specifically to improving mobility of user equipment (UEs) across multiple cells in a wireless network, specifically mobility based on layer-1 (LI) and / or layer-2 (L2) procedures that incur less delay than conventional layer-3 mobility procedures.

[0004] BACKGROUND

[0005] Security parameters in LTE and NR

[0006] Currently the fifth generation (5G) of cellular systems is being standardized within the Third- Generation Partnership Project (3GPP). NR is developed for maximum flexibility to support multiple and substantially different use cases. These include enhanced mobile broadband (eMBB), machine type communications (MTC), ultra-reliable low latency communications (URLLC), side-link device-to- device (D2D), and several other use cases.

[0007] In the Long-Term Evolution (LTE) and New Radio (NR) radio access networks (RANs) developed by 3GPP, security is applied between the user equipment (UE) and the network using a shared secret called a Next Hop (NH) parameter, which may be referred to as an "NH value." Another parameter used in these security procedures is the Next Hop Chaining Count (NCC), which is a counter that tracks the number of key chainings performed and facilitates synchronization of the UE's security parameters with the eNB. In particular, the NCC determines whether the next KeNB or KgNB, for example, should be based on the current KeNB or KgNB or based on a new KeNB or KgNB derived from a new NH value.

[0008] New NH values can be derived individually by both the UE and the core network in a sequential way, meaning that the UE and the network will derive the same sequence of NH values. The NH value can be partially referred to by the NCC value, in such a way that if a specific NH value is known, the NCC can point to one of the next 7 NH values, since the NCC value is three bits long and can thus indicate up to eight separate NH values.

[0009] In the existing signaling structure, the UE and the network each have a common NH value. If the network wants to perform a security update with a new NH value as base, it can indicate a NCC value to the UE and the UE will by that NCC value see if it should progress forward in the NH derivation chain. As long as the network indicates an NH value that is not more than 7 steps ahead, the UE will derive the same NH value as the network, and the Radio Resource Control (RRC) signaling with the applied security parameters will compute at both UE and network side. If the network and UE fall out of sync with respect to the NH value, the RRC messages from the UE to the network can't be decoded and RRC will time out according to legacy procedures, leading to a security reset between the UE and the network.

[0010] Security update with a new NH value is referred to as vertical key derivation. There is a lesser security update which only applies security based on the previous security, but also with input about a new cell's PCI and frequency. This lesser security update is referred to as horizontal key derivation. The principles of these horizonal and vertical key derivations are illustrated in Figure 1.

[0011] Another security aspect to consider is key separation between gNBs. To avoid allowing a potential attacker with knowledge of the current NH value to follow a user to a new gNB in a mobility procedure, one gNB should not know the NH values applied by other gNBs. Because of this, the NH values are only known to the core network and signaled to the target gNB in the event of a mobility procedure. The serving gNB will only be made aware of the NCC value, which points to the applied NH value in the target cell. The gNB can signal the NCC value to the UE, which will then know whether to perform horizontal or vertical key derivation, and, in case of the latter, which NH value to use.

[0012] The NH and NCC values are fetched for a mobility procedure when the UE has entered the target cell through the PATH SWITCH PROCEDURE, where the target gNB informs the core network about the new downlink termination point. In the Path Switch Request Acknowledge message from the Access & Mobility Function (AMF) to the target gNB, there is also an NH, NCC combination signaled.

[0013] If an unused NH value is present in the gNB for a UE, it should be applied as soon as possible by the RAN. The NH value can be signaled in existing procedures, such as an Intra-Cell Handover, for example. If no NH value is provided, the UE can update security by a horizontal key derivation instead.

[0014] Layer 1 / Layer 2 (Ll / L2)-Triggered Mobility (LTM) in 3GPP Rel-18

[0015] Layer 1 / Layer 2-Triggered Mobility (LTM) has been specified in Release 18 of the 3GPP specifications as part of the Mobility enhancements Work Item. According to a version of the running change request (CR) for 3GPP TS 38.300, LTM is a procedure in which a gNB receives LI measurement report(s) from a UE and, on their basis, changes UE's serving cell using a cell switch command signalled via a MAC CE. The cell switch command indicates an LTM candidate cell configuration that the gNB previously prepared and provided to the UE through RRC signalling. Upon receipt of the command, the UE switches to the target cell, according to the cell switch command. The LTM procedure can be used to reduce mobility latency. LTM supports both intra-gNB-DU and intra-gNB-CU / inter-gNB-DU mobility. LTM supports both intrafrequency and inter-frequency mobility, including mobility to an inter-frequency cell that is not a current serving cell.

[0016] 1) the 'handover / mobility-to-wrong-cell' cases a. The original serving cell can classify a handover failure to be 'handover / mobility-to- wrong-cell' when the original serving cell intends to perform the handover for this UE towards a particular target cell but the UE declares failure or declares failure shortly after successfully completing the handover and then reestablishes itself in a third cell. b. A corrective action from the original serving cell could be to initiate the measurement reporting procedure that leads to handover towards the target cell a bit later by decreasing the CIO (cell individual offset) towards the target cell or via initiating the handover towards the cell in which the UE reestablished a bit earlier by increasing the CIO towards the reestablishment cell.

[0017] Several issues remain.

[0018] In the case of an inter-Central Unit (inter-CU) lower layer triggered mobility (LTM) mobility procedure, where a UE is being handed over from one gNB to another, a vertical key derivation may be required. Typically, when this happens the target node receives new security parameters from its core network and these new security parameters are passed to the UE, via the source node, within the handover command. However, LTM supports a feature where the UE is not reconfigured between one LTM cell switch and another one - this feature is called "subsequent LTM." Given that new security parameters are needed when a vertical security derivation is done, the question is how these new security parameters can be forwarded to the UE in such a scenario, assuming that it should be possible for the network to use the subsequent LTM feature. According to this, it might also be the case that for Rel-19 Inter-CU LTM, it would be beneficial to prefetch the NH, NCC values, in order to apply these parameters already at the LTM cell switch command (instead of doing it in the target cell after the LTM cell switch). Because this requires a new NH value, then the NCC value needs to be signaled to the UE.

[0019] A problem is that the only way of fetching the NH, NCC value pair from the AMF during Xn-based handover is through the PATH SWITCH PROCEDURE, which is done after the cell switch.

[0020] A proposal to BGPP's RAN2 working group describes a solution according to which the security parameter (e.g., key material) is generated in advance for each candidate cell, e.g., for each LTM candidate configuration. A drawback with this solution is that in the case where multiple candidate cells are prepared, only one of these keys will be used and the others will be wasted. This increases the risk of wrap-around of the Next Hop Chaining Count, NCC. One limitation of this proposed solution is that no distinction is made among the candidate network nodes and lots of unnecessary pairs of NCC, NH will be derived and not used. For instance, in case a UE is configured with the maximum of eight LTM candidate cells, there will be one serving cell and seven candidate cells, and if each one of those seven candidate cells is served by a different gNB, seven pairs of NCC, NH values will be needed. This has an impact in terms of signaling and is a waste of NCC, NH resources.

[0021] SUMMARY

[0022] Techniques, apparatuses and systems to address these problems are described herein. According to various embodiments of the inventive techniques and apparatuses described herein, a procedure is introduced for a gNB to request a NH, NCC combination from the AMF without applying Path Switch Procedure. This procedure is performed before executing a mobility procedure, such as during an LTM and / or Conditional LTM preparation procedure. In one option, the procedure is combined with the Handover Request procedure, e.g., over Xn, and a new procedure over NG.

[0023] In one option, a modified path switch procedure that doesn't fetch new security parameters is introduced. This modified path switch procedure is performed during an LTM and / or Conditional LTM preparation procedure.

[0024] In one option, a modified path switch procedure is executed after LTM execution, where information elements used to signal NH and NCC from a core network node to a RAN network node are included but not used or ignored by the receiver, based on the presence of an indicator indicating that the above information elements shall not be used or ignored by the receiver, e.g., due to new values for NH and NCC having been obtained already by the receiver (e.g., prefetched by the receiver from core network, or pushed from the core network to the receiver).

[0025] Embodiments of the presently disclosed techniques, apparatuses, and systems include an example method, in a UE, for performing mobility, where the method comprises receiving, from a serving network node, one or more security parameters applicable to communication with a second network node not serving the UE. The example method further comprises performing a mobility procedure to the second network node and communicating with the second network node using one or more keys derived from the one or more security parameters.

[0026] Other embodiments include another example method, performed in a network node configured to provide a serving cell to a UE, where the method comprises requesting, from a second network node, security information for potential use by the UE after a mobility procedure to the second network node. This example method further comprises receiving one or more security parameters from the second network node, in response to the request, and forwarding the one or more security parameters to the UE.

[0027] Additional embodiments include another example method, performed in a network node, where the method comprises receiving, from a serving network node configured to provide a serving cell to a UE, a request for security information for potential use by the UE after a mobility procedure to a network node other than the serving network node. The method further comprises sending one or more security parameters to the serving network node, in response to the request, for forwarding to the UE.

[0028] Still further embodiments include yet another example method performed by a network node, where the method comprises receiving, from a serving network node configured to provide a serving cell to a UE, an indication that the UE may perform a mobility procedure to the network node, and requesting, from a third network node, one or more security parameters for the UE.

[0029] Other embodiments include apparatuses configured to carry out each of the methods summarized above, and variants thereof, as well as systems comprising two or more of these apparatuses.

[0030] Using the presently disclosed techniques:

[0031] • A candidate gNB can fetch a new NH value from the AMF.

[0032] • The candidate gNB can signal the NCC value only to the serving gNB.

[0033] • A modified path switch procedure without NH, NCC signaled from the AMF can be used.

[0034] • A new NGAP procedure for LTM or Conditional LTM can be used to request and obtain new values for NH, NCC without at the same time performing a path switch.

[0035] Using these techniques, vertical Key Derivation can be executed at an LTM cell switch, instead of being separately performed in a second step in the target gNB. This will reduce signaling, and since a vertical key derivation performed once in the candidate / target gNB may cause additional interruption, the solution reduces the interruption time.

[0036] Another advantage is that the solutions described herein enable the new security parameter to be generated just in time for the mobility procedure.

[0037] BRIEF DESCRIPTION OF THE FIGURES

[0038] Figure 1 illustrates vertical and horizontal key derivation procedures. Figure 2 is a schematic diagram illustrating nodes involved in various embodiments of the techniques described herein.

[0039] Figure 3 is a signaling flow diagram illustrating mobility procedures according to some embodiments of the presently disclosed invention.

[0040] Figure 4 is another signaling flow diagram illustrating mobility procedures according to some other embodiments of the presently disclosed invention.

[0041] Figure 5 is another signaling flow diagram illustrating mobility procedures according to still other embodiments of the presently disclosed invention.

[0042] Figure 6 is a process flow diagram illustrating an example method for a network node, according to various embodiments of the present disclosure.

[0043] Figure 7 is a process flow diagram illustrating another example method for a network node, according to various embodiments of the present disclosure.

[0044] Figure 8 is a process flow diagram illustrating still another example method for a network node, according to various embodiments of the present disclosure.

[0045] Figure 9 is a process flow diagram illustrating an example method for a network node such as an AMF, according to various embodiments of the present disclosure.

[0046] Figure 10 is a process flow diagram illustrating another example method for a network node such as an AMF, according to various embodiments of the present disclosure.

[0047] Figure 11 shows a communication system according to various embodiments of the present disclosure.

[0048] Figure 12 shows a UE according to various embodiments of the present disclosure.

[0049] Figure 13 shows a network node according to various embodiments of the present disclosure.

[0050] Figure 14 shows a host computing system according to various embodiments of the present disclosure.

[0051] Figure 15 is a block diagram of a virtualization environment in which functions implemented by some embodiments of the present disclosure may be virtualized. Figure 16 illustrates communication between a host computing system, a network node, and a UE via multiple connections, at least one of which is wireless, according to various embodiments of the present disclosure.

[0052] DETAILED DESCRIPTION

[0053] An LTM cell switch procedure may be triggered in the UE by reception of an LTM cell switch command, or, alternatively, triggered by some other event, such as a condition, e.g., a triggering condition used for conditional configuration, such as conditional handover, being fulfilled, as a result of recovery from radio link failure or handover failure.

[0054] This description refers to an inter-CU LTM cell switch procedure, which is an LTM cell switch procedure resulting in a change of serving cell, e.g., a change of SpCell, PCell, PSCell, to an LTM candidate cell controlled by a different gNB than the source gNB or serving gNB of the UE upon reception of the LTM cell switch command or, alternatively, triggered by some other event, such as a condition that triggers a conditional handover. From the UE's point of view, the actions performed during an inter-CU LTM cell switch procedure may be the same type of actions of an LTM cell switch procedure, but may also include additional actions, such as a change of security key(s).

[0055] This description also refers to an inter-CU LTM candidate cell configuration. An inter-CU LTM candidate cell configuration is a LTM candidate cell configuration that contains the configuration which the UE needs to start to operate accordingly when it performs an LTM cell switch procedure to an LTM candidate cell that is controlled by a different base station, e.g. gNB, from the current source base station, e.g., the serving gNB of the UE. An inter-CU LTM candidate cell configuration may be the same as an LTM candidate cell configuration but it may also include additional information over what is included in the LTM candidate cell configuration used for inter-CU cell switch. This additional information may include, for example:

[0056] • Information to perform security key refresh, e.g., the RRC Information Element (IE) MasterKeyUpdate or an RRC IE RadioBearerConfig that includes SecurityConfig with SecurityAlgorithmConfig /

[0057] • Information for vertical or horizontal key derivation during handover or security key refresh as specified in 3GPP TS 33.501 (e.g., deriving or updating the KgNB key) such as a Next Hop parameter, NH, a Next Hop Chaining Counter, NCC, or a NAS container, NASC, containing information such as a K_AMF_change_flag, downlink NAS COUNT, ngKSI, selected NAS security algorithms, and NAS MAC.

[0058] • An indication to perform a full configuration, e.g., the RRC field fullConfig. The term security key refresh as used herein refers to the UE changing its security key, e.g., during a mobility procedure such as an inter-CU LTM cell switch procedure. A security key refresh may comprise at least one of:

[0059] • The UE receives a Master Key Update parameter / IE (e.g., masterKeyUpdate) included in the inter-CU LTM candidate cell configuration (e.g., set by the Target CU);

[0060] • When a Non-Access Stratum (NAS) indication (e.g., nas-Container) is received (e.g., within the Master Key Update parameter / IE) the UE forwards the NAS indication to the upper layer (e.g., UE NAS layer);

[0061] • When a key set change indication (e.g., keySetChangelndicator) is received and / or is set to 'true' (e.g. within the Master Key Update parameter / IE) the UE derives or updates the KgNB key based on the KAMF key, as specified in TS 33.501;

[0062] • The UE derives or updates the KgNB key (for the inter-CU LTM candidate cell configuration indicated in the LTM cell switch command) based on the current KgNB key or the NH, using the Next Hop Chaining Count (e.g., nextHopChainingCount) value indicated in the received Master Key Update parameter / IE (e.g. MasterKeyUpdate), as specified in TS 33.501;

[0063] • The UE derives the KRRCenc and KUPenc keys associated with a ciphering algorithm (e.g., cipheringAlgorithm indicated in the securityAlgorithmConfig), as specified in TS 33.501;

[0064] • The UE derives the KRRCint and KUPint keys associated with an integrity protection algorithm (e.g., integrityProtAlgorithm indicated in the securityAlgorithmConfig), as specified in TS 33.501;

[0065] • The UE receives a security algorithm configuration included in the inter-CU LTM candidate cell configuration, based on which the UE derives User plane keys and / or control plane keys (e.g., for encryption and / or integrity protection) e.g., the KRRCenc and KUPenc keys, the KRRCint and KUPint keys;

[0066] • The UE uses its current security algorithm configuration, based on which the UE derives User plane keys and / or control plane keys (e.g. for encryption and / or integrity protection) e.g., the KRRCenc and KUPenc keys, the KRRCint and KUPint keys;

[0067] • The UE applies the provided ciphering algorithm and key during an PDCP entity reestablishment procedure;

[0068] • The UE applies the provided integrity protection algorithm and key during an PDCP entity reestablishment procedure

[0069] This description frequently refers to a security parameter. A security parameter may be a Master Key Update parameter / IE (e.g., masterKeyUpdate), key material for AS security, or information for vertical or horizontal key derivation during handover or security key refresh as specified in 3GPP TS 33.501 (e.g., deriving or updating the KgNB key) such as a Next Hop parameter, NH, a Next Hop Chaining Counter, NCC, KNG-RAN key, KgNB key, KNG-RAN* key, KgNB* key or a NAS container, NASC, containing information such as a K_AMF_change_flag, downlink NAS COUNT, ngKSI, selected NAS security algorithms, and NAS MAC. The term "security parameter" may refer to a single parameter or a set of parameters. Examples of such parameters are given here.

[0070] This description also refers to horizontal key derivation and vertical key derivation. In the context of this disclosure, horizontal key derivation refers to when a key used for securing the communication between the UE and the network, such as the KgNB key or KNG-RAN key, for example, used for communication with the next network node during mobility, is derived from the key used in the previous network node, sometimes referred to as the currently active key. In the context of the invention, vertical key derivation is when a key used for securing the communication between the UE and the network, such as the KgNB key or KNG-RAN key, for example, used for communication with the next network node during mobility, is derived from information, such as a Next Hop, NH, parameter, received from another network node, such as a core network node. More detailed examples of horizontal key derivation and vertical key derivation are specified in 3GPP TS 33.501.

[0071] This disclosure also refers to a mobility command. The term mobility command includes messages transmitted to the UE, such as an RRC message or a lower layer signalling, such as a MAC Control Element, that indicate to the UE to perform mobility to a cell (sometimes referred to as a target cell or a candidate cell), or a network node (sometimes referred to as a second network node, target gNB, or candidate gNB, and / or a beam. Examples of a mobility command includes a Handover command message, an RRCReconfiguration message including reconfigurationWithSync, or an LTM Cell Switch Command MAC CE. An LTM Cell Switch Command MAC CE may also be referred to as an LTM execution message. The term mobility command also includes messages that do not result in mobility but result in a mobility-related reconfiguration being performed by the UE. A mobility command received by the UE results in that the UE executes a mobility procedure, such as handover, LTM cell switch. In some cases, the reception of a mobility command by the UE results in that the UE performs security refresh or applies or stores security parameters.

[0072] Figure 2 illustrates a system structure including the entities involved in the invention. The User Equipment (UE) 1001 is a wireless terminal, such as a cellular smartphone, sometimes connected to the first network node 1002 over a wireless interface 1004 and sometimes connected to a second network node 1003, over a wireless interface 1005. The first network node 1002 controls a first cell 1007 (sometimes called serving cell or Special Cell, SpCell, PCell or PSCell, or, in the context of mobility, referred to as source cell). The second network node 1003 controls a second cell 1008, which sometimes, e.g,. in the context of mobility, is referred to as target cell, neighbour cell, candidate cell, LTM candidate cell or inter-CU LTM candidate cell.

[0073] Each of first network node 1002 and the second network node 1003 may be a base station, such as, when they are part of NG-RAN, a gNB. The first network node and the second network node may sometimes be interconnected over an interface 1006, which may be an Xn or Xn-C type of interface, for example when the first network node and second network node are of type gNB and part of an NG-RAN. In some cases, the first network node and the second network node are not interconnected.

[0074] In the context of mobility, such as L1 / L2 triggered mobility or layer 3 handover, the first network node 1002 may sometimes be referred to as either source network node, source gNB, serving network node or serving gNB, and the second network node 1003 may sometimes be referred to as either target network node, target gNB, candidate network node or candidate gNB.

[0075] In some cases, such as during intra-gNB or intra-CU mobility, the first network node and the second network node are the same network node.

[0076] In case of a distributed CU / DU RAN architecture, each of the first network node 1002 and / or the second network node 1003 may be divided into a distributed unit, sometimes known as gNB-DU or DU, and a central unit, CU, sometimes referred to as gNB-CU, CU, gNB-CU-CP or gNB-CU-UP. Thus, in such a case the first network node 1002 may be divided into a first central unit, CU sometimes referred to as serving CU or source CU, and a first distributed unit, DU, and second network node 1003 may be divided into a second central unit, CU sometimes referred to as target CU or candidate CU, and a second distributed unit, DU. Sometimes the first central unit, CU, is referred to as the first network node and the second central unit, CU, is referred to as the second network node. In some cases, such as during intra-gNB or intra-CU mobility, the first CU and the second CU are the same node (same CU).

[0077] The first network node 1002 and the second network node 1003 may be connected to a third network node 1009 over interfaces 1010 and 1011, respectively. The third network node 1009 may be, for example, a core network node, such as an 5G Core Network (5GC) node, a User Plane Function, UPF or an Access and Mobility management Function, AMF. In the latter case, the interfaces 1010 and 1011 are both an NG type of interface or an N2 reference point. Sometimes the third network node are two different network nodes, one (e.g., a source AMF) connected with the first network node and one (e.g., a target AMF) connected with the second network node. These two different network nodes may be inter-connected over an interface, such as an N14 reference point or an Namf type of service-based interface.

[0078] Figure 3 illustrates a message sequence chart in one example of one embodiment of the invention. In this example, the first network node requests security parameters from the second network node.

[0079] Referring to Figure 3, the main steps in this example are as follows.

[0080] Start. A UE is connected to a first network node in state RRC_CONNECTED with one or more LTM candidate configurations. The UE might be presynched in UL and / or DL, but it is not essential for the techniques described herein.

[0081] Step 4. The first network (source gNB) node prepares for the mobility procedure by contacting the candidate gNB and instructing it to fetch security information.

[0082] Step 5. The second network (candidate gNB) node contacts the AMF with a request for applicable NH, NCC pair for the UE.

[0083] Step 6. The third network node (AMF) sends the applicable NH, NCC pair to the second network node. This might be a new NH, NCC pair, but could also be the same NH, NCC pair, depending on what the AMF decides for the combination of source and candidate cell (vertical or horizontal key derivation).

[0084] Step 7. The NCC value received at the second network node is sent to the first network node (not sending NH to maintain key separation between gNBs, this is step 7 in Figure 3).

[0085] Step 8-10. The NCC value is delivered to the UE, either in a cell switch command, or separately (step 8, 9 or 10 in Figure 3). The UE executes the mobility procedure towards the second network node, either by instruction of the first network node, or conditionally.

[0086] Step 11. Optionally: The first network node notifies the second network node about the NCC that the UE will use.

[0087] Step 12. The UE communicates with the second network node by the NCC indicated to the UE by the first network node. Step 12 in Figure 3.

[0088] Step 13-14. The second network node prepares a path switch towards the third network node. If the third network includes a new NH, NCC to the second network node, the second network node ignores it.

[0089] Error! Reference source not found, illustrates a message sequence chart in one example of one embodiment of the techniques described herein. In this example, the second network node inquires about the necessity of updating security parameters from the first network node. Referring to Error! Reference source not found., the main steps in this example are as follows.

[0090] Step 1. The source gNB decides to configure the UE for LTM.

[0091] Step 2. The UE sends the LI measurements to the source gNB.

[0092] Step3. Pre-sync is triggered between UE and the candidate gNB.

[0093] Step 4. The candidate gNB sends an enquiry to the source gNB if any UE configured with LTM will switch to the cell under the candidate gNB soon.

[0094] Step 5. The source gNB replies with the UE related info to the candidate gNB.

[0095] Step 6 / 7. The candidate gNB initiates a request to the AMF to receive new security info.

[0096] Step 8 / 9. The source gNB decides to execute LTM for the UE, and it sends a request to the candidate gNB for the new security info.

[0097] Step 10 / 11 / 12. The source gNB delivers the new NCC to the UE via RRC or MAC CE message.

[0098] Step 13. The source gNB sends the Cell Switch Notification message to the candidate gNB.

[0099] Step 14. RRCReconfigurationComplete is done between the UE and the target gNB.

[0100] Step 15 / 16. Path Switch procedure is triggered to the AMF.

[0101] Figure 5 illustrates a message sequence chart in one example of one embodiment of the invention. In this example, the first network node (source gNB) requests security parameters from the third network node (AMF).

[0102] Referring to Figure 5, the main steps in this example are as follows.

[0103] Step 1. The source gNB determines to perform mobility of the UE to a cell controlled by the candidate gNB.

[0104] Step 2. The source gNB transmits, to the AMF, a message including a request for a security parameter for the UE. In one example, the message is a HANDOVER REQUEST NGAP message. In another example, the message is a new type of NGAP message, such as a SECURITY INFO REQUEST message. The message also includes an indication of a cell, such as a target cell or a candidate cell identity and / or an indication of an address of the candidate gNB.

[0105] Step 3. The AMF determines that a new security parameter needs to be generated for the UE, for AS security. In one example, the AMF determines that a new security parameter, such as a Next Hop, NH, parameter, needs to be generated because of mobility that requires vertical key derivation. The AMF generates the new security parameter.

[0106] Step 4. The AMF transmits, to the candidate gNB (corresponding to the second network node), a message that includes a new security parameter for the UE. In one example, the message is a HANDOVER REQUEST NGAP message. In another example, the message is a new type of NGAP message, such as a SECURITY INFO message. The security parameter in the message may in one example be an AS Security Information IE including K NG-RAN Star and Next Hop Chaining Count (NCC), or it may be in another example a Next Hop, NH, NCC pair.

[0107] Steps 5-6. The candidate gNB stores the received new security parameter for the UE and transmits a response message to the AMF confirming that the security parameter has been received. The message may also include a configuration for the UE in the target / candidate cell, which may in one example be in form of a Handover command message, an RRCReconfiguration message or an LTM candidate configuration. In one example, the response message is a HANDOVER REQUEST ACKNOWLEDGE NGAP message. In another example, the message is a new type of NGAP message, such as a SECURITY INFO ACK message.

[0108] Step 7. The AMF transmits, to the source gNB, a response message including the new security parameter. The message may also include a configuration for the UE in the target / candidate cell, which may in one example be in form of a Handover command message, an RRCReconfiguration message or an LTM candidate configuration. In one example, the response message is a HANDOVER COMMAND NGAP message. In another example, the message is a new type of NGAP message, such as a SECURITY INFO RESPONSE message.

[0109] Step 8. The source gNB then triggers execution of a mobility procedure for the UE towards a target / candidate cell controlled by the candidate gNB, by transmitting a Mobility command to the UE. The Mobility command may in one example be a Handover command message, such as an RRCReconfiguration message including reconfigurationWithSync. Ine another example, the Mobility command may be an LTM Cell Switch Command MAC CE. The Mobility command includes an indication of the target / candidate cell and an indication of a new security parameter for the UE.

[0110] Step 9. The UE executes the Mobility procedure, such as layer 3 handover or LTM cell switch towards the target / candidate cell and performs security key refresh using the received indication of a new security parameter.

[0111] Step 10. The UE transmits a message to the candidate gNB in the target / candidate cell using the new security key, to confirm the execution of a mobility procedure. The candidate gNB uses the new security key upon reception of the message. In one example, the message is a RRC message such as Handover Complete or RRCReconfigurationComplete.

[0112] Figures 6-10 are process flow diagrams that illustrate, at a high level, certain steps taken by each of various nodes, according to various embodiments of the techniques described herein. These process flow diagram focus on the messages and commands exchanged between the various nodes. It should be appreciated that these messages and commands are shown here at a relatively high level of generality, but the details of their contents may correspond to any of the example messages and commands described elsewhere in this document. Similarly, the specific context of each of the message exchanges may vary according to the various examples and scenarios described herein, particularly in and in connection with Figures 3-5, and the messages / commands may be triggered by any of the various events and triggering conditions described throughout this document.

[0113] Figure 6 illustrates the main steps performed by the first network node (source gNB) in one example of one embodiment of the invention.

[0114] Referring to Figure 6, the main steps performed by the first network node in this example are as follows.

[0115] Step 6001. The first network node transmits, to a second network node or a third network node, a message including a request for a security parameter for the UE.

[0116] Step 6002. The first network node receives, from a second network node or a third network node, a response message including a new security parameter for the UE.

[0117] Step 6003. The first network node transmits, to the UE, a mobility command including an indication of the new security parameter.

[0118] Figure 7 illustrates the main steps performed by the second network node (candidate gNB) in one example of one embodiment of the invention.

[0119] Referring to Figure 7, the main steps performed by the second network node in this example are as follows.

[0120] Step 7001. The second network node receives, from a first network node, a message including a request for a security parameter for the UE.

[0121] Step 7002. The second network node transmits, to a third network node, a message including a request for a security parameter for the UE.

[0122] Step 7003. The second network node receives, from the third network node, a response message including a new security parameter for the UE. Step 7004. The second network node transmits, to the first network node, a response message including the new security parameter for the UE.

[0123] Step 7005. The second network node receives an indication, from the UE, about an executed mobility procedure while applying the new security parameter.

[0124] Figure 8 illustrates the main steps performed by the second network node (candidate gNB) in one example of another embodiment of the invention.

[0125] Referring to Figure 8, the main steps performed by the second network node in this example are as follows.

[0126] Step 8001. The second network node receives, from a third network node, a message including a new security parameter for the UE.

[0127] Step 8002. The second network node receives an indication, from the UE, about an executed mobility procedure while applying the new security parameter.

[0128] Figure 9 illustrates the main steps performed by the third network node (AMF) in one example of one embodiment of the invention.

[0129] Referring to Figure 9, the main steps performed by the second network node in this example are as follows.

[0130] Step 9001. The third network node receives, from a first network node, a message including a request for a security parameter for the UE.

[0131] Step 9002. The third network node generates a new security parameter for the UE.

[0132] Step 9003. The third network node transmits, to a second network node, a message including a new security parameter for the UE.

[0133] Step 9004. The third network node transmits, to the first network node, a message including a new security parameter for the UE.

[0134] Figure 10 illustrates the main steps performed by the third network node (AMF) in one example of another embodiment of the invention.

[0135] Referring to Figure 10, the main steps performed by the third network node in this example are as follows.

[0136] Step 10001. The third network node receives, from a second network node, a message including a request for a security parameter for the UE.

[0137] Step 10002. The third network node generates a new security parameter for the UE.

[0138] Step 10003. The third network node transmits, to a second network node, a message including a new security parameter for the UE. More detailed embodiments of methods involving the first node include the following examples:

[0139] Al. A method at a first network node (Source gNB) configured with a first NH value (NHfirst) and a corresponding NCC value (N CCfirst as well as one or more LTM candidate configurations, where the first network node have decided to execute a mobility procedure and security parameters are prefetched for the mobility procedure. The method comprises:

[0140] • The first network node determining that an LTM cell switch procedure toward an LTM candidate cell of a second network node is needed.

[0141] • The first network node transmitting, to a second network node, a message including a request for a security parameter for the UE to perform an LTM cell switch procedure and, optionally, that new security parameters that should be applied in the second network node after the mobility should be requested from a third network node.

[0142] • The first network node receiving, from the second network node or a third network node, an indication to execute an LTM cell switch procedure and, optionally, new security parameters, e.g., only NCCsecond.

[0143] • Transmitting to the UE an indication of the new security parameters to be used when the mobility procedure is executed.

[0144] A2. The method of Al, wherein the new security parameters received from the second network node originate from a third network node.

[0145] A3. The method of A2, wherein the received new security parameters are requested by the second network node to a third network node.

[0146] A4. The method of Al, wherein the security parameters are the same as currently being used.

[0147] A5. The method of Al, wherein the first network node informs the second network node that a mobility procedure needs to be executed and is the second network node which determine that new security parameter are needed for the execution of the mobility procedure.

[0148] A6. The method of Al, wherein the first network node requests explicitly to the second network node whether a mobility procedure can be execution to one LTM candidate cell of the second network node and the second network node accepts or rejects the request based on the availability of new security parameters.

[0149] A7. The method of Al, wherein the first network node transmits the new security parameters to the UE before indicating to the UE to execute a mobility procedure. • In one example, the mobility procedure is an LTM cell switch procedure towards an LTM candidate cell of the second network node.

[0150] • In one example, the mobility procedure is conditional LTM cell switch procedure towards an LTM candidate cell of the second network node

[0151] • In one example, the mobility procedure is a conditional handover procedure

[0152] • In one example, the mobility procedure is a L3 HO procedure

[0153] A8. The method of Al, wherein the first network node transmits the new security parameters to the UE within the indication to the UE to execute a mobility procedure.

[0154] • In one example, the mobility procedure is an LTM cell switch procedure towards an LTM candidate cell of the second network node

[0155] • In one example, the mobility procedure is conditional LTM cell switch procedure towards an LTM candidate cell of the second network node

[0156] • In one example, the mobility procedure is a conditional handover procedure

[0157] • In one example, the mobility procedure is a L3 HO procedure

[0158] A9. The method of Al, wherein the first network node transmits the new security parameters to the UE according to one or the following signalling options:

[0159] • An RRC message

[0160] • A MAC Control Element (MAC CE)

[0161] • A LI signalling (e.g., DCI)

[0162] A10. The method of Al, wherein the first network node transmits the request to the second network node with one or more UE identifies information. The procedure can be a UE associated signaling, or a non-UE associated signaling.

[0163] All. A method at a first network node (Source gNB) configured with a first NH value (NHfirst) and a corresponding NCC value (N CCfirst as well as one or more LTM candidate configurations. The method comprises:

[0164] • the first network node (e.g., the source gNB) initiating early synchronization towards a given second network node (e.g., a candidate gNB) (alternatively the first network node receiving a message (e.g., from a given second network node or a core network node) indicating that early synchronization towards that given second node has been completed or is ongoing (e.g., the first network node receiving an XnAP TA information transfer message carrying at least one TA value related to a cell that is an LTM candidate cell served by the second network node). The first network node sending an indication to that given second network node that triggers the second network node the fetching of new security material (pair of NCC, NH values) before LTM execution. o In one option, if the first network node is deployed in split architecture, with a central unit (e.g., a gNB-CU) and a distributed unit (e.g. a gNB-DU) the first network node sends the indication to the second network node when the central unit receives an indication from the distributed unit that early synchronization towards the second network node is initiated

[0165] • The given second network node initiating a request towards a core network node (e.g., an AMF) to retrieve a new pair of NCC, NH values). o The request can be sent in a new NGAP procedure, or in an existing Path Switch Request comprising an additional information element indicating that only security material is requested.

[0166] Additional Embodiments

[0167] In one embodiment, the first gNB determines that a vertical key derivation is needed for an upcoming mobility procedure to an LTM candidate cell when the LTM candidate cell is a cell of different gNB than the first gNB and / or having a different security termination in the Access Stratum (e.g. different PDCP entity at the network side) than the current security termination in the Access Stratum of the first gNB. In other words, the first gNB triggers the procedure for LTM candidate cells for inter-CU LTM.

[0168] In one embodiment, the first gNB signals to the second network node that the second gNB shall request new security parameters (e.g., NH and / or NCC) from the core network (e.g., AMF) by including an indication in a request message transmitted to the second network node. In this embodiment, the request message is a Handover Request message, which also includes a request to configure the LTM candidate cell and includes the indication. Then, in response to the indication, the second network node requests the security parameters to the core network (see steps 5 and 6 in Figure 3).

[0169] In one embodiment, it is the second gNB which determines that a vertical key derivation is needed for an upcoming mobility procedure. In that case, the second gNB receives from the first network node a request to configure an LTM candidate cell of the second gNB and, upon determining that the first gNB is triggering an inter-CU LTM configuration / preparation and / or that the first gNB has a different security termination in the Access Stratum (e.g. different PDCP entity at the network side) than the security termination in the Access Stratum of the second gNB. In one embodiment, it is the second gNB which determines that a vertical key derivation is needed for an upcoming mobility procedure. In that case, the second gNB sends an enquiry to the first network node to consolidate the UE information for incoming mobility (see step 4 and 5 in Figure 4). This procedure is an existing XnAP procedure, or a new Class 1 XnAP procedure.

[0170] In one embodiment, the first gNB receives the enquiry from the second gNB and provide the UE related information, such as UE identifiers. The procedure can be a UE associated signaling, or a non- UE associated signaling.

[0171] In one embodiment, the first network node transmits a request message to a third network node, which is a core network node, such as an AMF. The request message may include a request for security parameters, in one example, the request message is a HANDOVER REQUIRED NGAP message. The third network node (AMF) determines that new security parameters are required and computes a new {NH, NCC} pair which is included in a response message transmitted to the first network node. In one example, the response message is a HANDOVER COMMAND NGAP message. In one example, the third network node (AMF) forwards the received request to a second AMF, for example when the second network node (candidate gNB) is controlled by a different AMF than the first gNB (first network node). In one embodiment, the AMF (or second AMF) transmits a message to the second network node (candidate gNB) including the new security parameters. In one example, the message is a HANDOVER REQUEST NGAP message. In this embodiment, the second network node (candidate gNB) in one example transmits a response message to the third network node (AMF or second AMF). In one example, the message is a HANDOVER REQUEST ACK NGAP message.

[0172] Network Side methods - Second Network Node

[0173] More detailed embodiments of methods involving the second node include the following examples:

[0174] Bl. A method at a second network node (Candidate gNB) configured as a candidate configuration to a UE, where the first network node has decided to execute a mobility procedure to the second network node. The method comprising:

[0175] • Receiving, from the first network node, an indication about a mobility procedure to be executed at the UE, wherein the indication about the mobility procedure may include a request to provide also new security parameters (to be used during the execution of the mobility procedure).

[0176] • The second network node being instructed from the first network or determining by itself that new security parameters are needed for a mobility procedure. • The second network node initiating a procedure towards a third network node to obtain a new set of security parameters without executing a path switch procedure.

[0177] • The second network node receiving a set of security parameters from a third network node without executing a path switch procedure.

[0178] • The second network node sending the received security parameter(s) (optionally a subset to maintain gNB key separation) to the first network node (and which the first network node will also send to the UE).

[0179] B2. The method of Bl, wherein the second network node transmits, to a third network node, a message including a request of a security parameter for the UE.

[0180] B3. The method of B22, wherein the second network node receives, from a first network node, a message including a request of a security parameter for the UE and transmits, to the first network node, a response message including a security parameter for the UE.

[0181] B4. The method of 0, wherein the request message requesting security information is a path switch request message.

[0182] B5. The method of Bl, wherein the second network node receives an indication from a first network node that a mobility procedure needs to be executed and this is the condition based on which the second network node determines that new security parameters are needed for the mobility procedure.

[0183] B6. The method of Bl, wherein the request to a third network node for new security parameters does not involve moving the PDU session of the UE from the first network node to the second network node.

[0184] B7. The method of Bl, wherein, in the request to third network node for new security parameters, one or more of the following information can be included:

[0185] • Current security parameters (e.g., NCC value, NH value)

[0186] • Identifier of the first network node

[0187] • Identifier of the second network node

[0188] • Identifier of the LTM candidate cell to which the mobility procedure is executed

[0189] • Identifier of the UE

[0190] • An explicit request for new security parameters

[0191] • Type of mobility procedure (e.g., LTM, CLTM, CHO, L3 HO) B8. The method of Bl, wherein the second network node receives a request from a first network node that a mobility procedure needs to be executed, and the new security parameters are needed for the mobility procedure. The included information can be one or more UE identifies. This procedure can be a UE associated signaling, or a non-UE associated signaling.

[0192] B9. The method of Bl, wherein the second network node transmits the new security information to the first network node. The included information can be one or more UE identifiers with a list of corresponding security information. This procedure can be a UE associated signaling, or a non-UE associated signaling.

[0193] Cl. A method at a second network node (Candidate gNB) comprising:

[0194] • The second network node sending a modified path switch request to a third network node.

[0195] • The modified path switch request having the meaning of the legacy path switch request but excluding the request for new security parameters.

[0196] C2. The method of Cl, but the modified path switch request including an indication (e.g., a security update flag, or similar) indicating to the receiver (e.g., an AMF) that the path switch request acknowledge should only contain security parameters (and not perform path switch procedures).

[0197] Network Side methods -Third Network Node

[0198] More detailed embodiments of methods involving the first third include the following examples:

[0199] DI. A method at a third network node (e.g., a core network or AMF) comprising:

[0200] • Receiving an indication from a second network node that a new mobility procedure needs to be executed and, optionally, that new security parameters are needed.

[0201] • Transmitting an indication to the second network node which may comprise new security parameters to be used during the execution of the mobility procedure.

[0202] D2. The method of DI, wherein the indication from the second network node also includes an indication to perform a path switch procedure to the second network node

[0203] D3. The method of DI, wherein the indication from the second network node does not include an indication to perform a path switch procedure to the second network node

[0204] D4. The method of DI, wherein the indication from the second network, if it includes a request for new security parameters, includes one or more of the following information:

[0205] • Current security parameters (e.g., NCC value, NH value) • Identifier of the first network node

[0206] • Identifier of the second network node

[0207] • Identifier of the LTM candidate cell to which the mobility procedure is executed

[0208] • Identifier of the UE

[0209] • An explicit request for new security parameters

[0210] • Type of mobility procedure (e.g., LTM, CLTM, CHO, L3 HO)

[0211] D5. The method of DI, wherein the third network node determines whether new security parameters are needed based on one or more or a combination of the following criteria:

[0212] • Current security parameters (e.g., NCC value, NH value)

[0213] • Identifier of the first network node

[0214] • Identifier of the second network node

[0215] • Type of mobility procedure (e.g., LTM, CLTM, CHO, L3 HO)

[0216] D6. A method for a third network node (core network node or AMF) for security handling during a mobility procedure comprising:

[0217] Receiving, from a first network node or a second network node, a message including a request of a security parameter for the UE generate a new security parameter for the UE transmit, to the second network node, a message including a new security parameter for the UE

[0218] D7. The method of D6, wherein the third network node transmits, to the first network node, a message including a new security parameter for the UE.

[0219] El. A method at a third network node (a core network node or AMF) comprising of:

[0220] • The third network node receiving a modified path switch request from the second network node.

[0221] • The third network node performing necessary steps related to a path switch procedure towards the second network node but without deriving new security parameters.

[0222] Additional Embodiments

[0223] In one embodiment, methods are executed by a first network node, a core network node, and a second network node, comprising: The first network node being the source network node for LTM and determining that the second network node is the candidate target network node for LTM towards which mobility is about to occur (or will occur)

[0224] Informing the second network node that the second network node is the selected target network node for LTM o Optionally informing the second network node that a new pair of values for NCC and NH should not be requested by the second network node to the core network node upon LTM execution o Optionally informing the second node that a path switch with no fetching of new value NCC and NH should be executed initiating a request (or sending a notification) towards the core network node to request (or indicate) the core network node to send updated security parameters towards the second network node. o This step can happen, e.g., when / upon the first network node sending the LTM cell switch command to the UE or upon sending a notification to the second network node that an LTM cell switch command has been sent (or is about to be sent) to the UE to perform LTM towards a cell of the second network node

[0225] The core network node receiving the request (or the indication) of the first network node and determining a new pair of values for NCC and NH security parameters to be sent to the second network node.

[0226] The core network node sending to the second network node the new pair of values for NCC and NH security parameters.

[0227] The second network node sending a modified path switch request which without a request a pair of new values for NCC and NH security parameters (or an implicit or explicit indication to not obtain a pair of new values for NCC and NH security parameters).

[0228] The core network node optionally sending a confirmation (or response) to the first network node.

[0229] In one embodiment, a core network node receives a request (or an indication) from the first network node the request (or the indication) comprising an identifier of a second network node (e.g., a gNB- ID) and an implicit or explicit indication / request to provide a new pair of values for NCC and NH security parameters to the second network node. The core network node, based on the request / indication, sends to the new pair of values for NCC and NH security parameters to the second network node. The core network may optionally respond to the first network node to confirm the request. In one embodiment, a core network node sends to a RAN node (e.g., a second network node, or the selected target network node for an LTM) a message (e.g., an NGAP Path Switch Request Acknowledge message) comprising a first indication related to security (e.g., a Security Prefetch Indication IE), indicating to the receiver that when the first indication is comprised in the message, a second information comprising security parameters (e.g., a Security Context IE defined in NGAP and comprising a pair of NCC and NH values), the second indication also comprised in the same message, the second information shall be ignored by the RAN node.

[0230] UE Side methods

[0231] Fl. A method at a User Equipment (UE) configured with a first NH value (NHfirst) and a corresponding NCC value (N CCfirst) as well as one or more LTM candidate configurations. The method comprising:

[0232] • Receiving, from a first network node, a first set of security parameters to be used during a mobility procedure.

[0233] • Receiving an indication from a first network node to perform a mobility procedure to the second network node and in the indication receiving a second set of security parameters to be used during the execution of the mobility procedure.

[0234] • Receiving from the second network node, after completing successfully the mobility procedure, a second set of security parameter (if those has not been received within the indication to perform a mobility procedure) to be used if a new mobility procedure needs to be executed towards a first or a fourth network node

[0235] F2. The method of Fl, where N CCsecond is signaled through an RRC message.

[0236] F3. The method of Fl, where N CCsecond is signaled through a MAC C E.

[0237] F4. The method of F3, where the MAC CE is a LTM Cell Switch MAC CE that also triggers the execution of the mobility procedure.

[0238] Generalized Example Embodiments

[0239] Following are enumerated examples of various embodiments of the presently disclosed invention. These embodiments serve as examples, and are not limiting. These embodiments may be modified and / or extended according to the various teachings herein, and in particular may be modified and / or extended to include, omit, or add additional steps so as to conform to all or part of any of the procedures illustrated in Figures 3-5, as described above. al. A method, in a user equipment, UE, for performing mobility, the method comprising: receiving, from a serving network node, one or more security parameters applicable to communication with a second network node not serving the UE; performing a mobility procedure to the second network node; and communicating with the second network node using one or more keys derived from the one or more security parameters. a2. The method of example embodiment al, wherein said receiving comprises receiving an NCC parameter from the serving network node. a3. The method of example embodiment al or a2, wherein performing the mobility procedure comprises executing an LTM cell switch procedure to the second network node. a4. The method of example embodiment a3, wherein the LTM cell switch procedure is a conditional LTM cell switch. a5. The method of any one of example embodiments al-a4, wherein the one or more security parameters are received in an LTM configuration message. a6. A user equipment, UE, adapted to carry out a method according to any one of example embodiments al-a5. a7. A user equipment, UE, comprising communication interface circuitry and processing circuitry operatively coupled to the communication interface circuitry, the processing circuitry being configured to: receive, from a serving network node, one or more security parameters applicable to communication with a second network node not serving the UE; perform a mobility procedure to the second network node; and communicate with the second network node using one or more keys derived from the one or more security parameters. a8. The UE of example embodiment a7, wherein the processing circuitry is configured to carry out a method according to any one of example embodiments a2-a5. bl. A method, in a network node configured to provide a serving cell to a user equipment, UE, the method comprising: requesting, from a second network node, security information for potential use by the UE after a mobility procedure to the second network node; receiving one or more security parameters from the second network node, in response to the request; and forwarding the one or more security parameters to the UE. b2. The method of example embodiment bl, wherein said forwarding the one or more security parameters comprises including the one or more security parameters in an LTM configuration for the UE. b3. The method of example embodiment bl or b2, further comprising, subsequent to said forwarding, sending a mobility command to the UE to trigger mobility of the UE to the second network node. b4. The method of example embodiment b3, wherein the mobility command is an LTM cell switch command. b5. The method of example embodiment b4, wherein the one or more security parameters are forwarded to the UE in the LTM cell switch command. b6. A method, in a network node, the method comprising: receiving, from a network node configured to provide a serving cell to a user equipment, UE, a request for security information for potential use by the UE after a mobility procedure to the second network node; and sending one or more security parameters to the network node configured to provide the serving cell to the UE, in response to the request, for forwarding to the UE. b7. The method of example embodiment b6, further comprising: requesting a third network node to provide one or more security parameters for the UE; and receiving the one or more security parameters from the third network node, prior to sending the one or more security parameters to the network node configured to provide the serving cell to the UE. b8. The method of example embodiment b7, wherein the method comprises receiving an NH parameter and an NCC parameter from the third network node, but sending the NCC parameter to the network node configured to provide the serving cell to the UE and not sending the NH parameter. blO. The method of any of example embodiments b6-bl0, wherein the method further comprises: preparing a path switch towards the third network. bll. A method, in a network node, the method comprising: receiving, from another network node configured to provide a serving cell to a user equipment, UE, an indication that the UE may perform a mobility procedure to the network node; and requesting, from a third network node, one or more security parameters for the UE. bl2. The method of example embodiment bll, further comprising: sending the one or more security parameters to the other network node. bl3. The method of example embodiment bl2, wherein said sending is in response to receiving a request for the one or more security parameters from the network node configured to provide the serving cell to the user equipment. bl4. The method of example embodiment bl2 or bl3, wherein the method comprises receiving an NH parameter and an NCC parameter from the third network node, but sending the NCC parameter to the network node configured to provide the serving cell to the UE and not sending the NH parameter. bl5. A network node adapted to carry out a method according to any one of example embodiments bl-bl4. bl6. A network node, comprising communication interface circuitry and processing circuitry operatively coupled to the communication interface circuitry, the processing circuitry being configured to: requesting, from a second network node, security information for potential use by the UE after a mobility procedure to the second network node; receiving one or more security parameters from the second network node, in response to the request; and forwarding the one or more security parameters to the UE. bl7. The network node of example embodiment bl6, wherein the processing circuitry is further configured to carry out a method according to any one of example embodiments b2-b5. bl8. A network node, comprising communication interface circuitry and processing circuitry operatively coupled to the communication interface circuitry, the processing circuitry being configured to: receive, from a network node configured to provide a serving cell to a user equipment, UE, a request for security information for potential use by the UE after a mobility procedure to the second network node; and send one or more security parameters to the network node configured to provide the serving cell to the UE, in response to the request, for forwarding to the UE. bl9. The network node of example embodiment bl8, wherein the processing circuitry is further configured to carry out a method according to any one of example embodiments b7-bl0. b20. A network node, comprising communication interface circuitry and processing circuitry operatively coupled to the communication interface circuitry, the processing circuitry being configured to: receive, from another network node configured to provide a serving cell to a user equipment, UE, an indication that the UE may perform a mobility procedure to the network node; and request, from a third network node, one or more security parameters for the UE. b21. The network node of example embodiment b20, wherein the processing circuitry is further configured to carry out a method according to any one of example embodiments bl2-bl4.

[0240] Although various embodiments are described above in terms of methods, techniques, and / or procedures, the person of ordinary skill will readily comprehend that such methods, techniques, and / or procedures can be embodied by various combinations of hardware and software in various systems, communication devices, computing devices, control devices, apparatuses, non-transitory computer-readable media, computer program products, etc. Thus, embodiments of the presently disclosed invention include computer program products and computer-readable media, including non-transitory computer-readable media, comprising program instructions configured for execution by processing circuitry in a UE or network node, as applicable, such that execution of the program instructions causes the UE or network node to carry out one of the methods described herein.

[0241] Figure 11 shows an example of a communication system 1100 in accordance with some embodiments. In this example, communication system 1100 includes telecommunication network 1102 that includes access network 1104 (e.g., RAN) and a core network 1106, which includes one or more core network nodes 1108. Access network 1104 includes one or more access network nodes, such as network nodes lllOa-b (one or more of which may be generally referred to as network nodes 1110), or any other similar 3GPP access node or non-3GPP access point. Network nodes 1110 facilitate direct or indirect connection of UEs, such as by connecting UEs 1112a-d (one or more of which may be generally referred to as UEs 1112) to core network 1106 over one or more wireless connections.

[0242] Example wireless communications over a wireless connection include transmitting and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, communication system 1100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals whether via wired or wireless connections. Communication system 1100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0243] UEs 1112 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and / or operable to communicate wirelessly with network nodes 1110 and other communication devices. Similarly, network nodes 1110 are arranged, capable, configured, and / or operable to communicate directly or indirectly with UEs 1112 and / or with other network nodes or equipment in telecommunication network 1102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in telecommunication network 802.

[0244] In the depicted example, core network 1106 connects network nodes 1110 to one or more hosts, such as host 1116. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. Core network 1106 includes one or more core network nodes (e.g., 1108) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of core network node 1108. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and / or a User Plane Function (UPF).

[0245] Host 1116 may be under the ownership or control of a service provider other than an operator or provider of access network 1104 and / or telecommunication network 1102, and may be operated by the service provider or on behalf of the service provider. Host 1116 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio / video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

[0246] As a whole, communication system 1100 of Figure 11 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.

[0247] In some examples, telecommunication network 1102 is a cellular network that implements 3GPP standardized features. Accordingly, telecommunication network 1102 may support network slicing to provide different logical networks to different devices that are connected to telecommunication network 802. For example, telecommunication network 1102 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and / or Massive Machine Type Communication (mMTC) / Massive loT services to yet further UEs.

[0248] In some examples, UEs 1112 are configured to transmit and / or receive information without direct human interaction. For instance, a UE may be designed to transmit information to access network 1104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from access network 1104. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e., being configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN- DC).

[0249] In the example, hub 1114 communicates with access network 1104 to facilitate indirect communication between one or more UEs (e.g., UE 1112c and / or 1112d) and network nodes (e.g., network node 1110b). In some examples, hub 1114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, hub 1114 may be a broadband router enabling access to core network 1106 for the UEs. As another example, hub 1114 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1110, or by executable code, script, process, or other instructions in hub 1114. As another example, hub 1114 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, hub 1114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, hub 1114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which hub 1114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, hub 1114 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

[0250] Hub 1114 may have a constant / persistent or intermittent connection to network node 1110b. Hub 1114 may also allow for a different communication scheme and / or schedule between hub 1114 and UEs (e.g., UE 1112c and / or 1112d), and between hub 1114 and core network 1106. In other examples, hub 1114 is connected to core network 1106 and / or one or more UEs via a wired connection. Moreover, hub 1114 may be configured to connect to an M2M service provider over access network 1104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with network nodes 1110 while still connected via hub 1114 via a wired or wireless connection. In some embodiments, hub 1114 may be a dedicated hub - that is, a hub whose primary function is to route communications to / from the UEs from / to network node 1110b. In other embodiments, hub 1114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1110b, but which is additionally capable of operating as a communication start and / or end point for certain data channels. Figure 12 shows a UE 1200 in accordance with some embodiments. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by 3GPP, including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0251] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to- vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0252] UE 1200 includes processing circuitry 1202 that is operatively coupled via bus 1204 to input / output interface 1206, power source 1208, memory 1210, communication interface 1212, and possibly other components not explicitly shown. Certain UEs may utilize all or a subset of the components shown in Figure 12. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0253] Processing circuitry 1202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine- readable computer programs in memory 1210. Processing circuitry 1202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, processing circuitry 1202 may include multiple central processing units (CPUs). In the example, input / output interface 1206 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and / or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into UE 1200. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

[0254] In some embodiments, power source 1208 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. Power source 1208 may further include power circuitry for delivering power from power source 1208 itself, and / or an external power source, to the various parts of UE 1200 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging power source 1208. Power circuitry may perform any formatting, converting, or other modification to the power from power source 1208 to make the power suitable for the respective components of UE 1200 to which power is supplied.

[0255] Memory 1210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable readonly memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, memory 1210 includes one or more application programs 1214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1216. Memory 1210 may store, for use by UE 1200, any of a variety of various operating systems or combinations of operating systems.

[0256] Memory 1210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as 'SIM card.' Memory 1210 may allow UE 1200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in memory 1210, which may be or comprise a device-readable storage medium.

[0257] Processing circuitry 1202 may be configured to communicate with an access network or other network using communication interface 1212. Communication interface 1212 may comprise one or more communication subsystems and may include or be communicatively coupled to antenna 1222. Communication interface 1212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include transmitter 1218 and / or receiver 1220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, transmitter 1218 and receiver 1220 may be coupled to one or more antennas (e.g., 1222) and may share circuit components, software or firmware, or alternatively be implemented separately.

[0258] In the illustrated embodiment, communication functions of communication interface 1212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), Q.UIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0259] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1212, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 16 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., an alert is sent when moisture is detected), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0260] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0261] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to UE 1200 shown in Figure 12.

[0262] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements, and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation. In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone's speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first and / or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0263] Figure 13 shows a network node 1300 in accordance with some embodiments. Examples of network nodes include, but are not limited to, access points (e.g., radio access points) and base stations (e.g., radio base stations, Node Bs, eNBs, and gNBs).

[0264] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and / or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0265] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and / or Minimization of Drive Tests (MDTs).

[0266] Network node 1300 includes processing circuitry 1302, memory 1304, communication interface 1306, and power source 1308. Network node 1300 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which network node 1300 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, network node 1300 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1304 for different RATs) and some components may be reused (e.g., a same antenna 1310 may be shared by different RATs). Network node 1300 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1300, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1300.

[0267] Processing circuitry 1302 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and / or encoded logic operable to provide, either alone or in conjunction with other network node 1300 components, such as memory 1304, to provide network node 1300 functionality.

[0268] In some embodiments, processing circuitry 1302 includes a system on a chip (SOC). In some embodiments, processing circuitry 1302 includes one or more of radio frequency (RF) transceiver circuitry 1312 and baseband processing circuitry 1314. In some embodiments, RF transceiver circuitry 1312 and baseband processing circuitry 1314 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1312 and baseband processing circuitry 1314 may be on the same chip or set of chips, boards, or units.

[0269] Memory 1304 may comprise any form of volatile or non-volatile computer-readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and / or any other volatile or non-volatile, non- transitory device-readable and / or computer-executable memory devices that store information, data, and / or instructions that may be used by processing circuitry 1302. Memory 1304 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and / or other instructions (collectively denoted computer program product 1304a) capable of being executed by processing circuitry 1302 and utilized by network node 1300. Memory 1304 may be used to store any calculations made by processing circuitry 1302 and / or any data received via communication interface 1306. In some embodiments, processing circuitry 1302 and memory 1304 is integrated.

[0270] Communication interface 1306 is used in wired or wireless communication of signaling and / or data between a network node, access network, and / or UE. As illustrated, communication interface 1306 comprises port(s) / terminal(s) 1316 to send and receive data, for example to and from a network over a wired connection. Communication interface 1306 also includes radio front-end circuitry 1318 that may be coupled to, or in certain embodiments a part of, antenna 1310. Radio front-end circuitry 1318 comprises filters 1320 and amplifiers 1322. Radio front-end circuitry 1318 may be connected to antenna 1310 and processing circuitry 1302. The radio front-end circuitry may be configured to condition signals communicated between antenna 1310 and processing circuitry 1302. Radio frontend circuitry 1318 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. Radio front-end circuitry 1318 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1320 and / or amplifiers 1322. The radio signal may then be transmitted via antenna 1310. Similarly, when receiving data, antenna 1310 may collect radio signals which are then converted into digital data by radio front-end circuitry 1318. The digital data may be passed to processing circuitry 1302. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0271] In certain alternative embodiments, network node 1300 does not include separate radio front-end circuitry 1318, instead, processing circuitry 1302 includes radio front-end circuitry and is connected to antenna 1310. Similarly, in some embodiments, all or some of RF transceiver circuitry 1312 is part of communication interface 1306. In still other embodiments, communication interface 1306 includes one or more ports or terminals 1316, radio front-end circuitry 1318, and RF transceiver circuitry 1312, as part of a radio unit (not shown), and communication interface 1306 communicates with the baseband processing circuitry 1314, which is part of a digital unit (not shown).

[0272] Antenna 1310 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. Antenna 1310 may be coupled to radio front-end circuitry 1318 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, antenna 1310 is separate from network node 1300 and connectable to network node 1300 through an interface or port. Antenna 1310, communication interface 1306, and / or processing circuitry 1302 may be configured to perform any receiving operations and / or certain obtaining operations described herein as being performed by the network node. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, antenna 1310, communication interface 1306, and / or processing circuitry 1302 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0273] Power source 1308 provides power to the various components of network node 1300 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). Power source 1308 may further comprise, or be coupled to, power management circuitry to supply the components of network node 1300 with power for performing the functionality described herein. For example, network node 1300 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of power source 1308. As a further example, power source 1308 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

[0274] Embodiments of network node 1300 may include additional components beyond those shown in Figure 13 for providing certain aspects of the network node's functionality, including any of the functionality described herein and / or any functionality necessary to support the subject matter described herein. For example, network node 1300 may include user interface equipment to allow input of information into network node 1300 and to allow output of information from network node 1300. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for network node 1300.

[0275] Figure 14 is a block diagram of a host 1400, which may be an embodiment of host 1116 of Figure 11, in accordance with various aspects described herein. Host 1400 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud- implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. Host 1400 may provide one or more services to one or more UEs.

[0276] Host 1400 includes processing circuitry 1402 that is operatively coupled via a bus 1404 to an input / output interface 1406, a network interface 1408, a power source 1410, and a memory 1412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 12 and 13, such that the descriptions thereof are generally applicable to the corresponding components of host 1400.

[0277] Memory 1412 may include one or more computer programs including one or more host application programs 1414 and data 1416, which may include user data, e.g., data generated by a UE for host 1400 or data generated by host 1400 for a UE. Embodiments of host 1400 may utilize only a subset or all of the components shown. Host application programs 1414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). Host application programs 1414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, host 1400 may select and / or indicate a different host for over-the-top services for a UE. Host application programs 1414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real- Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0278] Figure 15 is a block diagram illustrating a virtualization environment 1500 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

[0279] Applications 1502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment 1400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0280] Hardware 1504 includes processing circuitry, memory that stores software and / or instructions (collectively denoted computer program product 1504a) executable by hardware processing circuitry, and / or other hardware devices as described herein, such as a network interface, input / output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1508a-b (one or more of which may be generally referred to as VMs 1508), and / or perform any of the functions, features and / or benefits described in relation with some embodiments described herein. The virtualization layer 1506 may present a virtual operating platform that appears like networking hardware to VMs 1508.

[0281] VMs 1508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1506. Different embodiments of the instance of a virtual appliance 1502 may be implemented on one or more of VMs 1508, and the implementations may differ. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

[0282] In the context of NFV, each VM 1508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of VMs 1508, and that part of hardware 1504 that executes that VM, be it hardware dedicated to that VM and / or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1508 on top of hardware 1504 and corresponds to application 1502.

[0283] Hardware 1504 may be implemented in a standalone network node with generic or specific components. Hardware 1504 may implement some functions via virtualization. Alternatively, hardware 1504 may be part of a larger cluster of hardware (e.g., such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1510, which, among others, oversees lifecycle management of applications 1502. In some embodiments, hardware 1504 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of control system 1512 which may alternatively be used for communication between hardware nodes and radio units.

[0284] Figure 16 shows a communication diagram of a host 1602 communicating via a network node 1604 with a UE 1606 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1112a of Figure 11 and / or UE 1200 of Figure 12), network node (such as network node 1110a of Figure 11 and / or network node 1300 of Figure 13), and host (such as host 1116 of Figure 11 and / or host 1400 of Figure 14) discussed in the preceding paragraphs will now be described with reference to Figure 16.

[0285] Like host 1400, embodiments of host 1602 include hardware, such as a communication interface, processing circuitry, and memory. Host 1602 also includes software, which is stored in or accessible by host 1602 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as UE 1606 connecting via an over-the- top (OTT) connection 1650 extending between UE 1606 and host 1602. In providing the service to the remote user, a host application may provide user data which is transmitted using OTT connection 1650.

[0286] Network node 1604 includes hardware enabling it to communicate with host 1602 and UE 1606. Connection 1660 may be direct or pass through a core network (like core network 1106 of Figure 11) and / or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

[0287] UE 1606 includes hardware and software, which is stored in or accessible by UE 1606 and executable by the UE's processing circuitry. The software includes a client application, such as a web browser or operator-specific "app" that may be operable to provide a service to a human or non-human user via UE 1606 with the support of host 1602. In host 1602, an executing host application may communicate with the executing client application via OTT connection 1650 terminating at UE 1606 and host 1602. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. OTT connection 1650 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through OTT connection 1650. OTT connection 1650 may extend via a connection 1660 between host 1602 and network node 1604 and via wireless connection 1670 between network node 1604 and UE 1606 to provide the connection between host 1602 and UE 1606. Connection 1660 and wireless connection 1670, over which OTT connection 1650 may be provided, have been drawn abstractly to illustrate the communication between host 1602 and UE 1606 via network node 1604, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

[0288] As an example of transmitting data via OTT connection 1650, in step 1608, host 1602 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with UE 1606. In other embodiments, the user data is associated with a UE 1606 that shares data with host 1602 without explicit human interaction. In step 1610, host 1602 initiates a transmission carrying the user data towards UE 1606. Host 1602 may initiate the transmission responsive to a request transmitted by UE 1606. The request may be caused by human interaction with UE 1606 or by operation of the client application executing on UE 1606. The transmission may pass via network node 1604, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 1612, network node 1604 transmits to UE 1606 the user data that was carried in the transmission that host 1602 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 1614, UE 1606 receives the user data carried in the transmission, which may be performed by a client application executed on UE 1606 associated with the host application executed by host 1602.

[0289] In some examples, UE 1606 executes a client application which provides user data to host 1602. The user data may be provided in reaction or response to the data received from host 1602. Accordingly, in step 1616, UE 1606 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input / output interface of UE 1606. Regardless of the specific manner in which the user data was provided, UE 1606 initiates, in step 1618, transmission of the user data towards host 1602 via network node 1604. In step 1620, in accordance with the teachings of the embodiments described throughout this disclosure, network node 1604 receives user data from UE 1606 and initiates transmission of the received user data towards host 1602. In step 1622, host 1602 receives the user data carried in the transmission initiated by UE 1606.

[0290] One or more of the various embodiments improve the performance of OTT services provided to UE 1606 using OTT connection 1650, in which wireless connection 1670 forms the last segment. More precisely, embodiments can reduce and / or prevent undesired recovery actions by UEs. For example, due to the conditions for considering an LTM cell switch procedure successful (causing UE to stop a supervision timer), undesired recovery actions due to supervision timer expiration are prevented at the UE. This is especially an issue in the scenarios where LTM cell switch needs to be performed without a RA procedure (i.e., "RACH-less"). Preventing undesired recovery actions makes LTM RACH- less solutions more efficient, which reduces the delay to access an LTM candidate cell. Embodiments can facilitate predictable UE behavior in LTM execution failures and can reduce and / or eliminate ambiguity for UE actions in the event of LTM failures that are concurrent other failures such as radio link failure (RLF). By improving operation of UEs and RANs in this manner, embodiments increase the value of OTT services delivered to / from the UE via the RAN, to both end users and service providers.

[0291] In an example scenario, factory status information may be collected and analyzed by host 1602. As another example, host 1602 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, host 1602 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, host 1602 may store surveillance video uploaded by a UE. As another example, host 1602 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, host 1602 may be used for energy pricing, remote control of nontime critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and / or transmitting data.

[0292] In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring OTT connection 1650 between host 1602 and UE 1606, in response to variations in the measurement results. The measurement procedure and / or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of host 1602 and / or UE 1606. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which OTT connection 1650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of OTT connection 1650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of network node 1604. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by host 1602. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or 'dummy' messages, using OTT connection 1650 while monitoring propagation times, errors, etc.

[0293] The foregoing merely illustrates the principles of the disclosure. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in view of the teachings herein. It will thus be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and procedures that, although not explicitly shown or described herein, embody the principles of the disclosure and can be thus within the spirit and scope of the disclosure. Various embodiments can be used together with one another, as well as interchangeably therewith, as should be understood by those having ordinary skill in the art.

[0294] The term unit, as used herein, can have conventional meaning in the field of electronics, electrical devices and / or electronic devices and can include, for example, electrical and / or electronic circuitry, devices, modules, processors, memories, logic solid state and / or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and / or displaying functions, and so on, as such as those that are described herein.

[0295] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according to one or more embodiments of the present disclosure.

[0296] As described herein, device and / or apparatus can be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device or apparatus, instead of being hardware implemented, be implemented as a software module such as a computer program or a computer program product comprising executable software code portions for execution or being run on a processor. Furthermore, functionality of a device or apparatus can be implemented by any combination of hardware and software. A device or apparatus can also be regarded as an assembly of multiple devices and / or apparatuses, whether functionally in cooperation with or independently of each other. Moreover, devices and apparatuses can be implemented in a distributed fashion throughout a system, so long as the functionality of the device or apparatus is preserved. Such and similar principles are considered as known to a skilled person.

[0297] Furthermore, functions described herein as being performed by a wireless device or a network node may be distributed over a plurality of wireless devices and / or network nodes. In other words, it is contemplated that the functions of the network node and wireless device described herein are not limited to performance by a single physical device and, in fact, can be distributed among several physical devices.

[0298] In addition, certain terms used in the present disclosure, including the specification, drawings and embodiments thereof, can be used synonymously in certain instances, including, but not limited to, e.g., data and information. It should be understood that, while these words and / or other words that can be synonymous to one another, can be used synonymously herein, that there can be instances when such words can be intended to not be used synonymously. Further, to the extent that the prior art knowledge has not been explicitly incorporated by reference herein above, it is explicitly incorporated herein in its entirety. All publications referenced are incorporated herein by reference in their entireties.

[0299] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms used herein should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0300] In addition, certain terms used in the present disclosure, including the specification and drawings, can be used synonymously in certain instances (e.g., "data" and "information"). It should be understood, that although these terms (and / or other terms that can be synonymous to one another) can be used synonymously herein, there can be instances when such words can be intended to not be used synonymously.

[0301] Technical Specification Impact

[0302] In one example of implementation, the PATH SWITCH REQUEST message is extended with an IE (e.g., Security Prefetch Indicator) to indicate that, if present, the corresponding PATH SWITCH REQUEST ACKNOWLEDGE will not contain updated NCC, NH parameters. In the example implementations shown below, material added to existing 3GPP documentation is shown in bold.

[0303] - begin excerpts of proposed implementation in 3GPP documentation -

[0304] 9.2.3.8 PATH SWITCH REQUEST This message is sent by the NG-RAN node to inform the AMF of the new serving NG-RAN node and to transfer some NG-U DL tunnel termination point(s) to the SMF via the AMF for one or multiple PDU session resources.

[0305] Direction: NG-RAN node

[0306] 9.2.3.9 PATH SWITCH REQUEST ACKNOWLEDGE

[0307] This message is sent by the AMF to inform the NG-RAN node that the path switch has been successfully completed in the 5GC.

[0308] Direction: node.

[0309] end excerpts of proposed implementation in 3GPP documentation In accordance to the above extension of the PATH SWITCH REQUEST ACKNOWLEDGE message, a nonliming example of how the procedure text related to the Path Switch NGAP procedure can be modified in 3GPP documentation of the procedure is the following, in which new matter added to the 3GPP documentation is shown in bold:

[0310] "Upon reception of the PATH SWITCH REQUEST ACKNOWLEDGE message, if the Security Prefetch Indicator IE is not included in the PATH SWITCH REQUEST ACKNOWLEDGE message, the NG-RAN node shall store the received Security Context IE in the UE context and the NG-RAN node shall use it as specified in TS 33.501

[0013] ."

Claims

CLAIMS1. A method, in a user equipment, UE (1001), for performing mobility, the method comprising: receiving, from a serving network node (1002), one or more security parameters applicable to communication with a second network node (1003) not serving the UE; performing a mobility procedure to the second network node (1003); and communicating with the second network node (1003) using one or more keys derived from the one or more security parameters.

2. The method of claim 1, wherein said receiving comprises receiving an NCC parameter from the serving network node (1002).

3. The method of claim 1 or 2, wherein performing the mobility procedure comprises executing an LTM cell switch procedure to the second network node (1003).

4. The method of claim 3, wherein the LTM cell switch procedure is a conditional LTM cell switch.

5. The method of any one of claims 1-4, wherein the one or more security parameters are received in an LTM configuration message.

6. The method of any one of claims 1-4, wherein the one or more security parameters are received in an LTM execution message.

7. A user equipment, UE (1200), adapted to carry out a method according to any one of claims 1-7.

8. A user equipment, UE (1200), comprising communication interface circuitry (1212) and processing circuitry (1202) operatively coupled to the communication interface circuitry (1212), the processing circuitry (1202) being configured to: receive, from a serving network node, one or more security parameters applicable to communication with a second network node not serving the UE; perform a mobility procedure to the second network node; and communicate with the second network node using one or more keys derived from the one or more security parameters.

9. The UE (1200) of claim 8, wherein the one or more security parameters comprise an NCC parameter.

10. The UE (1200) of claim 8 or 9 wherein the mobility procedure comprises an LTM cell switch procedure to the second network node.

11. The UE (1200) of claim 10, wherein the LTM cell switch procedure is a conditional LTM cell switch.

12. The UE (1200) of any one of claims 8-11, wherein the processing circuitry (1202) is configured to receive the one or more security parameters in an LTM configuration message.

13. The UE (1200) of any one of claims 8-11, wherein the processing circuitry (1202) is configured to receive the one or more security parameters in an LTM execution message.

14. A method, in a network node configured to provide a serving cell to a user equipment, UE, the method comprising: requesting (6001), from a second network node, security information for potential use by the UE after a mobility procedure to the second network node; receiving (6002) one or more security parameters from the second network node, in response to the request; and forwarding (6003) the one or more security parameters to the UE.

15. The method of claim 14, wherein said forwarding (6003) the one or more security parameters comprises including the one or more security parameters in an LTM configuration for the UE.

16. The method of claim 14 or 15, further comprising, subsequent to said forwarding, sending a mobility command to the UE to trigger mobility of the UE to the second network node.

17. The method of claim 16, wherein the mobility command is an LTM cell switch command.

18. The method of claim 17, wherein the one or more security parameters are forwarded to the UE in the LTM cell switch command.

19. A network node (1300) adapted to carry out a method according to any one of claims 14-18.

20. A network node (1300), comprising communication interface circuitry (1306) and processing circuitry (1302) operatively coupled to the communication interface circuitry (1306), the processing circuitry (1302) being configured to: request, from a second network node, security information for potential use by a user equipment, UE, served by the network node after a mobility procedure to the second network node; receive one or more security parameters from the second network node, in response to the request; and forward the one or more security parameters to the UE.

21. The network node (1300) of claim 20, wherein the processing circuitry (1302) is further configured to forward the one or more security parameters by including the one or more security parameters in an LTM configuration for the UE.

22. The network node (1300) of claim 20 or 21, wherein the processing circuit (1302) is configured to, prior to said forwarding, send a mobility command to the UE to trigger mobility of the UE to the second network node.

23. The network node (1300) of claim 22, wherein the mobility command is an LTM cell switch command.

24. The network node (1300) of claim 20, wherein the processing circuitry (1302) is configured to forward the one or more security parameters to the UE in the LTM cell switch command.

25. A method, in a network node, the method comprising: receiving (7001), from a serving network node configured to provide a serving cell to a user equipment, UE, a request for security information for potential use by the UE after a mobility procedure to a network node other than the serving network node; and sending (7004) one or more security parameters to the serving network node, in response to the request, for forwarding to the UE.

26. The method of claim 25, further comprising: requesting (7002) a third network node to provide one or more security parameters for the UE; and receiving (7003) the one or more security parameters from the third network node, prior to sending the one or more security parameters to the serving network node.

27. The method of claim 25, wherein the method comprises receiving an NH parameter and an NCC parameter from the third network node, but sending the NCC parameter to the serving network node and not sending the NH parameter.

28. The method of any of claims 25-27, wherein the method further comprises: preparing a path switch towards the third network node.

29. A network node adapted to carry out a method according to any one of claims 25-28.

30. A network node, comprising communication interface circuitry and processing circuitry operatively coupled to the communication interface circuitry, the processing circuitry being configured to: receive, from a serving network node configured to provide a serving cell to a user equipment, UE, a request for security information for potential use by the UE after a mobility procedure to a network node other than the serving network node; and send one or more security parameters to the serving network node, in response to the request, for forwarding to the UE.

31. The network node of claim 30, wherein the processing circuitry is further configured to: request a third network node to provide one or more security parameters for the UE; and receive the one or more security parameters from the third network node, prior to sending the one or more security parameters to the serving network node.

32. The network node of claim 30, wherein the processing circuitry is configured to receive an NH parameter and an NCC parameter from the third network node, but is further configured to send the NCC parameter to the serving network node and not send the NH parameter.

33. The network node of any of claims 30-32 wherein the processing circuitry is further configured to prepare a path switch towards the third network node.

34. A method, in a network node, the method comprising: receiving, from a serving network node configured to provide a serving cell to a user equipment, UE, an indication that the UE may perform a mobility procedure to the network node; and requesting, from a third network node, one or more security parameters for the UE.

35. The method of claim 34, further comprising: sending the one or more security parameters to the serving network node.

36. The method of claim 35, wherein said sending is in response to receiving a request for the one or more security parameters from the serving network node.

37. The method of claim 35 or 36, wherein the method comprises receiving an NH parameter and an NCC parameter from the third network node, but sending the NCC parameter to the serving network node and not sending the NH parameter.

38. A network node (1300) adapted to carry out a method according to any one of claims 34-37.

39. A network node (1300), comprising communication interface circuitry (1306) and processing circuitry (1302) operatively coupled to the communication interface circuitry (1306), the processing circuitry (1302) being configured to: receive, from a serving network node configured to provide a serving cell to a user equipment, UE, an indication that the UE may perform a mobility procedure to the network node; and request, from a third network node, one or more security parameters for the UE.

40. The network node (1300) of claim 39, wherein the processing circuitry (1302) is further configured to send the one or more security parameters to the serving network node.

41. The network node (1300) of claim 40, wherein the processing circuitry (1302) is configured to send the one or more security parameters to the serving network node in response to receiving a request for the one or more security parameters from the serving network node.

42. The network node (1300) of claim 40 or 41, wherein the processing circuitry (1302) is configured to receive an NH parameter and an NCC parameter from the third network node but send the NCC parameter to the serving network node and not send the NH parameter.

Images