The simplest way to describe a “handover” is to think of it as the UE (mobile phone) changing its partner.

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)
• RRC Connection Reconfiguration for Target Cell Measurement
• RRC Connection Reconfiguration for Cell Change
• Common Root Cause for Handover Failure
• Intra eNB vs Inter eNB Handover
• Get the Test Procedure and Log / Amarisoft TechAcademy (intra frequency, inter frequency)

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.

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 garget 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.

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.

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

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.

+-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

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 ?

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. for 6 seconds

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).