Technologies for lower layer triggered mobility failure recovery operation

Abstract

The present application relates to devices and components including apparatus, systems, and methods for lower layer triggered mobility (LTM) failure recovery operation.

Description

TECHNOLOGIES FOR LOWER LAYER TRIGGERED MOBILITY FAILURE RECOVERY OPERATIONTECHNICAL FIELD

[0001] This application relates generally to communication networks and, in particular, to lower layer triggered mobility (LTM) failure recovery operation.BACKGROUND

[0002] Third Generation Partnership Project (3GPP) Technical Specifications (TSs) define standards for wireless networks. These TSs describe aspects related to user plane and control plane signaling over the networks.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates a network environment in accordance with some embodiments.

[0004] FIG. 2 illustrates a signaling diagram in accordance with some embodiments.

[0005] FIG. 3 illustrates another signaling diagram in accordance with some embodiments.

[0006] FIG. 4 illustrates another signaling diagram in accordance with some embodiments.

[0007] FIG. 5 illustrates an operation flow / algorithmic structure in accordance with some embodiments.

[0008] FIG. 6 illustrates another operation flow / algorithmic structure in accordance with some embodiments.

[0009] FIG. 7 illustrates another operation flow / algorithmic structure in accordance with some embodiments.

[0010] FIG. 8 illustrates a user equipment in accordance with some embodiments.

[0011] FIG. 9 illustrates a network node in accordance with some embodiments.DETAILED DESCRIPTION

[0012] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular structures, architectures, interfaces, and techniques to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrases “A / B” and “A or B” mean (A) , (B) , or (A and B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

[0013] The following is a glossary of terms that may be used in this disclosure.

[0014] The term “circuitry, ” as used herein, refers to, is part of, or includes hardware components that are configured to provide the described functionality. The hardware components may include an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application-specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , or a digital signal processor (DSP) . In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0015] The term “processor circuitry, ” as used herein, refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, recording, storing, or transferring digital data. The term “processor circuitry” may refer to an application processor, baseband processor, central processing unit (CPU) , graphics processing unit, single-core processor, dual-core processor, triple-core processor, quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

[0016] The term “interface circuitry, ” as used herein, refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I / O interfaces, peripheral component interfaces, and network interface cards.

[0017] The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities that may allow a user to access network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device, including a wireless communications interface.

[0018] The term “computer system, ” as used herein, refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” or “system” may refer to multiple computer devices or multiple computing systems that are communicatively coupled with one another and configured to share computing or networking resources.

[0019] The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component or asset within a computing or network environment, or a physical or virtual component within, accessible by, or available to a device or component. Resources could include, but are not limited to, memory space / usage, processor / CPU time, processor / CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input / output operations, ports or network sockets, channel / link allocations, throughput, or workload units. A “hardware resource” may refer to compute, storage, or networking resources provided by physical hardware elements. A “virtualized resource” may refer to compute, storage, or networking resources provided by virtualization infrastructure to an application, device, or system. The term “communication resource” may refer to resources that are accessible by, or available to, computer devices / systems for transferring information over a channel of a communication network. For example, communication resources may include, but are not limited to, time / frequency resources, code resources, modulation resources, etc. The term “system resources” may refer to any kind of shared entities to provide services and may include computing or network resources. System resources may be considered as a set of coherent functions, network data objects, or services accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0020] The term “channel, ” as used herein, refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with or equivalent to “communications channel, ” “data communications channel, ” “transmission channel, ” “data transmission channel, ” “access channel, ” “data access channel, ” “link, ” “data link, ” “carrier, ” “radio-frequency carrier, ” or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link, ” as used herein, refers to a connection between two devices for the purpose of transmitting and receiving information.

[0021] The terms “instantiate, ” “instantiation, ” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0022] The term “connected” may mean that two or more elements at a common communication protocol layer have an established signaling relationship with one another over a communication channel, link, interface, or reference point.

[0023] The term “network element, ” as used herein, refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous with or referred to as a networked computer, networking hardware, network equipment, network node, or a virtualized network function.

[0024] The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element or a data element that contains content. An information element may include one or more additional information elements.

[0025] FIG. 1 illustrates a network environment 100 in accordance with some embodiments. The network environment 100 may include a UE 104 communicatively coupled with a base station 108 of a radio access network (RAN) 110. The UE 104 and the base station 108 may communicate over air interfaces compatible with 3GPP TSs, such as those that define a Fifth Generation (5G) new radio (NR) system, a Sixth Generation (6G) system, or a later system. The base station (BS) 108 may provide user plane and control plane protocol terminations toward the UE 104.

[0026] Operations described herein as associated with devices of the network environment 100 (for example, the UE 104 and the base station 108) may be fully, substantially, or partially performed by processor circuitry of the device.

[0027] The network environment 100 may further include a core network 112. For example, the core network 112 may comprise a 5G Core network (5GC) , a 6G core network (6GC) , or a later generation core network. The core network 112 may be coupled to the base station 108 via a fiber optic or wireless backhaul. The core network 112 may provide functions for the UE 104 via the base station 108. These functions may include managing subscriber profile information, subscriber location, authentication of services, or switching functions for voice and data sessions. The core network 112, RAN 110, and RAN 110 may collectively be referred to as network 102.

[0028] The network environment 100 may further include a data network 120. Data network 120 may include a system of interconnected nodes that facilitate data transmission between UE 104 and various application servers and other service providers. The base station 108 and the core network 112 may route application data between the UE 104 and external data network 120 or application servers. These application servers host web applications, cloud storage, and multimedia streaming services, which communicate with the UE 104 via standardized protocols and interfaces defined by 3GPP, ensuring secure and efficient data exchange.

[0029] Lower-layer triggered mobility (LTM) may occur when network 102 determines that the serving cell’s signal quality has degraded or that UE 104 may benefit from transitioning to a better-suited target cell. This determination may be based on periodic or event-triggered measurement reports from UE 104, which may include metrics such as synchronization signal block (SSB) or channel state information-reference signal (CSI-RS) measurements. Alternatively, UE 104 may initiate LTM if it detects conditions indicating poor signal quality or mobility-related issues, such as degradation in beam-specific metrics. LTM may also be triggered proactively, where network 102 configures UE 104 with candidate cell information, enabling early synchronization and readiness for a cell switch. Early synchronization may involve downlink synchronization using activated Transmission Configuration Indicator (TCI) states, allowing UE 104 to establish timing alignment with candidate cells while remaining connected to the serving cell.

[0030] Conditional Layer 1 / Layer 2 Triggered Mobility (CLTM) may build upon LTM principles but introduce execution conditions that must be met before the mobility procedure is triggered. These conditions may be based on Layer 1 measurements, such as beam-specific quality metrics, or Layer 3 measurements, such as aggregated cell-level metrics. For example, the execution of CLTM may depend on predefined thresholds of signal strength or quality, allowing mobility to occur only when specific criteria are satisfied. Conditional LTM may enhance the reliability and adaptability of mobility procedures by tying the process to real-time network or UE conditions. This approach may also allow UE 104 to perform early synchronization with candidate cells while delaying the actual cell switch until the conditions are met. During CLTM execution, network 102 may signal the switch via a media access control (MAC) control element (CE) and provide updated timing advance (TA) information for the target cell if the execution condition is met.

[0031] The differences between LTM, CLTM, handover, and cell reselection may lie in the operational context and signaling requirements. LTM may operate in radio resource control (RRC) connected mode using lower-layer triggers for mobility decisions, while CLTM introduces additional criteria for execution, enabling more precise control of mobility processes. Handover, a Layer 3 mobility procedure, typically relies on higher layer signaling and may involve a broader set of operations, such as updating network contexts and security keys. Cell reselection, on the other hand, may occur in RRC idle mode, where UE 104 autonomously selects a new cell based on signal quality without network direction. In contrast, LTM and Conditional LTM may be active-mode mobility procedures, where network 102 plays a central role in configuring and directing mobility operations for UE 104 in connected mode. Ongoing data forwarding between the source and target cells may continue during the completion phase of both LTM and CLTM to prevent data loss or interruption.

[0032] LTM and CLTM operations may involve four distinct phases: preparation, early synchronization, cell switch execution, and cell switch completion. These phases may collectively enable mobility transitions for the UE 104 by tying cell switch execution to predefined conditions or events in the case of CLTM or to network-triggered events for LTM. Each phase may rely on specific configurations, measurements, and signaling interactions between the UE and the network to facilitate mobility processes.

[0033] During the preparation phase, the network may configure the UE 104 through signaling, such as RRC reconfiguration messages. Configuration information may include candidate cell details or execution conditions tied to Layer 1 (physical layer) or Layer 3 (network layer) measurements. These execution conditions may involve parameters such as beam identifiers, signal thresholds, or timing advance (TA) values. The network may also coordinate with candidate cells to gather channel state information (CSI) resource configurations necessary to support the cell switch operation. The UE 104 may store candidate cell configurations for subsequent mobility operations, with each candidate cell potentially having its own execution condition that may trigger the cell switch process when satisfied (for CLTM) or based on network commands (for LTM) .

[0034] The early synchronization phase may prepare the UE 104 for the cell switch by enabling early downlink (DL) and uplink (UL) synchronization with candidate cells. For early DL synchronization, the network may activate timing and spatial configuration information or TCI states associated with candidate cells, allowing the UE to synchronize with those cells while remaining connected to the serving cell. For UL synchronization, the network may trigger early timing advance acquisition by sending a Physical Downlink Control Channel (PDCCH) order, instructing the UE to transmit a preamble toward the candidate cell. This preamble transmission may enable the base station to calculate and share TA information with the UE, which may be used during the cell switch operation. In CLTM, if execution conditions tied to candidate cells are not met, the UE may maintain synchronization states without initiating the switch.

[0035] The cell switch execution phase may differ slightly between LTM and CLTM. For LTM, the network 102 may signal the cell switch to the UE 104 via a MAC CE, providing the target cell configuration and execution details. For CLTM, the cell switch may occur when predefined execution conditions for a candidate cell are satisfied, and the network signals the switch through a MAC CE. This command may specify the beam identifiers, TA values, and candidate cell configuration index associated with the target cell. Upon receiving the cell switch command, the UE 104 may apply the target cell configuration and transition to the target cell. If the TA value provided by the network is valid, the UE may perform a RACH-less switch to enable immediate uplink data transmission using configured grants. If no valid TA value is available, the UE 104 may perform a RACH-based switch to acquire the necessary TA for uplink transmission.

[0036] The cell switch completion phase may finalize the mobility process once the UE 104 has successfully transitioned to the target cell and established communication. The UE 104 may send an RRC reconfiguration completion message to the network 102, confirming the successful application of the target cell configuration. The network 102 may also initiate signaling to release resources associated with the previous serving cell, enabling a clean transition. During the completion phase, ongoing data forwarding between the source and target cells may continue, maintaining communication continuity. Both LTM and CLTM may support subsequent mobility operations by maintaining candidate cell configurations, allowing the UE 104 to execute further cell switches without requiring new configurations after each mobility event.

[0037] In LTM or CLTM, the UE 104 may be connected to a source cell and perform a cell switch operation to transition to a target cell. The target cell may be one of the configured candidate cells identified during the preparation phase of the mobility process. The source cell may refer to the cell currently serving the UE 104, which is provided by the base station 108. During the mobility process, the target cell is the cell to which the UE 104 transitions, for example, through a cell switch operation.

[0038] The source and target cells may be managed by the same Central Unit (CU) or by different CUs. A CU is a functional component of a base station, e.g., the base stations 108, 118, or 128, that is responsible for higher-layer operations such as RRC or Packet Data Convergence Protocol (PDCP) . The CU may manage the logical control and coordination of the cells under its domain. Whether the source and target cells are managed by the same CU or by different CUs may influence the signaling complexity and overall operational requirements of the mobility process.

[0039] When both the source and target cells are provided by the same CU, they may either belong to the same base station, such as base station 108, or to different base stations, such as base stations 108 and 118. When the source and target cells are provided by the same CU, the CU acts as a shared logical control entity, coordinating the mobility transition without requiring inter-CU signaling. On the other hand, when the source and target cells are provided by different CUs, the transition may involve additional signaling and coordination. In such cases, the cells may still belong to the same base station, such as base station 108, or to different base stations, such as base stations 108 and 128. The distinction is based on the separation of logical control entities, even if the physical base stations remain the same.

[0040] The involvement of different CUs introduces additional steps in the mobility process, such as the exchange of configuration information, security keys, and synchronization parameters between the managing entities. In contrast, the same CU overseeing both the source and target cells may simplify these operations, as a single logical control entity manages the mobility transition.

[0041] A failure may occur during the mobility process when the UE 104 cannot successfully transition to the target cell. For simplicity, unless explicitly stated otherwise, the term “LTM failure” or “LTM failure recovery” herein refers to both LTM and CLTM failures and their corresponding recovery procedures. LTM failure can arise from several factors, such as signaling issues, radio link failure, or unmet conditions required for the mobility transition. When such a failure occurs, the network or the UE 104 may trigger an LTM failure recovery procedure to ensure continuity of service by selecting an alternative candidate cell and attempting a new cell switch operation.

[0042] In an example scenario, the UE 104 is in an RRC connection with the source cell provided by base station 108. The source cell may send an RRC reconfiguration message to the UE 104, configuring LTM or CLTM and providing details for two candidate cells: candidate cell 1 and candidate cell 2. The UE 104 may receive an LTM cell switch command from the source cell, which indicates the target cell to be candidate cell 1. Upon receiving this command, the UE 104 may start a timer and attempt to perform an LTM cell switch to candidate cell 1. If the UE 104 cannot send an RRC reconfiguration complete message to candidate cell 1 before the timer expires, the UE 104 may detect an LTM failure. In response, the UE 104 may initiate a cell switching operation to candidate cell 2 and, upon successful completion of the procedure, may send an RRC reconfiguration complete message to candidate cell 2, thereby recovering from the failure and establishing a connection with the new target cell.

[0043] Release 18 (R18) Intra-CU LTM failure recovery may specifically address scenarios where the source and target cells are managed by the same CU. In such cases, the recovery mechanism may rely on predefined configurations and procedures to mitigate the impact of LTM failure. For example, upon detecting a failure during the switch to candidate cell 1, the UE 104 may revert to the source cell configuration, except for specific PDCP (Packet Data Convergence Protocol) variables associated with the Signaling Radio Bearer (SRB) . The UE 104 may then initiate a recovery procedure by selecting the next available candidate cell, such as candidate cell 2, and attempting a new cell switch operation. The UE 104 may initiate Contention-Based Random Access (CBRA) -based LTM CS procedure and send an RRC reconfiguration complete message to the network 102 to complete the LTM CS. In this case, the recovery process may involve a CBRA procedure with candidate cell 2, enabling the UE 104 to establish a new connection while maintaining service continuity.

[0044] The recovery procedure described in R18 allows the UE 104 to respond dynamically to failures during the LTM or CLTM process, particularly in scenarios where the source and target cells are managed by the same CU. By allowing the UE 104 to revert to the source cell configuration and attempt a connection with an alternative candidate cell, the procedure mitigates potential disruptions and enhances the reliability of mobility operations.

[0045] In Release 19 (R19) , Inter-CU LTM may enable mobility transitions between a source cell and a target cell managed by different CUs. This distinction introduces additional signaling and coordination requirements between the CU managing the source cell and the CU managing the target cell. The procedure begins with the UE 104 connected to the source cell provided by base station 108. The source cell’s CU may configure the UE 104 with candidate cell information, including details for cells managed by different CUs, such as base stations 118 or 128.

[0046] During the preparation and synchronization phases, early DL and UL synchronization to some LTM candidate cell (s) may be performed. The UE 104 may activate or deactivate TCI states of LTM candidate cell (s) , as triggered by the source base station 108. When execution conditions are satisfied, the CU of base station 108 may signal the UE 104 to perform the cell switch, and the CU of the target cell, such as base station 118 or 128, may facilitate the transition, with additional signaling to update resources and configurations.

[0047] Secure communication between the UE 104 and the network relies on the derivation and use of Access Stratum (AS) keys. The AS keys are cryptographically derived to ensure the confidentiality and integrity of data and signaling between the UE 104 and the base stations, such as base stations 108, 118, or 128. Keys for user plane traffic (KUP) or RRC signaling (KRRC) may be derived from a key of the base station, e.g., KgNB, which itself is generated during the mobility procedure using horizontal or vertical key derivation methods. The key derivation process involves the use of various input parameters, including the Next Hop (NH) parameter, the Next Hop Chaining Counter (NCC) , and a sequence number (COUNT) , which enable secure transitions during mobility. A sequence number (COUNT) is used as input for ciphering and integrity protection, and a given sequence number is only used once for a given key (except for identical re-transmission) on the same radio bearer in the same direction.

[0048] The AS key derivation procedure may differ based on the mobility context. In intra-CU mobility, where the source and target cells are managed by the same CU, the security keys used in the source cell may remain valid for the target cell, avoiding the need for new key derivation. However, for inter-CU mobility, where the target cell is managed by a different CU, the network may explicitly indicate an NCC value in the LTM cell switch command. When the LTM cell switch (CS) is initiated, the network 102 may explicitly indicate the NCC value in LTM CS Command MAC CE. The UE 104 may derive the new AS key based on NCC value and use it for the connection in the target PCell. Using the NCC value as input, the UE 104 may derive a new KgNB, which is then used to generate keys for data transmission and signaling in the target cell.

[0049] In some instances, the security key may be derived using {NH, NCC} pair. When UE and the network 102 need to derive a new KgNB, there are 2 methods –1) vertical derivation in which the base station (e.g., the base stations 108, 118, or 128) may use the NH for deriving KgNB when an unused {NH, NCC} pair is available in the base station; 2) horizontal derivation: when no unused {NH, NCC} pair is available in the base station, the base station may derive KgNB from the current KgNB. Additionally or alternatively, the COUNT sequence number may allow the integrity protection and ciphering processes to remain unique for each radio bearer and direction. This process allows the UE 104 to adapt dynamically to varying network architectures while maintaining secure communication during mobility transitions.

[0050] It is beneficial that the UE 104 and the network 102 can securely derive and apply new AS keys during LTM failure recovery while maintaining seamless communication. It is also beneficial to enhance intra-CU CLTM failure recovery procedures.

[0051] In some embodiments, addressing inter-CU LTM failure recovery may involve mechanisms that do not require the network to provide key information for candidate cells via RRC signaling. Instead, the network 102 may explicitly indicate an NCC value in the LTM cell switch command MAC CE. When LTM CS is initiated, the network 102 may explicitly indicate NCC value in LTM CS Command MAC CE. The UE 104 may derive a new AS key based on NCC value and use it for the connection in the target PCell. This allows the UE 104 to distinguish between intra-CU and inter-CU scenarios based on the NCC value, ensuring secure key derivation and mobility transitions.

[0052] In some embodiments, LTM failure recovery may be limited to intra-CU scenarios. The UE 104 may only perform LTM failure recovery when the selected cell is one of the candidate cells in the same CU as the source cell. The security key used in LTM failure recovery in the selected cell is the same as that used in source PCell. This approach simplifies the recovery process by focusing solely on cells managed by the same CU, avoiding the complexities of inter-CU coordination.

[0053] In other embodiments, LTM failure recovery may support both intra-CU and inter-CU scenarios, enabling greater flexibility in recovery operations. The UE 104 may perform LTM failure recovery when the selected cell is one of the candidate cells that is in the same or different CU as the source cell. For example, the selected cell may be limited to the same CU as the source or target PCell. The security key in the selected cell for recovery may be the same as that used in the source PCell or target PCell (if the NCC value is indicated in LTM CS Command) . Alternatively, the selected cell may belong to any CU, allowing broader recovery options. The security key in the selected cell for recovery may be the same as that used in the source PCell or target PCell (if the NCC value is indicated in LTM CS Command) . From a network perspective, the source gNB may need to inform the NCC value to all the target CUs of the candidate cells.

[0054] In some embodiments, the network 102 may configure specific candidate cells or sets of candidate cells for recovery purposes. The selected cell can be from any candidate cell based on configuration. In one option, the network 102 may provide the security key in the candidate cell RRC configuration. The security key in the selected cell for recovery may be derived from the selected candidate cell’s RRC configuration. In another option, the candidate cells that network 102 configures may be used for recovery. The security key for the recovery in the recovery candidate cell set is derived in some specific way, e.g., by horizontal key derivation or special NCC for recovery. This allows the UE 104 to apply predefined schemes to adapt its recovery operations based on the network’s configurations.

[0055] In some embodiments, these recovery approaches may be combined based on network configurations. The flexibility provided by combining these mechanisms may allow the UE 104 and the network 102 to address LTM failure recovery scenarios across both intra-CU and inter-CU contexts.

[0056] In the description of the following figures, it is assumed that there are three CUs: CU 1, CU 2, and CU 3. CU 1 provides three cells, Cell 1-1, 1-2, and 1-3; CU 2 provides two cells, Cell 2-1 and 2-2; and CU 3 provides one cell, Cell 3.

[0057] FIG. 2 illustrates a signaling diagram 200 in accordance with some embodiments. The signaling diagram 200 is an example of inter-CU LTM with key exchange. The UE 104 is connected with the source base station 108 and is performing inter-CU LTM with the target base station 118. In this embodiment, the source base station 108 may correspond to CU 1, and the target base station 118 may correspond to CU 2.

[0058] At 210, the UE 104 and the source base station 108 may exchange messages to establish an RRC connection. This process may involve the allocation of resources and configuration of connection parameters by the source base station 108, enabling the UE 104 to send and receive control and signaling information.

[0059] At 215, the source base station 108 and the target base station 118 may exchange messages in preparation for the handover operation. The source base station 108 coordinates with the target base station 118 to prepare for the mobility transition. This coordination may involve exchanging configuration details, such as candidate cell information, and ensuring synchronization and resource allocation in the target cell. The preparation may also include agreements on security key updates, enabling the target base station 118 to support the UE 104 during the mobility transition.

[0060] At 220, the source base station 108 may send a configuration message to configure LTM operation at the UE 104. The configuration message may include an indication of candidate cell 1 and candidate cell 2. The configuration message may be an RRC configuration message. The source base station 108 may generate and send an RRC reconfiguration message to the UE 104, providing details of the candidate cells for potential mobility transitions. Candidate cell 1 and candidate cell 2 may be selected based on measurement reports or network planning. The message may include execution conditions tied to Layer 1 or Layer 3 metrics, allowing the UE 104 to prepare for cell switch operations when conditions are satisfied.

[0061] At 225, the UE 104 may perform LTM measurement. The UE 104 may evaluate the candidate cells provided in the configuration message by conducting measurements such as SSB power levels (e.g., reference signal received power (RSRP) ) , CSI-RS quality, or beam-specific measurements. These measurements may be used to assess the suitability of candidate cell 1 or candidate cell 2 as potential target cells for mobility operations.

[0062] At 230, the UE 104 may report the LTM measurement to the source base station 108. The UE 104 may generate and send the measurement results to the source base station 108, including details such as signal strength or beam-specific metrics. The measurement report may enable the source base station 108 to decide on the target cell for the mobility procedure.

[0063] At 235, the source base station 108 may derive KgNB based on the NCC value. The source base station 108 may use the NCC value to derive the KgNB, which serves as the basis for generating the AS keys for secure communication.

[0064] At 240, the source base station 108 may send an LTM cell switch command to the UE 104. The LTM cell switch command may include an indication of the candidate cell 1, the NCC value, or NCC information (e.g., an indication of the NCC value) . The source base station 108 may instruct the UE 104 to perform a cell switch to candidate cell 1. The command may include target configuration details, such as timing advance values, beam identifiers, or the NCC value, which allows the UE 104 to derive the necessary AS keys for secure communication in the target cell.

[0065] At 245, the source base station 108 may send a cell switch notification message to the target base station 118. The cell switch notification message may include an indication of the candidate cell or KgNB. The notification may inform the target base station 118 about the selected candidate cell for the mobility transition and may include the derived KgNB for secure key generation.

[0066] At 250, the UE 104 may derive the AS key based on the NCC value or the NCC information. The NCC value or NCC information provided in the LTM cell switch command may enable the UE 104 to derive the AS key required for secure communication in candidate cell 1.

[0067] At 255, the UE 104 may establish a connection with the target base station 118 using the derived AS key. After deriving the AS key, the UE 104 may establish a secure connection with candidate cell 1, managed by the target base station 118. The secure connection may allow the UE 104 to resume communication in the new cell without interruption.

[0068] At 260, the target base station 118 may send the HO success message to the source base station 108. The target base station 118 may confirm the success of the handover operation by sending a handover success message to the source base station 108.

[0069] At 265, the source base station 108 may send a sequence number (SN) status transfer message to the target base station 118. The SN status transfer may provide continuity in user plane data transmission by providing the target base station 118 with information about the PDCP sequence numbers of packets already processed or still in transit. This may prevent data loss or duplication during the mobility transition.

[0070] In some embodiments, the UE 104 may determine the CU associated with a base station, e.g., base stations 108, 118, or 128, from a security key change identifier (ID) associated with that base station. The security key change ID allows the UE 104 to track whether a security key update has occurred during procedures like handover, LTM, or failure recovery. It allows the UE 104 and the network 102 to be synchronized on the current security context. In some instances, the security key change ID may be tied to NH, or NCC that are used to derive encryption kyes such as KeNB or KgNB.

[0071] The UE 104 may determine that two base stations are managed by the same CU by comparing their Security Key Change IDs, which reflect the security context tied to the NH chaining mechanism or the NCC. When both base stations (e.g., the base stations 108 and 118) are under the same CU, the CU may centrally control the NH key derivation process, ensuring consistent NH and NCC values across handovers or connections within its domain. By analyzing the Security Key Change IDs derived from the two base stations, the UE 104 can infer that the base stations share the same CU if the IDs align, or that they are managed by different CUs if the IDs differ. This comparison may provide the UE 104 with an indirect method to identify CU associations based on the NH chaining state embedded in the Security Key Change ID.

[0072] FIG. 3 illustrates another signaling diagram 300 in accordance with some embodiments. Signaling diagram 300 is an example of LTM recovery operation and illustrates the signaling among the UE 104, the source base station 108 providing CU 1 and Cells 1-1, 1-2, and 1-3, and the target base station 118 providing CU 2 and Cells 2-1 and 2-2.

[0073] At 310, the UE 104 and the source base station 108 may exchange messages to establish an RRC connection between the UE 104 and Cell 1-1 provided by CU 1 and the base station 108. This process may involve the allocation of resources and configuration of connection parameters by the source base station 108, enabling the UE 104 to send and receive control and signaling information.

[0074] At 320, the source base station 108 may send a configuration message to configure LTM operation at the UE 104. The configuration message may include an indication of candidate cells: Cell 1-1, 1-2, 1-3, 2-1, 2-2, and 3. The configuration message may be an RRC configuration message. The source base station 108 may generate and send an RRC reconfiguration message to the UE 104, providing details of the candidate cells for potential mobility transitions. Candidate cells may be selected based on measurement reports or network planning. The message may include execution conditions tied to Layer 1 (L1) or Layer 3 (L3) metrics, allowing the UE 104 to prepare for cell switch operations when conditions are satisfied.

[0075] At 335, the source base station 108 may derive KgNB based on the NCC value. The source base station 108 may use the NCC value to derive the KgNB, which serves as the basis for generating the AS keys for secure communication. The source base station 108 may initiate the LTM execution phase to target Cell 2-2.

[0076] At 340, the source base station 108 may send an LTM cell switch command to the UE 104. The LTM cell switch command may include an indication of the candidate Cell 2-1, the NCC value, NCC information (e.g., an indication of the NCC value) . The source base station 108 may instruct the UE 104 to perform a cell switch to candidate cell 2-1. The command may include target configuration details, such as timing advance values, beam identifiers, or the NCC value, which allows the UE 104 to derive the necessary AS keys for secure communication in the target cell.

[0077] At 345, the source base station 108 may send a cell switch notification message to the target base station 118. The cell switch notification message may include an indication of the candidate cell 2-1 or KgNB. The notification may inform the target base station 118 about the selected candidate cell 2-1 for the mobility transition and may include the derived KgNB for secure key generation.

[0078] At 350, the UE 104 may apply the target Cell 2-1 configuration. The UE 104 may also derive the AS key or KgNB based on the indicated NCC value or NCC information.

[0079] At 355, the UE 104 may attempt accessing target Cell 2-1 using the derived AS key. The UE 104 may send a random access preamble or other access signaling to the target base station 118, but the connection establishment may fail. The failure may be due to reasons such as radio link issues, synchronization problems, or resource unavailability in the target Cell 2-1.

[0080] At 360, the UE 104 may detect an LTM failure. The UE 104 may detect an LTM failure based on the expiration of a timer, which may be, for example, a T304 timer. The UE 104 may revert back to the source Cell 1-1 configuration, except SRB’s PDCP variable.

[0081] Two cases are considered for the LTM recovery procedure.

[0082] In Case 1, at 365, the UE 104 may perform the LTM recovery procedure by selecting Cell 1-2 provided by CU 1 and source base station 108 and initiate connection establishment with it. The UE 104 identifies Cell 1-2 as a valid candidate cell within the same CU as the source cell. The connection establishment process with Cell 1-2 may involve sending a random access preamble, receiving a response, and completing the RRC connection procedure. This recovery approach leverages the proximity and shared CU between the source Cell 1-1 and Cell 1-2 to ensure a simpler and more reliable recovery.

[0083] In Case 2, at 370, the UE 104 may initiate the connection reestablishment procedure with target Cell 2-1. The UE 104 may attempt to reestablish the connection with the target Cell 2-1 provided by CU 2 and target base station 118. This procedure may involve the UE 104 signaling its identity and context information to the target base station 118, followed by the target base station allocating new resources and reconfiguring the UE 104. In this case, the recovery process requires inter-CU coordination to ensure that the security keys and configuration parameters are correctly updated. The UE 104 may reuse the key derived at 350.

[0084] The signaling 300 is an example in which the UE 104 may prefer connection with intra-CU candidate cells in the LTM failure recovery operation. In some embodiments, LTM failure recovery may be limited to intra-CU scenarios, where UE only performs LTM failure recovery when the selected cell is one of the candidate cells in the same CU as the source cell (e.g., Cell 1-1) . The security key used in the recovery process may remain unchanged, allowing the security key used in LTM failure recovery to be the same as that used in source PCell in the selected cell. This simplifies the recovery operation by avoiding additional cryptographic processing for key derivation. The UE 104 may evaluate the candidate cells provided in the LTM configuration message, and if the selected cell is one of the LTM candidate cells that belong to the same CU of the source cell, UE may perform the LTM failure recovery, and the behavior may be similar as R18 behavior.

[0085] In some embodiments, when the selected cell does not belong to the same CU as the source cell, the UE 104 may perform the UE Connection Reestablishment procedure. In this scenario, the UE 104 may initiate signaling interactions with the target CU to update security keys and configuration parameters required for connection reestablishment.

[0086] FIG. 4 illustrates another signaling diagram 400 in accordance with some embodiments. Signaling diagram 400 is an example of LTM recovery operation and illustrates the signaling among the UE 104, the source base station 108 providing CU 1 and Cells 1-1, 1-2, and 1-3, the target base station 118 providing CU 2 and Cells 2-1 and 2-2, and the target base station 128 providing CU 3 and Cell 3.

[0087] At 410, 420, 435, 440, 445, 450, 455, 460, and 465, operations similar to those described at 310, 320, 335, 340, 345, 350, 355, 360, and 365, respectively, described in FIG. 3 may be performed.

[0088] In Case 2, at 470, Ithe UE 104 may perform an LTM recovery procedure with target base station 118 (e.g., Cell 2-1 or Cell 2-2) using a new AS key (e.g., the AS key derived at 450) . In some embodiments, the LTM recovery procedure with the new AS key may be applicable when the selected cell includes specific configurations provided by the network 102, such as key derivation settings. For example, the target base station 118, at 445, has received the AS key, e.g., KgNB. The selected cell can be from the candidate cell, where the network 102 provides the security key in the candidate cell RRC configuration. The security key in the selected cell for recovery may be derived from the selected candidate cell’s RRC configuration. The network 102 can provide the master key update in the candidate cell configuration. The UE 104 may utilize the master key update provided in the candidate cell configuration to derive the new AS key required for LTM recovery. When the selected cell’s cell reconfiguration message has the master key update configuration, the UE 104 may derive the key based on the RRC configuration and perform LTM recovery there. This procedure ensures secure communication and allows the UE 104 to recover from LTM failure by leveraging predefined RRC configurations and cryptographic updates specific to the selected cell.

[0089] In Case 3, at 475, the UE 104 may perform one of the following options. In option 1, the UE 104 may perform a connection reestablishment procedure. In some embodiments, this option may be applicable when the selected cell is not part of the same CU as the source PCell. When the selected cell is in the same CU as the source PCell, the UE 104 may perform the legacy LTM recovery procedure (no security key change) . When a selected cell is in a different CU from the source PCell, the UE 104 may perform the LTM recovery using the new security key derived by the NCC value indicated in LTM CS Command. The network 102 may provide an NCC value or an NCC information (e.g., an indication of the NCC value) in the LTM cell switch command, enabling the UE 104 to derive a new security key for communication with the selected cell. The source base station 108 may inform NCC value to all the target CUs of the candidate cells. The source base station 108 may send information associated with the NCC value to all the target CUs of the candidate cell. The connection reestablishment procedure may involve signaling interactions between the UE 104 and the target CU to update security contexts, allocate resources, and establish secure communication in the selected cell.

[0090] In option 2, the UE 104 may perform an LTM recovery procedure with a new AS key. In some embodiments, this option may be applicable when the selected cell includes specific configurations provided by the network 102, such as key derivation settings. The selected cell can be from the candidate cell where the network 102 provides the security key in the candidate cell RRC configuration. The security key in the selected cell for recovery may be derived from the selected candidate cell’s RRC configuration. The network 102 can provide the master key update in the candidate cell configuration. The UE 104 may utilize the master key update provided in the candidate cell configuration to derive the new AS key required for LTM recovery. When the selected cell’s cell reconfiguration message has the master key update configuration, the UE 104 may derive the key based on the RRC configuration and perform LTM recovery there. This procedure ensures secure communication and allows the UE 104 to recover from LTM failure by leveraging predefined RRC configurations and cryptographic updates specific to the selected cell.

[0091] In some embodiments, at 480, the source base station 108 may send a notification to target base station 128. The notification may include one or more candidate cell for LTM or LTM recovery procedures. The notification may include an indication of a parameter that can be used to derive security key. The parameter may be an indication of an NCC information, or KgNB.

[0092] In some embodiments, R19 CLTM may only support intra-CU CLTM procedures. This limitation ensures that the conditional mobility process is confined to candidate cells managed by the same CU as the source cell, simplifying coordination and signaling requirements during mobility transitions.

[0093] In some embodiments, R19 CLTM recovery procedures may use the R18 intra-CU LTM recovery procedure as a baseline. The recovery process does not involve security key updates, allowing the UE 104 to revert to the source cell configuration or select a candidate cell without requiring cryptographic processing for key derivation. This approach leverages the reliability of existing R18 mechanisms while maintaining simplicity in recovery operations.

[0094] In some embodiments, enhancements to CLTM recovery may include support for CFRA procedures under specific conditions. For instance, a CFRA-based procedure may be supported for CLTM recovery if a CFRA configuration is provided in the candidate cell configuration, and a beam associated with the indicated UE dedicated RACH resource is good (for example, has a quality above a predetermined threshold) . These conditions may enable the UE 104 to utilize dedicated resources for initial access and ensure high-quality communication during the recovery process.

[0095] In some embodiments, if the conditions for CFRA recovery are not met, the UE 104 may perform CBRA-based CLTM recovery procedures. This alternative allows the UE 104 to initiate random access using shared resources, ensuring recovery even in cases where dedicated resources are unavailable or unsuitable. By combining CFRA and CBRA recovery options, the network 102 and the UE 104 can adapt to varying conditions while maintaining communication continuity during CLTM operations.

[0096] FIG. 5 illustrates an operation flow / algorithmic structure 500 in accordance with some embodiments. The operation flow / algorithmic structure 500 may be performed or implemented by a UE such as, for example, the UE 104 or UE 800; or components thereof, for example, baseband processor circuitry 804A.

[0097] The operation flow / algorithmic structure 500, which may also be referred to simply as “operation 500, ” may include, at 510, identifying support only for an intra-CU LTM failure recovery operation. Operation 500 may identify that support only for an intra-CU LTM failure recovery operation is available. UE only performs LTM failure recovery when the selected cell is one of the candidate cells in the same CU as the source cell. This may ensure that the recovery process is confined to scenarios where both the source cell and the candidate cell are managed by the same CU. Operation 500 may further evaluate the configurations of candidate cells provided in the RRC reconfiguration message to verify that the recovery procedure can be executed within the same CU.

[0098] The operation flow / algorithmic structure 500 may include, at 520, detecting a failure of an operation. Operation 500 may detect a failure of an operation, such as a cell switch from a source PCell to a target candidate cell. The failure may be detected based on conditions such as the expiration of a timer or the inability of the UE 104 to establish communication with the target cell. Operation 500 may also detect issues such as poor signal quality or resource unavailability in the target cell, contributing to the failure. Upon detecting the failure, operation 500 may prepare to initiate a recovery procedure to maintain service continuity.

[0099] The operation flow / algorithmic structure 500 may include, at 530, determining a candidate cell in the same CU as the source cell. Operation 500 may determine a candidate cell for recovery, selecting a cell that belongs to the same CU as the source cell. If the selected cell is one of the LTM candidate cells that belong to the same CU as the source cell, the UE 104 may perform the LTM failure recovery. This determination may involve evaluating candidate cells identified during the preparation phase of the mobility operation and selecting the most suitable cell based on predefined conditions or metrics. Operation 500 may also confirm that the selected candidate cell satisfies execution conditions tied to L1 or L3 measurements, ensuring compatibility with the recovery procedure.

[0100] In some embodiments, operation 500 may further include determining that the operation is a conditional LTM operation or an LTM operation. In some embodiments, the failure recovery procedure may apply to both conditional and non-conditional LTM operations. For CLTM, operation 500 may rely on specific execution conditions to trigger the recovery. Operation 500 may also evaluate whether the mobility context involves proactive synchronization with candidate cells or conditions tied to signal quality thresholds.

[0101] In some embodiments, when the operation is a conditional LTM operation, the intra-CU LTM failure recovery operation may include identifying a CFRA configuration, determining that a channel quality associated with the CFRA configuration meets or exceeds a threshold, and performing a CFRA procedure.

[0102] In some embodiments, the recovery procedure for CLTM may support a CFRA-based mechanism under certain conditions. For CLTM recovery, operation 500 may support CFRA-based procedure when the CFRA configuration is provided in the candidate cell configuration and the beam associated with the indicated UE dedicated RACH resource has a quality that meets or exceeds a threshold. Operation 500 may evaluate the CFRA configuration provided in the candidate cell’s reconfiguration message and determine whether the associated channel quality meets or exceeds a predefined threshold. If these conditions are satisfied, operation 500 may proceed with a CFRA procedure to recover from the failure. Operation 500 may also confirm that the CFRA resources are properly allocated and accessible.

[0103] In some embodiments, when the operation is a conditional LTM operation, the intra-CU LTM failure recovery operation may include determining that a CFRA is not configured or that a channel quality associated with a CFRA configuration is less than a threshold and performing a CBRA procedure.

[0104] In some embodiments, if the conditions for CFRA are not met, such as when no CFRA configuration is provided, or the associated channel quality falls below the threshold, operation 500 may fall back to a CBRA-based recovery mechanism. If the condition is not met, UE performs a CBRA-based CLTM recovery procedure. This alternative ensures that operation 500 can initiate recovery even when dedicated resources are unavailable or unsuitable, leveraging shared random access resources for recovery. Operation 500 may also verify that the CBRA procedure adheres to predefined network configurations.

[0105] The operation flow / algorithmic structure 500 may include, at 540, performing the intra-CU LTM failure recovery based on the security key of the source cell. Operation 500 may perform the intra-CU LTM failure recovery using the security key of the source PCell. The security key used in LTM failure recovery is the same as that used in source PCell in the selected cell. By maintaining the same security key, Operation 500 avoids the need for additional cryptographic processing, simplifies the recovery operation, and ensures a seamless transition to the candidate cell. Operation 500 may also verify the integrity of the security key during the recovery process.

[0106] FIG. 6 illustrates an operation flow / algorithmic structure 600 in accordance with some embodiments. The operation flow / algorithmic structure 600 may be performed or implemented by a UE such as, for example, the UE 104 or UE 800; or components thereof, for example, baseband processor circuitry 804A.

[0107] The operation flow / algorithmic structure 600, which may also be referred to simply as “operation 600, ” may include, at 610, detecting a failure of LTM operation. Operation 600 may detect a failure of an LTM operation, wherein the operation involves a cell change from a source PCell provided by a CU to a first target cell. When the selected cell is in the same CU as the source PCell, UE performs a legacy LTM recovery procedure (no security key change) . When the selected cell is in the same CU as target PCell, UE 104 may perform the LTM recovery using the new security key derived by the NCC value indicated in LTM CS Command. The failure may be detected based on conditions such as the expiration of a timer, poor signal quality, or the inability to establish communication with the first target cell. Operation 600 may also evaluate the operational context, including the CU managing the source PCell and the first target cell, to determine whether the failure is associated with intra-CU or inter-CU mobility.

[0108] The operation flow / algorithmic structure 600 may include, at 620, selecting a target cell. Operation 600 may select a second target cell for recovery following the detection of an LTM failure. The selected cell is limited in the same CU as the source or target PCell. If the second target cell is managed by the same CU as the source PCell, operation 600 may proceed with intra-CU recovery procedures. In scenarios where the second target cell is managed by a different CU, operation 600 may evaluate the relationship between the first and second CUs. When the selected cell is in the different CU as source / target PCell, UE performs the RRC Connection Reestablishment procedure. Operation 600 may also ensure that the second target cell satisfies predefined execution conditions tied to L1 or L3 metrics.

[0109] The operation flow / algorithmic structure 600 may include, at 630, deriving a security key. Operation 600 may derive a security key based on the context of the selected second target cell. If the second target cell belongs to the same CU as the source PCell, the security key in the selected cell for recovery is the same as that used in the source PCell or target PCell (if the NCC value is indicated in LTM CS Command) . For inter-CU scenarios, operation 600 may derive the security key using the NCC value provided in the LTM cell switch command. When a selected cell is in a different CU from the source PCell, the UE 104 may perform the LTM recovery using the new security key derived by the NCC value indicated in LTM CS Command. The network 102 operation may include source base station 108 to inform NCC value to all the target CUs of the candidate cells.

[0110] In some embodiments, operation 600 may further include determining that the CU managing the second target cell is different from the CU managing the first target cell. If the selected second target cell is managed by a CU different from the CU of the first target cell and the source PCell, operation 600 may initiate inter-CU procedures to establish communication. When the selected cell is in a different CU as the source / target PCell, the UE 104 may perform the RRC Connection Reestablishment procedure. Operation 600 may evaluate the relationship among the source CU, the CU managing the first target cell, and the CU managing the second target cell, ensuring that the recovery process accounts for differences in security contexts and signaling requirements.

[0111] The operation flow / algorithmic structure 600 may include, at 640, performing the LTM failure recovery. Operation 600 may perform the LTM failure recovery procedure using the derived security key. The security key in the selected cell for recovery may be the same as that in the source PCell or target PCell (calculated based on indicated NCC) . If the second target cell belongs to the same CU as the source PCell, operation 600 may rely on the existing security key of the source PCell to simplify the recovery. For inter-CU scenarios, operation 600 may use the derived security key to establish communication with the selected second target cell.

[0112] FIG. 7 illustrates an operation flow / algorithmic structure 700 in accordance with some embodiments. The operation flow / algorithmic structure 700 may be performed or implemented by a UE such as, for example, the UE 104 or UE 800; or components thereof, for example, baseband processor circuitry 804A.

[0113] The operation flow / algorithmic structure 700, which may also be referred to simply as “operation 700, ” may include, at 710, Detecting an LTM failure. Operation 700 may detect an LTM failure during a mobility operation involving a cell switch from a source PCell to a first target cell. The failure may occur due to the expiration of a timer, poor signal quality, or the inability of the UE to establish communication with the first target cell. In some examples, when the selected cell is in the same CU as the source PCell, the UE 104 may perform a legacy LTM recovery procedure (no security key change) . If the first target cell fails to meet the conditions necessary for successful communication, operation 700 may prepare to initiate a recovery procedure by selecting an alternative candidate cell for mobility.

[0114] The operation flow / algorithmic structure 700 may include, at 720, processing a configuration including the master key update parameter. Operation 700 may process the configuration details of a second target cell that includes a master key update parameter. The selected cell can be from the candidate cell, where the network 102 provides the security key in the candidate cell RRC config. The network 102 can provide the master key update in the candidate cell configuration. The master key update parameter may be part of the candidate cell’s RRC configuration, enabling the UE to derive a new security key for secure communication. Operation 700 may also evaluate whether the second target cell satisfies additional network-defined conditions, ensuring it is suitable for the recovery procedure.

[0115] The operation flow / algorithmic structure 700 may include, at 730, selecting a target cell for the LTM failure recovery procedure. Operation 700 may select the second target cell for recovery following the detection of an LTM failure with the first target cell. The selection process may prioritize candidate cells that include a master key update parameter or other relevant configurations. When the selected cell’s cell reconfiguration has the master key update configuration, UE 104 may derive the key based on the RRC configuration and perform LTM recovery there.

[0116] The operation flow / algorithmic structure 700 may include, at 740, deriving a security key. Operation 700 may derive a security key for communication with the second target cell by processing the master key update parameter included in the candidate cell configuration. The security key in a selected cell for recovery may be derived from the selected candidate cell’s RRC configuration. Alternatively, the security key may be derived using other configuration details provided in the candidate cell’s RRC message.

[0117] The operation flow / algorithmic structure 700 may include, at 750, performing the LTM failure recovery procedure. Operation 700 may perform the LTM failure recovery procedure with the second target cell, utilizing the derived security key for secure communication. If the second target cell and the source PCell are managed by the same CU, when a selected cell is in the same CU as the source PCell, the UE 104 may perform a legacy LTM recovery procedure (no security key change) . For inter-CU scenarios, the security key derived from the master key update parameter or the RRC configuration ensures the integrity and confidentiality of the communication during recovery.

[0118] FIG. 8 illustrates a UE 800 in accordance with some embodiments. The UE 800 may be similar to and substantially interchangeable with the UE 104.

[0119] The UE 800 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, inventory sensors, electric voltage / current meters, or actuators) , video surveillance / monitoring devices (for example, cameras or video cameras) , wearable devices (for example, a smartwatch) , or Internet-of-things devices.

[0120] The UE 800 may include processors 804, RF interface circuitry 808, memory / storage 812, user interface 816, sensors 820, driver circuitry 822, power management integrated circuit (PMIC) 824, antenna 826, and battery 828. The components of the UE 800 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 8 is intended to show a high-level view of some of the components of the UE 800. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0121] The components of the UE 800 may be coupled with various other components over one or more interconnects 832, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, or optical connection that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0122] The processors 804 may include processor circuitry such as, for example, baseband processor circuitry (BB) 804A, central processor unit circuitry (CPU) 804B, and graphics processor unit circuitry (GPU) 804C. The processors 804 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 812 to cause the UE 800 to perform operations as described herein. The processors 804 may also include interface circuitry 804D to communicatively couple the processor circuitry with one or more other components of the UE 800.

[0123] In some embodiments, the baseband processor circuitry 804A may access a communication protocol stack 836 in the memory / storage 812 to communicate over a 3GPP-compatible network. In general, the baseband processor circuitry 804A may access the communication protocol stack 836 to: perform user plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a NAS layer. In some embodiments, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 808.

[0124] The baseband processor circuitry 804A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some embodiments, the waveforms for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0125] The memory / storage 812 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 836) that may be executed by one or more of the processors 804 to cause the UE 800 to perform various operations described herein.

[0126] The memory / storage 812 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 800. In some embodiments, some of the memory / storage 812 may be located on the processors 804 themselves (for example, memory / storage 812 may be part of a chipset that corresponds to the baseband processor circuitry 804A) , while other memory / storage 812 is external to the processors 804 but accessible thereto via a memory interface. The memory / storage 812 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read only memory (EPROM) , electrically erasable programmable read only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0127] The RF interface circuitry 808 may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE 800 to communicate with other devices over a radio access network. The RF interface circuitry 808 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, and control circuitry.

[0128] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna 826 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that down-converts the RF signal into a baseband signal that is provided to the baseband processor of the processors 804.

[0129] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna 826.

[0130] In various embodiments, the RF interface circuitry 808 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0131] The antenna 826 may include antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna 826 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna 826 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, or phased array antennas. The antenna 826 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0132] The user interface 816 includes various input / output (I / O) devices designed to enable user interaction with the UE 800. The user interface 816 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes (LEDs) and multi-character visual outputs, or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays (LCDs) , LED displays, quantum dot displays, and projectors) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 800.

[0133] The sensors 820 may include devices, modules, or subsystems whose purpose is to detect events or changes in their environment and send the information (sensor data) about the detected events to some other device, module, or subsystem. Examples of such sensors include inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other like audio capture devices.

[0134] The driver circuitry 822 may include software and hardware elements that operate to control particular devices that are embedded in the UE 800, attached to the UE 800, or otherwise communicatively coupled with the UE 800. The driver circuitry 822 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within or connected to the UE 800. For example, driver circuitry 822 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 820, and control and allow access to sensors 820, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0135] The PMIC 824 may manage power provided to various components of the UE 800. In particular, with respect to the processors 804, the PMIC 824 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0136] A battery 828 may power the UE 800, although in some examples, the UE 800 may be mounted deployed in a fixed location and may have a power supply coupled to an electrical grid. The battery 828 may be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 828 may be a typical lead-acid automotive battery.

[0137] FIG. 9 illustrates a network device 900 in accordance with some embodiments. The network device 900 may be similar to and substantially interchangeable with base station 108.

[0138] The network device 900 may include processors 904, RF interface circuitry 908 (if implemented as a base station) , core network (CN) interface circuitry 914, memory / storage circuitry 912, and antenna structure 926.

[0139] The components of the network device 900 may be coupled with various other components over one or more interconnects 928.

[0140] The processors 904, RF interface circuitry 908, memory / storage circuitry 912 (including communication protocol stack 910) , antenna structure 926, and interconnects 928 may be similar to like-named elements shown and described with respect to FIG. 8.

[0141] The processors 904 may include processor circuitry such as, for example, baseband processor circuitry (BB) 904A, central processor unit circuitry (CPU) 904B, and graphics processor unit circuitry (GPU) 904C. The processors 904 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage circuitry 912 to cause the UE 800 to perform operations as described herein. The processors 904 may also include interface circuitry 904D to communicatively couple the processor circuitry with one or more other components of the network device 900.

[0142] The CN interface circuitry 914 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols or some other suitable protocol. Network connectivity may be provided to / from the network device 900 via a fiber optic or wireless backhaul. The CN interface circuitry 914 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 914 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0143] It is well understood that the use of personally identifiable information should follow privacy policies and practices generally recognized as meeting or exceeding industry or governmental requirements for maintaining users’ privacy. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0144] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry described above in connection with one or more of the preceding figures may be configured to operate according to one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, or network element described above in connection with one or more of the preceding figures may be configured to operate according to one or more of the examples set forth below in the example section.EXAMPLES

[0145] In the following sections, further exemplary embodiments are provided.

[0146] Example 1 includes a method including: identifying support only for an intra-central unit (CU) lower-layer triggered mobility (LTM) failure recovery operation; detecting a failure of an operation, wherein the operation includes a cell switch from a source cell to a target cell, wherein the source cell is provided by a central unit (CU) ; in response to said detecting the failure, selecting a candidate cell for recovering the failure based on a security key change identifier (ID) of the source cell; and performing the intra-CU LTM failure recovery operation based on a security key of the source cell.

[0147] Example 2 includes the method of example 1 or some other examples herein, wherein said selecting the candidate cell for recovering the failure based on the security key change ID of the source cell includes: determining, based on the security key change ID of the source cell and a security key change ID of the target cell, that the source cell and the target cell are provided by the CU; and selecting the target cell based on said determining that the source cell and the target cell are provided by the CU.

[0148] Example 3 includes the method of example 1 or some other examples herein, wherein the operation is a conditional LTM operation or an LTM operation.

[0149] Example 4 includes the method of example 3 or some other examples herein, wherein the operation is a conditional LTM operation, and the intra-CU LTM failure recovery operation includes: identifying a contention free random access (CFRA) configuration; determining that a channel quality associated the CFRA configuration meets or exceeds a threshold; and performing a CFRA procedure in the target cell.

[0150] Example 5 includes the method of example 3 or some other examples herein, wherein the operation is a conditional LTM operation, and the intra-CU LTM failure recovery operation includes: determining that a contention free random access (CFRA) is not configurated or a channel quality associated a CFRA configuration is not greater than a threshold; and performing a contention based random access (CBRA) procedure.

[0151] Example 6 includes a method including: detecting a failure of a lower-layer triggered mobility (LTM) operation, wherein the LTM operation includes a cell switch from a source cell to a first target cell, wherein the first target cell is provided by a central unit (CU) ; selecting a second target cell for an LTM failure recovery procedure; and deriving a security key based on whether the second target cell is provided by the CU.

[0152] Example 7 includes the method of example 6 or some other examples herein, further including: processing an LTM cell switch command that includes a next hop chaining counter (NCC) information.

[0153] Example 8 includes the method of example 7 or some other examples herein, wherein said deriving the security key is further based the NCC information.

[0154] Example 9 includes the method of example 6 or some other examples herein, wherein the second target cell is provided by the CU and the security key is used in the source cell.

[0155] Example 10 includes the method of example 6 or some other examples herein, further including: determining that the first target cell and the second target cell are provided by the CU; identifying a parameter in an LTM cell switch command associated with the first target cell, wherein said deriving the security key includes deriving the security key based on the parameter; and performing the LTM failure recovery procedure with the second target cell using the security key.

[0156] Example 11 includes the method of example 6 or some other examples herein, wherein the parameter is associated with next hop chaining counter (NCC) information.

[0157] Example 12 includes the method of example 6 or some other examples herein, wherein the CU is a first CU and the method further includes: determining that a second CU associated with the second target cell is different from the first CU; determining that the second CU is different from a third CU associated with the source cell; and performing a radio resource control (RRC) connection reestablishment procedure with the second target cell.

[0158] Example 13 includes the method of example 12 or some other examples herein, wherein said deriving the security key includes: deriving the security key based on the RRC connection reestablishment procedure.

[0159] Example 14 includes the method of example 6 or some other examples herein, wherein the CU is a first CU and the method further includes: determining that a second CU associated with the second target cell is different from the first CU; determining that the second CU is different from a third CU associated with the first target cell; and performing the LTM failure recovery procedure with the second target cell using the security key.

[0160] Example 15 includes the method of example 14 or some other examples herein, further includes: processing an LTM cell switch command, including a next hop chaining counter (NCC) information.

[0161] Example 16 includes the method of example 15 or some other examples herein, wherein said deriving the security key is further based the NCC information.

[0162] Example 17 includes a method including: detecting a lower-layer triggered mobility (LTM) failure with a first target cell; processing a configuration of a second target cell including a master key update parameter; selecting the second target cell for an LTM failure recovery procedure based on said detecting the LTM failure with the first target cell; deriving a security key based on the master key update parameter or a radio resource control (RRC) configuration of the second target cell; and performing the LTM failure recovery procedure with the second target cell using the security key.

[0163] Example 18 includes the method of example 17 or some other examples herein further including: determining that the second target cell and a source cell are provided by a central unit (CU) , wherein the LTM failure recovery procedure with the second target cell is without a security key exchange based on said determining that the second target cell and the source cell are provided by the CU.

[0164] Example 19 includes the method of example 17 or some other examples herein, wherein said deriving the security key for the LTM failure recovery procedure is based on the RRC configuration.

[0165] Example 20 includes the method of example 17 or some other examples herein, wherein said deriving the security key for the LTM failure recovery procedure is based on the master key update parameter.

[0166] Another example may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1–13, or any other method or process described herein.

[0167] Another example may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1–20, or any other method or process described herein.

[0168] Another example may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1–20, or any other method or process described herein.

[0169] Another example may include a method, technique, or process as described in or related to any of examples 1–20, or portions or parts thereof.

[0170] Another example may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–20, or portions thereof.

[0171] Another example may include a signal as described in or related to any of examples 1–20, or portions or parts thereof.

[0172] Another example may include a datagram, information element, packet, frame, segment, PDU, or message as described in or related to any of examples 1–20, or portions or parts thereof, or otherwise described in the present disclosure.

[0173] Another example may include a signal encoded with data as described in or related to any of examples 1–20, or portions or parts thereof, or otherwise described in the present disclosure.

[0174] Another example may include a signal encoded with a datagram, IE, packet, frame, segment, PDU, or message as described in or related to any of examples 1–20, or portions or parts thereof, or otherwise described in the present disclosure.

[0175] Another example may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1–20, or portions thereof.

[0176] Another example may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1–20, or portions thereof.

[0177] Another example may include a signal in a wireless network as shown and described herein.

[0178] Another example may include a method of communicating in a wireless network, as shown and described herein.

[0179] Another example may include a system for providing wireless communication, as shown and described herein.

[0180] Another example may include a device for providing wireless communication, as shown and described herein.

[0181] Unless explicitly stated otherwise, any of the above-described examples may be combined with any other example (or combination of examples) . The foregoing description of one or more implementations provides illustration and description but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from the practice of various embodiments.

[0182] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method comprising:identifying support only for an intra-central unit (CU) lower-layer triggered mobility (LTM) failure recovery operation;detecting a failure of an operation, wherein the operation includes a cell switch from a source cell to a target cell, wherein the source cell is provided by a central unit (CU) ;in response to said detecting the failure, selecting a candidate cell for recovering the failure based on a security key change identifier (ID) of the source cell; andperforming the intra-CU LTM failure recovery operation based on a security key of the source cell.2.The method of claim 1, wherein said selecting the candidate cell for recovering the failure based on the security key change ID of the source cell comprises:determining, based on the security key change ID of the source cell and a security key change ID of the target cell, that the source cell and the target cell are provided by the CU; andselecting the target cell based on said determining that the source cell and the target cell are provided by the CU.3.The method of claim 1, wherein the operation is a conditional LTM operation or an LTM operation.4.The method of claim 3, wherein the operation is a conditional LTM operation, and the intra-CU LTM failure recovery operation comprises:identifying a contention free random access (CFRA) configuration;determining that a channel quality associated the CFRA configuration meets or exceeds a threshold; andperforming a CFRA procedure in the target cell.5.The method of claim 3, wherein the operation is a conditional LTM operation, and the intra-CU LTM failure recovery operation comprises:determining that a contention free random access (CFRA) is not configurated or a channel quality associated a CFRA configuration is not greater than a threshold; andperforming a contention based random access (CBRA) procedure.6.A method comprising:detecting a failure of a lower-layer triggered mobility (LTM) operation, wherein the LTM operation includes a cell switch from a source cell to a first target cell, wherein the first target cell is provided by a central unit (CU) ;selecting a second target cell for an LTM failure recovery procedure; andderiving a security key based on whether the second target cell is provided by the CU.7.The method of claim 6, further comprising:processing an LTM cell switch command that includes a next hop chaining counter (NCC) information.8.The method of claim 7, wherein said deriving the security key is further based the NCC information.9.The method of claim 6, wherein the second target cell is provided by the CU and the security key is used in the source cell.10.The method of claim 6, further comprising:determining that the first target cell and the second target cell are provided by the CU;identifying a parameter in an LTM cell switch command associated with the first target cell, wherein said deriving the security key includes deriving the security key based on the parameter; andperforming the LTM failure recovery procedure with the second target cell using the security key.11.The method of claim 6, wherein the parameter is associated with next hop chaining counter (NCC) information.12.The method of claim 6, wherein the CU is a first CU and the method further comprises:determining that a second CU associated with the second target cell is different from the first CU;determining that the second CU is different from a third CU associated with the source cell; andperforming a radio resource control (RRC) connection reestablishment procedure with the second target cell.13.The method of claim 12, wherein said deriving the security key comprises:deriving the security key based on the RRC connection reestablishment procedure.14.The method of claim 6, wherein the CU is a first CU and the method further comprises:determining that a second CU associated with the second target cell is different from the first CU;determining that the second CU is different from a third CU associated with the first target cell; andperforming the LTM failure recovery procedure with the second target cell using the security key.15.The method of claim 14, further comprises:processing an LTM cell switch command, including a next hop chaining counter (NCC) information.16.The method of claim 15, wherein said deriving the security key is further based the NCC information.17.A method comprising:detecting a lower-layer triggered mobility (LTM) failure with a first target cell;processing a configuration of a second target cell including a master key update parameter;selecting the second target cell for an LTM failure recovery procedure based on said detecting the LTM failure with the first target cell;deriving a security key based on the master key update parameter or a radio resource control (RRC) configuration of the second target cell; andperforming the LTM failure recovery procedure with the second target cell using the security key.18.The method of claim 17 further comprising:determining that the second target cell and a source cell are provided by a central unit (CU) , wherein the LTM failure recovery procedure with the second target cell is without a security key exchange based on said determining that the second target cell and the source cell are provided by the CU.19.The method of claim 17, wherein said deriving the security key for the LTM failure recovery procedure is based on the RRC configuration.20.The method of claim 17, wherein said deriving the security key for the LTM failure recovery procedure is based on the master key update parameter.

Images