WO2025156504A1

WO2025156504A1 - A method for security key update in layer-1/layer-2 triggered mobility

Info

Publication number: WO2025156504A1
Application number: PCT/CN2024/092259
Authority: WO
Inventors: Mengjie ZHANG; Eswar Kalyan Vutukuri; Jing Liu; He Huang; Fei DONG
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2024-05-10
Filing date: 2024-05-10
Publication date: 2025-07-31
Anticipated expiration: 2026-11-10

Abstract

This disclosure is directed generally to wireless communications technologies and more specifically to security provisioning in Layer-1/Layer-2 Triggered Mobility (LTM). A security information delivery to user equipment via media resource control (MAC) control element (MAC CE) is disclosed. The MAC CE may be also used as LTM cell switch command. The MAC CE may be integrity protected by an integrity protection token that are generated by the network side via various interactions between the network side nodes. The network side nodes further interact to exchange various security information needed for the key generation by the network nodes and the UE.

Description

A METHOD FOR SECURITY KEY UPDATE IN LAYER-1/LAYER-2 TRIGGERED MOBILITY

TECHNICAL FIELD

This disclosure is directed generally to wireless communications technologies and more specifically to security provisioning in Layer-1/Layer-2 Triggered Mobility (LTM) ,

BACKGROUND

In a wireless network, a wireless terminal device in communication with a serving cell may need to switch cells during mobility. It is desirable for such cell switches to be performed with reduced mobility latency, data interruption time, communication overhead and/or energy consumption while maintain communication security in various network architectures and topologies.

SUMMARY

This disclosure is directed generally to wireless communications technologies and more specifically to security provisioning in Layer-1/Layer-2 Triggered Mobility (LTM) . A security information delivery to user equipment via media resource control (MAC) control element (MAC CE) is disclosed. The MAC CE may be also used as LTM cell switch command. The MAC CE may be integrity protected by an integrity protection token that are generated by the network side via various interactions between the network side nodes. The network side nodes further interact to exchange various security information needed for the key generation by the network nodes and the UE.

In some example implementations, a method performed by a wireless terminal in communication with a base station in a wireless communication network is disclosed. The method may include receiving layer-1/layer-2 triggered mobility (LTM) cell switch command for switching to a target cell; retrieving a set of security information items; generating a security key for communication with the target cell based on at least the set of security information items and cell information of the target cell.

In the example implementations above, the set of security information items are retrieved from the LTM cell switch command, wherein the LTM cell switch command is carried via a media access control (MAC) control element (MAC CE) received from the base station.

In any one of the example implementations above, the set of security information items comprise a next hop counter (NCC) for the target cell and wherein generating the security key comprises: generating the security key based on a horizontal key derivation when the NCC matches a current NCC corresponding to a current active security key associated with the base station; or generating the security key based on a vertical key derivation when the NCC differs from the current NCC.

In any one of the example implementations above, the MAC CE further comprises an expected token for integrity protection of the MAC CE and wherein the method further comprises performing an integrity verification of the MAC CE according to the expected token.

In any one of the example implementations above, performing the integrity verification of the MAC CE comprises: generating a calculated token based on the security key; comparing the calculated token to the expected token; and determining that the integrity verification of the MAC CE is successful when the calculated token matches the expected token; or determining that the integrity verification of the MAC CE fails when the calculated token differs from the expected token.

In any one of the example implementations above, when the integrity verification fails, the method further comprises at least one of: switching to a radio resource control (RRC) idle mode of the wireless terminal and performing an NAS recovery; initiating an RRC re-establishment procedure; or discarding the MAC CE as invalid.

In any one of the example implementations above, the integrity verification of the MAC CE is performed at a MAC layer of the wireless terminal.

In any one of the example implementations above, the integrity verification of the MAC CE is performed at a higher layer above a MAC layer of the wireless terminal.

In any one of the example implementations above, the higher network layer where the integrity verification of the MAC CE is performed comprises a packet data convergence protocol (PDCP) layer.

In any one of the example implementations above, the method may further include indicating by the MAC layer to the higher layer at least one of (1) that an LTM cell switch procedure is triggered; (2) an LTM candidate configuration ID for the target cell; or (3) the set of security information items.

In any one of the example implementations above, the calculated token is generated using the security key and based on at least one of: a physical cell identifier (PCI) of a last serving cell of the wireless terminal; a C-RNTI allocated by the last serving cell; or a cell ID of the target cell.

In any one of the example implementations above, the calculated token is generated using a integrity algorithm with input parameters including at least one of BEARER bits, DIRECTION bit, COUNT bits, or with MESSAGE bits set to a bit length of the MAC CE.

In any one of the example implementations above, the cell ID of the target cell comprises at least one of a cell global ID (CGI) , a PCI, a cell identity, or a candidate configuration index of the target cell.

In any one of the example implementations above, the expected token is generated by a distributed unit (DU) or a central unit (CU) of the base station.

In any one of the example implementations above, the expected token is generated by the DU based on the set of security information items transferred from the CU to the DU.

In any one of the example implementations above, the expected token is generated by the CU and sent to the DU.

In any one of the example implementations above, the expected token is received by the wireless terminal from the DU.

In any one of the example implementations above, a set of expected tokens are generated for one or more configured candidate cells for LTM, and wherein the target cell is selected among the one or more configured candidate cells for LTM and the expected token of the target cell among the set of expected tokens is received by the wireless terminal from the DU.

In any one of the example implementations above, the MAC CE further comprises at least one of: a first indicator for key set change to indicate whether the security key is derived from a base key provided by a core network of the wireless communication network; a second indicator of a ciphering algorithm used for all bearers using a master key; a third indicator of a ciphering algorithm used for all bearers using a secondary key; a fourth indicator of an integrity protection algorithm used for all bearers using the master key; or a fifth indicator of an integrity protection algorithm used for all bearers using the secondary key.

In any one of the example implementations above, the MAC CE further comprises an index for identifying a ciphering algorithm or an integrity protection algorithm to apply to the target cell from a list of ciphering algorithms or a list of integrity protection algorithms preconfigured to the wireless terminal via an RRC message.

In some other example implementations, a method performed by a base station in communication with a wireless terminal in a wireless communication network is disclosed. The method may include sending a request message to request a set of security information items from a core network of the wireless communication network during a layer-1/layer-2 triggered mobility (LTM) preparation phase; and receiving a response message including the set of security information items from the core network for an LTM configuration.

In the example implementations above, the request message includes at least one of: an indicator to request a list of pairs of next hop (NH) parameters and NCCs; an indicator to request a list of pairs of NHs and NCCs provided per candidate network node for LTM; one or more LTM candidate cell IDs; or one or more LTM candidate network node IDs.

In any one of the example implementations above, the base station is a source network node for LTM, and wherein the set of security information items comprise one or more lists of NH parameters and NCCs, each of the lists of NH parameters and NCCs being associated with a LTM candidate network node ID.

In any one of the example implementations above, the method may further include sending the list of NH parameters and NCCs being associated with a LTM candidate network node ID to a LTM candidate network node identified by the LTM candidate network node ID.

In any one of the example implementations above, the base station is a source network node for LTM or a candidate network node for LTM, and wherein the set of security information items comprise a list of pairs of NH parameters and NCCs.

In any one of the example implementations above, the base station is the candidate network node for LTM, and further comprising: sending the set of security information items to the source network node for LTM.

In some other implementations, a wireless communications apparatus is disclosed. The wireless communication apparatus may include a processor and a memory, wherein the processor is configured to read code from the memory and implement any one of the methods above.

In yet some other implementations, a non-transitory computer readable medium is disclosed. The non-transitory computer readable medium may include computer instructions, when executed by a processor of a wireless communication device, may cause the wireless communication device to implement any one of the methods above.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example wireless communication network including a wireless access network, a core network, and data networks.

FIG. 2 illustrates an example wireless access network including a plurality of mobile stations/terminals or User Equipments (UEs) and a wireless access network node in communication with one another via an over-the-air radio communication interface.

FIG. 3 shows an example radio access network (RAN) architecture.

FIG. 4 shows an example communication protocol stack in a wireless access network node or wireless terminal device including various network layers.

FIG. 5 illustrates an example LTM procedure.

FIG. 6 illustrates vertical and horizontal key update procedures.

FIG. 7 illustrates an example algorithm for generating integrity protection token from both a sending and receiving side.

FIG. 8 illustrate an example procedure for an RRC and lower layer cross-layer interaction during LTM cell switch.

FIG. 9 illustrates a network side inter-node interaction during an LTM cell switch procedure for exchanging security information.

FIG. 10 illustrates another network side inter-node interaction during an LTM cell switch procedure for exchanging security information.

FIG. 11 illustrates a network side inter-node interaction during an LTM cell switch procedure for key generation and transfer.

FIG. 12 illustrates another network side inter-node interaction during an LTM cell switch procedure for key generation and transfer.

DETAILED DESCRIPTION

The present disclosure will now be described in detail hereinafter with reference to the accompanied drawings, which form a part of the present disclosure, and which show, by way of illustration, specific examples of embodiments. The present disclosure may, however, be embodied in a variety of different forms and, therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the embodiments to be set forth below.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment” or “in some embodiments” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment” or “in other embodiments” as used herein does not necessarily refer to a different embodiment. The phrase “in one implementation” or “in some implementations” as used herein does not necessarily refer to the same implementation and the phrase “in another implementation” or “in other implementations” as used herein does not necessarily refer to a different implementation. It is intended, for example, that claimed subject matter includes combinations of exemplary embodiments or implementations in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part upon the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” or “at least one” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a” , “an” , or “the” , again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” or “determined by” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Wireless Network Overview

An example wireless communication network, shown as 100 in FIG. 1, may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The wireless terminal devices or UEs, may be alternatively referred to as wireless terminals. The carrier network 102, for example, may include access network nodes 120 and 121, and a core network 130. The carrier network 110 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and the other data networks 150. The access network nodes 120 and 121 may be configured as various wireless access network nodes (WANNs, alternatively referred to as wireless base stations) to interact with the UEs on one side of a communication session and the core network 130 on the other. The term “access network” may be used more broadly to refer a combination of the wireless terminal devices 110, 111, and 112 and the access network nodes 120 and 121. A wireless access network may be alternatively referred to as Radio Access Network (RAN) . The core network 130 may include various network nodes configured to control communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers deployed outside of but connected to the core network 130. Likewise, the other data networks 150 may also be connected to the core network 130.

In the example wireless communication network of 100 of FIG. 1, the UEs may communicate with one another via the wireless access network. For example, UE 110 and 112 may be connected to and communicate via the same access network node 120. The UEs may communicate with one another via both the access networks and the core network. For example, UE 110 may be connected to the access network node 120 whereas UE 111 may be connected to the access network node 121, and as such, the UE 110 and UE 111 may communicate to one another via the access network nodes 120 and 121, and the core network 130. The UEs may further communicate with the service applications 140 and the data networks 150 via the core network 130. Further, the UEs may communicate to one another directly via side link communications, as shown by 113.

FIG. 2 further shows an example system diagram of the wireless access network 120 including a WANN 202 serving UEs 110 and 112 via the over-the-air interface 204. The wireless transmission resources for the over-the-air interface 204 include a combination of frequency, time, and/or spatial resource. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with mobile access units such as SIM/USIM modules for accessing the wireless communication network 100. The UEs 110 and 112 may each be implemented as a terminal device including but not limited to a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle on-board communication equipment, a roadside communication equipment, a sensor device, a smart appliance (such as a television, a refrigerator, and an oven) , or other devices that are capable of communicating wirelessly over a network. As shown in FIG. 2, each of the UEs such as UE 112 may include transceiver circuitry 206 coupled to one or more antennas 208 to effectuate wireless communication with the WANN 120 or with another UE such as UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage devices. The memory 212 may be transitory or non-transitory and may store therein computer instructions or code which, when read and executed by the processor 210, cause the processor 210 to implement various ones of the methods described herein.

Similarly, the WANN 120 may include a wireless base station or other wireless network access point capable of communicating wirelessly via the over-the-air interface 204 with one or more UEs and communicating with the core network 130. For example, the WANN 120 may be implemented, without being limited, in the form of a 2G base station, a 3G nodeB, an LTE eNB, a 4G LTE base station, a 5G NR base station of a 5G gNB, a 5G central-unit base station, or a 5G distributed-unit base station. Each type of these WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include transceiver circuitry 214 coupled to one or more antennas 216, which may include an antenna tower 218 in various forms, to effectuate wireless communications with the UEs 110 and 112. The transceiver circuitry 214 may be coupled to one or more processors 220, which may further be coupled to a memory 222 or other storage devices. The memory 222 may be transitory or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

Data packets in a wireless access network such as the example described in FIG. 2 may be transmitted as protocol data units (PDUs) . The data included therein may be packaged as PDUs at various network layers wrapped with nested and/or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) once a connection (e.g., a radio link control (RRC) connection) is established between the transmitting and receiving ends. Any of the transmitting device or receiving device may be either a wireless terminal device such as device 110 and 120 of FIG. 2 or a wireless access network node such as node 202 of FIG. 2. Each device may both be a transmitting device and receiving device for bi-directional communications.

The core network 130 of FIG. 1 may include various network nodes geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes may be implemented as dedicated hardware network nodes. Alternatively, these network nodes may be virtualized and implemented as virtual machines or as software entities. These network nodes may each be configured with one or more types of network functions which collectively provide the provisioning and routing functionalities of the core network 130.

Returning to wireless radio access network (RAN) , FIG. 3 illustrates an example RAN 340 in communication with a core network 310 and wireless terminals UE1 to UE7. The RAN 340 may include one or more various types of wireless base station or WANNs 320 and 321 which may include but are not limited to gNB, eNodeB, NodeB, or other type of base stations. The RAN 340 may be backhauled to the core network 310. The WANNs 320, for example, may further include multiple separate access network nodes in the form of a Central Unit (CU) 322 and one or more Distributed Unit (DU) 324 and 326. The CU 322 is connected with DU1 324 and DU2 326 via various interfaces, for example, an F1 interface. The F1 interface, for example, may further include an F1-C interface and an F1-U interface, which may be used to carry control plane information and user plane data, respectively. In some embodiments, the CU may be a gNB Central Unit (gNB-CU) , and the DU may be a gNB Distributed Unit (gNB-DU) . While the various implementations described below are provided in the context of a 5G cellular wireless network, the underlying principles described herein are applicable to other types of radio access networks including but not limited to other generations of cellular network, as well as Wi-Fi, Bluetooth, ZigBee, and WiMax networks.

The UEs may be connected to the network via the WANNs 320 over an air interface. The UEs may be served by at least one cell. Each cell is associated with a coverage area. These cells may be alternatively referred to as serving cells. The coverage areas between cells may partially overlap. Each UE may be actively communicating with at least one cell while may be potentially connected or connectable to more than one cell. In the example of FIG. 1, UE1, UE2, and UE3 may be served by cell1 330 of the DU1, whereas UE4 and UE5 may be served by cell2 332 of the DU1, and UE6 and UE7 may be served by cell3 associated with DU2. In some implementations, a UE may be served simultaneously by two or more cells. Each of the UE may be mobile and the signal strength and quality from the various cells at the UE may depend on the UE location and mobility.

FIG. 4 further illustrates a simplified view of the various network layers involved in transmitting user-plane PDUs from a transmitting device 402 to a receiving device 404 in the example wireless access network of FIGs. 1-3. FIG. 4 is not intended to be inclusive of all essential device components or network layers for handling the transmission of the PDUs. FIG. 4 illustrates that the data packaged by upper network layers 420 at the transmitting device 402 may be transmitted to corresponding upper layer 430 (such as radio resource control or RRC layer) at the receiving device 304 via Packet Data Convergence Protocol layer (PDCP layer, not shown in FIG. 4) and radio link control (RLC) layer 422 and of the transmitting device, the physical (PHY) layers of the transmitting and receiving devices and the radio interface, as shown as 406, and the media access control (MAC) layer 434 and RLC layer 432 of the receiving device. Various network entities in each of these layers may be configured to handle the transmission and retransmission of the PDUs.

In FIG. 4, the upper layers 420 may be referred as layer-3 or L3, whereas the intermediate layers such as the RLC layer and/or the MAC layer and/or the PDCP layer (not shown in FIG. 4) may be collectively referred to as layer-2, or L2, and the term layer-1 is used to refer to layers such as the physical layer and the radio interface-associated layers. In some instances, the term “low layer” may be used to refer to a collection of L1 and L2, whereas the term “high layer” may be used to refer to layer-3. In some situations, the term “lower layer” may be used to refer to a layer among L1, L2, and L3 that are lower than a current reference layer. Control signaling may be initiated and triggered at each of L1 through L3 and within the various network layers therein. These signaling messages may be encapsulated and cascaded into lower layer packages and transmitted via allocated control or data over-the-air radio resources and interfaces. The term “layer” generally includes various corresponding entities thereof. For example, a MAC layer encompasses corresponding MAC entities that may be created. The layer-1 (L1) , for example, encompasses PHY entities. The layer-2 (L2) , for another example encompasses MAC layers/entities, RLC layers/entities, service data adaptation protocol (SDAP) layers and/or PDCP layers/entities.

L1/L2 Triggered Mobility (LTM) in Intra-CU Cell Switching

LTM is a procedure in which a gNB (generally representing a base station) receives L1 measurement report (s) from a UE, and on that basis the gNB changes UE’s serving cell by a cell switch command signaled via, for example, a MAC CE. The cell switch command indicates as a target cell an LTM candidate cell with a cell configuration that the gNB previously prepared and provided to the UE through RRC signaling. Then the UE switches to the target cell according to the cell switch command. The cell switch command may be conveyed in a MAC CE, which contains the necessary information to perform the LTM cell switch.

An overall example procedure for LTM is shown in FIG. 5. Subsequent LTM is done by repeating the early synchronization, LTM cell switch execution, and LTM cell switch completion steps without releasing other LTM candidate cell configurations after each LTM cell switch completion. FIG. 5 may be applied to a scenario that the cell switch is intra-CU, and as such only one gNB is shown and the LTM cell switch may occur between a source cell and a target cell associated with the same gNB. The example general procedure of FIG. 5 may be applicable to Main-Cell-Group (MCG) LTM cell switching and/or Secondary-Cell-Group SCG LTM cell switching.

The example general procedure of FIG. 5 for LTM is described as follows. The numeral headers represent the corresponding steps of FIG. 5.

1. The UE may send a MeasurementReport message to the gNB in the current communication connection with a source cell associated with the gNB. The gNB receives MeasurementReport message and then decides, based on the MeasurementReport message, to initiate LTM preparation to configure future LTM cell switch.

2. The gNB transmits an RRCReconfiguration message to the UE including the LTM candidate cell configurations for candidate cells.

3. The UE stores the LTM candidate cell configurations and transmits an RRCReconfigurationComplete message to the gNB. Steps 1-3 may be referred to as an LTM preparation procedure.

4a. The UE may perform downlink (DL) synchronization with the candidate cell (s) before receiving the cell switch command.

4b. If configured/indicated by the network, the UE may perform UE-based Time Advance (TA) measurement (s) or PDCCH order triggered early RACH to acquire the TA value (s) of one or multiple candidate cells before receiving the cell switch command. For UE-based Time Advance (TA) measurement (s) , the UE performs TA measurement (s) for the candidate cells after being configured by RRC but the exact timing for the UE to perform the TA measurement (s) is up to UE implementation. For PDCCH order triggered early RACH, this may be done via Contention Free Random Access (CFRA) triggered by a Physical Downlink Control Channel (PDCCH) order from the source cell, following which the UE sends preamble towards the indicated candidate cell. Then the indicated candidate cell calculates the TA value (s) . In order to minimize the data transmission interruption of the source cell in the current communication with the UE due to the CFRA towards the candidate cell (s) , the candidate cell (s) may not transmit and the UE may not receive Random Access Response (RAR) for the purpose of TA value acquisition, and the TA value (s) of the candidate cell (s) may be indicated in the cell switch command to the UE. The UE may not maintain TA timer (s) for the candidate cell (s) , and may rely on network implementation to guarantee TA validity instead. Steps 4a and 4b above may be referred to as an early synchronization procedure.

5. The UE may then perform L1 measurements on the configured candidate cell (s) and transmits L1 measurement reports to the gNB. L1 measurements should be performed as long as the RRC reconfiguration message (received in Step 2) is applied by the UE.

6. The gNB may decide to execute cell switch to a target cell (among the candidate cell (s) ) and transmits, e.g., a MAC CE triggering the cell switch by including a candidate configuration index of the target cell (for identify the target cell configuration among one or more candidate cells) . The UE may then switch to the target cell and applies the cell configuration indicated by the candidate configuration index.

7. The UE performs the random access procedure towards the target cell, if UE does not already have valid TA of the target cell from, for example, the synchronization procedure above. The random access procedure of Step 7 may be omitted if the UE has already obtained a valid TA of the target cell. Steps 5 through 7 above may be referred to as LTM cell switch execution procedure.

8. The UE completes the LTM cell switch procedure by sending RRCReconfigurationComplete message to the target cell. If the UE has performed a random access procedure in Step 7 above, the UE may consider that LTM cell switch execution is successfully completed when the random access procedure is successfully completed. For RACH-less LTM (where Step 7 is omitted) , the UE may instead consider that LTM cell switch execution is successfully completed when the UE determines that the network has successfully received its first UL data.

The Steps 4-8 above can be performed multiple times for subsequent LTM using the LTM candidate configuration (s) provided in Step 2.

Security Key Handling in Handover

Security keys are used as a basis for protecting communication between the UE and the base stations. Security keys may need to be updated during mobility and handover of a UE. For LTM, security keys may need to be updated, particularly for LTM involving inter CU cell switch. Because LTM is triggered at L1/L2, additional mechanisms may need to be considered in order to effectuate the security key update when needed. A security key for accessing a base station, e.g., an gNB, may be referred to as KgNB.

Handover on the network side may be performed over an Xn interface. FIG. 6 illustrates an example KgNB generation and update procedure. As shown in FIG. 6, In Xn handovers the source gNB/ng-eNB shall perform a vertical key derivation in case it has an unused {NH, NCC} pair (representing, {Next Hop, NH Chaining Counter} ) . The source gNB/ng-eNB shall first compute K_NG-RAN*from target PCI (Physical Cell ID) , its frequency ARFCN-DL/EARFCN-DL, and either from currently active K_gNB in case of horizontal key derivation or from the NH in case of vertical key derivation.

As further shown in FIG. 6, the source gNB/ng-eNB shall forward the {K_NG-RAN*, NCC} pair to the target gNB/ng-eNB. The target gNB/ng-eNB shall use the received K_NG-RAN*directly as K_gNB to be used with the UE. The target gNB/ng-eNB shall associate the NCC value received from source gNB/ng-eNB with the K_gNB. The target gNB/ng-eNB shall include the received NCC into the prepared handover (HO) Command message, which is sent back to the source gNB/ng-eNB in a transparent container and forwarded to the UE by source gNB/ng-eNB.

Security Information Deliver to UE

As generally described above, security information, such as the {K_NG-RAN*, NCC} pairs, the NCC information above, and the like, need to be communicated between source base station and the target base station. Security information may also need to be delivered to the UE in order for the UE to perform security key update/derivation (e.g., vertical or horizontal key derivation) to generate security keys to access a target base station in LTM.

Such security information may be delivered to the UE from the network side in several example manners.

In a first example implementation, referred to as Option 1, a new information item or element in a MAC CE may be used to deliver the security information to the UE. Whether the UE uses horizontal or vertical key derivation may be derived from this new information in MAC CE (which is currently, neither integrity protected nor ciphered) . For example, the NCC value to be used at inter-CU LTM execution may be included in the LTM cell switch command MAC CE. Alternatively, or additionally, the UE may be preconfigured with a list of NCC values in a ciphered and integrity protected RRC message and the index of an NCC value in the list may be included in the LTM cell switch command MAC CE. In either of the alternatively manner, the UE would be able to receive the NCC value needed for security key generation during LTM.

In a second example implementation, referred to as Option 2, an approach similar to S-CPAC (Subsequent Conditional PSCell Add/Change) key update mechanism may be designed. Specifically, the UE may be preconfigured from the source gNB with a list of NCC values per CU using, e.g., RRC signaling (that is both integrity-protected and ciphered) . The list of NCC values per CU may be generated by the core network (CN) or the source gNB. If the list is generated by the CN, the CN may send it to the source gNB during LTM preparation. It may be expected that the participating gNBs (CUs) would need to be aware of the list and how the UE applies the list during LTM cell switches. In some example implementations, the UE may choose the first unused NCC for the target CU upon inter-CU LTM execution. Alternatively, or additionally, as an alternative to choosing the next unused NCC, horizontal key derivation may be used if the LTM cell switch is between the same two CUs.

In some other example implementations, referred to as Option 3, after the execution of an inter-CU LTM cell switch, the participating gNBs may be expected to be updated with new K-gNB*to be used for the next inter-CU LTM cell switch. The UE and CN are aware of how the UE would use the next NCC value. For example, the UE may determine the following NCC value to use by itself (e.g., increase the NCC by 1) after subsequent inter-CU LTM execution. Alternatively, or additionally, the UE may be pre-configured by the core network (via source gNB RRC signaling) with a list of NCC values and the UE may choose the first unused NCC value as the next NCC value.

In some other example implementations, referred to as Option 4, after every inter-CU LTM cell switch execution, the UE may be provided via RRC signaling with the NCC value to be used by the UE for key derivation at the next inter-CU LTM cell switch.

Integrity protection of Security Information within a MAC CE

For Option 1 above, where MAC CE is used to deliver security information, such MAC CE is currently neither integrity protected nor ciphered.

If security information such as NCC is included in the MAC CE, it may not be necessary to encrypt the MAC CE. Similarly, in some other example implementations, NCC may be included and delivered in an RRCReestablishment message and the like, which is also not encrypted. However, integrity protection for the MAC CE may be desired and may need to be considered, particularly when it contains such critical information such as the security information above.

In some example implementations, the security information such as the NCC and an integrity protection token may be included within the same MAC CE.

Such an integrity protection token may be similar to the shortMAC-I (included in the RRCReestablishmentRequest message) or ResumeMAC-I (included in the RRCResumeRequest message) . In some example implementations, such an integrity protection token may be computed using a new security key that may be derived from the NCC being integrity protected as part of the MAC CE.

With the example scheme above for the delivery of security information and integrity protection token in the MAC CE, an example UE procedure for extracting the security information, deriving new security key, and/or verifying integrity of the MAC CE may include at least one of the following steps:

● Step 1: the UE may first receive the MAC CE with the new NCC and the integrity protection token.

● Step 2: the UE may then check whether the NCC value received in the MAC CE is equal to the NCC value associated with the currently active key, e.g., KgNB. If the NCC value received in the MAC CE is equal to the NCC value associated with the currently active KgNB, the UE may use horizontal key derivation to derive the new key. In other words, the UE may derive the K_NG-RAN* from the currently active K_gNB and the target PCI and its frequency ARFCN-DL. However, if the NCC value received in the MAC CE is different from the NCC value associated with the currently active KgNB, the UE may then use vertical key derivation to derive the new key. In other words, the UE may first synchronize a locally kept NH parameter (by increasing the NCC value until it matches the NCC value received via the MAC CE, and then obtain the synchronized NH) . When the NCC values match, the UE may then compute the K_NG-RAN* from the synchronized NH parameter and the target PCI and its frequency ARFCN-DL.

● Step 3: the UE may further check the integrity of the received MAC CE based on the new derived key and the integrity protection token. For example, if the integrity check fails (e.g., the integrity protection token calculated by the UE based on the new key is different from the integrity protection token received in the MAC CE, which may be referred to as “expected integrity protection token” , or “expected token” ) , the UE may perform at least one of : (1) Option 1: moving or transitioning to RRC_IDLE mode and performing NAS recovery; (2) Option 2: initiating an RRC re-establishment procedure; and in some example implementations, the UE may report the re-establishment cause (e.g., integrity check failure of MAC CE) to the network, e.g., via RRCReestablishmentRequest message; (3) Option 3: considering the MAC CE as invalid and/or discard the MAC CE. However, if the integrity check succeeds (e.g., the integrity protection token calculated by the UE based on the new key is equal to the integrity protection token received in the MAC CE, or the expected integrity protection token) , the UE may then perform the LTM, e.g., LTM cell switch execution procedure.

In the example procedure above, the integrity check may be performed within the UE’s MAC layer. Alternatively, the UE may invoke another layer of the UE, such as Package Data Convergence Protocol (PDCP) layer to perform the verification of integrity by passing the received integrity protection token to the PDCP layer.

Generation/Calculation of Integrity Protection Token

In some example implementations, the integrity protection token above for the MAC CE may be determined by using a last serving cell PCI, C-RNTI allocated by last serving cell and the Cell ID of the target cell (e.g., CGI or Cell Group ID, PCI, cell identity, LTM candidate configuration index) and calculated using the new security key (e.g., the integrity protection key K_RRCint derived using the NCC received in the MAC CE) .

In order to calculate the token as described above, the source node or source base station may use an integrity protection algorithm (e.g., the negotiated Integrity Algorithm for 5G (NIA) from the 5G AS Security context from the source node) with at least one of the following inputs:

● the last serving cell PCI (e.g., source cell PCI) ;

● the last serving cell C-RNTI (e.g., source cell C-RNTI) ;

● the cell ID of the target cell (e.g., the CGI, the PCI, the cell identity, or the LTM candidate configuration index of the target cell) ;

● KEY parameter of the NIA algorithm may be set to the integrity protection key of the target cell, e.g., the integrity protection key for the control plane K_RRCint derived based on the NCC included in the MAC CE;

● all BEARER bits for the NIA algorithm may be set to a default value, e.g., 0 or 1;

● DIRECTION bit for the NIA algorithm may be set to a default value, e.g., 0 or 1;

● all COUNT bits for the NIA algorithm may be set to a default value, e.g., 0 or 1;

● MESSAGE bit for the NIA algorithm may be set to the bit length/size of the MAC CE, or the MAC CE plus its subheader.

In some example implementations, the 16 least significant bits of the output of the integrity algorithm above may be retained as the calculated integrity protection token.

An example illustration of using the NIA to authenticate the integrity of the MAC CE is shown in FIG. 7 from both the sender (base station) and the receiver (UE) point of view. FIG. 7 shows that the sender and the receiver perform symmetric calculation. Both the sender and the receiver perform key derivation (e.g., based on NCC know to the sender, and NCC received from the MAC CE by the receiver) . And then using the NIA algorithm to process the key and other inputs above that are either of known default value or otherwise related to the MAC CE to generate the token. The sender would then include it as the expected token in the MAC CE whereas the receiver would compare its calculated token to the expected token carried by the MAC CE for integrity check.

The generation and/or calculation of the integrity protection token at the network side (the sender above) may be performed at various network entities. But regardless, it may be preferable that the source/serving CU be responsible for generating the new key for the target cell, e.g., deriving the K_NG-RAN* from the target PCI and its frequency ARFCN-DL, and the currently active K_gNB or the NH (if there is an unused {NH, NCC} pair available in the source/serving gNB) .

In some other example implementations, the integrity protection token at the network side as the expected token may instead be generate at the DU of the base station (e.g., the source/serving DU) . In such implementations, the source/serving CU would need to know the cell info (e.g., target PCI and its frequency ARFCN-DL) of the target cell, in order to generate the target key for the target cell (e.g., the key K_RRCint derived using the NCC) and transfer the target key security key and associated NCC to the source/serving DU. The DU would then generate the integrity protection token based on the key information received from the CU using, e.g., the NIA algorithm, as described above.

In yet some other example implementations, the integrity protection token may be generated/calculated by the source/serving CU. Again, the CU needs first to know the cell info (e.g., target PCI and its frequency ARFCN-DL) of the target cell in order to generate the key for the target cell. The source/serving CU may then generate/calculate the integrity protection token. The source/serving CU may then transfer the NCC value and associated integrity protection token to the source/serving DU.

In LTM, the target cell is selected and determined by the source/serving DU. Considering that the source/serving CU needs to know the cell info (e.g., target PCI and its frequency ARFCN-DL) of the target cell in order to generate the key information for the target cell, there may be further two alternatives for the integrity protection token generation in terms of a timing for the token generation at the network side.

In some example implementations, the integrity protection token may be generated or calculated on the network side after the source/serving DU determines/decides/selects the target cell for the LTM execution. For example, when the source/serving DU decides/selects the target cell for the LTM execution, the DU may provide the target cell info (e.g., the candidate cell configuration ID) to the source/serving CU. The source/serving CU may then send the security related information (e.g., NCC and security key, or the integrity protection token if generated by the source/serving CU) for the target cell to the source/serving DU. The source/serving DU may then include the NCC value and/or the integrity protection token (either received from the source/serving CU or generated at the source/serving DU) into the LTM cell switch command MAC CE and sends the MAC CE to the UE to trigger the LTM.

In some example alternatives to the implementations above, the integrity protection token may be generated or calculated on the network side before the source/serving DU determines/decides/selects the target cell for the LTM execution. In that situation, the source/serving CU may pre-provide the security related information to the DU for each configured candidate cell. For the case where the integrity protection token is to be generated by the source/serving DU, the CU may send the NCC value, and a list of new keys to the source/serving DU. In some example, each key in the list may be associated with the cell information (e.g., CGI, PCI, cell identity, the candidate configuration index) for the configured candidate cell. For the case where the integrity protection token is to be generated by the source/serving CU, the CU would generate a list of integrity protection tokens for the configured candidate cell (s) , and transmits the NCC (s) , key (s) , and/or a list of tokens to the DU. In some example, each token in the list may be associated with the cell information (e.g., CGI, PCI, cell identity, the candidate configuration index) of the configured candidate. After the DU finally decides/selects the target cell from the configured candidate cells for the LTM execution, the DU would include the NCC value and/or the integrity protection token (either by selecting from the list of tokens from the source/serving CU, or by calculating the token for the target cell by selecting the corresponding key from the list of such information for the configured candidate cells as received from the source/serving CU) for the selected target cell into the LTM cell switch command MAC CE and sends the MAC CE to the UE to trigger the LTM. Upon sending the MAC CE to the UE, the source/serving DU may inform the target candidate cell info to the source/serving CU, e.g., via CU-DU CELL SWITCH NOTIFICATION message. After receiving the target candidate cell info, the CU may discard the key and/or integrity protection token generated by candidate cell (s) other than the target candidate cell.

Security Update Information in MAC CE

The MAC CE above for delivering the NCC and/or the integrity protection token to the UE, such as the LTM cell switch MAC CE command, may also include additional security information.

In some implementations, information about change of security algorithm and/or the change of key set indicator may be indicated in the HO command (i.e. via RRCReconfiguration message) . Such information may be included in the MAC CE above.

In some example implementations, the security algorithm may be provided per radio bearer. The ciphering or integrity protection algorithms configured for all bearers using master key shall be the same, and ciphering or integrity protection algorithms configured for all bearers using secondary key, if any, shall be the same.

In some example implementations, the MAC CE above may include at least one of the following security related information:

● An NCC value as described above.

● An integrity protection token (the expected integrity protection token as calculated from the network side, as described above) ;

● An indicator for key set change, e.g., to indicate whether a K_gNB key is derived from a K_AMF key

● The ciphering algorithm used for all bearers using master key;

● The ciphering algorithm used for all bearers using secondary key;

● The integrity protection algorithm used for all bearers using master key;

● The integrity protection algorithm used for all bearers using secondary key;

In some example implementations, the integrity protection algorithm may include at least one of algorithms nia0, nia1, nia2, or nia3. The ciphering algorithm may include at least one of the algorithms nea0, nea1, nea2, nea3.

In some other example implementations, an alternative way to indicate the ciphering algorithm and/or integrity protection algorithm in the MAC CE may be used. For example, the network may provide a pre-configured list of ciphering algorithms and/or a pre-configured list of integrity protection algorithms to the UE via RRC message. The MAC CE may include an index of ciphering algorithm (to indicate which ciphering algorithm from the pre-configure list is to be applied for the target cell) and/or an index of integrity protection algorithm (to indicate which integrity protection algorithm from the pre-configured list is to be applied for the target cell) .

If the above security related information is to be included in the MAC CE, the source/serving CU would need to transfer such information to the source/serving DU via, for example, F1 message (s) . In some example implementations, the CU may provide such information to the DU after the DU decides the target cell for the LTM execution. In that situation, the CU may send the information for the target candidate cell to the DU. In some other example implementations, the CU may provide such information to the DU before the DU decides the target cell for the LTM execution. In that situation, the CU may pre-provide the security related information to the DU for each configured candidate cell, e.g., the CU sends a list of security algorithms and associated candidate cell info (e.g., CGI, PCI, cell identity, the candidate configuration index) to the DU.

Cross-layer Interaction at the UE side

An example of cross layer interaction at the UE side for LTM cell switch execution, particularly involving security related information is illustrated in FIG. 8.

In FIG. 8, RRC and lower layer (MAC/PDCP) cross-layer interactions during LTM cell switch execution are shown. Such interaction may include at least one of the following steps.

Step 1: The UE may receive the LTM cell switch command MAC CE from the serving/source DU. The MAC CE may include the LTM candidate configuration ID for the target cell and security related information. The security related information may include at least one of the following:

● An NCC value;

● An integrity protection token;

● An indicator for key set change, e.g., to indicate whether a K_gNB key is derived from a K_AMF key;

● The ciphering algorithm used for all bearers using master key;

● The ciphering algorithm used for all bearers using secondary key;

● The integrity protection algorithm used for all bearers using master key; or

Step 2: The MAC layer decodes the LTM cell switch command MAC CE;

Step 3: The MAC layer indicates to upper layers (e.g., RRC layer) that the LTM cell switch procedure is triggered and the LTM candidate configuration ID for the target cell, the security related information included in the MAC CE.

If the integrity check is performed in the MAC layer, the MAC layer may not be required to indicate the received integrity protection token to upper layers. If the integrity check is performed in the PDCP layer, the MAC layer may indicate the received integrity protection token to upper layers.

Step 4: The RRC layer derives the new key (s) for the target cell, based on the received security related information, e.g., the NCC value, the ciphering algorithm, and/or the integrity protection algorithm.

Step 5: The RRC layer may request lower layers (e.g., MAC layer, PDCP layer) to verify the integrity protection of the MAC CE, e.g., using the integrity protection algorithm and/or the derived key for integrity protection. If the integrity check is performed in the MAC layer, the RRC layer may indicate the integrity protection algorithm and/or the derived key for integrity protection to the MAC layer. If the integrity check is performed in the PDCP layer, the RRC layer may indicate the received integrity protection token, the integrity protection algorithm and/or the derived key for integrity protection to PDCP layer.

Step 6: The lower layer performs the integrity check, e.g., calculating the value of integrity protection token based on the newly derived key. If the calculated value is equal to the integrity protection token received in the MAC CE, the integrity protection is verified successfully. Otherwise, the integrity protection check fails.

Step 7: The lower layer indicates the indication of integrity check failure or success to upper layers.

Step 8: The RRC performs the LTM cell switch execution procedure or failure handling procedure, based on the integrity check indication from lower layers.

Signaling interaction between Network Nodes

For the various implementations above, the network side node (the base stations including source/serving CU and DU, target CU and DU, candidate CU and DU, and/or core network) may need to interact in order to implement the security information delivery, and other general configuration and execution of LTM cell switch. In some options for security information deliver not via MAC CE (e.g., option 2 or option 3 in parallel with the MAC CE option 1 above) , the core network CN (e.g., AMF) may need to pre-provide a list of {NH, NCC} for candidate cells during LTM preparation phase.

Some interactions between nodes on the network side may target particular information being communicated. For example, network side may interact for {NH, NCC} list preparation. Various example interactions mechanisms may be used to handle interaction with respect to the {NH, NCC} list preparation.

In some example implementations, the source node may request the core network (CN, e.g., an AMF node) to provide a list of {NH, NCC} for candidate cells or nodes. For another implementation, each candidate node may request the CN to provide a list of {NH, NCC} for this candidate node. In other words, the request for the list of {NH, NCC} may be requested by the source node or each candidate node, as shown in FIG. 9 and FIG. 10.

The example network node interaction in FIG. 9 may include:

1. The source node (e.g., the source CU) decides to configure LTM and initiates LTM preparation.

2. The source node sends an LTM Security Request message to the AMF to request the security context, e.g., the {NH, NCC} pair (s) for the candidate cell (s) or the candidate node (s) . The message may include an indication to indicate the request for a list of {NH, NCC} pairs for candidate cells, or the request for a list of {NH, NCC} pairs per candidate node. The message may also include the candidate cell ID (s) and/or candidate node ID (s) . In addition, the request message may also include other information that the AMF can use to determine the NH, NCC pair to be used for the candidate cells such as the UE Security Capabilities.

3. In the successful case, the AMF responds to an LTM Security Request message with an LTM Security Request Acknowledge message to the source node. This message may include a list of {NH, NCC} pairs, or a list of {NH, NCC} pairs per candidate node (e.g., each list is associated with a candidate node ID) . If the AMF cannot provide the {NH, NCC} pair for candidate cell (s) or node (s) , it may respond with a LTM Security Request Failure message.

4. Once the Security context including {NH, NCC} pair (s) for a given candidate cell or node is obtained from the AMF, the source node sends a Handover Request message to the candidate node (e.g., candidate CU) for the LTM request. If the list of {NH, NCC} pairs is provided per candidate node, the source node may include the list of {NH, NCC} pairs for the corresponding candidate node in the message. For the candidate cell (s) or node (s) for which AMF doesn’ t provide the security context (e.g., the {NH, NCC} pair) , the source node may not send the Handover Request message and hence will not prepare these candidate cell (s) or node (s) for LTM handover.

5. The candidate node responds a Handover Request Acknowledge message to the source node.

6. The source node sends a RRCReconfiguration message with LTM configuration to the UE. The message may also include the list (s) of NCC values for LTM candidate cell (s) .

7. The UE sends a RRCReconfigurationComplete message to the source node.

The LTM Security Request procedure (e.g., step 2/3 of FIG. 9) may be performed after the Handover Request procedure (e.g., step 4/5) . The source node may initiate this procedure after the candidate node prepares the LTM candidate cell (s) . If the list of {NH, NCC} pairs is prepared per candidate node, the source node may initiate another procedure (e.g., a modification procedure) to each candidate node to inform the {NH, NCC} pairs for the candidate node, after receiving such information from the AMF.

The example network node interaction in FIG. 10 may include:

2. The source node sends a Handover Request message to each candidate node (e.g., candidate CU) for the LTM request.

3. The candidate node sends an LTM Security Request message to the AMF to request {NH, NCC} pair (s) for candidate cell (s) . The message may include an indication to indicate the request for a list of {NH, NCC} pairs for candidate cells, candidate cell ID (s) , and/or the UE Security Capabilities.

4. In the successful case, the AMF responds to an LTM Security Request message with an LTM Security Request Acknowledge message to the candidate node. The message may include a list of {NH, NCC} pairs. If the AMF cannot provide the {NH, NCC} pair for candidate cell (s) , it may respond with an LTM Security Request Failure message

5. If the AMF responds with the LTM Security Request Acknowledge message including the Security Context, the candidate node responds with a Handover Request Acknowledge message to the source node. With this, the source node knows that the corresponding candidate node is prepared for LTM. In successful case, the candidate node may also include a list of {NH, NCC} pairs to the source node. The list may be included in the Handover Request Acknowledge message directly (e.g., as an IE) or included in the RRCReconfiguration message contained in the Handover Request Acknowledge message. On the other hand, if the AMF responds to the candidate node with LTM Security Request Failure message (e.g., it doesn’ t provide the Security context) , the candidate node responds with Handover Request Failure message to the source node. In this case, the source node will not consider the candidate node as a candidate for LTM and will not include the candidate cell (s) in this node in the LTM candidate list in the RRCReconfiguration message sent to the UE.

6～7. These interactions are similar to 6～7 in FIG. 9.

Network Side Interaction on the Key Generation and/or Transfer

The example implementations below are applicable to all options of security information delivery above including using MAC CE.

As described above, in some example implementations, the source node (e.g., source CU) is responsible for generating the new key for the target cell, e.g., deriving the K_NG-RAN* from the target PCI and its frequency ARFCN-DL, and the currently active K_gNB or the NH (if there is an unused {NH, NCC} pair available in the source gNB) . And the source node shall send the new key (i.e. K_NG-RAN*) and/or associated NCC to the target node, e.g., via HO Request message.

[Rectified under Rule 91, 28.05.2024]
The network side interaction may depend on when to generate the new key for the target cell and/or transfer it to the target/candidate node, as shown in FIG. 11 and FIG. 12.

As shown in FIG. 12, in one example implementation, the serving CU may generate the new key for the target cell after the serving DU decides/selects the target cell for the LTM execution. In such an implementation, when the serving DU decides/selects the target cell for the LTM execution, the serving DU informs the target cell info (e.g., the candidate cell configuration ID) to the serving CU. The serving CU then generate the new key for the target cell (based on the target cell info and/or NH) and sends the NCC value to the serving DU. Then the serving DU may include the NCC value into the LTM cell switch command MAC CE and sends the MAC CE to the UE to trigger the LTM. The serving CU may then transfer the new key and associated NCC to the target CU before/upon/after sending the NCC value to the serving DU, or after receiving the DU-CU CELL SWITCH NOTIFICATION message.

[Rectified under Rule 91, 28.05.2024]
In another example implementation, as shown in FIG. 12, the serving CU may generate the new key for each target cell before the serving DU decides/selects the target cell for the LTM execution. The serving CU may then generate the new key for each candidate cell (based on the candidate cell info and/or NH) , e.g., when the UE switches to the serving CU. The serving CU may transfer the NCC and/or generated new key (s) to each candidate CU, e.g., sending an NCC and/or a list of generated new key and associated candidate cell info. The serving CU may then transfer the NCC to the serving DU. When the serving DU decides/selects the target cell for the LTM execution, the serving DU may include the NCC value into the LTM cell switch command MAC CE and sends the MAC CE to the UE to trigger the LTM. Upon sending the MAC CE to the UE, the serving DU may inform the target cell info to the serving CU, e.g., via CU-DU CELL SWITCH NOTIFICATION message. Then the serving CU may inform the target candidate CU and other candidate CU (s) that the LTM is triggered via an Xn message, which may include the target cell info. After receiving the above message from the serving CU, the target candidate CU may discard the new key (s) for the candidate cell (s) except for the target candidate cell, and/or other candidate CU (s) may discard the previously received new key (s) and/or NCC from the serving CU.

For option 2 in section above entitled “Security Information Delivery to UE” , the UE maintains a list of NCC values per CU, correspondingly, each CU maintains a list of {NH, NCC} pairs for itself. Upon inter-CU LTM execution, the UE may choose the first unused NCC associated with the target CU to derive the new key for the target cell. In the NW side, the target CU may also choose the first unused NCC to derive the new key for the target cell, e.g., when the target CU knows the target cell information from the source CU.

The description and accompanying drawings above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment/implementation” as used herein does not necessarily refer to the same embodiment and the phrase “in another embodiment/implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and/or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

A method performed by a wireless terminal in communication with a base station in a wireless communication network, comprising:

receiving layer-1/layer-2 triggered mobility (LTM) cell switch command for switching to a target cell;

retrieving a set of security information items;

generating a security key for communication with the target cell based on at least the set of security information items and cell information of the target cell.
The method of clam 1, wherein the set of security information items are retrieved from the LTM cell switch command, wherein the LTM cell switch command is carried via a media access control (MAC) control element (MAC CE) received from the base station.
The method of claim 2, wherein the set of security information items comprise a next hop counter (NCC) for the target cell and wherein generating the security key comprises:

generating the security key based on a horizontal key derivation when the NCC matches a current NCC corresponding to a current active security key associated with the base station; or

generating the security key based on a vertical key derivation when the NCC differs from the current NCC.
The method of claim 2, wherein the MAC CE further comprises an expected token for integrity protection of the MAC CE and wherein the method further comprises performing an integrity verification of the MAC CE according to the expected token.
The method of claim 4, wherein performing the integrity verification of the MAC CE comprises:

generating a calculated token based on the security key;

comparing the calculated token to the expected token; and

determining that the integrity verification of the MAC CE is successful when the calculated token matches the expected token; or

determining that the integrity verification of the MAC CE fails when the calculated token differs from the expected token.
The method of claim 5, wherein when the integrity verification fails, the method further comprises at least one of:

switching to a radio resource control (RRC) idle mode of the wireless terminal and performing an NAS recovery;

initiating an RRC re-establishment procedure; or

discarding the MAC CE as invalid.
The method of claim 5, wherein the integrity verification of the MAC CE is performed at a MAC layer of the wireless terminal.
The method of claim 5, wherein the integrity verification of the MAC CE is performed at a higher layer above a MAC layer of the wireless terminal.
The method of claim 8, wherein the higher network layer where the integrity verification of the MAC CE is performed comprises a packet data convergence protocol (PDCP) layer.
The method of claim 8, further comprising indicating by the MAC layer to the higher layer at least one of (1) that an LTM cell switch procedure is triggered; (2) an LTM candidate configuration ID for the target cell; or (3) the set of security information items.
The method of claim 5, wherein the calculated token is generated using the security key and based on at least one of:

a physical cell identifier (PCI) of a last serving cell of the wireless terminal;

a C-RNTI allocated by the last serving cell; or

a cell ID of the target cell.
The method of claim 11, wherein the calculated token is generated using a integrity algorithm with input parameters including at least one of BEARER bits, DIRECTION bit, COUNT bits, or with MESSAGE bits set to a bit length of the MAC CE.
The method of claim 11, wherein the cell ID of the target cell comprises at least one of a cell global ID (CGI) , a PCI, a cell identity, or a candidate configuration index of the target cell.
The method of claim 4, wherein the expected token is generated by a distributed unit (DU) or a central unit (CU) of the base station.
The method of claim 14, wherein the expected token is generated by the DU based on the set of security information items transferred from the CU to the DU.
The method of claim 14, wherein the expected token is generated by the CU and sent to the DU.
The method of claim 14, wherein the expected token is received by the wireless terminal from the DU.
The method of claim 14, wherein a set of expected tokens are generated for one or more configured candidate cells for LTM, and wherein the target cell is selected among the one or more configured candidate cells for LTM and the expected token of the target cell among the set of expected tokens is received by the wireless terminal from the DU.
The method of claim 4, wherein the MAC CE further comprises at least one of:

a first indicator for key set change to indicate whether the security key is derived from a base key provided by a core network of the wireless communication network;

a second indicator of a ciphering algorithm used for all bearers using a master key;

a third indicator of a ciphering algorithm used for all bearers using a secondary key;

a fourth indicator of an integrity protection algorithm used for all bearers using the master key; or

a fifth indicator of an integrity protection algorithm used for all bearers using the secondary key.
[Rectified under Rule 91, 06.06.2024]
The method of claim 4, wherein the MAC CE further comprises an index for identifying a ciphering algorithm or an integrity protection algorithm to apply to the target cell from a list of ciphering algorithms or a list of integrity protection algorithms preconfigured to the wireless terminal via an RRC message.
A method performed by a base station in communication with a wireless terminal in a wireless communication network, comprising:

sending a request message to request a set of security information items from a core network of the wireless communication network during a layer-1/layer-2 triggered mobility (LTM) preparation phase; and

receiving a response message including the set of security information items from the core network for an LTM configuration.
The method of claim 21, wherein the request message includes at least one of:

an indicator to request a list of pairs of next hop (NH) parameters and NCCs;

an indicator to request a list of pairs of NHs and NCCs provided per candidate network node for LTM;

one or more LTM candidate cell IDs;

or

one or more LTM candidate network node IDs.
The method of claim 21, wherein the base station is a source network node for LTM, and wherein the set of security information items comprise one or more lists of NH parameters and NCCs, each of the lists of NH parameters and NCCs being associated with a LTM candidate network node ID.
The method of claim 23, further comprising:

sending the list of NH parameters and NCCs being associated with a LTM candidate network node ID to a LTM candidate network node identified by the LTM candidate network node ID.
The method of claim 21, wherein the base station is a source network node for LTM or a candidate network node for LTM, and wherein the set of security information items comprise a list of pairs of NH parameters and NCCs.
The method of claim 25, wherein the base station is the candidate network node for LTM, and further comprising:

sending the set of security information items to the source network node for LTM.
The wireless terminal or base station of any one of claims 1-26 comprising at least one memory for storing computer instructions and at least one processor for executing the computer instructions to perform any one of the methods of claims 1-26.