4G/LTE - Multi Cell

 

 

 

LTE to LTE Handover

 

The simplest way to describe a “handover” is to think of it as the UE (mobile phone) changing its partner. The picture is useful because it separates two roles. The UE is the one that moves, but the network decides when it moves and to which cell.

Who is the partner in this context?

It’s the cell that the UE is currently connected to. Just as a dance partner changes when the music shifts, the UE changes cells when it detects that another cell can provide better service or when it physically moves out of range of its current cell. This swapping of “partners” is precisely what we mean by a handover.

In the world of LTE, handovers ensure that a user can keep talking, texting, or streaming video without interruption as they move around. When the phone spots a neighboring cell with a stronger signal—or the current one becomes too weak—it initiates a handover. During this process, the network quickly sets up a new connection in the target cell while gracefully releasing the old one, so the user barely notices a change. The underlying steps can get a bit technical, involving signaling messages and core network coordination, but the essence remains: the UE seamlessly “breaks up” with one cell and pairs with another.

In this note, we’ll explore exactly how LTE-to-LTE handover procedures work. We’ll look at what happens over the air between the UE and the network, how the network decides when it’s time for a handover, and the different paths the process can take (especially when switching between cells controlled by the same eNB or by different eNBs). By the end, you’ll see how all the pieces fit together to keep your calls and data sessions running smoothly, even as your phone roams from one cell to the next.

NOTE : In handover, it is the UE that changes partners, but the instruction to change the partner comes from Cell(i.e, Network) and is notified to UE.

Procedure of Handover - LTE to LTE handover

Overall logic is simple and this process are the same (or at least very similar) in every technology. The steps below describe it without the message names of any one technology, so the same list fits UMTS and LTE alike.

    i) A UE is in connection with a cell (let's call this 'Cell A').

    ii) Now a situation that requires handover happened.

    iii) Network send "signal quality measurement" command to UE for the target cell ('Cell B') to which it will handover to.

    iv) UE performance the measurement and report the "measurement result" to the network via the current cell (Cell A).

    v) Network evaluate the measurement result reported by UE.

    vi) If the evaluation result turns out to be good for handover, Network send 'Change Cell' command to UE.

    vii) UE perform the cell change process.

    viii) If cell change process is completed properly, UE send 'cell change completion' message to the network via the target cell (Cell B).

I used very generic term e.g, "signal quality measurement command", "measurement result", "Change Cell Command", "Cell Change Completion Message" etc. These generic commands can be translated to a specific jargon for each technology. For example, if I translate these for UMTS, they would be as follows :

    "Signal quality measurement command" ==> Measurement Control

    "Measurement Result" ==> Measurement Report

    "Change Cell Command" ==> Physical Channel Reconfiguration or ActiveSetUpdate

    "Cell Change Compeletion Message ==> Physical Channel Reconfiguration Complete or ActiveSetUpdateComplete

If you translate them into LTE jargon, they will be as follows.

    "Signal quality measurement command" ==> RRC Connection Reconfiguration

    "Measurement Result" ==> Measurement Report

    "Change Cell Command" ==> RRC Connection Reconfiguration

    "Cell Change Compeletion Message ==> RRC Connection Reconfiguration Complete

You may noticed that LTE is using the same message called "RRC Connection Reconfiguration" both for "Signal quality measurement command" and "Change Cell Command". How UE can tell whether it means "Signal quality measurement command" or "Change Cell Command" ?

Good question ! You will see the answer later.

Then you may have whole lots of questions. It is very good. The more questions you have, the more information you will get through this page.. (not now, in the future -: ) Following is a set of my personal questions.

    i) you talked about "Signal Quality Measurement". What kind of signal quality UE has to measure ? Would it be a certain absolute value ? or a some relative value with reference to some other value ? or is it a special event changes ?

    ii) How much time I can leave the current cell to perform the measurement for target cell ? (If the leave too long from the current cell to measure target cell, the call would drop. But if this time is too short, UE would not get correct measurement values).

    iii) What if UE failed to performe the measurement or fail to find the target cell ?

    iv) you talked about "Change Cell", how UE can change cell ? Just cut the connection with the current cell and reconnect to the target cell ? or is there any specific procedure ?

    v) Cutting the connection from the current cell will be easy, but how can UE reconnect to target cell ?

    vi) What if UE failed to reconnect to target cell after he cut off the connection with the current cell ?

This list would get longer and longer.

Now let's jump into detailed technical aspects of LTE handover. Following is the overall and simplest form of LTE-LTE handover procedure. (This sequence is based on 36.523 TC 8.2.4.2 and I modified the sequence a little bit for clear/easy understanding, hopefully -:). It means this is mainly for UE side aspect of Handover process.

 

Step

Direction

Message

Target Cell

Memo

1

UE <---> SS

< Power On and Registration >

Cell 1

 

2

UE <---> SS

< Now UE is in IDLE mode >

Cell 1

 

3

UE <--- SS

Paging

Cell 1

 

4

UE ---> SS

RRC Connection Request

Cell 1

 

5

UE <--- SS

RRC Connection Setup

Cell 1

 

6

UE ---> SS

RRC Connection Setup Complete

Cell 1

 

7

UE <--- SS

Security Mode Command

Cell 1

 

8

UE ---> SS

Security Mode Complete

Cell 1

 

9

UE <--- SS

RRC Connection Reconfiguration

Cell 1

reactivating default EPS Bearer

10

UE ---> SS

RRCConnectionReconfigurationComplete

Cell 1

 

11

UE <--- SS

RRC Connection Reconfiguration

Cell 1

Measurement Control for Target Cell

12

UE ---> SS

RRCConnectionReconfigurationComplete

Cell 1

 

13

UE ---> SS

Measurement Report

Cell 1

 

14

UE <--- SS

RRC Connection Reconfiguration

Cell 1

Handover Command

15

UE ---> SS

PRACH

Cell 2

 

16

UE <--- SS

RACH Response

Cell 2

 

17

UE ---> SS

RRCConnectionReconfigurationComplete

Cell 2

PASS/FAIL

18

UE <--- SS

ueCapabilityEnquiry

Cell 2

 

19

UE ---> SS

ueCapabilityInformation

Cell 2

 

20

UE ---> SS

ulInformationTransfer + Detach Request

Cell 2

 

21

UE <--- SS

RRC Connection Release

Cell 2

 

 

The table is the UE side of 36.523-1 test case 8.2.4.2, whose title in v19.3.0 is "RRC connection reconfiguration / Handover / Success / Common preamble". Steps 1 to 10 only bring the UE into RRC_CONNECTED on Cell 1 with a default bearer. The handover itself is steps 11 to 17.

Step 11 gives the UE its measurement configuration, and step 13 is the Measurement Report that the configured event triggers. Step 14 is the handover command. In steps 15 and 16, the UE runs random access on Cell 2, and step 17 is the first RRC message the UE sends in Cell 2. The words "Common preamble" in the test title mean that the UE picks a random access preamble itself, because the handover command gives it no dedicated preamble. The capture of step 14 below shows exactly that.

  • Steps 11 and 14 are both RRC Connection Reconfiguration : the contents, not the message name, make one a measurement setup and the other a handover command.
  • Step 13 is the trigger : the network decides on the handover only after the Measurement Report.
  • Steps 15 to 17 happen on the target cell : random access first, then RRCConnectionReconfigurationComplete.

Now let's dig into some of the critical steps of this handover process. I will start with radio message for these critical steps and put additional comments as time goes a long.

RRC Connection Reconfiguration for Target Cell Measurement - Step 11

I will add more comments later, but for now let's just look into the contents of this message. As you see in the parts marked in red, most part of this message about measurement.

Actual message for the measurement would not be as complicated as this one (may be longer due to the long list of cells to be measured), but I enabled almost every information elements for the reference. Especially understanding the Quantity Configuration parameters would take very long for you to understand in details and would be the main source of problems you will have in field test and field troubleshoot.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

DL-DCCH-Message ::= SEQUENCE
  +-message ::= CHOICE [c1]
    +-c1 ::= CHOICE [rrcConnectionReconfiguration]
      +-rrcConnectionReconfiguration ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [rrcConnectionReconfiguration-r8]
            +-rrcConnectionReconfiguration-r8 ::= SEQUENCE [100000]
              +-measConfig ::= SEQUENCE [01010111111] OPTIONAL:Exist
              | +-measObjectToRemoveList ::= SEQUENCE OF OPTIONAL:Omit
              | +-measObjectToAddModList ::= SEQUENCE OF SIZE(1..maxObjectId[32]) [1]
              | | +-MeasObjectToAddMod ::= SEQUENCE
              | |   +-measObjectId ::= INTEGER (1..maxObjectId[32]) [1]
              | |   +-measObject ::= CHOICE [measObjectEUTRA]
              | |     +-measObjectEUTRA ::= SEQUENCE [100000]
              | |       +-carrierFreq ::= INTEGER (0..maxEARFCN[65535]) [6300]
              | |       +-allowedMeasBandwidth ::= ENUMERATED [mbw25]
              | |       +-presenceAntennaPort1 ::= BOOLEAN [FALSE]
              | |       +-neighCellConfig ::= BIT STRING SIZE(2) [01]
              | |       +-offsetFreq ::= ENUMERATED [dB0] OPTIONAL:Exist
              | |       +-cellsToRemoveList ::= SEQUENCE OF OPTIONAL:Omit
              | |       +-cellsToAddModList ::= SEQUENCE OF OPTIONAL:Omit
              | |       +-blackCellsToRemoveList ::= SEQUENCE OF OPTIONAL:Omit
              | |       +-blackCellsToAddModList ::= SEQUENCE OF OPTIONAL:Omit
              | |       +-cellForWhichToReportCGI ::= INTEGER OPTIONAL:Omit
              | +-reportConfigToRemoveList ::= SEQUENCE OF OPTIONAL:Omit
              | +-reportConfigToAddModList ::= SEQUENCE OF SIZE(1..maxReportConfigId[32]) [1]
              | | +-ReportConfigToAddMod ::= SEQUENCE
              | |   +-reportConfigId ::= INTEGER (1..maxReportConfigId[32]) [1]
              | |   +-reportConfig ::= CHOICE [reportConfigEUTRA]
              | |     +-reportConfigEUTRA ::= SEQUENCE
              | |       +-triggerType ::= CHOICE [event]
              | |       | +-event ::= SEQUENCE
              | |       |   +-eventId ::= CHOICE [eventA3]
              | |       |   | +-eventA3 ::= SEQUENCE
              | |       |   |   +-a3-Offset ::= INTEGER (-30..30) [0]
              | |       |   |   +-reportOnLeave ::= BOOLEAN [FALSE]
              | |       |   +-hysteresis ::= INTEGER (0..30) [0]
              | |       |   +-timeToTrigger ::= ENUMERATED [ms640]
              | |       +-triggerQuantity ::= ENUMERATED [rsrp]
              | |       +-reportQuantity ::= ENUMERATED [both]
              | |       +-maxReportCells ::= INTEGER (1..maxCellReport[8]) [1]
              | |       +-reportInterval ::= ENUMERATED [ms1024]
              | |       +-reportAmount ::= ENUMERATED [r1]
              | +-measIdToRemoveList ::= SEQUENCE OF OPTIONAL:Omit
              | +-measIdToAddModList ::= SEQUENCE OF SIZE(1..maxMeasId[32]) [1] OPTIONAL:Exist
              | | +-MeasIdToAddMod ::= SEQUENCE
              | |   +-measId ::= INTEGER (1..maxMeasId[32]) [1]
              | |   +-measObjectId ::= INTEGER (1..maxObjectId[32]) [1]
              | |   +-reportConfigId ::= INTEGER (1..maxReportConfigId[32]) [1]
              | +-quantityConfig ::= SEQUENCE [1111] OPTIONAL:Exist
              | | +-quantityConfigEUTRA ::= SEQUENCE [11] OPTIONAL:Exist
              | | | +-filterCoefficientRSRP ::= ENUMERATED [fc0] OPTIONAL:Exist
              | | | +-filterCoefficientRSRQ ::= ENUMERATED [fc0] OPTIONAL:Exist
              | | +-quantityConfigUTRA ::= SEQUENCE [1] OPTIONAL:Exist
              | | | +-measQuantityUTRA-FDD ::= ENUMERATED [cpich-RSCP]
              | | | +-measQuantityUTRA-TDD ::= ENUMERATED [pccpch-RSCP]
              | | | +-filterCoefficient ::= ENUMERATED [fc0] OPTIONAL:Exist
              | | +-quantityConfigGERAN ::= SEQUENCE [1] OPTIONAL:Exist
              | | | +-measQuantityGERAN ::= ENUMERATED [rssi]
              | | | +-filterCoefficient ::= ENUMERATED [fc0] OPTIONAL:Exist
              | | +-quantityConfigCDMA2000 ::= SEQUENCE OPTIONAL:Exist
              | |   +-measQuantityCDMA2000 ::= ENUMERATED [pilotStrength]
              | +-measGapConfig ::= CHOICE [release] OPTIONAL:Exist
              | | +-release ::= NULL
              | +-s-Measure ::= INTEGER (0..97) [0] OPTIONAL:Exist
              | +-preRegistrationInfoHRPD ::= SEQUENCE [11] OPTIONAL:Exist
              | | +-preRegistrationAllowed ::= BOOLEAN [FALSE]
              | | +-preRegistrationZoneId ::= INTEGER (0..255) [0] OPTIONAL:Exist
              | | +-secondaryPreRegistrationZoneIdList ::= SEQUENCE OF SIZE(1..2) [1]
              | |   +-PreRegistrationZoneIdHRPD ::= INTEGER (0..255) [0]
              | +-speedStatePars ::= CHOICE [setup] OPTIONAL:Exist
              |   +-setup ::= SEQUENCE
              |     +-mobilityStateParameters ::= SEQUENCE
              |     | +-t-Evaluation ::= ENUMERATED [s30]
              |     | +-t-HystNormal ::= ENUMERATED [s30]
              |     | +-n-CellChangeMedium ::= INTEGER (1..16) [1]
              |     | +-n-CellChangeHigh ::= INTEGER (1..16) [1]
              |     +-timeToTrigger-SF ::= SEQUENCE
              |       +-sf-Medium ::= ENUMERATED [oDot25]
              |       +-sf-High ::= ENUMERATED [oDot25]
              +-mobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
              +-dedicatedInfoNASList ::= SEQUENCE OF OPTIONAL:Omit
              +-radioResourceConfigDedicated ::= SEQUENCE OPTIONAL:Omit
              +-securityConfigHO ::= SEQUENCE OPTIONAL:Omit
              +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

The red fields build one measurement in three parts. The object measObjectId 1 is an E-UTRA carrier with carrierFreq 6300, which is EARFCN 6300. That EARFCN is in band 20, at 791 + 0.1 x (6300 - 6150) = 806 MHz. The field allowedMeasBandwidth mbw25 limits the measurement to 25 RB. The report configuration reportConfigId 1 is event A3, and measId 1 links the object to the report configuration. So the UE measures cells on 806 MHz and reports them when event A3 is met.

Event A3 means that a neighbour cell becomes offset better than the serving cell. 36.331 v19.3.0 clause 5.5.4.4 writes the entering condition as Mn + Ofn + Ocn - Hys > Mp + Ofp + Ocp + Off. Here a3-Offset, hysteresis and offsetFreq are all 0, and no cell has an individual offset. The condition is therefore met as soon as a neighbour is measured stronger than the serving cell. It must hold for timeToTrigger ms640 before the UE sends the report. The field triggerQuantity rsrp compares RSRP, and reportQuantity both reports RSRP and RSRQ.

The IE quantityConfigEUTRA sets filterCoefficientRSRP and filterCoefficientRSRQ to fc0. In clause 5.5.3.2, a coefficient k of 0 means that no layer 3 filtering applies. The UE then evaluates the event on the raw physical layer results. That suits a test, but in a live network a larger coefficient smooths out fast fading. The fields maxReportCells 1 and reportAmount r1 ask for a single report with the best neighbour only.

Most of the other fields are there only because the author enabled them for reference. The capture is a Release 8 message, and some names have changed since then. In 36.331 v19.3.0, blackCellsToRemoveList and blackCellsToAddModList of MeasObjectEUTRA are now excludedCellsToRemoveList and excludedCellsToAddModList. The capture shows the names that the tester decoded, and it is left as captured.

  • One measurement is object + report config + measId : measId 1 joins the carrier 6300 object to the event A3 report config.
  • A3 with zero offsets : any neighbour stronger than the serving cell for 640 ms triggers a report.
  • fc0 means no layer 3 filtering : the event is evaluated on raw RSRP.
  • blackCells is now excludedCells : the capture keeps the Release 8 names.

RRC Connection Reconfiguration for Cell Change - Step 14

I will add more comments later, but for now let's just look into the contents of this message. As you see in the parts marked in red, most part of this message about measurement. As you see in the part marked red, major part of this message is 'mobilityControlInfo' IE and 'securityConfigHO'.

'mobilityControlInfo' tells UE about the frequency of target cell and various physical channel configuration and RACH procedure information about the target cell. In short, this IE (information element) carries the most of SIB2 information of target cell.

Decoded RRC message, tester tree format. Field values are from a captured message, not from the specification.

+-c1 ::= CHOICE [rrcConnectionReconfiguration-r8]
  +-rrcConnectionReconfiguration-r8 ::= SEQUENCE [010110]
    +-measConfig ::= SEQUENCE OPTIONAL:Omit
    +-mobilityControlInfo ::= SEQUENCE [1000] OPTIONAL:Exist
    | +-targetPhysCellId ::= INTEGER (0..503) [2]
    | +-carrierFreq ::= SEQUENCE [1] OPTIONAL:Exist
    | | +-dl-CarrierFreq ::= INTEGER (0..maxEARFCN[65535]) [6300]
    | | +-ul-CarrierFreq ::= INTEGER (0..maxEARFCN[65535]) [24300] OPTIONAL:Exist
    | +-carrierBandwidth ::= SEQUENCE OPTIONAL:Omit
    | +-additionalSpectrumEmission ::= INTEGER OPTIONAL:Omit
    | +-t304 ::= ENUMERATED [ms1000]
    | +-newUE-Identity ::= BIT STRING SIZE(16) [0001000000110100]
    | +-radioResourceConfigCommon ::= SEQUENCE [100010000]
    | | +-rach-ConfigCommon ::= SEQUENCE OPTIONAL:Exist
    | | | +-preambleInfo ::= SEQUENCE [0]
    | | | | +-numberOfRA-Preambles ::= ENUMERATED [n52]
    | | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit
    | | | +-powerRampingParameters ::= SEQUENCE
    | | | | +-powerRampingStep ::= ENUMERATED [dB2]
    | | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-104]
    | | | +-ra-SupervisionInfo ::= SEQUENCE
    | | | | +-preambleTransMax ::= ENUMERATED [n6]
    | | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10]
    | | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf48]
    | | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4]
    | | +-prach-Config ::= SEQUENCE [1]
    | | | +-rootSequenceIndex ::= INTEGER (0..837) [86]
    | | | +-prach-ConfigInfo ::= SEQUENCE OPTIONAL:Exist
    | | |   +-prach-ConfigIndex ::= INTEGER (0..63) [3]
    | | |   +-highSpeedFlag ::= BOOLEAN [FALSE]
    | | |   +-zeroCorrelationZoneConfig ::= INTEGER (0..15) [5]
    | | |   +-prach-FreqOffset ::= INTEGER (0..94) [2]
    | | +-pdsch-ConfigCommon ::= SEQUENCE OPTIONAL:Omit
    | | +-pusch-ConfigCommon ::= SEQUENCE
    | | | +-pusch-ConfigBasic ::= SEQUENCE
    | | | | +-n-SB ::= INTEGER (1..4) [1]
    | | | | +-hoppingMode ::= ENUMERATED [interSubFrame]
    | | | | +-pusch-HoppingOffset ::= INTEGER (0..98) [4]
    | | | | +-enable64QAM ::= BOOLEAN [FALSE]
    | | | +-ul-ReferenceSignalsPUSCH ::= SEQUENCE
    | | |   +-groupHoppingEnabled ::= BOOLEAN [TRUE]
    | | |   +-groupAssignmentPUSCH ::= INTEGER (0..29) [0]
    | | |   +-sequenceHoppingEnabled ::= BOOLEAN [FALSE]
    | | |   +-cyclicShift ::= INTEGER (0..7) [0]
    | | +-phich-Config ::= SEQUENCE OPTIONAL:Omit
    | | +-pucch-ConfigCommon ::= SEQUENCE OPTIONAL:Omit
    | | +-soundingRS-UL-ConfigCommon ::= CHOICE [setup] OPTIONAL:Exist
    | | | +-setup ::= SEQUENCE [0]
    | | |   +-srs-BandwidthConfig ::= ENUMERATED [bw3]
    | | |   +-srs-SubframeConfig ::= ENUMERATED [sc0]
    | | |   +-ackNackSRS-SimultaneousTransmission ::= BOOLEAN [TRUE]
    | | |   +-srs-MaxUpPts ::= ENUMERATED OPTIONAL:Omit
    | | +-uplinkPowerControlCommon ::= SEQUENCE OPTIONAL:Omit
    | | +-antennaInfoCommon ::= SEQUENCE OPTIONAL:Omit
    | | +-p-Max ::= INTEGER OPTIONAL:Omit
    | | +-tdd-Config ::= SEQUENCE OPTIONAL:Omit
    | | +-ul-CyclicPrefixLength ::= ENUMERATED [len1]
    | +-rach-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
    +-dedicatedInfoNASList ::= SEQUENCE OF OPTIONAL:Omit
    +-radioResourceConfigDedicated ::= SEQUENCE [000001] OPTIONAL:Exist
    | +-srb-ToAddModList ::= SEQUENCE OF OPTIONAL:Omit
    | +-drb-ToAddModList ::= SEQUENCE OF OPTIONAL:Omit
    | +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit
    | +-mac-MainConfig ::= CHOICE OPTIONAL:Omit
    | +-sps-Config ::= SEQUENCE OPTIONAL:Omit
    | +-physicalConfigDedicated ::= SEQUENCE [0000111111] OPTIONAL:Exist
    |   +-pdsch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
    |   +-pucch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
    |   +-pusch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
    |   +-uplinkPowerControlDedicated ::= SEQUENCE OPTIONAL:Omit
    |   +-tpc-PDCCH-ConfigPUCCH ::= CHOICE [setup] OPTIONAL:Exist
    |   | +-setup ::= SEQUENCE
    |   |   +-tpc-RNTI ::= BIT STRING SIZE(16) [0000001111111111]
    |   |   +-tpc-Index ::= CHOICE [indexOfFormat3]
    |   |     +-indexOfFormat3 ::= INTEGER (1..15) [1]
    |   +-tpc-PDCCH-ConfigPUSCH ::= CHOICE [setup] OPTIONAL:Exist
    |   | +-setup ::= SEQUENCE
    |   |   +-tpc-RNTI ::= BIT STRING SIZE(16) [0000000111111010]
    |   |   +-tpc-Index ::= CHOICE [indexOfFormat3]
    |   |     +-indexOfFormat3 ::= INTEGER (1..15) [1]
    |   +-cqi-ReportConfig ::= SEQUENCE [11] OPTIONAL:Exist
    |   | +-cqi-ReportModeAperiodic ::= ENUMERATED [rm30] OPTIONAL:Exist
    |   | +-nomPDSCH-RS-EPRE-Offset ::= INTEGER (-1..6) [0]
    |   | +-cqi-ReportPeriodic ::= CHOICE [setup] OPTIONAL:Exist
    |   |   +-setup ::= SEQUENCE [1]
    |   |     +-cqi-PUCCH-ResourceIndex ::= INTEGER (0..1185) [0]
    |   |     +-cqi-pmi-ConfigIndex ::= INTEGER (0..1023) [25]
    |   |     +-cqi-FormatIndicatorPeriodic ::= CHOICE [widebandCQI]
    |   |     | +-widebandCQI ::= NULL
    |   |     +-ri-ConfigIndex ::= INTEGER (0..1023) [483] OPTIONAL:Exist
    |   |     +-simultaneousAckNackAndCQI ::= BOOLEAN [FALSE]
    |   +-soundingRS-UL-ConfigDedicated ::= CHOICE [setup] OPTIONAL:Exist
    |   | +-setup ::= SEQUENCE
    |   |   +-srs-Bandwidth ::= ENUMERATED [bw0]
    |   |   +-srs-HoppingBandwidth ::= ENUMERATED [hbw0]
    |   |   +-freqDomainPosition ::= INTEGER (0..23) [0]
    |   |   +-duration ::= BOOLEAN [TRUE]
    |   |   +-srs-ConfigIndex ::= INTEGER (0..1023) [20]
    |   |   +-transmissionComb ::= INTEGER (0..1) [0]
    |   |   +-cyclicShift ::= ENUMERATED [cs0]
    |   +-antennaInfo ::= CHOICE [defaultValue] OPTIONAL:Exist
    |   | +-defaultValue ::= NULL
    |   +-schedulingRequestConfig ::= CHOICE [setup] OPTIONAL:Exist
    |     +-setup ::= SEQUENCE
    |       +-sr-PUCCH-ResourceIndex ::= INTEGER (0..2047) [20]
    |       +-sr-ConfigIndex ::= INTEGER (0..155) [30]
    |       +-dsr-TransMax ::= ENUMERATED [n4]
    +-securityConfigHO ::= SEQUENCE OPTIONAL:Exist
    | +-handoverType ::= CHOICE [intraLTE]
    |   +-intraLTE ::= SEQUENCE [0]
    |     +-securityAlgorithmConfig ::= SEQUENCE OPTIONAL:Omit
    |     +-keyChangeIndicator ::= BOOLEAN [FALSE]
    |     +-nextHopChainingCount ::= INTEGER (0..7) [0]
    +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

The capture starts at the c1 choice of the message, and its upper part is not shown. The first section asked how the UE tells a measurement setup from a handover command, when both are RRC Connection Reconfiguration. The answer is mobilityControlInfo. 36.331 v19.3.0 clause 5.3.5.4 applies when the message includes it, and the UE then performs a handover. Clause 5.3.5.3 applies when the message does not include it, as in step 11.

The field targetPhysCellId 2 names the target cell, and dl-CarrierFreq 6300 is the same EARFCN as the serving cell. This is therefore an intra-frequency handover. The field ul-CarrierFreq 24300 is the band 20 uplink at 832 + 0.1 x (24300 - 24150) = 847 MHz. The field newUE-Identity 0001000000110100 is the C-RNTI in the target cell, 0x1034 or 4148. The IE radioResourceConfigCommon carries the RACH, PRACH, PUSCH and SRS settings of Cell 2, which the UE would otherwise read in SIB2.

The field t304 ms1000 starts timer T304 when the UE receives the message. The UE stops it when random access in the target cell completes. If T304 expires first, the handover has failed, and clause 5.3.5.6 sends the UE to RRC connection re-establishment. The field rach-ConfigDedicated is omitted, so the UE has no dedicated preamble and uses contention-based random access. That is the common preamble case of test case 8.2.4.2.

The IE securityConfigHO says how the UE derives its security key for the target cell. The value keyChangeIndicator FALSE means that the key does not come from a new KASME. The value nextHopChainingCount 0 is the NCC value that the UE already holds after the initial security setup. In that case, 33.401 v19.2.0 clause 7.2.8 uses horizontal key derivation. The new KeNB comes from the current KeNB, bound to the target PCI and its EARFCN-DL.

  • mobilityControlInfo makes it a handover : 36.331 clause 5.3.5.4 instead of 5.3.5.3.
  • Same EARFCN 6300 on both cells : an intra-frequency handover to PCI 2.
  • No rach-ConfigDedicated : contention-based random access with a common preamble.
  • T304 of 1000 ms : on expiry, the UE falls back to re-establishment.
  • NCC 0 and keyChangeIndicator FALSE : horizontal derivation of the new KeNB.

Common Root Cause for Handover Failure

Handover failure is a common problem in LTE networks that can result in degraded network performance and poor user experience. The root cause of handover failure can be complex and multifaceted, involving issues with UE hardware and software, network configuration, and radio access network (RAN) design. Addressing these issues requires a thorough understanding of the underlying causes and a targeted approach to troubleshooting and resolving the problem. We all know that there would be a lot of handover failure we will encounter in the field, but it is hard (almost impossible) to exactly pin point out exactly when it will happen by what cause.  The only thing we can try is to consolidate various cases of the failure from the field and brainstorm on the possible root causes. Followings are some of the root causes (of course not all of them) we can think of.

  • Weak or fluctuating signal strength: A weak signal can cause a handover failure because the target cell may not have sufficient signal strength to maintain the connection. Fluctuating signal strength can also lead to a handover failure because the UE (User Equipment) may not be able to determine the best target cell.
  • Interference: Interference from other devices or networks can cause a handover failure. This is particularly common in urban areas where multiple networks may be operating in close proximity.
  • Congestion: Congestion on the network can cause a handover failure because there may not be enough resources available to support the handover.
  • Incorrect neighbor cell list: If the UE's neighbor cell list is not properly configured, it may not be able to identify the best target cell for handover.
  • UE issues: UE hardware or software issues can cause a handover failure. For example, if the UE is not properly configured, it may not be able to perform a handover correctly. Followings are some of possible UE issues we can think of (Of course,you may have further issues based on your own experience).
    • Incorrect UE configuration: If the UE is not properly configured, it may not be able to perform a handover correctly. For example, if the measurement parameters are not set correctly, the UE may not be able to accurately measure the signal strength of the surrounding cells.
    • Hardware issues: UE hardware issues, such as faulty antennas or radios, can cause a handover failure. This can result in a weak signal or an inability to communicate with the serving cell.
    • Software issues: UE software issues, such as incorrect firmware or operating system versions, can also cause handover problems. For example, if the firmware is outdated, the UE may not be able to support the latest handover protocols.
    • Battery issues: If the UE's battery is low or failing, it may not be able to maintain a stable connection with the serving cell. This can cause a handover failure or result in the UE being unable to communicate with the network.
    • Incompatible UE: If the UE is not compatible with the network or the network operator's configuration, it may not be able to perform a handover correctly. This can result in a handover failure or an inability to establish a connection with the network.
  • Network configuration issues: Configuration issues within the network can cause a handover failure. For example, if the handover parameters are not properly set, the handover may fail. Followings are some of examples of Network configuration Issues that may lead to handover failure.
    • Incorrect handover parameters: Handover parameters such as hysteresis, time-to-trigger, and threshold values need to be set correctly for successful handover. If the parameters are not properly configured, the UE may not be able to identify the best target cell, leading to handover failures.
    • Incorrect neighbor cell list: The UE's neighbor cell list needs to be properly configured to ensure that it can accurately measure and identify the best target cell for handover. If the neighbor cell list is not up-to-date or properly configured, the UE may not be able to make an optimal handover decision.
    • Incorrect cell coverage area: If the coverage area of cells is not configured properly, it can cause handover problems. For example, if the cells are too small or too large, the UE may not be able to make a successful handover decision.
    • Incorrect load balancing settings: Load balancing is used to distribute traffic across cells to optimize network performance. However, if the load balancing settings are not configured properly, the UE may be handed over to a heavily loaded cell that cannot support the additional traffic, resulting in a handover failure.
    • Incorrect mobility settings: Mobility parameters such as handover margin, mobility state, and handover priority need to be set correctly for successful handover. If the parameters are not properly configured, the UE may not be able to make an optimal handover decision.
    • Incorrect radio access network (RAN) configuration: If the RAN is not configured properly, it can cause handover problems. For example, if the RAN is not properly dimensioned or the inter-site distance is too large, it can result in handover failures.
  • Ping Pong handover: A ping pong handover occurs when the UE rapidly switches between two cells, causing network congestion and impacting the quality of service. This can be caused by incorrect measurement thresholds, incorrect neighbor cell lists, or a weak signal in both cells.
  • Radio link failure: A radio link failure (RLF) occurs when the UE is unable to communicate with the serving cell. This can be caused by interference, a weak signal, or congestion. If the RLF is not detected in time, it can lead to a handover failure.
  • Load balancing issues: Load balancing is used to distribute traffic across cells to optimize network performance. However, incorrect load balancing settings can cause handover failures if the UE is handed over to a heavily loaded cell that cannot support the additional traffic.
  • Handover triggered too late: If the handover decision is triggered too late, the UE may have already lost the signal from the serving cell, resulting in a handover failure.

Intra eNB vs Inter eNB Handover

What are the difference between intra eNB handover and inter eNB handover ? The answer decides how many network nodes take part. It matters mainly on the network side, because the UE sees almost the same messages in both cases.

In LTE (and similarly in 5G NR), a handover is the process of transferring an ongoing connection (radio resource control) from one cell to another. The terms intra-eNB and inter-eNB refer to whether the cells involved are controlled by the same eNB (intra) or by different eNBs (inter)

Both handover types are essential in maintaining continuous connectivity and service quality as users move throughout the network. The choice of procedure often depends on cell layout, eNB connectivity (X2 availability), and operator configuration.

Definition

Handover is an essential mechanism in LTE that ensures a user maintains seamless connectivity when moving from one cell to another. The classification of handovers hinges on whether both the source and target cells are managed by the same eNB. When they are, it is referred to as intra-eNB handover, a relatively straightforward procedure since the same eNB handles both cells. Conversely, if the source and target cells belong to different eNBs, the process is known as inter-eNB handover, which introduces additional complexity through coordination over the X2 or S1 interface and may involve core network entities such as the MME.

  • Intra-eNB Handover
    • Occurs between two cells under the same eNB (eNodeB).
    • Typically involves a simpler signaling procedure because the same eNB manages both source and target cells.
    • An intra-eNB handover is simpler because the user remains under the same eNB, requiring minimal changes in the core network.
  • Inter-eNB Handover
    • Occurs between two cells belonging to different eNBs.
    • Requires additional coordination and signaling across the X2 or S1 interfaces between eNBs (and possibly involvement of the MME).
    • An inter-eNB handover involves coordination between two different eNBs and the MME/S-GW, making it a more involved procedure with additional signaling and potential rerouting of user traffic.

Signaling Procedures

The signaling procedures for handovers in mobile networks play a critical role in maintaining seamless connectivity as users move between cells. In both intra-eNB and inter-eNB handovers, the UE experiences similar over-the-air (OTA) signaling, primarily driven by RRC messages, ensuring smooth radio resource control (RRC) transitions. However, the underlying network coordination differs significantly. In *intra-eNB handovers*, since both the source and target cells are controlled by the same eNB, the process is generally simpler and localized, avoiding major changes in the data path and minimizing signaling overhead. In contrast, *inter-eNB handovers* require additional coordination either through an X2 interface (if available) for direct data forwarding or via the S1 interface. These procedures necessitate more complex signaling exchanges between different eNBs and may trigger supplementary updates to the core network, such as path switching and resource reconfiguration. While the OTA RRC signaling remains relatively consistent between both types of handovers, the network-internal steps greatly influence the overall complexity and data management during inter-eNB handovers.

Signaling procedures in LTE handovers are primarily distinguished by whether they stay within one eNB or span across multiple eNBs. From the UE’s perspective over the air (OTA), the core RRC messages remain largely unchanged in both cases. However, the network-side processes differ significantly, particularly in how context and data paths are transferred or updated. In an intra-eNB scenario, the handover is local to the same eNB, resulting in simpler signaling and minimal core network involvement. By contrast, an inter-eNB handover—especially when using the X2 or S1 interface—requires additional coordination among the eNBs and the MME to ensure continuity of the user-plane path, thus adding complexity behind the scenes.

  • Intra-eNB Handover
    • Local handover within the same eNB.
    • The eNB can internally handle most of the radio resource control (RRC) reconfiguration since the user’s context remains in one logical node.
    • The data path does not need a major change because the serving gateway (S-GW) and MME do not have to re-establish a user-plane tunnel for a different eNB.
  • Inter-eNB Handover
    • X2-based handover
      • If an X2 interface is available between the source and target eNB, user-plane data can be forwarded directly.
      • A “Path Switch Request” is sent from the target eNB to the MME to update the data path through the S-GW.
      • Requires an exchange of handover messages between the two eNBs over the X2 interface.
    • S1-based handover
      • Used if the X2 interface is not available or not configured.
      • Handover messages go via the MME over the S1 interface, resulting in a more centralized handover procedure.
      • The MME directs the target eNB to set up resources for the incoming user.

Complexity & Latency

When examining the complexity and latency of LTE handovers, a key factor is whether they occur within a single eNB or span multiple eNBs. An intra-eNB handover involves fewer nodes—just the source and target cells under the same eNB—leading to lower signaling overhead and a typically faster, more seamless transition. By contrast, an inter-eNB handover engages at least two separate eNBs, along with the MME and potentially the S-GW for path switching, which increases signaling complexity and can introduce additional latency as the network reconfigures the data path.

  • Intra-eNB:
    • Less signaling overhead (fewer nodes involved).
    • Typically faster and more seamless since it remains within the same eNB.
  • Inter-eNB:
    • Higher signaling overhead (at least two eNBs plus the MME, and possibly the S-GW for path switching).
    • May introduce slightly higher latency due to additional messaging and path reconfiguration.

Impact on the Core Network

Handovers do not just involve the radio interface; they can also require adjustments in the core network. An intra-eNB handover typically has little to no effect on the MME or the S-GW, as the radio transition remains within the same eNB. In contrast, an inter-eNB handover triggers updates to the UE’s context at the MME and may necessitate a user-plane path switch at the S-GW, ensuring traffic is routed correctly to the new target eNB

  • Intra-eNB:
    • Minimal or no impact on the MME or S-GW.
    • Most of the procedure is confined within the radio side of the same eNB.
  • Inter-eNB:
    • The MME is informed of the handover (to update UE context) and to trigger the S-GW path switch if needed.
    • The core network user-plane path (from S-GW to eNB) needs reconfiguration to point to the new target eNB.

Any differences in OTA message, i.e, RRC/NAS ?

In LTE, the core over-the-air (OTA) signaling for a handover remains broadly the same, whether moving between cells under the same eNB (intra-eNB) or across different eNBs (inter-eNB). The UE sends measurement reports to the source eNB, receives an RRCConnectionReconfiguration command with mobilityControlInfo, and may perform a Random Access procedure before sending an RRCConnectionReconfigurationComplete to confirm the new radio link. These RRC messages do not fundamentally change based on the target eNB.

Behind the scenes, however, inter-eNB handovers involve additional network-side steps, such as X2 or S1 signaling to transfer the UE’s context and a Path Switch Request to update the user-plane route at the MME and S-GW. In contrast, intra-eNB handovers typically remain local to the same eNB with minimal core network involvement. Lastly, NAS messaging (e.g., for Tracking Area Updates) usually occurs independently of the basic handover process, unless other mobility or security triggers coincide with the handover event.

In short, there is “ there is no major difference in the OTA (RRC/NAS) messages themselves.” All the extra steps for an inter-eNB handover (path switch, X2 signaling, etc.) happen inside the network, invisible to the UE in terms of RRC/NAS message content.

  • From the UE standpoint:
    • The same RRCConnectionReconfiguration-based handover command is received.
    • No additional/different NAS messages are typically sent over the air.
  • From the network standpoint:
    • Intra-eNB: Handled internally, minimal signaling to the core network.
    • Inter-eNB: Requires X2/S1-based handover signaling between the source and target eNBs (and possibly a path switch in the core network).

How intra-eNB handover works ?

Cell 1 and Cell 2 may belong to one eNB. Then why does the UE still need a handover command ? It must change its PCell, C-RNTI and radio timing even though the network keeps the UE context inside one logical eNB. There is no second eNB to prepare over X2.

The diagram below starts after the source-cell measurement report. It shows the radio procedure, not an X2 or S1 handover hidden inside the eNB. The eNB can prepare Cell 2 locally and keep its core-facing UE association.

Intra-eNB handoverUEOne eNB: Cell 1 and Cell 2MeasurementReport on Cell 1Prepare target resources locally; no X2APRRCConnectionReconfiguration with mobilityControlInfoUE synchronizes and accesses Cell 2RRCConnectionReconfigurationComplete on Cell 2Old Cell 1 resources can be released locally

Figure 1. The cell changes, but the eNB remains the same node; X2AP preparation and S1 path switch are not part of this local path.

  1. The UE reports the measured neighbour on Cell 1. A report is input to the decision, not the decision itself.
  2. The eNB checks Cell 2 resources locally and sends the handover RRCConnectionReconfiguration to the UE.
  3. The UE synchronizes, performs target random access when required, and sends RRCConnectionReconfigurationComplete on Cell 2.
  4. The eNB frees obsolete Cell 1 resources. Its existing S1 bearer can remain anchored at the same eNB.

Local preparation and radio command

The source and target cells share the eNB's UE context, so the eNB does not send X2AP HANDOVER REQUEST to itself. It still sends a real LTE handover command on Uu. The important discriminator is mobilityControlInfo inside RRCConnectionReconfiguration, not the RRC message name alone.

The following selected-field JER is synthetic. It follows TS 36.331 v19.4.0 and shows the command's target PCI 2, T304 of 1000 ms and new C-RNTI 0x1034. It omits other mandatory radio configuration and therefore is not a complete PDU or a capture.

Illustrative RRCConnectionReconfiguration, selected-field JER; synthetic values.

{
  "rrc-TransactionIdentifier": 1,
  "criticalExtensions": { "c1": { "rrcConnectionReconfiguration-r8": {
    "mobilityControlInfo": {
      "targetPhysCellId": 2,
      "t304": "ms1000",
      "newUE-Identity": "1034"
    }
  } } }
}

Target access and completion

After receiving the command, the UE moves to Cell 2 and gets uplink timing. In the common-preamble test above, the UE uses contention-based random access because the command has no rach-ConfigDedicated. With a dedicated preamble, the access branch differs, but the completion message still confirms the RRC transaction.

Illustrative RRCConnectionReconfigurationComplete JER, sent on Cell 2.

{
  "rrc-TransactionIdentifier": 1,
  "criticalExtensions": { "rrcConnectionReconfigurationComplete-r8": {} }
}

If the UE cannot complete target access before T304 expires, it does not send this completion message. The failure belongs to radio execution, not X2 target admission. That difference matters when the trace contains only the UE-side messages.

For a network-side trace, first check whether Cell 1 and Cell 2 are configured under the same logical eNB. If they are, the absence of X2AP HANDOVER REQUEST, SN STATUS TRANSFER and UE CONTEXT RELEASE is expected. The source and target cell identifiers still differ, and the RRC command still contains mobilityControlInfo. Those radio-side facts distinguish a real intra-eNB cell change from an ordinary RRC reconfiguration that only adjusts measurements or bearers.

The eNB also does not need to ask the MME for an S1 path switch merely because this UE changes between its own cells. Its existing core-facing association remains with the same eNB. Local scheduling, target admission and old-cell cleanup are implementation actions, so their exact internal messages cannot be inferred from the standardized Uu trace alone.

  • One eNB handles both cells : target preparation can remain local.
  • Uu handover is still real : the UE changes serving cell and confirms the RRC transaction.

How X2-based inter-eNB handover works ?

Now Cell 2 belongs to another eNB. The source cannot prepare that target locally, so it asks the target over X2-C. The MME does not prepare the target in this path. It becomes involved when the UE has arrived and the target needs the S-GW downlink path changed.

The diagram shows an ordinary successful X2 handover. X2-U forwarding can carry buffered data during the radio interruption, but it is GTP-U user-plane traffic, not one of the X2AP control messages drawn here.

X2-based LTE handoverUESource eNBTarget eNBMME / S-GWMeasurementReportX2AP HANDOVER REQUESTHANDOVER REQUEST ACKNOWLEDGERRCConnectionReconfigurationX2AP SN STATUS TRANSFERTarget access + RRC CompleteS1AP PATH SWITCH REQUESTPATH SWITCH REQUEST ACKNOWLEDGEX2AP UE CONTEXT RELEASE

Figure 2. X2 prepares the target before the radio move; S1 path switch follows target access and precedes source context release.

  1. The source selects a target after measurement and sends X2AP HANDOVER REQUEST with UE context and target ECGI.
  2. The target admits E-RAB resources and returns HANDOVER REQUEST ACKNOWLEDGE with a target-generated RRC container.
  3. The source sends the RRC command to the UE and transfers PDCP status on X2-C. Optional packet forwarding uses X2-U.
  4. The UE accesses the target and sends RRCConnectionReconfigurationComplete there.
  5. The target requests S1 path switch. After MME acknowledgement, it tells the source to release the old UE context.

X2 preparation

X2AP HANDOVER REQUEST uses the old eNB UE X2AP ID to identify the source context. TargetCell-ID selects the target ECGI. UE-ContextInformation carries the MME UE S1AP ID, security context, E-RAB setup information and RRC context. The target may reject preparation; a sent request alone does not mean radio resources were reserved.

The following examples show selected IEs from TS 36.423 v19.1.0. Their values are synthetic, and mandatory IEs omitted for readability remain mandatory in an actual PDU. The 28-bit E-UTRAN cell identifier is represented as a JER hex string.

Illustrative X2AP HandoverRequest, selected-IE JER; synthetic values.

{
  "initiatingMessage": { "procedureCode": 0, "criticality": "reject", "value": {
    "protocolIEs": [
      { "id": 10, "criticality": "reject", "value": 420 },
      { "id": 11, "criticality": "reject", "value": {
        "pLMN-Identity": "00f110", "eUTRANcellIdentifier": "0000202" } },
      { "id": 14, "criticality": "reject", "value": {
        "mME-UE-S1AP-ID": 880001,
        "e-RABs-ToBeSetup-List": [ { "id": 4, "criticality": "ignore",
          "value": { "e-RAB-ID": 5 } } ] } }
    ]
  } }
}

The target answers with a new X2AP UE ID and an admitted E-RAB list. The target-to-source transparent container remains encoded bytes at the X2AP layer. Its contained RRC command is decoded separately on the UE side, not inserted as a JSON child of that OCTET STRING.

Illustrative X2AP HandoverRequestAcknowledge, selected-IE JER.

{
  "successfulOutcome": { "procedureCode": 0, "criticality": "reject", "value": {
    "protocolIEs": [
      { "id": 10, "criticality": "ignore", "value": 420 },
      { "id": 9, "criticality": "ignore", "value": 891 },
      { "id": 1, "criticality": "ignore", "value": [
        { "id": 0, "criticality": "ignore", "value": { "e-RAB-ID": 5 } } ] },
      { "id": 12, "criticality": "ignore", "value": "004a10340201" }
    ]
  } }
}

UE execution and status transfer

The source passes the target-generated command to the UE as RRCConnectionReconfiguration. The UE then changes to Cell 2 and confirms the transaction there. While this happens, the source can forward downlink packets over X2-U and sends X2AP SN STATUS TRANSFER for E-RABs that need PDCP continuity.

The X2 status list is not user data. Each E-RAB item reports UL and DL PDCP COUNT state, using PDCP SN and HFN. The example keeps the same old and new X2AP IDs so the target can attach the status to its prepared UE context.

Illustrative X2AP SNStatusTransfer, selected-IE JER.

{
  "initiatingMessage": { "procedureCode": 4, "criticality": "ignore", "value": {
    "protocolIEs": [
      { "id": 10, "criticality": "reject", "value": 420 },
      { "id": 9, "criticality": "reject", "value": 891 },
      { "id": 18, "criticality": "ignore", "value": [
        { "id": 19, "criticality": "ignore", "value": { "e-RAB-ID": 5,
          "uL-COUNTvalue": { "pDCP-SN": 101, "hFN": 0 },
          "dL-COUNTvalue": { "pDCP-SN": 104, "hFN": 0 } } } ] }
    ]
  } }
}

S1 path switch and source release

After target access, the target sends S1AP PATH SWITCH REQUEST to the MME. The MME and S-GW change the downlink S1-U tunnel toward the target, then the MME returns PATH SWITCH REQUEST ACKNOWLEDGE. Only after that confirmation does the target send X2AP UE CONTEXT RELEASE to the source.

Forwarded packets may still arrive while the old route drains. That is why the first target packet is not proof of path-switch completion. The X2AP release carries both peer UE IDs; it releases one UE context, not the X2 association between eNBs.

Illustrative X2AP UEContextRelease, selected-IE JER.

{
  "initiatingMessage": { "procedureCode": 5, "criticality": "ignore", "value": {
    "protocolIEs": [
      { "id": 10, "criticality": "reject", "value": 420 },
      { "id": 9, "criticality": "reject", "value": 891 }
    ]
  } }
}
  • X2 prepares : the source and target exchange UE context directly.
  • Uu executes : the UE receives the RRC command and accesses Cell 2.
  • S1 completes the path : the MME acknowledges path switch before source release.

How S1-based inter-eNB handover works ?

What if the source cannot use X2 to prepare the target ? It can ask the MME to coordinate an S1-based handover. The MME sends the preparation request to the target eNB and returns the target's radio command to the source. This is not an X2 request routed through the MME; it is a different S1AP procedure.

The diagram assumes one MME for clarity. Core-internal bearer and S-GW actions depend on the deployment, so only the main S1AP and Uu checkpoints are drawn. The UE still receives RRCConnectionReconfiguration as the radio command.

S1-based LTE handoverUESource eNBMME / EPCTarget eNBS1AP HANDOVER REQUIREDS1AP HANDOVER REQUESTHANDOVER REQUEST ACKNOWLEDGES1AP HANDOVER COMMANDRRCConnectionReconfigurationTarget access + RRC CompleteS1AP HANDOVER NOTIFYUE CONTEXT RELEASE COMMAND

Figure 3. S1 preparation passes through the MME; target arrival is reported by HANDOVER NOTIFY, not by an X2-style Path Switch Request.

  1. The source sends S1AP HANDOVER REQUIRED to the MME with the target identity and source-to-target container.
  2. The MME sends S1AP HANDOVER REQUEST to the target. The target admits bearers and returns HANDOVER REQUEST ACKNOWLEDGE.
  3. The MME sends HANDOVER COMMAND to the source. The source delivers the target RRC command to the UE.
  4. The UE accesses the target and sends RRCConnectionReconfigurationComplete. The target sends HANDOVER NOTIFY to the MME.
  5. The EPC finishes the bearer route update, and the MME orders the old source context released.

MME-assisted preparation

HANDOVER REQUIRED identifies the source-side MME and eNB UE associations, handover type, target eNB and encoded source-to-target context. The target does not see this source message directly. Instead, the MME creates HANDOVER REQUEST for target admission. A target refusal appears as S1AP HANDOVER FAILURE before the UE receives any radio command.

The next JER examples use TS 36.413 v19.2.0. They show selected IEs with synthetic values, not full PDUs. An actual HandoverRequired also carries its mandatory Cause, and HandoverRequest carries security and bearer context not expanded here.

Illustrative S1AP HandoverRequired, selected-IE JER; synthetic values.

{
  "initiatingMessage": { "procedureCode": 0, "criticality": "reject", "value": {
    "protocolIEs": [
      { "id": 0, "criticality": "reject", "value": 880001 },
      { "id": 8, "criticality": "reject", "value": 1201 },
      { "id": 1, "criticality": "reject", "value": "intralte" },
      { "id": 4, "criticality": "reject", "value": { "targeteNB-ID": {
        "global-ENB-ID": { "pLMNidentity": "00f110",
          "eNB-ID": { "macroENB-ID": "00023" } },
        "selected-TAI": { "pLMNidentity": "00f110", "tAC": "0001" } } } },
      { "id": 104, "criticality": "reject", "value": "0102a03b5c90" }
    ]
  } }
}

The MME's request to the target uses procedure code 1, not the source's code 0. E-RAB 5 is one requested bearer. The target acknowledges it with a target-side eNB UE S1AP ID and an encoded target-to-source radio container.

Illustrative S1AP HandoverRequest and HandoverRequestAcknowledge, selected-IE JER.

{
  "initiatingMessage": { "procedureCode": 1, "criticality": "reject", "value": {
    "protocolIEs": [
      { "id": 0, "criticality": "reject", "value": 880001 },
      { "id": 1, "criticality": "reject", "value": "intralte" },
      { "id": 53, "criticality": "reject", "value": [
        { "id": 27, "criticality": "reject", "value": { "e-RAB-ID": 5 } } ] },
      { "id": 104, "criticality": "reject", "value": "0102a03b5c90" }
    ]
  } }
}
{
  "successfulOutcome": { "procedureCode": 1, "criticality": "reject", "value": {
    "protocolIEs": [
      { "id": 0, "criticality": "ignore", "value": 880001 },
      { "id": 8, "criticality": "ignore", "value": 5402 },
      { "id": 18, "criticality": "ignore", "value": [
        { "id": 20, "criticality": "ignore", "value": { "e-RAB-ID": 5 } } ] },
      { "id": 123, "criticality": "reject", "value": "004a10340201" }
    ]
  } }
}

Radio execution and Handover Notify

The MME returns S1AP HANDOVER COMMAND to the source, including the target-to-source transparent container. The source sends the contained RRCConnectionReconfiguration to the UE. The UE then accesses Cell 2 and sends RRCConnectionReconfigurationComplete to the target, just as in the X2 case.

After the UE arrives, the target sends S1AP HANDOVER NOTIFY to the MME. Its target-side eNB UE S1AP ID and E-UTRAN CGI distinguish the new association. The MME already handled preparation, so do not look for the target's S1AP PATH SWITCH REQUEST as the completion trigger in this path.

Illustrative S1AP HandoverNotify, selected-IE JER.

{
  "initiatingMessage": { "procedureCode": 2, "criticality": "ignore", "value": {
    "protocolIEs": [
      { "id": 0, "criticality": "reject", "value": 880001 },
      { "id": 8, "criticality": "reject", "value": 5402 },
      { "id": 100, "criticality": "ignore", "value": {
        "pLMNidentity": "00f110", "cell-ID": "0000202" } },
      { "id": 67, "criticality": "ignore", "value": {
        "pLMNidentity": "00f110", "tAC": "0001" } }
    ]
  } }
}

After core bearer handling, the MME sends UE CONTEXT RELEASE COMMAND to the source eNB. That is S1AP, not X2AP. Forwarding may be direct or indirect depending on transport availability, but neither form changes the UE's RRC handover command name.

  • MME prepares the target : source and target do not exchange X2AP HANDOVER REQUEST.
  • Uu execution looks familiar : the UE still receives RRCConnectionReconfiguration.
  • Handover Notify marks arrival : it is the S1 completion checkpoint.

Reference

[1] 3GPP TS 36.331 v19.4.0 - clauses 5.3.5.3, 5.3.5.4 and 5.3.5.6, RRC connection reconfiguration and handover; clauses 5.5.3.2 and 5.5.4.4, layer 3 filtering and event A3

[2] 3GPP TS 36.523-1 v19.3.0 - test case 8.2.4.2, RRC connection reconfiguration / Handover / Success / Common preamble

[3] 3GPP TS 33.401 v19.2.0 - clause 7.2.8, key handling in handover

[4] 3GPP TS 36.300 v19.2.0 - clause 10.1.2.1, Handover

[5] 3GPP TS 36.423 v19.1.0 - X2AP handover preparation, SN status transfer, UE context release and protocol IE definitions

[6] 3GPP TS 36.413 v19.2.0 - S1AP handover preparation, Handover Notify and protocol IE definitions