🗂️ RRC — Radio Resource ControlIntermediate

Handover Overview (how mobility is triggered) in 5G NR

The full mobility chain: measConfig → measurement → MeasurementReport → HO decision → RRCReconfiguration with reconfigurationWithSync.

📚 3GPP-basedTS 38.300TS 38.331

An RRC_CONNECTED UE has one radio connection and a context that cannot be cheaply rebuilt -- keys, PDCP state, DRB mappings, an N3 tunnel at the UPF. Handover is the family of procedures that moves that connection to a different cell without the bearer noticing. This document is the framework for the family: the complete taxonomy from intra-DU to inter-RAT, the decision that selects among them, the three-phase structure they all share, the single IE (reconfigurationWithSync) that executes every one of them, T304 and its failure semantics, the interruption budget broken down step by step with a worked total, the too-early / too-late / wrong-cell taxonomy that MRO is built on, and key derivation across the boundary. The procedural detail lives in the companions: 23 Xn Handover, 24 NG / N2 Handover and 25 Conditional HO and DAPS.

Contents

01Why Handover Exists, and What It Must Not Break
02The Handover Family: A Complete Taxonomy
03Choosing the Handover Type
04The Universal Phase Structure
05What Starts It: Measurement-Triggered Mobility
06The Handover Decision at the Source
07reconfigurationWithSync: the Whole Execution Phase in One IE
08T304, and What Its Expiry Means
09Access at the Target: CFRA, CBRA and RACH-Less
10Data Forwarding, in Concept
11The Interruption Time Budget
12What the Special Modes Do to the Interruption
13Failure Modes, and the Too-Early / Too-Late / Wrong-Cell Taxonomy
14Key Derivation Across Handover
15Mobility Robustness, Ping-Pong, and the Parameters That Control It
16Configuration Reference (ASN.1 and Ranges)
17Illustrative Message Traces
18Release Deltas: Rel-15 to Rel-18
19Reading Handover in Logs: A Checklist
20Glossary
21References

1. Why Handover Exists, and What It Must Not Break

A UE in RRC_IDLE that finds a better cell simply moves to it. It re-reads system information, and if it needs to send anything it starts a fresh random access. Nothing is lost because nothing was in flight. That is cell reselection, and it is entirely the UE's decision.

A UE in RRC_CONNECTED cannot do that. It is holding state that took real signalling to build and that exists in several places at once: a C-RNTI the target has never heard of, PDCP sequence-number and reordering state per DRB, an AS security context derived from a key the target does not have, a QoS-flow-to-DRB mapping the target must reproduce exactly, and an N3 GTP-U tunnel at the UPF pointing at the source gNB's transport address. Throw any one of those away and the bearer breaks -- a TCP connection stalls, a voice call gaps, an in-order-delivery bearer delivers out of order. So mobility in RRC_CONNECTED is network-controlled and stateful: the UE measures and reports, but the network decides, prepares the destination, and hands the UE a complete instruction telling it exactly where to go and how to get in.

What must survive	Where it lives	How it survives the handover	What it looks like when it does not
Radio identity	C-RNTI, cell-local	The target allocates a new C-RNTI and puts it in `newUE-Identity`; the old one is meaningless at the target.	UE transmits with the wrong RNTI; the target never schedules it, T304 expires.
AS security context	K_gNB and derived keys, at UE and source gNB	Source derives `K_NG-RAN*` from the target PCI and ARFCN and ships it in the preparation message; UE derives the same value from the NCC it is given (§14).	Integrity check failure on the first message at the target, or a failed `RRCReconfigurationComplete` MAC-I.
PDCP state	PDCP entity, per DRB, at UE and source gNB	SN Status Transfer carries the UL and DL SN and HFN per DRB so the target continues the same numbering (§10).	Duplicate or discarded PDUs, reordering timer expiries, an in-order bearer delivering a gap.
Bearer configuration	`RadioBearerConfig`, QoS flow to DRB map	Copied into the UE Context Information in the preparation message; the target reproduces it or refuses the PDU session.	A partially admitted handover: some flows survive, others are dropped silently.
User-plane path	N3 tunnel endpoint at the UPF	Path switch at the very end, after the UE has already arrived; forwarding tunnels cover the interval.	Downlink data continues to the source gNB and is discarded there.
UE capabilities	UE, and the source's stored container	Relayed unmodified as a container -- the target does not ask the UE again (companion 26 UE Capability).	The target configures something the UE cannot do; the UE fails the reconfiguration.

Table 1. Six things that have to be carried across a cell boundary, and the mechanism that carries each. Every message in every handover procedure exists to move one of these.

💡

Key point

The fundamental constraint is simpler than the procedure: the UE has one SpCell for its master cell group and one set of RF chains tuned to it. Moving is therefore break-before-make by default, and the break is measured in tens of milliseconds. Every special execution mode in §12 -- Conditional Handover, DAPS, LTM -- is an attempt to shrink or hide that break without changing the constraint.

2. The Handover Family: A Complete Taxonomy

"Handover" covers five structurally different procedures and four execution styles, and they compose: an Xn handover can be conditional, an intra-DU cell change can use LTM. The two axes are independent, and reading a log gets much easier once you know which cell of the grid you are in.

2.1 By interface and scope

Scope	What changes	Control-plane signalling	Path switch?	Covered in
Intra-gNB, intra-DU	Serving cell only. Same CU, same DU, same PDCP and RLC entities.	gNB-CU authors the `RRCReconfiguration`; F1AP UE CONTEXT MODIFICATION REQUEST to the DU carries the new cell and the CFRA resources. No Xn, no NGAP.	No	This document (§3)
Intra-gNB, inter-DU (over F1)	Serving cell and the DU. PDCP stays in the CU; RLC and MAC are rebuilt at the new DU.	F1AP UE CONTEXT SETUP at the target DU, then UE CONTEXT MODIFICATION at the source DU to stop transmission, then UE CONTEXT RELEASE. Data is re-routed internally over F1-U.	No	This document (§3); F1AP detail in 23
Inter-gNB over Xn	Serving cell, DU, CU, and the RAN-side N3 endpoint.	XnAP HANDOVER REQUEST / HANDOVER REQUEST ACKNOWLEDGE, SN STATUS TRANSFER, UE CONTEXT RELEASE; then NGAP PATH SWITCH REQUEST.	Yes	23 Xn Handover
Inter-gNB over NG / N2 (no Xn)	Same as Xn, but with no direct interface between the gNBs.	NGAP HANDOVER REQUIRED -> AMF -> HANDOVER REQUEST / ACKNOWLEDGE -> HANDOVER COMMAND -> HANDOVER NOTIFY. Also the only option when the AMF itself changes.	Yes (via the AMF)	24 NG / N2 Handover
Inter-RAT, NR to E-UTRA	The RAT. Bearer contexts and security are translated across the boundary.	`MobilityFromNRCommand` with `targetRAT-Type = eutra` and a `targetRAT-MessageContainer` holding a complete E-UTRA `RRCConnectionReconfiguration`. Carried over Xn to an ng-eNB or over NG/N2.	Yes	Outlined here; see 24
Intra-cell	Nothing moves. Same PCI, same everything.	`reconfigurationWithSync` pointing at the current cell. Used to force a key refresh, reset PDCP and RLC, or recover a wedged UE context.	No	Companion 27 AS Security Mode

Table 2. The interface axis. Note that the first two rows and the last involve no core-network signalling at all -- from the 5GC's point of view nothing happened.

⚠️

Common pitfall

The intra-DU case is the one most often missed when reading logs, because it produces no Xn and no NGAP traffic whatsoever -- just one F1AP UE CONTEXT MODIFICATION and an air-interface reconfiguration. A site that appears to have "no handovers" in its Xn statistics may be doing thousands per hour internally. Count reconfigurationWithSync occurrences, not XnAP messages.

2.2 By execution style

Mode	Release	What is different	Typical interruption	Main constraint
Baseline ("hard") handover	Rel-15	The UE releases the source the moment it applies the command, then acquires the target. One candidate, one command, one attempt.	20-50 ms	The command must reach the UE while the source link still works -- which is exactly when it is least likely to.
Conditional Handover (CHO)	Rel-16	The UE is given up to eight complete stored `RRCReconfiguration`s in advance, each with an execution condition (`CondEvent A3` / `A5`, and `A4` from Rel-17). The UE evaluates and executes on its own.	10-20 ms	Targets must hold reserved resources for candidates that may never arrive. Does not help if all candidates degrade together.
DAPS handover	Rel-16	The UE keeps the source link and the target link up simultaneously, per DRB, until the network sends an explicit source release.	~0 ms	Two active protocol stacks: intra-frequency only in practice, no CA on the target during DAPS, high UE complexity, limited device support.
RACH-less handover	Rel-16 (LTE Rel-14 origin)	The target supplies a preallocated uplink grant and a TA value, so the UE skips the preamble entirely.	saves 5-15 ms	Only safe when the target already knows the UE's timing -- co-sited cells, or a source that can supply a usable TA.
LTM -- L1/L2-triggered mobility	Rel-18	Candidate cell configurations are pushed in advance by RRC, then the switch is commanded by a MAC CE rather than an RRC message. Optional early TA acquisition and RACH-less switch.	1-5 ms	Confined to intra-CU cell switches in Rel-18; needs the candidate set kept fresh, and UE support.

Table 3. The execution axis. Interruption figures are engineering expectations, not spec requirements; see §11 and §12 for where they come from. CHO, DAPS and LTM are the subject of the companion 25 Conditional HO and DAPS.

💡

Key point

All five execution styles use the same reconfigurationWithSync to actually move (§7). CHO changes when the UE is told; DAPS changes when the source is released; LTM changes what carries the command. None of them changes what the UE does once it starts moving. If you can read one execution phase you can read all of them.

3. Choosing the Handover Type

The choice is not a policy decision -- it falls out of topology. The source knows which cells it serves itself, which gNBs it has an Xn association with (from the Xn Setup exchange, see 23), and which cells the AMF has forbidden for this UE. That is enough to determine the interface uniquely.

Figure 1. Interface selection. The only genuinely discretionary node is the last one: a source that has Xn to the target may still be configured to prefer NG/N2 for a specific neighbour, for example across an operator boundary.

Input	Where the source gets it	Effect on the choice
Own served cell list	Local configuration	Target in the list -> intra-gNB. Decided first, because it is the cheapest outcome.
gNB-DU cell mapping	F1 Setup Response from each DU TS 38.473	Distinguishes intra-DU from inter-DU, which decides whether the DU needs a UE CONTEXT SETUP.
Xn neighbour table	Xn Setup Response and NG-RAN Node Configuration Update TS 38.423	Lists each Xn peer's served cells with their NR-CGI, PCI, TAC and supported PLMNs. No entry -> NG/N2.
Mobility Restriction List	NGAP INITIAL CONTEXT SETUP REQUEST, per UE TS 38.413	Forbidden TAs, PLMNs and RATs for this UE. A target inside a forbidden area is removed from the candidate set before any interface question is asked.
Handover restriction for the slice	Allowed NSSAI and per-slice policy	A target that cannot serve the UE's active slices will fail admission; a good implementation filters it out first.
Neighbour relation table state	ANR / OAM, plus MRO feedback	A neighbour relation flagged no-HO (for example after repeated too-early failures) is excluded even though Xn exists.

Table 4. What the source consults before it can name an interface. The first four are hard constraints; the last two are policy.

4. The Universal Phase Structure

Every handover in the family -- intra-DU, Xn, NG/N2, inter-RAT, conditional, DAPS -- decomposes into the same three phases. Learning them once is what makes the rest of the family legible.

Figure 2. The three phases and their division of labour. The single most useful fact on this figure is in the bottom row.

Phase	Starts when	Ends when	Who can still recover a failure
Preparation	The source's RRM decides to move the UE to a named target cell.	The source holds a complete target-authored `RRCReconfiguration` and the target holds reserved resources.	Everyone. The UE has not been told anything and is still served normally. A preparation failure is invisible to the user -- the source can pick another target, or do nothing.
Execution	The UE receives and applies the `RRCReconfiguration` containing `reconfigurationWithSync`. T304 starts.	Random access at the target succeeds and `RRCReconfigurationComplete` is transmitted. T304 stops.	Only the UE, and only until T304 expires. No network message can reach it: the source has been released and the target has not yet heard from it. This is the phase where handovers are actually lost.
Completion	The target has the UE on its SRB1.	The N3 tunnel points at the target and the source has released the UE context.	The network. The UE already has service. A slow or failed path switch costs downlink throughput and buffer, not the connection -- unless it fails hard, in which case the target releases the UE.

Table 5. The three phases, TS 38.300 cl. 9.2.3.2, with the recovery question that matters most at 2am.

Figure 3. One generic ladder that covers the whole family. Compare it against the Xn-specific ladder in 23 and the NG/N2 ladder in 24: the top and bottom bands change, the middle band does not.

💡

Key point

Only the preparation phase differs meaningfully between Xn and NG/N2. Preparation is a direct XnAP round trip in one case and an NGAP detour through one or two AMFs in the other, which is worth 5-10 ms against 20-40 ms and is the entire performance argument for Xn. Execution is byte-identical. Completion differs only in which message asks the core to move the tunnel. Do not learn two procedures; learn one and two preparation phases.

5. What Starts It: Measurement-Triggered Mobility

Almost every handover in a live network begins with a MeasurementReport. The source configures the UE with a MeasConfig containing measurement objects (a carrier plus an SSB or CSI-RS configuration), report configurations (an event plus its parameters), and measId values binding one object to one report configuration. The UE then evaluates the event condition continuously on its L3-filtered measurements and reports when the condition has held for timeToTrigger. The mechanics are the subject of the companion 20 Measurements and Events; what matters here is which events lead to a handover and why.

Event	Condition, informally	What a handover based on it means	Where it is normally used
A1	Serving cell becomes better than a threshold	Not a handover trigger. Used to stop inter-frequency measurement and release measurement gaps.	Gap and battery management (companion 21)
A2	Serving cell becomes worse than a threshold	Not itself a handover trigger, but usually the event that turns inter-frequency measurement on, so it precedes one.	Arming the inter-frequency search
A3	Neighbour becomes better than serving by an offset	The classic coverage handover. Relative, so it works at any absolute level and adapts to the whole cell edge.	Intra-frequency and equal-priority inter-frequency mobility
A4	Neighbour becomes better than a threshold	Absolute, so it ignores how good the serving cell is. Used for load-balancing handovers -- moving a UE that does not need to move.	Load balancing, and CHO conditions from Rel-17
A5	Serving worse than threshold1 and neighbour better than threshold2	The coverage-driven handover with a floor: only move when the serving cell is genuinely bad and somewhere decent exists.	Inter-frequency coverage layers, VoNR retention
A6	Neighbour becomes better than an SCell by an offset	SCell change, not PCell handover.	Carrier-aggregation SCell management
B1 / B2	Inter-RAT neighbour better than threshold (B1); serving worse and inter-RAT better (B2)	Inter-RAT handover to E-UTRA. B2 is the coverage fallback; B1 is policy-driven.	NR to LTE fallback, EPS fallback for voice

Table 6. Reporting events, TS 38.331 cl. 5.5.4.2 to 5.5.4.9, seen from the handover side. A2 and A1 are included because they explain why an A3 report can arrive hundreds of milliseconds later than you expected.

Two properties of the reporting chain matter for handover timing. First, the UE reports L3-filtered values, not raw ones: F_n = (1 - a)·F_(n-1) + a·M_n with a = 1 / 2^(k/4) and k = filterCoefficient TS 38.331 cl. 5.5.3.2. A filterCoefficient of fc8 gives a = 0.25, which smooths fading but adds hundreds of milliseconds of lag to a genuine trend. Second, timeToTrigger adds a deliberate delay on top. Both are there to suppress ping-pong, and both directly increase the chance of a too-late handover (§13).

🔍

What you see in logs

A handover that looks late in a log is frequently not a late decision. Add up filterCoefficient lag plus timeToTrigger plus reportInterval before blaming the RRM. With fc8, timeToTrigger = ms320 and a 30 kHz reportInterval of 240 ms, a genuine 10 dB drop can take most of a second to surface -- and the UE was moving during all of it.

6. The Handover Decision at the Source

This is the part of handover that 3GPP does not specify. TS 38.331 defines exhaustively how the UE measures and reports and how it executes a command; it says nothing about when a gNB shall hand a UE over. The decision is vendor RRM, and it is the single largest source of behavioural difference between two networks running the same release.

Decision input	Typical use	Why it is not in the spec
The triggering measurement report	The primary input: which neighbour, how much better, on which beams.	The spec defines the report, not the response.
Cell individual offset (`cellIndividualOffset`)	Per-neighbour bias, ±24 dB, applied by the UE inside the event evaluation. Used to make a cell attractive or unattractive without touching the event parameters.	It is in the spec -- but choosing its value is policy. It is the most-abused mobility knob in existence.
Target cell load	Xn Resource Status Reporting, or OAM. A better neighbour that is congested may be skipped in favour of a worse one.	Load exchange is specified; the trade-off is not.
Slice and QoS admissibility	Will the target admit the UE's 5QI set and slices? A guaranteed-bitrate flow that the target cannot honour argues against the move.	Admission is the target's decision; anticipating it is the source's optimisation.
Beam-level information	`reportQuantityRS-Indexes` gives the source per-beam RSRP at the target. Used to pick the CFRA resource and to judge whether the target coverage is real or a single lucky beam.	Reported optionally; interpreting it is policy.
UE speed / mobility history	`speedStateReselectionPars`-style estimation, or the count of recent handovers. A fast UE may be sent to a macro layer rather than a small cell it would leave immediately.	Speed-state scaling exists for idle mode; connected-mode use is vendor.
Recent failure history for the relation	MRO feedback: a neighbour relation with a high too-early rate gets a larger offset or is barred.	MRO defines the reports (§13), not the reaction.

Table 7. What a real RRM weighs. Only the second row is standardised, and only its encoding.

Figure 4. An A3 evaluation drawn as the inequality it actually is: the neighbour has to beat a level derived from the serving cell, not the serving cell itself. Raising cellIndividualOffset lowers that level and so triggers earlier.

6.1 Worked example: an A3-triggered decision

The A3 entering condition TS 38.331 cl. 5.5.4.4 is Mn + Ofn + Ocn - Hys > Mp + Ofp + Ocp + Off, and the leaving condition is the same with + Hys on the left and the inequality reversed. Mn and Mp are the L3-filtered neighbour and serving RSRP in dBm; Ofn/Ofp are the measurement-object offsets (offsetMO); Ocn/Ocp are the cell individual offsets; Off is a3-Offset; Hys is hysteresis.

🧮

Worked calculation

Both cells intra-frequency, so Ofn = Ofp = 0. Ocp = 0.

a3-Offset = 6 (units of 0.5 dB) -> Off = 3 dB

hysteresis = 4 (units of 0.5 dB) -> Hys = 2 dB

cellIndividualOffset for the neighbour = dB2 -> Ocn = +2 dB

At t = 800 ms: Mp = -95 dBm, Mn = -93 dBm

left = -93 + 0 + 2 - 2 = -93

right = -95 + 0 + 0 + 3 = -92

-93 > -92 is false -> condition not entered.

At t = 900 ms: Mp = -96 dBm, Mn = -92 dBm

left = -92 + 2 - 2 = -92

right = -96 + 3 = -93

-92 > -93 is true -> enter A3, start timeToTrigger (ms320).

At t = 1220 ms the condition still holds, so the UE sends the MeasurementReport.

Now remove the cell individual offset (Ocn = 0):

left = -92 - 2 = -94, right = -93 -> false. The condition would not be entered until Mn - Mp exceeded 5 dB rather than 3 dB. The two cells are closing at 2 dB per 100 ms, so that is 100 ms later and 2 dB deeper into the serving cell's decline -- on top of the 320 ms of timeToTrigger that still has to elapse afterwards.

⚠️

Common pitfall

cellIndividualOffset is evaluated by the UE, inside the event, and it is per measurement object entry -- so it is asymmetric by construction. Cell A can be configured to see cell B as +3 dB while cell B sees cell A as 0 dB. That asymmetry is the standard cure for ping-pong and the standard cause of one-way coverage holes: raise it too far and UEs hand over into B early and then refuse to come back, sitting in B's edge with a perfectly good A available.

7. reconfigurationWithSync: the Whole Execution Phase in One IE

There is no "handover command" message in NR. There is an ordinary RRCReconfiguration whose masterCellGroup contains a spCellConfig containing a reconfigurationWithSync. The presence of that one IE is what turns a reconfiguration into a handover: it tells the UE to perform a synchronous reconfiguration towards the cell described inside it, which means resetting MAC, re-establishing RLC, re-establishing PDCP for the affected bearers, applying the new security key, starting T304, and acquiring the target TS 38.331 cl. 5.3.5.5.2.

Field	Presence	Values	What it does, and what happens without it
`spCellConfigCommon`	Optional but always present in practice	`ServingCellConfigCommon`: `physCellId`, `downlinkConfigCommon` (frequency info, initial DL BWP), `uplinkConfigCommon` (including `rach-ConfigCommon`), `ssb-PositionsInBurst`, `ssbSubcarrierSpacing`, `tdd-UL-DL-ConfigurationCommon`, `n-TimingAdvanceOffset`	The target cell's broadcast configuration, handed to the UE so it does not have to read the target's SIB1 before accessing it. Omitting it is only legal for an intra-cell reconfiguration; on a real handover its absence would add a full SI acquisition to the interruption.
`newUE-Identity`	Mandatory	`RNTI-Value`, 0x0001..0xFFEF	The C-RNTI the UE will use at the target. Allocated by the target during preparation, which is why the source cannot author the message itself.
`t304`	Mandatory	`ms50, ms100, ms150, ms200, ms500, ms1000, ms2000, ms10000`	The execution-phase deadline (§8). Started on applying this IE, stopped on successful random access at the target.
`rach-ConfigDedicated`	Optional	CHOICE { `uplink`, `supplementaryUplink` } of `RACH-ConfigDedicated`, which carries `cfra` (per-SSB or per-CSI-RS preamble assignments) and `ra-Prioritization`	Contention-free access at the target. Absent -> the UE falls back to contention-based access using the `rach-ConfigCommon` inside `spCellConfigCommon`, which adds contention risk and typically 5-10 ms (§9).
`smtc`	Optional (Rel-15 extension group)	`SSB-MTC`: periodicity, offset and duration	The SSB measurement timing configuration to use at the target before any dedicated `MeasConfig` arrives, so the UE knows where to look for SSBs immediately on arrival. Absent -> the UE uses the source's assumption, which is wrong if the target's SSB timing differs.

Table 8. Every field of ReconfigurationWithSync, TS 38.331. Five fields -- and between them they are the entire execution phase.

🔍

What you see in logs

reconfigurationWithSync is also how a PSCell is added or changed in NR-DC: the same IE appears inside secondaryCellGroup instead of masterCellGroup, with its own T304 instance. When you see T304 in a log, check which cell group it belongs to before concluding that the PCell moved.

📘

Spec detail

The security part of the handover is not in reconfigurationWithSync. The Next Hop Chaining Count arrives separately, in masterKeyUpdate inside the securityConfig of the same RRCReconfiguration: MasterKeyUpdate ::= SEQUENCE { keySetChangeIndicator BOOLEAN, nextHopChainingCount NextHopChainingCount, nas-Container OPTIONAL }. Two IEs, two branches of the message, one handover -- and a UE that applies one without the other fails integrity protection on its first uplink message at the target. See §14 and the companion 27 AS Security Mode.

8. T304, and What Its Expiry Means

T304 is the only timer that governs the execution phase, and it is the only thing standing between a UE that cannot reach its target and a UE that never comes back. It starts when the UE applies the reconfigurationWithSync and stops on successful completion of random access at the target SpCell TS 38.331 cl. 7.1. While it runs, the UE has no source link and no target link.

Timer / counter	Where configured	Values	Starts / stops	On expiry
`T304` (MCG)	`reconfigurationWithSync` in `masterCellGroup`	ms50 .. ms10000; ms100-ms200 common in FR1	Start: applying `reconfigurationWithSync`. Stop: random access at the target SpCell succeeds.	Handover failure. Revert to the source PCell configuration, store the failure in `VarRLF-Report`, and initiate RRC re-establishment TS 38.331 cl. 5.3.5.8.3.
`T304` (SCG)	`reconfigurationWithSync` in `secondaryCellGroup`	same range	Same, for the PSCell.	SCG failure. `SCGFailureInformation` is sent on the MCG, which still works -- so this does not break the connection.
`T310`	`UE-TimersAndConstants` in SIB1 or dedicated	ms0 .. ms2000, ms1000 common	Start: N310 consecutive out-of-sync indications. Stop: N311 in-sync, or handover, or re-establishment.	Radio link failure on the source -- the too-late handover case (§13). See companion 16 RLM and RLF.
`T311`	`UE-TimersAndConstants`	ms1000 .. ms30000	Start: re-establishment initiated. Stop: a suitable cell is found.	Go to RRC_IDLE with release cause `rrc-Connection-Failure`. This is where a failed handover becomes a dropped call.
`preambleTransMax`	`rach-ConfigGeneric` at the target	n3 .. n200, n10 common	Counts preamble attempts at the target.	Random Access problem indication to RRC. During handover this does not end the procedure -- T304 keeps running (see the companion 03 Random Access).
`T312`	`RLF-TimersAndConstants` (Rel-16)	ms0 .. ms1000	Start: T310 running and a measurement report for a mobility-triggering event is sent. Stop: T310 stops.	Declares RLF early, on the grounds that a report has already been sent and no handover command came. Shortens the too-late failure.

Table 9. The timers that bound a handover, and which failure each one produces. Note that only T304 is carried in the handover command itself.

8.1 Worked example: sizing T304 against the RACH it must accommodate

🧮

Worked calculation

Target cell: 30 kHz SCS, PRACH configuration with occasions every 10 ms, ra-ResponseWindow = sl20 (20 slots at 30 kHz = 10 ms), CFRA allocated, preambleTransMax = n10.

Fixed cost before the first preamble can go out:

retune + fine sync on the target SSB ...................... 4 ms

wait for the first PRACH occasion (worst case) ............ 10 ms

Cost of one failed attempt:

preamble + full ra-ResponseWindow ......................... 10 ms

wait for the next occasion ................................ 10 ms

-> 20 ms per retry

With t304 = ms100: (100 - 14) / 20 = 4.3 -> 4 attempts fit.

With t304 = ms50: (50 - 14) / 20 = 1.8 -> 1 attempt fits.

preambleTransMax = n10 would need 14 + 9x20 = 194 ms to be reachable. It never is. T304, not the counter, is the operative limit on every handover.

⚠️

Common pitfall

Because T304 always expires before preambleTransMax in any sane configuration, a handover failure log shows a timer expiry and only two, three or four preamble attempts -- not the ten you would see on initial access. Engineers who expect the counter to be the limit read "only 3 preambles sent" as a UE bug. It is not; it is arithmetic. Conversely, setting t304 = ms50 in a cell whose PRACH periodicity is 20 ms guarantees a single-shot handover with no retry at all, which turns every lost preamble into a handover failure.

Figure 5. The UE's execution-phase behaviour. Both failure edges lead to the same place, and the re-establishment that follows is what makes a handover failure expensive -- hundreds of milliseconds, not tens.

9. Access at the Target: CFRA, CBRA and RACH-Less

How the UE gets its first uplink grant at the target is the largest controllable term in the interruption budget. Three options exist, and which one is in use is visible in the handover command.

Option	What the command contains	Cost at the target	When it is used	Failure signature
CFRA	`rach-ConfigDedicated` -> `cfra` with a `ra-PreambleIndex` per SSB (or per CSI-RS)	One preamble, one RAR. No contention, no MSG3, no contention resolution.	The normal case for handover. The target reserves an index out of the same 64-preamble space it uses for CBRA.	No RAR: either the reserved index was released, or the UE is on an SSB with no allocated resource.
CBRA fallback	`rach-ConfigDedicated` absent, or present but with no resource for the SSB the UE actually selects	Full 4-step access plus contention resolution: typically 5-10 ms more than CFRA, with a collision probability.	When the target could not spare a dedicated preamble, or the UE arrives on an unexpected beam.	Contention-resolution mismatches in a handover trace -- which should never happen and always means the CFRA path was not taken.
RACH-less	A preallocated uplink grant plus a timing advance value, so no preamble is sent at all	Saves the PRACH occasion wait and the RAR window entirely.	Co-sited or tightly synchronised cells where the source's TA is valid at the target; also the LTM early-TA case.	The first uplink transmission is simply not received, and T304 expires with no preamble anywhere in the log.

Table 10. Target access options. The CFRA preamble is allocated per SSB, which is why the source's beam-level measurement report matters to the target's preparation.

⚠️

Common pitfall

CFRA preambles come out of the target cell's 64-preamble budget, bounded against CBRA by totalNumberOfRA-Preambles. A cell with heavy inbound mobility and a generous CBRA allocation runs out of dedicated preambles and quietly starts admitting handovers with CBRA instead. The symptom is not a failure -- it is a slow, gradual rise in mean interruption time and in handover failure rate under load. See the companion 03 Random Access §2.

10. Data Forwarding, in Concept

During the execution phase the UPF is still sending downlink data to the source gNB, because the path switch has not happened yet -- and cannot, because the core has no idea whether the UE will arrive. That data has to go somewhere. Data forwarding is the mechanism that gets it to the target, and it is the reason a well-implemented handover is lossless rather than merely brief.

Concept	What it is	Who sets it up	Cost / consequence
Direct forwarding	A GTP-U tunnel from the source gNB straight to the target gNB, carrying buffered and newly arriving downlink PDCP SDUs.	Target allocates the tunnel endpoint during preparation and returns it in the preparation response; source starts using it immediately.	One extra transport hop, a few milliseconds. Requires user-plane connectivity between the two gNBs -- which is the Xn-U case.
Indirect forwarding	The same data routed source -> UPF -> target, because there is no usable direct path.	The AMF/SMF sets up the intermediate tunnels as part of the preparation.	Two extra hops and a longer, more variable delay. The normal case for NG/N2 handover and for inter-operator boundaries.
SN status transfer	The source tells the target the current uplink and downlink PDCP SN and HFN per DRB, plus the receive status bitmap for PDUs it has not yet delivered in order.	Source, once it has committed to the handover -- so it must be sent after the command goes to the UE and before the target starts delivering.	Omit it and the target restarts SN numbering; the UE's PDCP discards everything as out of window.
End marker	A one-PDU GTP-U message the UPF sends down the old N3 tunnel after it has switched to the new one.	UPF, on completing the path switch.	It is the target's signal that no more in-order data will arrive over the forwarding tunnel, so it can stop reordering and tear the tunnel down.
In-order delivery at the target	The target must interleave forwarded PDUs (older SNs) with freshly arriving ones (newer SNs) so PDCP delivers in sequence.	Target PDCP, using the transferred SN state.	Gets this wrong and the bearer delivers out of order or stalls on a reordering timer -- visible as a throughput dip after a successful handover.

Table 11. Forwarding concepts, framed generally. The GTP-U tunnel details, the exact SN status contents and a worked buffer-size calculation are in 23 (Xn-U) and 24 (indirect via the UPF).

💡

Key point

Forwarding is what makes the interruption an interruption rather than a loss. Nothing is dropped: the packets that arrived while the UE was in the air are buffered, forwarded and delivered late. The application sees a latency spike of roughly the interruption time, not a gap -- which is why a handover that measures 30 ms of interruption does not cost a TCP retransmission, and why one that measures 300 ms does.

11. The Interruption Time Budget

The user-visible cost of a handover is the interval during which the UE can neither transmit nor receive user data. It begins when the UE releases the source -- which it does as soon as it applies the reconfigurationWithSync, not when it starts moving -- and ends when it has an uplink grant and a downlink assignment at the target. Everything before that (measurement, reporting, preparation) is free, because the source is still serving the UE.

Figure 6. The same 26 ms shown four ways: what the source sees, what the UE is doing, what the target sees, and what the application experiences. Note that the source-facing lane goes quiet at t = 0 -- the UE releases the source before it has looked at the target once.

Step	Typical	Dominated by	Reducible by
a. Decode and apply the `RRCReconfiguration`	10 ms	The RRC processing delay allowance -- a UE requirement, not a radio effect TS 38.331 cl. 12	CHO and LTM: the target configuration is already stored and largely processed.
b. Release the source, retune the RF chain	0.5 - 1 ms	RF settling; negligible for an intra-frequency handover	Nothing, except not doing it (DAPS).
c. Fine time/frequency sync on the target SSB	2 - 20 ms	SSB periodicity and whether the target was already being measured. 20 ms `ssb-periodicityServingCell` is the common case.	Keeping the target in the measurement object; LTM candidate maintenance; `smtc` in the handover command.
d. Wait for a PRACH occasion	0 - 10 ms (mean = half the period)	`prach-ConfigurationIndex` at the target	Denser PRACH configuration; RACH-less handover removes it entirely.
e. Transmit the preamble	0.1 - 1 ms	Preamble format	Nothing meaningful.
f. Wait for and decode the RAR	2 - 10 ms	`ra-ResponseWindow` and target scheduler latency	RACH-less handover; a shorter response window if the target can meet it.
g. Apply TA, build and send `RRCReconfigurationComplete`	1 - 2 ms	The granted PUSCH occasion	Nothing meaningful.
h. Target schedules the first downlink PDSCH	1 - 2 ms	Whether forwarded data has already arrived at the target	Starting forwarding early -- i.e. at SN status transfer, not at path switch.

Table 12. The interruption, step by step. Steps a, c and d account for most of it, and none of the three is a radio-quality problem.

🧮

Worked calculation

FR1, 30 kHz SCS. Target already in the measurement object and coarsely SSB-synchronised. PRACH occasions every 10 ms. CFRA allocated.

a RRC decode + apply ..................... 10.0 ms

b release source, retune ................. 1.0 ms

c fine sync on target SSB ................ 3.0 ms

d wait for the next PRACH occasion (mean) 5.0 ms

e preamble transmission .................. 0.5 ms

f RAR window until decoded ............... 3.0 ms

g TA applied, Complete transmitted ....... 2.0 ms

---------------------------------------------------

UE is off the air from a to g .......... 24.5 ms

h first forwarded DL PDSCH at the target . 1.5 ms

---------------------------------------------------

Total user-plane interruption .......... 26.0 ms

Worst realistic case, same cell pair: the target SSB has to be found from scratch (c -> 20 ms, +17) and PRACH occasions are every 20 ms (d -> 10 ms mean, +5), with one lost preamble (+20):

26.0 + 17 + 5 + 20 = 68 ms, and T304 = ms100 barely covers it.

💡

Key point

Two thirds of the best case is spent on things that have nothing to do with the radio: 10 ms of RRC processing allowance and 5 ms waiting for a PRACH occasion. This is why the interruption has stayed stubbornly in the tens of milliseconds across releases while the physical layer got much faster, and why the Rel-16 and Rel-18 mobility work attacks the procedure rather than the link.

12. What the Special Modes Do to the Interruption

Figure 7. Each mode removes a different block of the budget. Read this against the step table in §11: CHO deletes step a, RACH-less deletes d-f, DAPS deletes the concept of a break, LTM deletes most of everything but needs the candidate set kept warm.

Mode	What it deletes from the budget	What it costs instead	What it does not fix
Conditional Handover	Step a almost entirely: the `RRCReconfiguration` was delivered and processed while the source link was still good, so only the execution trigger is on the critical path.	Reserved resources at every candidate target, held for the lifetime of the conditional configuration; and a late `HANDOVER CANCEL` to each candidate that was not used.	The access itself -- steps c to g are unchanged. CHO's real value is robustness: it removes the risk of the command not arriving, which is the dominant cause of too-late failures.
DAPS	All of it. The source link stays up and continues to carry data until the network explicitly releases it, so there is no interval with no serving cell.	Two simultaneous protocol stacks in the UE; a PDCP entity that must receive from both cells and deduplicate; restrictions on carrier aggregation and on the frequency relationship between source and target.	Anything that is not a coverage handover -- DAPS is generally restricted to intra-frequency, and device support is far from universal.
LTM (Rel-18)	Steps a, d, e and f, in the best case: candidate configuration is pre-applied, the switch command is a MAC CE (one slot, not an RRC round trip), and TA may be pre-acquired so the switch is RACH-less.	Continuous L1 measurement and reporting on candidate cells; candidate configurations that must be kept fresh; confinement to intra-CU cell switches in Rel-18.	Inter-gNB mobility, which still needs a full RRC handover in Rel-18.
RACH-less	Steps d, e and f -- typically 5 to 15 ms.	A preallocated grant that the target must hold, and a timing advance the target has to believe is valid.	Anything about the command delivery or the sync; and it is unsafe wherever the source's TA is not a good estimate at the target.

Table 13. Mode by mode. Full treatment in the companion 25 Conditional HO and DAPS; this table exists so that a reader can place a mode without leaving this document.

💡

Key point

CHO does not make handover faster in any interesting sense -- it makes it happen. The scenario CHO is built for is the one where the source link fails between the measurement report and the delivery of the handover command: with baseline handover that is a radio link failure and a re-establishment costing hundreds of milliseconds, and with CHO the UE already has the command and simply executes it. Comparing CHO to baseline on mean interruption time therefore understates it dramatically; compare tail latency, or handover failure rate.

13. Failure Modes, and the Too-Early / Too-Late / Wrong-Cell Taxonomy

13.1 Failure modes

What fails	Detected by	What happens next	What it points at diagnostically
Preparation rejected by the target	Source, on receiving a preparation failure	Nothing user-visible. The source may try another target, retry later, or keep the UE where it is.	Target admission control: capacity, slice support, an unsupported 5QI, or a UE capability the target cannot serve. Look at the cause value, not the fact of failure.
Preparation times out	Source, on its own preparation guard timer	Same as rejection, plus a `HANDOVER CANCEL` to the target if it eventually answers.	Transport between the gNBs, or an overloaded target CU. In the NG/N2 case, the AMF.
Handover command never reaches the UE	Nobody, directly. The UE declares RLF on the source instead.	T310 expires -> radio link failure -> re-establishment. Hundreds of milliseconds.	The classic too-late handover. Trigger thresholds too conservative, `timeToTrigger` too long, or filter lag. This is the case CHO exists for.
UE cannot find the target SSB	UE, when T304 expires with no successful access	Handover failure -> revert to the source configuration -> re-establishment.	Wrong `physCellId` or frequency in `spCellConfigCommon`; a stale neighbour relation pointing at a cell that has been reconfigured or switched off; PCI confusion between two cells with the same PCI.
Random access at the target fails	UE MAC, reported to RRC; T304 expires	Handover failure -> re-establishment. The RLF report records `ra-InformationCommon`.	CFRA resource released or never allocated; UE arrived on an SSB with no dedicated preamble; uplink coverage at the target worse than the downlink suggested; T304 too short for the target's PRACH periodicity (§8.1).
`RRCReconfigurationComplete` fails integrity	Target gNB	Target releases the UE context; the UE eventually re-establishes.	Key derivation mismatch -- NCC not applied, or the source derived `K_NG-RAN*` with the wrong target PCI/ARFCN (§14).
Path switch rejected or times out	Target gNB	Target releases the UE, or in some implementations falls back and asks the source to retain the context. The UE is on the air but its downlink path is wrong.	AMF or SMF state: the UE context the core holds does not match what the target claimed, or the PDU session was released concurrently. Rare, and always a core-network conversation.
Handover succeeds, then fails immediately	UE, via RLF at the target shortly after arrival	Re-establishment, in the source or in a third cell.	Too-early handover or handover to the wrong cell -- see below. Almost always a coverage or offset problem at the target, not a procedural one.
Repeated handovers between the same pair	OAM statistics; no failure anywhere	Nothing fails. Every handover succeeds.	Ping-pong (§15). Costs interruption, signalling and battery, and shows up as high handover rate with a normal success rate.

Table 14. Handover failure modes across all three phases. The middle rows are the expensive ones, because only they cost the user a re-establishment.

💡

Key point

There are exactly two moments in a handover where a failure costs the user real time, and both are in the execution phase: the command not arriving, and the target not being reachable. A preparation failure costs nothing and a completion failure costs throughput. When triaging, sort by phase first -- it is the fastest way to decide whether you are looking at an RF problem or a configuration problem.

13.2 Too early, too late, wrong cell

Mobility Robustness Optimisation classifies every mobility failure into one of three cases, and the classification is what makes automatic tuning possible. All three are distinguished from each other by only two pieces of information: how long the UE had been on its new cell when it failed, and which cell it re-established in.

Figure 8. The three cases. Rows two and three differ only in the last span -- which is exactly why the RLF report has to carry reestablishmentCellId and not just the fact of failure.

Case	What happened	How it is recognised	The usual fix
Too-late handover	The UE stayed on the source until the source link failed. Either no handover was triggered, or it was triggered but the command never arrived.	RLF on the source with no recent handover (`timeConnFailure` absent or large), and re-establishment in a cell that is not the source.	Trigger earlier: reduce `a3-Offset` or `timeToTrigger`, raise the neighbour's `cellIndividualOffset`, reduce filter lag. Or deploy Conditional Handover, which removes the command-delivery risk entirely.
Too-early handover	The handover succeeded, but the target could not actually hold the UE -- or the handover failed during execution and the source was still the best cell.	Failure shortly after a handover (`timeConnFailure` below a configured threshold), and re-establishment in the source cell -- `reestablishmentCellId` equals `previousPCellId`.	Trigger later or more conservatively for that relation: raise `a3-Offset`, add `hysteresis`, lower the target's `cellIndividualOffset`. Check whether the target's downlink coverage is real or a reflection.
Handover to the wrong cell	The handover succeeded or failed, and the UE ended up somewhere that was neither source nor target -- a better neighbour existed and was not chosen.	Failure shortly after a handover, and re-establishment in a cell that is neither `previousPCellId` nor the failed target.	Fix the neighbour relation and the candidate ranking: a missing neighbour relation, a wrong `cellIndividualOffset` making the wrong cell look best, or PCI confusion where two neighbours share a PCI.

Table 15. The MRO taxonomy. The threshold that separates "shortly after" from "later" is an implementation choice, commonly a few hundred milliseconds to a couple of seconds.

The UE supplies the evidence. On any RLF or handover failure it stores a report in VarRLF-Report, and it makes that report available to the next cell it successfully connects to, which fetches it with UEInformationRequest / UEInformationResponse. The RAN then redistributes the relevant part to the gNB that made the bad decision -- over Xn with the HANDOVER REPORT and FAILURE INDICATION messages TS 38.423.

RLF report field	What it carries	Its role in the classification
`connectionFailureType`	`rlf` or `hof`	Distinguishes a radio link failure on a serving cell from a handover failure (T304 expiry). `hof` immediately narrows the case to too-early or wrong-cell.
`failedPCellId`	NR-CGI or PCI+ARFCN of the cell where it went wrong	For `hof`, this is the target that could not be reached.
`previousPCellId`	The cell the UE was on before the last handover	The source. Comparing it with the re-establishment cell is what separates too-early from wrong-cell.
`reestablishmentCellId`	Where the UE actually recovered	The single most diagnostic field in the report.
`timeConnFailure`	Time from the last handover initialisation to the failure, in units of 100 ms	The "shortly after" test. Small -> the handover caused the failure; large or absent -> the handover was not the cause, so too-late.
`timeSinceFailure`	Time from the failure to the moment the report is delivered	Lets the receiving gNB judge whether the report is still relevant, and correlate it with its own logs.
`measResultLastServCell`, `measResultNeighCells`	RSRP/RSRQ/SINR of the serving cell and of neighbours at the moment of failure	Shows whether a better cell existed at the time -- which is what makes "wrong cell" provable rather than inferred.
`ra-InformationCommon`	The random access attempts made at the failed cell: preambles, SSB indices, contention detection	Separates "never heard the target" from "heard it and could not get in".
`rlf-Cause`	`t310-Expiry`, `randomAccessProblem`, `rlc-MaxNumRetx`, `beamFailureRecoveryFailure`, `lbtFailure`, ...	Points at the layer that gave up first, which usually points at the fix.

Table 16. RLF-Report fields relevant to mobility, TS 38.331 VarRLF-Report. The Rel-16 extension is the version that carries most of these; see the companion 16 RLM and RLF for the full structure and the retrieval procedure.

14. Key Derivation Across Handover

The target gNB must never be able to compute the keys the source was using, and ideally should not be able to compute the keys the next target will use. NR achieves both with a chained derivation TS 33.501 cl. 6.9. On every handover a fresh K_NG-RAN* is derived and becomes the target's K_gNB, from which RRC and user-plane keys follow as usual. The only question is what it is derived from.

	Horizontal key derivation	Vertical key derivation
Input key	The current K_gNB held by the source	An unused NH (Next Hop) that the source received from the AMF
NCC behaviour	`nextHopChainingCount` sent to the UE is unchanged from the current value	`nextHopChainingCount` is incremented, telling the UE to use the next NH in the chain
Other inputs	Target `physCellId` and target downlink ARFCN TS 33.501 Annex A.11 / A.12	The same, plus the NH
Forward security	Not achieved: a compromised source can compute the target's key	Achieved: the source cannot compute the target's key, because it does not hold the NH that was consumed
When it happens	Xn handover where the source has no unused NH left -- the common case for a run of consecutive Xn handovers between the same gNBs	Whenever an unused NH is available. The AMF supplies a fresh NH in the PATH SWITCH REQUEST ACKNOWLEDGE, so the next handover after a path switch is normally vertical
How the UE knows	It compares the received `nextHopChainingCount` against its stored value; equal means horizontal	Received value greater means vertical, and the UE iterates the NH chain that many times

Table 17. Horizontal and vertical derivation. Both produce a key the source no longer uses; only vertical produces one the source cannot compute.

📘

Spec detail

The whole mechanism reaches the UE as a three-bit integer: nextHopChainingCount, NextHopChainingCount ::= INTEGER (0..7), carried in masterKeyUpdate inside securityConfig. Everything else -- which NH, which PCI, which ARFCN -- the UE already knows or can see in the handover command. That is the entire security content of a handover, and it is why a mismatch shows up not as a security failure message but as an integrity check failure on the UE's very first uplink RRC message at the target. Companion 27 AS Security Mode has the derivation chain in full.

🔍

What you see in logs

The NH chain is also why the intra-cell handover in §2.1 exists. Refreshing K_gNB without moving the UE requires a synchronous reconfiguration, and the cheapest way to force one is a reconfigurationWithSync that points at the cell the UE is already on. In a log that looks exactly like a handover to the same PCI, T304 and all -- and it is not an error.

15. Mobility Robustness, Ping-Pong, and the Parameters That Control It

Mobility tuning is a two-sided problem with no interior optimum. Trigger too late and UEs fail on the source; trigger too early and they fail on the target or bounce straight back. Every parameter below moves the operating point along that line, and the reason there are so many of them is that they act at different points in the chain -- some on the measurement, some on the event, some on the decision.

Parameter	ASN.1 range	Typical	Which failure it trades against
`a3-Offset`	`MeasTriggerQuantityOffset` -30..30, in 0.5 dB steps (so -15..+15 dB)	2-4 dB	Raise it -> later handovers -> fewer too-early, more too-late. The primary coverage-handover knob.
`hysteresis`	0..30, in 0.5 dB steps (0..15 dB)	1-2 dB	Applied to both entering and leaving, so it directly suppresses ping-pong at the cost of delaying every handover slightly.
`timeToTrigger`	ms0, ms40, ms64, ms80, ms100, ms128, ms160, ms256, ms320, ms480, ms512, ms640, ms1024, ms1280, ms2560, ms5120	ms160-ms320	The strongest anti-ping-pong control and the strongest cause of too-late handover. Scale it to UE speed, not to cell size.
`cellIndividualOffset`	`Q-OffsetRange`: dB-24 .. dB24	0 dB	Per-neighbour, asymmetric bias. Fixes a single bad relation without touching anything else -- and creates one-way coverage holes when overdone (§6).
`offsetMO` (`Q-OffsetRangeList`)	dB-24 .. dB24 per quantity	0 dB	Per-frequency bias. Used to prefer or de-prefer a whole layer, e.g. to keep UEs off a capacity band at the edge.
`filterCoefficient`	fc0, fc1, fc2, fc3, fc4, fc5, fc6, fc7, fc8, fc9, fc11, fc13, fc15, fc17, fc19	fc4-fc8	L3 filter depth. Deeper filtering suppresses fading-driven ping-pong and adds lag to real trends.
`reportInterval`	ms120 .. min60	ms240-ms1024	Only matters for periodic and event-plus-periodic reporting; a long interval delays the second report the RRM may be waiting for.
`s-Measure`	`RSRP-Range` 0..127	often absent	Suppresses neighbour measurement entirely while the serving cell is above it. Saves UE power; delays discovery of a neighbour when the serving cell degrades quickly.
`t304`	ms50 .. ms10000	ms100-ms200	How long the UE will keep trying at the target. Too short turns recoverable access problems into handover failures; too long delays the re-establishment that is the only remaining recovery (§8).
`maxReportCells`	1..8	4-8	How many neighbours one report can describe. Too low and the RRM cannot see the cell it should have chosen -- a wrong-cell contributor.

Table 18. Mobility parameters and the failure each one trades against. Ranges from TS 38.331 ReportConfigNR, MeasObjectNR and ReconfigurationWithSync; typical values are what many vendors ship, not spec defaults.

⚠️

Common pitfall

Ping-pong is not a failure and will never appear in a handover success rate. A UE bouncing between two cells every 400 ms is doing perfectly successful handovers -- and paying 25 ms of interruption, two XnAP round trips, an SN status transfer and a path switch for each one. Look for it as handovers per UE per minute against a baseline, or as the count of handovers back to previousPCellId within a few seconds. The cure is hysteresis and timeToTrigger, applied to the specific relation, not cell-wide.

Two further mechanisms are worth knowing because they change mobility behaviour without appearing in any of the parameters above. The Mobility Restriction List, delivered per UE over NGAP, forbids tracking areas, PLMNs and RATs outright -- a UE that will not hand over to an apparently ideal neighbour may simply be barred from it. And MRO itself, where implemented, will adjust offsets automatically from the failure reports in §13, which means a parameter you set by hand may not still be the parameter in force.

16. Configuration Reference (ASN.1 and Ranges)

The handover command is an RRCReconfiguration. The IEs that make it a handover are nested inside masterCellGroup, abridged here to the path that matters:

RRCReconfiguration-IEs ::= SEQUENCE {
    radioBearerConfig            RadioBearerConfig      OPTIONAL,
    secondaryCellGroup          OCTET STRING (CONTAINING CellGroupConfig) OPTIONAL,
    measConfig                  MeasConfig             OPTIONAL,
    ...,
    [[ masterCellGroup          OCTET STRING (CONTAINING CellGroupConfig) OPTIONAL,
       fullConfig               ENUMERATED {true}      OPTIONAL ]],
    ...
}

CellGroupConfig ::= SEQUENCE {
    cellGroupId                 CellGroupId,
    rlc-BearerToAddModList      SEQUENCE (SIZE(1..maxLC-ID)) OF RLC-BearerConfig  OPTIONAL,
    mac-CellGroupConfig         MAC-CellGroupConfig    OPTIONAL,
    physicalCellGroupConfig     PhysicalCellGroupConfig OPTIONAL,
    spCellConfig                SpCellConfig           OPTIONAL,
    sCellToAddModList           ...                    OPTIONAL,
    ...
}

SpCellConfig ::= SEQUENCE {
    servCellIndex               ServCellIndex          OPTIONAL,
    reconfigurationWithSync     ReconfigurationWithSync OPTIONAL,  -- <== the handover
    rlf-TimersAndConstants      SetupRelease {RLF-TimersAndConstants} OPTIONAL,
    rlmInSyncOutOfSyncThreshold ENUMERATED {n1}        OPTIONAL,
    spCellConfigDedicated       ServingCellConfig      OPTIONAL,
    ...
}

ReconfigurationWithSync ::= SEQUENCE {
    spCellConfigCommon          ServingCellConfigCommon OPTIONAL,
    newUE-Identity              RNTI-Value,
    t304                        ENUMERATED {ms50, ms100, ms150, ms200,
                                            ms500, ms1000, ms2000, ms10000},
    rach-ConfigDedicated        CHOICE {
        uplink                      RACH-ConfigDedicated,
        supplementaryUplink         RACH-ConfigDedicated
    }                                                   OPTIONAL,
    ...,
    [[ smtc                     SSB-MTC                 OPTIONAL ]]
}

RACH-ConfigDedicated ::= SEQUENCE {
    cfra                        CFRA                    OPTIONAL,
    ra-Prioritization           RA-Prioritization       OPTIONAL,
    ...
}

CFRA ::= SEQUENCE {
    occasions SEQUENCE {
        rach-ConfigGeneric      RACH-ConfigGeneric,
        ssb-perRACH-Occasion    ENUMERATED {oneEighth, oneFourth, oneHalf,
                                            one, two, four, eight, sixteen} OPTIONAL
    }                                                   OPTIONAL,
    resources CHOICE {
        ssb SEQUENCE {
            ssb-ResourceList    SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-Resource,
            ra-ssb-OccasionMaskIndex INTEGER (0..15)
        },
        csirs SEQUENCE { ... }
    },
    ...
}

CFRA-SSB-Resource ::= SEQUENCE {
    ssb                         SSB-Index,
    ra-PreambleIndex            INTEGER (0..63),
    ...
}

-- security, in a different branch of the same RRCReconfiguration:
MasterKeyUpdate ::= SEQUENCE {
    keySetChangeIndicator       BOOLEAN,
    nextHopChainingCount        NextHopChainingCount,   -- INTEGER (0..7)
    nas-Container               OCTET STRING            OPTIONAL,
    ...
}

Listing 1. Abridged from TS 38.331. ... marks omitted fields and extension markers. The nesting is the point: four levels down from the message root before you reach the IE that moves the UE.

17. Illustrative Message Traces

🔍

ABOUT THESE TRACES

Illustrative trace. Field names and encodings follow 3GPP; the values are constructed for this document and are not a capture from any deployed or lab network.

17.1 The report and the decision

[RRC / RRM] measurement report and handover decision

09:41:07.412  [RRC-UL] MeasurementReport on SRB1
              measId ......................... 1     -- A3, intra-freq
              measResultServingMOList
                servCellId ................... 0
                measResultServingCell
                  physCellId ................. 118
                  rsrp ....................... 60    -- RSRP-Range -> -96 dBm
                  rsrq ....................... 62    -- -12.5 dB
              measResultNeighCells
                measResultListNR[0]
                  physCellId ................. 341
                  measResultCell
                    rsrp ..................... 64    -- -92 dBm
                    rsrq ..................... 65    -- -11.0 dB
                  rsIndexResults
                    ssbIndex 3  rsrp 64             -- best beam
                    ssbIndex 4  rsrp 60

09:41:07.414  [RRM]   A3 report accepted for measId 1
              serving  PCI 118  Mp -96 dBm
              best nbr PCI 341  Mn -92 dBm  Ocn +2 dB
              a3-Offset 3 dB  hysteresis 2 dB  -> margin satisfied by 1 dB
              MobilityRestrictionList ........ target TAC permitted
              neighbour relation ............. Xn established, no HO bar
              target load (last Xn Resource Status) ... 41% PRB, admit
              -> decision: Xn handover to NR-CGI ...341, best SSB 3

Listing 2. The report, and the decision it produced. The rsIndexResults block is what lets the target allocate a CFRA preamble on the right beam.

17.2 The handover command as the UE sees it

[RRC-DL] RRCReconfiguration with reconfigurationWithSync

09:41:07.431  [RRC-DL] RRCReconfiguration on SRB1  (relayed from the target)
              rrc-TransactionIdentifier ...... 1
              secondaryCellGroup ............. absent
              masterCellGroup  (CellGroupConfig, 186 bytes)
                cellGroupId .................. 0
                rlc-BearerToAddModList ....... 3 entries (SRB1, SRB2, DRB1)
                mac-CellGroupConfig .......... present
                spCellConfig
                  servCellIndex .............. 0
                  reconfigurationWithSync
                    spCellConfigCommon
                      physCellId ............. 341        -- the target
                      downlinkConfigCommon
                        frequencyInfoDL
                          absoluteFrequencySSB   636768
                          scs-SpecificCarrierList  30 kHz, 273 PRB
                        initialDownlinkBWP ..... present
                      uplinkConfigCommon
                        initialUplinkBWP -> rach-ConfigCommon  present
                      ssb-PositionsInBurst  mediumBitmap 11110000
                      ssbSubcarrierSpacing ... kHz30
                      tdd-UL-DL-ConfigurationCommon  present
                      n-TimingAdvanceOffset .. n25600
                    newUE-Identity ........... 0x5C1A     -- new C-RNTI
                    t304 ..................... ms100
                    rach-ConfigDedicated
                      uplink
                        cfra
                          occasions
                            rach-ConfigGeneric  prach-ConfigurationIndex 159
                            ssb-perRACH-Occasion  one
                          resources
                            ssb
                              ssb-ResourceList[0]  ssb 3, ra-PreambleIndex 58
                              ssb-ResourceList[1]  ssb 4, ra-PreambleIndex 59
                              ra-ssb-OccasionMaskIndex  0
                    smtc  periodicityAndOffset sf20-0, duration sf5
                  spCellConfigDedicated ...... present (target BWP, PDCCH, PUCCH)
              measConfig ..................... present (target's MeasConfig)
              securityConfig
                masterKeyUpdate
                  keySetChangeIndicator ...... FALSE   -- intra-5GC, no new K_AMF
                  nextHopChainingCount ....... 3       -- was 2 -> VERTICAL derivation
              -- UE: reset MAC, re-establish RLC and PDCP, derive K_NG-RAN*
              --     from NH[3] with PCI 341 / ARFCN 636768, start T304

Listing 3. The whole handover, as one message. Note that nextHopChainingCount sits in a completely different branch from reconfigurationWithSync -- and that both must be applied for the first uplink message at the target to pass integrity.

17.3 A successful execution phase

[UE] execution phase, success

09:41:07.433  [RRC]    reconfigurationWithSync applied, T304 started (100 ms)
09:41:07.433  [MAC]    MAC reset; RLC re-established on LCH 1,2,4
09:41:07.433  [PDCP]   DRB1 PDCP re-established, DL SN continues from SN 4181
09:41:07.442  [PHY]    source PCell 118 released
09:41:07.443  [PHY]    retuned; searching target PCI 341 SSB per smtc sf20-0
09:41:07.446  [PHY]    SSB 3 acquired, RSRP -91.5 dBm, timing offset resolved
09:41:07.451  [MAC-UL] RA initiated  trigger=handover  type=CFRA
                       ra-PreambleIndex 58 (dedicated, SSB 3)
                       PRACH occasion SFN 604 slot 9 sym 0 f_id 0 -> RA-RNTI 127
09:41:07.454  [MAC-DL] RAR: RAPID 58, TA cmd 71 -> N_TA ~18.5 us (~2.8 km)
                       UL grant 12 PRB MCS 4; no TC-RNTI needed (C-RNTI 0x5C1A)
09:41:07.456  [MAC]    RA successful (contention-free) -> T304 stopped
09:41:07.457  [RRC-UL] RRCReconfigurationComplete, SRB1, C-RNTI 0x5C1A
                       integrity OK with the K_NG-RAN*-derived K_RRCint
09:41:07.459  [PDCP]   first forwarded DL PDU delivered, SN 4181
              -- interruption from 07.433 to 07.459 = 26 ms

Listing 4. A clean CFRA handover. The 26 ms matches the worked budget in §11 almost exactly, and the largest single block is the 9 ms between applying the config and releasing the source.

17.4 T304 expiry and re-establishment

[UE] T304 expiry -> handover failure -> re-establishment

10:22:53.118  [RRC]    reconfigurationWithSync applied, T304 started (100 ms)
10:22:53.127  [PHY]    source PCell 118 released; searching PCI 341
10:22:53.148  [PHY]    no SSB detected for PCI 341 within smtc window
10:22:53.168  [PHY]    SSB 3 acquired late, RSRP -114 dBm (report said -92)
10:22:53.171  [MAC-UL] CFRA preamble 58 on SSB 3, attempt 1
10:22:53.181  [MAC]    ra-ResponseWindow expired, no RAR
10:22:53.191  [MAC-UL] CFRA preamble 58 on SSB 3, attempt 2
10:22:53.201  [MAC]    ra-ResponseWindow expired, no RAR
10:22:53.211  [MAC-UL] CFRA preamble 58 on SSB 3, attempt 3
10:22:53.218  [RRC]    T304 EXPIRED  (PREAMBLE_TRANSMISSION_COUNTER = 3 of n10)
10:22:53.218  [RRC]    -> handover failure
10:22:53.218  [RRC]    -> revert to the source PCell configuration
10:22:53.218  [RRC]    -> store VarRLF-Report
                          connectionFailureType .... hof
                          failedPCellId ............ PCI 341 / ARFCN 636768
                          previousPCellId .......... NR-CGI ...118
                          timeConnFailure .......... 1   -- 100 ms units
                          measResultLastServCell  rsrp 60 (-96 dBm)
                          measResultNeighCells    PCI 341 rsrp 43 (-113 dBm)
                          ra-InformationCommon  3 preambles, SSB 3, no response
                          rlf-Cause ................ randomAccessProblem
10:22:53.219  [RRC]    -> initiate RRC re-establishment, T311 started
10:22:53.244  [RRC]    suitable cell found: PCI 118 (the source)
10:22:53.262  [RRC-UL] RRCReestablishmentRequest  cause handoverFailure
10:22:53.301  [RRC-DL] RRCReestablishment; SRB1 resumed
              -- user-plane gap 10:22:53.118 -> 10:22:53.318 = ~200 ms
              -- classification: re-established in previousPCellId with
              --   timeConnFailure = 1 -> TOO-EARLY HANDOVER

Listing 5. A too-early handover, end to end. Three preambles, not ten, because T304 is the binding limit (§8.1); and a 200 ms gap instead of 26 ms, because re-establishment is an order of magnitude more expensive than a handover.

🔍

What you see in logs

The tell in that trace is at 10:22:53.168: the target SSB measured -114 dBm when the report that triggered the handover said -92 dBm. A 22 dB discrepancy in a few hundred milliseconds is not fading -- it is either PCI confusion (a different cell with the same PCI answered the measurement) or a reflection that vanished when the UE turned a corner. Both are wrong-cell and too-early generators, and both are found by correlating measResultNeighCells in the RLF report against the MeasurementReport that started it.

18. Release Deltas: Rel-15 to Rel-18

Release	Change	Why it matters when reading handover logs
Rel-15	Baseline handover: `reconfigurationWithSync`, T304, Xn and NG/N2 preparation, CFRA at the target, direct and indirect forwarding, path switch	Everything in §4 through §11. All later work is layered on this execution phase without replacing it.
Rel-15	`VarRLF-Report` and the `UEInformationRequest` retrieval mechanism	The first version of the failure evidence in §13. The Rel-15 report is thinner than the Rel-16 one -- notably in beam-level information.
Rel-16	Conditional Handover: `conditionalReconfiguration`, `condReconfigToAddModList`, `CondEvent A3` / `A5`, execution by the UE	A handover can now execute with no RRC message immediately preceding it. The command in your log may be seconds old. See 25.
Rel-16	DAPS handover: `daps-Config` per DRB, a source release sent as a separate reconfiguration	The source link stays up after the handover command, so a reconfiguration is no longer the end of source-side activity.
Rel-16	RACH-less handover and mobility enhancements; T312	A successful handover may contain no preamble at all. T312 can declare RLF earlier than T310 alone would.
Rel-16	Enhanced `RLF-Report` (beam measurements, `ra-InformationCommon`, richer causes) and Xn FAILURE INDICATION / HANDOVER REPORT	This is the release that makes MRO classification (§13.2) reliable rather than heuristic.
Rel-17	`CondEvent A4` for CHO; CHO for NR-DC and for inter-RAT cases; slice-aware mobility	A conditional handover can now be armed on an absolute neighbour threshold, which changes when candidates are prepared.
Rel-17	NTN and non-terrestrial mobility, with time- and location-based triggers	A handover can be triggered by ephemeris and a clock rather than by a measurement, so an absent measurement report is not evidence of an absent trigger.
Rel-18	LTM (L1/L2-triggered mobility): candidate configurations by RRC, cell switch by MAC CE, optional early TA acquisition and RACH-less switch	A mobility event may consist of a single MAC CE. Searching an RRC log for handovers will miss it entirely.
Rel-18	Subsequent CHO (CHO to a further candidate without new preparation), and CHO/DAPS combinations	One preparation can serve several consecutive moves, so preparation and execution are no longer one-to-one.

Table 19. Handover-relevant changes by release. Confirm feature presence against the UE capability exchange -- companion 26 UE Capability -- before concluding a feature is broken.

19. Reading Handover in Logs: A Checklist

Find the reconfigurationWithSync, not the word "handover". It is the only unambiguous marker, and it is four levels deep: RRCReconfiguration -> masterCellGroup -> spCellConfig -> reconfigurationWithSync. If it is in secondaryCellGroup instead, you are looking at a PSCell change, not a handover.
Classify the scope before anything else (§2.1). Compare the source and target NR-CGI against the gNB's own served cell list and against its Xn peers' cell lists. Intra-DU, inter-DU, Xn and NG/N2 produce four completely different sets of surrounding messages, and looking for the wrong ones wastes the most time.
Read t304 and the target's PRACH periodicity together and work out how many attempts actually fit (§8.1). This tells you in one calculation whether a two- or three-preamble failure is a UE problem or a configuration problem.
Check whether rach-ConfigDedicated is present, and whether it covers the SSB the UE actually used. A handover that falls back to contention-based access is not a failure, but it is 5-10 ms slower and it means the target's CFRA pool or beam mapping needs attention (§9).
Compare nextHopChainingCount against the UE's stored value to decide horizontal versus vertical (§14). If the first uplink message at the target failed integrity, this is where the fault is, and no amount of RF investigation will find it.
Time-stamp the interruption yourself, from the moment the UE applies the config to the first user-plane PDU at the target. Do not trust a "handover duration" counter without knowing which two events it brackets -- most vendor counters start at the measurement report, which is not interruption at all (§11).
On failure, get the RLF report and read exactly three fields first: connectionFailureType, timeConnFailure and reestablishmentCellId. Those three place the failure in the MRO taxonomy (§13.2) and the taxonomy tells you which parameter to move.
Cross-check the target RSRP in the RLF report against the MeasurementReport that triggered the handover. A large discrepancy means PCI confusion or a vanished reflection, not a procedural fault.
Count handovers back to previousPCellId within a few seconds to find ping-pong, which will not show up anywhere in a success-rate metric (§15).
Before blaming the RRM for a late decision, add up the lag: filterCoefficient plus timeToTrigger plus reportInterval (§5). It is routinely most of a second, and the UE was moving throughout.

20. Glossary

Term	Expansion	Meaning in this document
`reconfigurationWithSync`	--	The IE inside `spCellConfig` whose presence makes an `RRCReconfiguration` a handover. Carries the target cell configuration, the new C-RNTI, T304 and the CFRA resources (§7).
Preparation / execution / completion	--	The three phases every handover shares. Only preparation differs meaningfully between Xn and NG/N2 (§4).
T304	--	The execution-phase timer. Expiry is handover failure and leads to re-establishment (§8).
CFRA	Contention-Free Random Access	Access at the target using a preamble index the target reserved for this UE, per SSB. The normal handover case (§9).
Interruption time	--	The interval during which the UE can neither send nor receive user data: from applying the handover command to the first user-plane PDU at the target (§11).
Path switch	--	Moving the N3 GTP-U tunnel endpoint at the UPF from the source gNB to the target. Happens after the UE has arrived, which is why forwarding is needed (§10).
SN status transfer	--	The source's handover of PDCP sequence-number and HFN state per DRB, so the target continues the same numbering (§10).
End marker	--	The GTP-U PDU the UPF sends down the old N3 tunnel after switching, telling the target no more forwarded data is coming (§10).
`K_NG-RAN*`	--	The key the target uses as its K_gNB, derived from either the current K_gNB (horizontal) or an unused NH (vertical), plus the target PCI and ARFCN (§14).
NCC / NH	Next hop Chaining Count / Next Hop	The three-bit counter and the key-chain value that together tell the UE which derivation to perform (§14).
MRO	Mobility Robustness Optimisation	The framework that classifies mobility failures as too-late, too-early or wrong-cell and feeds the classification back to the deciding gNB (§13.2).
Ping-pong	--	Repeated successful handovers between the same pair of cells. Costs interruption and signalling; invisible in a success-rate metric (§15).
CHO / DAPS / LTM	Conditional Handover / Dual Active Protocol Stack / L1-L2-Triggered Mobility	The three special execution modes. All still execute a `reconfigurationWithSync`; they differ in when and how it is delivered and when the source is released (§12).
SpCell	Special Cell	The PCell of the master cell group, or the PSCell of a secondary cell group. `reconfigurationWithSync` always targets one SpCell.

21. References

3GPP TS 38.300 -- NR and NG-RAN overall description. Clause 9.2.3 (mobility in RRC_CONNECTED), 9.2.3.2 (handover phases and the preparation/execution/completion model), 9.2.3.4 (data forwarding), clause 15 (self-configuration and self-optimisation, including mobility robustness).
3GPP TS 38.331 -- RRC protocol specification. Clause 5.3.5 (reconfiguration, including 5.3.5.5.2 for cell group configuration and 5.3.5.8.3 for T304 expiry), clause 5.5 (measurements; 5.5.3.2 for L3 filtering, 5.5.4.4 for event A3, 5.5.4.6 for A5), clause 5.7.10 (VarRLF-Report and its retrieval), clause 7.1 (timers), clause 12 (processing delay). IEs: ReconfigurationWithSync, SpCellConfig, CellGroupConfig, RACH-ConfigDedicated, CFRA, MasterKeyUpdate, ReportConfigNR, MeasObjectNR, RLF-Report.
3GPP TS 38.401 -- NG-RAN architecture description. Clause 8.2 (intra-gNB and inter-gNB mobility procedures across the CU/DU split, including the F1AP sequences for intra-DU and inter-DU cell change).
3GPP TS 38.423 -- Xn Application Protocol (XnAP). HANDOVER REQUEST, HANDOVER REQUEST ACKNOWLEDGE, HANDOVER PREPARATION FAILURE, SN STATUS TRANSFER, UE CONTEXT RELEASE, HANDOVER CANCEL, FAILURE INDICATION, HANDOVER REPORT, Xn SETUP, NG-RAN NODE CONFIGURATION UPDATE.
3GPP TS 38.413 -- NG Application Protocol (NGAP). PATH SWITCH REQUEST and ACKNOWLEDGE, HANDOVER REQUIRED, HANDOVER REQUEST, HANDOVER COMMAND, HANDOVER NOTIFY, the Mobility Restriction List IE.
3GPP TS 38.473 -- F1 Application Protocol (F1AP). UE CONTEXT SETUP, UE CONTEXT MODIFICATION and UE CONTEXT RELEASE, and the F1 Setup exchange that gives the CU its DU cell mapping.
3GPP TS 33.501 -- Security architecture and procedures for 5G System. Clause 6.9 (key handling in handover, horizontal and vertical derivation), Annex A.11 / A.12 (K_NG-RAN* derivation functions).
3GPP TS 38.133 -- Requirements for support of radio resource management. Handover delay and interruption time requirements, and the measurement reporting delays that underlie §5 and §11.
3GPP TS 23.502 -- Procedures for the 5G System. The core-network side of the path switch and of PDU session modification during handover.

Companion documents in this set

23 Xn Handover -- the deep procedural document for the common case: every XnAP message, the transparent container principle, data forwarding over Xn-U, and the F1AP exchange at the target.
24 NG / N2 Handover -- the same procedure with the AMF as coordinator, and the inter-AMF case.
25 Conditional HO and DAPS -- the special execution modes summarised in §12, in full.
20 Measurements and Events -- the MeasConfig, the events and the L3 filtering that produce the report in §5.
21 Measurement Gaps and SMTC -- why an inter-frequency neighbour is sometimes not measured at all, and the smtc in §7.
16 RLM and RLF -- T310, T311, the re-establishment procedure and the full RLF-Report structure behind §13.
03 Random Access -- CFRA and CBRA at the target, and why a handover RACH failure appears as a timer expiry.
15 RRC Procedures / 13 RRC Overview -- where RRCReconfiguration sits among the other RRC procedures.
27 AS Security Mode -- the key hierarchy that §14 walks one step of.
26 UE Capability -- the container the source relays to the target, and where CHO, DAPS and LTM support is declared.