5G/NR  

 

 

 

CHO(Conditional Handover)

You already know what handover is. It is a cell change while the UE stays in connected mode. The network decides the right moment and tells the UE to move from one cell to another.

Conditional handover is different. If you put it literally, it means handover that happens under specific conditions. It does not happen right away when the network prepares it. The network gives the UE a handover command in advance and also gives the condition for when to use it. The UE keeps this information and monitors the radio environment. When the condition is satisfied, the UE executes the handover by itself without waiting for another command from the network.

This makes the handover faster and more robust in fast-changing radio environments. The execution timing is controlled by the UE instead of the gNB. The network prepares the target cell early, and the UE chooses the right moment (i.e, the specific situation to meet the specific conditions defined by gNB) to make the switch. This is the core idea of conditional handover.

NOTE : For formal overview of CHO, refer to 3GPP 38.300 - 9.2.3.4 Conditional Handover

Fundamental difference between Conventional Handover and Condition Handover

The basic difference between conventional handover and conditional handover can be seen from multiple perspectives such as who decides the timing of execution, how the handover message is structured, and how the signaling flows between UE and the network. In a conventional handover, the gNB controls the entire process. The UE sends a measurement report when a specific event, such as A3, is triggered. The gNB decides whether to hand over and when to do it. Once the decision is made, the gNB sends an RRC Reconfiguration message containing the handover command, and the UE executes the handover immediately. The handover timing is tightly coupled to the moment when the gNB makes its decision.

In a conditional handover, the process is split. The gNB still makes the initial decision on which cells to prepare as handover candidates, but it does not decide the exact moment of execution. Instead, the gNB provides the UE with the handover command in advance together with the execution condition and validity timer. The UE stores this configuration and monitors the radio link. When the pre-defined condition is met, the UE executes the handover on its own without waiting for another network command. This shifts the execution timing from network control to UE control.

This change also impacts the message flow. In conventional handover, the handover command comes after the measurement report and the decision, which means the signaling chain directly determines the HO timing. In conditional handover, the UE receives the configuration earlier and the execution happens locally, so the HO is not bound by network signaling latency. It also affects how multiple targets are handled. Conventional handover usually involves a single target cell at decision time. Conditional handover can involve multiple candidate cells provided to the UE at once, and the UE executes toward whichever meets the condition first.

The result is that conventional handover provides tight network control and simpler resource handling but can be vulnerable to delay and failure in fast mobility. Conditional handover increases execution flexibility and reliability in high-mobility or uncertain radio conditions but requires more preparation and context management at the network side. The most fundamental difference is simple: in conventional handover, the network decides when to execute. In conditional handover, the UE decides when to execute.

  •   In conventional handover, the gNB controls the execution timing.
    • The UE sends a measurement report when a specific event like A3 is triggered.
    • The gNB decides whether to hand over and when to do it.
    • Once the decision is made, the gNB sends an RRC Reconfiguration message containing the handover command.
    • The UE executes the handover immediately after receiving the command.
    • The handover timing is tightly coupled with the network decision.
  •   In conditional handover, the execution timing shifts to the UE.
    • The gNB determines candidate cells and prepares the CHO configuration.
    • The UE receives the handover command together with the execution condition and validity timer.
    • The UE monitors the radio condition locally.
    • When the condition is met, the UE executes the handover without waiting for further signaling.
    • This allows faster and more robust execution, especially in high-mobility scenarios.
  •   The message structure and signaling flow are also different.
    • In conventional HO, the handover command follows the measurement report and decision.
    • In CHO, the configuration is sent in advance, and execution is decoupled from the signaling chain.
    • This reduces signaling latency during handover execution.
  •   The handling of multiple targets is different as well.
    • Conventional HO usually involves one target cell chosen at decision time.
    • CHO can include multiple candidate cells, and the UE selects the one that meets the condition first.
  •   The network impact also differs.
    • Conventional HO offers tighter network control and simpler resource handling.
    • CHO requires more preparation and context management but increases handover reliability in fast-changing environments.
  •   The most fundamental difference is simple and clear:
    • In conventional HO, the network decides when to execute.
    • In CHO, the UE decides when to execute.

Why CHO ?

Conventional handover works well when the radio condition is stable and the UE is not moving too fast. But it can become fragile when the UE moves quickly or when the signal fluctuates rapidly around the cell border. In these situations, the handover timing decided by the network may not match the best radio moment for the UE. Even a small delay in signaling can cause the UE to lose coverage or hit radio link failure before the handover completes.

CHO addresses this problem by shifting the execution timing from the network to the UE. The network prepares the handover in advance and provides the target information and the execution condition. The UE monitors the radio environment and executes the handover at the optimal moment, without waiting for a new command. This reduces latency, minimizes failure due to late execution, and improves robustness in mobility scenarios such as highway movement, high-speed trains, and cell-edge fluctuations.

Another reason for CHO is flexibility. The network can prepare multiple candidate cells in one step. The UE can choose the most appropriate one at runtime, depending on which signal becomes strongest first. This avoids unnecessary handover retries and helps reduce ping-pong effects.

From a performance perspective, CHO is especially beneficial when the handover margin is narrow, the UE speed is high, or the radio environment changes fast. It provides more control to the UE while reducing time-critical dependency on network signaling. The end result is faster handover execution and better mobility stability.

  • CHO is introduced to make handover more reliable in conditions where conventional handover can be too slow or too rigid.
  • It reduces the dependency on network signaling timing and allows the UE to choose the best execution moment.
  • It minimizes handover failure caused by late execution or unstable cell edge signal.
  • It improves mobility performance especially for high-speed UEs such as vehicles and trains.
  • It gives flexibility by allowing the network to configure multiple candidate cells in advance.
  • It helps avoid ping-pong and unnecessary retries by letting the UE pick the best cell at runtime.
  • It improves overall handover latency and stability in rapidly changing radio environments.

RRC Parameters

CHO related RRC parameters define how the network delivers conditional handover configurations to the UE. They are carried in the RRC Reconfiguration message and provide all the information the UE needs to store, manage, and execute a conditional handover without waiting for further commands. In a conventional handover, the network decides the target and timing, then instructs the UE to execute. But in CHO, the network prepares the configuration early and lets the UE decide when to execute based on radio conditions.

Some parameters define when and how the UE should attempt CHO after a failure. Others define the candidate cells to be added or removed, the shared reference configurations, and the security context needed for smooth execution. Certain fields are specifically related to security handling and key derivation, especially in inter-node scenarios. Together, these fields allow the network to hand over decision timing to the UE while keeping full control of target preparation, security, and resource management. This structure is what makes CHO both fast and reliable in challenging mobility situations.

ConditionalReconfiguration-r16 ::= SEQUENCE {

     attemptCondReconfig-r16 ENUMERATED {true} OPTIONAL, -- Cond CHO

     condReconfigToRemoveList-r16 CondReconfigToRemoveList-r16 OPTIONAL, -- Need N

     condReconfigToAddModList-r16 CondReconfigToAddModList-r16 OPTIONAL, -- Need N

     ...,

     [[

     scpac-ReferenceConfiguration-r18 SetupRelease {ReferenceConfiguration-r18} OPTIONAL, -- Need M

     servingSecurityCellSetId-r18 SecurityCellSetId-r18 OPTIONAL, -- Need M

     sk-CounterConfiguration-r18 SK-CounterConfiguration-r18 OPTIONAL -- Need M

     ]]

}

 

CondReconfigToRemoveList-r16 ::= SEQUENCE (SIZE (1.. maxNrofCondCells-r16)) OF CondReconfigId-r16

     SK-CounterConfiguration-r18 ::= SEQUENCE {

          sk-CounterConfigToReleaseList-r18 SEQUENCE (SIZE (1..maxSecurityCellSet-r18))

                                                                                       OF SecurityCellSetId-r18 OPTIONAL, -- Need N

          sk-CounterConfigToAddModList-r18 SEQUENCE (SIZE (1..maxSecurityCellSet-r18))

                                                                                       OF SK-CounterConfig-r18 OPTIONAL -- Need N

}

 

SK-CounterConfig-r18 ::= SEQUENCE {

     securityCellSetId-r18 SecurityCellSetId-r18,

     sk-CounterList-r18 SEQUENCE (SIZE (1..maxSK-Counter-r18)) OF SK-Counter

}

SecurityCellSetId-r18 ::= INTEGER (1.. maxSecurityCellSet-r18)

Followings are brief descriptions of these parameters

  • attemptCondReconfig : If present, the UE shall perform conditional reconfiguration if selected cell is a target candidate cell and it is the first cell selection after failure as described in clause 5.3.7.3.
    • This flag indicates whether the UE should attempt CHO immediately after a failure, such as an RLF or RRC re-establishment.
    • It allows the UE to re-use existing CHO configuration to speed up recovery and avoid going through a full reconfiguration again.
    • This reduces the interruption time by letting UE directly execute handover to one of the previously configured candidate cells.
  • condReconfigToAddModList : List of the configuration of candidate SpCells to be added or modified for CHO, CPA or CPC.
    • This list contains one or more conditional reconfiguration entries that the UE will store and monitor.
    • Each entry corresponds to a candidate SpCell that may be used for conditional handover or related conditional procedures.
    • It provides the full configuration required for the UE to execute HO without additional network signaling.
  • condReconfigToRemoveList : List of the configuration of candidate SpCells to be removed.
    • This list tells the UE which previously configured candidate cells should be deleted from its conditional configuration storage.
    • It ensures that outdated or unused CHO candidates are cleared out, avoiding confusion or invalid execution triggers.
    • This is important for maintaining consistency when new CHO configurations are added.
  • scpac-ReferenceConfiguration : Includes the reference configuration for the candidate supporting subsequent CPAC.
    • This field provides reference parameters that are shared across multiple candidates supporting Conditional PCell Addition or Change (CPAC).
    • It allows the network to avoid repeating identical configuration for each candidate cell.
    • This makes signaling more efficient and keeps the CHO configuration compact.
  • servingSecurityCellSetId : This field identifies the security cell set for serving PSCell. The network does not provide this field for the conditional reconfiguration(s) generated by the SN.
    • This parameter links the conditional configuration to the correct security context of the serving cell.
    • It ensures that key material and security associations remain valid when UE executes CHO.
    • It is provided only when the configuration originates from the MN, not from the SN.
  • sk-counterConfiguration : Includes a list of sk-Counter from which the UE should select the sk-counter used to derive S-KgNB for inter-SN subsequent CPAC. The network does not provide this field for the conditional reconfiguration(s) generated by the SN.
    • This parameter gives the UE a set of counters used to derive the key S-KgNB for security context at the target cell.
    • It ensures secure handover execution across nodes, especially in inter-SN mobility scenarios.
    • As with servingSecurityCellSetId, this is provided only when the configuration originates from the MN.

UE Capability Informations

UE capability information plays a critical role in determining whether the network can use conditional handover for a specific UE. Unlike conventional handover, CHO requires the UE to store configuration, monitor execution conditions, and autonomously trigger the handover at the right moment. Not every device can support these functions, so the gNB must know in advance what the UE is capable of. This is done through capability signaling, where the UE advertises its support for CHO features as part of its radio access capability information.

The capability information not only indicates basic CHO support but also specifies the details of what the UE can handle. This includes whether it supports multiple trigger events, different types of execution conditions such as measurement-based, location-based, or time-based triggers, and whether it can handle CHO across duplex modes or frequency ranges. It also covers support for advanced configurations such as dual connectivity scenarios with NR, EN-DC, or NE-DC. These capabilities give the network a clear view of how flexible the UE is in handling CHO.

With this information, the gNB can decide if CHO should be configured, how many candidate cells can be used, and which trigger mechanisms are appropriate. It can also determine whether to apply CHO in inter-band or dual connectivity scenarios. In short, the UE capability information defines the boundary of what can be configured, ensuring the network uses CHO only when the UE can handle it properly. This makes CHO configuration more efficient, more reliable, and well aligned with the actual capabilities of the device.

  • condHandover-r16 : Indicates whether the UE supports conditional handover including execution condition, candidate cell configuration and maximum 8 candidate cells. Except for NTN bands, UE shall set the capability value consistently for all FDD-FR1 bands, all TDD-FR1 bands, all TDD-FR2-1 bands and all TDD-FR2-2 bands respectively. For NTN, UE shall set the capability value consistently for all FDD-FR1 NTN bands.
    • This is the main capability flag indicating whether the UE supports CHO in general.
    • When this feature is supported, the UE can receive and store conditional handover configurations with up to eight candidate cells.
    • The consistency requirement ensures that the capability is applied uniformly across all frequency ranges and duplex modes, avoiding partial implementation per band.
    • For NTN (Non-Terrestrial Network) operation, this consistency rule applies specifically to FDD-FR1 NTN bands.
  • condHandoverTwoTriggerEvents-r16 : Indicates whether the UE supports 2 trigger events for same execution condition. This feature is mandatory supported if the UE supports condHandover-r16. Except for NTN bands, UE shall set the capability value consistently for all FDD-FR1 bands, all TDD-FR1 bands, all TDD-FR2-1 bands and all TDD-FR2-2 bands respectively. For NTN, UE shall set the capability value consistently for all FDD-FR1 NTN bands.
    • This capability allows the UE to monitor two different measurement events for the same CHO execution condition.
    • It increases flexibility and robustness by letting the UE trigger CHO from multiple measurement perspectives, for example both A3 and A5 events.
    • It is a mandatory feature for any UE that declares CHO support since it enhances mobility performance in dynamic radio environments.
  • condHandoverFailure-r16 : Indicates whether the UE supports conditional handover during re-establishment procedure when the selected cell is configured as candidate cell for condition handover. Except for NTN bands, UE shall set the capability value consistently for all FDD-FR1 bands, all TDD-FR1 bands, all TDD-FR2-1 bands and all TDD-FR2-2 bands respectively. For NTN, UE shall set the capability value consistently for all FDD-FR1 NTN bands.
    • This feature allows the UE to reuse CHO configuration during RRC re-establishment, for example after a radio link failure.
    • It prevents unnecessary fallback to idle or full reconnection if the previously configured candidate is still valid.
    • It helps improve recovery time and reliability in case of link interruption during CHO preparation.
  • eventA4BasedCondHandover-r17 : Indicates whether the UE supports Event A4 based conditional handover in NTN bands, i.e., CondEvent A4 as specified in TS 38.331 [9]. A UE supporting this feature shall also indicate the support of condHandover-r16 for NTN bands and the support of nonTerrestrialNetwork-r17. UE shall set the capability value consistently for all FDD-FR1 NTN bands.
    • This capability extends CHO support to Event A4 triggering conditions for NTN systems.
    • It means the UE can perform CHO based on absolute signal level thresholds rather than relative comparisons (as in A3).
    • It is specific to Non-Terrestrial Networks and must be reported consistently across all FDD-FR1 NTN bands.
  • locationBasedCondHandover-r17 : Indicates whether the UE supports location based conditional handover, i.e., CondEvent D1 as specified in TS 38.331 [9]. A UE supporting this feature shall also indicate the support of condHandover-r16 for NTN bands and the support of nonTerrestrialNetwork-r17. UE shall set the capability value consistently for all FDD FR1 NTN bands.
    • This capability enables CHO triggered by location-based conditions rather than purely by radio measurements.
    • The UE uses its position information to determine when to execute the handover.
    • This is useful for NTN systems where geographic movement rather than signal fluctuation may be the main mobility factor.
  • timeBasedCondHandover-r17 : Indicates whether the UE supports time based conditional handover, i.e., CondEvent T1 as specified in TS 38.331 [9]. A UE supporting this feature shall also indicate the support of condHandover-r16 for NTN bands and the support of nonTerrestrialNetwork-r17. UE shall set the capability value consistently for all FDD-FR1 NTN bands.
    • This allows CHO to be triggered at a specific time or after a predefined duration, rather than by radio measurement.
    • It is designed mainly for NTN scenarios where satellite movement and timing predictability play a key role.
    • It complements measurement-based triggers and provides deterministic HO timing for predictable orbits.
  • condHandoverFDD-TDD-r16 : Indicates whether the UE supports conditional handover between FDD and TDD cells. The parameter can only be set if condHandover-r16 is set for both FDD and TDD. The UE that indicates support of this feature shall also indicate support of handoverFDD-TDD.
    • This defines whether the UE can perform CHO across duplexing modes, from FDD to TDD or vice versa.
    • It is important for inter-mode mobility in mixed deployments, especially in FR1 where both FDD and TDD coexist.
    • The support must align with general inter-mode HO capability (handoverFDD-TDD).
  • condHandoverFR1-FR2-r16 : Indicates whether the UE supports conditional handover HO between FR1 and FR2. The parameter can only be set if condHandover-r16 is set for both FR1 and FR2. The UE that indicates support of this feature shall also indicate support of handoverFR1-FR2.
    • This enables CHO between low and high frequency ranges, such as between sub-6 GHz (FR1) and mmWave (FR2).
    • It allows UEs to handle wideband mobility with preconfigured CHO conditions across frequency ranges.
    • It must be aligned with inter-frequency HO capability between FR1 and FR2.
  • condHandoverWithSCG-NRDC-r17 : Indicates whether the UE supports conditional handover with NR SCG configuration for NR-DC. The UE indicating support of this feature shall also indicate the support of condHandover-r16 and support of at least one NR-DC band combination.
    • This enables CHO operation for NR Dual Connectivity (NR-DC), where the UE maintains both Master and Secondary NR cells.
    • It allows CHO to be executed even when an NR SCG configuration is active.
    • The feature improves seamless mobility between dual-connected NR networks.
  • condHandoverWithSCG-ENDC-r17 : Indicates whether the UE supports conditional handover with NR SCG configuration for EN-DC. The UE indicating support of this feature shall also indicate the support of cho-r16 as specified in TS 36.306 [15] and at least one ENDC band combination.
    • This extends CHO support to E-UTRA and NR Dual Connectivity (EN-DC) scenarios.
    • It allows UEs with LTE primary and NR secondary cells to perform conditional HO using preconfigured NR SCG settings.
    • This enables smooth mobility between mixed LTE-NR deployments while maintaining data continuity.
  • condHandoverWithSCG-NEDC-r17 : Indicates whether the UE supports conditional handover with E-UTRA SCG configuration for NE-DC. The UE indicating support of this feature shall also indicate the support of condHandover-r16 and at least one NE-DC band combination.
    • This capability applies to New E-UTRA Dual Connectivity (NE-DC), enabling CHO when LTE secondary cells are used alongside NR master cells.
    • It ensures the UE can maintain dual connectivity context during CHO execution.
    • It is mainly intended for transitional deployments where NR is dominant but LTE cells are still used as secondary carriers.