🗂️ RRC — Radio Resource ControlAdvanced

S1-based Handover (with exact IEs) in LTE 4G

Handover via the core when there's no X2 — Handover Required/Request/Command over S1AP, with the MME/S-GW path switch.

📚 3GPP-basedTS 23.401TS 36.413TS 36.300

S1-based handover is how LTE moves a connected UE between two eNBs that have no direct X2 link — the core network relays the entire handover on their behalf. Learn it message by message and "call drops during mobility" tickets stop being mysteries.

Introduction

The S1-based handover is the LTE inter-eNB mobility procedure used when there is no direct X2 interface between the source and target eNB — because the two eNBs belong to different vendors or configuration domains, sit across an operator boundary, or the operator has administratively barred X2 mobility. Because the source eNB cannot reach the target directly, the Evolved Packet Core relays the entire preparation phase over S1-MME (S1AP): the source eNB triggers a HANDOVER REQUIRED toward the MME, the MME drives a HANDOVER REQUEST into the target eNB, the target admits resources and returns a ready-made RRCConnectionReconfiguration inside a transparent container, and the MME hands it back to the source in a HANDOVER COMMAND.

The source then commands the UE to retune with RRCConnectionReconfiguration carrying mobilityControlInfo (targetPhysCellId, rach-ConfigDedicated, t304). After the UE performs contention-free RACH to the target and sends RRCConnectionReconfigurationComplete, the target issues HANDOVER NOTIFY, the MME switches the downlink bearer path at the S-GW with a Modify Bearer Request (end markers flushed on the old path), and finally releases the source UE context.

This document walks the intra-MME case as the main flow and notes the inter-MME additions (Forward Relocation over S10) where they apply. It is specified in TS 23.401 (EPC stage-2 flow), TS 36.413 (S1AP messages and IEs) and TS 36.300 (E-UTRAN handover). Because the flow is a long chain of messages across four network nodes, a failure almost always lives in one specific step — which is exactly why walking it message by message pays off.

Why S1 handover is needed

💡

In plain words: imagine two shops that want to transfer a customer's open account, but they have no private phone line between them. So they route the whole handover through head office: shop A calls HQ, HQ calls shop B, B prepares the account and sends the paperwork back through HQ to A, and only then does A tell the customer "walk next door, they're expecting you." X2 handover is the private phone line; S1 handover is doing it all through head office (the MME) because that line does not exist.

Concretely, LTE has two ways to hand a connected UE between eNBs. X2 handover uses a direct X2 interface between the eNBs and is fast because the two RANs prepare each other directly. But an X2 link is not always there — different vendors without X2 configured, different MME pool areas, or an operator policy that bars X2 mobility. When there is no usable X2, the mobility must still happen, so the eNB falls back to S1 handover, in which the MME sits in the middle and relays every preparation message. This is the only way to keep an active call or data session alive across an eNB boundary that X2 cannot cross — and, because the MME and S-GW are in the path, S1 handover can additionally relocate the MME (over S10) or the S-GW when topology makes that efficient, something X2 can never do.

Measurement & Decision (1–2)S1 Preparation via MME (3–8)Execution (9–13)Path Switch & Release (14–16)

Call flow

The message-sequence chart below shows an intra-MME S1 handover end to end: with no X2 to the target, the MME relays the entire preparation phase, then the UE retunes and the core switches the downlink path before the source is released.

Figure 1. S1-based intra-MME handover message sequence, with the MME relaying preparation, over-the-air execution, path switch and source release.

MeasurementReport (event A3) — the UE reports a neighbour has become offset-better than the serving cell.
Handover Required (S1AP) — with no X2, the source eNB asks the MME to prepare the target.
Handover Request — the MME drives resource allocation into the target eNB.
Handover Request Acknowledge — the target admits E-RABs and returns the RRC handover command container.
Handover Command — the MME hands the target-built RRC command back to the source.
RRCConnectionReconfiguration (HO command) — the source commands the UE to retune to the target.
Data forwarding of buffered downlink PDCP SDUs, direct or indirect via the S-GW.
The UE performs contention-free RACH and confirms with RRCConnectionReconfigurationComplete to the target.
Handover Notify — the target tells the MME the UE has arrived, triggering the path switch.
The MME switches the downlink path at the S-GW with Modify Bearer Request/Response.
UE Context Release Command — the MME releases the source eNB's UE context and resources.

Note: X2 handover uses a direct X2 interface between eNBs; S1 handover is used when there is no X2, with the MME relaying preparation (and, across MME pools, via Forward Relocation over S10).

Call flow at a glance

Step	Message	Direction	Interface	Purpose
1	MeasurementReport (Event A3)	UE → Source eNB	LTE-Uu	UE reports neighbour cell stronger; source eNB begins handover decision
2	Handover Decision (no X2)	Source eNB (internal)	eNB RRM	No X2 to target, so source selects the S1 handover procedure
3	S1AP HANDOVER REQUIRED	Source eNB → MME	S1-MME	Source asks core to prepare the target eNB (no X2 available)
4	Forward Relocation Request (inter-MME only)	Source MME → Target MME	S10	Relocate MM/bearer context when target is on a different MME
5	S1AP HANDOVER REQUEST	MME → Target eNB	S1-MME	Core requests target to reserve radio/transport resources
6	S1AP HANDOVER REQUEST ACKNOWLEDGE	Target eNB → MME	S1-MME	Target admits E-RABs, returns RRC HO command container
7	Forward Relocation Response (inter-MME only)	Target MME → Source MME	S10	Relay outcome + set up indirect forwarding tunnels
8	S1AP HANDOVER COMMAND	MME → Source eNB	S1-MME	Core hands the target-built RRC command back to the source
9	RRCConnectionReconfiguration (mobilityControlInfo)	Source eNB → UE	LTE-Uu	Source commands UE to synchronise to the target cell
10	eNB Status Transfer / MME Status Transfer	Source eNB → MME → Target eNB	S1-MME	Conveys PDCP SN/HFN status for lossless AM bearers
11	Data Forwarding (GTP-U)	Source eNB → Target (direct/indirect via S-GW)	GTP-U	Forward buffered/in-flight DL PDCP SDUs to avoid loss
12	RACH + RRCConnectionReconfigurationComplete	UE → Target eNB	LTE-Uu	UE detaches, does CFRA and confirms handover on new C-RNTI
13	S1AP HANDOVER NOTIFY	Target eNB → MME	S1-MME	Target tells core UE has arrived; triggers path switch
14	Modify Bearer Request / Response	MME ↔ S-GW	S11	S-GW switches DL path to target; end markers on old path
15	Forward Relocation Complete Notify/Ack (inter-MME only)	Target MME → Source MME	S10	Confirms relocation done; starts source-side release timer
16	S1AP UE CONTEXT RELEASE COMMAND / COMPLETE	MME → Source eNB	S1-MME	Release source UE context and radio/transport resources

Phase A — Measurement & Decision (Steps 1–2)

The source eNB has previously configured the UE with event-triggered mobility measurements. When a neighbour cell becomes offset-better than the serving cell, the UE reports it, and the source eNB runs its handover decision algorithm. Discovering that it has no X2 interface toward the reported target, it selects the S1 handover procedure and begins preparation through the MME.

Step 1Measurement Report (Event A3)UE → Source eNB · LTE-Uu

What happens

The UE, configured with an A3 reportConfig (neighbour becomes an offset better than serving), performs L3 filtering on RSRP/RSRQ of detected neighbours and starts the timeToTrigger timer when the A3 entering condition Mn + Ofn + Ocn − Hys > Mp + Ofp + Ocp + Off is satisfied. When the condition persists for the full timeToTrigger, the UE sends a MeasurementReport on SRB1 carrying the measId and the measured results for the serving cell (PCI 42) and the best neighbour (PCI 310). The source eNB evaluates measResults and selects PCI 310 as the handover target candidate; because no X2 link exists toward the eNB owning that cell, it will proceed over S1.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
measId	1	Links the A3 measObject and reportConfig that triggered the report
measResultPCell.physCellId	42	PCI of the current serving cell
measResultPCell.rsrpResult	40 (−100 dBm)	Serving cell quality, degrading as the UE moves away
measResultPCell.rsrqResult	18 (−15.5 dB)	Serving cell load/quality indicator
measResultNeighCells.physCellId	310	PCI of the reported target neighbour cell
neighCell.rsrpResult	55 (−85 dBm)	Target is ~15 dB stronger — satisfies A3 offset
neighCell.rsrqResult	28 (−10.5 dB)	Confirms target cell viability
reportConfig / triggerType	eventA3 (a3-Offset 3 dB, hysteresis 1 dB, TTT ms320)	Entry condition and anti-ping-pong margin for the report

Packet Capture

No. 10.000000UE→eNB-SourceLTE RRC62UL-DCCH MeasurementReport (measId=1, PCI 310 RSRP −85dBm)

LTE Radio Resource Control (RRC) protocol
    UL-DCCH-Message
        message: c1 (0)
            c1: measurementReport (1)
                measurementReport
                    criticalExtensions: c1 (0)
                        measurementReport-r8
                            measResults
                                measId: 1
                                measResultPCell
                                    rsrpResult: 40 (RSRP −100dBm)
                                    rsrqResult: 18 (RSRQ −15.5dB)
                                measResultNeighCells: measResultListEUTRA (0)
                                    MeasResultEUTRA: physCellId 310
                                        rsrpResult: 55 (RSRP −85dBm)
                                        rsrqResult: 28 (RSRQ −10.5dB)

Step 2Handover Decision (No X2 to Target)Source eNB (internal) · eNB RRM

What happens

The source eNB's radio resource management (RRM) function processes the MeasurementReport and confirms that PCI 310 crosses the handover trigger threshold with sufficient margin. It resolves PCI 310 to a target eNB Global ID and looks up its mobility state: there is no X2 association toward that eNB (no X2 Setup has ever completed, or X2 handover is administratively barred by policy). With direct RAN-to-RAN preparation impossible, the eNB selects the S1 handover procedure and marks Direct Forwarding Path Availability according to whether a source-to-target IP transport path exists — here it does not, so indirect forwarding via the S-GW will be used. This is a purely internal decision with no radio or network message; the log entry below is an eNB RRM trace, not an over-the-air PDU.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
Reported target PCI	310	Neighbour selected as handover target from step 1
Resolved Target eNB ID	0x00013 (macro eNB)	Global eNB ID owning the target cell PCI 310
X2 association state	NOT_ESTABLISHED	No X2 link to target — direct X2 handover not possible
Selected procedure	S1 Handover (IntraLTE)	Core-relayed handover chosen as the only option
Direct Forwarding Path	notAvailable	No source-to-target transport; indirect forwarding via S-GW
Cause	handover-desirable-for-radio-reasons	Reason that will be signalled to the MME in step 3

Packet Capture

No. 20.001200eNB-Source→eNB-SourceeNB RRM—HO decision: PCI 310, no X2 → select S1 handover

eNB Radio Resource Management (internal trace)
    Mobility Event: A3_TRIGGER
        measId: 1
        target-PCI: 310
        target-eNB-ID: 0x00013
        x2-link-state: NOT_ESTABLISHED
    Handover Decision
        procedure-selected: S1_HANDOVER (IntraLTE)
        direct-forwarding-path: notAvailable
        cause: handover-desirable-for-radio-reasons
        action: build S1AP HandoverRequired to MME

✅ Debugging steps

Confirm the UE was actually configured with the A3 reportConfig and a measObject for the target frequency — no config, no MeasurementReport, no handover.
Check the reported neighbour PCI resolves to a real target eNB in the ANR/neighbour relation table; an unresolved PCI stalls the decision.
Verify the source eNB genuinely has no X2 association to that target (X2 state NOT_ESTABLISHED or policy-barred) — that is what forces the S1 path.
Sanity-check the A3 parameters (a3-Offset, hysteresis, timeToTrigger) against ping-pong or late-handover symptoms.

⚠ Common causes of failure

Missing or wrong measurement configuration, so the UE never reports the neighbour.
A3 offset/TTT too large — the report comes too late and the radio link fails before handover starts.
Reported PCI ambiguous (PCI confusion) so the eNB resolves the wrong target eNB.
Neither X2 nor S1 usable toward the target (no neighbour relation at all), so no handover can be prepared.

Phase B — S1 Preparation via MME (Steps 3–8)

With the S1 procedure selected, the source eNB relays the request through the MME. In the intra-MME case a single MME plays both roles; when the target eNB is served by a different MME, the source MME first relocates the session to the target MME over S10 (Forward Relocation Request/Response). The target eNB performs admission control, builds the RRCConnectionReconfiguration, and returns it inside a transparent container that the MME relays back to the source. All S1AP signalling rides SCTP with PPID 18 on port 36412.

Step 3S1AP HANDOVER REQUIREDSource eNB → MME · S1-MME (S1AP/SCTP)

What happens

The source eNB sends HANDOVER REQUIRED to the serving MME to request core-assisted preparation. It carries the Handover Type (IntraLTE), the Cause, the Target ID identifying the target eNB Global ID and its selected TAI, and a Source eNB to Target eNB Transparent Container — an opaque blob built by the source RRC that holds the source RRC context (HandoverPreparationInformation with UE radio capabilities and current AS-Config), the target cell ID, and E-RAB information the target will need. It also indicates Direct Forwarding Path Availability. The MME uses the Target ID to determine the target eNB and, if it lies under a different MME, the target MME.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	MME's identifier for this UE association on S1
eNB UE S1AP ID	0x0001A2B	Source eNB's identifier for the UE association
Handover Type	IntraLTE	Handover stays within E-UTRAN (eNB to eNB)
Cause	radioNetwork: handover-desirable-for-radio-reasons	Reason reported to the core for the handover
Target ID.Global eNB ID	PLMN 310-410, Macro eNB-ID 0x00013	Global identity of the target eNB to prepare
Target ID.Selected TAI	PLMN 310-410, TAC 0x0A2C	Target tracking area identity
Direct Forwarding Path Availability	notAvailable	Signals indirect (via S-GW) forwarding will be used
Source-to-Target Transparent Container	RRC context + targetCellID (ECGI 0x0013001)	Opaque source RRC info relayed through the core to the target

Packet Capture

No. 30.003500eNB-Source→MMES1AP296HandoverRequired (id-HandoverPreparation, IntraLTE)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 296 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-HandoverPreparation (0)
            value
                HandoverRequired
                    id-MME-UE-S1AP-ID: 0x000045F1
                    id-eNB-UE-S1AP-ID: 0x0001A2B
                    id-HandoverType: intralte (0)
                    id-Cause: radioNetwork (0): handover-desirable-for-radio-reasons
                    id-TargetID: targeteNB-ID (Global eNB-ID 0x00013, sTAI PLMN 310-410 TAC 0x0A2C)
                    id-Direct-Forwarding-Path-Availability: notAvailable
                    id-Source-ToTarget-TransparentContainer: 212 bytes (RRC context, targetCell ECGI 0x0013001)

Step 4Forward Relocation Request (inter-MME only)Source MME → Target MME · S10 (GTPv2-C) · OPTIONAL

What happens

This step applies only when the target eNB is served by a different MME. The source MME relocates the UE by sending a GTPv2-C Forward Relocation Request to the target MME over S10, conveying the UE's MM context (security keys, UE network capabilities), the EPS bearer contexts (with the S-GW S1-U endpoints), the target identification, and the same Source-to-Target Transparent Container to be delivered to the target eNB. The target MME allocates its own resources and continues the preparation toward the target eNB. In the intra-MME case covered as the main flow, this step is skipped entirely — the single MME plays both source and target roles and proceeds directly to step 5.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
Message Type	Forward Relocation Request (133)	GTPv2-C message that relocates the UE to a new MME
IMSI	310410123456789	Subscriber identity anchoring the relocated context
MME/SGSN UE MM Context	KASME, NAS keys, UE Network Capability	Security and capability context handed to target MME
Sender F-TEID for Control Plane	10.30.1.1, TEID 0x0000C0DE	Source MME S10 control endpoint for the response
EPS Bearer Context.EBI	5 (QCI 9), 6 (QCI 1)	Bearers to be relocated with their S-GW S1-U endpoints
Target Identification	Macro eNB-ID 0x00013, TAI 310-410/0x0A2C	Identifies the target eNB the new MME must prepare
Source-to-Target Transparent Container	212 bytes (opaque RRC context)	Passed through unchanged to the target eNB

Packet Capture

No. 40.005000MME-Source→MME-TargetGTPv2-C248Forward Relocation Request (IMSI 310410…, EBI 5,6) [inter-MME]

GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2, T 1)
    Message Type: Forward Relocation Request (133)
    Message Length: 244
    TEID: 0x00000000
    Sequence Number: 0x000012
    IMSI: 310410123456789
    MME/SGSN UE MM Context: KASME present, UE-NW-Capability present
    F-TEID (Sender, Control Plane): IPv4 10.30.1.1, TEID 0x0000C0DE
    Bearer Context: EBI 5 (QCI 9), EBI 6 (QCI 1)
    Target Identification: eNB-ID 0x00013, TAI 310-410 TAC 0x0A2C
    F-Container: Source-to-Target Transparent Container (212 bytes)

Step 5S1AP HANDOVER REQUESTMME → Target eNB · S1-MME (S1AP/SCTP)

What happens

The (target) MME sends HANDOVER REQUEST to the target eNB to reserve radio and transport resources. It carries the E-RAB To Be Setup List — each E-RAB's ID, QoS (QCI, ARP, and for GBR bearers the GBR/MBR), and the S-GW uplink GTP-U transport-layer address and TEID so the target can send uplink user data toward the S-GW. It also conveys the UE Security Capabilities, the Security Context (the fresh KeNB* material and its Next Hop Chaining Count NCC used to derive the target AS keys), the UE Aggregate Maximum Bit Rate, and the Source-to-Target Transparent Container holding the source RRC context. The target uses all of this to admit the UE and build the handover command.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	MME association identity given to the target eNB
Handover Type	IntraLTE	Confirms E-UTRAN-to-E-UTRAN handover
UE Aggregate Maximum Bit Rate	DL 150 Mbps, UL 50 Mbps	Non-GBR aggregate rate cap for the UE
E-RAB To Be Setup.E-RAB ID	5 (QCI 9), 6 (QCI 1)	Bearers to establish at the target eNB
E-RAB 5 QoS / ARP	QCI 9 non-GBR, ARP priority 8	Default internet bearer QoS to honour at target
E-RAB 6 QoS / GBR-MBR	QCI 1 GBR, GBR 150/150 kbps, ARP priority 4	VoLTE bearer — guaranteed bit rate must be reserved
E-RAB 5 UL GTP-U TNL	S-GW 10.30.5.8, TEID 0x00A1F3C4	Uplink S1-U endpoint at S-GW for E-RAB 5
E-RAB 6 UL GTP-U TNL	S-GW 10.30.5.8, TEID 0x00A1F3C5	Uplink S1-U endpoint at S-GW for E-RAB 6
UE Security Capabilities	EEA0/EEA1/EEA2, EIA1/EIA2	Supported EPS encryption and integrity algorithms
Security Context.NCC / KeNB*	NCC 3, KeNB* 0x9F..C1 (256-bit)	Next Hop Chaining Count and key material for target AS keys
Source-to-Target Transparent Container	212 bytes (RRC context)	Opaque source RRC info the target needs to build HO command

Packet Capture

No. 50.015000MME→eNB-TargetS1AP352HandoverRequest (id-HandoverResourceAllocation, E-RAB 5,6)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 352 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-HandoverResourceAllocation (1)
            value
                HandoverRequest
                    id-MME-UE-S1AP-ID: 0x000045F1
                    id-HandoverType: intralte (0)
                    id-uEaggregateMaximumBitrate: DL 150000000, UL 50000000
                    id-E-RABToBeSetupListHOReq: 2 items
                        E-RAB-ID 5: QCI 9, ARP 8, non-GBR
                            transportLayerAddress 10.30.5.8, gTP-TEID 0x00A1F3C4
                        E-RAB-ID 6: QCI 1, ARP 4, GBR 150000/150000
                            transportLayerAddress 10.30.5.8, gTP-TEID 0x00A1F3C5
                    id-UESecurityCapabilities: EEA0/EEA1/EEA2, EIA1/EIA2
                    id-SecurityContext: nextHopChainingCount 3, nextHopParameter 0x9F..C1
                    id-Source-ToTarget-TransparentContainer: 212 bytes

Step 6Admission Control & S1AP HANDOVER REQUEST ACKNOWLEDGETarget eNB → MME · S1-MME (S1AP/SCTP)

What happens

The target eNB performs admission control, reserves radio resources for the admitted bearers, allocates a C-RNTI and a dedicated RACH preamble for contention-free access, derives the target AS keys from KeNB*/NCC, and builds the RRCConnectionReconfiguration the UE will execute. It returns HANDOVER REQUEST ACKNOWLEDGE carrying the E-RAB Admitted List (each admitted E-RAB's downlink S1-U TEID at the target, plus DL data-forwarding TEIDs used for indirect forwarding) and a Target eNB to Source eNB Transparent Container holding the RRC message. That message's mobilityControlInfo carries targetPhysCellId 310, the new C-RNTI 0x4E21, rach-ConfigDedicated with ra-PreambleIndex 23, and t304. Any bearers that could not be admitted are reported in a Failed list.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	Echoes MME association for correlation
eNB UE S1AP ID	0x0002C77 (target-allocated)	Target eNB's new UE S1AP ID for the association
E-RAB Admitted.E-RAB ID	5, 6	Bearers accepted by target admission control
E-RAB 5 DL GTP-U TNL (target)	eNB 10.40.9.4, TEID 0x00B2D5E6	Target DL S1-U endpoint for S-GW to send DL data
E-RAB 5 DL Forwarding TNL	10.40.9.4, TEID 0x00C7A1	Tunnel target offers for forwarded DL PDUs (E-RAB 5)
E-RAB 6 DL Forwarding TNL	10.40.9.4, TEID 0x00C7A2	Tunnel target offers for forwarded DL PDUs (E-RAB 6)
Target-to-Source Transparent Container	RRCConnectionReconfiguration (mobilityControlInfo)	Opaque RRC command for the UE, relayed via MME/source
mobilityControlInfo.targetPhysCellId	310	Target physical cell identity the UE must sync to
mobilityControlInfo.newUE-Identity	C-RNTI 0x4E21	C-RNTI the UE will use in the target cell
rach-ConfigDedicated.ra-PreambleIndex	23	Contention-free preamble reserved for this UE
mobilityControlInfo.t304	ms1000	Handover supervision timer at the UE

Packet Capture

No. 60.089000eNB-Target→MMES1AP288HandoverRequestAcknowledge (eNB-UE 0x2C77, E-RAB 5,6 admitted)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 288 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: successfulOutcome (1)
        successfulOutcome
            procedureCode: id-HandoverResourceAllocation (1)
            value
                HandoverRequestAcknowledge
                    id-MME-UE-S1AP-ID: 0x000045F1
                    id-eNB-UE-S1AP-ID: 0x0002C77
                    id-E-RABAdmittedList: 2 items
                        E-RAB-ID 5: DL-TNL 10.40.9.4 TEID 0x00B2D5E6, dlFwd-TNL 10.40.9.4 TEID 0x00C7A1
                        E-RAB-ID 6: DL-TNL 10.40.9.4 TEID 0x00B2D5E7, dlFwd-TNL 10.40.9.4 TEID 0x00C7A2
                    id-Target-ToSource-TransparentContainer: 168 bytes
                        (RRCConnectionReconfiguration: mobilityControlInfo
                         targetPhysCellId 310, newUE-Identity C-RNTI 0x4E21,
                         rach-ConfigDedicated ra-PreambleIndex 23, t304 ms1000)

Step 7Forward Relocation Response & Indirect Tunnel Setup (inter-MME only)Target MME → Source MME · S10 (GTPv2-C) · OPTIONAL

What happens

Applicable only in the inter-MME case. The target MME relays the target eNB's outcome back to the source MME in a GTPv2-C Forward Relocation Response over S10, echoing the admitted bearers and the Target-to-Source Transparent Container. In parallel, because no direct forwarding path exists, the MMEs and S-GW establish the indirect data-forwarding tunnels: the S-GW allocates DL forwarding endpoints that map the source eNB's forwarded traffic onto the target eNB's DL forwarding TEIDs. In the intra-MME main flow this exchange collapses into the single MME's internal handling and no S10 message is sent.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
Message Type	Forward Relocation Response (134)	GTPv2-C reply relaying the target's preparation outcome
Cause	Request accepted (16)	Confirms the target MME/eNB admitted the UE
Sender F-TEID for Control Plane	10.30.2.1, TEID 0x0000BEEF	Target MME S10 control endpoint
E-RAB Admitted / Bearer Context	EBI 5, 6 admitted	Bearers accepted, echoed from the target eNB
Indirect Fwd DL S-GW F-TEID	10.30.5.9, TEID 0x00D1A2 / 0x00D1A3	S-GW endpoints for indirect DL forwarding tunnels
Target-to-Source Transparent Container	168 bytes (RRC command)	Opaque RRC message passed back toward the source eNB

Packet Capture

No. 70.093000MME-Target→MME-SourceGTPv2-C196Forward Relocation Response (Cause: Accepted) [inter-MME]

GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2, T 1)
    Message Type: Forward Relocation Response (134)
    Message Length: 192
    TEID: 0x0000C0DE
    Sequence Number: 0x000012
    Cause: Request accepted (16)
    F-TEID (Sender, Control Plane): IPv4 10.30.2.1, TEID 0x0000BEEF
    Bearer Context: EBI 5 admitted, EBI 6 admitted
    Indirect Fwd Tunnel: S-GW 10.30.5.9 TEID 0x00D1A2 (EBI5), 0x00D1A3 (EBI6)
    F-Container: Target-to-Source Transparent Container (168 bytes)

Step 8S1AP HANDOVER COMMANDMME → Source eNB · S1-MME (S1AP/SCTP)

What happens

The MME relays the target's decision to the source eNB in a HANDOVER COMMAND. It confirms the E-RABs Subject To Forwarding with the forwarding GTP-U TEIDs the source should tunnel buffered DL data to (the target's endpoints directly, or the S-GW's indirect endpoints), lists any E-RABs to release, and carries the Target-to-Source Transparent Container holding the RRCConnectionReconfiguration the source must deliver to the UE unchanged. Receipt of this message ends the preparation phase and authorises the source eNB to execute the handover over the air.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	Correlates to the ongoing UE association
eNB UE S1AP ID	0x0001A2B	Source eNB's UE S1AP ID
Handover Type	IntraLTE	Confirms the E-UTRAN handover type
E-RAB Subject to Forwarding.E-RAB ID	5, 6	Bearers authorised for DL data forwarding
E-RAB 5 DL Forwarding TNL	10.30.5.9, TEID 0x00D1A2 (indirect via S-GW)	Endpoint the source uses to forward buffered DL PDUs
E-RAB 6 DL Forwarding TNL	10.30.5.9, TEID 0x00D1A3 (indirect via S-GW)	Forwarding endpoint for the VoLTE bearer
Target-to-Source Transparent Container	168 bytes (RRCConnectionReconfiguration)	The exact RRC command to send to the UE

Packet Capture

No. 80.101000MME→eNB-SourceS1AP236HandoverCommand (id-HandoverPreparation, E-RAB 5,6 fwd)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 236 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: successfulOutcome (1)
        successfulOutcome
            procedureCode: id-HandoverPreparation (0)
            value
                HandoverCommand
                    id-MME-UE-S1AP-ID: 0x000045F1
                    id-eNB-UE-S1AP-ID: 0x0001A2B
                    id-HandoverType: intralte (0)
                    id-E-RABSubjecttoDataForwardingList: 2 items
                        E-RAB-ID 5: dL-TransportLayerAddress 10.30.5.9, dL-gTP-TEID 0x00D1A2
                        E-RAB-ID 6: dL-TransportLayerAddress 10.30.5.9, dL-gTP-TEID 0x00D1A3
                    id-Target-ToSource-TransparentContainer: 168 bytes (RRCConnectionReconfiguration)

Reading the S1 preparation in an eNB log

On the source eNB, the whole preparation phase collapses into a short handover-manager trace: the decision to go S1, the HandoverRequired it sent, and the HandoverCommand it got back with the target-built RRC container. This is the trace you reach for when a handover "never leaves the source."

Representative eNB handover-manager log — illustrative, values vary by vendor/build:

HO_MGR: trigger=A3 measId=1 tgtPCI=310 tgtEnbId=0x00013 x2State=NOT_ESTABLISHED -> proc=S1_HANDOVER S1AP TX HandoverRequired: mmeUeS1apId=0x000045F1 enbUeS1apId=0x0001A2B type=intraLTE cause=ho-desirable-radio dfpa=notAvailable src2tgtContainer=212B S1AP ..waiting.. T_HO_PREP running (timeout 2000ms) S1AP RX HandoverCommand: mmeUeS1apId=0x000045F1 erabFwd={5,6} tgt2srcContainer=168B [prep OK, 98ms] RRC: extracted RRCConnectionReconfiguration (mobilityControlInfo tgtPCI=310 cRNTI=0x4E21 preambleIdx=23 t304=ms1000)

Field	Meaning	Example	Check
`x2State`	X2 association state to the resolved target eNB.	`NOT_ESTABLISHED`	Confirms why S1 (not X2) was selected; if it says `ESTABLISHED` the eNB should have used X2 — a policy/config anomaly.
`proc`	Handover procedure selected.	`S1_HANDOVER`	Must match the interface you are debugging; a mismatch means you are reading the wrong flow.
`dfpa`	Direct Forwarding Path Availability sent in `HandoverRequired`.	`notAvailable`	Drives direct vs indirect (via S-GW) data forwarding; must agree with the transport reality.
`src2tgtContainer`	Size of the Source-to-Target Transparent Container.	`212B`	Empty/zero size means the source RRC context was not built — the target cannot construct the HO command.
`T_HO_PREP`	Handover preparation supervision timer at the source.	`2000ms`	Expiry with no `HandoverCommand` = preparation failed at MME/target; the handover is abandoned.
`tgt2srcContainer`	Target-to-Source container carrying the RRC HO command.	`168B`	Its presence proves the target admitted the UE and built the reconfiguration; absence means admission failure.
prep latency	Time from `HandoverRequired` to `HandoverCommand`.	`98ms`	Unusually high latency points at MME/target load or S1-MME transport delay.

✅ Debugging steps

Verify the source eNB actually transmitted HandoverRequired on S1-MME and that SCTP (PPID 18, port 36412) to the MME is up.
Confirm the MME resolved the Target ID and reached the correct target eNB with HandoverRequest (inter-MME: check the S10 Forward Relocation Request/Response).
Check the target's admission result — every needed E-RAB in the E-RAB Admitted List, especially the GBR VoLTE bearer; a bearer in the Failed list narrows the cause.
Confirm the Target-to-Source Transparent Container arrived and decodes to a valid RRCConnectionReconfiguration with mobilityControlInfo.
Watch the preparation timer — if it expires before HandoverCommand, the fault is on the MME/target side, not the source.

⚠ Common causes of failure

S1-MME/SCTP transport down or congested, so HandoverRequired or HandoverCommand is lost.
Target admission control rejects a bearer (no radio/GBR resources), returning it in the Failed list or rejecting the request.
Security context mismatch — wrong NCC/KeNB* so the target cannot derive valid AS keys.
Inter-MME S10 failure (no Forward Relocation Response) when the target is under a different MME.
Malformed or empty transparent container, so the target cannot build (or the source cannot deliver) the RRC command.

Phase C — Execution (Steps 9–13)

With preparation complete, the source eNB commands the UE to synchronise to the target using mobilityControlInfo. PDCP SN status is transferred so AM bearers stay lossless, buffered downlink data is forwarded to the target, the UE detaches and performs contention-free RACH, and finally confirms the reconfiguration on the new C-RNTI. From the moment the UE receives the command it is supervised by timer t304.

Step 9RRCConnectionReconfiguration (mobilityControlInfo)Source eNB → UE · LTE-Uu

What happens

The source eNB delivers the target-built RRCConnectionReconfiguration to the UE on SRB1 — this is the handover command. Its mobilityControlInfo carries targetPhysCellId 310, the target carrierFreq, the new C-RNTI in newUE-Identity, the handover supervision timer t304, and rach-ConfigDedicated with the reserved preamble for contention-free access. A securityConfigHO element carries the nextHopChainingCount (NCC 3) that tells the UE how to derive the new AS keys. On receiving it the UE starts t304, applies the configuration, and begins synchronising to the target cell; the source stops scheduling new grants for this UE.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
rrc-TransactionIdentifier	1	Identifies this RRC reconfiguration transaction
mobilityControlInfo.targetPhysCellId	310	Target physical cell identity to synchronise to
mobilityControlInfo.carrierFreq (EARFCN)	1850 (Band 3, 1842.5 MHz DL)	Target carrier frequency the UE must retune to
newUE-Identity	C-RNTI 0x4E21	UE's new identity in the target cell
mobilityControlInfo.t304	ms1000	Timer supervising completion of the handover
rach-ConfigDedicated.ra-PreambleIndex	23	Contention-free preamble to use on the target
rach-ConfigDedicated.ra-PRACH-MaskIndex	0	PRACH resource mask tying the preamble to occasions
securityConfigHO.nextHopChainingCount	3	NCC that drives AS key refresh at the UE (KeNB*)

Packet Capture

No. 90.104000eNB-Source→UELTE RRC98DL-DCCH RRCConnectionReconfiguration (mobilityControlInfo, PCI 310)

LTE Radio Resource Control (RRC) protocol
    DL-DCCH-Message
        message: c1 (0)
            c1: rrcConnectionReconfiguration (3)
                rrcConnectionReconfiguration
                    rrc-TransactionIdentifier: 1
                    criticalExtensions: c1 (0)
                        rrcConnectionReconfiguration-r8
                            mobilityControlInfo
                                targetPhysCellId: 310
                                carrierFreq: dl-CarrierFreq 1850
                                newUE-Identity: 0x4E21 (C-RNTI)
                                t304: ms1000
                                rach-ConfigDedicated: ra-PreambleIndex 23, ra-PRACH-MaskIndex 0
                            securityConfigHO
                                handoverType: intraLTE
                                nextHopChainingCount: 3

Step 10eNB Status Transfer → MME Status TransferSource eNB → MME → Target eNB · S1-MME (S1AP/SCTP)

What happens

For AM DRBs that require lossless handover, the source eNB sends an eNB Status Transfer to the MME carrying the uplink and downlink PDCP SN and Hyper Frame Number (HFN) status per bearer — the UL PDCP receiver status (which PDUs have been received) and the next DL PDCP SN to assign. The MME relays this to the target eNB in an MME Status Transfer. The target uses it to continue PDCP numbering seamlessly, so no packets are lost or duplicated across the switch. This message is only present for bearers configured for PDCP status preservation.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	MME association identity for the UE
eNB UE S1AP ID	0x0001A2B	Source eNB's UE S1AP ID
E-RAB Subject to Status Transfer.E-RAB ID	5	AM bearer whose PDCP status is being conveyed
receiveStatusOfULPDCP-SDUs	bitmap (first missing UL SN)	Tells target which UL PDUs were already received
uL-COUNTValue.PDCP-SN	UL SN 3120, HFN 0x0001	Uplink PDCP COUNT to resume from at the target
dL-COUNTValue.PDCP-SN	DL SN 4711, HFN 0x0002	Next downlink PDCP SN the target should assign

Packet Capture

No. 100.105500eNB-Source→MMES1AP104eNBStatusTransfer (E-RAB 5, UL SN 3120 / DL SN 4711)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 104 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-eNBStatusTransfer (24)
            value
                ENBStatusTransfer
                    id-MME-UE-S1AP-ID: 0x000045F1
                    id-eNB-UE-S1AP-ID: 0x0001A2B
                    id-eNB-StatusTransfer-TransparentContainer
                        E-RAB-ID 5
                            uL-COUNTValue: pDCP-SN 3120, hFN 0x0001
                            dL-COUNTValue: pDCP-SN 4711, hFN 0x0002
                            receiveStatusOfULPDCP-SDUs: bitmap present
    [MME relays as MMEStatusTransfer (procedureCode 25) to eNB-Target]

Step 11Data Forwarding (direct or indirect via S-GW)Source eNB → Target eNB / S-GW · GTP-U

What happens

To minimise packet loss during the switch, the source eNB forwards the downlink PDCP SDUs it has buffered or received to the forwarding endpoint given in the Handover Command over GTP-U. With a direct forwarding path the tunnel runs source-to-target; here, because no direct path exists (common in S1 handover without X2), forwarding is indirect and traverses the S-GW, which relays each packet onto the target eNB's DL forwarding TEID. Combined with the PDCP SN status from step 10, this preserves ordering and gives lossless handover for AM bearers.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
Forwarding type	indirect (via S-GW)	No direct eNB-to-eNB path; core relays forwarded data
GTP-U message type	G-PDU (255)	User-plane packet carrying a forwarded PDCP SDU
DL Forwarding TEID (S-GW ingress)	0x00D1A2	Endpoint the source tunnels forwarded DL PDUs to
Forwarding endpoint IP	10.30.5.9 (S-GW) → 10.40.9.4 (target)	Indirect path: source → S-GW → target eNB
Forwarded PDCP SN	DL SN 4711, HFN 0x0002	Preserves ordering, matching the status transfer
End Marker handling	expected on old S1-U path	Marks last DL packet before the path switch completes
Number of forwarded DL PDUs	~86 PDCP SDUs	In-flight/buffered packets relayed to the target

Packet Capture

No. 110.106000eNB-Source→S-GWGTP-U1332G-PDU TEID=0x00D1A2 (indirect fwd, E-RAB 5)

GPRS Tunneling Protocol
    Flags: 0x30 (version 1, PT 1)
    Message Type: G-PDU (255)
    Length: 1320
    TEID: 0x00D1A2
    T-PDU (forwarded DL PDCP SDU)
        PDCP: DL SN 4711, HFN 0x0002
        [E-RAB 5 / QCI 9 user data]
    [S-GW relays to eNB-Target 10.40.9.4, TEID 0x00C7A1]

Step 12Detach + RACH to Target + RRCConnectionReconfigurationCompleteUE → Target eNB · LTE-Uu

What happens

The UE detaches from the source cell, retunes to the target carrier, acquires PCI 310, and performs contention-free random access using the dedicated preamble index 23 from rach-ConfigDedicated. The target eNB detects the preamble and returns a MAC-LTE Random Access Response (RAR) with a Timing Advance command and an uplink grant for Msg3; because the preamble is dedicated, no contention resolution is needed. The UE then sends RRCConnectionReconfigurationComplete on SRB1 using its new C-RNTI 0x4E21, stops timer t304, and the handover is complete on the radio side. The target eNB can now resume downlink scheduling.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
ra-PreambleIndex (dedicated)	23	Contention-free preamble assigned in step 9
RA-RNTI	0x0011	RNTI computed from the PRACH time/frequency occasion
RAR.Timing Advance Command	31	Initial timing advance for UE UL alignment
RAR.UL Grant	~56 bits (Msg3 allocation)	Uplink grant for RRCConnectionReconfigurationComplete
RAR.Temp C-RNTI / C-RNTI	0x4E21	Confirms the C-RNTI assigned for the target cell
rrc-TransactionIdentifier	1	Matches the transaction from step 9
t304 status	stopped (success)	Handover supervision timer cleared on completion
LCID	1 (SRB1)	Logical channel carrying the handover confirm

Packet Capture

No. 120.150000UE→eNB-TargetLTE RRC40UL-DCCH RRCConnectionReconfigurationComplete (C-RNTI 0x4E21)

MAC-LTE
    Radio Network Temporary Identifier (RNTI): 0x4E21 (C-RNTI)
    LCID: 1 (SRB1)
    [preceded by MAC RAR: RAPID 23, TA 31, Temp C-RNTI 0x4E21]
LTE Radio Resource Control (RRC) protocol
    UL-DCCH-Message
        message: c1 (0)
            c1: rrcConnectionReconfigurationComplete (1)
                rrcConnectionReconfigurationComplete
                    rrc-TransactionIdentifier: 1
                    criticalExtensions: rrcConnectionReconfigurationComplete-r8

Step 13S1AP HANDOVER NOTIFYTarget eNB → MME · S1-MME (S1AP/SCTP)

What happens

Having confirmed the UE on the radio, the target eNB sends HANDOVER NOTIFY to the (target) MME indicating the UE has successfully arrived and reporting its current location — the E-UTRAN Cell Global Identifier (ECGI) and the TAI. This message triggers the core-network path switch so that downlink user data is routed to the target eNB, and it authorises the eventual release of source resources.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	Correlates the notify to the UE's MME association
eNB UE S1AP ID	0x0002C77	Target eNB's UE S1AP ID
E-UTRAN CGI (ECGI)	PLMN 310-410, Cell ID 0x0013001	Cell where the UE has landed (E-UTRAN cell global id)
TAI	PLMN 310-410, TAC 0x0A2C	Tracking area of the target cell

Packet Capture

No. 130.158000eNB-Target→MMES1AP96HandoverNotify (eNB-UE 0x2C77, ECGI 0x0013001)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 96 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-HandoverNotification (2)
            value
                HandoverNotify
                    id-MME-UE-S1AP-ID: 0x000045F1
                    id-eNB-UE-S1AP-ID: 0x0002C77
                    id-EUTRAN-CGI: PLMN 310-410, cell-ID 0x0013001
                    id-TAI: PLMN 310-410, TAC 0x0A2C

✅ Debugging steps

Confirm the source actually delivered the RRCConnectionReconfiguration (HO command) to the UE and that the UE started t304.
Check the contention-free RACH at the target: the UE should use the dedicated ra-PreambleIndex (23) and the target should detect it — a fallback to contention-based RACH is a red flag.
Verify the target received RRCConnectionReconfigurationComplete on the new C-RNTI before t304 expiry.
For lossless AM bearers, confirm the eNB/MME Status Transfer carried the PDCP SN/HFN and that data forwarding (direct or indirect via S-GW) actually flowed.
Confirm HandoverNotify reached the MME so the path switch is triggered.

⚠ Common causes of failure

t304 expiry — the UE cannot sync to the target cell (weak target RSRP, wrong targetPhysCellId/carrierFreq), triggering handover failure and re-establishment.
Dedicated preamble/RACH mismatch, so the UE's Msg1 is not detected at the target.
Wrong AS keys at the target (bad nextHopChainingCount), so RRCConnectionReconfigurationComplete fails integrity check.
Forwarding tunnel not set up or PDCP status missing, causing packet loss or reordering gaps during the switch.

Phase D — Path Switch & Release (Steps 14–16)

The final phase moves the downlink bearer path to the target and tears down the source. The MME instructs the S-GW to switch the DL path with a Modify Bearer procedure (end markers flush the old path), the inter-MME case completes the relocation over S10, and once the relocation-overall timer expires the MME releases the source eNB's UE context.

Step 14Modify Bearer Request / ResponseMME ↔ S-GW · S11 (GTPv2-C)

What happens

On receiving HANDOVER NOTIFY, the MME sends a GTPv2-C Modify Bearer Request to the S-GW over S11, providing the target eNB's downlink S1-U endpoints (address and TEID) for each bearer. The S-GW updates its downlink forwarding so fresh DL user data now flows to the target eNB rather than the source, and sends one or more end-marker packets on the old S1-U path so the target can order the last forwarded packets ahead of new traffic. The S-GW then replies with Modify Bearer Response confirming the switch. If the S-GW is also relocated, the MME instead uses Create Session toward the new S-GW.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
Message Type	Modify Bearer Request (34)	GTPv2-C message that switches the DL bearer path
TEID (S-GW control)	0x00AB12CD	S-GW S11 control endpoint for this PDN connection
Bearer Context.EBI	5, 6	Bearers whose DL S1-U path is being switched
E-RAB 5 DL S1-U F-TEID (target)	eNB 10.40.9.4, TEID 0x00B2D5E6	New DL endpoint at target the S-GW must send data to
E-RAB 6 DL S1-U F-TEID (target)	eNB 10.40.9.4, TEID 0x00B2D5E7	New DL endpoint for the VoLTE bearer
End Marker	sent on old S1-U path	Flushes the source path so target orders last packets
Cause (in Response)	Request accepted (16)	Confirms DL path now terminates at the target eNB

Packet Capture

No. 140.161000MME→S-GWGTPv2-C120Modify Bearer Request (EBI 5,6 → target 10.40.9.4)

GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2, T 1)
    Message Type: Modify Bearer Request (34)
    Message Length: 116
    TEID: 0x00AB12CD
    Sequence Number: 0x0000A3
    Bearer Context: EBI 5
        F-TEID (S1-U eNB DL): IPv4 10.40.9.4, TEID 0x00B2D5E6
    Bearer Context: EBI 6
        F-TEID (S1-U eNB DL): IPv4 10.40.9.4, TEID 0x00B2D5E7
    [S-GW switches DL path, emits End Marker on old S1-U, replies Modify Bearer Response (35)]

Step 15Forward Relocation Complete Notification / Acknowledge (inter-MME only)Target MME → Source MME · S10 (GTPv2-C) · OPTIONAL

What happens

Applicable only in the inter-MME case. After the path switch, the target MME sends a GTPv2-C Forward Relocation Complete Notification to the source MME over S10 to signal that the UE has successfully relocated. The source MME acknowledges with Forward Relocation Complete Acknowledge and starts a timer (TS1relocoverall / TimerGTPMME) after which it will release the source eNB. In the intra-MME main flow there is no second MME, so this exchange does not occur and the single MME proceeds straight to the source release.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
Message Type	Forward Relocation Complete Notification (135)	Signals successful UE relocation to the source MME
TEID	0x0000C0DE	Source MME S10 control endpoint
Ack Message Type	Forward Relocation Complete Acknowledge (136)	Source MME confirmation of the notification
Cause (in Ack)	Request accepted (16)	Confirms the relocation is complete end to end
Timer started	TS1relocoverall (TimerGTPMME)	Guards source-context release after relocation

Packet Capture

No. 150.170000MME-Target→MME-SourceGTPv2-C72Forward Relocation Complete Notification [inter-MME]

GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2, T 1)
    Message Type: Forward Relocation Complete Notification (135)
    Message Length: 68
    TEID: 0x0000C0DE
    Sequence Number: 0x000013
    [Source MME replies Forward Relocation Complete Acknowledge (136), Cause 16]
    [Source MME starts TS1relocoverall before releasing source eNB]

Step 16S1AP UE CONTEXT RELEASE COMMAND / COMPLETEMME → Source eNB · S1-MME (S1AP/SCTP)

What happens

Once the relocation-overall timer (TS1relocoverall / TimerGTPMME) expires — giving forwarded data time to drain — the MME sends UE CONTEXT RELEASE COMMAND to the source eNB with a Cause of successful-handover. The source eNB tears down the UE's radio bearers, the S1 and forwarding tunnels, and the RRC context, then replies with UE CONTEXT RELEASE COMPLETE. Any temporary indirect-forwarding tunnels through the S-GW are then torn down. This closes the S1 handover procedure end to end.

Key IEs & Parameters

IE / Field	Example Value	Why it matters
MME UE S1AP ID	0x000045F1	Identifies the UE association to release at the source
eNB UE S1AP ID	0x0001A2B	Source eNB's UE S1AP ID being released
Cause	radioNetwork: successful-handover	Reason for releasing the source context
Timer before release	TS1relocoverall (TimerGTPMME) expired	Ensured forwarded data drained before teardown
UE Context Release Complete	eNB confirms resources freed	Source radio/S1/forwarding resources released

Packet Capture

No. 160.180000MME→eNB-SourceS1AP88UEContextReleaseCommand (eNB-UE 0x1A2B, successful-handover)

Stream Control Transmission Protocol, Src Port: 36412 (36412), Dst Port: 36412 (36412)
    DATA chunk (ordered, payload length 88 bytes, PPID: S1AP (18))
S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-UEContextRelease (23)
            value
                UEContextReleaseCommand
                    id-UE-S1AP-IDs: uE-S1AP-ID-pair
                        mME-UE-S1AP-ID: 0x000045F1
                        eNB-UE-S1AP-ID: 0x0001A2B
                    id-Cause: radioNetwork (0): successful-handover
    [eNB-Source replies UEContextReleaseComplete (successfulOutcome, procedureCode 23)]

✅ Debugging steps

Confirm the MME sent Modify Bearer Request to the S-GW on S11 and received Modify Bearer Response (Cause accepted) — the DL path only moves once this completes.
Check that end markers were emitted on the old S1-U path so the target can order the last forwarded packets ahead of fresh traffic.
Verify the source received UE Context Release Command with cause successful-handover and replied UE Context Release Complete; a lingering source context leaks resources.
Confirm any indirect-forwarding tunnels through the S-GW were torn down after the release.
Inter-MME: check the S10 Forward Relocation Complete Notification/Acknowledge and that TS1relocoverall expired before release.

⚠ Common causes of failure

Path switch fails or is delayed at the S-GW, so downlink data keeps going to the source (packet loss / stall after the UE has moved).
Missing end markers, causing out-of-order delivery or duplicate detection problems at the target.
Source context not released (lost UE Context Release Command), leaking radio/S1/forwarding resources.
Release fired too early (timer misconfigured), cutting off still-draining forwarded data.
Inter-MME S10 relocation-complete exchange lost, so the source MME never releases the old context.

🔀

LTE ↔ NR: the S1 handover maps almost one-for-one onto NR's N2 (NGAP) handover. The RAN nodes become gNBs; the MME becomes the AMF and the S-GW becomes the UPF. HANDOVER REQUIRED/HANDOVER REQUEST/HANDOVER COMMAND become NGAP HANDOVER REQUIRED/HANDOVER REQUEST/HANDOVER COMMAND; the RRC handover command is RRCReconfiguration with reconfigurationWithSync (carrying newUE-Identity, t304, rach-ConfigDedicated) instead of RRCConnectionReconfiguration with mobilityControlInfo; and the path switch is done by the SMF/UPF via PDU-session modification rather than a Modify Bearer Request on S11. The direct-interface fast path is Xn in NR (the analogue of X2), and Forward Relocation over S10 becomes AMF-to-AMF relocation over N14. The core idea — when there is no direct RAN interface, the core relays the whole preparation — is identical.

Summary

S1 handover is LTE's core-relayed mobility path for when X2 does not exist between the source and target eNB. Walk it in four phases: (A) Measurement & Decision — an A3 MeasurementReport triggers the source, which finds no X2 and selects S1; (B) Preparation via MME — HANDOVER REQUIRED → HANDOVER REQUEST → admission → HANDOVER REQUEST ACKNOWLEDGE → HANDOVER COMMAND, with the target-built RRCConnectionReconfiguration carried in transparent containers (plus S10 Forward Relocation when inter-MME); (C) Execution — the UE retunes under t304, does contention-free RACH with the dedicated preamble, and confirms with RRCConnectionReconfigurationComplete, while PDCP status transfer and data forwarding keep AM bearers lossless; (D) Path Switch & Release — HANDOVER NOTIFY triggers the S-GW Modify Bearer, end markers flush the old path, and the source context is released.

The fastest way to root-cause a handover failure is the same discipline the RACH page preaches: find the first message that broke. No HandoverCommand back → suspect preparation (MME/target admission, S1-MME transport, security context). t304 expiry → suspect the over-the-air execution (target coverage, dedicated RACH, AS keys). DL stall after the UE moved → suspect the path switch (S11 Modify Bearer, end markers). Each step points at a small, distinct set of causes, so knowing where it broke usually tells you why.

Q&A — X2 vs S1 Handover

Q&A Q&A — X2 vs S1 Handover

Q. What's the actual deciding factor for whether LTE uses X2 handover vs. S1 handover for a given mobility event?

A. Same logic as 5G's Xn vs N2: if a direct X2 interface exists between source and target eNB (and no MME/S-GW relocation is needed), X2 is used for speed. If there's no X2 link (e.g., handover between eNBs from different vendors without X2 configured, or across MME pool boundaries), it falls back to S1 handover routed through the MME.

Q. Why does S1 handover sometimes require an S-GW relocation while X2 handover never does?

A. X2 handover keeps the S-GW anchor unchanged — only the radio side moves, so the core user-plane path is untouched. S1 handover can span MME pool areas or serving-gateway service areas, so the MME may decide (based on target eNB's associated S-GW) that a different S-GW is topologically more efficient, triggering an S-GW relocation as part of the same procedure — something X2's gNB-only signalling scope can't decide or execute.

Related call flows & topics

Step back for the bigger picture and compare the direct RAN path.

Handover OverviewX2-based HandoverS1AP (S1-MME — eNB ↔ MME)

S1-based Handover (with exact IEs) in LTE 4G

Introduction

On this page

Why S1 handover is needed

Call flow

Call flow at a glance

Phase A — Measurement & Decision (Steps 1–2)

✅ Debugging steps

⚠ Common causes of failure

Phase B — S1 Preparation via MME (Steps 3–8)

Reading the S1 preparation in an eNB log

✅ Debugging steps

⚠ Common causes of failure

Phase C — Execution (Steps 9–13)

✅ Debugging steps

⚠ Common causes of failure

Phase D — Path Switch & Release (Steps 14–16)

✅ Debugging steps

⚠ Common causes of failure

Summary

Q&A — X2 vs S1 Handover

Related call flows & topics