Handover Overview (how mobility is triggered) in LTE 4G

Introduction

A handover is the procedure that moves a UE in RRC_CONNECTED from one cell (the source) to another (the target) without dropping the RRC connection or the user's data session. It is the connected-mode counterpart of idle-mode cell reselection: in idle the UE chooses for itself, but the moment it has an active connection the network takes the wheel, because only the network knows load, neighbour relations, and bearer state.

Handover happens continuously in a live network — every time a moving user crosses a cell edge, every time a cell sheds load, every time coverage on the serving carrier fades and a better neighbour exists. It is one of the most-executed and most-scrutinised procedures in the RAN, because a handover that fires too late, too early, or to the wrong cell shows up directly as a dropped call or a stall.

The value of learning it as a single spine is that every variant — intra-eNB, X2, S1, inter-frequency, inter-RAT — is the same chain of events with a different node preparing the target. Master the spine and you can debug any of them by asking one question at each link: did this step happen, and did it carry the right IEs?

Why handover is needed

Concretely, the UE moves and radio quality on the serving cell fades while a neighbour improves. If nothing acted, the serving link would eventually degrade into radio link failure (RLF) and the connection would drop. Handover steers the UE onto the better cell before that happens, keeping the RRC connection alive and user-plane data flowing across the move. It also serves non-coverage goals: load balancing (event A4) pushes users off a congested cell, and inter-RAT handover (B1/B2) moves a UE to UTRAN/GERAN when LTE coverage runs out.

The mobility spine

Learn one chain and you understand every LTE handover variant. The steps repeat whether the target is another cell on the same eNB, a neighbour eNB reachable over X2, or one reachable only through the core over S1. What changes between variants is which node prepares the target and which interface carries that preparation — never the shape of the chain itself.

The links in the chain, in order:

1. Configure measurements. The source eNB sends an RRCConnectionReconfiguration carrying measConfig. A measObject (the carrier/frequency to watch) and a reportConfig (the event and reporting rules) are bound together by a measId. See Measurements & Events for the full IE tree.
2. UE measures and reports. The UE filters RSRP/RSRQ on the serving cell and configured neighbours. When an event condition holds for the configured timeToTrigger, the UE sends a MeasurementReport carrying measResults — the measId plus RSRP/RSRQ per physCellId for the serving cell and the best neighbours.
3. Decide. The source eNB feeds the report into its own radio-resource-management algorithm and selects a target cell. This step is entirely internal and produces no over-the-air message.
4. Prepare. The source performs handover preparation with the target — directly over the X2 interface, or through the MME over S1 when no X2 exists. The target admits the UE, allocates a C-RNTI and a dedicated preamble, and returns the RRC configuration the UE must apply.
5. Command & execute. The source sends the UE an RRCConnectionReconfiguration containing mobilityControlInfo. The UE detaches from the source, performs RACH to the target, and confirms with RRCConnectionReconfigurationComplete sent to the target.

What triggers a handover

Nothing inside the UE spontaneously starts a handover. The ignition is a MeasurementReport that satisfies a report configuration the source eNB installed earlier through measConfig. The classic trigger is event A3: a neighbour cell becomes an offset better than the serving cell, sustained for the configured timeToTrigger and beyond a hysteresis margin, so momentary fades do not cause needless handovers. The A3 entering condition is Mn + Ofn + Ocn − Hys > Ms + Ofs + Ocs + Off, where Mn/Ms are the measured neighbour/serving results and the offsets come from the frequency and cell-individual configuration.

The report is the ignition and the source eNB is the driver: it configured the event via reportConfigEUTRA (or reportConfigInterRAT for B-events), it receives the report on SRB1, and it alone runs the decision. The a3-Offset, hysteresis and timeToTrigger values it chooses are the levers that trade handover promptness against ping-pong resistance. The exact field tree lives on the Measurements & Events page; here it is enough to know the report is what wakes the whole chain.

Classifying the handover

The spine is constant, but LTE handovers are classified along several independent axes at once. A single handover is, for example, an inter-eNB, X2-based, intra-frequency handover. Knowing which axis you are on tells you which interface carries preparation and whether the core is involved.

The two rows that matter most for the signalling are node scope and preparation interface. In an intra-eNB handover the eNB simply reconfigures the UE onto another of its own cells — no X2, no S1, no path switch. In an X2-based inter-eNB handover the source and target eNBs talk directly with X2AP HANDOVER REQUEST / HANDOVER REQUEST ACKNOWLEDGE, and the core is touched only at the very end via a Path Switch Request. In an S1-based handover, used when no X2 exists between the eNBs, the MME is involved from the start and relays preparation with S1AP Handover Required / Handover Command, driving the bearer switch itself. Both inter-eNB flavours are broken out in full on their own pages; this overview is the map that ties them together.

Three phases: preparation, execution, completion

However you classify it, an inter-eNB handover always factors into three phases. Keeping them separate is the cleanest way to reason about what has and has not yet happened at any point in the flow.

• Preparation. Everything before the UE is told to move. The source decides, then negotiates with the target: the target performs admission control, reserves radio resources, allocates the C-RNTI and dedicated RACH preamble, and hands back the ready-made RRCConnectionReconfiguration (as a transparent container). No user-plane break yet — the UE is still happily on the source.
• Execution. The window in which the UE actually moves. The source delivers the handover command over the air, transfers PDCP status and forwards buffered data for lossless bearers, and the UE detaches, performs RACH to the target, and confirms. This is where the radio-link interruption lives.
• Completion. Everything after the UE is on the target. The target switches the core user-plane path (the path switch) so downlink data flows to the new eNB, and the source is told to release the UE context and free its resources.

The diagram below shows the high-level flow across the actors, coloured by phase. Every arrow is labelled with the message and the IEs that matter. This is intra-eNB or X2-based inter-eNB at a glance; the inter-node detail (X2AP or S1AP messages, SN Status Transfer, GTP-U forwarding, path switch) is on the linked pages.

Inside the handover command

The single most important message on the spine is the RRCConnectionReconfiguration that carries mobilityControlInfo. This is what people mean when they say "handover command." Its presence is exactly what turns an ordinary reconfiguration into a handover — per TS 36.331, a reconfiguration containing mobilityControlInfo instructs the UE to perform a synchronised reconfiguration (a handover) to the cell named inside it. The fields you must know:

Alongside mobilityControlInfo, the same reconfiguration carries a radioResourceConfigDedicated holding the target's prepared SRB/DRB, MAC and PHY setup, and a securityConfigHO whose nextHopChainingCount tells the UE how to derive the fresh access-stratum keys for the target. On receiving it the UE stops using the source, applies the target configuration, derives the target keys, starts t304, and does RACH to the target. Because rach-ConfigDedicated gives it a reserved preamble, the target recognises the UE immediately and returns an uplink grant; the UE then sends RRCConnectionReconfigurationComplete on the target C-RNTI, which stops t304 and completes the radio-side handover.

Hard handover, interruption and lossless delivery

LTE uses hard handover — break-before-make. The UE releases the source radio link before it accesses the target, so there is always a brief interruption during which the UE can neither transmit nor receive user data on either cell: the gap runs from when the UE detaches from the source to when it completes RACH and confirms on the target. There is no soft handover (no simultaneous connection to two cells) as there was in UMTS. Two mechanisms keep that gap from hurting: the dedicated (contention-free) RACH from rach-ConfigDedicated shortens the interruption, and data forwarding keeps packets from being lost during it.

Data forwarding. During preparation the source begins tunnelling downlink packets it has buffered — and packets that keep arriving from the core before the path is switched — to the target eNB. On X2 these travel over a GTP-U forwarding tunnel directly between the eNBs (X2-U); on S1 they are relayed through the Serving Gateway. The target buffers them and delivers them once the UE arrives, so nothing is dropped even though the radio link broke.

SN Status Transfer. Forwarding alone is not enough for acknowledged-mode (RLC-AM) bearers, where every PDCP SDU is numbered and must be delivered exactly once, in order. So the source also sends an SN Status Transfer (X2AP over X2, or embedded in the S1AP flow over S1) conveying, per AM bearer, the uplink PDCP receiver status (the next expected UL PDCP SN plus a bitmap of already-received out-of-order SDUs) and the downlink COUNT the target should assign to the first forwarded or new DL SDU. COUNT is HFN concatenated with PDCP SN. With this the target resumes PDCP numbering at the exact next value, reorders uplink correctly, and avoids both loss and duplication. Unacknowledged-mode (RLC-UM) bearers do not get this treatment — a few packets may be lost across a handover, which is acceptable for the delay-sensitive traffic that uses UM.

When handover fails

The execution phase is supervised by t304. The UE starts it the moment it applies the handover command and stops it when it successfully completes access to the target (i.e. when it sends RRCConnectionReconfigurationComplete). If the UE cannot reach the target before t304 expires — the dedicated preamble goes unanswered, the target is unreachable, or the radio simply fails on the way in — the UE declares handover failure.

On t304 expiry the UE does not silently drop the call. It reverts to the source configuration it saved before the handover, then initiates RRC connection re-establishment: it performs cell selection, camps on the best suitable cell (which may be the original source, the intended target, or a third cell), and sends an RRCConnectionReestablishmentRequest. If the cell it lands on has a prepared UE context (for example the source, or a target that had been prepared), re-establishment succeeds and the connection continues with minimal disruption; if not, the request is rejected and the UE must fall all the way back to a full RRCConnectionSetup from RRC_IDLE, which the user perceives as a dropped connection. Handover failures are also what the network watches to detect too-early, too-late or wrong-cell handovers, feeding mobility robustness optimisation (MRO) so the eNB can retune its A3 offsets and timeToTrigger.

Reading a handover in the logs

On the UE side, a successful handover is a compact, recognisable sequence of RRC and MAC events: the report goes up, the command comes down with mobilityControlInfo, t304 starts, RACH to the target succeeds, the complete goes up, and t304 stops. Walking these in order is the fastest way to localise a failure.

Representative UE log — illustrative, values vary by vendor/build:

Summary

Every LTE connected-mode handover is the same spine: measConfig → MeasurementReport → HO decision → preparation → RRCConnectionReconfiguration(mobilityControlInfo) → RACH to target → RRCConnectionReconfigurationComplete → path switch. The variants (intra-eNB, X2, S1, inter-frequency, inter-RAT) differ only in which node prepares the target and which interface carries preparation — never in the shape of the chain.

The mobilityControlInfo IE is what turns a reconfiguration into a handover; the target builds it and the source forwards it unmodified. LTE handover is hard (break-before-make), so it always has an interruption gap, made short by contention-free RACH and lossless (for AM bearers) by data forwarding plus SN Status Transfer. When it fails, t304 expiry drives the UE into re-establishment. To debug, walk the spine in the logs and find the first link that did not happen or carried the wrong IE — that link names the cause.

Quick Q&A