X2AP (X2 — eNB ↔ eNB) in LTE 4G

Introduction

X2AP is the application-layer signalling protocol that runs between two eNBs across the X2 interface of an LTE radio access network. It is the RAN's lateral nervous system: where S1AP reaches up from an eNB to the core (the MME), X2AP reaches sideways to a peer eNB, so neighbours can coordinate directly instead of round-tripping every decision through the Evolved Packet Core.

It matters at two moments in the UE lifecycle. The first is mobility: when a connected UE moves and its measurement reports say a neighbour cell is now better, the source eNB drives an X2 handover directly to the target — preparing the target, forwarding in-flight data, and only afterwards telling the core to switch the S1 path. The second is continuous coordination: even with no UE moving, neighbours constantly exchange interference and load information to shape spectrum use and balance traffic. X2AP is defined in TS 36.423; the general X2 architecture (planes, transport) is in TS 36.420.

Because X2 keeps mobility and coordination local, it is a large part of why LTE handovers feel seamless and why operators build dense X2 meshes between adjacent cells. The same design — a standing association, symmetric peers, and self-contained elementary procedures — was later reused to anchor 5G NR onto LTE in EN-DC, and carried forward as the Xn interface in standalone 5G.

Why X2AP is needed

Concretely, X2AP exists so that two things can happen without involving the core. First, fast handover: preparing a target cell, moving the UE context, and forwarding user data are all done peer-to-peer, so the only thing the EPC hears is a single S1 Path Switch Request after the move — the slow S1-handover path through the MME is the fallback when no X2 exists. Second, local coordination: interference and load between neighbours change on a timescale far too fast to arbitrate centrally, so eNBs exchange per-PRB interference and load information directly and adapt their own scheduling. Both jobs share one property — they are decisions best made between the two cells that are actually affected, which is exactly what a direct interface gives you.

What X2AP Is

X2 is the logical interface directly between two eNBs in an LTE radio access network. X2AP (X2 Application Protocol) is the signalling protocol that runs over it, carried reliably by SCTP over IP. Where S1AP connects an eNB up to the core (the MME), X2AP connects an eNB sideways to its neighbours — a peer-to-peer link that keeps mobility and coordination local and fast instead of round-tripping through the EPC for every decision.

An X2AP transaction is always an elementary procedure (EP). A class-1 procedure has an initiating message plus a response — either a successful outcome or an unsuccessful outcome (for example Handover Request → Handover Request Acknowledge or Handover Preparation Failure). A class-2 procedure (like Load Information) is fire-and-forget: an initiating message with no response at all. Everything on X2 is built from these two shapes, and the association is symmetric — either eNB may initiate any procedure, so there is no fixed client/server role.

Each X2AP message is an ASN.1 (aligned PER, per TS 36.423) structure built from Information Elements (IEs). Every IE is tagged with an IE criticality (reject, ignore, or notify) so a receiver that does not understand an IE knows whether to reject the whole message, silently ignore the IE, or process it but report back — the mechanism that lets the protocol evolve across releases without breaking older peers.

Interface Management — X2 Setup and Configuration Update

Before two eNBs can help each other, they must know each other. The X2 Setup Request / X2 Setup Response pair establishes the X2 relationship over an already-open SCTP association. Each eNB advertises its identity (Global eNB ID) and a full description of its served cells: for every cell it lists the PCI (physical cell ID), the EARFCN for downlink and uplink, the TAC (tracking area code), the broadcast PLMN identities, the transmission bandwidth, and neighbour information. Once the exchange completes, each side holds an accurate picture of the other's cells — the foundation every later procedure depends on, because a Handover Request or a Load Information report is meaningless without knowing which target cell it refers to.

The Served Cell Information IE is worth opening up, because handover targeting depends on it. Per served cell it carries the ECGI (E-UTRAN Cell Global Identifier — the globally unique cell identity, PLMN + 28-bit Cell Identity), the PCI (0–503), downlink and uplink EARFCN, the transmission bandwidth as a number of resource blocks (from 6 up to 100, i.e. 1.4–20 MHz), the duplex mode (FDD/TDD), the TAC and a Broadcast PLMNs list, plus the neighbour cell list. The receiving eNB stores all of this so that when it later admits a UE, it can map the source's target-cell pointer to a real cell it serves.

Configurations are not static. When a cell's parameters change later — a new cell is brought into service, a PCI is re-planned, bandwidth is reconfigured, or a cell is deactivated — an eNB does not tear down and rebuild X2. It sends an eNB Configuration Update carrying only the deltas (Served Cells To Add, Served Cells To Modify, Served Cells To Delete), and the peer confirms with eNB Configuration Update Acknowledge. If the peer cannot apply the change, it returns eNB Configuration Update Failure with a Cause and possibly a Time To Wait. The same failure pattern applies to setup itself: a mismatch or an overloaded peer answers the X2 Setup Request with an X2 Setup Failure carrying a Cause and a back-off Time To Wait before the initiator may retry.

The Cause IE is a structured enumeration — grouped into radio network, transport, protocol and miscellaneous causes (for example handover-target-not-allowed, no-radio-resources-available, unknown-eNB-Measurement-ID, or unspecified) — so every unsuccessful outcome on X2 says why in a machine-readable way, not just "failed". The Time To Wait enumerates fixed back-off steps (e.g. 1s, 2s, 5s, 10s, 20s, 60s) so a rejected initiator does not hammer an overloaded peer.

Two further procedures keep the association healthy. The Reset procedure (Reset Request / Reset Response) lets one eNB tell its neighbour to release all or a subset of UE-associated contexts after a restart, so both sides agree on which contexts still exist. The Error Indication procedure reports standalone protocol errors (a message not understood, an IE missing or malformed) using the same Cause and Criticality Diagnostics IEs. Setup, configuration update, reset and error indication are the "housekeeping" of X2 — nothing to do with any individual UE, everything to do with keeping the peer relationship consistent.

X2-C and X2-U — the Two Planes

The X2 interface is split into a control plane and a user plane, and it is worth being precise about what rides where, because they use entirely different transport and serve entirely different purposes.

The control plane, X2-C, carries X2AP signalling. Its protocol stack is X2AP over SCTP over IP. SCTP gives X2AP what it needs: reliable, in-sequence delivery, multi-streaming (so a stuck message on one stream does not head-of-line block others), and heartbeat-based failure detection. X2-C uses the registered SCTP payload protocol identifier for X2AP and a single standing association per eNB pair. Every procedure discussed on this page — setup, handover preparation, load information, resource status — is X2-C traffic.

The user plane, X2-U, exists for exactly one job: data forwarding during handover. It carries user PDUs in GTP-U tunnels (TS 29.281) over UDP (port 2152) over IP between the eNBs. X2-U tunnels are transient — created for a specific handover using endpoints negotiated on X2-C, used to move buffered and in-flight packets, then torn down. There is no permanent user-plane bearer standing on X2 the way there is on S1-U toward the S-GW.

Mobility — X2 Handover Signalling

The headline job of X2AP is X2-based handover: moving a connected UE from a source eNB to a target eNB without going through the core for the preparation. The source eNB decides, from the UE's measurement reports, that a neighbour cell has become better, and drives the handover directly over X2. This is the fast path; without an X2 relationship LTE falls back to the slower S1 handover through the MME.

Every UE-associated message carries a pair of identifiers so both eNBs resolve the same context. The source allocates the Old eNB UE X2AP ID in the Handover Request; the target allocates the New eNB UE X2AP ID in the acknowledge; thereafter both IDs travel together. Each is a value in the range 0–4095 (a 12-bit space) drawn independently from each eNB's own pool, so no shared numbering authority is needed — the same convention 5G reuses with AMF UE NGAP ID/RAN UE NGAP ID. The core sequence is a small, ordered set of elementary procedures:

Read the flow as three beats. First, preparation: the source asks, the target admits, and the target returns everything needed to move — the RRC command the source will hand to the UE, and the forwarding tunnel endpoints. If the target cannot admit the UE (no radio resources, an unsupported bearer, an internal failure) it replies with Handover Preparation Failure carrying a Cause instead of the acknowledge, and the source simply keeps serving the UE. Second, execution: the source sends the RRC handover command to the UE over the air, transfers PDCP status with SN Status Transfer, and begins forwarding buffered data over X2-U. Third, completion: once the UE has synchronised to the target and the target has run the S1 Path Switch Request toward the MME to redirect the downlink data path, the target sends UE Context Release so the source frees the context. The blow-by-blow, including the S-GW path switch, is covered on the dedicated X2 Handover page.

Data Forwarding over X2-U

Handover would drop packets if the source simply stopped transmitting at the moment the UE detaches. To keep the flow seamless, X2 uses its user plane, X2-U, running GTP-U tunnels between the two eNBs. In the Handover Request Acknowledge the target hands back tunnel endpoint identifiers (a 32-bit GTP-TEID plus the transport-layer address), one per E-RAB it is willing to receive forwarded data for. The source then tunnels the user data it has buffered — and any that keeps arriving from the S-GW on the old S1-U path before the path is switched — across X2-U to the target, which delivers it to the UE at the new cell.

Two flavours exist. Downlink forwarding moves buffered and in-flight downlink PDUs from source to target so the UE receives them there rather than losing them. Uplink forwarding (used when direct forwarding is selected) relays uplink PDUs the source received but had not yet delivered toward the S-GW. Combined with the SN Status Transfer, this lets PDCP resume at the target on exactly the right sequence numbers, so for acknowledged-mode bearers the handover is lossless and free of duplicates. Unacknowledged-mode bearers still benefit, though a few packets may be dropped by design.

In an X2 handover the eNBs forward directly to each other over X2-U; indirect forwarding routed via the S-GW is what S1 handover falls back to when there is no X2. Direct forwarding is lower latency and does not burden the core — a concrete reason operators keep X2 meshes dense between neighbours. The forwarding tunnel is closed once the S-GW's End Marker (GTP-U message type 254), emitted on the old S1-U path at the path switch and relayed by the source over X2-U, tells the target the old path is fully drained.

Load, Interference and SON Coordination

Beyond mobility, X2AP is how neighbours coordinate to avoid stepping on each other. These procedures need no UE to be moving — they run continuously between cells to shape interference and balance load.

Load Information is the workhorse (a class-2, fire-and-forget procedure): an eNB periodically tells its neighbours about interference and load conditions per physical resource block. It carries three key indicators. The UL Interference Overload Indication (OI) reports, per PRB, one of three levels — high-interference, medium-interference or low-interference — a reactive "I am being interfered with here" signal. The UL High Interference Indication (HII) is a proactive per-PRB bitmap (one bit per PRB) warning neighbours "I am about to schedule cell-edge users on these PRBs, so please avoid them." The downlink Relative Narrowband Tx Power (RNTP) is a per-PRB bitmap telling neighbours which downlink PRBs this cell will transmit above an RNTP threshold on, so they can steer their own edge users elsewhere. Together these drive ICIC (Inter-Cell Interference Coordination). Add the ABS Information IE — the Almost Blank Subframe pattern, a bitmap of subframes the cell will keep (almost) empty, plus an ABS Inactive option — and you get eICIC, where a macro cell blanks certain subframes so a small cell in its coverage can serve its edge users cleanly in the time domain.

Resource Status Reporting lets one eNB measure a neighbour's load on demand. The requesting eNB sends a Resource Status Request (naming the cells and metrics it wants via a Report Characteristics bitmap, an eNB1/eNB2 Measurement ID pair to correlate the session, and a Reporting Periodicity); the neighbour answers Resource Status Response to accept, or Resource Status Failure to reject, and thereafter streams periodic Resource Status Update messages carrying hardware load, S1-TNL load, radio-resource usage per cell (Radio Resource Status, DL/UL PRB usage as a percentage), and the Composite Available Capacity group (a cell-capacity class value scaled by a capacity value). This feeds load-balancing and admission decisions. A related procedure, Mobility Settings Change (Mobility Change Request / Mobility Change Acknowledge, with Mobility Change Failure on rejection), lets two neighbours negotiate a change to the handover trigger thresholds between their cells. Paired with the Handover Report and RLF Indication messages — which flag too-early, too-late and ping-pong handovers and radio-link failures — it forms the Mobility Robustness Optimisation (MRO) feature. These are the SON (Self-Organising Network) functions that live on X2.

EN-DC — X2 Reused for 5G Anchoring

X2 did not retire when 5G arrived. In EN-DC (E-UTRAN–NR Dual Connectivity), the NSA deployment where an LTE eNB anchors a 5G NR node, the interface between the Master eNB and the Secondary node — the en-gNB — is a variant of X2 running X2AP. This is why an operator with a working X2 mesh could add 5G NSA capacity comparatively quickly: the control-plane transport, the elementary-procedure model, and even much of the mobility machinery were already in place.

The reuse builds on LTE Dual Connectivity (DC), where X2AP gained inter-node procedures for a Master and Secondary node to share a UE. The SgNB Addition Request / SgNB Addition Request Acknowledge pair lets the master ask the secondary to allocate radio resources for a split, SCG or MCG-split bearer — carrying the E-RABs To Be Added list with per-bearer bearer-type choice and the SCG security material (the S-KgNB-related parameters). SgNB Modification Request/Acknowledge (and the SgNB-initiated SgNB Modification Required) adjust the secondary leg, and SgNB Release Request/Confirm drop it. Through these, a UE is served by LTE and NR radio at once, with the eNB remaining the control-plane anchor to the EPC while the en-gNB adds NR throughput.

The key mental cross-link: on plain LTE X2 the peer is always another eNB; in EN-DC the peer across X2 is an en-gNB, but the interface identity is preserved. The strictly-5G analogue — gNB-to-gNB in a standalone NR network — is not X2 at all but the Xn interface running XnAP, which is X2's direct descendant. So X2 spans two generations: eNB↔eNB for LTE mobility, and eNB↔en-gNB for 5G NSA anchoring.

Summary

X2AP is the lateral signalling protocol of the LTE RAN: eNB-to-eNB over a single standing SCTP association (X2-C), with transient GTP-U tunnels (X2-U) rolled out only to forward data during a handover. Everything on it is built from elementary procedures — class-1 with a success/failure outcome, class-2 fire-and-forget — and the peers are symmetric, each free to initiate.

Three job families cover the interface. Interface management (X2 Setup, eNB Configuration Update, Reset, Error Indication) keeps the two eNBs' view of each other's Served Cell Information consistent. Mobility (Handover Request → Ack → SN Status Transfer → UE Context Release, with paired Old/New eNB UE X2AP IDs and X2-U forwarding) makes handover fast and lossless. Coordination (Load Information with OI/HII/RNTP/ABS, plus Resource Status Reporting and MRO) shapes interference and balances load between neighbours.

The design outlived LTE: X2 was reused to anchor 5G NR in EN-DC (eNB↔en-gNB with the SgNB procedures), and its direct 5G descendant is XnAP over the Xn interface. Learn X2AP once and you have most of Xn for free.

Interview Quickfire