🗂️ RRC — Radio Resource ControlAdvanced

Xn-based Handover (with exact IEs) in 5G NR

Inter-gNB handover over Xn — Handover Request/Ack, SN Status Transfer, RACH to target, Path Switch — drawn with the real IEs.

📚 3GPP-basedTS 38.300TS 38.423TS 38.331

In a mature deployment almost every inter-gNB handover goes over Xn, because Xn is a direct SCTP association between two gNBs and the alternative is a detour through the AMF. This document is the procedural detail for that case: what the Xn interface is and what Xn Setup tells the source about the target, every XnAP message in the handover named and decoded, the transparent container principle that makes the target the author of the RRCReconfiguration the source merely relays, the F1AP exchange that happens at the target before any air-interface activity, SN status transfer and data forwarding in detail, the NGAP path switch that moves the N3 tunnel at the UPF after the UE has already arrived, timers on both sides, the complete failure taxonomy, and worked arithmetic for the interruption, the PDCP SN reconstruction and the forwarding buffer. The framework -- taxonomy, phases, reconfigurationWithSync, T304, MRO -- is in the companion 22 Handover Overview.

Contents

01When Xn Handover Applies, and Why It Is the Common Case
02The Xn Interface: XnAP over SCTP, Xn-C and Xn-U
03Xn Setup, Configuration Update, and What the Source Knows
04The Full Message Sequence
05HANDOVER REQUEST, Field by Field
06The Transparent Container Principle
07HANDOVER REQUEST ACKNOWLEDGE
08Admission Control at the Target, and Partial Admission
09The CU/DU Dimension: F1AP Before Anything Reaches the Air
10Execution: the RRCReconfiguration the UE Actually Receives
11SN STATUS TRANSFER
12Data Forwarding in Detail
13Completion: Path Switch and UE Context Release
14Timers on Both Sides
15The Complete Failure Taxonomy
16Worked Arithmetic
17Illustrative Message Traces
18Release Deltas: Rel-15 to Rel-18
19Reading Xn Handover in Logs: A Checklist
20Glossary
21References

1. When Xn Handover Applies, and Why It Is the Common Case

Xn handover is what happens when the two gNBs can talk to each other directly. That sounds like a small distinction and it is worth about 20 ms of preparation latency, a great deal of AMF signalling load, and the option of forwarding user data over one transport hop instead of three. In a network where neighbour relations have been provisioned properly it is the path essentially every inter-gNB handover takes; the companion 24 NG / N2 Handover covers what happens when it cannot.

Five conditions have to hold. The first four are hard; the fifth is policy.

Condition	Where the source checks it	What happens if it does not hold
An Xn-C SCTP association to the target gNB is up	Local Xn peer state, established by Xn Setup (§3)	No Xn -- fall back to NG/N2 handover, or, if the operator has not configured that either, no handover at all and eventually a too-late failure.
The target cell appears in that peer's served-cell list	The Served Cell Information NR list received in XN SETUP RESPONSE or a later NG-RAN NODE CONFIGURATION UPDATE	The source does not know which gNB owns the cell. A stale list here is a common cause of handovers aimed at a cell that has been moved to another gNB.
Both gNBs have an NG-C association to the same AMF serving this UE	Its own NG-C associations plus the GUAMI in the UE's context	The target cannot send PATH SWITCH REQUEST to the AMF that holds the UE context, so the handover cannot complete. This is why an inter-AMF move must be an NG/N2 handover.
The target is not barred for this UE	Mobility Restriction List received per UE over NGAP; forbidden TAs, PLMNs and RATs	The candidate is removed before any interface question is asked. A UE that stubbornly will not hand over to an obviously better neighbour is often barred from it, not failing on it.
Policy prefers Xn for this neighbour relation	Local configuration and MRO feedback	A relation flagged for NG/N2 -- across an operator or vendor boundary, or after repeated Xn failures -- is prepared the slow way on purpose.

Table 1. The Xn preconditions. Only the third is a genuine architectural limit; the other four are configuration, and three of the four fail silently.

💡

Key point

Xn handover is intra-AMF by construction. The target completes the procedure by sending an NGAP PATH SWITCH REQUEST on its own NG-C association, and that message identifies the UE by the Source AMF UE NGAP ID -- a value that only means anything to the AMF that allocated it. If the target is not connected to that AMF there is nowhere to send it. This is the whole reason NG/N2 handover exists, and it is not about the absence of Xn.

Everything in this document assumes NR-to-NR mobility between two gNBs under one AMF, with the CU/DU split present (§9) because that is what a real log looks like. The framework the procedure sits inside -- the taxonomy, the three phases, reconfigurationWithSync, T304, the MRO failure classification -- is in the companion 22 Handover Overview and is not repeated here.

2. The Xn Interface: XnAP over SCTP, Xn-C and Xn-U

"Xn" is not a cable. It is a pair of logical interfaces between two NG-RAN nodes, running over whatever transport network already connects them TS 38.420. The control plane and the user plane are separate and independent, and confusing them is the source of one of the more baffling failure modes in mobility.

Figure 1. The two Xn planes. Xn-C is a single long-lived SCTP association per peer; Xn-U is a set of short-lived GTP-U tunnels created and destroyed per handover, per DRB.

	Xn-C (control plane)	Xn-U (user plane)
Protocol	XnAP over SCTP over IP TS 38.422	GTP-U over UDP over IP TS 38.424
Transport identity	SCTP port 38422, payload protocol identifier 61	UDP port 2152, tunnels distinguished by TEID
Lifetime	One association per peer, up from Xn Setup until Xn Removal or a transport fault. Multi-streamed, so per-UE procedures do not head-of-line block each other.	One tunnel per DRB per direction, allocated by the receiving node during handover preparation and torn down after the End Marker (§12).
Reliability	SCTP retransmits. A lost XnAP message is a transport stall, not a lost procedure.	None. A lost forwarded PDU is a PDCP gap, recovered (or not) by RLC and PDCP at the target.
Carries, during handover	HANDOVER REQUEST, HANDOVER REQUEST ACKNOWLEDGE, SN STATUS TRANSFER, UE CONTEXT RELEASE, HANDOVER CANCEL, HANDOVER PREPARATION FAILURE	Buffered and newly arriving downlink PDCP SDUs, and the forwarded End Marker
What its absence looks like	No handover prepares at all; the source either falls back to NG/N2 or never triggers.	Handovers prepare and execute perfectly, and every UE sees a throughput hole and a burst of TCP retransmissions on arrival.

Table 2. Xn-C and Xn-U. Note the last row: these two failures look nothing alike in a log and are usually investigated by different teams.

⚠️

Common pitfall

Xn-U reachability is not verified by Xn Setup. Xn Setup is an XnAP procedure over SCTP; it exchanges transport-layer addresses for the user plane but does not probe them. A firewall rule that blocks UDP 2152 between two sites leaves Xn-C perfectly healthy, every handover succeeding, every KPI green -- and every handed-over UE losing its in-flight downlink data. The symptom is a throughput dip immediately after handover with a normal handover success rate, which is why it survives in networks for months.

XnAP procedures come in the usual two classes TS 38.423 cl. 8. Class 1 procedures have a response and can fail explicitly: handover preparation is class 1, with HANDOVER REQUEST ACKNOWLEDGE as the successful outcome and HANDOVER PREPARATION FAILURE as the unsuccessful one. Class 2 procedures are fire-and-forget: SN STATUS TRANSFER, UE CONTEXT RELEASE and HANDOVER CANCEL are all class 2, which is why none of them has an acknowledgement and why a lost one produces a stuck context rather than an error.

3. Xn Setup, Configuration Update, and What the Source Knows

Before any handover can be prepared, the two gNBs have to have introduced themselves. XN SETUP REQUEST / XN SETUP RESPONSE runs once, when the association comes up TS 38.423 cl. 8.4, and it is the only reason the source is able to look at a PCI in a measurement report and name the gNB that owns it.

IE exchanged at Xn Setup	Contents	What the source can do with it
Global NG-RAN Node ID	PLMN identity plus gNB ID (22-32 bits), or an ng-eNB ID	Identifies the peer for the lifetime of the association, and keys every later Configuration Update.
TAI Support List	Tracking Area Identities the peer serves, with the supported S-NSSAIs per TAI	Pre-screens candidates against the UE's Mobility Restriction List and Allowed NSSAI before wasting a preparation round trip.
Served Cell Information NR (per cell)	NR-CGI, PCI, TAC, broadcast PLMN list, FDD or TDD mode with `absoluteFrequencySSB`, `absoluteFrequencyPointA`, transmission bandwidth, subcarrier spacing, and the `measurementTimingConfiguration`	Maps a reported PCI to a specific NR-CGI on a specific gNB. The frequency and SMTC information is what lets the source configure the UE to measure the cell at all.
Neighbour Information NR (optional, per served cell)	The neighbours the peer knows about, with their NR-CGI, PCI and ARFCN	Second-hand neighbour discovery -- useful for populating relations the source has never seen a report for.
AMF Region Information / Global AMF ID list	Which AMFs the peer is connected to	Decides the third precondition in §1: whether Xn handover can complete for this UE's AMF at all.
Interface Instance Indication	Distinguishes multiple parallel Xn instances between the same node pair	Rarely relevant to handover; matters when reading transport-level traces.

Table 3. Xn Setup contents, TS 38.423. The third row is the one that matters most operationally, and the one most likely to be stale.

Anything that changes afterwards is signalled with NG-RAN NODE CONFIGURATION UPDATE, which can add, modify or remove served cells and update TNL address information, and is acknowledged with NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE. Two related global procedures complete the picture: XN REMOVAL, which tears the association down cleanly, and RESET, which discards all UE-associated context on the interface without touching the association itself.

🔍

What you see in logs

A Configuration Update that removes a cell is the correct way to decommission one, and it is frequently skipped. The result is a source gNB that keeps a cell in its Xn served-cell list and keeps preparing handovers to it. Those preparations do not fail at the transport layer -- they reach a live gNB that simply no longer owns the cell, and they come back as HANDOVER PREPARATION FAILURE with a cause like unknown-target-ID or cell-not-available. A rising rate of that one cause value against a specific peer almost always means a stale served-cell list, not a radio problem.

4. The Full Message Sequence

Every message, in order, with the interface each one runs on. The sequence is drawn in two figures because one would be too tall to read: preparation and execution first, then completion.

Figure 2. Preparation and execution. The UE is not involved in, and knows nothing about, anything above the divider -- which is where roughly a third of the elapsed time goes.

Figure 3. Completion. Note the order: the UE is already being scheduled by the target before the core network is told anything at all.

Message	Interface	Direction	Class	What it is for
HANDOVER REQUEST	Xn-C	source -> target	1	Ask the target to admit the UE, and hand it everything it needs to reconstruct the context (§5).
HANDOVER REQUEST ACKNOWLEDGE	Xn-C	target -> source	1	Accept, wholly or partly, and return the target-authored `RRCReconfiguration` plus forwarding addresses (§7).
HANDOVER PREPARATION FAILURE	Xn-C	target -> source	1	Refuse, with a Cause. Nothing user-visible has happened (§15).
RRCReconfiguration	Uu (via SRB1)	source -> UE	--	The handover command. Relayed verbatim from the container (§10).
SN STATUS TRANSFER	Xn-C	source -> target	2	Hand over PDCP sequence-number state per DRB so the target can continue the numbering (§11).
Forwarded user data	Xn-U	source -> target	--	Buffered and newly arriving downlink PDCP SDUs (§12).
RRCReconfigurationComplete	Uu (via SRB1)	UE -> target	--	The UE has arrived. First message on the target's SRB1, and the first test of the new key.
PATH SWITCH REQUEST	NG-C	target -> AMF	1	Ask the core to move the N3 tunnel to the target (§13).
PATH SWITCH REQUEST ACKNOWLEDGE	NG-C	AMF -> target	1	Confirmation, plus the fresh NH that seeds the next handover's key derivation (§13).
UE CONTEXT RELEASE	Xn-C	target -> source	2	The source may now free the context and tear down the forwarding tunnels (§13).
HANDOVER CANCEL	Xn-C	source -> target	2	Withdraw a prepared handover -- because the UE came back, because a better target appeared, or because the source is giving up (§15).

Table 4. The complete message set. Only four of the eleven rows are Xn-C class 1 procedures; the rest cannot fail visibly, which is why the failure taxonomy in §15 is mostly about timers.

📘

Spec detail

The ordering of SN STATUS TRANSFER relative to the handover command is not arbitrary and is worth memorising. It must go after the source has committed -- once it is sent, the source has stopped assigning new downlink PDCP SNs -- and before the target starts delivering, or the target has no idea where to continue from. In a log the correct order is always: RRCReconfiguration to the UE, then SN STATUS TRANSFER, then forwarding. Seeing SN STATUS TRANSFER before the RRC command means an implementation that has stopped the downlink earlier than it needed to, and it lengthens the interruption for nothing.

5. HANDOVER REQUEST, Field by Field

HANDOVER REQUEST is the largest UE-associated message on Xn, because it has to carry enough of the UE's context that the target can rebuild it without ever talking to the UE or to the core. Abridged to the IEs that matter operationally TS 38.423 cl. 9.1.1:

IE	Presence	Contents	Why it matters
Source NG-RAN node UE XnAP ID reference	M	The source's handle for this UE on this Xn association	Every later message in the procedure quotes it. It is the join key for correlating an Xn trace with a source-side UE log.
Cause	M	Typically `handover-desirable-for-radio-reasons`, `reduce-load-in-serving-cell`, or `time-critical-handover`	The only statement of why the source is moving the UE. A cell whose outgoing handovers are all `reduce-load-in-serving-cell` is telling you something about its own loading, not about coverage.
Target Cell Global ID	M	NR-CGI of the target cell	A cell, not a node. The target gNB uses it to pick which of its DUs and cells to prepare (§9).
GUAMI	M	Globally Unique AMF Identifier of the serving AMF	How the target knows which of its NG-C associations to use for the path switch. A mismatch here is the failure in §1.
UE Context Information -> NG-C UE associated Signalling reference	M	AMF UE NGAP ID	Quoted back in PATH SWITCH REQUEST so the AMF can find the UE.
UE Context Information -> UE Security Capabilities	M	Supported NR and E-UTRA integrity and ciphering algorithms	The target re-runs algorithm selection against its own priority list; it may legitimately choose different algorithms than the source used.
UE Context Information -> AS Security Information	M	`K_NG-RAN*` (256 bits, derived by the source from the target PCI and downlink ARFCN) and the NCC (0..7)	The entire security handover. The NCC is copied into `masterKeyUpdate` in the RRC the target writes; see companion 27 AS Security Mode.
UE Context Information -> UE Aggregate Maximum Bit Rate	M	UL and DL AMBR for the UE	The target must enforce it from the first scheduled slot; it cannot ask the core.
UE Context Information -> PDU Session Resources To Be Setup List	M	Per PDU session: PDU Session ID, S-NSSAI, PDU Session Type, session AMBR, the UL NG-U UP TNL Information at the UPF, and a DRB list with DRB ID, SDAP and PDCP configuration, mapped QoS flows with their 5QI and ARP, and a data-forwarding proposal per DRB	The whole user plane. The UPF's uplink address is here because the target has to start sending uplink data to the core immediately on arrival, long before the path switch.
UE Context Information -> RRC Context	M	An OCTET STRING containing `HandoverPreparationInformation` (§6)	The UE capabilities and the source's own RRC configuration, so the target can produce a delta rather than a full configuration.
UE Context Information -> Index to RAT/Frequency Selection Priority	O	RFSP index from the AMF	Subscription-driven layer preference. The target uses it for its later mobility decisions.
UE Context Information -> Mobility Restriction List	O	Forbidden TAs, PLMNs, RATs; core-network type restriction	Passed on so the target inherits the same restrictions. Omitting it is how a UE ends up handed onward into an area it was barred from.
UE History Information	O	The list of cells the UE has recently been in, with time spent in each	The target's input for its own decisions and for ping-pong suppression. Genuinely useful in a trace: it is the UE's mobility history handed to you for free.
Location Reporting Information, Trace Activation, Masked IMEISV	O	As named	Continuity of core-requested reporting and tracing across the boundary.

Table 5. HANDOVER REQUEST, abridged. "M" and "O" are mandatory and optional as XnAP defines them; several of the optional IEs are mandatory in practice for the handover to behave correctly.

💡

Key point

Two addresses travel in this message and they are easy to confuse. The UL NG-U UP TNL Information is the UPF's address, so the target can send uplink user data to the core the moment the UE arrives -- uplink never needs a path switch, because the UPF does not care which gNB packets come from. The data-forwarding addresses go the other way and are allocated by the target, in the acknowledge (§7). Uplink works immediately; only downlink needs forwarding and a path switch.

6. The Transparent Container Principle

This is the single most misunderstood thing about handover, so it is worth stating flatly: the target gNB writes the RRCReconfiguration that moves the UE, and the source gNB relays it without reading it.

It has to be that way. The message has to contain the target's C-RNTI, the target's cell configuration, the target's CFRA preamble allocation and the target's bandwidth-part and PDCCH configuration -- none of which the source knows or could invent. So XnAP defines two IEs whose type is, as far as XnAP is concerned, OCTET STRING, and the peers agree that what is inside is an RRC message defined by TS 38.331.

Figure 4. Four levels of encapsulation in each direction. XnAP validates the outer two and copies the rest verbatim.

	Source to target	Target to source
XnAP IE	RRC Context, inside UE Context Information	Target NG-RAN node to Source NG-RAN node Transparent Container
XnAP type	OCTET STRING	OCTET STRING
RRC message inside	`HandoverPreparationInformation` TS 38.331 cl. 6.2.2	`HandoverCommand` TS 38.331 cl. 6.2.2
What it carries	`ue-CapabilityRAT-List` (the UE capability containers), `sourceConfig` -> `AS-Config` -> `rrcReconfiguration` (the full configuration the UE is running now), `as-Context` (re-establishment info, SCG restrictions, stored `UEAssistanceInformation`), and `rrm-Config` (`ue-InactiveTime`, candidate cell measurements)	`handoverCommandMessage`, itself an OCTET STRING containing a complete `RRCReconfiguration` -- with `masterCellGroup`, `securityConfig` -> `masterKeyUpdate`, `radioBearerConfig`, and the target's own `measConfig`
Who authored it	The source gNB's RRC layer	The target gNB's RRC layer -- specifically the target gNB-CU, using the `CellGroupConfig` its DU produced (§9)
Who may modify it	Nobody. The target reads it; it does not rewrite it.	Nobody. The source relays it; it does not rewrite it.

Table 6. The two containers. Both are opaque to XnAP, which is exactly what makes them work across a vendor boundary.

💡

Key point

Because the containers are opaque, an XnAP-only decode tells you nothing about an RRC problem, and an RRC-only decode tells you nothing about which node produced the message. If a handover command is malformed or configures something the UE cannot do, the fault is at the target, even though the message you captured was transmitted by the source. This one inversion accounts for a large share of misdirected mobility investigations.

🔄

Release delta

sourceConfig exists so the target can send a delta. The target reads the source's full AS-Config, decides what needs to change, and may emit an RRCReconfiguration that only carries the differences -- leaving the UE to keep the rest. That is why a handover command can be surprisingly small. It is also why a target that does not trust the source's sourceConfig (a different vendor, a different release) may instead set fullConfig and send everything, which is larger, slower to process, and shows up as a handover command several times the usual size.

7. HANDOVER REQUEST ACKNOWLEDGE

The acknowledge does three jobs at once: it says which PDU sessions were admitted, it hands back the transparent container, and it publishes the transport addresses the source needs in order to forward data.

IE	Presence	Contents	Why it matters
Source NG-RAN node UE XnAP ID reference	M	Echo of the source's handle	Correlation. A response quoting an ID the source has already released is a late acknowledge (§14).
Target NG-RAN node UE XnAP ID	M	The target's own handle	The source uses it in SN STATUS TRANSFER and HANDOVER CANCEL; the target uses it in UE CONTEXT RELEASE.
PDU Session Resources Admitted List	M	Per admitted session: PDU Session ID, the DL NG-U UP TNL Information at the target (the address the UPF will be pointed at during the path switch), and per DRB the DL forwarding UP TNL Information and optionally the UL forwarding UP TNL Information	The forwarding tunnel endpoints. Their presence is the target's agreement to accept forwarded data; their absence means the target wants no forwarding for that DRB, and the source must discard rather than forward.
PDU Session Resources Not Admitted List	O	Per rejected session: PDU Session ID and a Cause	Partial admission (§8). The handover still goes ahead, with fewer sessions than it started with.
Target NG-RAN node to Source NG-RAN node Transparent Container	M	`HandoverCommand` containing the target-authored `RRCReconfiguration` (§6)	The handover command. Relayed to the UE unmodified.
Criticality Diagnostics	O	Which IEs the target did not understand, and how it reacted	The first place to look in a multi-vendor deployment. A populated Criticality Diagnostics on an otherwise successful acknowledge means the two nodes disagree about a release or an extension.

Table 7. HANDOVER REQUEST ACKNOWLEDGE, abridged from TS 38.423 cl. 9.1.1.

⚠️

Common pitfall

The forwarding addresses are allocated per DRB, not per PDU session, and the target may offer them for some DRBs and not others -- typically declining forwarding for a bearer whose traffic is loss-tolerant and latency-sensitive, where a late duplicate is worse than a gap. Voice over a 5QI 1 bearer is the standard example: forwarding a 40 ms backlog of speech frames delivers audio the user has already missed. A source that forwards anyway, ignoring the absent address, produces exactly that artefact.

8. Admission Control at the Target, and Partial Admission

Admission control is the target's decision and the spec says nothing about how to make it. What the spec does define is the shape of the answer, and that shape has a feature worth understanding: the answer is not binary. The target can admit some PDU sessions and refuse others, and the handover proceeds regardless.

Outcome	What the target sends	What the source does	What the UE experiences
Full admission	HANDOVER REQUEST ACKNOWLEDGE with every session in the Admitted List	Relay the command, transfer SN status, forward data	A normal handover.
Partial admission	ACKNOWLEDGE with some sessions in the Admitted List and the rest in the Not Admitted List, each with a Cause	Relay the command. The target's `RRCReconfiguration` already omits the refused bearers, so the UE releases them as part of applying it.	The handover succeeds and some bearers silently disappear. If a data session was refused, an application stalls; if the refused session was the voice one, the call drops while the data session survives.
Rejection	HANDOVER PREPARATION FAILURE with a Cause	Keep the UE where it is; try another candidate or wait	Nothing at all.

Table 8. Three possible answers. The middle one is the dangerous one, because it is counted as a successful handover by every standard KPI.

What the target actually weighs is implementation, but the inputs are the same everywhere: PRB availability against the guaranteed bit rate of each GBR flow; the number of active UEs against its scheduler and PDCP context limits; whether it supports the S-NSSAI of each session; whether it supports the 5QI and can honour its packet delay budget; whether the UE's declared capabilities are ones it can configure; and whether transport capacity exists on N3 and on Xn-U for the forwarding it is about to accept.

🔍

What you see in logs

Partial admission is the mobility failure mode that hides best. Every counter says the handover succeeded, because it did. Find it by joining the Not Admitted List in the acknowledge against the PDU Session Resources To Be Setup List in the request, per handover, and alarming on any non-empty difference. If your monitoring only counts prepare/succeed/fail, this is invisible.

9. The CU/DU Dimension: F1AP Before Anything Reaches the Air

Almost every gNB you will read a log from is split. The gNB-CU terminates RRC, PDCP, SDAP, Xn and NG; the gNB-DU terminates RLC, MAC and PHY and owns the cell TS 38.401 cl. 6.1. That split has a direct and very useful consequence for handover: the target CU cannot answer HANDOVER REQUEST until its DU has told it what the UE's cell group configuration is. So an F1AP exchange sits inside the Xn preparation round trip, and it happens before the UE has any idea it is moving.

Figure 5. The target-side sequence. Steps 2 and 3 are entirely internal to the target gNB and are invisible on Xn -- but they are the reason the Xn round trip takes as long as it does.

F1AP message	Direction	Key IEs	What it does for the handover
UE CONTEXT SETUP REQUEST	target CU -> target DU	`gNB-CU UE F1AP ID`, SpCell ID (target NR-CGI), `CUtoDURRCInformation` (the UE capabilities lifted out of `HandoverPreparationInformation`), SRBs To Be Setup List, DRBs To Be Setup List with UL F1-U TNL info and QoS per flow	Creates the UE context at the DU. The DU has never seen this UE and learns everything about it from this one message.
UE CONTEXT SETUP RESPONSE	target DU -> target CU	`gNB-DU UE F1AP ID`, `DUtoCURRCInformation` containing the `CellGroupConfig`, C-RNTI, DL F1-U TNL info per DRB, DRB Setup and Failed lists	The DU has allocated the C-RNTI, built the cell group and reserved a CFRA preamble. This is where the contents of the handover command come from.
UE CONTEXT MODIFICATION REQUEST / RESPONSE	target CU <-> target DU	`RRCReconfigurationCompleteIndicator`, `TransmissionActionIndicator`, DRB modification lists	Commonly used after `RRCReconfigurationComplete` arrives, to start transmission on the DRBs and release the reserved CFRA resource. Some implementations instead set everything up in the initial setup.
UL RRC MESSAGE TRANSFER	target DU -> target CU	SRB ID = 1, the encoded `RRCReconfigurationComplete`	Not INITIAL UL RRC MESSAGE TRANSFER -- the context already exists. Seeing the initial variant here means the DU had no context, i.e. this is a re-establishment, not a handover.
UE CONTEXT RELEASE COMMAND / COMPLETE	source CU -> source DU	Cause = `normal-release` or `handover-cancelled`	The source side of the clean-up, triggered by XnAP UE CONTEXT RELEASE. Its absence leaves a DU-side context and a leaked C-RNTI.

Table 9. F1AP during an Xn handover TS 38.473 cl. 8.3. The DU is a full participant in preparation and does not appear on Xn at all.

🔍

What you see in logs

The ordering rule to hold on to: F1AP UE CONTEXT SETUP at the target always precedes the target's first PRACH detection for that UE, by roughly the Xn round trip plus the UE's processing and retune time. In a target-side log you therefore see a UE context appear, sit idle for 20-40 ms, and only then produce air-interface activity. That idle gap is normal and is not evidence of a stuck procedure. Conversely, if PRACH with a reserved CFRA index arrives at a DU with no matching context, the F1AP setup either failed or the UE arrived after the target gave up (§14).

⚠️

Common pitfall

The CellGroupConfig inside the handover command is authored by the target DU, wrapped by the target CU, carried by XnAP, relayed by the source CU, and applied by the UE. Five entities touch it and only the first and last understand it. When a handover command configures something the UE rejects, the node to interrogate is the target DU -- which is typically the node furthest from where the failure was observed.

10. Execution: the RRCReconfiguration the UE Actually Receives

The source dequeues the octet string from the transparent container and sends it on SRB1, ciphered and integrity-protected with the source's keys, because the UE is still on the source cell. Everything about the message's content, however, describes the target. The companion 22 Handover Overview covers reconfigurationWithSync as a mechanism; what matters here is which node put each field there.

-- TS 38.331, abridged: only the fields a handover command populates.
RRCReconfiguration-IEs ::= SEQUENCE {
    radioBearerConfig        RadioBearerConfig    OPTIONAL,
    secondaryCellGroup       OCTET STRING         OPTIONAL,
    measConfig               MeasConfig           OPTIONAL,
    masterCellGroup          OCTET STRING         OPTIONAL,  -- CellGroupConfig
    ...
}

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,
    ...
}

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

SecurityConfig ::= SEQUENCE {
    securityAlgorithmConfig  SecurityAlgorithmConfig OPTIONAL,
    keyToUse                 ENUMERATED {master, secondary} OPTIONAL,
    ...
}
MasterKeyUpdate ::= SEQUENCE {
    keySetChangeIndicator    BOOLEAN,
    nextHopChainingCount     NextHopChainingCount,    -- INTEGER (0..7)
    nas-Container            OCTET STRING OPTIONAL,
    ...
}

Listing 1. Abridged from TS 38.331 with ... marking omitted fields. newUE-Identity and rach-ConfigDedicated are values the target DU allocated in the F1AP exchange of §9.

Field	Who chose the value	Typical value	Consequence if wrong
`newUE-Identity`	Target gNB-DU	Any 16-bit C-RNTI free in the target cell	The UE addresses PDCCH with an RNTI the target is not scrambling with. Every grant is missed; T304 expires with no visible error at either end.
`t304`	Target gNB-CU (policy)	`ms100` in FR1, `ms150` in FR2	Too short and marginal-coverage handovers fail that would have succeeded; too long and a doomed handover holds the UE off the air for the full duration before re-establishment starts (§14).
`rach-ConfigDedicated` -> `cfra`	Target gNB-DU	One `ra-PreambleIndex` per SSB the UE might select, plus the RO association	Absent means the UE must contend (CBRA) -- typically 10-20 ms slower and occasionally unsuccessful. Present but stale means the preamble is sent on an index the DU is not watching.
`spCellConfigCommon`	Target gNB-DU	`physCellId`, `absoluteFrequencySSB`, TDD UL/DL common config, `ssb-PositionsInBurst`	The UE tunes to the wrong SSB or applies the wrong TDD pattern and cannot even receive the RAR.
`nextHopChainingCount`	Source gNB (copied by the target)	0..7, the NCC the source used to derive `K_NG-RAN*`	The UE derives a different `K_gNB` from the target. `RRCReconfigurationComplete` fails integrity check at the target, which logs it as a MAC-I failure on SRB1 -- see companion 27 AS Security Mode.
`measConfig`	Target gNB-CU	Release of the source's `measId`s and addition of the target's	The UE keeps measuring against the source's thresholds. It usually still works, and produces reports that make no sense for the cell it is now in.
`radioBearerConfig`	Target gNB-CU	DRB list, possibly with bearers released after partial admission (§8)	A bearer the target has not set up but has left configured produces uplink data with nowhere to go.

Table 10. Every value in a handover command, and which node is responsible for it. Only nextHopChainingCount originates at the source.

📘

Spec detail

The UE applies this message and then stops listening to the source. There is no acknowledgement on the source cell: the source never learns whether the UE received the command. That asymmetry is why T304 lives in the UE and why the source's only protection is TXnRELOCoverall at the target and a re-establishment arriving later (§14, §15). If you are looking for a source-side log line saying "handover succeeded", there is none -- the closest thing is XnAP UE CONTEXT RELEASE arriving from the target.

11. SN STATUS TRANSFER

PDCP numbering has to survive the handover. The target has to know which downlink sequence number to assign next, and which uplink sequence numbers the source has already received so it does not demand retransmission of data that was delivered. SN STATUS TRANSFER is the one message that carries that state TS 38.423 cl. 8.3.1, and it is a class 2 procedure with no acknowledgement.

IE	Width / range	Meaning	What the target does with it
DRB ID	1..32	Which bearer this entry describes	Matches it to the DRB it set up during admission. An entry for a DRB it did not admit is discarded.
UL COUNT Value -> PDCP-SN	12 or 18 bits	The SN of the first uplink SDU the source has not received in order	Sets the target's uplink receive window start (`RX_NEXT` / `RX_DELIV`). The UE will retransmit from here.
UL COUNT Value -> HFN	20 or 14 bits	The hyper frame number for that SN	Together with the SN this reconstructs the full 32-bit COUNT, which is an input to deciphering and to integrity protection.
DL COUNT Value -> PDCP-SN, HFN	as above	The next downlink SN the source would have assigned	The target begins assigning downlink SNs here for SDUs forwarded without a SN. Getting this wrong desynchronises the UE's receive window.
Receive Status of UL PDCP SDUs	BIT STRING, 1..2048 or 1..131072 bits	A bitmap starting at the SN after the UL COUNT SN: bit set = that SDU was received out of order	Suppresses retransmission of already-received SDUs and lets the target reconstruct the reordering gap. Omitted when there is no gap, which is the common case.
Old / New QoS Flow to DRB mapping (Rel-16+)	--	Flow remapping information where the target maps flows to DRBs differently	Lets SDAP continue without the UE seeing a reflective mapping change.

Table 11. DRBsSubjectToStatusTransfer-List, one entry per DRB. The bitmap length limits differ with the SN length: 2048 for a 12-bit SN, 131072 for 18 bits.

COUNT is the concatenation HFN || SN, always 32 bits total. With an 18-bit SN the HFN is 14 bits; with a 12-bit SN it is 20. This matters because COUNT is the deciphering input: if the two ends disagree about COUNT by even one, every subsequent PDCP PDU on that bearer decrypts to garbage, and the symptom is not a handover failure but a bearer that carries traffic which the higher layers silently drop.

⚠️

Common pitfall

The two gNBs must agree on the PDCP SN length per DRB, and they do -- because the source sent the PDCP configuration in HANDOVER REQUEST and the target either honours it or refuses the bearer. But a target that re-derives the SN length from its own policy rather than taking it from the request will interpret the COUNT split at the wrong bit boundary. The handover succeeds, the RRC is clean, and one bearer is dead. This is a classic multi-vendor first-integration failure and it looks like nothing at all in an XnAP-only trace, because the fields are all present and all well-formed.

🔍

What you see in logs

Because it is class 2, a lost SN STATUS TRANSFER is not reported to anyone. The target then either waits for it (delaying delivery until an implementation timeout) or starts from SN 0, which resets the UE's receive window and discards everything in flight. If you see a post-handover PDCP gap on every DRB of one UE while other UEs on the same pair of cells are fine, look for the SN STATUS TRANSFER first.

12. Data Forwarding in Detail

At the moment the handover command goes out, the source holds downlink data for this UE in three places: PDCP SDUs not yet given to RLC, PDCP PDUs given to RLC but not yet RLC-acknowledged, and new SDUs still arriving from the UPF on the old N3 tunnel. None of it can be delivered over the air any more. Forwarding exists so that none of it is lost.

12.1 Direct and indirect forwarding

	Direct forwarding (over Xn-U)	Indirect forwarding (via the UPF)
When it is used	Whenever Xn-U connectivity exists between the two gNBs -- the normal case for an Xn handover	When there is no usable user-plane path between the gNBs. Normal for NG/N2 handover across a boundary; rare but possible on Xn.
Path	source gNB -> target gNB, one GTP-U tunnel per DRB	source gNB -> UPF (or an intermediate UPF) -> target gNB, two tunnels in series
Who allocates the TEIDs	The target, in HANDOVER REQUEST ACKNOWLEDGE	The core, during the path switch or (for NG/N2) during handover preparation
Added latency	One transport hop -- typically 1-5 ms	Two hops through the core -- commonly 10-30 ms, and it is added to every forwarded packet
Cost	Xn transport capacity between two RAN sites	N3 capacity, twice, plus UPF processing
Diagnostic signature	Forwarded PDUs arrive at the target with source gNB source IP	Forwarded PDUs arrive from a UPF address, interleaved with live N3 traffic on the same interface -- much harder to separate in a capture

Table 12. Xn handover normally forwards directly; the indirect case is worth recognising because its extra latency can exceed the interruption it is covering.

12.2 What travels, and how it is numbered

Figure 6. A forwarded PDU. The PDCP PDU Number extension header is what distinguishes an already-numbered SDU (retain the SN) from a fresh one (the target assigns from the DL COUNT it was given).

What the source holds	Is it forwarded?	With a PDCP SN?	Why
SDUs already RLC-acknowledged by the UE	No	--	The UE has them. Forwarding would produce duplicates that PDCP at the UE has to discard.
PDUs handed to RLC, not yet acknowledged	Yes	Yes -- the SN already assigned	The UE may or may not have them. The SN lets the UE's PDCP reordering and duplicate detection sort it out.
SDUs numbered but not yet handed to RLC	Yes	Yes	Same reasoning; the SN is already committed and must not change.
SDUs received from the UPF after the SN status was frozen	Yes	No -- the target assigns from the DL COUNT	The source stopped assigning SNs when it sent SN STATUS TRANSFER. Continuous numbering across the boundary is what preserves in-order delivery.
SDUs whose `discardTimer` expired while waiting	No	--	PDCP discard applies during handover exactly as it does normally. Forwarding stale data wastes Xn capacity and delivers packets the application has already timed out.
SDUs on a DRB for which the target offered no forwarding address	No	--	The target has declined forwarding for that bearer (§7). The source discards.

Table 13. The forwarding decision, per SDU. The fourth row is the one that makes SN STATUS TRANSFER necessary.

12.3 In-order delivery, duplicates, and the End Marker

The target now has two downlink sources for the same bearer: forwarded SDUs from the source over Xn-U, and -- once the path switch completes -- fresh SDUs from the UPF on the new N3 tunnel. Those two streams arrive over different paths with different latencies, so they can and do interleave. Delivering them in arrival order would present the UE with out-of-order PDCP SNs and, worse, with newer data before older.

The rule is therefore simple and strict: the target delivers everything forwarded before anything from the new path. It buffers new-path SDUs until it knows the forwarded stream has ended. Knowing that is what the End Marker is for.

Step	Node	Action
1	UPF	On the N4 modification that switches the path, sends a GTP-U End Marker (message type 254, no payload) on the old N3 tunnel, then starts sending on the new one.
2	Source gNB	Recognises the End Marker as the last thing it will ever receive for this UE, and forwards it over the Xn-U tunnel behind the last real forwarded PDU.
3	Target gNB	On receiving the forwarded End Marker, stops expecting forwarded data, releases the reordering buffer for the new path, and begins delivering new-path SDUs.
4	Both	The Xn-U forwarding tunnels are released. The source frees the UE context on receiving XnAP UE CONTEXT RELEASE (§13).

Table 14. The End Marker's whole purpose is step 3. Without it the target must guess when forwarding has ended, and guessing means either reordering delay or out-of-order delivery.

💡

Key point

Duplicates are expected, not exceptional. The UE's PDCP receives some SDUs twice -- once over the air from the source before it left, once forwarded to the target -- and discards the second copy using the receive window and the SN. That only works because the SNs were preserved across the boundary. A source that renumbers forwarded data, or a target that assigns new SNs to SDUs that arrived with one, breaks duplicate detection and delivers the same TCP segments twice. TCP recovers; a codec does not.

Figure 7. The forwarding tunnel must outlive the interruption at both ends -- it opens before the UE leaves and closes after the End Marker. Sizing a forwarding buffer against the interruption alone under-provisions it by roughly a factor of two.

13. Completion: Path Switch and UE Context Release

By the time the core network hears about the handover, it is already over. RRCReconfigurationComplete has arrived, the UE is being scheduled, and uplink user data is already flowing from the target straight to the UPF -- because the target was given the UPF's uplink address in HANDOVER REQUEST (§5). Only downlink is still wrong, and fixing it is the path switch TS 38.413 cl. 8.4.4.

IE	Message	Contents	Why it is there
Source AMF UE NGAP ID	PATH SWITCH REQUEST	The AMF UE NGAP ID the source gave the target in HANDOVER REQUEST	The only way the AMF can find the UE context. This is the field that makes Xn handover intra-AMF (§1).
RAN UE NGAP ID	PATH SWITCH REQUEST	The target's newly allocated RAN-side identifier	Replaces the source's. Every later NGAP message for this UE uses it.
User Location Information	PATH SWITCH REQUEST	Target NR-CGI, TAI, timestamp	The core's record of where the UE is; feeds charging, lawful intercept and location services.
PDU Session Resources To Be Switched in Downlink List	PATH SWITCH REQUEST	Per session: PDU Session ID and the DL NG-U UP TNL Information at the target	The actual instruction. The SMF turns it into an N4 rule at the UPF.
PDU Session Resources Failed To Setup List	PATH SWITCH REQUEST	Sessions the target did not admit, with Cause	Tells the core to release them; otherwise the UPF keeps sending downlink data for a bearer that no longer exists.
Security Context: NCC and NH	PATH SWITCH REQUEST ACKNOWLEDGE	A fresh `{NCC, NH}` pair computed by the AMF	Seeds the next handover's vertical key derivation. See companion 27 AS Security Mode.
PDU Session Resources Switched List	PATH SWITCH REQUEST ACKNOWLEDGE	Which sessions were switched, with the UPF's UL TNL info if it changed	Confirmation per session. A session missing from this list has not been switched, whatever the overall result says.
PDU Session Resources Released List	PATH SWITCH REQUEST ACKNOWLEDGE	Sessions the core has torn down	The core's response to partial admission.

Table 15. NGAP path switch, abridged. Note that the acknowledge carries security material -- the path switch is not purely a user-plane operation.

💡

Key point

Why the path switch happens after the UE arrives, rather than in parallel with preparation: because until RRCReconfigurationComplete lands, the handover might still fail, and the UE might come back to the source. If the N3 tunnel had already been moved, a T304 expiry would leave a UE on the source cell with its downlink data going to the target -- a failure the source cannot repair without another core-network round trip. Doing it last means a failed handover costs the core network nothing at all.

XnAP UE CONTEXT RELEASE then closes the procedure. It is class 2 and carries little more than the two XnAP UE IDs. On receiving it the source releases the UE context, sends F1AP UE CONTEXT RELEASE COMMAND to its own DU, tears down the Xn-U forwarding tunnels and frees the C-RNTI. Until it arrives, the source must keep everything -- context, buffers and tunnels -- because the UE may yet come back.

🔍

What you see in logs

The target sends UE CONTEXT RELEASE only after PATH SWITCH REQUEST ACKNOWLEDGE. So a stalled AMF or SMF does not merely delay the core update: it pins the source gNB's context and forwarding buffers for the whole duration. On a busy source cell handing over many UEs, a slow path switch shows up as rising memory and Xn-U buffer occupancy at the source, which is nowhere near the actual fault.

14. Timers on Both Sides

Timer	Where	Started	Stopped	On expiry	Typical
`TRELOCprep`	Source gNB	On sending HANDOVER REQUEST	On HANDOVER REQUEST ACKNOWLEDGE or HANDOVER PREPARATION FAILURE	The source abandons preparation and sends HANDOVER CANCEL with Cause `tRELOCprep-expiry`. The UE is untouched.	50-200 ms
`TXnRELOCoverall`	Target gNB	On sending HANDOVER REQUEST ACKNOWLEDGE	On PATH SWITCH REQUEST ACKNOWLEDGE (i.e. the handover completed)	The target releases the reserved UE context, F1AP resources and CFRA preamble. A UE arriving after this is unknown to the target.	1-2 s
`T304`	UE	On applying `reconfigurationWithSync`	On successful random access and delivery of `RRCReconfigurationComplete`	Handover failure: revert to the source configuration, store `VarRLF-Report`, initiate re-establishment.	`ms100` FR1
`t-Reordering`	UE and target PDCP	On a PDCP reordering gap	When the gap is filled or the window advances past it	The gap is declared permanent and SDUs above it are delivered. Forwarding latency above this value causes avoidable loss.	ms50-ms100
`discardTimer`	Source PDCP (per DRB)	When an SDU arrives from SDAP	When the SDU is RLC-acknowledged	The SDU is discarded and not forwarded (§12).	ms50-ms500
Data-forwarding hold timer	Source gNB (implementation)	On starting forwarding	On XnAP UE CONTEXT RELEASE	Forwarding tunnels are torn down even without a release, to stop a lost class 2 message leaking resources forever.	1-5 s

Table 16. TRELOCprep and TXnRELOCoverall are XnAP timers TS 38.423 cl. 9.4; T304 and the PDCP timers are RRC-configured. Typical values are what many vendors ship, not spec requirements.

⚠️

Common pitfall

TXnRELOCoverall is much longer than T304 on purpose, and the relationship is the one to check when handovers fail intermittently. It has to outlast the UE's entire T304 window plus the re-establishment the UE may attempt at the target -- because if the target has already released the context, it cannot verify the shortMAC-I in an RRCReestablishmentRequest and must reject it, turning a recoverable handover failure into a full RRC setup and an NAS-visible service interruption. A TXnRELOCoverall configured shorter than T304 + re-establishment time is a self-inflicted drop.

15. The Complete Failure Taxonomy

Figure 8. The two ends of the cost spectrum. The dividing line is whether the UE had been told to move: before the command, failure is free; after it, failure costs a re-establishment.

Failure	Who detects it	How it appears	What the UE does	What it points at
Preparation failure	Source gNB	HANDOVER PREPARATION FAILURE with a Cause	Nothing -- it was never told	Target capacity, a stale served-cell list, an unsupported S-NSSAI or 5QI, or a slice/capability mismatch. Read the Cause; it is usually accurate.
Preparation timeout	Source gNB	`TRELOCprep` expiry, then HANDOVER CANCEL	Nothing	Xn-C transport, or a target that is overloaded at the CU rather than on the radio. Distinguish from the above: a timeout means no answer, a failure means a considered no.
Partial admission	Nobody, by default	A successful acknowledge with a non-empty Not Admitted List	Applies the command and silently releases the refused bearers	Target-side per-slice or per-5QI admission limits. Invisible to standard KPIs (§8).
Command lost on the air	UE (never receives it); source never learns	No source-side symptom. Target-side `TXnRELOCoverall` eventually expires.	Nothing -- carries on with the source, or declares RLF if the radio was that bad	Too-late handover: the source cell had already degraded past the point where SRB1 was reliable. The classic MRO too-late case; see companion 22 Handover Overview.
RACH failure at the target	UE	`preambleTransMax` exhausted, or no RAR within `ra-ResponseWindow`, inside T304	Keeps retrying until T304 expires	Uplink coverage at the target worse than the downlink measurement suggested; a stale or wrong CFRA index; a TDD or SSB mismatch in `spCellConfigCommon`.
T304 expiry	UE	The UE reverts and initiates re-establishment; the target sees a UE it prepared but never met	Revert to the source configuration, store `VarRLF-Report`, select a cell, re-establish	The endpoint of every execution-phase failure. The `VarRLF-Report` the UE stores is the diagnostic -- retrieve it from the cell the UE lands on.
Integrity failure on arrival	Target gNB	`RRCReconfigurationComplete` arrives and fails its MAC-I check	It believes it succeeded, then loses the connection	A key-derivation mismatch: NCC, or the wrong PCI/ARFCN used in the `K_NG-RAN` derivation. Companion 27 AS Security Mode*.
Path switch failure	Target gNB	PATH SWITCH REQUEST FAILURE, or no response	Nothing at first -- it has service	An AMF/SMF/UPF problem, or a `Source AMF UE NGAP ID` the AMF does not recognise. The target must then release the UE (NGAP UE CONTEXT RELEASE REQUEST), so the user does lose service -- after appearing to have succeeded.
Lost UE CONTEXT RELEASE	Source gNB (only via its own timer)	Nothing on Xn; a source-side context that never goes away	Nothing	Class 2 with no acknowledgement. Symptom is source-side context and buffer leakage, cleaned up only by the implementation's hold timer (§14).

Table 17. Nine failure modes. Note how many are detected by a node other than the one that can fix them, and how many are not reported at all.

15.1 Cause values worth recognising

Cause group	Value	What it really means
radioNetwork	`no-radio-resources-available-in-target-cell`	Genuine admission rejection. Check the target cell's load, not the radio.
radioNetwork	`unknown-GUAMI-ID`	The target has no NG-C association to the UE's AMF. Precondition three in §1 -- this handover should have been NG/N2.
radioNetwork	`cell-not-available` / `unknown-target-ID`	The target cell is not (or no longer) served by this peer. Almost always a stale served-cell list (§3).
radioNetwork	`tRELOCprep-expiry`	Seen in HANDOVER CANCEL, not in a failure. The source gave up waiting.
radioNetwork	`ho-target-not-allowed`	Policy or mobility restriction at the target, not capacity.
radioNetwork	`slice-not-supported` / `no-QoS-flow-established`	The target cannot serve an S-NSSAI or a 5QI in the request. Common when a slice is deployed unevenly across a cluster.
transport	`transport-resource-unavailable`	N3 or Xn-U transport, not radio. Often the only warning you get before the Xn-U problem in §2.
protocol	`abstract-syntax-error-reject`, `semantic-error`	A genuine encoding disagreement. Read Criticality Diagnostics; this is a software or release mismatch, not a network condition.
misc	`om-intervention`	Someone locked the target cell. Not a fault.

Table 18. XnAP Cause values TS 38.423 cl. 9.2.6. Grouping outgoing preparation failures by Cause per neighbour relation is the single highest-value mobility dashboard you can build.

15.2 Reversion, cancellation, and what the target is left holding

When the UE fails at the target, it reverts to the source configuration it kept for exactly this purpose and then performs re-establishment. Two outcomes follow, and both are normal:

The UE selects the target cell. The target still holds the prepared context (if TXnRELOCoverall has not expired), can verify the shortMAC-I, and accepts the re-establishment. The handover effectively succeeds, several hundred milliseconds late, and is counted as a failure by every KPI. This is the good outcome.
The UE selects the source cell, or a third cell. The receiving gNB fetches the context -- from the source over Xn with RETRIEVE UE CONTEXT if it is a third cell -- and the source sends HANDOVER CANCEL to the target with a Cause such as ue-not-available-for-ps or radio-connection-with-ue-lost. The target then releases the reserved context, the CFRA preamble and the forwarding tunnels.

HANDOVER CANCEL is also the source's tool in three non-failure cases: a better candidate appeared after preparation completed, the UE stopped meeting the trigger condition, or the source prepared several candidates and needs to cancel the ones it did not use. That last case is normal for conditional handover -- see companion 25 Conditional Handover and DAPS, where cancellation of unused prepared candidates is part of the steady-state design rather than an exception.

16. Worked Arithmetic

Figure 9. The same budget as the calculation below, drawn to scale. The red bars are the only ones the user experiences; the blue-only portions are latency the network spends on its own.

16.1 An interruption budget for one Xn handover

💡

INTERRUPTION BUDGET

Scenario. FR1, 30 kHz SCS (slot 0.5 ms), TDD DDDSU. Source and target gNBs on the same Xn with 2 ms one-way transport latency. CFRA configured at the target. Two PDU sessions, both admitted.

Contributions, from the measurement report to the first downlink PDU at the UE:

Report -> RRM decision: 2 ms (report arrives, source runs candidate selection, derives K_NG-RAN*).

HANDOVER REQUEST -> ACKNOWLEDGE: 2 ms out + 3 ms at the target (admission control plus the F1AP round trip of §9) + 2 ms back = 7 ms.

Command transmission and UE processing: 1 ms to schedule and transmit on SRB1, plus 10 ms of UE RRC processing and re-configuration = 11 ms. This is where the interruption starts.

Retune and acquire the target SSB: 3 ms (the UE already has target measurements, so this is retune plus one SSB occasion, not a full search).

Wait for the next PRACH occasion, transmit the CFRA preamble, receive the RAR: 2.5 ms average wait + 1 ms preamble + ra-ResponseWindow latency of 5 ms = 8.5 ms.

RRCReconfigurationComplete on SRB1, then the target's first downlink grant: 3.5 ms.

Interruption = 11 + 3 + 8.5 + 3.5 = 26 ms. Total procedure to the path switch acknowledge = 26 + 2 + 7 + 20 = 55 ms.

Reading the result. Only 11 of the 26 ms are radio; 14.5 ms are UE processing and PRACH-occasion waiting. Halving the Xn latency would improve the procedure by 2 ms and the interruption by nothing at all. The levers that matter are PRACH occasion density at the target and UE processing capability -- which is why DAPS and conditional handover, not faster transport, are the mechanisms that attack this number (companion 25).

16.2 Reconstructing an SN status transfer

💡

SN STATUS RECONSTRUCTION

Given. DRB 1, PDCP SN length 18 bits, so COUNT = HFN(14) || SN(18) and the SN space is 2^18 = 262,144. At the moment the source freezes the state it has: assigned downlink SNs up to and including 4,101 in HFN 3; RLC-acknowledged up to and including 4,089; 12 PDUs (4,090..4,101) handed to RLC but unacknowledged; 3 SDUs still in the PDCP queue whose discardTimer expired 2 ms ago.

Downlink. DL COUNT Value = { HFN = 3, PDCP-SN = 4,102 }, i.e. COUNT = 3 x 262,144 + 4,102 = 790,534. That is the next SN the target will assign.

Forwarded with their SN: the 12 PDUs 4,090..4,101, each carrying its SN in the GTP-U PDCP PDU Number extension header.

Not forwarded: SN <= 4,089 (the UE already has them) and the 3 discarded SDUs (never numbered, discard already applied).

Forwarded without an SN: everything that arrives from the UPF from now until the End Marker. The target numbers them 4,102, 4,103, ... continuing the sequence.

Uplink. Suppose the source has received uplink SNs up to 1,270 in order, and then 1,272, 1,273 and 1,275 out of order. UL COUNT Value = { HFN = 3, PDCP-SN = 1,271 } -- the first missing SN, not the last received. Receive Status of UL PDCP SDUs is a bitmap starting at SN 1,272: 1101 0000... -- bits for 1,272, 1,273 and 1,275 set, 1,274 and beyond clear.

Result. The UE will retransmit 1,271 and 1,274 (and anything above 1,275 it had not yet had acknowledged); the target will not wait for 1,272, 1,273 or 1,275. Without the bitmap the target would either stall its reordering window on SNs it already has, or deliver a gap it did not need to.

16.3 Sizing the forwarding buffer

💡

FORWARDING BUFFER

Given. A UE receiving 150 Mbit/s downlink at the moment of handover. Forwarding must run from SN STATUS TRANSFER (1 ms after the command) until the forwarded End Marker clears the target (44 ms after the command, from the timeline in §12) -- a forwarding lifetime of 43 ms.

Per-UE forwarded volume = 150 x 10^6 bit/s x 0.043 s = 6.45 Mbit = 806 kbyte. Add the pre-existing PDCP backlog: 12 unacknowledged PDUs at, say, 1,200 bytes is another 14 kbyte, so call it 820 kbyte per handover.

Xn-U instantaneous rate. The target must absorb the forwarded stream and the new N3 stream over the last few milliseconds of overlap, so provision Xn-U for the full 150 Mbit/s per concurrent handover, not for the average.

At cell scale. A cell handing over 20 UEs per second at this rate, each holding a buffer for 43 ms, has 20 x 0.043 = 0.86 handovers in flight on average -- so about 700 kbyte of steady-state forwarding buffer. That is comfortable. The number that hurts is the burst: a coverage-hole event or a cell outage that moves 200 UEs at once needs 200 x 820 kbyte = 164 Mbyte of buffer and 30 Gbit/s of Xn-U capacity for the duration.

Reading the result. Forwarding is cheap per handover and expensive per event. This is why implementations cap forwarding -- by buffer, by rate, or by declining forwarding addresses for some DRBs -- and why a mass mobility event produces post-handover data loss that a single handover test never reproduces.

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. IP addresses are taken from the RFC 5737 documentation ranges and the PLMN is the reserved test PLMN 001-01, so nothing here can be mistaken for operator data.

One UE, one handover, throughout. Source cell NR-CGI 001-01-0x0A1B2C001 (PCI 231), target cell NR-CGI 001-01-0x0A1B3D002 (PCI 417). Source C-RNTI 0x4C21, target C-RNTI 0x5A03. Two PDU sessions: 5 (5QI 9, DRB 1) and 6 (5QI 1, DRB 2).

17.1 XnAP HANDOVER REQUEST

[XnAP] HANDOVER REQUEST, source -> target

09:41:07.412  [XnAP-TX] peer=gNB-ID 0x0A1B3D  stream 2  HANDOVER REQUEST
  initiatingMessage  procedureCode = 0 (handoverPreparation)  criticality = reject
  sourceNG-RANnodeUEXnAPID ........ 0x00005B21
  cause
    radioNetwork .................. handover-desirable-for-radio-reasons
  targetCellGlobalID
    nr .. plmn-id 001-01  nr-cell-identity 0x0A1B3D002   -- PCI 417's NR-CGI
  guami .. plmn 001-01  amf-region-id 0x02  amf-set-id 0x001  amf-pointer 0x01
  uEContextInfoHORequest
    ng-c-UE-reference ............. 0x0000000012F4E2     -- AMF UE NGAP ID
    signalling-TNL-at-source ...... 192.0.2.11
    ueSecurityCapabilities
      nr-EncryptionAlgorithms ..... 'NEA1,NEA2'  (bitmap 0110 0000 ...)
      nr-IntegrityProtectionAlgs .. 'NIA1,NIA2'
    securityInformation
      key-NG-RAN-Star ............. <256 bits>   -- KDF(K_gNB, PCI 417, ARFCN)
      ncc ......................... 5            -- copied into masterKeyUpdate
    ue-AMBR  dl = 1000000000  ul = 500000000     -- bit/s
    pduSessionResourcesToBeSetup-List
      [0] pduSessionId ............ 5
          s-NSSAI  sst = 0x01
          pduSessionType ........... ipv4
          uL-NG-U-TNLatUPF  gtp-tunnel  198.51.100.5 : TEID 0x0000A1F3
          dataForwardingRequest .... dl-forwarding-proposed
          drb-ToBeSetup-List
            drbID 1  pdcp-SN-Size-DL = 18 bits  pdcp-SN-Size-UL = 18 bits
                     rlc-mode = rlc-am   discardTimer = ms100
                     qosFlow 1  5QI 9  arp 8  non-GBR
      [1] pduSessionId ............ 6
          s-NSSAI  sst = 0x01
          uL-NG-U-TNLatUPF  gtp-tunnel  198.51.100.5 : TEID 0x0000A1F4
          dataForwardingRequest .... (absent)     -- voice: no forwarding wanted
          drb-ToBeSetup-List
            drbID 2  pdcp-SN-Size-DL = 12 bits   rlc-mode = rlc-um
                     qosFlow 1  5QI 1  arp 2  GBR  gfbr-dl 38400 gfbr-ul 38400
    rrc-Context ................... (OCTET STRING, 512 bytes)
                                    -- HandoverPreparationInformation, opaque to XnAP
    mobilityRestrictionList  serving-plmn 001-01  (no forbidden TAs)
    index-to-RAT-FrequencySelectionPriority .. 6
  ueHistoryInformation
    [0] nr-CGI 0x0A1B2C001  PCI 231  timeUE-StayedInCell 41 s
    [1] nr-CGI 0x0A1B2C003  PCI 233  timeUE-StayedInCell 12 s
  -- 512-byte RRC Context is a delta-capable sourceConfig, not a fullConfig

Listing 2. Note dataForwardingRequest present for PDU session 5 and absent for the voice session 6 -- the source is not asking for what it does not want (§7). The UE History Information gives you the UE's last two cells for free.

17.2 XnAP HANDOVER REQUEST ACKNOWLEDGE

[XnAP] HANDOVER REQUEST ACKNOWLEDGE, target -> source

09:41:07.419  [XnAP-RX] peer=gNB-ID 0x0A1B3D  stream 2
                        HANDOVER REQUEST ACKNOWLEDGE   (elapsed 7.1 ms)
  successfulOutcome  procedureCode = 0 (handoverPreparation)
  sourceNG-RANnodeUEXnAPID ........ 0x00005B21     -- echo, matches
  targetNG-RANnodeUEXnAPID ........ 0x0000AC41     -- the target's handle
  pduSessionResourcesAdmitted-List
    [0] pduSessionId ............. 5
        dL-NG-U-TNLatNG-RAN  gtp-tunnel  192.0.2.21 : TEID 0x0000C351
                                        -- goes into PATH SWITCH REQUEST later
        qosFlowsAdmitted-List ..... { qfi 1 }
        dataForwardingInfoFromTarget
          dl-forwarding-UP-TNL  gtp-tunnel  192.0.2.21 : TEID 0x00A10001
                                        -- the Xn-U tunnel for DRB 1
    [1] pduSessionId ............. 6
        dL-NG-U-TNLatNG-RAN  gtp-tunnel  192.0.2.21 : TEID 0x0000C352
        qosFlowsAdmitted-List ..... { qfi 1 }
        dataForwardingInfoFromTarget .. (absent)   -- as requested
  pduSessionResourcesNotAdmitted-List .. (absent)  -- full admission
  target2SourceNG-RANnodeTransparentContainer
    (OCTET STRING, 287 bytes)
      HandoverCommand
        handoverCommandMessage  (OCTET STRING, 281 bytes)
          -- an RRCReconfiguration; see 17.3. XnAP does not decode this.
  criticalityDiagnostics ........... (absent)
  -- 287-byte container: a delta reconfiguration. A fullConfig here would
  -- typically be 700-1100 bytes and take longer for the UE to apply.

Listing 3. The two address families in one message: dL-NG-U-TNLatNG-RAN is for the core to use after the path switch; dl-forwarding-UP-TNL is for the source to use immediately.

17.3 The RRCReconfiguration as the UE sees it

[RRC] RRCReconfiguration with reconfigurationWithSync

09:41:07.421  [RRC-DL] SRB1  DL-DCCH-Message  RRCReconfiguration  281 bytes
              -- ciphered and integrity-protected with the SOURCE keys
  rrc-TransactionIdentifier ........ 1
  criticalExtensions rrcReconfiguration
    radioBearerConfig
      drb-ToAddModList
        [0] drb-Identity 1  reestablishPDCP  recoverPDCP-absent
        [1] drb-Identity 2  reestablishPDCP
      securityConfig
        securityAlgorithmConfig
          cipheringAlgorithm ....... nea2      -- target's choice, was nea2
          integrityProtAlgorithm ... nia2
        keyToUse ................... master
    masterCellGroup  (OCTET STRING -> CellGroupConfig, 198 bytes)
      cellGroupId .................. 0
      rlc-BearerToAddModList  { lcid 1 (SRB1), lcid 4 (DRB1), lcid 5 (DRB2) }
      mac-CellGroupConfig  bsr-Config  drx-Config (short cycle absent)
      physicalCellGroupConfig  pdsch-HARQ-ACK-Codebook = dynamic
      spCellConfig
        servCellIndex ............ 0
        reconfigurationWithSync
          spCellConfigCommon
            physCellId ........... 417              -- the target
            downlinkConfigCommon
              frequencyInfoDL  absoluteFrequencySSB 632640  offsetToPointA 24
              initialDownlinkBWP  genericParameters  locationAndBandwidth 12925
            uplinkConfigCommon  initialUplinkBWP  rach-ConfigCommon (...)
            tdd-UL-DL-ConfigurationCommon  dl-UL-TransmissionPeriodicity ms2p5
            ssb-PositionsInBurst  inOneGroup '10101010'
          newUE-Identity ......... 0x5A03           -- target C-RNTI
          t304 ................... ms100
          rach-ConfigDedicated uplink
            cfra
              occasions  rach-ConfigGeneric  prach-ConfigurationIndex 159
                         ssb-perRACH-Occasion one
              resources ssb
                ssb-ResourceList
                  { ssb-Index 3, ra-PreambleIndex 61 }
                  { ssb-Index 4, ra-PreambleIndex 62 }
              ra-Prioritization  powerRampingStepHighPriority dB2
        rlmInSyncOutOfSyncThreshold .. (absent)
    masterKeyUpdate
      keySetChangeIndicator ........ FALSE          -- horizontal derivation
      nextHopChainingCount ......... 5              -- matches the NCC in 17.1
    measConfig  measIdToRemoveList { 1, 2 }  measObjectToAddModList (...)

09:41:07.421  [RRC] T304 started (100 ms)
09:41:07.421  [RRC] source configuration stored for possible revert
09:41:07.422  [MAC] source cell released, MAC reset, C-RNTI 0x4C21 discarded

Listing 4. Every value under reconfigurationWithSync was produced by the target DU in the F1AP exchange of §9. The nextHopChainingCount is the one field that originated at the source -- compare it with the NCC in 17.1.

17.4 F1AP UE CONTEXT SETUP at the target

[F1AP] target CU <-> DU, and the arrival that follows

-- Target-side view. Note the timestamps: this completes 2 ms BEFORE the
-- source even transmits the handover command in 17.3.

09:41:07.414  [F1AP-TX] to gNB-DU 0x01  UE CONTEXT SETUP REQUEST
  gNB-CU-UE-F1AP-ID ................ 0x00021A7C
  spCell-ID  nr-CGI 001-01-0x0A1B3D002
  servCellIndex .................... 0
  cuToDURRCInformation
    uE-CapabilityRAT-ContainerList .. (240 bytes, lifted from the RRC Context)
    measConfig ...................... (absent)
  srbs-ToBeSetup-List  { srbID 1, srbID 2 }
  drbs-ToBeSetup-List
    [0] drbID 1  qosInformation  5QI 9  arp 8
        uLUPTNLInformation-ToBeSetup  192.0.2.21 : TEID 0x00B10001
        rLCMode .................... rlc-am-bi-directional
    [1] drbID 2  qosInformation  5QI 1  arp 2  gbr 38400/38400
        uLUPTNLInformation-ToBeSetup  192.0.2.21 : TEID 0x00B10002
        rLCMode .................... rlc-um-bi-directional

09:41:07.417  [F1AP-RX] from gNB-DU 0x01  UE CONTEXT SETUP RESPONSE
  gNB-CU-UE-F1AP-ID ................ 0x00021A7C
  gNB-DU-UE-F1AP-ID ................ 0x0000913B
  duToCURRCInformation
    cellGroupConfig ................ (198 bytes)
      -- contains newUE-Identity 0x5A03 and the cfra ssb-ResourceList
      -- that appear verbatim in 17.3
  c-RNTI ........................... 0x5A03
  drbs-Setup-List
    [0] drbID 1  dLUPTNLInformation  192.0.2.21 : TEID 0x00B20001
    [1] drbID 2  dLUPTNLInformation  192.0.2.21 : TEID 0x00B20002
  srbs-FailedToBeSetup-List ........ (absent)

09:41:07.417  [DU-MAC] UE context created, C-RNTI 0x5A03, no air activity yet
09:41:07.417  [DU-MAC] CFRA reserved: ra-PreambleIndex 61 (SSB 3), 62 (SSB 4)
09:41:07.419  [XnAP-TX] HANDOVER REQUEST ACKNOWLEDGE  (see 17.2)

              ... 26 ms of nothing on this UE context ...

09:41:07.443  [DU-PHY] PRACH detected  preamble 61  SSB 3  TA est 21
09:41:07.443  [DU-MAC] CFRA index 61 -> C-RNTI 0x5A03  (no TC-RNTI needed)
09:41:07.445  [DU-MAC] RAR sent: TA command 21, UL grant 6 PRB
09:41:07.448  [DU-MAC] UL-SCH from C-RNTI 0x5A03, LCID 1 (SRB1), 24 bytes
09:41:07.448  [F1AP-TX] UL RRC MESSAGE TRANSFER  srbID 1
                        -- NOT initialULRRCMessageTransfer: context exists
09:41:07.449  [RRC] RRCReconfigurationComplete  MAC-I verified with new K_RRCint
09:41:07.449  [RRC] T304 stopped at the UE; handover complete on the air
09:41:07.450  [F1AP-TX] UE CONTEXT MODIFICATION REQUEST
                        transmissionActionIndicator = restart
                        -- DRBs activated, CFRA resource released

Listing 5. The 26 ms gap is the whole point of this trace. A target DU context that sits idle for tens of milliseconds after setup is behaving correctly -- it is waiting for a UE that has not yet been told to come.

17.5 SN status transfer and forwarding

[XnAP / GTP-U] SN STATUS TRANSFER and the forwarding tunnel

09:41:07.422  [XnAP-TX] SN STATUS TRANSFER  (class 2, no response expected)
  sourceNG-RANnodeUEXnAPID ......... 0x00005B21
  targetNG-RANnodeUEXnAPID ......... 0x0000AC41
  drbsSubjectToStatusTransfer-List
    [0] drbID 1
        receiveStatusOfULPDCPSDUs .. '1101 0000 0000 0000'B
        ul-COUNTValue  pdcp-SN = 1271   hfn = 3      -- first missing UL SN
        dl-COUNTValue  pdcp-SN = 4102   hfn = 3      -- next DL SN to assign
    -- no entry for drbID 2: RLC-UM voice, no SN continuity required

09:41:07.423  [GTP-U-TX] Xn-U 192.0.2.11 -> 192.0.2.21  TEID 0x00A10001
              12 G-PDUs, ext hdr PDCP PDU Number, SNs 4090..4101
              -- the RLC-unacknowledged backlog, SNs preserved
09:41:07.424  [PDCP-SRC] 3 SDUs discarded (discardTimer ms100 expired), not forwarded
09:41:07.425  [GTP-U-TX] TEID 0x00A10001  G-PDU, no PDCP PDU Number ext hdr
              -- fresh SDU from the UPF; the target will number it 4102

09:41:07.463  [GTP-U-RX] old N3 198.51.100.5 -> 192.0.2.11  msg type 254
              End Marker, TEID 0x00009C10, length 0
09:41:07.464  [GTP-U-TX] End Marker forwarded on Xn-U TEID 0x00A10001
09:41:07.466  [PDCP-TGT] End Marker received; forwarding complete
              in-order delivery released, new-path SDUs now delivered
09:41:07.468  [XnAP-RX] UE CONTEXT RELEASE  src=0x00005B21 tgt=0x0000AC41
09:41:07.468  [XnAP]    Xn-U forwarding tunnels torn down, context freed

Listing 6. Only DRB 1 appears in the status transfer: an RLC-UM voice bearer has no delivery guarantee to preserve, which is the same reason the target declined a forwarding address for it.

17.6 A failure case: preparation rejected, then a second candidate

[XnAP] HANDOVER PREPARATION FAILURE, then partial admission

09:52:18.104  [RRC-UL] MeasurementReport  measId 2  eventA3
                       servCell PCI 231 RSRP -104   PCI 417 RSRP -93
09:52:18.106  [XnAP-TX] HANDOVER REQUEST  target 0x0A1B3D002 (PCI 417)
                       3 PDU sessions, one 5QI 1 GBR 38400/38400
09:52:18.106  [XnAP]    TRELOCprep started (100 ms)

09:52:18.113  [XnAP-RX] HANDOVER PREPARATION FAILURE
  unsuccessfulOutcome  procedureCode = 0 (handoverPreparation)
  sourceNG-RANnodeUEXnAPID ......... 0x00006E02
  cause
    radioNetwork ................... no-radio-resources-available-in-target-cell
  criticalityDiagnostics ........... (absent)
09:52:18.113  [XnAP]    TRELOCprep stopped
09:52:18.113  [RRC]     prepared K_NG-RAN* discarded; UE not informed
09:52:18.113  [RRM]     candidate PCI 417 blacklisted for 2000 ms
09:52:18.113  [RRM]     next candidate: PCI 419 (NR-CGI 0x0A1B3D004), RSRP -97

09:52:18.114  [XnAP-TX] HANDOVER REQUEST  target 0x0A1B3D004 (PCI 419)
09:52:18.122  [XnAP-RX] HANDOVER REQUEST ACKNOWLEDGE
  pduSessionResourcesAdmitted-List ...... { 5, 6 }
  pduSessionResourcesNotAdmitted-List
    [0] pduSessionId 7  cause radioNetwork: slice-not-supported
                       -- s-NSSAI sst=0x02 sd=0x0000C8 not deployed on PCI 419
09:52:18.123  [RRC-DL] RRCReconfiguration relayed to the UE
                       -- radioBearerConfig releases DRB 3 (was PDU session 7)
09:52:18.161  [XnAP-RX] UE CONTEXT RELEASE   -- handover "successful"

-- Outcome: the handover is counted as one preparation failure and one
-- success. Nothing counts the slice the UE silently lost.

Listing 7. Two of the failure modes in §15 in one sequence: an honest rejection that costs the user nothing, followed by a partial admission that costs a slice and is recorded as a success.

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

Release	Change on Xn	Why it matters when reading a trace
Rel-15	XnAP defined: handover preparation, SN status transfer, UE context release, Xn setup and configuration update; direct and indirect forwarding; NGAP path switch	The baseline. Everything in §4 exists here.
Rel-16	Conditional handover (CHO) adds a Conditional Handover Information Request/Update and cancellation of prepared candidates; DAPS adds Early Status Transfer and dual-connectivity-like forwarding; NR-U and IAB extensions; Mobility Robustness Optimisation over Xn (Failure Indication, Handover Report)	A source may now hold several prepared targets at once, and cancellation of a prepared handover becomes routine rather than exceptional. See companion 25 Conditional Handover and DAPS.
Rel-16	EARLY STATUS TRANSFER as a distinct procedure from SN STATUS TRANSFER	Lets the source hand over the downlink COUNT before it stops transmitting -- essential for DAPS, where the source keeps serving the UE after the command.
Rel-17	Inter-donor IAB migration; NR multicast/broadcast context over Xn; RACH-less handover for a subset of cases; enhanced `ueHistoryInformation` with the visited-cell type	New IEs appear in HANDOVER REQUEST that older peers must skip via criticality. Populated Criticality Diagnostics on a working handover is usually this.
Rel-18	Layer 1/Layer 2 triggered mobility (LTM), where the target cell is pre-configured and the switch is a MAC CE rather than an RRC procedure; NTN mobility with feeder-link switch; further MRO extensions	LTM does not use HANDOVER REQUEST per cell switch at all -- the Xn preparation happens once and many switches follow. A log that shows cell changes with no XnAP activity is LTM, not a broken trace.

Table 19. Rel-16 is the release that changes how you read an Xn trace, because it breaks the one-preparation-per-handover assumption.

🔄

Release delta

EARLY STATUS TRANSFER is the one addition worth understanding even if you never touch DAPS. Ordinary SN STATUS TRANSFER can only be sent once the source has stopped assigning downlink SNs, which means it cannot be sent early. Early Status Transfer breaks that coupling: it conveys the downlink COUNT of the first SDU the target should send, letting the target prepare while the source is still transmitting. If you see both messages for one handover, you are looking at DAPS.

19. Reading Xn Handover in Logs: A Checklist

Anchor on the two XnAP UE IDs. sourceNG-RANnodeUEXnAPID and targetNG-RANnodeUEXnAPID are the join keys for the whole procedure. Every message from HANDOVER REQUEST ACKNOWLEDGE onward carries both; a message quoting an ID the other side has released is a late message, not a corrupt one (§14).
Check the preparation round-trip time first. HANDOVER REQUEST to HANDOVER REQUEST ACKNOWLEDGE should be single-digit milliseconds on a well-provisioned Xn (§16.1). Tens of milliseconds means either transport or a target CU that is slow to get its DU to answer (§9) -- and both are invisible on the radio.
Diff the To Be Setup list against the Admitted list, every time. A non-empty Not Admitted List is a partial admission: a successful handover in which the UE lost a bearer (§8). No standard counter will tell you this happened.
Confirm the container is a container. If your tool shows you an RRCReconfiguration under HANDOVER REQUEST ACKNOWLEDGE, it decoded the transparent container for you. Remember that its author is the target (§6) -- an RRC problem in a message the source transmitted is a target-side bug.
Match nextHopChainingCount in the RRC against the NCC in HANDOVER REQUEST. They must be equal. A mismatch means the target rewrote a field it should have copied, and the observable consequence is a MAC-I failure on the target's SRB1 (§15).
Look for F1AP UE CONTEXT SETUP at the target before any PRACH. It should precede the preamble by the Xn round trip plus UE processing (§9). If the target's first sign of the UE is a PRACH with no matching context, either F1AP failed or TXnRELOCoverall had already expired.
Verify the ordering: RRC command, then SN STATUS TRANSFER, then forwarding. Any other order lengthens the interruption or loses data (§4). Check that the DRB set in the status transfer matches the DRB set in the admitted list, and that RLC-UM bearers are legitimately absent.
Follow the End Marker end to end. It should appear on the old N3 tunnel, then on Xn-U, then be consumed by the target (§12.3). A missing End Marker means the target is guessing when to stop reordering, and the symptom is post-handover jitter, not loss.
Time the path switch separately. PATH SWITCH REQUEST to ACKNOWLEDGE is core-network latency and does not affect the interruption -- but it gates XnAP UE CONTEXT RELEASE, and so pins source-side buffers (§13).
On failure, classify by whether the UE had been told. Preparation failure and TRELOCprep expiry are free. Anything after the RRC command costs a re-establishment. The two have different owners and different fixes (§15).
Group preparation failures by Cause and by neighbour relation. no-radio-resources-available-in-target-cell against one cell is load; cell-not-available against one peer is a stale served-cell list; unknown-GUAMI-ID means the relation should not be using Xn at all (§15.1).

20. Glossary

Term	Expansion	Meaning in this document
Xn-C	Xn control plane	XnAP over SCTP between two NG-RAN nodes; one long-lived association per peer, carrying all handover signalling.
Xn-U	Xn user plane	GTP-U tunnels between two NG-RAN nodes; created per DRB per handover for data forwarding, and torn down afterwards.
XnAP	Xn Application Protocol	TS 38.423. Class 1 procedures have a response and can fail explicitly; class 2 procedures do not.
Transparent container	--	An XnAP `OCTET STRING` carrying an RRC message the peer authored. XnAP does not decode it (§6).
`HandoverPreparationInformation`	--	The RRC message inside the source-to-target container: UE capabilities and the source's current `AS-Config`.
`HandoverCommand`	--	The RRC message inside the target-to-source container; its `handoverCommandMessage` is the `RRCReconfiguration` the UE receives.
`K_NG-RAN*`	--	The key the source derives from the current `K_gNB`, the target PCI and the target downlink ARFCN; it becomes the target's `K_gNB`.
NCC	Next hop Chaining Count	0..7. Sent in HANDOVER REQUEST and copied into `nextHopChainingCount` in the RRC; tells the UE which derivation to perform.
COUNT	--	The 32-bit PDCP counter, `HFN \|\| SN`. Its continuity across the handover is what SN STATUS TRANSFER preserves (§11).
Direct forwarding	--	Downlink data forwarded source-to-target over Xn-U, one GTP-U tunnel per DRB. The normal case on Xn.
Indirect forwarding	--	Forwarding routed through the UPF because no usable user-plane path exists between the gNBs; two hops instead of one.
End Marker	--	A GTP-U PDU (message type 254, no payload) sent by the UPF on the old tunnel at the path switch, and forwarded by the source; the target's signal that forwarding has ended.
Path switch	--	The NGAP procedure moving the downlink N3 tunnel to the target at the UPF. Uplink needs no equivalent (§5, §13).
`TRELOCprep`	--	Source-side XnAP timer supervising handover preparation; expiry causes HANDOVER CANCEL (§14).
`TXnRELOCoverall`	--	Target-side XnAP timer supervising the whole relocation; expiry releases the prepared context (§14).
Partial admission	--	The target admits some PDU sessions and refuses others. The handover succeeds with fewer bearers, and no KPI notices (§8).

21. References

3GPP TS 38.423 -- Xn Application Protocol (XnAP). Clause 8.2 (UE-associated mobility procedures: handover preparation, SN status transfer, UE context release, handover cancel), clause 8.3 (further UE-associated procedures), clause 8.4 (global procedures: Xn setup, NG-RAN node configuration update, Xn removal, reset), clause 9.1.1 (message and IE definitions), clause 9.2.6 (Cause), clause 9.4 (timers).
3GPP TS 38.420 -- Xn general aspects and principles. The functional split between Xn-C and Xn-U.
3GPP TS 38.421 / 38.422 / 38.424 -- Xn layer 1, Xn signalling transport (SCTP, port 38422), Xn data transport (GTP-U, UDP 2152).
3GPP TS 38.300 -- NR overall description. Clause 9.2.3 (mobility in RRC_CONNECTED), clause 9.2.3.2 (inter-gNB handover including the Xn sequence and data forwarding), clause 16 (CU/DU aspects).
3GPP TS 38.413 -- NG Application Protocol (NGAP). Clause 8.4.4 (Path Switch Request), clause 9.2 (IEs including the Security Context and PDU Session lists), clause 9.3.1 (Cause).
3GPP TS 38.473 -- F1 Application Protocol (F1AP). Clause 8.3 (UE context management: UE Context Setup, Modification, Release), clause 8.4 (RRC message transfer), and the CUtoDURRCInformation / DUtoCURRCInformation IE definitions.
3GPP TS 38.401 -- NG-RAN architecture description. Clause 6.1 (CU/DU functional split), clause 8.2 (Xn handover with the CU/DU split made explicit).
3GPP TS 38.331 -- RRC protocol specification. RRCReconfiguration, CellGroupConfig, ReconfigurationWithSync, MasterKeyUpdate, RACH-ConfigDedicated, HandoverPreparationInformation and HandoverCommand (clause 6.2.2), UE-TimersAndConstants.
3GPP TS 38.323 -- PDCP specification. COUNT, HFN, the reordering and duplicate-discard behaviour that makes forwarding work, discardTimer and t-Reordering.
3GPP TS 29.281 -- GPRS Tunnelling Protocol User Plane (GTPv1-U). Clause 5.1 (header format), clause 5.2 (extension headers, including PDCP PDU Number), and the End Marker message.
3GPP TS 33.501 -- Security architecture and procedures for 5G. Clause 6.9.2 (key handling in handover), Annex A (the K_NG-RAN* derivation function).
3GPP TS 23.502 -- Procedures for the 5G System. Clause 4.9.1.2 (Xn-based handover from the core network's point of view, including indirect forwarding).

Companion documents in this set

22 Handover Overview -- the framework this document sits inside: the handover taxonomy, the three phases, reconfigurationWithSync, T304, the interruption budget in general, and the MRO too-early / too-late / wrong-cell classification. Read it first.
24 NG / N2 Handover -- what happens when the Xn preconditions in §1 do not hold: the same procedure with the AMF relaying preparation, and indirect forwarding as the norm.
25 Conditional Handover and DAPS -- multiple prepared targets, EARLY STATUS TRANSFER, and how both mechanisms attack the 26 ms interruption of §16.1.
20 Measurements and Events -- the A3 report that starts everything in §4, and the thresholds that decide when.
21 Measurement Gaps and SMTC -- how the UE measured the target cell in the first place, and the measurementTimingConfiguration exchanged at Xn Setup (§3).
03 Random Access -- the CFRA procedure at the target in §9 and §16.1, in detail.
16 RLM and RLF -- where a T304 expiry goes next, and the VarRLF-Report the UE stores on the way.
27 AS Security Mode -- K_NG-RAN*, the NCC, and the vertical / horizontal key derivation that the path switch acknowledge reseeds.
15 RRC Procedures -- re-establishment, the recovery path for every execution-phase failure in §15.
26 UE Capability -- what is inside the ue-CapabilityRAT-List that travels in the RRC Context and is handed to the target DU in §9.