5G NR Handover: Xn vs N2, Conditional HO, Beam Failure Recovery Interview Prep
5G NR handover — Xn vs N2 signaling paths, conditional handover, measurement events A1-A6, time-to-trigger, MRO, and intra/inter-DU mobility.
Quick answer
5G NR handover is the procedure by which a UE in RRC_CONNECTED moves its active connection from a source cell to a target cell while preserving service continuity.
Handover is the most-asked operational topic in 5G modem and RAN-engineer interviews because it is the procedure that determines user-visible service continuity and the operations team's daily mobility-debug workload.
Editorial review
Written by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Reviewed by
CompoundLearn editorial team
Wireless / RF / hardware engineering
Last reviewed
Built from curated topic maps, editorial validation, and subject-matter review so the page stays aligned with the interview intent and the current content pipeline.
What it is
5G NR handover is the procedure by which a UE in RRC_CONNECTED moves its active connection from a source cell to a target cell while preserving service continuity. The procedure involves several stages: the UE measures serving and neighbor cells per its measurement configuration; when a configured measurement event is met for the time-to-trigger (TTT), the UE sends a Measurement Report; the source gNB applies operator-configured policy and decides whether to initiate handover; if yes, the source gNB coordinates with the target gNB (either directly via Xn or through the AMF via N2), prepares the target cell, and issues the HO command — an RRC Reconfiguration with synchronization — to the UE; the UE detaches from the source, performs contention-free RACH at the target using a pre-allocated dedicated preamble, and confirms arrival with RRC Reconfiguration Complete. The Xn-based and N2-based handover variants differ in signaling path. Xn-based handover goes directly between source and target gNBs via the Xn interface — the AMF is informed at the end via Path Switch Request so the user-plane GTP-U tunnels are switched to the new gNB. Xn is the faster path because the 5GC is not on the critical path during prepare-and-execute. N2-based handover signals through the AMF — source gNB sends Handover Required to the AMF, the AMF coordinates with the target gNB (possibly via a different AMF for inter-AMF handovers), and the HO command flows back through the AMF. N2 is the fallback path used for inter-AMF handovers, inter-PLMN handovers, and any case where Xn is not configured between the source and target. Conditional handover (CHO) is the 5G addition that addresses the "too-late handover" failure mode. In standard handover, the source gNB must successfully deliver the HO command to the UE before the source link degrades — in high-mobility scenarios this can fail. CHO splits the procedure: the source pre-configures the UE with a target cell configuration plus execution conditions (typically RSRP/RSRQ thresholds), and the UE autonomously executes the handover when the conditions are met, without needing a new HO command at execution time. CHO can pre-configure multiple candidate targets so the UE picks whichever target meets the conditions first. Measurement events A1-A6 are the configured triggers that drive handover. Event A3 — neighbor becomes offset-better than serving — is the standard intra-frequency handover trigger. Event A5 — serving worse than threshold1 AND neighbor better than threshold2 — is the cell-edge trigger that combines serving-side weakness with neighbor-side strength. Each event has configurable thresholds, hysteresis, and time-to-trigger (TTT). TTT exists to filter ping-pong handovers caused by transient measurement fluctuations; typical TTT values range from 40 ms (aggressive) to 640 ms (conservative). Mobility Robustness Optimization (MRO) is the SON feature that automatically tunes these parameters per cell based on observed handover success rates. MRO typically runs as an rApp on the Non-RT RIC, collecting per-cell statistics on handover successes, too-early handovers, too-late handovers, and ping-pong handovers, then pushing parameter updates (event offsets, hysteresis, TTT) via A1 policy to the Near-RT RIC and via O1 configuration to the RAN. MRO is the practical mechanism that keeps a deployed RAN's mobility parameters tuned to actual user-mobility patterns. Beam failure recovery (BFR — see /topics/nr-beam-management) and handover address different failure scopes. BFR is a within-cell recovery for transient beam-level failures, typical at FR2 with body shadowing or fast beam-mismatch; it completes in tens of ms. Handover is the cross-cell mobility procedure for inter-cell movement, typical at any frequency range; it completes in hundreds of ms including signaling. Operators tune both procedures to handle their respective failure modes.
Why interviewers ask
Handover is the most-asked operational topic in 5G modem and RAN-engineer interviews because it is the procedure that determines user-visible service continuity and the operations team's daily mobility-debug workload. A candidate who fluently navigates Xn vs N2 signaling paths, A3/A5 measurement-event triggers, conditional handover, MRO tuning, and the BFR-vs-handover scope distinction is showing the integrated mobility-architecture understanding that staff RAN-engineering and modem-design roles require. The Xn vs N2 split is the most-asked architectural question. Strong candidates explain that Xn is the faster direct-gNB-to-gNB path used for most intra-PLMN handovers, while N2 goes through the AMF and is the fallback for inter-AMF or Xn-unavailable cases. Weak candidates conflate the two or describe handover as a single signaling path. Conditional handover is the modern-NR deep-cut question. Strong candidates explain the "too-late handover" failure mode that CHO addresses, the split between pre-configuration (while source is good) and autonomous execution (when target condition is met), and the high-mobility deployment scenarios (rail, highway) where CHO materially reduces failure rates. Candidates who do not know CHO exists or who treat it as a marketing renamed feature have not faced production high-mobility deployments. The measurement-event A3 trigger plus TTT is the operational-tuning question. Strong candidates explain that A3 (neighbor offset-better than serving) is the standard intra-frequency trigger, that TTT (40-640 ms typical) filters ping-pong handovers, and that MRO automates per-cell tuning of A3 offsets, hysteresis, and TTT. Candidates who can name A3 without understanding the trigger semantics or TTT purpose have surface knowledge only. The BFR-vs-handover scope question is the FR2-deployment probe. Strong candidates explain that BFR is a within-cell mechanism for transient beam failures, completes in tens of ms, and is the right tool for body-shadowing or fast beam-mismatch at FR2; handover is the cross-cell mechanism for inter-cell mobility and takes hundreds of ms. Candidates who confuse the scopes or who treat BFR as a handover variant miss the FR2 architectural addition. The intra-DU vs inter-DU vs inter-CU question is the CU/DU split probe. Strong candidates explain that mobility cost scales with how high up the architecture the signaling has to travel — intra-DU is fastest, intra-CU-inter-DU is mid, inter-CU is full handover. Candidates who do not know the CU/DU mobility hierarchy have not worked at the O-RAN deployment level.
Common mistakes
The most common mistake is treating handover as a single procedure rather than a family of procedures. Xn-based, N2-based, conditional, DAPS, intra-DU, inter-DU, inter-CU, inter-AMF, inter-PLMN, and inter-RAT handovers all have different signaling paths and use cases. Candidates who collapse them into "handover" miss the operator-level decision surface. A second gap is missing time-to-trigger (TTT). Without TTT, A3 events would fire on every transient measurement fluctuation and the network would ping-pong handovers between cells at the edge. TTT (40-640 ms typical) is the filter that prevents this. Candidates who know A3 but not TTT have not worked at the mobility-tuning level. A third gap is misunderstanding conditional handover. Some candidates treat CHO as identical to standard handover; it is not — the split between pre-configuration and autonomous execution is the architectural change. Some candidates think CHO removes RACH at the target; it does not — CHO still uses contention-free RACH at the target, it just removes the need for the source to deliver the HO command at execution time. The key insight is that CHO addresses the "too-late HO" failure mode by decoupling configuration from execution. A fourth gap is confusing BFR with handover. BFR (beam failure recovery) is within-cell — when the UE's serving beam fails, it finds a new candidate beam in the same cell and signals recovery via PUCCH or CFRA. Handover is cross-cell mobility — the UE moves to a different cell with full RRC reconfiguration. Candidates who treat BFR as a handover variant or vice versa miss the scope distinction that drives FR2 deployment design. A fifth gap is missing the AMF role. In Xn-based handover the AMF is informed at the end via Path Switch Request — the user-plane GTP-U tunnels rebind to the new gNB. In N2-based handover the AMF is on the critical path during the prepare-and-execute phase. Candidates who claim "5G handover doesn't involve the core network" miss the AMF's role even in the Xn-fast-path case. A sixth gap is treating MRO as theoretical. Operators run MRO continuously in production deployments — A3 offsets, hysteresis, and TTT are tuned per cell based on observed success rates. The implementation lives on the Non-RT RIC as an rApp, pushing parameter updates via A1 and O1. Candidates who do not surface MRO or who treat it as a research feature have not worked at the production-mobility-tuning level. See /topics/rsrp-rsrq-sinr for the measurement-quantity context, /topics/nr-rrc-states for the RRC-state context, and /topics/xapps-rapps-ran-intelligence for the rApp deployment context.
NR Handover Types — Signaling Path and Use
| HO Type | Signaling Path | Latency | Best Use | Trigger |
|---|---|---|---|---|
| Xn-based HO | Source gNB ↔ Target gNB via Xn (AMF informed at end) | Fastest | Intra-PLMN, intra-AMF, intra-mobility-set HO | Measurement event (A3 typical) |
| N2-based HO | Source gNB → AMF → Target gNB via N2 | Slower (CN-hop) | Inter-AMF, inter-PLMN, Xn-unavailable | Measurement event (A3 typical) |
| Conditional HO (CHO) | Pre-configured on source; UE autonomous execution | No source-side execution delay | High-mobility (rail, highway) | UE-internal execution condition (RSRP/RSRQ threshold) |
| DAPS HO (dual-active) | Make-before-break across both gNBs | Service-continuity hand-off | Service-critical applications (e.g., URLLC handover) | A3 + DAPS-capable UE + DAPS-enabled cell |
Sample interview questions
- A UE reports a measurement event A3 — neighbor RSRP exceeds serving RSRP by the configured offset plus hysteresis for the configured time-to-trigger (TTT). What does the gNB do next, and why does TTT exist?
- A. The gNB evaluates the report against operator-configured policy and, if a handover is appropriate, sends an RRC Reconfiguration with synchronization to instruct the UE to perform handover to the target cell. TTT (time-to-trigger) exists to filter out short transient measurements that would cause unnecessary handovers — the UE only reports the event after the trigger condition has held continuously for TTT (typically 40-640 ms). ✓
- B. The gNB immediately re-establishes RRC connection with the neighbor.
- C. The gNB drops the UE's connection and forces re-attach.
- D. A3 events are informational only; the gNB never triggers handover from them.
Option A is correct. Event A3 is the standard intra-frequency handover trigger: "Neighbour becomes amount of offset better than serving." The UE evaluates this condition continuously and, when it has held for time-to-trigger (TTT), sends a Measurement Report to the gNB. The gNB applies operator-configured policy (load balancing, beam-management state, prior HO history) and issues RRC Reconfiguration with synchronization carrying the target cell's configuration, security keys, dedicated preamble for CFRA at the target, and the rest of the parameters the UE needs to switch. TTT exists to filter against ping-pong handovers. Without TTT, every transient measurement fluctuation would trigger a handover, and the UE would oscillate between cells at the edge. Typical TTT values are 40 ms (aggressive), 160 ms (default), 320 ms or 640 ms (conservative). The MRO (Mobility Robustness Optimization) framework in O-RAN automates the tuning of A3 offsets, hysteresis, and TTT per-cell based on observed handover success rates. The HO procedure post-trigger: 1. gNB sends RRC Reconfiguration with sync (the "HO command") on the source cell 2. UE detaches from source cell, performs contention-free RACH at the target with the pre-allocated dedicated preamble 3. UE sends RRC Reconfiguration Complete on the target — handover complete 4. Source gNB releases UE context Option B is wrong — the procedure is RRC Reconfiguration with sync, not re-establishment. Option C is wrong — handover is not a connection drop. Option D dismisses the well-established A3 trigger semantics. Production reality: A3 + TTT + offsets are the operator-tunable knobs that determine the network's mobility robustness. See /topics/rsrp-rsrq-sinr for the measurement-quantity context that feeds these events.
- Conditional handover (CHO) was introduced in 5G NR. What does it do that standard handover does not, and what deployment problem motivated it?
- A. CHO is identical to standard handover; the naming is marketing.
- B. In standard handover the UE receives the HO command, detaches from the source, and attaches to the target — if the radio link to the source has already failed when the HO command arrives, the UE never receives the command and the procedure fails (handover failure). CHO splits the HO command into two phases: (1) the gNB pre-configures the UE with a target-cell handover configuration plus execution conditions (typically RSRP/RSRQ thresholds), and (2) the UE autonomously executes the handover when the execution conditions are met — without needing a new HO command on the source. This protects against HO failures caused by rapidly deteriorating source links in high-mobility scenarios. ✓
- C. CHO is only used in submarine handovers.
- D. CHO removes the need for RACH at the target cell.
Option B is correct. CHO addresses the well-known "too-late handover" failure mode. In standard handover the source gNB must successfully deliver the HO command to the UE before the source link degrades to the point where the UE can no longer receive it. In high-mobility scenarios (e.g., high-speed rail, vehicular) the source link can degrade faster than the network can react, and the HO command arrives too late or not at all — the UE loses the connection and falls back to RRC re-establishment. CHO splits the procedure: 1. **Pre-configuration phase**: while the source link is still good, the source gNB pre-configures the UE with a candidate target cell configuration plus execution conditions (typically RSRP/RSRQ thresholds on the target relative to the source). The configuration is stored on the UE but not yet executed. 2. **Autonomous execution phase**: the UE monitors the execution conditions and, when they are met, autonomously executes the handover — performing CFRA at the target with the pre-allocated dedicated preamble and sending RRC Reconfiguration Complete to the target gNB. CHO can pre-configure multiple candidate targets so the UE picks whichever target meets the execution conditions first. Option A misses real architectural differences. Option C is unrelated to deployment scenario. Option D is wrong — CHO still uses CFRA at the target; it just removes the need for the source to deliver the HO command at the moment of execution. Production reality: CHO is widely deployed in high-mobility scenarios (railway corridors, highway segments) where it materially reduces handover-failure rates and the associated re-establishment overhead.
- What is the difference between Xn-based handover and N2-based handover in 5G, and when is each used?
- A. Xn and N2 handovers are identical; the naming is just signaling-path detail.
- B. Xn-based handover is only used in non-standalone (NSA) deployments.
- C. Xn-based handover signals directly between source and target gNBs via the Xn interface — the 5GC AMF is informed at the end of the procedure but does not participate in real time. N2-based handover signals through the AMF — source gNB sends Handover Required to the AMF, the AMF coordinates with the target gNB and returns the HO command. Xn is faster (fewer signaling hops, lower latency) and is preferred whenever both gNBs are connected to the same AMF. N2 is required when the target is in a different AMF's coverage (inter-AMF handover) or when Xn is not available between the source and target. ✓
- D. N2 is the older 4G interface and is not used in 5G.
Option C is correct. NR defines two handover-control paths: - Xn-based handover: source gNB sends Handover Request directly to the target gNB via the Xn interface (RAN-to-RAN). Target prepares the HO, returns Handover Request Acknowledge, source issues the HO command to the UE. The AMF is informed at the end via a Path Switch Request (so the user-plane GTP-U tunnels are switched to the new gNB). This is the faster path because the 5GC is not on the critical path during the prepare-and-execute phase. - N2-based handover: source gNB sends Handover Required to the AMF via the N2 interface (RAN-to-CN), the AMF coordinates with the target gNB (possibly via a different AMF if the target is in a different mobility area), and the HO command flows back through the AMF to the source. This is the fallback path used when Xn is not available or when the handover crosses AMF boundaries. When each is used: - Xn is preferred whenever both gNBs are in the same AMF's coverage and the Xn interface is available between them (most intra-PLMN, intra-mobility-set handovers) - N2 is used for inter-AMF handovers, inter-PLMN handovers, and any handover where Xn is not configured between the specific gNB pair - Xn-prepared handover may also be canceled if conditions change, and the AMF receives the eventual path switch Option A misses real signaling-path differences. Option B is wrong — Xn handover is standard in SA 5G; NSA uses LTE-style X2-based handover. Option D is wrong — N2 is the gNB-to-AMF interface in 5G NR (the analog of S1-MME in 4G). Production reality: most intra-PLMN handovers use Xn for the latency advantage; N2 is reserved for cases that require AMF involvement. See /topics/nr-architecture-nsa-sa-cu-du (queued T6) for the architectural context of these interfaces.
Frequently asked questions
- What is 5G NR handover?
- Handover is the procedure by which a UE in RRC_CONNECTED moves its active connection from a source cell to a target cell while preserving service continuity. The procedure involves measurement reporting from the UE, HO-decision policy on the gNB, an RRC Reconfiguration with synchronization carrying the target cell's configuration, contention-free RACH at the target with a pre-allocated preamble, and RRC Reconfiguration Complete from the UE confirming arrival. NR supports several handover variants: Xn-based (faster, gNB-to-gNB), N2-based (AMF-coordinated), conditional handover (UE-autonomous execution), dual-active-protocol-stack (DAPS) handover (for break-before-make to break-free transitions), and inter-RAT to/from LTE.
- What is the difference between Xn-based and N2-based handover?
- Xn-based handover signals directly between source and target gNBs over the Xn interface — the AMF is informed at the end via Path Switch Request but does not participate during prepare-and-execute. N2-based handover signals through the AMF — source gNB sends Handover Required to the AMF, the AMF coordinates with the target gNB, and the HO command flows back. Xn is faster and is preferred whenever both gNBs share an AMF and the Xn interface is configured between them. N2 is used for inter-AMF handovers, inter-PLMN handovers, and any case where Xn is not available.
- What is conditional handover (CHO)?
- CHO is the 5G NR feature that lets a UE pre-store a handover configuration and execute it autonomously when configured conditions are met, without needing a new HO command at execution time. The source gNB pre-configures the UE with a target cell configuration (possibly multiple candidate targets) plus execution conditions (typically RSRP/RSRQ thresholds on the target). The UE monitors the conditions and, when they are met, performs the handover. CHO addresses the "too-late handover" failure mode where standard handover fails because the source link degrades faster than the network can deliver the HO command. Widely deployed in high-mobility corridors (rail, highway) where it reduces handover-failure rates materially.
- What are the measurement events A1-A6?
- NR measurement events are configured triggers that cause the UE to send a Measurement Report. The main events: A1 — serving becomes better than absolute threshold (used to stop neighbor measurements when serving is strong); A2 — serving becomes worse than absolute threshold (used to start neighbor measurements when serving is weak); A3 — neighbor becomes offset-better than serving (the standard intra-frequency handover trigger); A4 — neighbor becomes better than absolute threshold (used for blind mobility); A5 — serving becomes worse than threshold1 AND neighbor becomes better than threshold2 (combined trigger for cell-edge HO); A6 — neighbor becomes offset-better than secondary cell (used in CA scenarios). Each event has configurable thresholds, hysteresis, and time-to-trigger.
- What is time-to-trigger (TTT)?
- TTT is the period for which a measurement-event trigger condition must hold continuously before the UE sends the Measurement Report. Typical values: 0, 40, 64, 80, 100, 128, 160, 256, 320, 480, 512, 640, 1024 ms. TTT exists to filter out short measurement-fluctuation transients that would cause ping-pong handovers. Aggressive (short) TTT makes the network responsive to mobility but increases ping-pong rate; conservative (long) TTT reduces ping-pong but adds latency to handover. MRO (Mobility Robustness Optimization) in O-RAN automates per-cell tuning of TTT plus event offsets based on observed handover success rates.
- What is beam failure recovery (BFR) vs handover?
- BFR and handover address different failure scopes. BFR (see /topics/nr-beam-management) is a within-cell recovery: when the UE's serving beam fails, it tries to find a new candidate beam in the same cell and signal the recovery via PUCCH or contention-free PRACH. This typically completes in tens of ms and does not involve the AMF or core network. Handover is a cross-cell mobility procedure: the UE moves to a different cell with full RRC reconfiguration, CFRA at the target, and the user-plane GTP-U tunnels rerouted. Handover takes much longer (hundreds of ms typical including signaling) and involves the AMF (for N2-based) or both gNBs (for Xn-based). BFR is the right tool for transient beam-level failures at FR2; handover is the right tool for genuine inter-cell mobility.
- What is intra-DU vs inter-DU mobility?
- In CU/DU split architecture (see /topics/nr-physical-channels and /topics/open-ran-vs-traditional-ran), the gNB is split into a Central Unit (CU) handling RRC/PDCP and one or more Distributed Units (DUs) handling RLC/MAC/PHY. Intra-DU mobility — UE moves between cells served by the same DU — still needs the CU-CP for the RRC reconfiguration (RRC lives in the CU), but avoids inter-DU/inter-CU coordination, so it is the fastest mobility scenario. Intra-CU inter-DU mobility — UE moves between DUs served by the same CU — requires CU-coordinated DU switch but stays within one CU's scope. Inter-CU mobility — UE moves between CUs — is a full inter-gNB handover requiring Xn-based or N2-based signaling between the two CUs. The cost of mobility scales with how high up the architecture the signaling has to travel.
- What is Mobility Robustness Optimization (MRO)?
- MRO is the SON (Self-Organizing Network) feature that automatically tunes handover parameters per cell based on observed handover success rates and failure causes. The MRO function (typically running on the Non-RT RIC as an rApp — see /topics/xapps-rapps-ran-intelligence) collects per-cell statistics on handover successes, too-early handovers, too-late handovers, and ping-pong handovers; calculates parameter adjustments (event offsets, hysteresis, TTT) per cell pair; and pushes the updated parameters via A1 policy to the Near-RT RIC and via O1 configuration to the RAN. MRO is the practical mechanism that keeps a large-scale RAN deployment's mobility parameters tuned to actual user-mobility patterns rather than initial-deployment guesses.
Related topics
Siblings
- 5G NR Explained: Numerology, BWP, HARQ, and Frame Structure
- RRC States in 5G NR: RRC_IDLE, RRC_INACTIVE, RRC_CONNECTED
- NR Beam Management: SSB Sweep, P-1/P-2/P-3, TCI States, QCL
- NR Initial Access: SSB, MIB, SIB1, and the RACH Procedure
- 5G NR Architecture: NSA vs SA, CU/DU Split, and CA
- RSRP vs RSRQ vs SINR
- LTE-Advanced
Practice
Essential AI-Native Skills for 5G NR Handover: Xn vs N2, Conditional HO, Beam Failure Recovery
Modern engineering work increasingly uses AI tools for design and code review, debugging, documentation, test and testbench generation, and workflow automation. The goal is not to let AI replace engineering judgment — it is to move faster while keeping verification discipline.
- Use AI to explain unfamiliar code, logs, waveforms, datasheets, or test failures.
- Break large problems into small, reviewable steps you can verify independently.
- Ask AI for hypotheses, then validate them against tests, measurements, simulations, or lab data.
- Version-control your analysis scripts, testbenches, and configs — keep changes small and reviewable.
- Document your assumptions, design tradeoffs, and debugging decisions.
- Verify AI output before trusting it: run the checks that fit the domain — unit tests, linters, simulations, or bench/lab measurements.
- Review AI output for correctness, edge cases, and real-world consequences.
5G NR Handover: Xn vs N2, Conditional HO, Beam Failure Recovery — coming to the question bank
The adaptive practice engine is already live for core wireless, RF, and ML systems. 5G NR Handover: Xn vs N2, Conditional HO, Beam Failure Recovery isn't covered in the question bank yet — get notified when it's added.