X2AP (X2 — EN-DC with eNB) in 5G NR

Introduction

X2 is the LTE-era interface between two E-UTRAN nodes, and X2AP (TS 36.423) is the control protocol that runs on it over SCTP. It was built so neighbouring eNBs could coordinate directly — handovers, load, interference — instead of routing everything through the core. Its second life came with 5G: when 3GPP defined the first commercial 5G deployment, EN-DC (E-UTRA–NR Dual Connectivity), it reused X2 to let an LTE master node attach a 5G node as a secondary leg.

You meet X2 in two distinct settings. In pure LTE it carries inter-eNB handover and load/interference management between 4G cells. In NSA 5G it carries the SgNB life-cycle — addition, modification, status transfer and release — that bolts an NR carrier onto an existing LTE connection. The same association, the same transport, the same paired-ID addressing serve both roles; EN-DC simply adds a family of procedures on top.

It matters because NSA was, and in many networks still is, how 5G actually got switched on: an operator with a live 4G EPC could add NR throughput without first deploying a 5G Core. Understanding X2AP is understanding how that "5G-on-top-of-4G" attach works — where the anchor stays, where the security keys come from, and where the user plane is terminated.

Why X2 Comes Back for 5G

Concretely, EN-DC had a hard constraint: at the time it was standardised, most operators had a mature 4G EPC and no 5G Core at all. So the control anchor had to stay on LTE, the core had to remain the EPC, and 5G could only be added as extra radio. That is exactly the shape X2 was already built for — a direct, RAN-to-RAN interface that adds and manages a second node without the core arbitrating every step. Reusing X2 meant the transport (SCTP), the node-setup handshake, the UE-associated addressing pattern and the data-forwarding tunnels all existed already; EN-DC only had to drop in a new set of SgNB procedures. Inventing a fresh interface would have delayed 5G launch for no functional gain.

What X2AP Is (and Why It Comes Back for 5G)

X2AP is the control-plane application protocol between two E-UTRAN nodes. It was designed for a flat LTE RAN where neighbouring eNBs need to coordinate directly instead of routing everything through the core: hand a UE from one cell to the next, exchange load and interference information, and set up the peering that makes those exchanges possible. When 3GPP defined EN-DC (E-UTRA–NR Dual Connectivity) for the first wave of 5G, it did not invent a new inter-node interface — it extended X2AP, because the anchor was still LTE and the core was still the EPC.

Everything in X2AP falls into two buckets. Non-UE-associated procedures configure the peering itself — which cells each node serves, what load each is carrying — and are run once or occasionally. UE-associated procedures act on a single UE's context and carry a pair of identifiers so both ends bind messages to the same subscriber. The base X2 role uses both buckets for LTE-to-LTE work; EN-DC adds a family of UE-associated SgNB procedures on top of the very same association.

The Base X2 Role: Handover and Load Management

Before any 5G existed, X2 already did two jobs, and both survive intact under NSA. Understanding them explains why X2 was the natural home for EN-DC.

Inter-eNB handover. When a UE moves between two eNBs that have an X2 association, the source hands the UE over directly rather than through the MME. The source sends HANDOVER REQUEST carrying the UE context and the target-cell information; the target admits the UE and replies with HANDOVER REQUEST ACKNOWLEDGE containing the prepared radio configuration. As the UE detaches, the source forwards buffered downlink data to the target over the user plane and passes uplink/downlink PDCP sequence-number state in SN STATUS TRANSFER. Once the UE arrives, the target triggers a Path Switch toward the MME/S-GW so the S1-U bearer is redirected, then the source context is cleared with UE CONTEXT RELEASE. This is the X2-based handover, distinct from the S1-based handover that routes through the core when no X2 exists.

Load and interference management. Neighbouring cells exchange RESOURCE STATUS REQUEST/RESPONSE/UPDATE to report radio and transport load, and LOAD INFORMATION to share interference-coordination indicators such as the Relative Narrowband Transmit Power (RNTP), High-Interference and Overload indicators used by ICIC. A MOBILITY SETTINGS CHANGE procedure lets two eNBs negotiate handover-trigger thresholds to balance load across a boundary. None of this touches the core — it is pure RAN-to-RAN coordination, which is exactly the design philosophy EN-DC inherits.

X2 Setup, Configuration Update and Transport

Before any UE can be dual-connected, the two nodes exchange global, non-UE-associated configuration. The MeNB sends X2 SETUP REQUEST carrying its served-cell information — PCIs, PLMNs, frequencies, neighbour relations; the peer replies with X2 SETUP RESPONSE listing its own served cells. For an en-gNB the response describes served NR cells. From then on both sides know each other's cells and can address UE contexts.

Configuration drifts, so X2AP provides update procedures. ENB CONFIGURATION UPDATE (and its acknowledge) pushes changes to an eNB's served-cell list after setup; for the EN-DC case the EN-DC CONFIGURATION UPDATE procedure lets the eNB and en-gNB refresh EN-DC-specific served-cell and TNL (transport) information without tearing the association down. If a node loses state, the RESET procedure clears UE contexts on the association cleanly, and ERROR INDICATION reports protocol problems.

All of this rides on a single SCTP association between the nodes (see SCTP). SCTP gives X2AP ordered, reliable, multi-streamed delivery: one stream typically carries the non-UE-associated signalling and others carry per-UE procedures, so head-of-line blocking between UEs is avoided. The standardised SCTP destination port for X2AP is 36422, and its SCTP Payload Protocol Identifier (PPID) is 27; per TS 33.501 the transport is protected with IPsec. The control plane is X2-C; the user plane that forwards data between the nodes is X2-U, a set of GTP-U tunnels over UDP, whose endpoints are named by a transport address and a 32-bit TEID. Every UE-associated message after setup carries an MeNB UE X2AP ID and, once the secondary node has allocated one, an SgNB UE X2AP ID; that pair is how two nodes keep dozens of dual-connected UEs unambiguous over one association.

Bearer Options and NSA Deployment Options 3/3a/3x

Dual connectivity is really about where a bearer's user plane lives. TS 37.340 defines three bearer termination options, and the deployment falls into the classic Option 3 family — both views describe the same thing: which node anchors PDCP and where S1-U terminates. Start with the deployment options, all controlled over the same X2-C.

Option 3 keeps the EPC's view simple — the S-GW only ever talks to the MeNB, and the master splits traffic downward — but it loads the LTE backhaul with all the NR user data. Option 3a routes distinct bearers to distinct nodes but cannot split a single bearer across both radios. Option 3x became the workhorse: the en-gNB terminates S1-U and anchors PDCP, so the high-rate NR path avoids the LTE backhaul, yet a single bearer can still be split, with the en-gNB forwarding a portion to the MeNB over X2-U for the LTE radio. The choice is per E-RAB and is signalled during SgNB addition and modification.

SgNB Addition — Adding the 5G Leg

This is the defining EN-DC procedure. The trigger is a measurement: the MeNB configures the UE with a B1 event (an inter-RAT neighbour becoming better than a threshold) pointed at the NR carrier. When the UE reports that a candidate NR cell is strong enough, the master decides to add it as a secondary node — this is the cross-link NSA attach, where an LTE-measured report reaches over to configure an NR leg.

MeNB → SgNB: SgNB ADDITION REQUEST. Key IEs:

SgNB → MeNB: SgNB ADDITION REQUEST ACKNOWLEDGE. The en-gNB runs admission control, reserves NR radio and transport, allocates an SgNB UE X2AP ID, and returns:

The MeNB embeds the SCG container inside an LTE RRCConnectionReconfiguration to the UE. The UE applies it, performs random access to the NR PSCell (the primary cell of the Secondary Cell Group), and confirms with RRCConnectionReconfigurationComplete. The master then sends SgNB RECONFIGURATION COMPLETE to the en-gNB, telling it the UE has successfully applied the SCG configuration and that the NR leg may go active. For SCG and split bearers the master finally runs an EPC E-RAB Modification so the S-GW steers downlink toward the correct endpoint. Data now flows over NR.

Bearer Types and X2-U Data Forwarding

Underneath those deployment options sit the three bearer types themselves — the PDCP anchor is what distinguishes them.

A split bearer runs a single PDCP entity feeding two RLC legs, so PDUs sent down the LTE and NR radios must be reordered at the receiver on their PDCP SN — this is exactly where PDCP reordering matters (see Radio Bearers). The plumbing that carries one node's share of those PDUs to the other node is X2-U: GTP-U tunnels identified by the TEIDs exchanged during addition. In Option 3x the en-gNB is the anchor and forwards the LTE portion to the MeNB over X2-U; in a MeNB-anchored split it is the reverse. The bearer option chosen for each E-RAB is signalled in SgNB ADDITION REQUEST and can be changed later with SgNB MODIFICATION — for instance promoting an SCG bearer to a split bearer when the LTE leg has spare capacity.

X2-U also carries data forwarding at life-cycle boundaries. When a bearer's anchor moves, in-flight PDCP SDUs that were buffered on the old side are tunnelled to the new side so nothing is lost and nothing is duplicated, coordinated with the sequence-number state described next.

Modification, Reconfiguration Complete, Status Transfer and Release

SgNB MODIFICATION. Either node can trigger it. The master-initiated SgNB MODIFICATION REQUEST (answered by SgNB MODIFICATION REQUEST ACKNOWLEDGE) or the SgNB-initiated SgNB MODIFICATION REQUIRED (answered by SgNB MODIFICATION CONFIRM) adds, modifies or removes E-RABs on the NR leg, changes a bearer's type (e.g. SCG → split), updates the SCG radio configuration, or refreshes security. As with addition, an RRCReconfiguration container is carried transparently to the UE and confirmed back with SgNB RECONFIGURATION COMPLETE.

SN STATUS TRANSFER. Whenever a bearer's PDCP anchor moves between the eNB and the en-gNB — on release, or on a bearer-type change of an acknowledged-mode bearer — the losing side sends SN STATUS TRANSFER carrying, per bearer, the uplink and downlink PDCP SN and HFN receiver/transmitter state. The new anchor resumes sequence numbering from exactly where the old one stopped, so reordering and duplicate detection keep working across the move.

SgNB RELEASE. Tears the NR leg down. SgNB RELEASE REQUEST (master-initiated) or SgNB RELEASE REQUIRED (SgNB-initiated) frees the secondary context. Where user data was buffered on the released side, SN STATUS TRANSFER plus X2-U data forwarding preserve in-flight PDCP SDUs while the master reverts the affected bearers to LTE, or moves them to a different en-gNB. A change of secondary node (SgNB change) is effectively an addition to the new node combined with a release of the old, stitched together by the master so the UE sees a single reconfiguration.

SgNB Addition — Message Sequence

The full addition exchange across UE, master eNB and secondary en-gNB is below. Note that the SCG RRCReconfiguration is built by the en-gNB but delivered to the UE inside an LTE RRC message by the master — the UE has only one RRC connection, and it is with the MeNB.

Summary

X2 is the LTE inter-node interface that got a second career as the backbone of NSA 5G. Keep the anchor rule front and centre: in EN-DC the master is always the LTE eNB, the UE stays RRC_CONNECTED on LTE with its S1-MME/EPC control plane, and NR is added only as a Secondary Cell Group over the same X2 association. The base X2 jobs — inter-eNB handover and load/interference management — still run; EN-DC layers the SgNB life-cycle on top.

The SgNB procedures are the ones to know: addition (triggered by a B1 measurement, carrying S-KgNB, the E-RAB list and the transparent SCG RRCReconfiguration the MeNB relays to the UE), modification (add/remove/retype E-RABs, refresh security), SN status transfer (hand over PDCP SN/HFN state when a PDCP anchor moves), and release. Cutting across all of them are two ideas: the paired MeNB UE X2AP ID / SgNB UE X2AP ID that keep UEs unambiguous, and the deployment options 3/3a/3x that decide where S1-U terminates and where PDCP is anchored — with 3x, the en-gNB-anchored split bearer, the practical workhorse. When you move to the 5G Core, the same shapes reappear on Xn; on the EPC you stay on X2.

X2 vs Xn, and Quick Q&A

The final thing to keep straight is which inter-node interface applies. X2/X2AP (TS 36.423) is the LTE interface, reused for EN-DC because the anchor is LTE and the core is the EPC. The NG-RAN world has its own interface, Xn (Xn-AP, TS 38.423), used between NG-RAN nodes connected to the 5G Core — that is where NR-NR Dual Connectivity and NGEN-DC live, and where the equivalent secondary-node procedures are named S-NODE ADDITION rather than SgNB ADDITION. Same idea, different interface, different core. If you are on the EPC, you are on X2; if you are on the 5GC, you are on Xn (see Xn Handover).