Conditional handover in 5G NR procedures exist to solve one specific problem: every legacy handover in cellular networks has the same structural weakness — the network waits until radio conditions are already degrading before it commits the UE to a decision. Every legacy handover in cellular networks has the same structural weakness: the network waits until radio conditions are already degrading before it commits the UE to a decision. The Measurement Report goes out over a weakening uplink. The Handover Command comes back over a weakening downlink, sometimes large enough to need segmentation and retransmission. If that command doesn’t arrive in time, the result is a Radio Link Failure, not a handover — the UE drops the call or session entirely rather than moving cleanly to a better cell.
Conditional Handover (CHO), standardized in 3GPP Release 16 for both NR and E-UTRAN, fixes this by changing when the UE commits — not by changing the physics of a weakening radio link. Instead of receiving a single command it must execute immediately, the UE receives several pre-approved options in advance and decides for itself, later, which one to use.
The core problem CHO solves: legacy handover risks its most critical signaling exactly when the link is weakest.
The mechanism: separating preparation from execution
In legacy handover, preparation and execution happen back-to-back and depend on the same degrading link. CHO breaks that dependency into two distinct phases, and the separation is the entire point of the feature.
In Phase 1 (preparation), the source gNB runs Xn Handover Preparation in parallel against multiple candidate target gNBs — up to eight — while the UE’s link to the source cell is still good. Each candidate reserves resources and returns its own RRC Reconfiguration. The source gNB packages all of these into a single RRCReconfiguration message containing the ConditionalReconfiguration information element, per 3GPP TS 38.331, and sends it to the UE. Critically, the UE stores this without acting on it and keeps its connection to the source cell exactly as before.
In Phase 2 (execution), the UE continuously evaluates the stored execution conditions against its own measurements. The moment one candidate cell satisfies its condition, the UE autonomously detaches from the source cell and synchronizes to that target — no further network round trip required at the moment of execution, because the approval already happened while the link was healthy.
The full six-step flow for an intra-NR, Xn-based CHO.
What actually triggers execution: A3 and A5
CHO reuses the same measurement event framework as ordinary measurement reporting, defined in TS 38.331 — but for CHO, satisfying the event triggers direct execution rather than a report back to the network.
Event A3 fires when a neighbor cell becomes better than the serving (special) cell by a configured offset — the standard case for intra- or inter-frequency handover. Event A5 fires only when two conditions hold simultaneously: the serving cell drops below a first threshold and the neighbor rises above a second threshold. A5 is the more conservative trigger, since it requires the source to actually be getting bad, not just relatively worse than a neighbor.
Each execution condition is tunable via the same parameters that govern ordinary handover: offset, hysteresis, and Time-to-Trigger (TTT). Get these wrong in the field and the symptoms are well known to anyone who’s tuned a live network: an offset set too small — 0 dB instead of a typical 3 dB — produces repeated A3 events alternating between two cells, the classic ping-pong pattern. A TTT set too high for the UE’s actual speed means the condition is confirmed too slowly, and the handover, conditional or not, arrives after the link has already failed.
Why this specifically matters for high-speed and low-latency use cases
CHO isn’t a general efficiency improvement — it’s targeted at the mobility scenarios where legacy handover fails most often: high Doppler environments (high-speed rail, vehicular mobility) and FR2 mmWave deployments, where narrow beams and shorter range make radio conditions swing faster than a legacy Measurement-Report-then-Command exchange can reliably track.
This is also why CHO shows up specifically in URLLC and industrial automation discussions. A use case that can’t tolerate an unplanned Radio Link Failure — an autonomous vehicle, a factory-floor control loop — benefits disproportionately from moving the risky signaling earlier in time, even though the underlying radio link budget hasn’t changed at all.
The related feature worth knowing: Conditional PSCell Change
CHO’s principle — prepare early, execute autonomously — extends beyond full handover. Conditional PSCell Addition/Change (CPAC) applies the same A3/A5-triggered logic to the Secondary Cell Group in dual-connectivity deployments (EN-DC, NR-DC), letting the network reconfigure the PSCell without the full handover signaling weight. Release 16 scoped this initially to the intra-SN case only — where the source and target Secondary Node are the same node — with cross-node PSCell changes left for later releases.
What CHO explicitly does not cover
Two boundaries are worth knowing precisely, since they come up quickly in any real deployment discussion: CHO is not supported for NG-C (core-network-based, N2) handover — it’s an Xn/X2, RAN-to-RAN feature only. And a CHO candidate cell configuration cannot be combined with a DAPS (Dual Active Protocol Stack) handover configuration for the same candidate — they’re two separate Release 16 mobility-robustness features solving overlapping problems in different ways, not a combinable stack.
If you’ve worked with live A3/A5 tuning in the field, what’s the most stubborn ping-pong or late-handover case you’ve had to chase down?