🗂️ RRC — Radio Resource ControlAdvanced

N2 / NG-based Handover (with exact IEs) in 5G NR

Handover via the core when there's no Xn — Handover Required/Request/Command over NGAP, with the AMF/UPF path switch.

📚 3GPP-basedTS 23.502TS 38.413TS 38.300

An NG handover is the same handover as an Xn handover with the AMF standing between the two gNBs. That single change turns two messages into nine, adds a service-based leg to the SMF and, on an inter-AMF move, a second AMF and a key derivation the UE has to be told about. This document is the procedural detail for that case: when the source chooses N2 and how you tell from a log that it did, every NGAP message named and decoded, the transparent-container principle that survives the extra relay unchanged, indirect data forwarding through the UPF and the two extra hops it costs, UPLINK and DOWNLINK RAN STATUS TRANSFER as the split equivalent of Xn's single status message, TNGRELOCprep and TNGRELOCoverall against T304 at the UE, K_AMF handling across an AMF boundary, the Xn-versus-N2 comparison in numbers, and the failure taxonomy that has one more owner in it than Xn's does. The framework -- taxonomy, phases, reconfigurationWithSync, T304, MRO -- is in the companion 22 Handover Overview; the Xn case in full is the companion 23 Xn Handover.

Contents

01When NG/N2 Is Used, and How the Source Chooses
02The Nodes, the Interfaces, and NGAP Itself
03The Full Message Sequence
04HANDOVER REQUIRED, Field by Field
05Inside the AMF: Target Selection, Inter-AMF Transfer, the SMF Leg
06HANDOVER REQUEST and HANDOVER REQUEST ACKNOWLEDGE
07The Transparent Container Principle, Relayed
08HANDOVER COMMAND and Execution on the Air
09UPLINK and DOWNLINK RAN STATUS TRANSFER
10Data Forwarding: Indirect by Default
11Completion: HANDOVER NOTIFY, Path Update, Context Release
12Security Across an Inter-AMF Handover
13Inter-PLMN and Roaming
14Timers: TNGRELOCprep, TNGRELOCoverall and T304
15Xn against NG/N2, Side by Side
16The NG/N2 Failure Taxonomy
17Worked Arithmetic
18Illustrative Message Traces
19Release Deltas: Rel-15 to Rel-18
20Reading NG/N2 Handover in Logs: A Checklist
21Glossary
22References

1. When NG/N2 Is Used, and How the Source Chooses

An NG handover -- everyone says N2 handover, after the interface between the gNB and the AMF -- exists for the cases Xn cannot reach. Xn requires a direct SCTP association between two NG-RAN nodes that already know each other's served cells; where that association does not exist, or does not extend to the target cell, the source has exactly one other way to ask, and that is to ask the AMF. TS 38.300 cl. 9.2.3.2

Three preconditions send a handover down the N2 path, and it is worth separating them because they have different fixes.

Trigger	What the source actually observes	Is it a fault?	Where the fix lives
No Xn to the target	The target NR-CGI resolved from the measurement report does not appear in the served-cell list of any Xn peer, so there is no `XnAP` association to send a HANDOVER REQUEST on.	Sometimes. A brand-new neighbour, a partitioned transport network, or a peer whose Xn Setup never completed all look identical here.	Xn Setup / NG-RAN Node Configuration Update, or transport. See companion 23 Xn Handover §3.
Inter-AMF move	The target's TAI is outside the list of TAIs the serving AMF supports, so even with an Xn association the core-network context has to move.	No. This is planned topology, and N2 is the only mechanism that moves the UE's NGAP and NAS context between AMFs.	Nothing to fix. Design the AMF set boundaries to fall where mobility is low.
Inter-PLMN or inter-operator	The target's PLMN ID differs from the serving PLMN. There is no Xn between operators in any normal deployment.	No.	Roaming agreement and the `mobilityRestrictionList` (§13).
Policy	An Xn association exists and would work, but the operator has configured the relation as N2-only -- commonly during Xn commissioning, across a vendor boundary, or where a lawful-intercept or charging requirement wants the core in the loop.	No, but it is frequently a forgotten setting.	The neighbour relation table on the source gNB.

Table 1. Only the first row is a fault condition, and only sometimes. An operator seeing NG handovers is not necessarily seeing a problem -- but an operator seeing NG handovers between two cells that share an Xn association almost certainly is.

The decision is made at the source, once, before anything is transmitted, and it is never renegotiated. There is no fallback from Xn to N2 mid-procedure and no fallback the other way. If an Xn preparation fails, the source may pick a different candidate cell, or it may retry the same cell over N2 as a fresh preparation -- but that is a new decision, taken after the first one failed, and it appears in the log as two separate procedures with two separate timers.

🔍

What you see in logs

This matters for log reading more than anything else in §1. NGAP and XnAP carry no field that says why this interface. The only evidence of the source's decision is which interface the first preparation message appears on -- XnAP HANDOVER REQUEST or NGAP HANDOVER REQUIRED.

So the diagnostic question is never "why did it choose N2". It is "what does the source believe about this neighbour relation", and the answer is in the source's configuration, not in the trace.

Figure 1. The same preparation, routed two ways. Count the boxes that have to be alive and responsive in each row: two against five.

One thing does not change: the UE. Nothing in the RRCReconfiguration the UE receives tells it which interface prepared the handover, and nothing in its behaviour differs. T304, the CFRA attempt at the target, the revert-on-failure -- all identical to the Xn case in companion 22 Handover Overview §6. A UE-side log cannot distinguish an Xn handover from an N2 handover, and any tool that claims to is inferring it from timing.

2. The Nodes, the Interfaces, and NGAP Itself

An Xn handover involves two nodes and one protocol. An N2 handover involves up to six nodes and three protocols, and the boundaries between those protocols are where the latency and most of the failure modes live.

Figure 2. The intra-AMF case collapses the two AMF boxes into one and removes the Namf_Communication_CreateUEContext exchange; everything else survives. The I-UPF is present only when the SMF decides the PDU Session Anchor is too far from the target to serve it directly.

Node	Role in this procedure	Protocol it speaks here	What it can independently refuse
Source gNB	Decides the handover, builds `HandoverPreparationInformation`, relays the target's `RRCReconfiguration`, forwards downlink data, reports PDCP status.	NGAP over SCTP on N2; GTP-U on N3 and on the forwarding tunnel; F1AP to its own DU.	Nothing -- by this point it has already committed.
Source AMF	Owns the UE's NGAP association and NAS context. Resolves the Target ID, decides whether it serves the target's TAI, and either continues alone or selects a target AMF.	NGAP on N2; HTTP/2 service-based interface to the NRF, target AMF and SMFs.	The whole handover, with HANDOVER PREPARATION FAILURE -- typically for `unknown-targetID` or `ho-target-not-allowed`.
Target AMF	Present only on an inter-AMF move. Creates the UE context, drives the SMF interactions, and becomes the serving AMF at completion.	HTTP/2 to the source AMF and the SMFs; NGAP to the target gNB.	The `Namf_Communication_CreateUEContext` request, which the source AMF then turns into a preparation failure.
SMF	One per PDU session. Decides whether the session can be served from the target, whether an I-UPF is needed, and allocates the indirect forwarding tunnel endpoints.	HTTP/2 to the AMF; PFCP on N4 to its UPFs.	Individual PDU sessions -- which is how a handover ends up partially admitted before the target has even been asked.
UPF (PSA)	The N3 anchor. Holds the downlink tunnel that must move from the source gNB to the target gNB, and emits the End Marker when it does.	PFCP on N4; GTP-U on N3 and N9.	Nothing at handover time; it executes what the SMF installs.
I-UPF	Optional intermediate UPF. May be inserted, relocated or removed at the handover, and is the node that usually terminates the indirect forwarding tunnels.	PFCP on N4; GTP-U on N3 and N9.	Nothing directly; an N4 session establishment failure here surfaces as an SMF-side failure.
Target gNB	Admission control, F1AP context setup at its DU, authorship of the `RRCReconfiguration`, allocation of the downlink forwarding endpoints.	NGAP on N2; F1AP to its DU; GTP-U on N3 and the forwarding tunnel.	The handover, with HANDOVER FAILURE, or individual PDU sessions via the Failed-to-Setup list.

Table 2. Read the last column as a list of places the procedure can end. Xn has one entry in it; NG/N2 has four.

2.1 NGAP: classes, identifiers, and what an SCTP association carries

NGAP TS 38.413 runs over SCTP on port 38412, one association per AMF the gNB is configured to reach, established by NG Setup at start of day. Every UE-associated message carries a pair of identifiers, and they are the join keys for the entire procedure.

Identifier	Allocated by	Range	Changes at an inter-AMF handover?	Use when reading a trace
`RAN-UE-NGAP-ID`	The NG-RAN node	INTEGER (0..2^32-1)	Yes -- the target gNB allocates its own; it has never heard of the source's.	Correlates all messages for one UE on one gNB's association.
`AMF-UE-NGAP-ID`	The AMF	INTEGER (0..2^40-1)	Yes -- the target AMF allocates a new one. Same UE, different number.	Correlates all messages for one UE on one AMF's association.
`GUAMI`	Configured on the AMF	PLMN + AMF Region ID (8 bit) + AMF Set ID (10 bit) + AMF Pointer (6 bit)	Yes, on an inter-AMF move -- that is what makes it inter-AMF.	The single most useful field for deciding whether a trace is intra- or inter-AMF.

Table 3. Two of the three identifiers change mid-procedure. Any tool that correlates a handover on AMF-UE-NGAP-ID alone will lose the UE at the AMF boundary and report two half-handovers.

NGAP procedures come in two classes, exactly as XnAP's do. Class 1 procedures have a defined response and can fail explicitly: Handover Preparation (HANDOVER REQUIRED → HANDOVER COMMAND or HANDOVER PREPARATION FAILURE), Handover Resource Allocation (HANDOVER REQUEST → ACKNOWLEDGE or HANDOVER FAILURE), Handover Cancellation, UE Context Release. Class 2 procedures are fire-and-forget with no response at all: Handover Notification, Uplink and Downlink RAN Status Transfer, Error Indication. TS 38.413 cl. 8.4

⚠️

Common pitfall

A class 2 message that is lost is lost silently. There is no retransmission at NGAP level and no acknowledgement to be missing -- SCTP is the only thing standing between you and a vanished HANDOVER NOTIFY.

The observable symptom is specific and worth memorising: the UE is on the target and happy, uplink data flows, and downlink data does not, because nothing ever triggered the path update. Then TNGRELOCoverall expires at the target and it releases a UE that is actively being served.

3. The Full Message Sequence

Three figures, because the whole thing at readable size is taller than a screen. The phase boundaries are the ones in companion 22 Handover Overview §3: preparation is everything before the UE is told, execution is everything between the UE being told and the UE arriving, completion is everything after.

Figure 3. Seven numbered hops and two service-based round trips, none of which the UE knows about. Note that TNGRELOCprep runs at the source and covers all of it -- the source is supervising work being done by four nodes it cannot see.

Figure 4. Identical on the air to an Xn handover. The two differences are structural: one Xn status message becomes two NGAP messages with an AMF between them, and one Xn-U tunnel becomes two GTP-U tunnels with a UPF between them.

Figure 5. There is no PATH SWITCH REQUEST here and no equivalent of it. The AMF has been coordinating from the start, so HANDOVER NOTIFY -- an unacknowledged class 2 message -- is sufficient to trigger the path update.

#	Message or operation	From → to	Phase	Class	What it commits
1	MeasurementReport	UE → source gNB	Prep	RRC	Nothing. Evidence, not a request.
2	NGAP HANDOVER REQUIRED	source gNB → source AMF	Prep	1	The source's intent. Starts `TNGRELOCprep`.
3	Namf_Communication_CreateUEContext	source AMF → target AMF	Prep	SBI	Moves the UE's core-network context. Inter-AMF only.
4	Nsmf_PDUSession_UpdateSMContext	AMF → SMF (per session)	Prep	SBI	The SMF's assessment of whether the session survives the move, and the uplink N3 endpoint the target will use.
5	NGAP HANDOVER REQUEST	AMF → target gNB	Prep	1	Asks the target to reserve resources. Starts `TNGRELOCoverall`.
6	NGAP HANDOVER REQUEST ACKNOWLEDGE	target gNB → AMF	Prep	1	The target's resources, its `RRCReconfiguration`, and its forwarding endpoints. The target is now committed.
7	Nsmf_PDUSession_UpdateSMContext	AMF → SMF	Prep	SBI	Indirect forwarding tunnel setup, using the target's endpoints.
8	NGAP HANDOVER COMMAND	source AMF → source gNB	Prep	1	Ends preparation. Stops `TNGRELOCprep`. The source may now transmit.
9	RRCReconfiguration	source gNB → UE	Exec	RRC	The point of no return. T304 starts; the UE leaves.
10	NGAP UPLINK RAN STATUS TRANSFER	source gNB → source AMF	Exec	2	PDCP COUNT continuity. Unacknowledged.
11	NGAP DOWNLINK RAN STATUS TRANSFER	AMF → target gNB	Exec	2	The same container, relayed unchanged.
12	GTP-U forwarding, two hops	source → UPF → target	Exec	--	Buffered and in-flight downlink data.
13	CFRA + RRCReconfigurationComplete	UE ↔ target gNB	Exec	RRC	Arrival. T304 stops.
14	NGAP HANDOVER NOTIFY	target gNB → target AMF	Compl	2	Triggers the path update. Unacknowledged -- see §2.1.
15	Nsmf_PDUSession_UpdateSMContext	AMF → SMF	Compl	SBI	The downlink path moves to the target at the UPF. End Marker emitted.
16	Namf_Communication_N2InfoNotify	target AMF → source AMF	Compl	SBI	Tells the source AMF the handover completed. Inter-AMF only.
17	NGAP UE CONTEXT RELEASE COMMAND / COMPLETE	source AMF ↔ source gNB	Compl	1	Frees the source. The source's only positive confirmation of success.

Table 4. Nine NGAP messages against Xn's four, plus four to six service-based operations and two to six PFCP exchanges that never appear in a RAN trace at all. §15 turns this into numbers.

💡

Key point

Steps 9 through 13 are identical to the Xn case in companion 23 Xn Handover §10, message for message and field for field. If you are debugging an air-interface problem in an N2 handover, everything you know about Xn execution still applies -- go straight to that document and come back here only when the problem is on the ground.

4. HANDOVER REQUIRED, Field by Field

HANDOVER REQUIRED is the source's request to the AMF, and it is the closest N2 equivalent of Xn's HANDOVER REQUEST -- with one large difference of intent. Xn's HANDOVER REQUEST is the request to the target, and carries everything the target needs. HANDOVER REQUIRED asks the AMF to arrange a handover, and carries everything the AMF needs to decide where to send it, plus an opaque container for the target. TS 38.413 cl. 8.4.1

IE	Presence	Content	Consequence if wrong
`AMF-UE-NGAP-ID` / `RAN-UE-NGAP-ID`	M	The existing UE association on this N2 interface.	`unknown-local-UE-NGAP-ID`; the AMF cannot even fail it against a UE context.
`HandoverType`	M	ENUMERATED { `intra5gs`, `fivegs-to-eps`, `eps-to-5gs`, `fivegs-to-utran`, ... }. Everything in this document is `intra5gs`.	An `intra5gs` handover declared as `fivegs-to-eps` sends the AMF looking for an MME over N26 and fails with `n26-interface-not-available` -- a confusing cause for a pure NR handover.
`Cause`	M	Typically `radioNetwork: handover-desirable-for-radio-reason`; also `time-critical-handover`, `resource-optimisation-handover`, `reduce-load-in-serving-cell`.	None functionally. But it is the only field that records why, and load-balancing handovers that claim radio reasons make MRO statistics meaningless.
`TargetID`	M	`targetRANNodeID` = { Global RAN Node ID, Selected TAI }, or `targetENB-ID` for EPS. The TAI is what the AMF routes on, not the cell.	`unknown-targetID` if no AMF in the set serves that TAI. A stale neighbour table produces this reliably and the target never hears about it (§16).
`DirectForwardingPathAvailability`	O	ENUMERATED { `directPathAvailable` }. Present only if the source knows a direct user-plane path to the target exists.	Absent when it should be present costs the extra forwarding hop for no reason (§10). Present when it should be absent gives you a forwarding tunnel to an unreachable address, and silent data loss.
`PDUSessionResourceListHORqd`	M	One entry per PDU session the source wants to move, each carrying a `HandoverRequiredTransfer` octet string with the per-session direct forwarding availability.	A session omitted here is a session released at the handover, silently. No counter records it.
`SourceToTarget-TransparentContainer`	M	Opaque to NGAP; carries `HandoverPreparationInformation` and the target cell ID (§7).	The AMF cannot detect a malformed container. The target rejects it with an abstract syntax error and the source sees a generic failure.

Table 5. Compare the TargetID row with companion 23 Xn Handover §5, where the source addresses the target cell directly on an established association. Here it names a cell and a TAI and hopes the core knows how to reach them.

⚠️

Common pitfall

DirectForwardingPathAvailability is the field most worth checking early in an N2 trace, because it is the one the source can be wrong about without anything failing.

The source is asserting that a user-plane path to the target exists. In a deployment where Xn control plane is absent but the two gNBs share a transport domain, that assertion is true and saves a hop. In a deployment where they do not, the assertion is false, the SMF believes it, no indirect tunnel is built, and the forwarded data goes nowhere. The symptom is a clean handover with a burst of TCP retransmissions immediately afterwards -- and nothing in any NGAP trace to explain it.

4.1 The container, in ASN.1

NGAP HandoverRequired and the source-to-target container

-- TS 38.413, abridged. Only the IEs discussed above are shown.

HandoverRequired ::= SEQUENCE {
    protocolIEs   ProtocolIE-Container { {HandoverRequiredIEs} },
    ...
}

-- id-AMF-UE-NGAP-ID           mandatory  reject
-- id-RAN-UE-NGAP-ID           mandatory  reject
-- id-HandoverType             mandatory  reject
-- id-Cause                    mandatory  ignore
-- id-TargetID                 mandatory  reject
-- id-DirectForwardingPathAvailability   optional   ignore
-- id-PDUSessionResourceListHORqd        mandatory  reject
-- id-SourceToTarget-TransparentContainer mandatory reject

TargetID ::= CHOICE {
    targetRANNodeID     TargetRANNodeID,
    targetENB-ID        TargetENB-ID,
    ...
}

TargetRANNodeID ::= SEQUENCE {
    globalRANNodeID     GlobalRANNodeID,
    selectedTAI         TAI,               -- what the AMF routes on
    iE-Extensions       ProtocolExtensionContainer { ... } OPTIONAL,
    ...
}

-- The container itself is defined in TS 38.413 cl. 9.3.1 and is an
-- OCTET STRING to NGAP.  Its decoded form:

SourceNGRANNode-ToTargetNGRANNode-TransparentContainer ::= SEQUENCE {
    rRCContainer                    RRCContainer,
                                    -- HandoverPreparationInformation
    pDUSessionResourceInformationList
            PDUSessionResourceInformationList        OPTIONAL,
    e-RABInformationList            E-RABInformationList  OPTIONAL,
    targetCell-ID                   NGRAN-CGI,
    indexToRFSP                     IndexToRFSP           OPTIONAL,
    uEHistoryInformation            UEHistoryInformation,
    iE-Extensions                   ProtocolExtensionContainer { ... }
                                                          OPTIONAL,
    ...
}

Listing 1. targetCell-ID appears inside the container as well as in the TargetID IE outside it. The outer one routes; the inner one tells the target which of its own cells to prepare. A target serving many cells needs the inner one, and a mismatch between the two is a real and hard-to-see misconfiguration.

5. Inside the AMF: Target Selection, Inter-AMF Transfer, the SMF Leg

This section is the part of the procedure with no Xn counterpart at all, and it is where most of the 40-odd extra milliseconds go. It is also almost entirely invisible from the RAN: neither gNB sees any of it, and a RAN-side trace shows only a gap between HANDOVER REQUIRED and HANDOVER REQUEST that could be anything.

5.1 Resolving the target and deciding whether to relocate the AMF

The AMF takes the selectedTAI from the TargetID and asks a simple question: do I serve this TAI? If yes, it is an intra-AMF handover and the AMF proceeds directly to HANDOVER REQUEST. If no, the AMF must find one that does, which it does by querying the NRF for an AMF supporting that TAI and the UE's allowed NSSAI, or from local configuration where the AMF set topology is static.

Case	AMF behaviour	Extra messages	Typical extra latency	How you spot it in a trace
Intra-AMF	Serves the target TAI itself; keeps the UE context.	None	0 ms	The `GUAMI` in HANDOVER REQUEST equals the one the source was using.
Inter-AMF, same PLMN	Selects a target AMF, transfers the UE context to it, and stays involved only as the source's N2 peer until release.	`Namf_Communication_CreateUEContext` request and response; `Namf_Communication_N2InfoNotify` at completion	6-12 ms, dominated by SBI round trips and NRF discovery	New `GUAMI`, new `AMF-UE-NGAP-ID`, and a possible `nas-Container` in the RRC (§12).
Inter-PLMN	As above, plus the target AMF belongs to a different PLMN and the context crosses a security boundary (SEPP).	The same operations, routed through the two SEPPs	15-40 ms, and highly variable -- inter-operator transport is not engineered for milliseconds	PLMN differs in the `GUAMI` and in the target NR-CGI (§13).
Inter-AMF with I-SMF insertion	The target area is served by a different SMF service area, so an intermediate SMF is inserted for the session.	`Nsmf_PDUSession_Create` toward the I-SMF in addition to the update toward the anchor SMF	10-25 ms per affected PDU session	Invisible from the RAN. The only RAN-visible symptom is a long preparation.

Table 6. The first row is the common case in a well-planned network and costs nothing beyond the N2 hops themselves. The rest is why an N2 preparation budget has to be quoted as a range.

5.2 Namf_Communication_CreateUEContext

The inter-AMF context transfer is a single HTTP/2 POST carrying, in one request body, everything the target AMF needs to act as this UE's AMF: the SUPI and permanent identifiers, the allowed and subscribed NSSAI, the list of PDU sessions with their SMF instance IDs, the UE's 5G security context including K_AMF (or a horizontally derived K_AMF', §12), the UE radio capabilities, the mobility restrictions, and the N2 information -- the TargetID and the source-to-target transparent container, passed through untouched. TS 23.502 cl. 4.9.1.3.2

The response carries the N2 information for the reverse direction: the target-to-source transparent container and the per-session forwarding endpoints, which the source AMF then packs into HANDOVER COMMAND. In other words the entire target-side preparation happens inside one SBI request/response pair, and from the source AMF's point of view the target AMF, the SMF, the UPF and the target gNB are one very slow node.

🔍

What you see in logs

That framing explains a class of incident that otherwise looks impossible. When an inter-AMF preparation is slow, the source AMF has no visibility into which of the four downstream nodes is slow, and neither do you from a RAN trace.

The only way to decompose it is the target AMF's own log: the interval between its receipt of CreateUEContext and its transmission of HANDOVER REQUEST is SMF time; the interval between HANDOVER REQUEST and the ACKNOWLEDGE is target-gNB time. Without that log you are guessing.

5.3 The SMF leg, and why it runs twice

Nsmf_PDUSession_UpdateSMContext is invoked twice per PDU session during preparation, for two genuinely different reasons, and confusing them makes the flow look redundant when it is not.

Invocation	When	What the AMF supplies	What the SMF returns	Why it cannot be merged with the other
First -- feasibility and uplink path	Before HANDOVER REQUEST	Target ID, target TAI, the handover indication	Whether the session can be served from the target at all; the uplink N3 TNL information (UPF address and TEID) that the target must send uplink data to; the QoS profiles to be set up	The target cannot be asked to reserve resources until it knows what to reserve and where to send uplink data.
Second -- forwarding tunnels	After HANDOVER REQUEST ACKNOWLEDGE	The target's downlink forwarding endpoints, learned from the ACKNOWLEDGE	The forwarding tunnel endpoint at the UPF that the source will transmit into	The endpoint the source forwards to is chosen by the UPF only once the UPF knows where to forward it on to -- which is not known until the target has answered.

Table 7. This ordering is forced, not conventional, and it is why the SMF appears twice in the preparation ladder. Roughly 20 ms of the N2 preparation budget in §17 is these two round trips.

Each invocation is also an opportunity for the SMF to decide the session cannot move. A session refused here never reaches the target: it appears in HANDOVER COMMAND's PDUSessionResourceToReleaseListHOCmd and the source releases the corresponding DRB when it relays the RRCReconfiguration. The UE simply finds a bearer gone. This is the N2 analogue of the partial admission described in companion 23 Xn Handover §8, with the important difference that the core caused it and no RAN counter will ever attribute it.

6. HANDOVER REQUEST and HANDOVER REQUEST ACKNOWLEDGE

From the target gNB's point of view an N2 handover and an Xn handover are nearly the same job. It receives a request containing a security context, a list of PDU sessions to set up, and an opaque container describing the UE; it runs admission control; it sets up its DU over F1AP; it authors an RRCReconfiguration; it answers. The differences are in who asks and in two fields.

IE in HANDOVER REQUEST	Presence	Content and range	Difference from the Xn equivalent
`HandoverType`	M	`intra5gs` for everything here.	No Xn equivalent -- Xn cannot cross a system boundary, so the question never arises.
`UEAggregateMaximumBitRate`	M	Subscribed non-GBR aggregate, bit/s.	Comes from the AMF's subscription data rather than being relayed by the source gNB. It is therefore authoritative here and merely a copy on Xn.
`UESecurityCapabilities`	M	NR and E-UTRA encryption and integrity algorithm bitmaps.	Same content, different origin -- the AMF's stored NAS-level view.
`SecurityContext`	M	{ `nextHopChainingCount` (0..7), `nextHopNH` (BIT STRING (256)) }.	The key difference. The AMF supplies `NH`, so the target always performs a vertical key derivation. On Xn the source supplies `K_NG-RAN*` directly and horizontal derivation is possible (§12).
`PDUSessionResourceSetupListHOReq`	M	Per session: PDU session ID, S-NSSAI, and a `PDUSessionResourceSetupRequestTransfer` octet string carrying the uplink N3 TNL information, PDU session type, QoS flow list and any `DataForwardingNotPossible` indication.	The nesting is deeper: on Xn the DRB configuration is visible in the XnAP message, here it is inside a per-session transfer container the AMF does not decode.
`AllowedNSSAI`	M	The slices the UE may use in the target area.	No Xn equivalent. This is the field that causes a slice to be dropped at an area boundary.
`GUAMI`	M	The target AMF's identity.	Tells the target which AMF now owns the UE. Compare with the source's `GUAMI` to classify the handover.
`NASC` (NAS-PDU)	O	A NAS container the target must relay to the UE inside the `RRCReconfiguration`.	No Xn equivalent. Present when the NAS security context changes (§12).
`SourceToTarget-TransparentContainer`	M	Relayed verbatim from HANDOVER REQUIRED.	Identical content to Xn's `rrc-Context`, one relay further from its author.

Table 8. Four IEs here have no Xn counterpart, and three of the four (AllowedNSSAI, SecurityContext, NASC) exist because the core is asserting things about the UE that no gNB is entitled to assert.

6.1 HANDOVER REQUEST ACKNOWLEDGE

The acknowledgement carries three distinct things that are easy to confuse because they are all GTP-U endpoints and they all live in the same per-session transfer container.

Endpoint	Whose address	Who uses it	For how long	Where it goes next
`dL-NGU-UP-TNLInformation`	Target gNB	The UPF, for downlink N3 traffic	For the life of the session on the target	To the SMF, which installs it in the UPF at the path update (§11).
`dLForwardingUP-TNLInformation`	Target gNB	The UPF's forwarding function, or the source directly if direct forwarding is possible	The forwarding window only -- tens of milliseconds	To the SMF in the second `UpdateSMContext` (§5.3), which chains it to the tunnel it gives the source.
`uLForwardingUP-TNLInformation`	Target gNB	The source, for forwarding uplink data the source received but could not deliver	The forwarding window only	Rarely used. Present when the source has undelivered uplink PDCP SDUs, which mostly means RLC-AM bearers under congestion.

Table 9. Three addresses on the same node with three different lifetimes. A tool that shows you "the target's TEID" without saying which one is not telling you anything.

Sessions the target could not admit appear in PDUSessionResourceFailedToSetupListHOAck, each with its own cause. The handover still succeeds. Combined with the sessions the SMF refused in §5.3, a UE can arrive at the target with strictly fewer bearers than it left with, from two independent causes, and the procedure is recorded as a success by every standard counter on both sides.

⚠️

Common pitfall

Diff three lists on every N2 handover, not two: the sessions in HANDOVER REQUIRED, the sessions in HANDOVER REQUEST, and the sessions in the Admitted list of the ACKNOWLEDGE.

A session that disappears between list one and list two was refused by the SMF or the AMF, and the target never saw it. A session that disappears between list two and list three was refused by the target. These have completely different owners, and the Xn habit of comparing only the request and the admitted list will attribute the first kind to the wrong node.

7. The Transparent Container Principle, Relayed

This is the single most useful comparison in the document, and it is a comparison in which almost nothing changes. The nesting that companion 23 Xn Handover §6 describes for XnAP is identical in NGAP: four levels of encapsulation in each direction, with the innermost level authored by the far end and copied verbatim by everything in between.

Figure 6. The only structural difference from the Xn figure is the box in the middle. The container that leaves the source gNB arrives at the target gNB byte-identical, having been copied through one or two AMFs and, on an inter-AMF move, across an HTTP/2 body as a base64-encoded N2 information element.

Level	Xn	NG/N2	Decoded by
1 -- transport IE	`UE Context Information` in XnAP HANDOVER REQUEST	`Source to Target Transparent Container` IE in NGAP HANDOVER REQUIRED	XnAP / NGAP, as an OCTET STRING
2 -- container	`RRC Context` OCTET STRING	`SourceNGRANNode-ToTargetNGRANNode-TransparentContainer`, itself PER-encoded	The target gNB only
3 -- RRC message	`HandoverPreparationInformation`	`HandoverPreparationInformation` -- the same message, unchanged	The target gNB's RRC layer
4 -- payload	`ue-CapabilityRAT-List`, `as-Config`, `rrm-Config`	Identical	The target gNB's RRC layer
Reverse 1	`Target to Source Transparent Container` in ACKNOWLEDGE	The same IE, in ACKNOWLEDGE and again in HANDOVER COMMAND	XnAP / NGAP, as an OCTET STRING
Reverse 2-4	`HandoverCommand` → `handoverCommandMessage` → `RRCReconfiguration`	Identical, byte for byte	The UE. Not the source gNB, and not the AMF.

Table 10. Level 2 has a different ASN.1 type name on the two interfaces but the same fields. Levels 3 and 4 are the same RRC messages from TS 38.331 in both cases -- which is precisely why a single target implementation serves both interfaces.

The practical consequences are worth stating explicitly, because they are the ones people get wrong when the AMF is in the path.

The AMF cannot validate a container, and must not try. NGAP types it as an OCTET STRING and gives the AMF no schema. An AMF that rejects a handover on container content is either decoding RRC it has no business decoding, or has a length check that a longer container from a newer release will eventually trip.
An RRC problem in the message the source transmitted is a target-side bug. The source relayed bytes it did not author and cannot read. This is true on Xn and equally true here, and the extra AMF hop does not create a new suspect -- it only makes people think it might have.
Vendor interoperability rides on this. A target running a newer release can include RRC features the source has never heard of, and they reach the UE intact. The AMF is not even a version-compatibility consideration.
The container is the reason the two interfaces cost the same on the air. The RRCReconfiguration the UE receives is produced by the same target code in both cases, so t304, the CFRA resources and the reconfigurationWithSync contents are indistinguishable. Everything in companion 22 Handover Overview §5 applies unchanged.

📘

Spec detail

One genuine NG-specific wrinkle: the target-to-source container appears twice on N2, once in HANDOVER REQUEST ACKNOWLEDGE and once in HANDOVER COMMAND, and on an inter-AMF move it also crosses the SBI in the CreateUEContext response. Three copies, all of which must be identical. If your decoder shows you different byte lengths for the same container at two points in one procedure, an AMF is re-encoding something it should have copied.

8. HANDOVER COMMAND and Execution on the Air

HANDOVER COMMAND is the AMF's successful outcome to the Handover Preparation procedure. It ends preparation, stops TNGRELOCprep, and gives the source everything it needs for the next few milliseconds: the container to relay, and the forwarding endpoint per session to transmit into. TS 38.413 cl. 8.4.1

IE	Presence	Content	What the source does with it
`HandoverType`	M	Echo of the request.	Sanity check only.
`NASSecurityParametersFromNGRAN`	O	A NAS container generated by the target AMF when the NAS security context changes.	Copies it into `masterKeyUpdate` → `nas-Container` in the `RRCReconfiguration` it relays (§12). It does not read it.
`PDUSessionResourceHandoverList`	M	Per admitted session: the `HandoverCommandTransfer` container with `dLForwardingUP-TNLInformation` -- the address and TEID the source must forward downlink data to -- and the QoS flows to be forwarded.	Opens a GTP-U tunnel per session and starts forwarding as soon as it has transmitted the RRC message.
`PDUSessionResourceToReleaseListHOCmd`	O	Sessions that will not survive the move, with causes.	Releases the corresponding DRBs in the relayed `RRCReconfiguration`. The UE loses them at the handover (§5.3).
`TargetToSource-TransparentContainer`	M	The target's `HandoverCommand` → `RRCReconfiguration`.	Extracts the innermost `RRCReconfiguration` and transmits it on SRB1, ciphered and integrity-protected with the source keys.

Table 11. Note the asymmetry with the forwarding endpoint in §6.1: the address the source is given here is the UPF's, not the target's, whenever forwarding is indirect. The source never learns the target's forwarding address at all.

Figure 7. Repeated from §3 for reference while reading this section. Rows 1, 6 and 7 are the only rows the UE participates in, and they are identical to Xn.

What happens next is described in full in companion 22 Handover Overview §5 and §6 and in companion 23 Xn Handover §10, and there is no point restating it: the source transmits the RRCReconfiguration on SRB1, the UE starts T304, releases the source cell, retunes, acquires the target's SSB timing, performs contention-free random access with the ra-PreambleIndex it was given, and transmits RRCReconfigurationComplete on the target's SRB1 protected with the new keys. T304 stops. The whole of it takes 20 to 30 ms on FR1 and the interface that prepared it is irrelevant to every step.

💡

Key point

There is exactly one air-interface field that can differ between an Xn and an N2 handover, and it is masterKeyUpdate.

On Xn, keySetChangeIndicator is usually FALSE and the derivation is horizontal. On N2 the AMF always supplies a fresh {NH, NCC} pair, so the derivation at the target is always vertical -- and on an inter-AMF move with a changed K_AMF, keySetChangeIndicator is TRUE and a nas-Container is present. A nas-Container inside masterKeyUpdate is conclusive evidence of an inter-AMF N2 handover, and it is the only such evidence visible on the air (§12).

9. UPLINK and DOWNLINK RAN STATUS TRANSFER

Xn has one message for PDCP status handover: SN STATUS TRANSFER, source to target, class 2. N2 has two, because there is no direct path between the gNBs. The source sends UPLINK RAN STATUS TRANSFER to its AMF; the AMF -- or, inter-AMF, the pair of AMFs via Namf_Communication_N1N2MessageTransfer -- sends DOWNLINK RAN STATUS TRANSFER to the target. Both are class 2 and neither is acknowledged. TS 38.413 cl. 8.4.6, 8.4.7

The payload is the same information as Xn's, in a differently named container.

The RAN status transfer container

-- TS 38.413 cl. 9.3.1, abridged

RANStatusTransfer-TransparentContainer ::= SEQUENCE {
    dRBsSubjectToStatusTransferList  DRBsSubjectToStatusTransferList,
    iE-Extensions   ProtocolExtensionContainer { ... } OPTIONAL,
    ...
}

DRBsSubjectToStatusTransferItem ::= SEQUENCE {
    dRB-ID          DRB-ID,                   -- INTEGER (1..32)
    dRBStatusUL     DRBStatusUL,
    dRBStatusDL     DRBStatusDL,
    iE-Extensions   ProtocolExtensionContainer { ... } OPTIONAL,
    ...
}

DRBStatusUL18 ::= SEQUENCE {
    uL-COUNTValue                 COUNTValueForPDCP-SN18,
    receiveStatusOfUL-PDCP-SDUs   BIT STRING (SIZE(1..131072)) OPTIONAL,
    ...
}

COUNTValueForPDCP-SN18 ::= SEQUENCE {
    pDCP-SN18       INTEGER (0..262143),      -- 18-bit SN
    hFN-PDCP-SN18   INTEGER (0..16383),       -- 14-bit HFN
    ...
}

-- COUNT = HFN || SN, 32 bits total, in both SN-size variants.
-- The 12-bit variants (DRBStatusUL12 / COUNTValueForPDCP-SN12) are
-- structurally identical with INTEGER (0..4095) and (0..1048575).

Listing 2. Compare with the XnAP DRBsSubjectToStatusTransfer-List in companion 23 Xn Handover §11: the same fields, the same semantics, a different type name. A decoder written for one will not read the other, which is why status-transfer bugs are interface-specific even though the information is not.

Aspect	Xn SN STATUS TRANSFER	NG/N2 RAN STATUS TRANSFER	Practical consequence
Messages	One	Two, plus an SBI relay when inter-AMF	Two more places to lose it, and no acknowledgement on either.
Latency source→target	One Xn hop, ~1-2 ms	Two N2 hops plus AMF processing, ~9-12 ms	The target may start receiving forwarded PDUs before it knows what COUNT to expect. It buffers; it does not fail.
Ordering guarantee relative to forwarding	Both on paths the source controls; the source sends status first.	Status goes via the AMF, forwarding goes via the UPF. Two independent paths with independent latencies.	Order is not guaranteed. A target implementation that assumes status arrives before the first forwarded PDU is wrong on N2.
Which DRBs appear	RLC-AM bearers with SN continuity to preserve.	Identical rule.	RLC-UM bearers legitimately absent from both.
Failure if lost	Target starts DL numbering from 0 and discards duplicates it cannot recognise; some loss.	Identical.	TCP recovers; a voice bearer would not care. Not fatal, but measurable as a retransmission burst.

Table 12. The third row is the one that produces real bugs. On Xn, the source controls both the status message and the forwarded data and can order them; on N2 it controls neither path's latency.

🔍

What you see in logs

The AMF is a pure relay for this container and does not decode it. That has a pleasant consequence for debugging: the dRBStatusUL and dRBStatusDL values you see in UPLINK RAN STATUS TRANSFER at the source AMF are byte-identical to the ones in DOWNLINK RAN STATUS TRANSFER at the target. If they differ, the AMF re-encoded the container, and that is a core-network defect with a RAN-visible symptom.

10. Data Forwarding: Indirect by Default

On Xn, forwarding is direct: the source opens a GTP-U tunnel to the target over Xn-U and sends. On N2 that is usually impossible, and the reason is worth being precise about, because it is not simply "there is no Xn".

Direct forwarding requires a routable user-plane path between the two gNBs, and requires the source to know it exists. The Xn association provides both: it proves reachability and it carries the target's transport addresses. Without Xn, the source has neither piece of information -- it has never spoken to the target and does not know its transport address. The AMF could in principle tell it, and this is exactly what DirectForwardingPathAvailability is for; but the source must assert availability before the target is contacted, on the basis of local configuration alone. Most operators leave the assertion off, and so indirect forwarding is the default in practice as well as in the specification. TS 23.502 cl. 4.9.1.3.3

Mode	Path	Who allocates the endpoints	When it is chosen	Cost
Direct	source gNB → target gNB, one GTP-U tunnel per session	The target, in HANDOVER REQUEST ACKNOWLEDGE; relayed to the source in HANDOVER COMMAND	Only when `DirectForwardingPathAvailability` = `directPathAvailable` and the SMF agrees	One transport crossing. Same as Xn.
Indirect	source gNB → UPF (or I-UPF) → target gNB, two GTP-U tunnels per session	The target allocates its side; the SMF/UPF allocate the endpoint the source uses, in the second `UpdateSMContext`	The default whenever direct is not asserted, and always across a UPF service-area boundary	Two transport crossings, one extra store-and-forward, ~2× the one-way delay plus UPF processing.
None	Nothing is forwarded; the target receives only new data on the new N3 tunnel	--	When `DataForwardingNotPossible` is set for the session, or the bearer is RLC-UM, or the operator disables it	Zero signalling, at the price of losing whatever was in flight. Correct for voice, wrong for TCP.

Table 13. The middle row is what you will see in almost every N2 trace. The third row is more common than people expect and is often a deliberate choice for GBR bearers.

Figure 8. The two forwarding lanes are offset by the UPF's one-way transit and processing time, not by anything the RAN controls. The bottom lane shows where the same PDUs would have been on Xn -- the gap between it and the hop-2 lane is the entire user-visible cost of indirect forwarding.

10.1 What the extra hop actually costs

Three separate costs, and only one of them is latency.

Cost	Magnitude for a 150 Mbit/s downlink session	Who pays	Observable as
Added delay to the first forwarded byte	One extra one-way transport hop plus UPF store-and-forward: commonly 6-10 ms	The user, once, at the handover	A slightly longer gap in the downlink stream than the air interruption alone would explain.
Buffer at the UPF	~800 kB per PDU session over a 44 ms forwarding window (§17.3), times the number of concurrent handovers	The operator, in UPF memory	Nothing, until the UPF is undersized -- then dropped forwarded PDUs and no error anywhere.
Transport capacity	Every forwarded byte crosses the transport network three times instead of twice	The operator, in backhaul	Handover-correlated bursts on the N3 links, which capacity planning based on user throughput will not have predicted.

Table 14. The second and third rows are why some operators disable forwarding entirely for high-throughput non-GBR sessions and let TCP recover instead. That is a defensible trade and it should be a deliberate one.

📘

Spec detail

The End Marker still works, and still matters. When the SMF switches the downlink path at the UPF (§11), the UPF sends a GTP-U End Marker -- message type 254, no payload -- on the old N3 tunnel to the source. The source forwards it down the indirect tunnel like any other PDU, and it arrives at the target two hops later as the last thing on that tunnel.

That is the target's signal to stop reordering and release everything it is holding. A missing End Marker does not lose data; it makes the target wait for its reordering timer instead, and the symptom is a burst of jitter tens of milliseconds after an otherwise clean handover. See companion 23 Xn Handover §12.3 for the same mechanism with one hop fewer.

11. Completion: HANDOVER NOTIFY, Path Update, Context Release

The completion phase on N2 does the same work as Xn's path switch, with one message fewer and one important structural difference: it is not the target that asks for the path to move, it is the target that reports arrival, and the AMF -- which has been coordinating throughout -- moves the path on its own initiative.

Figure 9. Repeated from §3. The two End Marker rows are the same PDU traversing the same two forwarding hops as the user data did, which is exactly why it works as an ordering marker.

Step	Message	Class	What breaks if it is lost or late
1	NGAP HANDOVER NOTIFY, target gNB → AMF	2	Everything downstream. There is no retransmission and no acknowledgement: the downlink path never moves, the source is never released, and `TNGRELOCoverall` eventually expires at a target that is actively serving the UE. This is the worst single-message loss in the procedure.
2	Nsmf_PDUSession_UpdateSMContext (handover complete), AMF → SMF	SBI	The downlink stays on the old N3 tunnel to the source, which forwards it -- so the user is served, over three hops, indefinitely. A handover that looks fine but whose downlink latency is 8 ms too high for minutes is this.
3	N4 modification and End Marker, SMF → UPF	PFCP	The target waits for its reordering timer instead of the marker; post-handover jitter (§10).
4	Namf_Communication_N2InfoNotify, target AMF → source AMF	SBI	Inter-AMF only. The source AMF never learns the handover finished, so step 5 never happens.
5	NGAP UE CONTEXT RELEASE COMMAND, source AMF → source gNB	1	The source holds the UE context, the C-RNTI, the forwarding tunnel and the forwarding buffer. At scale this is a resource leak with a handover-rate-proportional size.
6	NGAP UE CONTEXT RELEASE COMPLETE, source gNB → source AMF	1	The AMF retries or times out; the source has already freed everything, so the practical impact is a counter, not an outage.

Table 15. Step 1 is a class 2 message on which the entire completion phase depends. That is the single largest robustness difference between N2 completion and Xn's acknowledged PATH SWITCH REQUEST.

Note the release ordering. The AMF does not send UE CONTEXT RELEASE COMMAND the instant it receives HANDOVER NOTIFY; it waits, either for the path update to complete or for a configured guard interval, so that the source has time to forward the last in-flight downlink data and the End Marker. Releasing the source early throws away exactly the data the forwarding tunnels exist to preserve.

🔍

What you see in logs

Cause = radioNetwork: successful-handover in UE CONTEXT RELEASE COMMAND is the source gNB's only positive confirmation that the handover worked. It has no other channel to the target.

Two consequences. First, the source-side handover success counter is incremented on a message that arrives two nodes and one SBI notification after the UE actually succeeded -- so source-side success latency is not handover latency. Second, if that cause value is anything else, the release is not a success: handover-cancelled, partial-handover and ho-failure-in-target-5GC-ngran-node-or-target-system all appear here and all mean something different happened.

12. Security Across an Inter-AMF Handover

The AS key handling in an N2 handover is simpler than Xn's in one respect and more complicated in another. Simpler, because the AMF always supplies a fresh {NH, NCC} pair and the target therefore always performs a vertical derivation -- there is no horizontal AS key derivation on N2 at all. More complicated, because on an inter-AMF move the NAS key can change too, and the UE has to be told. TS 33.501 cl. 6.9.2.3

Step	Who	Operation	Result
1	Source AMF	Retrieves the stored `{NH, NCC}` pair, or computes the next one from `K_AMF` and the current `NH`.	A fresh NH the target has never seen.
2	Source AMF (inter-AMF, if policy requires)	Horizontal `K_AMF` derivation: `K_AMF'` = KDF(`K_AMF`, uplink NAS COUNT, ...), sent with `keyAmfHDerivationInd` = true.	The target AMF never holds the source AMF's `K_AMF`. Backward security at the AMF boundary.
3	Target AMF	Uses `K_AMF` or `K_AMF'` to derive the `{NH, NCC}` sent in HANDOVER REQUEST, and -- when the key changed -- builds a NAS container with the new `ngKSI`, the NAS algorithms and the NAS COUNT.	`SecurityContext` IE in HANDOVER REQUEST; `NASC` IE alongside it.
4	Target gNB	`K_gNB` = KDF(`NH`, target PCI, target downlink ARFCN). Always vertical.	New AS keys, cryptographically separated from the source's.
5	Target gNB	Sets `keySetChangeIndicator` and copies `nextHopChainingCount` into `masterKeyUpdate`; includes the NAS container as `nas-Container` if the AMF supplied one.	The `RRCReconfiguration` inside the target-to-source container.
6	UE	Reads `masterKeyUpdate`. If `keySetChangeIndicator` is TRUE it derives `K_gNB` from the new `K_AMF` after processing the `nas-Container`; if FALSE it uses the `NH` chain implied by `nextHopChainingCount`.	The UE reaches the same `K_gNB` the target did, or the handover fails at the first integrity check.

Table 16. Step 2 is optional and operator-policy-driven. Steps 1, 3, 4, 5 and 6 happen on every N2 handover. Companion 27 AS Security Mode covers the key hierarchy and the derivation functions themselves.

The field to look at, on the air, is masterKeyUpdate in the RRCReconfiguration.

RRC MasterKeyUpdate, and how to read it

-- TS 38.331, abridged

MasterKeyUpdate ::= SEQUENCE {
    keySetChangeIndicator     BOOLEAN,
    nextHopChainingCount      NextHopChainingCount,   -- INTEGER (0..7)
    nas-Container             OCTET STRING            OPTIONAL,
                              -- Need N; carries the NAS security
                              -- parameters when the NAS context changed
    ...
}

-- keySetChangeIndicator = TRUE   -> derive K_gNB from the (new) K_AMF
-- keySetChangeIndicator = FALSE  -> derive K_gNB from NH / NCC chain
--
-- On Xn:   almost always FALSE.
-- On N2 intra-AMF:  FALSE, but the NCC always advances (vertical).
-- On N2 inter-AMF with horizontal K_AMF derivation:  TRUE, and
--                   nas-Container present.

Listing 3. A nas-Container inside masterKeyUpdate is conclusive: this is an inter-AMF N2 handover with a NAS security context change. It is the only interface-revealing field on the entire air interface.

⚠️

Common pitfall

The nas-Container is generated by the target AMF, relayed by the target gNB inside a container, relayed again by the source gNB, and consumed by the UE's NAS layer. Four nodes handle it and only two ends can read it.

The classic failure is a source gNB that receives NASSecurityParametersFromNGRAN in HANDOVER COMMAND and does not know what to do with it -- so it relays the target's RRCReconfiguration correctly, with the nas-Container the target already embedded, and everything works. The genuinely broken variant is a target that ignores the NASC IE in HANDOVER REQUEST. Then the UE never gets the new NAS parameters, derives the wrong K_gNB, and RRCReconfigurationComplete fails its integrity check at the target. The log signature is a successful PRACH followed by a MAC-I failure on SRB1 -- see companion 27 AS Security Mode.

13. Inter-PLMN and Roaming

An inter-PLMN handover is an N2 handover by necessity: there is no Xn between operators, and the UE's core-network context has to move between two administrative domains. Everything in §5 and §12 applies, with additional constraints.

Constraint	Mechanism	Where it is enforced	Failure signature
The target PLMN must be permitted for this subscriber	`MobilityRestrictionList`: serving PLMN, equivalent PLMNs, forbidden areas, RAT restrictions	Source AMF, before it even selects a target AMF	HANDOVER PREPARATION FAILURE, `Cause = radioNetwork: ho-target-not-allowed`. The target is never contacted.
The slices the UE uses must exist in the target PLMN	`AllowedNSSAI` computed for the target PLMN, with S-NSSAI mapping between the home and serving PLMN values	Target AMF, when it builds HANDOVER REQUEST	Sessions missing from HANDOVER REQUEST, or `Cause = radioNetwork: slice-not-supported` per session at the target.
The SBI traffic must cross the operator boundary safely	SEPP at each end; N32 between them	Outside the RAN entirely	SBI timeout at the source AMF, then `TNGRELOCprep` expiry and HANDOVER CANCEL (§16). Indistinguishable from an unreachable target AMF.
The user plane must reach a UPF that can serve the session	Home-routed sessions keep the PSA in the home PLMN; local-breakout sessions need a new PSA and often a new SMF	SMF, in the first `UpdateSMContext`	PDU sessions refused at the SMF, appearing in `PDUSessionResourceToReleaseListHOCmd`.

Table 17. The first row is the only one that fails cleanly and early. The other three fail late, partially, or with a cause that points at the wrong node.

Two practical notes. First, latency budgets do not survive contact with an inter-operator boundary: N32 round trips through two SEPPs are not engineered to the few-millisecond targets of an intra-operator SBI mesh, and TNGRELOCprep values that are comfortable intra-PLMN are marginal across one. Second, mobilityRestrictionList is carried in HANDOVER REQUEST to the target as well, so the target enforces the same restrictions on any subsequent handover -- a UE that reached a forbidden area through a chain of handovers is a bug in whichever node dropped the restriction list, and the list is worth checking at every hop.

⚠️

Common pitfall

Inter-PLMN handover is rare in most networks and correspondingly poorly tested. If you are seeing them at all, check first whether they are intentional: a border cell whose neighbour list includes a competitor's cell, or a shared-RAN deployment where two PLMN IDs are broadcast from the same gNB, both generate inter-PLMN preparations that nobody planned for.

14. Timers: TNGRELOCprep, TNGRELOCoverall and T304

Three timers supervise an N2 handover, on three different nodes, and none of them can see either of the others. Understanding which one expired tells you which node gave up, and that is usually the whole diagnosis.

Timer	Runs at	Started by	Stopped by	Typical value	On expiry
`TNGRELOCprep`	Source NG-RAN node	Transmission of HANDOVER REQUIRED	Receipt of HANDOVER COMMAND or HANDOVER PREPARATION FAILURE	Vendor-configurable; commonly a few hundred ms, and it must exceed the worst-case AMF-plus-SMF-plus-target round trip of §17.1	The source sends HANDOVER CANCEL with `Cause = radioNetwork: tngrelocprep-expiry` and keeps serving the UE. Costs nothing but a lost opportunity.
`TNGRELOCoverall`	Target NG-RAN node	Receipt of HANDOVER REQUEST	Receipt of `RRCReconfigurationComplete` from the UE	Vendor-configurable; commonly 1-10 s, and it must exceed the preparation tail plus T304	The target releases the prepared context and sends UE CONTEXT RELEASE REQUEST with `Cause = radioNetwork: tngrelocoverall-expiry`. The reserved CFRA preamble and DU context are freed.
`t304`	UE	Reception of `reconfigurationWithSync`	Successful completion of random access and transmission of `RRCReconfigurationComplete`	`ms50` to `ms10000`; `ms100` or `ms150` is common on FR1	Handover failure. The UE reverts to the source configuration and starts RRC re-establishment. See companion 22 Handover Overview §6 and 16 RLM and RLF.

Table 18. Only t304 is specified in 3GPP with a value range, because only t304 is signalled to another node. The two NGAP timers are purely local and 3GPP defines their function, not their duration TS 38.413.

The relationship between them is a strict nesting, and getting it wrong produces distinctive failures.

TNGRELOCprep must be longer than the full preparation round trip in §17.1 -- including the SMF and, inter-AMF, the second AMF. A value tuned for Xn's 9 ms preparation will cancel every N2 handover it ever attempts, and the log will show HANDOVER CANCEL arriving at an AMF that was still working.
TNGRELOCoverall must be longer than the remaining preparation tail (HANDOVER REQUEST ACKNOWLEDGE onward, roughly 20 ms) plus t304 plus the UE's processing. It is generously sized in practice precisely because the target cannot see how long the rest of the preparation took.
t304 is unchanged from the Xn case and should be: it covers only the air-interface part, which is identical. A vendor that lengthens t304 for N2 handovers has misunderstood where the extra time goes.
The dangerous configuration is TNGRELOCoverall shorter than the preparation tail plus t304. Then the target releases the UE context while the UE is performing random access into it, and the symptom is a CFRA preamble that gets no RAR, a T304 expiry, and a re-establishment -- with nothing in any log to say the target had already given up.

⚠️

Common pitfall

The nesting relationship is the same as Xn's TRELOCprep / TXnRELOCoverall / t304 triple in companion 23 Xn Handover §14, but the middle value has to absorb a much longer and much more variable preparation. If you inherit TNGRELOCoverall from an Xn configuration without changing it, the first slow SMF will produce the release-during-random-access failure above.

15. Xn against NG/N2, Side by Side

This is the table the rest of the document exists to justify. Every row is a decision a network designer makes once and a log reader lives with forever.

Dimension	Xn handover	NG/N2 handover	Why the difference exists
Coordination	Direct, gNB to gNB over one SCTP association.	Mediated by one or two AMFs, with an SBI leg to each SMF.	No Xn association exists, or the core context has to move.
Precondition	Xn Setup completed, target cell in the peer's served-cell list, same AMF set.	An N2 association to an AMF that can reach the target's TAI. That is all.	N2 is the universal fallback precisely because it assumes nothing about gNB-to-gNB connectivity.
RAN-visible messages	4 XnAP (HANDOVER REQUEST, ACKNOWLEDGE, SN STATUS TRANSFER, UE CONTEXT RELEASE) + 2 NGAP (PATH SWITCH REQUEST / ACKNOWLEDGE) = 6	9 NGAP (HANDOVER REQUIRED, REQUEST, REQUEST ACKNOWLEDGE, COMMAND, UL and DL RAN STATUS TRANSFER, NOTIFY, UE CONTEXT RELEASE COMMAND and COMPLETE) = 9	Every gNB-to-gNB message becomes two AMF-relayed messages.
Invisible messages	None beyond the path switch.	2-4 SBI operations, plus 2-6 PFCP exchanges on N4.	The core is doing work Xn does not require of it.
Nodes that must respond	2	4 to 6	Each is an independent failure and latency source.
Preparation latency	~9 ms (§17.1)	~52 ms intra-AMF, ~62 ms inter-AMF (§17.1)	Six to seven serial transport crossings instead of two.
Air interruption	~26 ms	~26 ms -- identical	The `RRCReconfiguration` is authored by the same target code and the UE behaves identically.
Forwarding mode	Direct over Xn-U, one hop.	Indirect through the UPF, two hops, unless the source explicitly asserts a direct path.	The source does not know the target's transport address without Xn.
Status transfer	One XnAP message, source to target.	Two NGAP messages via the AMF, plus an SBI relay when inter-AMF.	There is no direct control-plane path between the gNBs.
Path update	Target-initiated PATH SWITCH REQUEST, acknowledged.	Target-initiated HANDOVER NOTIFY, not acknowledged (class 2).	The AMF was already coordinating, so no new procedure is needed -- at the cost of losing the acknowledgement.
AS key derivation	Horizontal from `K_gNB`, or vertical if the source has an unused NH.	Always vertical: the AMF supplies a fresh `{NH, NCC}`.	The AMF is in the loop and has the key material.
NAS impact	None.	Possible `K_AMF` change and a `nas-Container` to the UE on an inter-AMF move.	The UE's NAS anchor moved.
Failure surface	Target admission, `TRELOCprep`, `TXnRELOCoverall`, T304.	All of those, plus AMF target resolution, inter-AMF SBI, SMF session feasibility, forwarding tunnel setup, and a lost class 2 NOTIFY.	More nodes, more interfaces, more timers.
Source's success signal	XnAP UE CONTEXT RELEASE from the target, one hop.	NGAP UE CONTEXT RELEASE COMMAND from the AMF, after the path update and an inter-AMF notification.	The source has no direct channel to the target.

Table 19. The row worth arguing about is air interruption. It is identical, and that surprises people who expect an N2 handover to feel worse to the user. What is worse is everything around it: preparation, forwarding delay, resource hold time and robustness.

Figure 10. The same comparison in milliseconds. The second group of bars is the one the user experiences and it is flat; the first and fourth are the ones the network pays for.

💡

Key point

Two design consequences follow from the table, and they pull in opposite directions.

Deploy Xn wherever you can: the preparation latency and the failure surface are both several times smaller, and MRO over Xn works better because both gNBs can see the outcome. But do not treat an N2 handover as a defect. Inter-AMF and inter-PLMN mobility have no Xn equivalent, and a network with zero N2 handovers is a network whose AMF set boundaries nobody ever crosses -- which is either excellent planning or a mobility hole.

16. The NG/N2 Failure Taxonomy

Figure 11. Four alternatives from one starting point. The vertical position of the failure in each branch tells you how much work was wasted and, more usefully, whether the UE had been told anything yet.

Failure	Detected by	Message and cause	UE impact	What it points at
Target resolution failure	Source AMF, immediately	HANDOVER PREPARATION FAILURE, `Cause = radioNetwork: unknown-targetID`	None. The UE never knows.	A stale neighbour relation on the source, or a TAI the AMF set does not cover. Check the `selectedTAI`, not the cell.
Handover not allowed	Source AMF	HANDOVER PREPARATION FAILURE, `Cause = radioNetwork: ho-target-not-allowed`	None.	`MobilityRestrictionList`: forbidden area, non-equivalent PLMN, or a RAT restriction (§13).
Inter-AMF context transfer failure	Source AMF	HANDOVER PREPARATION FAILURE with a generic cause, or nothing at all and then `TNGRELOCprep` expiry	None.	NRF discovery, the target AMF, or the SBI transport between them. Invisible from the RAN -- you need the AMF log (§5.2).
SMF refuses a session	SMF, per PDU session	Not a failure. The session appears in `PDUSessionResourceToReleaseListHOCmd` in HANDOVER COMMAND.	A bearer disappears at the handover. No RRC failure, no counter.	UPF service area, slice availability in the target area, or a home-routed session that cannot follow (§5.3, §13).
Target admission rejection, whole handover	Target gNB	HANDOVER FAILURE → AMF → HANDOVER PREPARATION FAILURE → source. `Cause = radioNetwork: no-radio-resources-available-in-target-cell`	None.	Target load. Compare against target-cell PRB utilisation at that timestamp; if there is none, look for an admission-control policy misconfiguration.
Target admission rejection, per session	Target gNB	HANDOVER REQUEST ACKNOWLEDGE with a non-empty `PDUSessionResourceFailedToSetupListHOAck`	The handover succeeds with fewer bearers.	`slice-not-supported`, `not-supported-5QI-value`, or `up-integrity-protection-not-possible` -- each names a specific target capability gap (§6.1).
Container rejected	Target gNB's NGAP layer	HANDOVER FAILURE, `Cause = protocol: abstract-syntax-error-reject`, often with populated `CriticalityDiagnostics`	None.	A source encoding defect, or an unrecognised extension the target should have skipped. The AMF cannot have caused it -- it copied bytes (§7).
Forwarding tunnel setup failure	SMF or UPF	Usually none. The forwarding endpoint is simply absent from HANDOVER COMMAND.	The handover succeeds and in-flight downlink data is lost.	N4 session modification failure, or UPF resource exhaustion. The symptom is a TCP retransmission burst with no signalling evidence (§10).
`TNGRELOCprep` expiry	Source gNB	The source sends HANDOVER CANCEL, `Cause = radioNetwork: tngrelocprep-expiry`; the AMF replies HANDOVER CANCEL ACKNOWLEDGE	None. The UE stays on the source.	Either the timer is tuned for Xn (§14) or something downstream is genuinely slow. Compare the value against §17.1 before blaming the core.
`TNGRELOCoverall` expiry	Target gNB	UE CONTEXT RELEASE REQUEST, `Cause = radioNetwork: tngrelocoverall-expiry`	Depends. If it fires before the UE arrives, the UE's random access gets no response and T304 expires.	Either the UE never came (a radio problem, or the command was lost) or the timer is too short for N2's preparation tail (§14).
T304 expiry at the UE	UE	No NGAP message. The UE reverts and starts re-establishment; the target eventually times out.	Service interruption of hundreds of milliseconds.	A too-late handover, a wrong target, or a target that was not actually ready. Identical to the Xn case -- see companion 22 Handover Overview §8 for the MRO classification.
HANDOVER NOTIFY lost	Nobody, initially	None -- it is class 2.	The UE is served over the old, three-hop path until `TNGRELOCoverall` releases it.	SCTP or AMF-side loss. The signature is a handover with normal uplink and abnormally high downlink latency, followed by an unexplained release (§2.1, §11).

Table 20. Read the fourth column first. Six of these twelve cost the user nothing at all, three cost a bearer or some in-flight data silently, and three cost a real interruption. The silent three are the ones no dashboard will show you.

16.1 The cancel path

HANDOVER CANCEL is the source's way of withdrawing a preparation it has already started, and unlike everything else in this section it is not a failure -- it is a normal, healthy part of a mobile network. TS 38.413 cl. 8.4.5

Trigger	Timing	Cause value	What the AMF must unwind
`TNGRELOCprep` expiry	During preparation	`radioNetwork: tngrelocprep-expiry`	Any target AMF context, any SMF session updates, any forwarding tunnels, and the target gNB's reservation via UE CONTEXT RELEASE.
Radio conditions reversed	After HANDOVER COMMAND but before the source transmits the RRC message	`radioNetwork: handover-cancelled` or `radio-connection-with-ue-lost`	The same, plus the target's prepared context including its CFRA reservation.
A better candidate appeared	During preparation	`radioNetwork: handover-cancelled`	The same. The source then starts a fresh preparation toward the new candidate.
The UE was lost	Any time before the RRC message is transmitted	`radioNetwork: radio-connection-with-ue-lost`	The same, and the source then releases the UE entirely.

Table 21. The AMF always answers HANDOVER CANCEL ACKNOWLEDGE and the procedure cannot fail. The interesting question is not whether the cancel worked but whether the target actually released what it had reserved.

⚠️

Common pitfall

A cancelled N2 preparation leaves debris in more places than a cancelled Xn preparation: a target AMF context, one SMF context per PDU session, possibly UPF forwarding rules, and the target gNB's CFRA reservation and DU context.

If any of those leaks, the observable symptom is not an error but a slow drift: a target cell that exhausts its CFRA preamble pool after hours of operation, or an SMF whose session count exceeds its UE count. Count HANDOVER CANCEL against UE CONTEXT RELEASE at the target; they should match one for one.

17. Worked Arithmetic

Three calculations. All use the same illustrative network: FR1 at 30 kHz subcarrier spacing, 4 ms one-way transport on every N2 and GTP-U hop, an SBI round trip of 3 ms between co-located network functions, two PDU sessions, CFRA at the target. Substitute your own transport numbers -- the structure is what matters.

17.1 A preparation latency budget, hop by hop

💡

PREPARATION BUDGET

Xn, for reference (companion 23 Xn Handover §16.1): source decision and container build 2.0 ms, then HANDOVER REQUEST to ACKNOWLEDGE including the target's F1AP round trip 7.0 ms. Total Xn preparation = 9.0 ms.

NG/N2, intra-AMF, hop by hop: source decision and container build 2.0; N2 source gNB to AMF 4.0; AMF TAI resolution and context lookup 4.0; Nsmf_PDUSession_UpdateSMContext plus N4 for two sessions 12.0; N2 AMF to target gNB 4.0; target admission control plus F1AP UE CONTEXT SETUP 7.0; N2 target gNB to AMF 4.0; second Nsmf_PDUSession_UpdateSMContext for the forwarding tunnels 10.0; N2 AMF to source gNB 4.0; source extracts the container and builds the RRC message 1.0.

Total intra-AMF = 2.0 + 4.0 + 4.0 + 12.0 + 4.0 + 7.0 + 4.0 + 10.0 + 4.0 + 1.0 = 52.0 ms, which is 5.8 times the Xn figure.

NG/N2, inter-AMF adds four serial steps: NRF discovery of a target AMF +1.0; Namf_Communication_CreateUEContext request +3.0; target AMF context creation +3.0; CreateUEContext response +3.0.

Total inter-AMF = 52.0 + 10.0 = 62.0 ms, which is 6.9 times the Xn figure.

Reading the result. Every one of those hops is serial -- the only parallelism available anywhere in the budget is across PDU sessions within a single Nsmf invocation, which is why 12.0 ms covers two sessions rather than being doubled. And note the shape: 22 of the 52 ms are the two SMF round trips, more than all four N2 crossings put together. An operator trying to reduce N2 preparation latency should measure SMF and UPF response times before touching transport.

The practical consequence is a configuration one. TNGRELOCprep has to be longer than the worst case of that budget, not the typical case, and the worst case includes an SMF that is garbage-collecting and an NRF lookup that misses its cache. A value that comfortably covers 62 ms of median latency will still cancel a few per cent of handovers at the tail -- and every one of those cancellations is recorded as a source-side failure against a target that did nothing wrong (§14, §16).

17.2 An interruption budget including indirect forwarding

💡

INTERRUPTION BUDGET

The air interruption is unchanged from Xn, because nothing about it is different: RRC message decode and apply 6.0 ms; source release, retune and target SSB timing acquisition 5.0 ms; wait for the next PRACH occasion 2.5 ms average; CFRA preamble plus ra-ResponseWindow 8.5 ms; first uplink grant and RRCReconfigurationComplete 4.0 ms.

Air interruption = 6.0 + 5.0 + 2.5 + 8.5 + 4.0 = 26.0 ms, identical on Xn and on N2.

What differs is the forwarding path. Forwarding starts as soon as the source has transmitted the RRC message, at t = 2 ms. On Xn the first forwarded PDU reaches the target after one hop of 1.5 ms. On N2 it takes 4.0 ms to the UPF, 1.0 ms of UPF store-and-forward, and 4.0 ms to the target = 9.0 ms.

Both are shorter than the 26 ms interruption, so in both cases the data is already waiting at the target when the UE arrives and the user-visible outage is 26 ms either way.

The difference shows up in the tail. The last forwarded PDU is delivered at 26.0 + 1.5 = 27.5 ms on Xn and at 26.0 + 9.0 = 35.0 ms on N2 -- an extra 7.5 ms, or 29% of the interruption.

Reading the result. For a TCP flow at 150 Mbit/s with a 20 ms round-trip time, 7.5 ms of extra tail is well inside one RTT and will not trigger a retransmission. For a 1 ms URLLC budget it is catastrophic, which is one concrete reason URLLC deployments insist on Xn everywhere and treat an N2 handover as an outage.

17.3 The forwarding buffer at the UPF

💡

FORWARDING BUFFER AND THROUGHPUT

Question. How much must the UPF hold, and move, for one PDU session during one N2 handover at a sustained downlink rate R = 150 Mbit/s?

The forwarding window runs from the moment the source stops transmitting to the UE until the SMF has moved the downlink path: air interruption 26.0 ms, plus HANDOVER NOTIFY from target gNB to AMF 4.0 ms, plus AMF processing 2.0 ms, plus Nsmf_PDUSession_UpdateSMContext and the N4 path switch 12.0 ms. W = 44.0 ms.

Total forwarded volume = R × W = 150e6 × 0.044 = 6.6 Mbit = 825 000 bytes ≈ 806 KiB per PDU session.

Resident at the UPF is only what is in transit through it, which is one hop plus its own processing: 150e6 × (4.0 + 1.0) ms = 750 kbit ≈ 94 KiB.

At scale, for a UPF serving 200 N2 handovers per second: concurrent handovers = 200 × 0.044 = 8.8; steady-state forwarding buffer ≈ 8.8 × 94 KiB ≈ 0.8 MiB; steady-state forwarding throughput ≈ 8.8 × 150 Mbit/s ≈ 1.3 Gbit/s.

Reading the result. The buffer is trivial and nobody should size a UPF on it. The throughput is not: 1.3 Gbit/s of forwarded traffic crosses the UPF twice, once in and once out, purely because of mobility. On Xn that traffic never touches the core at all.

That last line is the one to take away. Sizing an indirect-forwarding deployment on buffer memory is the wrong instinct; the constraint is N3/N9 capacity and UPF packet-processing rate, and it scales with handover rate times per-UE throughput -- a product that grows much faster than either factor alone as networks get denser and faster.

18. 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 inter-AMF N2 handover, throughout. Source cell NR-CGI 001-01-0x0A1B2C001 (PCI 231, gNB-ID 0x0A1B2C), target cell NR-CGI 001-01-0x0C4E71005 (PCI 502, gNB-ID 0x0C4E71). Source C-RNTI 0x4C21, target C-RNTI 0x7B14. Two PDU sessions: 5 (5QI 9, DRB 1) and 6 (5QI 1, DRB 2) -- the same session layout as the Xn scenario in companion 23 Xn Handover §17, so the two can be read side by side.

18.1 NGAP HANDOVER REQUIRED

[NGAP] HANDOVER REQUIRED, source gNB -> source AMF

11:20:44.118  [NGAP-TX] assoc=AMF 192.0.2.101:38412  stream 3
                        HANDOVER REQUIRED
  initiatingMessage  procedureCode = 12 (handoverPreparation)
                     criticality = reject
  aMF-UE-NGAP-ID .................. 0x0000000031B7A0
  rAN-UE-NGAP-ID .................. 0x00003F91
  handoverType .................... intra5gs
  cause
    radioNetwork ................. handover-desirable-for-radio-reason
  targetID  targetRANNodeID
    globalRANNodeID  globalGNB-ID  plmn 001-01  gNB-ID 0x0C4E71 (24 bit)
    selectedTAI ................... plmn 001-01  tac 0x00A204
                                    -- outside this AMF's TAI list
  directForwardingPathAvailability  (absent)
                                    -- no direct path asserted; expect
                                    -- indirect forwarding (see 18.4)
  pDUSessionResourceListHORqd
    [0] pDUSessionID .............. 5
        handoverRequiredTransfer .. (4 bytes)
              directForwardingPathAvailability .. (absent)
    [1] pDUSessionID .............. 6
        handoverRequiredTransfer .. (4 bytes)
  sourceToTarget-TransparentContainer .. (OCTET STRING, 604 bytes)
    SourceNGRANNode-ToTargetNGRANNode-TransparentContainer
      rRCContainer ............... (531 bytes)
                                   -- HandoverPreparationInformation,
                                   -- opaque to NGAP (see 18.2)
      targetCell-ID  nr-CGI  plmn 001-01  nrCellIdentity 0x0C4E71005
      indexToRFSP ................ 6
      uEHistoryInformation
        [0] nr-CGI 0x0A1B2C001  pCI 231  timeUEStayedInCell 37 s
        [1] nr-CGI 0x0A1B2C003  pCI 233  timeUEStayedInCell 15 s

11:20:44.118  [RRM]  no Xn peer serves NR-CGI 0x0C4E71005 -> N2 chosen
11:20:44.118  [NGAP] TNGRELOCprep started

Listing 4. Two independent statements of the target cell: targetID (routing, TAI-based) and targetCell-ID inside the container (which cell the target should prepare). §4 explains why both are needed and what a mismatch costs.

18.2 NGAP HANDOVER REQUEST at the target

[NGAP] HANDOVER REQUEST, target AMF -> target gNB

-- Target-side view, on the target AMF's association. Note the new
-- AMF-UE-NGAP-ID and the new GUAMI: this is an inter-AMF handover.

11:20:44.147  [NGAP-RX] assoc=AMF 203.0.113.101:38412  stream 2
                        HANDOVER REQUEST   (29 ms after 18.1)
  initiatingMessage  procedureCode = 13 (handoverResourceAllocation)
  aMF-UE-NGAP-ID .................. 0x000000004C0921
                                    -- NOT the value in 18.1
  handoverType .................... intra5gs
  cause  radioNetwork ............. handover-desirable-for-radio-reason
  uEAggregateMaximumBitRate  dl = 1000000000  ul = 500000000   -- bit/s
  uESecurityCapabilities
    nRencryptionAlgorithms ........ 'NEA1,NEA2'   (bitmap 0110 0000 ...)
    nRintegrityProtectionAlgs ..... 'NIA1,NIA2'
  securityContext
    nextHopChainingCount .......... 3
    nextHopNH ..................... <256 bits>
                                    -- AMF-supplied; derivation at the
                                    -- target is VERTICAL, always
  pDUSessionResourceSetupListHOReq
    [0] pDUSessionID .............. 5
        s-NSSAI  sst = 0x01
        handoverRequestTransfer .. (PDUSessionResourceSetupRequestTransfer)
          uL-NGU-UP-TNLInformation  gtpTunnel 198.51.100.5 : TEID 0x0000B7C1
                                    -- the UPF endpoint for UPLINK data
          pDUSessionType ......... ipv4
          qosFlowSetupRequestList  { qfi 1  5QI 9  arp 8  non-GBR }
          dataForwardingNotPossible .. (absent)
    [1] pDUSessionID .............. 6
        s-NSSAI  sst = 0x01
        handoverRequestTransfer
          uL-NGU-UP-TNLInformation  gtpTunnel 198.51.100.5 : TEID 0x0000B7C2
          qosFlowSetupRequestList  { qfi 1  5QI 1  arp 2  GBR 38400/38400 }
          dataForwardingNotPossible .. true   -- voice: nothing to forward
  allowedNSSAI .................... { sst 0x01 }
  guami  plmn 001-01  aMFRegionID 0x0B  aMFSetID 0x004  aMFPointer 0x02
                                    -- source GUAMI was region 0x02
  nASC ............................ (OCTET STRING, 22 bytes)
                                    -- NAS security parameters; K_AMF
                                    -- changed at the AMF boundary (§12)
  mobilityRestrictionList  servingPLMN 001-01   (no forbidden TAs)
  sourceToTarget-TransparentContainer .. (604 bytes)
                                    -- byte-identical to 18.1

11:20:44.147  [NGAP] TNGRELOCoverall started
11:20:44.148  [F1AP-TX] to gNB-DU 0x03  UE CONTEXT SETUP REQUEST
11:20:44.152  [F1AP-RX] UE CONTEXT SETUP RESPONSE  c-RNTI 0x7B14
11:20:44.152  [DU-MAC] CFRA reserved: ra-PreambleIndex 58 (SSB 1)

Listing 5. Three fields identify this as inter-AMF: a different aMF-UE-NGAP-ID from 18.1, a guami with a different AMF Region ID, and the presence of nASC. The 29 ms gap between 18.1 and this message is the whole of §5, and nothing in either trace decomposes it.

18.3 NGAP HANDOVER REQUEST ACKNOWLEDGE

[NGAP] HANDOVER REQUEST ACKNOWLEDGE, target gNB -> target AMF

11:20:44.156  [NGAP-TX] assoc=AMF 203.0.113.101:38412  stream 2
                        HANDOVER REQUEST ACKNOWLEDGE   (elapsed 9.1 ms)
  successfulOutcome  procedureCode = 13 (handoverResourceAllocation)
  aMF-UE-NGAP-ID .................. 0x000000004C0921
  rAN-UE-NGAP-ID .................. 0x00011C08   -- the target's handle
  pDUSessionResourceAdmittedList
    [0] pDUSessionID .............. 5
        handoverRequestAcknowledgeTransfer
          dL-NGU-UP-TNLInformation   gtpTunnel 203.0.113.31 : TEID 0x0001D4A1
                                     -- for the UPF, after the path update
          dLForwardingUP-TNLInformation
                                     gtpTunnel 203.0.113.31 : TEID 0x00C10001
                                     -- for the FORWARDING tunnel; goes to
                                     -- the SMF, not to the source (§6.1)
          qosFlowSetupResponseList ... { qfi 1 }
          securityResult  integrityProtectionResult = not-performed
                          confidentialityProtectionResult = performed
    [1] pDUSessionID .............. 6
        handoverRequestAcknowledgeTransfer
          dL-NGU-UP-TNLInformation   gtpTunnel 203.0.113.31 : TEID 0x0001D4A2
          dLForwardingUP-TNLInformation .. (absent)
                                     -- dataForwardingNotPossible was set
          qosFlowSetupResponseList ... { qfi 1 }
  pDUSessionResourceFailedToSetupListHOAck .. (absent)  -- full admission
  targetToSource-TransparentContainer .. (OCTET STRING, 318 bytes)
    TargetNGRANNode-ToSourceNGRANNode-TransparentContainer
      rRCContainer ................ (312 bytes)
        HandoverCommand
          handoverCommandMessage ... (306 bytes)
            -- an RRCReconfiguration. NGAP does not decode this.
            -- Its masterKeyUpdate will carry nas-Container (from nASC),
            -- keySetChangeIndicator TRUE and nextHopChainingCount 3.
  criticalityDiagnostics .......... (absent)

Listing 6. Two GTP-U endpoints on the same node with different lifetimes: dL-NGU-UP-TNLInformation lives for the session, dLForwardingUP-TNLInformation for about 40 ms. Neither is the address the source will forward to -- that comes from the UPF (see 18.4).

18.4 NGAP HANDOVER COMMAND as the source receives it

[NGAP] HANDOVER COMMAND, source AMF -> source gNB

11:20:44.180  [NGAP-RX] assoc=AMF 192.0.2.101:38412  stream 3
                        HANDOVER COMMAND   (62 ms after 18.1)
  successfulOutcome  procedureCode = 12 (handoverPreparation)
  aMF-UE-NGAP-ID .................. 0x0000000031B7A0   -- source AMF's
  rAN-UE-NGAP-ID .................. 0x00003F91
  handoverType .................... intra5gs
  nASSecurityParametersFromNGRAN .. (22 bytes)
                                    -- relay into masterKeyUpdate; the
                                    -- source does not decode it
  pDUSessionResourceHandoverList
    [0] pDUSessionID .............. 5
        handoverCommandTransfer
          dLForwardingUP-TNLInformation
                       gtpTunnel 198.51.100.9 : TEID 0x00E20001
                       -- an I-UPF address, NOT 203.0.113.31 from 18.3.
                       -- Forwarding is indirect; this is hop 1 of 2.
          qosFlowToBeForwardedList .. { qfi 1 }
  pDUSessionResourceToReleaseListHOCmd .. (absent)
  targetToSource-TransparentContainer .. (318 bytes)
                                    -- byte-identical to 18.3

11:20:44.180  [NGAP] TNGRELOCprep stopped (62.1 ms elapsed)
11:20:44.181  [RRC-DL] SRB1  RRCReconfiguration  306 bytes
              -- ciphered with the SOURCE keys; contents authored by
              -- the target and never inspected here
                reconfigurationWithSync
                  physCellId ......... 502
                  newUE-Identity ..... 0x7B14
                  t304 ............... ms100
                  rach-ConfigDedicated cfra { ssb-Index 1, preamble 58 }
                masterKeyUpdate
                  keySetChangeIndicator .. TRUE     -- K_AMF changed
                  nextHopChainingCount ... 3        -- matches 18.2
                  nas-Container .......... (22 bytes)
11:20:44.181  [MAC] source cell released, C-RNTI 0x4C21 discarded
11:20:44.181  [GTP-U-TX] forwarding opened -> 198.51.100.9 TEID 0x00E20001

Listing 7. The single most informative line in an N2 trace: the forwarding address in HANDOVER COMMAND is a UPF address, not the target gNB address from 18.3. That one substitution is the whole of indirect forwarding, and keySetChangeIndicator = TRUE with a nas-Container is the whole of §12.

18.5 RAN status transfer and the two forwarding hops

[NGAP / GTP-U] status relay against two-hop forwarding

11:20:44.182  [NGAP-TX] UPLINK RAN STATUS TRANSFER   (class 2)
  initiatingMessage  procedureCode = 49 (uplinkRANStatusTransfer)
  aMF-UE-NGAP-ID .................. 0x0000000031B7A0
  rAN-UE-NGAP-ID .................. 0x00003F91
  rANStatusTransfer-TransparentContainer
    dRBsSubjectToStatusTransferList
      [0] dRB-ID .................. 1
          dRBStatusUL18
            uL-COUNTValue  pDCP-SN18 = 2044   hFN-PDCP-SN18 = 7
            receiveStatusOfUL-PDCP-SDUs .. '1011 1000 0000 0000'B
          dRBStatusDL18
            dL-COUNTValue  pDCP-SN18 = 6613   hFN-PDCP-SN18 = 7
      -- no entry for dRB-ID 2: RLC-UM voice, no SN continuity to keep

-- Target-side, on the other AMF's association:
11:20:44.193  [NGAP-RX] DOWNLINK RAN STATUS TRANSFER  (11 ms later)
  initiatingMessage  procedureCode = 7 (downlinkRANStatusTransfer)
  aMF-UE-NGAP-ID .................. 0x000000004C0921
  rAN-UE-NGAP-ID .................. 0x00011C08
  rANStatusTransfer-TransparentContainer .. byte-identical to the above

-- Meanwhile, on the forwarding path:
11:20:44.183  [GTP-U-TX] hop 1  192.0.2.11 -> 198.51.100.9  TEID 0x00E20001
              14 G-PDUs, ext hdr PDCP PDU Number, SNs 6599..6612
11:20:44.187  [GTP-U-RX] target: hop 2  198.51.100.9 -> 203.0.113.31
                                        TEID 0x00C10001, same 14 G-PDUs
              -- 4.2 ms later. The status transfer above has NOT yet
              -- arrived: forwarded data beat it by 6 ms (§9).
11:20:44.187  [PDCP-TGT] 14 SDUs buffered, no COUNT reference yet
11:20:44.193  [PDCP-TGT] COUNT reference applied, DL numbering from 6613

11:20:44.207  [DU-PHY] PRACH detected  preamble 58  SSB 1  TA est 34
11:20:44.209  [DU-MAC] RAR sent: TA command 34, UL grant 6 PRB
11:20:44.212  [RRC] RRCReconfigurationComplete  MAC-I verified
11:20:44.212  [NGAP] TNGRELOCoverall stopped; T304 stopped at the UE

Listing 8. The forwarded data arrives 6 ms before the status that describes it. That is normal on N2 and the target must buffer rather than discard -- the exact ordering hazard §9 warns about, and one that cannot occur on Xn.

18.6 Completion

[NGAP / GTP-U] HANDOVER NOTIFY, path update, context release

11:20:44.213  [NGAP-TX] HANDOVER NOTIFY   (class 2, no response expected)
  initiatingMessage  procedureCode = 11 (handoverNotification)
  aMF-UE-NGAP-ID .................. 0x000000004C0921
  rAN-UE-NGAP-ID .................. 0x00011C08
  userLocationInformation  userLocationInformationNR
    nR-CGI ........................ plmn 001-01  0x0C4E71005
    tAI ........................... plmn 001-01  tac 0x00A204
    timeStamp ..................... 2024-xx-xx 11:20:44 UTC

-- Core-network side, not visible in any RAN trace:
11:20:44.217  [SBI]  Nsmf_PDUSession_UpdateSMContext (handover complete)
11:20:44.228  [N4]   PFCP Session Modification: DL FAR -> 203.0.113.31
                                                        TEID 0x0001D4A1

11:20:44.231  [GTP-U-RX] source: old N3 198.51.100.5 -> 192.0.2.11
              msg type 254, End Marker, TEID 0x00007E30, length 0
11:20:44.232  [GTP-U-TX] source: End Marker forwarded, hop 1
11:20:44.236  [GTP-U-RX] target: End Marker, hop 2
11:20:44.236  [PDCP-TGT] forwarding complete; in-order delivery released

11:20:44.241  [NGAP-RX] source: UE CONTEXT RELEASE COMMAND
  initiatingMessage  procedureCode = 41 (uEContextRelease)
  uE-NGAP-IDs  uE-NGAP-ID-pair
    aMF-UE-NGAP-ID ................ 0x0000000031B7A0
    rAN-UE-NGAP-ID ................ 0x00003F91
  cause  radioNetwork ............. successful-handover
11:20:44.242  [NGAP-TX] source: UE CONTEXT RELEASE COMPLETE
  userLocationInformation ......... nR-CGI 0x0A1B2C001  (last known)
11:20:44.242  [GTP-U] forwarding tunnel 0x00E20001 torn down
11:20:44.242  [F1AP-TX] UE CONTEXT RELEASE COMMAND to source gNB-DU

-- Source-side elapsed: HANDOVER REQUIRED 11:20:44.118
--                     UE CONTEXT RELEASE COMPLETE 11:20:44.242
--                     = 124 ms of held context for a 26 ms interruption.

Listing 9. The closing arithmetic is the point. The UE was served by the target from 11:20:44.212; the source did not free its context until 30 ms later, and the forwarding tunnel stayed open for all of it. That hold time, not the interruption, is what scales badly with handover rate.

18.7 A failure case: preparation failure, then cancel

[NGAP] HANDOVER PREPARATION FAILURE, then TNGRELOCprep expiry

-- Same UE, a different attempt 40 seconds later toward a third cell.

11:21:24.703  [RRC-UL] MeasurementReport  measId 3  eventA3
                       servCell pCI 231 RSRP -103  |  pCI 610 RSRP -91
11:21:24.705  [NGAP-TX] HANDOVER REQUIRED
  targetID  targetRANNodeID
    globalGNB-ID  plmn 001-01  gNB-ID 0x0C4E90
    selectedTAI ................... plmn 001-01  tac 0x00A2FF
11:21:24.705  [NGAP] TNGRELOCprep started

11:21:24.712  [NGAP-RX] HANDOVER PREPARATION FAILURE   (7.1 ms)
  unsuccessfulOutcome  procedureCode = 12 (handoverPreparation)
  aMF-UE-NGAP-ID .................. 0x0000000031B7A0
  rAN-UE-NGAP-ID .................. 0x00003F91
  cause  radioNetwork ............. unknown-targetID
  criticalityDiagnostics .......... (absent)
11:21:24.712  [NGAP] TNGRELOCprep stopped
11:21:24.712  [RRM]  tac 0x00A2FF served by no AMF in the set
                     -- the target gNB was NEVER contacted
11:21:24.712  [RRM]  neighbour 0x0C4E90 suppressed for 30000 ms
11:21:24.712  [RRM]  next candidate: pCI 502 (NR-CGI 0x0C4E71005)

11:21:24.714  [NGAP-TX] HANDOVER REQUIRED  -> target 0x0C4E71005
11:21:24.714  [NGAP] TNGRELOCprep started

              ... no response ...

11:21:25.014  [NGAP] TNGRELOCprep EXPIRED after 300 ms
11:21:25.014  [NGAP-TX] HANDOVER CANCEL
  initiatingMessage  procedureCode = 10 (handoverCancel)
  aMF-UE-NGAP-ID .................. 0x0000000031B7A0
  rAN-UE-NGAP-ID .................. 0x00003F91
  cause  radioNetwork ............. tngrelocprep-expiry
11:21:25.019  [NGAP-RX] HANDOVER CANCEL ACKNOWLEDGE
  successfulOutcome  procedureCode = 10 (handoverCancel)
11:21:25.019  [RRC]  UE retained on the source cell; nothing transmitted

-- Neither attempt cost the user anything: the UE was never told to move.
-- But the second attempt held a target AMF context, two SMF contexts and
-- a CFRA reservation for 300 ms before anyone unwound them (§16.1).

Listing 10. Two of the branches in §16 in one sequence. The first is a clean, fast, correct rejection that names the real problem -- a TAI no AMF serves. The second is the expensive one: 300 ms of held resources across four nodes and no information about which of them was slow.

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

Release	Change on N2	Why it matters when reading a trace
Rel-15	NGAP handover preparation, resource allocation, notification, cancellation, uplink and downlink RAN status transfer, UE context release; direct and indirect forwarding; inter-AMF relocation via `Namf_Communication_CreateUEContext`.	The baseline. Everything in §3 exists here.
Rel-15	5GS-to-EPS and EPS-to-5GS handover over N26, using the same HANDOVER REQUIRED with a different `HandoverType`.	`fivegs-to-eps` in `HandoverType` sends the procedure somewhere completely different. `n26-interface-not-available` as a cause on a pure-NR handover means someone set this field wrong (§4).
Rel-16	Conditional handover over N2: the AMF can prepare multiple targets, and cancellation of prepared-but-unused candidates becomes routine. MRO extensions carry handover reports over NGAP.	One HANDOVER REQUIRED may produce several HANDOVER REQUESTs, and several HANDOVER CANCELs afterwards. A one-preparation-per-handover assumption breaks here. See companion 25 Conditional Handover and DAPS.
Rel-16	Secondary RAT usage reporting in HANDOVER REQUIRED and UE CONTEXT RELEASE COMPLETE; NR-U and IAB support; network slicing enhancements in `AllowedNSSAI` handling.	New optional IEs on messages you already know. Populated `CriticalityDiagnostics` on an otherwise successful handover is usually an older peer skipping one of these.
Rel-17	NTN mobility over N2 including feeder-link switch; inter-donor IAB migration; enhanced `UEHistoryInformation`; small-data-transmission context handling.	In an NTN deployment the target may be a moving cell and the `selectedTAI` may be time-dependent -- `unknown-targetID` failures there are often a clock problem, not a configuration problem.
Rel-18	Layer 1/Layer 2 triggered mobility (LTM) is defined for intra-CU cases and does not use N2 preparation per cell switch; further NTN and network-energy-saving mobility enhancements; RedCap-specific mobility handling.	LTM never appears on N2 at all, because it cannot cross a CU boundary. A deployment mixing LTM and N2 will show cell changes with no NGAP activity interleaved with full N2 handovers, and that is correct.

Table 22. Rel-16 is again the release that changes how you read a trace, for the same reason as on Xn: conditional handover breaks the assumption that one preparation means one handover.

🔄

Release delta

One N2-specific consequence of conditional handover deserves emphasis. Each prepared candidate holds a target gNB context, an SMF context per PDU session and possibly UPF forwarding rules -- all of the debris listed in §16.1, multiplied by the number of candidates. Conditional handover on Xn is comparatively cheap; on N2 it is not, and the number of simultaneously prepared candidates should be chosen with that in mind.

20. Reading NG/N2 Handover in Logs: A Checklist

Establish which interface prepared it, first. HANDOVER REQUIRED means N2; XnAP HANDOVER REQUEST means Xn. Nothing else tells you, and no field records the reason (§1). If the two cells share an Xn association and you are seeing N2 anyway, the neighbour relation on the source is misconfigured.
Classify intra- or inter-AMF from the GUAMI. Compare the GUAMI in HANDOVER REQUEST with the one the source's association was using. A different AMF Region ID or Set ID means an inter-AMF move, which changes the latency budget (§17.1), the security handling (§12) and the failure surface (§16).
Do not correlate on AMF-UE-NGAP-ID alone. It changes at the AMF boundary, as does RAN-UE-NGAP-ID. Correlate on the UE's air-interface identity or on the transparent container, or you will see two half-handovers (§2.1).
Time HANDOVER REQUIRED to HANDOVER REQUEST as one number, and know you cannot decompose it. Anything above about 40 ms intra-AMF or 60 ms inter-AMF is worth investigating, and the investigation has to start on the AMF, not the RAN (§5.2, §17.1).
Check DirectForwardingPathAvailability against the forwarding address you actually get. If the source asserted a direct path and HANDOVER COMMAND still returns a UPF address, the SMF overrode it -- fine. If the source did not assert one and the address is the target gNB's, something is wrong. And if the source asserted one that does not exist, forwarded data is being dropped silently (§4, §10).
Diff three PDU session lists, not two. HANDOVER REQUIRED, HANDOVER REQUEST, and the Admitted list. A session lost between the first two was refused by the core; between the last two, by the target. Different owners, different fixes, and no counter distinguishes them (§6.1).
Look for nas-Container inside masterKeyUpdate in the RRC. Its presence proves an inter-AMF handover with a NAS security context change. Its absence on a handover you have already classified as inter-AMF means the target ignored the NASC IE, and the next thing you will see is a MAC-I failure on the target's SRB1 (§12).
Confirm both halves of the status transfer, and do not assume ordering. UPLINK RAN STATUS TRANSFER at the source and DOWNLINK RAN STATUS TRANSFER at the target should carry byte-identical containers. Forwarded data arriving before the status is normal on N2 and a target must buffer, not discard (§9).
Count the forwarding hops. The address in HANDOVER COMMAND should be a UPF address and the address in HANDOVER REQUEST ACKNOWLEDGE should be the target's; two different addresses for the same session is indirect forwarding working correctly (§10, trace 18.4).
Follow the End Marker through both hops. Old N3 tunnel to the source, forwarding hop 1 to the UPF, hop 2 to the target. Missing at any stage means the target waits for its reordering timer, and the symptom is post-handover jitter rather than loss (§10, §11).
Treat a missing HANDOVER NOTIFY as the prime suspect for "handover worked, downlink is slow". It is class 2 and unacknowledged; if it is lost, the path never switches and the UE is served over three hops until TNGRELOCoverall releases it (§2.1, §11).
Measure source context hold time separately from interruption. HANDOVER REQUIRED to UE CONTEXT RELEASE COMPLETE is typically four to five times the interruption on N2 (trace 18.6). It is what pins forwarding buffers and C-RNTIs, and it is the number that scales badly with handover rate.
On failure, classify by whether the UE had been told. Everything before HANDOVER COMMAND is free: preparation failure, TNGRELOCprep expiry, cancel. Everything after costs a re-establishment. Group the free ones by cause and by target TAI -- unknown-targetID clusters by TAI, no-radio-resources-available-in-target-cell clusters by cell and time of day (§16).

21. Glossary

Term	Expansion	Meaning in this document
N2	--	The reference point between an NG-RAN node and the AMF. NGAP over SCTP, port 38412. The interface that gives this handover its name.
N3 / N4 / N9	--	GTP-U between gNB and UPF; PFCP between SMF and UPF; GTP-U between UPFs. N3 is the tunnel the handover moves; N4 is how the move is instructed.
NGAP	NG Application Protocol	TS 38.413. Class 1 procedures have a response and can fail explicitly; class 2 procedures have neither (§2.1).
`HandoverRequired`	--	The source gNB's request to the AMF. The N2 analogue of Xn's HANDOVER REQUEST, but addressed to the core rather than the target (§4).
`HandoverCommand`	--	Two distinct things with the same name: the NGAP message the AMF returns to the source, and the RRC message inside the target-to-source container. Context distinguishes them.
`HandoverNotify`	--	The target's class 2 report of arrival. Triggers the path update; unacknowledged (§11).
`TargetID`	--	Global RAN Node ID plus the selected TAI. The AMF routes on the TAI, not the cell (§4).
Transparent container	--	An NGAP OCTET STRING carrying an RRC message the far-end gNB authored. Neither NGAP nor the AMF decodes it (§7).
`GUAMI`	Globally Unique AMF Identifier	PLMN plus AMF Region ID, Set ID and Pointer. The fastest way to tell an inter-AMF handover from an intra-AMF one (§2.1).
`AMF-UE-NGAP-ID`	--	The AMF's handle for the UE on one N2 association. Changes at an inter-AMF handover.
Indirect forwarding	--	Downlink forwarding routed through the UPF because the source has no usable direct path to the target. Two GTP-U hops instead of one (§10).
I-UPF	Intermediate UPF	A UPF between the gNB and the PDU Session Anchor. Frequently the node that terminates the indirect forwarding tunnels, and may itself be inserted or relocated at the handover.
`NH` / `NCC`	Next Hop / Next hop Chaining Count	The key material the AMF supplies in `SecurityContext`. On N2 the target's derivation from NH is always vertical (§12).
`K_AMF'`	--	A horizontally derived `K_AMF`, produced by the source AMF so that the target AMF never holds the old key. Signalled with `keyAmfHDerivationInd` (§12).
`nas-Container`	--	NAS security parameters relayed to the UE inside `masterKeyUpdate`. Its presence proves an inter-AMF N2 handover (§12).
`TNGRELOCprep`	--	Source-side NGAP timer supervising handover preparation. Expiry causes HANDOVER CANCEL (§14).
`TNGRELOCoverall`	--	Target-side NGAP timer supervising the whole relocation. Expiry releases the prepared context (§14).
End Marker	--	A GTP-U PDU, message type 254, no payload, emitted by the UPF on the old tunnel at the path update. On N2 it traverses both forwarding hops (§10, §11).

22. References

3GPP TS 38.413 -- NG Application Protocol (NGAP). Clause 8.4 (UE mobility management procedures: 8.4.1 Handover Preparation, 8.4.2 Handover Resource Allocation, 8.4.3 Handover Notification, 8.4.4 Path Switch Request, 8.4.5 Handover Cancellation, 8.4.6 Uplink RAN Status Transfer, 8.4.7 Downlink RAN Status Transfer), clause 8.3 (UE context management including UE Context Release), clause 9.2 (message definitions), clause 9.3 (IE definitions including the transparent containers, Security Context and PDU session transfer containers), and the Timers clause for TNGRELOCprep and TNGRELOCoverall.
3GPP TS 23.502 -- Procedures for the 5G System. Clause 4.9.1.3 (N2-based handover: 4.9.1.3.1 preparation, 4.9.1.3.2 execution, and the inter-AMF and indirect-forwarding variants), clause 4.9.1.2 (the Xn case, for comparison), clause 4.23 (UPF selection and I-UPF insertion).
3GPP TS 23.501 -- System architecture for the 5G System. Clause 5.6 (session management and UPF roles), clause 6.3 (AMF and SMF selection), clause 5.15 (network slicing and AllowedNSSAI).
3GPP TS 38.300 -- NR overall description. Clause 9.2.3 (mobility in RRC_CONNECTED), clause 9.2.3.2 (inter-gNB handover, both Xn and NG-based, including data forwarding).
3GPP TS 38.401 -- NG-RAN architecture description. Clause 8.4 (inter-gNB handover with the CU/DU split made explicit for the NG-based case), clause 6.1 (functional split).
3GPP TS 38.331 -- RRC protocol specification. HandoverPreparationInformation and HandoverCommand (clause 6.2.2), RRCReconfiguration, CellGroupConfig, ReconfigurationWithSync, MasterKeyUpdate including nas-Container, RACH-ConfigDedicated, UE-TimersAndConstants.
3GPP TS 33.501 -- Security architecture and procedures for 5G System. Clause 6.9.2.3 (key handling in N2 handover), clause 6.9.3 (handling of K_AMF at AMF change, including horizontal derivation), Annex A (key derivation functions).
3GPP TS 38.323 -- PDCP specification. COUNT, HFN, reordering and duplicate discard -- the behaviour that makes forwarded data usable at the target, and discardTimer.
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 29.518 -- Namf services. Namf_Communication_CreateUEContext, Namf_Communication_N1N2MessageTransfer and Namf_Communication_N2InfoNotify as used in this procedure.
3GPP TS 29.502 -- Nsmf_PDUSession services. Nsmf_PDUSession_UpdateSMContext including the handover indications and the forwarding tunnel information.
3GPP TS 29.244 -- Packet Forwarding Control Protocol (PFCP). The N4 session modification that moves the downlink path and triggers the End Marker.
RFC 5737 -- IPv4 Address Blocks Reserved for Documentation. The source of every IP address in §18.

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.
23 Xn Handover -- the direct gNB-to-gNB case in the same depth. Every comparison in §7, §9, §10 and §15 refers to it, and the execution phase of §8 is documented there rather than repeated here.
25 Conditional Handover and DAPS -- multiple prepared targets and EARLY STATUS TRANSFER, and why both are more expensive over N2 than over Xn (§19).
27 AS Security Mode -- the key hierarchy, K_AMF, NH and NCC, and the vertical and horizontal derivations §12 depends on.
20 Measurements and Events -- the A3 report that starts every sequence in this document, and the thresholds that decide when.
21 Measurement Gaps and SMTC -- how the UE measured a target cell it has no Xn relation to in the first place.
03 Random Access -- the CFRA procedure at the target in §8 and §17.2, in detail.
16 RLM and RLF -- where a T304 expiry goes next, and the VarRLF-Report the UE stores on the way.
15 RRC Procedures -- re-establishment, the recovery path for every execution-phase failure in §16.
26 UE Capability -- what is inside the ue-CapabilityRAT-List that travels in the transparent container of §7.
01 Registration Process -- the AMF-side context that Namf_Communication_CreateUEContext moves in §5.2.