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

Introduction

This document describes the complete signalling flow for a contention-free, intra-MME X2-based handover in an LTE/E-UTRAN network, in which a UE in RRC_CONNECTED is moved from a source eNB to a neighbouring target eNB that share a direct X2 interface and are anchored to the same MME and Serving Gateway. The source eNB configures event-A3 measurements over LTE-Uu and, upon receiving a MeasurementReport indicating that a neighbour cell has become an offset better than the serving cell, decides to hand the UE over and prepares the target directly across X2-C without involving the EPC for preparation. The target performs admission control, allocates a C-RNTI and a dedicated RACH preamble, and returns a Target eNB To Source eNB Transparent Container carrying the RRCConnectionReconfiguration handover command. After the UE detaches, performs contention-free RACH to the target, and sends RRCConnectionReconfigurationComplete, the target switches the S1-U downlink path via the S1AP Path Switch procedure toward the MME/S-GW and finally triggers X2AP UE Context Release toward the source. Lossless handover of RLC-AM bearers is achieved through X2AP SN Status Transfer and GTP-U data forwarding over X2-U. The behaviour follows 3GPP TS 36.300 (overall procedure), TS 36.423 (X2AP), and TS 36.331 (RRC).

X2 handover is the workhorse of intra-LTE mobility. Wherever two eNBs are neighbours and an operator has provisioned a direct X2 interface between them, this is the path a normal coverage or load handover takes — it is faster and lighter than routing preparation through the core, because the eNBs negotiate the move themselves and touch the MME only once, at the very end, to repoint the user-plane. It sits directly on the generic handover spine; here that spine is filled in with the exact X2AP and S1AP messages.

Why X2 handover exists

Concretely, X2 handover exists to make inter-eNB mobility fast and to keep the core network out of the critical path. Because the source prepares the target directly over X2-C and forwards in-flight data directly over X2-U, the interruption is short and the EPC is involved only for the final Path Switch. This matters because handovers happen constantly at cell edges; doing preparation eNB-to-eNB avoids the extra round trips and MME load that an S1 handover incurs. X2 handover is always intra-MME — if the target is under a different MME, or no X2 exists, the network must fall back to S1 handover instead.

Call flow

The message-sequence chart below shows an intra-MME X2 handover end to end: the source eNB prepares the target directly over X2, commands the UE to retune, and only afterwards touches the core to switch the downlink path and release the source.

1. MeasurementReport (event A3) — the UE reports a neighbour has become offset-better than the serving cell.
2. Handover Request (X2AP) — the source eNB prepares the target directly over X2, passing the UE context and E-RABs.
3. Handover Request Acknowledge — the target admits the bearers and returns the RRC handover command in a transparent container.
4. RRCConnectionReconfiguration with mobilityControlInfo — the source commands the UE to retune to the target.
5. SN Status Transfer plus GTP-U data forwarding over X2-U keep AM bearers lossless.
6. The UE performs contention-free RACH and confirms with RRCConnectionReconfigurationComplete to the target.
7. Path Switch Request (S1AP) — the target asks the MME to move the downlink path to itself.
8. The MME switches the path at the S-GW with Modify Bearer Request/Response.
9. Path Switch Request Acknowledge — the MME confirms and supplies fresh NCC/security context.
10. UE Context Release (X2AP) — the target tells the source to free the UE context and forwarding tunnels.

Call flow at a glance

Phase A — Measurement & Decision

The source eNB has previously configured the UE for event-triggered mobility measurements. When a neighbour cell becomes sufficiently stronger than the serving cell, the UE sends a MeasurementReport, and the source eNB's radio resource management turns that report into a handover decision. Because a direct X2 interface exists to the target eNB and both eNBs share the same MME and S-GW, the source can prepare the target itself over X2-C, keeping the core out of the loop until the final path switch.

Earlier in the connection the source eNB provisioned the UE with a measurement configuration inside an RRCConnectionReconfiguration, comprising a measObjectEUTRA (the EARFCN and neighbour list of the frequency to monitor), a reportConfigEUTRA carrying event A3 (neighbour becomes an offset better than the serving cell), and a measId that binds the object to the report. The UE performs L3 filtering on RSRP/RSRQ of detected cells and starts the timeToTrigger timer when the A3 entering condition (Mn + Ofn + Ocn − Hys > Ms + Ofs + Ocs + Off) is satisfied. When the condition persists for the whole timeToTrigger, the UE sends a MeasurementReport on SRB1 carrying the measId and the measResults for the serving cell and the best neighbour. This report is the trigger that leads the source eNB to run its handover decision algorithm; here the neighbour PCI 288 has become roughly 10 dB stronger than serving PCI 150.

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 45 (-95dBm), rsrqResult 17 (-11dB)
                                measResultNeighCells: measResultListEUTRA (0)
                                    MeasResultEUTRA: physCellId 288
                                        measResult: rsrpResult 55 (-85dBm), rsrqResult 21 (-9dB)

The source eNB feeds the MeasurementReport into its mobility/RRM algorithm. It checks that PCI 288 maps to a known neighbour relation with a usable X2 interface (via the Automatic Neighbour Relation table), verifies the target cell is served by the same MME and S-GW, and applies any cell-individual offsets, load, and hysteresis policy. Having confirmed the neighbour is a valid, stronger target, it decides on an X2-based handover rather than an S1 handover, derives the fresh access-stratum key material (KeNB* from the current KeNB and the target PCI/EARFCN, plus the Next Hop Chaining Count), and prepares to send the X2AP HANDOVER REQUEST. This step is entirely internal to the source eNB and produces no over-the-air or inter-node message; it is shown here for completeness of the flow.

eNB Radio Resource Management (internal L3 trace)
    Mobility event: A3 report accepted (measId 1)
        serving: PCI 150, RSRP -95 dBm
        best neighbour: PCI 288, RSRP -85 dBm (margin 10 dB)
    Neighbour relation: PCI 288 => ECGI 001-01-0x0112203
        x2-link: UP, noHO false, noX2 false
        mme-check: same MME (GUMMEI 001-01-8001-01)
    Decision: trigger X2 handover
        derive KeNB* (target PCI 288, EARFCN 1850), NCC 3
        next action: X2AP HandoverRequest

Phase B — X2 Preparation

The source eNB runs the X2AP Handover Preparation procedure directly with the target eNB. It sends a HANDOVER REQUEST carrying the full UE context and E-RAB list, the target admits the bearers and allocates radio resources, and the target returns a HANDOVER REQUEST ACKNOWLEDGE containing the handover command as an opaque transparent container. No EPC signalling occurs in this phase.

The source eNB initiates handover preparation by sending an X2AP HANDOVER REQUEST to the target eNB across X2-C. This single message carries everything the target needs to admit the UE: the Old eNB UE X2AP ID that identifies the UE on the source side, a Cause, the Target Cell ID (target ECGI), the GUMMEI of the serving MME, and a full UE Context Information block. Inside that context are the MME UE S1AP ID, the UE Security Capabilities, the AS Security Information (the freshly derived KeNB* and the NCC), the UE Aggregate Maximum Bit Rate, the RRC context, and the E-RABs To Be Setup List. Each E-RAB entry gives the E-RAB ID, the E-RAB Level QoS Parameters (QCI plus Allocation and Retention Priority, and for GBR bearers the GBR/MBR bit rates), and the S-GW's uplink GTP tunnel endpoint (transport-layer address plus GTP-TEID) so the target knows where to send uplink user data. The RRC Context field carries a HandoverPreparationInformation container with the UE's radio capabilities and current AS configuration.

Stream Control Transmission Protocol, Dst Port: 36422 (36422)
    DATA chunk (ordered, complete segment)
        Payload protocol identifier: X2AP (27)
X2 Application Protocol
    X2AP-PDU: initiatingMessage (0)
        procedureCode: id-handoverPreparation (0)
        HandoverRequest
            Old eNB UE X2AP ID: 161
            Cause: radioNetwork (handover-desirable-for-radio-reasons)
            targetCell-ID (ECGI): PLMN 001-01, ECI 0x0112203
            GUMMEI: PLMN 001-01, MMEGI 0x8001, MMEC 0x01
            UE Context Information
                MME UE S1AP ID: 69
                UESecurityCapabilities: EEA0/1/2, EIA1/2
                AS-SecurityInformation: KeNB* (256 bits), NCC 3
                E-RABs ToBeSetup: E-RAB ID 5 (QCI 9, ARP 9), UL-GTP 10.20.30.40 TEID 0x00A1F301
                E-RABs ToBeSetup: E-RAB ID 6 (QCI 1, ARP 2, GBR/MBR 128k), UL-GTP TEID 0x00A1F302
                RRC-Context: HandoverPreparationInformation (207 octets)

The target eNB runs admission control against the requested E-RABs and their QoS. For the GBR bearer (E-RAB 6, QCI 1) it verifies that the guaranteed bit rate can be reserved on the air interface and transport; for the non-GBR bearer (E-RAB 5, QCI 9) it admits it under the UE-AMBR budget. It then allocates a new C-RNTI for the UE in the target cell and reserves a dedicated contention-free RACH preamble and PRACH mask so the incoming UE can access the cell without contention. Finally it builds the RRCConnectionReconfiguration handover command containing mobilityControlInfo and stores the resulting DL/UL data-forwarding tunnel endpoints. Like the source's HO decision, this step is internal to the target eNB and generates no inter-node message; its outputs are returned to the source in the next step.

eNB Admission Control (internal L3 trace)
    HandoverRequest received: Old X2AP ID 161, ECGI 001-01-0x0112203
    Connection Admission Control
        E-RAB 5 (QCI 9, non-GBR): admit under UE-AMBR
        E-RAB 6 (QCI 1, GBR 128k): reserve GBR, admit
    Radio resource allocation
        C-RNTI: 0x5C7A
        rach-ConfigDedicated: ra-PreambleIndex 34, ra-PRACH-MaskIndex 0
    Data forwarding tunnels (X2-U)
        E-RAB 5: DL-forward TEID 0x00B2C401
        E-RAB 6: DL-forward TEID 0x00B2C402
    Build RRCConnectionReconfiguration (mobilityControlInfo) => transparent container

The target eNB replies with a HANDOVER REQUEST ACKNOWLEDGE that completes the preparation phase. It carries the New eNB UE X2AP ID it has allocated for this UE, the E-RABs Admitted List (each entry giving the target's DL GTP tunnel endpoint and, where forwarding is proposed, the UL/DL forwarding GTP tunnel endpoints), and the Target eNB To Source eNB Transparent Container. That container wraps the RRCConnectionReconfiguration handover command, which contains mobilityControlInfo with the targetPhysCellId, the newUE-Identity (target C-RNTI), the rach-ConfigDedicated (the dedicated preamble), t304, and the target radioResourceConfigCommon. The source treats the container as opaque: it will forward it to the UE unmodified. Receiving this acknowledge gives the source everything it needs to command the handover.

Stream Control Transmission Protocol, Src Port: 36422 (36422)
    DATA chunk (ordered, complete segment)
        Payload protocol identifier: X2AP (27)
X2 Application Protocol
    X2AP-PDU: successfulOutcome (1)
        procedureCode: id-handoverPreparation (0)
        HandoverRequestAcknowledge
            Old eNB UE X2AP ID: 161
            New eNB UE X2AP ID: 183
            E-RABs Admitted: E-RAB ID 5 (DL-GTP TEID 0x00C05001, DL-fwd TEID 0x00B2C401)
            E-RABs Admitted: E-RAB ID 6 (DL-GTP TEID 0x00C05002, DL-fwd TEID 0x00B2C402)
            TargeteNBtoSourceeNBTransparentContainer
                RRCConnectionReconfiguration: mobilityControlInfo
                    targetPhysCellId: 288
                    newUE-Identity (C-RNTI): 0x5C7A
                    rach-ConfigDedicated: ra-PreambleIndex 34, ra-PRACH-MaskIndex 0
                    t304: ms1000

Phase C — HO Execution

With the target prepared, the source commands the handover by delivering the transparent RRCConnectionReconfiguration to the UE, transfers PDCP status and forwards in-flight data for lossless AM bearers, and the UE detaches from the source, performs contention-free RACH to the target, and confirms completion.

The source eNB takes the Target eNB To Source eNB Transparent Container received in step 5 and delivers it to the UE as an RRCConnectionReconfiguration on SRB1, integrity-protected and ciphered with the current source AS keys. The decisive element is mobilityControlInfo, which instructs the UE to synchronise to the target cell: it contains the targetPhysCellId, the target carrierFreq, the newUE-Identity (target C-RNTI), the target radioResourceConfigCommon, the rach-ConfigDedicated (dedicated preamble and PRACH mask for contention-free access), and the t304 supervision timer. The securityConfigHO carries the nextHopChainingCount so the UE can derive the target AS keys. On receiving it the UE starts t304, applies the target configuration, derives KeNB and the target KRRCint/KRRCenc/KUPenc, and detaches from the source cell. This is the point at which the UE is committed to leaving the source.

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: 288
                                carrierFreq: dl-CarrierFreq 1850
                                newUE-Identity (C-RNTI): 0x5C7A
                                t304: ms1000
                                rach-ConfigDedicated: ra-PreambleIndex 34, ra-PRACH-MaskIndex 0
                            securityConfigHO: nextHopChainingCount 3

For lossless handover of RLC-AM bearers, the source eNB sends an X2AP SN STATUS TRANSFER so the target can continue PDCP numbering without loss or duplication. For each bearer in the E-RABs Subject To Status Transfer List it conveys the uplink PDCP receiver status (the next expected UL PDCP SN plus a receiveStatusOfUL-PDCP-SDUs bitmap marking already-received out-of-order SDUs) and the downlink COUNT the target should assign to the first forwarded or new DL PDCP SDU. COUNT values are expressed as HFN concatenated with the PDCP SN. This lets the target reorder uplink data correctly and resume downlink transmission at the exact next COUNT so nothing is duplicated or lost across the move.

Stream Control Transmission Protocol, Src Port: 36422 (36422)
    DATA chunk (ordered, complete segment)
        Payload protocol identifier: X2AP (27)
X2 Application Protocol
    X2AP-PDU: initiatingMessage (0)
        procedureCode: id-snStatusTransfer (4)
        SNStatusTransfer
            Old eNB UE X2AP ID: 161
            New eNB UE X2AP ID: 183
            E-RABs SubjectToStatusTransfer: E-RAB ID 5
                receiveStatusofULPDCP-SDUs: 128 bits (first missing 3301)
                ulCOUNTvalue: HFN 0x002, PDCP-SN 3300 (0x0002CE4)
                dlCOUNTvalue: HFN 0x002, PDCP-SN 4095 (0x0002FFF)
            E-RABs SubjectToStatusTransfer: E-RAB ID 6
                ulCOUNTvalue: HFN 0x000, PDCP-SN 205 (0x00000CD)
                dlCOUNTvalue: HFN 0x000, PDCP-SN 210 (0x00000D2)

Using the DL forwarding tunnel endpoints received in the HANDOVER REQUEST ACKNOWLEDGE, the source eNB tunnels buffered and in-flight downlink PDCP SDUs to the target eNB over X2-U via GTP-U. For AM bearers the source forwards the PDCP SDUs that were not yet acknowledged by the UE, starting from the DL COUNT signalled in the SN Status Transfer, preserving their PDCP sequence numbers so the target can deliver them in order once the UE arrives. Uplink data that the source still receives before the UE detaches may likewise be forwarded to avoid loss. This forwarding overlaps in time with the UE's RACH to the target and continues until the source releases the context; an End Marker eventually closes each forwarding tunnel.

GPRS Tunneling Protocol
    Flags: 0x30 (version 1, PT 1, E 0, S 1)
    Message Type: G-PDU (0xff)
    Length: 1392
    TEID: 0x00b2c401
    Sequence Number: 4095
    T-PDU: forwarded DL PDCP SDU
        E-RAB 5, first forwarded PDCP-SN 4095, total 37 PDUs
        forwarding endpoint 10.60.70.80
        [followed by GTP-U End Marker (0xfe) when buffer drained]

The UE detaches from the source cell, retunes to the target PCI 288 on EARFCN 1850, and performs a contention-free random access using the dedicated resources from rach-ConfigDedicated. It transmits the assigned ra-PreambleIndex on the PRACH occasions selected by the mask (Msg1), and the target eNB responds with a Random Access Response (Msg2/RAR) on PDCCH addressed by the RA-RNTI, containing a Timing Advance command, an uplink grant for Msg3, and a Temporary C-RNTI that equals the C-RNTI already assigned via mobilityControlInfo. Because the preamble is dedicated there is no contention resolution step, so the UE proceeds directly to send its handover confirm. The whole exchange must complete before t304 expires or the UE declares handover failure and attempts RRC re-establishment.

MAC-LTE
    Radio Type: FDD
    Direction: Downlink
    RNTI Type: RA-RNTI
    RNTI: 2 (RA-RNTI 0x0002)
    MAC PDU (DL-SCH)
        Random Access Response (RAR)
            RAPID: 34 (dedicated preamble)
            Timing Advance Command: 31 (~16.1 us)
            UL Grant: 6 PRBs, MCS 4, TPC 0
            Temporary C-RNTI: 0x5c7a

Using the uplink grant from the RAR, the UE sends RRCConnectionReconfigurationComplete to the target eNB as Msg3 on SRB1, now identified by its target C-RNTI 0x5C7A and protected with the newly derived target AS keys. Reception of this message tells the target that the UE has successfully synchronised and applied the handover configuration; the target stops treating the UE as in-transit and resumes SRB/DRB traffic, delivering forwarded and buffered downlink PDCP SDUs in order. The UE stops timer t304. From this moment the UE is fully served by the target eNB on the air interface, and the target proceeds to switch the core-network user-plane path via S1AP.

LTE Radio Resource Control (RRC) protocol
    UL-DCCH-Message
        message: c1 (0)
            c1: rrcConnectionReconfigurationComplete (2)
                rrcConnectionReconfigurationComplete
                    rrc-TransactionIdentifier: 1
                    criticalExtensions: rrcConnectionReconfigurationComplete-r8 (0)
                        rrcConnectionReconfigurationComplete-r8
                            [C-RNTI: 0x5C7A]
                            [SRB: SRB1, PDCP-SN 0, integrity EIA2]

Phase D — Path Switch & Release

Now that the UE is on the target cell, the target eNB switches the S1-U downlink user-plane away from the source by running the S1AP Path Switch procedure with the MME, which in turn asks the S-GW to repoint the bearer path over S11. The MME returns a fresh security parameter for the next handover, and the target finally tells the source to release the UE context over X2.

Having taken over the UE on the radio side, the target eNB initiates the S1AP Path Switch Request procedure toward the MME to redirect the downlink S1-U user-plane from the source eNB to itself. The message carries the target's eNB UE S1AP ID, the MME UE S1AP ID that identifies the UE's S1 context, the E-RAB To Be Switched in Downlink List (each entry giving the target eNB's Transport Layer Address and GTP-TEID for the downlink), the serving EUTRAN CGI (ECGI) and TAI, and the UE Security Capabilities. This is the only EPC interaction in an X2 handover and it happens after the radio handover has already succeeded.

Stream Control Transmission Protocol, Dst Port: 36412 (36412)
    DATA chunk (ordered, complete segment)
        Payload protocol identifier: S1AP (18)
S1 Application Protocol
    S1AP-PDU: initiatingMessage (0)
        procedureCode: id-PathSwitchRequest (3)
        PathSwitchRequest
            eNB-UE-S1AP-ID: 167
            E-RABToBeSwitchedDLList
                E-RAB ID 5: transportLayerAddress 10.60.70.90, GTP-TEID 0x00C05001
                E-RAB ID 6: transportLayerAddress 10.60.70.90, GTP-TEID 0x00C05002
            sourceMME-UE-S1AP-ID: 69
            EUTRAN-CGI: PLMN 001-01, ECI 0x0112203
            TAI: PLMN 001-01, TAC 0x0001
            UESecurityCapabilities: EEA0/1/2, EIA1/2

On receiving the Path Switch Request, the MME asks the Serving Gateway to switch the downlink S1-U path by sending a GTPv2-C Modify Bearer Request over S11, carrying the target eNB's S1-U F-TEID(s) as the new downlink endpoints for each bearer. The S-GW updates its bearer context so that downlink packets now flow to the target eNB and, to help the target reorder any last in-flight packets, sends one or more GTP-U End Marker packets on the old S1-U path toward the source eNB. It then returns a Modify Bearer Response confirming the switched bearers. Because this is an intra-S-GW handover the S-GW's own uplink F-TEID is unchanged, so the uplink endpoint the target uses stays the same.

GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2, P 0, T 1)
    Message Type: Modify Bearer Request (34)
    TEID: 0x0000e202
    Sequence Number: 0x000311
    Bearer Context (EBI 5)
        EPS Bearer ID (EBI): 5
        F-TEID (S1-U eNodeB): 10.60.70.90, TEID 0x00C05001
    Bearer Context (EBI 6)
        EPS Bearer ID (EBI): 6
        F-TEID (S1-U eNodeB): 10.60.70.90, TEID 0x00C05002
    [S-GW sends GTP-U End Marker on old path, then Modify Bearer Response cause 16]

With the downlink path switched at the S-GW, the MME returns an S1AP PATH SWITCH REQUEST ACKNOWLEDGE to the target eNB. It confirms the switched E-RABs and, if the S-GW's uplink endpoint changed, supplies the new UL S1-U transport address and GTP-TEID (unchanged here for an intra-S-GW handover). Crucially it carries the updated Security Context, including a new Next Hop parameter (NH) and an incremented Next Hop Chaining Count (NCC = 4) that the target will use as the security base for the UE's next handover. With this acknowledgement the user plane is fully anchored on the target and the EPC-side relocation is complete.

Stream Control Transmission Protocol, Src Port: 36412 (36412)
    DATA chunk (ordered, complete segment)
        Payload protocol identifier: S1AP (18)
S1 Application Protocol
    S1AP-PDU: successfulOutcome (1)
        procedureCode: id-PathSwitchRequest (3)
        PathSwitchRequestAcknowledge
            MME-UE-S1AP-ID: 69
            eNB-UE-S1AP-ID: 167
            E-RABToBeSwitchedULList
                E-RAB ID 5: transportLayerAddress 10.20.30.40, GTP-TEID 0x00A1F301
                E-RAB ID 6: transportLayerAddress 10.20.30.40, GTP-TEID 0x00A1F302
            SecurityContext
                nextHopChainingCount: 4
                nextHopParameter (NH): 256 bits

Once the path switch is acknowledged and the user plane is confirmed on the target, the target eNB sends an X2AP UE CONTEXT RELEASE to the source eNB, signalling that the handover is fully complete and the source may free all UE-associated resources. On receipt the source eNB releases the UE's C-RNTI, its RLC/MAC/PDCP entities, the DRB and SRB resources, the reserved radio and transport resources, and tears down the X2-U data-forwarding tunnels. This ends the handover procedure: the UE is now served entirely by the target eNB with its S1-U user-plane anchored there, and no state remains at the source.

Stream Control Transmission Protocol, Src Port: 36422 (36422)
    DATA chunk (ordered, complete segment)
        Payload protocol identifier: X2AP (27)
X2 Application Protocol
    X2AP-PDU: initiatingMessage (0)
        procedureCode: id-uEContextRelease (5)
        UEContextRelease
            Old eNB UE X2AP ID: 161
            New eNB UE X2AP ID: 183
            Cause: radioNetwork (normal-release / successful-handover)
            [source frees C-RNTI, RLC/MAC/PDCP, E-RAB 5 & 6]
            [X2-U forwarding TEID 0x00B2C401 / 0x00B2C402 torn down]

Summary

An X2 handover is the generic handover spine filled in with concrete inter-node messages. In four phases: (A) the UE's A3 MeasurementReport drives the source's internal HO decision; (B) the source prepares the target directly over X2-C with HANDOVER REQUEST/ACKNOWLEDGE, the target admitting bearers and returning the RRCConnectionReconfiguration(mobilityControlInfo) in a transparent container; (C) the source commands the UE, sends SN Status Transfer and forwards data over X2-U, and the UE does contention-free RACH and confirms with RRCConnectionReconfigurationComplete; (D) the target runs the S1AP Path Switch so the S-GW repoints downlink, receives a fresh {NH, NCC}, and tells the source to release with UE Context Release.

The core is touched exactly once, at the path switch, which is what makes X2 the fast path. Losslessness for AM bearers comes from SN Status Transfer (COUNT continuity) plus GTP-U forwarding; a short interruption comes from contention-free RACH. To debug, walk the fourteen steps in order and find the first message that is missing or carries the wrong IE — the phase it belongs to (measurement, preparation, execution, path switch) points straight at the subsystem to investigate.