XnAP (Xn — gNB ↔ gNB) in 5G NR

Introduction

Xn is the horizontal interface of the 5G RAN: it runs between peer NG-RAN nodes rather than up toward the core. Where NG (N2/N3) connects a gNB to the 5G Core, Xn connects a gNB to its neighbours, and XnAP (TS 38.423) is the control protocol spoken across it, carried over SCTP over IP. A parallel user plane, Xn-U, carries forwarded data over GTP-U only while a handover is in flight.

You meet Xn throughout a connected UE's mobility and multi-connectivity life: when a UE moves from one gNB to another (Xn handover), when a suspended UE resumes under a different gNB (context retrieval), when an inactive UE must be paged across several cells (RAN paging), and when a second node is added to boost throughput (dual connectivity). In every case the intent is the same — keep the operation inside the RAN, where it is fast, and only involve the core at the very last step.

It matters because RAN-local mobility is what makes 5G handovers cheap and low-latency. Routing every handover decision up to the AMF and back would add core round-trips to a time-critical operation; Xn removes them. Understanding Xn is really understanding how neighbouring gNBs cooperate directly, and how the RAN keeps a UE's data flowing while it moves.

Why Xn is needed

Concretely, Xn earns its place by removing the core from operations that are inherently RAN-local. A handover decision comes from the UE's radio measurements, which only the RAN sees; the target's admission control and radio configuration are RAN state; and the in-flight packets that must be preserved during the handover gap live in the source gNB's PDCP buffers. Mediating all of that through the AMF over NG would add core signalling round-trips to a latency-sensitive procedure and load the core with events it does not need to arbitrate. Xn lets the two gNBs prepare the move, transfer PDCP state, and forward buffered data directly, so the core is touched exactly once — a single NG PATH SWITCH REQUEST at the end to redirect the downlink from the UPF.

What Xn Is

Two neighbouring NG-RAN nodes that expect to exchange UEs set up an Xn interface between them. Once it is up, they speak XnAP over SCTP for control, and forward user data over GTP-U when a handover is in flight. The whole point is locality: preparing a handover or pulling a stored context directly between neighbours is far cheaper in latency than routing every decision through the AMF over NG. Xn is the low-latency, RAN-internal shortcut that the core never has to see until the very end.

XnAP procedures split cleanly into two families, and the distinction runs through everything that follows. Non-UE-associated procedures manage the interface itself — they carry no subscriber identity and are about the relationship between two nodes. UE-associated procedures act on one specific UE's context, and each side references that UE with its own NG-RAN node UE XnAP ID — an INTEGER (0..232−1) handle. The initiator allocates its identifier first; the responder allocates a second and echoes both back, so from then on either node can point unambiguously at the same context. This is the identical addressing pattern used across NG-RAN control interfaces.

Xn-C and Xn-U: Two Planes on One Interface

Xn is not a single pipe. It carries a control plane and a user plane that use completely different transport stacks, and knowing which is which explains most of what the interface does. The control plane, Xn-C, carries all XnAP signalling and rides on SCTP over IP — the same reliable, message-oriented transport used on NG and F1. The user plane, Xn-U, carries only forwarded user data during mobility, tunnelled in GTP-U over UDP/IP. Crucially, Xn-U is not a steady-state data path; it exists to move in-flight packets from the source to the target for the brief window of a handover, then it is torn down.

Interface Management (Non-UE-Associated)

Before any UE can be handed over, the two nodes must agree on who each other is and which cells they serve. That is the job of the non-UE-associated procedures. They run once when the Xn link is first configured and then again whenever a node's served cells, tracking areas or slice support change. Everything downstream depends on each node holding an accurate picture of its neighbour — a stale served-cell list means handovers prepared toward cells that no longer exist.

Notice that XN SETUP can be initiated by either node — there is no fixed client and server, unlike the strictly gNB-initiated NG SETUP toward the AMF. Whichever node decides the link should exist sends the request; the other responds. After that the two are peers, and either can push a NG-RAN NODE CONFIGURATION UPDATE at any time. Each served cell is named by its NR CGI (the 36-bit NR Cell Identity under the PLMN), its physical-layer PCI, its TAC and its supported S-NSSAI list — exactly the fields a neighbour needs to decide whether, and how, to prepare a handover toward it.

Mobility: Handover and Data Forwarding

Mobility is what Xn is really for. When a source gNB decides, from the UE's measurement reports, that a neighbour cell is better, it prepares a handover directly over Xn-C and then forwards the UE's in-flight downlink data over Xn-U so nothing is lost in the gap. The four UE-associated procedures below make up the full flow.

Two things are worth stressing. First, the AMF is not involved in preparation at all — it learns of the move only when the target runs the NG PATH SWITCH REQUEST to redirect the downlink from the UPF, after which the source is released. Second, data forwarding is what makes an Xn handover feel seamless: the source keeps feeding the target the packets that were in flight during the handover interruption, so the UE's TCP flows do not stall or reset. The full step-by-step walk-through lives in Xn Handover.

Dual Connectivity and RRC Transfer

Xn also coordinates multi-connectivity, where a UE is served by two nodes at once. In NR-DC (and the broader MR-DC family) a master node (MN) keeps the control-plane anchor and recruits a secondary node (SN) to add radio resources — typically extra throughput on a second carrier. All of that recruitment happens over Xn with the S-Node procedures.

The role of RRC TRANSFER is easy to miss but essential: in MR-DC the UE has one RRC connection, anchored at the MN, yet the SN needs to configure and monitor its own cell group. Xn's RRC TRANSFER is the courier that shuttles the SN's RRC container to the UE via the MN and shuttles the UE's SCG responses back to the SN. Without it the secondary node would be blind to the radio conditions on its own carrier.

RRC-INACTIVE: RAN Paging and Context Retrieval

A UE in RRC_INACTIVE is suspended but not released: its AS context (security state, bearers, PDU sessions) stays stored in the last-serving gNB — the anchor — and the NG connection to the core is kept alive. Two XnAP procedures make this state work across a RAN Notification Area that spans several gNBs.

The first is RAN paging. When downlink data arrives for an inactive UE, the anchor must page it — but the UE may have moved to a cell served by a different gNB within the notification area. So the anchor sends XN-U ADDRESS INDICATION and issues the RAN PAGING procedure to its neighbours over Xn, and each neighbour transmits the paging message on its own air interface. This is distinct from core-network (CN) paging over NG: RAN paging stays inside the RAN and targets only the notification area.

The second is context retrieval. If the inactive UE decides to resume — or is reached by RAN paging — and does so at a gNB that is not its anchor, the new gNB has nothing stored locally. It uses the I-RNTI the UE presents in RRCResumeRequest to identify the anchor, then pulls the stored context over Xn with RETRIEVE UE CONTEXT REQUEST / RESPONSE. This avoids a full re-establishment through the core. The I-RNTI comes in two sizes — a full I-RNTI (40 bits) and a short I-RNTI (24 bits) — and it encodes both the anchor's identity and the UE's context reference there, which is exactly how the new gNB knows which neighbour to ask.

Key XnAP Procedures at a Glance

Summary

Xn is the RAN's horizontal interface — the direct link between two NG-RAN nodes that keeps mobility and multi-connectivity local to the RAN. Hold on to the two-plane split: Xn-C runs XnAP over SCTP for all control, and Xn-U carries GTP-U data forwarding only during the brief handover window. Everything XnAP does then sorts into two families — non-UE-associated procedures (XN SETUP, NG-RAN NODE CONFIGURATION UPDATE) that manage the link, and UE-associated procedures that act on one subscriber under a paired NG-RAN node UE XnAP ID.

The four things Xn is really for: handover (prepare the target, transfer PDCP COUNT state, forward in-flight data, release the source), context retrieval (pull a suspended UE's AS context from its anchor using the I-RNTI on RRC_INACTIVE resume), RAN paging (reach an inactive UE across the notification area), and dual connectivity (add and steer a secondary node, shuttling its RRC over RRC TRANSFER). In all of them the AMF is touched only at the end, in a single NG path switch — which is the whole reason Xn exists.

Quick Q&A