LTE Handover Troubleshooting and Optimization Guide

Doc.
Code
LTE Handover Troubleshooting

and Optimization Guide
Issue 01
Date 2012-05-11
HUAWEI TECHNOLOGIES CO., LTD.

LTE Handover Troubleshooting and Optimization Guide
Copyright © Huawei Technologies Co., Ltd. 2012. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
LTE Handover Troubleshooting and Optimization Guide Contents
Contents
1 Overview.........................................................................................................................................1
2 Handover Principles.....................................................................................................................2
2.1 Handover Signaling Interaction.........................................................................................................................2
2.1.2 Signaling Interaction for Intra-eNodeB Handover...................................................................................4
2.1.3 Signaling Interaction for Inter-eNodeB X2-based handover....................................................................5
2.1.4 Signaling Interaction for Inter-eNodeB S1-based handover....................................................................6
2.2 Handover-Related Parameters...........................................................................................................................7
2.2.1 Handover Threshold.................................................................................................................................7
2.2.2 Time-To-Trigger.......................................................................................................................................9
2.2.3 CIO.........................................................................................................................................................10
2.3 Handover Interaction on the User Plane..........................................................................................................10
3 Handover-Related KPIs..............................................................................................................12
3.1 Handover Success Rate....................................................................................................................................12
3.2 Control Plane Handover Delay........................................................................................................................12
3.3 User Plane Handover Delay.............................................................................................................................13
3.3.2 Uplink Application Layer Delay.............................................................................................................14
3.3.3 Downlink Application Layer Delay........................................................................................................14
3.3.4 Delay at the Uplink RLC Layer of the Network....................................................................................14
3.3.5 Delay at the Downlink RLC Layer of the Network................................................................................15
3.3.6 Delay at the Uplink RLC Layer of the Terminal....................................................................................15
3.3.7 Delay at the Downlink RLC Layer of the Terminal...............................................................................15
4 Handover Fault Identification Methods.................................................................................16

4.1 Identifying the Causes of Handover Failures..................................................................................................16
4.1.1 Abnormal Signaling over the Uu Interface.............................................................................................16
4.1.2 Abnormal Signaling over the X2 Interface.............................................................................................19

4.1.3 Abnormal Signaling over the S1 Interface.............................................................................................20
4.2 Identifying the Causes of Handover Delays....................................................................................................24
4.2.1 Identifying the Causes of Control Plane Handover Delays....................................................................24
4.2.2 Identifying the Causes of User Plane Handover Delays.........................................................................24
5 Operations for Handover Fault Identification.......................................................................26

5.1 Observing the Signaling...................................................................................................................................26
5.1.1 Observing the Signaling from the Network............................................................................................26
5.1.2 Observing the Signaling from the UE....................................................................................................27
5.2 Observing the User Plane Handover Delay.....................................................................................................27
5.2.1 Observing the Application Layer Delay.................................................................................................28
5.2.2 Observing the RLC Layer Delay............................................................................................................29
5.3 Solutions..........................................................................................................................................................30
6 Reference Cases...........................................................................................................................32
6.2 Handover Failures............................................................................................................................................35
6.2.1 After Sending Multiple Measurement Reports, a UE Fails to Receive a Handover Command.............35
6.2.2 Random Access Fails During a Handover..............................................................................................35
6.2.3 Problems in Encryption and Integrity Check Lead to Failure in Decoding Messages...........................37
6.2.4 Measurement Reports Are Lost..............................................................................................................38
6.2.5 Handover Commands Are Lost..............................................................................................................41
6.2.6 Due to Poor Downlink Channel Quality, UE Fails to Receive RAR After Sending the Preamble for a
Maximum of Times.........................................................................................................................................42
6.2.7 eNodeB Delivers an RRC Signaling Message, Waits for UE Response, and Does Not Process a
Handover Command........................................................................................................................................43
6.2.8 Incorrect X2 IPPATH Configuration Leads to Handover Failure..........................................................44
6.2.9 The Handover Place Is Distant From the Target Cell and Is Out of the Maximum Theoretical Access
Radius Specified By Ncs_Index.......................................................................................................................46
6.2.10 In an Inter-eNodeB X2-based handover, the Source Cell Sends Handover Request But Fails to
Receive Response............................................................................................................................................47
6.2.11 In an Inter-eNodeB X2-based handover, the Target Cell Sends S1AP_PATH_SWITCH_REQ and
Fails to Receive a Response............................................................................................................................47
6.2.12 Long Time in Inter-eNodeB X2-based handover Preparation Crosses the Handover Time................48
6.2.13 When a UE Processes a System Message, It Does Not Process a Handover Command.....................50
6.2.14 For Intra-eNodeB Handovers Where S_RSRP and N_RSRP Are High, a Small HO_TTT (64 Ms) Can
Trigger Handover Timely Before Signal Deterioration...................................................................................51
6.2.15 In Signal Overlapping Areas Where a Handover Can Be Easily Triggered, Frequent Incoming and
Outgoing Handovers Result in Sharply-Deteriorated Signals and Handover Failures...................................55
6.2.16 After the Handover Threshold Is Decreased, the Number of Ping-Pong Handovers Is Increased. Due
to Handover Timeliness, the Number of Handover Failures Is Decreased.....................................................59
6.3 Large User Plane Handover Delay..................................................................................................................59
6.3.1 Incorrect X2 IPPATH Configuration Leads to Long Handover Delay...................................................59
6.3.2 Retransmission of a Handover Command Leads to Long Handover Delay...........................................60
6.3.3 Consecutive CRC Errors of the Data Packets at the Source Cell Lead to Long Handover Delay.........61
6.3.4 Consecutive CRC Errors of the Data Packets at the Target Cell Lead to Long Handover Delay..........62
6.3.5 Retransmission of Preamble During Random access Leads to Long Handover Delay..........................63
6.3.6 UE Fails to Send or Is Late in Sending PDCP Status Report.................................................................65
6.4 Handover Failure Analysis Based on CHRs....................................................................................................65
6.4.1 Intra-eNodeB Handover Failure Caused by a Random Access Failure..................................................65
6.4.2 Intra-eNodeB Handover Failure Caused by the Lost Handover Complete Message.............................69
6.4.3 X2-based Handover Failure Caused by the Reason that the Source eNodeB Fails to Receive a Context
Release Command Before the Timer Expires..................................................................................................71
6.4.4 X2-based Handover Failure Caused by an S1 Path Switch Failure.......................................................73
6.4.5 Service Drop Caused by a Connection Reestablishment Failure During the Connection
Reestablishment Process Triggered by a Random Access Failure in a Handover...........................................77
6.4.6 Service Drop Caused by Deteriorating Channel Quality due to the eNodeB Failing to Respond to the
Handover Measurement Report from the UE..................................................................................................78
6.4.7 Handover Failure Caused by a Lost Handover Command.....................................................................80
6.4.8 X2-based Handover Failure Caused by a Lost Preamble.......................................................................82
6.4.9 X2-based Handover Failure Caused by the Reason that the Target eNodeB Does Not Receive the
S1PathSwitchAck Message Before the Timer Expires....................................................................................85
6.4.10 Service Drop Caused by a Lost Connection Reestablishment Completion Message During the
Connection Reestablishment Triggered by a Random Access Failure in a Handover....................................89
6.4.11 Intra-eNodeB Handover Failure Caused by a Connection Reestablishment Failure During the
Connection Reestablishment Triggered by a Random Access Failure............................................................91
6.4.12 Service Drop Caused by a Connection Reestablishment Failure During the Connection
Reestablishment Triggered by a Lost Handover Completion Message in an Intra-eNodeB Handover..........96
7 Reference........................................................................................................................................99
LTE Handover Troubleshooting and Optimization Guide
Acronyms and Abbreviations
Abbreviation Full Spelling

ANR Automatic Neighbor Relation
CCE Control channel Element
DRB Data Radio Bearer
PDCP Packet Data Convergence Protocol
RAR Random Access Response
SRB Signaling Radio Bearer
TAC Tracking Area Code
TAU Tracking Area Update
LTE Handover Troubleshooting and Optimization Guide 7 Overview
1 Overview
A characteristic of wireless communications is mobility control. When a UE moves across

cells, the network needs to monitor in real time the UE and commands the UE to hand over to
an appropriate cell at appropriate time to ensure service continuity. During handover, the UE
and the network work together to exchange handover signaling and to restore the service
quickly. In the long-term evolution (LTE) system, this handover process is hard handover,
meaning that services are interrupted during handover. The handover process needs to ensure
three important counters: handover success rate, handover interruption duration, and handover
throughput. The most important counter is the handover success rate. A handover failure
seriously affects user experience. The handover interruption duration and handover
throughput also affect user experience to various degrees. This document describes
troubleshooting for the handover problems based on our knowledge and experience in
troubleshooting for the intra-RAT handovers. Readers can use this document to optimize the
network performance.
LTE Handover Troubleshooting and Optimization Guide 7 Handover Principles
2 Handover Principles
2.1 Handover Signaling Interaction

A UE and several eNodeBs work together to perform handover. They exchange information
by signaling. A complete signaling interaction process is as follows:
 The source eNodeB controls the UE measurement by sending an RRC CONNECT

RECONFIG signaling to the UE over the Uu interface. Upon reception of this signaling,
the UE responds to the eNodeB to acknowledge that this signaling is received and is
being correctly processed.
 The UE acknowledges reception of the control message by sending an RRC CONNECT
RECONFIG CMP message to the eNodeB over the Uu interface. Then the UE performs
measurement as specified in the measurement control. Once conditions are satisfied, the
UE triggers a handover event measurement report.
 The UE sends the measurement report to the source eNodeB in the RRC
MEASUREMENT REPORT message over the Uu interface.
 If the source eNodeB decides to perform a handover upon reception of measurement
reports, the LTE network prepares the required handover information. This process is
invisible to the UE.
 The network prepares the required handover resources. Depending on the handover
scenarios, there are the following handover signaling interactions:
− Intra-eNodeB handover requires no extra signaling interaction.
− Handover between eNodeBs with a configured X2 interface (referred to as inter-
eNodeB X2-based handover) requires the HANDOVER REQUEST and
HANDOVER REQUEST ACK messages over the X2 interface.
− Handover between eNodeBs without a configured X2 interface (referred to as inter-
eNodeB S1-based handover) requires HANDOVER REQUIRED and HANDOVER
COMMAND messages over the S1 interface of the source eNodeB and HANDOVER
RQUEST and HANDOVER REQUEST ACK messages over the S1 interface of the
target eNodeB.
 The source eNodeB delivers the handover command by sending the RRC CONNNECT
RECONFIG message over the Uu interface.
Upon reception of the handover command, the UE disconnects from the source eNodeB (cell)
and attempts to access the target eNodeB (cell). This interaction process contains three
messages, but only the third (known as MSG3) is sent over the standard signaling interface
 The UE in the target cell sends MSG3 (handover completion message) by the RRC
CONNECT RECONFIG CMP message over the Uu interface.
 The inter-eNodeB S1-based handover does not involve the air interface and the
probability of failure is very small. It is unnecessary to describe troubleshooting for such
handover here.
The interactive messages for the preceding measurement control and handovers have the same
name (either RRC CONNECT RECONFIG or RRC CONNECT RECONFIG CMP), but their
content is different.
Figure 1-1 A reconfiguration command for handover

Figure 1-2 A reconfiguration command for measurement control
After a UE accesses a cell, the measurement control information is delivered to the UE

regardless of whether the UE is to perform a handover or not. The handover problems that are
of concern generally occur after the first handover event is triggered. Therefore, during fault
diagnosis for handover problems, you need to analyze the process after the first handover
event is triggered.
The signaling interaction varies for different handover types. In the LTE system, handovers
are classified into intra-eNodeB handovers and inter-eNodeB handovers; inter-eNodeB
handovers are classified into inter-eNodeB X2-based handovers and inter-eNodeB S1-based
handovers. The signaling flow of each of these types is described as follows:
2.1.1 Signaling Interaction for Intra-eNodeB Handover

Figure 1-3 shows the interaction between a UE and an eNodeB for intra-eNodeB handover.
Figure 1-3 Signaling interaction for intra-eNodeB handover
2.1.2 Signaling Interaction for Inter-eNodeB X2-based handover

Figure 1-4 shows the signaling interaction for inter-eNodeB X2-based handover.
Figure 1-4 Signaling interaction for inter-eNodeB X2-based handover
2.1.3 Signaling Interaction for Inter-eNodeB S1-based handover

Figure 1-5 shows the signaling interaction for inter-eNodeB S1-based handover.
Figure 1-5 Signaling interaction for inter-eNodeB S1-based handover
2.2 Handover-Related Parameters

To ensure the accuracy and timeliness of the handover signaling flow, the network uses three
parameters in the evaluation for event A3 triggering: handover threshold, time-to-trigger
(TTT), and cell individual offset (CIO). According to Huawei handover algorithm, a handover
is triggered by event A3.
2.2.1 Handover Threshold

In the current Huawei LTE system, the intra-frequency handover algorithm is triggered by
event A3 and the event reporting mode is event-triggered periodic reporting. When the quality
of a neighboring cell is higher than that of the serving cell by a preset value, event A3 is
triggered. According to 3GPP TS36.331, the conditions for event A3 are as follows:
Entering condition: Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + Off
Leaving condition: Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Off

where the variables in the formulas are defined as follows:
 Mn is the measurement result of the neighboring cell.

 Ofn is the frequency-specific offset of the neighboring cell and the default value is 0. It
is not considered in the evaluation for intra-frequency handover.
 Ocn is the cell-specific offset of the neighboring cell and is determined by the
CellIndividualOffset parameter. When the value is not zero, this parameter is delivered
in the measurement control message; when the value is zero, this parameter is not
delivered. The parameter value determines the occasion when an intra-frequency
handover is triggered.
 Ms is the measurement result of the serving cell.
 Ofs is the frequency-specific offset of the serving cell and the default value is 0. It is not
considered in the evaluation for intra-frequency handovers.
 Ocs is the cell-specific offset of the serving cell; the default value is zero.
 Hys is the hysteresis of event A3 and is determined by the IntraFreqHoA3Hyst
parameter. This parameter is delivered in the measurement control message.
 Off is the offset of event A3 and is determined by the IntraFreqHoA3Offset parameter.
This parameter is used by event A3 to adjust the degree of difficulty of a handover. The
sum of this value and the measurement value is used to evaluate event entering or
leaving. This parameter is delivered in the measurement object of the measurement
control message; its value can be positive or negative. In case of a positive value, the
difficulty in event triggering is increased to postpone handovers; in case of a negative
value, the difficulty is decreased to advance handovers.
The quantity that Mn and Ms measure is determined by IntraFreqHoA3TrigQuan

parameter. According to 3GPP TS36.331, this parameter is specified in the report
configuration of the measurement control message and can be either RSRP or RSRQ. RSRP is
used by Huawei as the default value.
Figure 1-6shows the event A3 triggering mechanism. Within time-to-trigger, when conditions
are satisfied for triggering event A3, the UE reports event A3 in event-triggered periodic
reporting mode.
Figure 1-6 Event A3 triggering mechanism
In an intra-frequency handover, the serving cell and the neighboring cell use the same
frequency. In this case, the value of Ofn and the value of Ofs are both 0; the value of Ocs is 0
in ordinary situations. Therefore, the event A3 entering condition can be simplified as follows:
Mn -Hys>Ms +Off, that is, Mn > Ms +Off + Hys.
where Off and Hys, in units of 0.5 dB, are determined by the IntraFreqHoA3Offset and
IntraFreqHoA3Hyst parameters. The two parameters can be set by running the MOD
INTRARATHOQCI command as follows:
MOD INTRARATHOQCI: LocalCellId=0, QCI=1, IntraFreqHoA3Hyst=4,

IntraFreqHoA3Offset=4
Mn > Ms +Off + Hys = Ms + 4* 0.5 + 4 * 0.5 = Ms + 4dB
In this example, if the RSRP of the neighboring cell is 4 dB higher than that of the serving
cell, event A3 is triggered,
2.2.2 Time-To-Trigger
To prevent unnecessary handovers, a time-to-trigger is introduced so that event A3 is
triggered only when the measurement results meet the triggering condition during the time-to-
trigger.
The following is an example.
MOD INTRARATHOQCI: LocalCellId=0, QCI=1, IntraFreqHoA3TimeToTrig=640ms

In this example, the value of Time-To-Trigger is 640 ms, meaning event A3 is reported only if
the triggering condition is continuously satisfied for 640 ms.
2.2.3 CIO
The CIO of each cell is set independently. When signals fluctuate, it is necessary to adjust the
degree of difficulty in outgoing handovers or incoming handovers of a cell. According to
3GPP TS36.331, the event A3 triggering condition is as follows:
Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + Off
After removing the parameters whose values are zero in Huawei implementation, the
triggering condition is simplified as follows:
Mn + Ocn – Hys > Ms + Off
where Ocn refers to CIO. The CIO determines the boundary for handovers. The easiness in
handover has a positive correlation with the CIO of the target cell. Huawei MRO algorithm
can automatically adjust CIOs.
The CIO is delivered in the information element (IE) Neighbor cell list in the measurement
control message. The CIO is delivered only if the CIO is not zero.
2.3 Handover Interaction on the User Plane

Hard handover is implemented in the LTE system, meaning that the UE disconnects from the
source cell upon reception of a handover command. Before the UE begins to interact with the
target cell, the user plane is interrupted for tens of milliseconds, which has little impact on the
service. However, longer interruption duration affects user experience.
Figure 1-7shows the interaction on the user plane during handover.

Figure 1-7 Interaction on the user plane
Huawei eNodeB implements a handover on the user plane as follows:
2. At the time that the eNodeB delivers the handover command, the source cell stops
sending data at the PDCP layer and RLC layer, though the HARQ queue at the MAC
layer has some retransmission data to send over the air interface.
3. Upon reception of the handover command, the UE stops sending and receiving data to
and from the source cell.
4. After sending MSG3 (handover completion message) to the target cell, the UE can send
uplink data to and receive downlink data from the target cell.
Due to misaligned timing for inter-eNodeB handovers, the inter-eNodeB handover delay
cannot be accurately calculated. In the following chapters, the handover delay refers to intra-
eNodeB handover delay.
LTE Handover Troubleshooting and Optimization Guide 7 Handover-Related KPIs
3 Handover-Related KPIs
The handover-related KPIs are handover success rate, control plane handover delay, and user
plane handover interruption and delay.
3.1 Handover Success Rate

The handover success rate is defined as follows:
Handover success rate = number of successful handovers / number of handover attempts *

100%.
The measurement value of the handover success rate varies depending on the measurement
point for a handover attempt. For example, the value of handover attempts can be incremented
by one once the eNodeB receives a measurement report or issues a handover command. The
handover success rate also depends on whether it is calculated from the UE or the eNodeB. In
case of the former, the handover success rate is calculated from the UE data obtained from a
drive test; in case of the latter, the handover success rate is calculated from the message trace
or traffic statistics.
3.2 Control Plane Handover Delay

A control plane handover delay refers to the interval between the handover command and the
handover completion message, which is the interval between line 154 and line 155 shown in
the following figure.
A control plane handover delay can be calculated from the signaling traced on the network, or
the signaling traced on the UE, the former being greater than the latter.
3.3 User Plane Handover Delay

The interruption duration on the user plane significantly affects user experience. The user
plane handover delay is divided into uplink delay and downlink delay. The uplink and
downlink interruption durations on the user plane can be calculated at any of the following
layers: MAC, RLC, PDCP, application layer. The interruption duration at the application layer
is closest to those experienced by users.
Figure 1-1 Protocol stack on the Uu interface
Figure 1-1shows the protocol layers for data transmission between a terminal and the
network. The uplink data transmission is indicated by the black arrow, the downlink data
transmission by the red arrow. In between the PDCP layer and the IP layer there is a dashed
line, indicating that there are other transmission nodes. For example, if a laptop is connected
to the terminal, the application layer software (for example, QQ program) is installed on the
laptop, and the QQ server is installed on a Web Server in the Internet. Once data transmission
is interrupted for some time, the protocol layers at the transmission line generate delays. This
is why delays can be measured at different protocol layers. During a delay test, you need to
inject packets in the correct direction at full rate. This avoids the problem that data delay at
the application layer gives rise to delay at the other layers.
The user plane handover delay is defined as the interval between the last data packet sent or
received before a handover and the first data packet sent or received after the handover by a
protocol layer. The user plane handover delay can be calculated from the terminal or the
network. In practice, the uplink and downlink delays at the application layer and the RLC
layer are of concern.
3.3.1 Uplink Application Layer Delay

By analyzing the uplink packets captured by the server, the network can calculate the uplink
interruption duration at the application layer delay, which is defined as the maximum
handover-caused interruption duration during a handover process. This definition is not
scientifically well grounded as it does not specify the handover process and is subject to
various uncertainties. In practice, the time window of handover period cannot be aligned.
Even if it can, the application layer delay lags the handover delay for some time. In addition,
the intervals of the data packets captured by the packet capturer vary and are influenced by
multiple factors such as core network, external network, and packet size at the application
layer. In an actual test, inject small UDP packets so that the interruption duration can be
adjusted by controlling the number of packets transmitted during a time unit. This minimizes
the delay caused by external factors other than handover.
3.3.2 Downlink Application Layer Delay

By analyzing the downlink packets captured by the UE, the network can calculate the
downlink interruption duration at the application layer delay, which is defined as the
maximum handover-caused interruption duration during a handover process. This definition is
not scientifically well grounded as it does not specify the handover process and is subject to
various uncertainties. In practice, the time window of handover period cannot be aligned.
Even if it can, the application layer delay lags the handover delay for some time. In addition,
the intervals of the data packets captured by the packet capturer vary and are influenced by
multiple factors such as core network, external network, and packet size at the application
layer. In an actual test, inject small UDP packets so that the interruption duration can be
adjusted by controlling the number of packets transmitted during a time unit. This minimizes
the delay caused by external factors other than handover.
3.3.3 Delay at the Uplink RLC Layer of the Network

This is defined as the delay between the last PDU that the source eNodeB receives at the RLC
layer and the first PDU that the target eNodeB receives at the RLC layer. This delay is
applicable to intra-eNodeB handovers. This delay cannot be calculated for inter-eNodeB
handovers due to asynchronous clocks.
3.3.4 Delay at the Downlink RLC Layer of the Network

This is defined as the delay between the last PDU sent the source eNodeB at the RLC layer
and the first PDU sent by the target eNodeB at the RLC layer. This delay is applicable to
intra-eNodeB handover. This delay cannot be calculated for inter-eNodeB handovers due to
asynchronous clocks.
3.3.5 Delay at the Uplink RLC Layer of the Terminal

This is defined as the delay between the last PDU sent by the UE at the RLC layer at the
source cell and the first PDU sent by the UE at the RLC layer at the target cell.
3.3.6 Delay at the Downlink RLC Layer of the Terminal

This is defined as the delay between the last PDU received by the UE at the RLC layer at the
source cell and the first PDU received by the UE at the RLC layer at the target cell.
LTE Handover Troubleshooting and Optimization Guide 7 Handover Fault Identification Methods
4 Handover Fault Identification Methods
4.1 Identifying the Causes of Handover Failures

A handover failure refers to the failure in signaling interaction during a handover. The focus is
on the signaling interaction. A handover failure is caused by loss of signaling or failure in
signaling processing. Loss of signaling indicates that errors occur during transmission of a
signaling message or that the signaling message cannot reach the target. Failure in signaling
processing indicates that errors occur when the terminal or network processes the signaling,
leading to aborted processing, as caused by insufficient resources during a handover.
Depending on the transmission medium, failures in signaling transmission are categorized
into failure in wireless transmission and failure in wire transmission. Transmission over the
X2 or S1 interface is wire transmission; transmission over the Uu interface is wireless
transmission. The probability of failure in wire transmission is small; the probability of failure
in wireless transmission is large, especially in handover areas of poor signal quality.
4.1.1 Abnormal Signaling over the Uu Interface

There are three signaling messages over the Uu interface for handovers: measurement report
(MEASUREMENT REPORT), handover command (RRC CONN RECFG), and handover
completion (RRC RECFG CMP). During troubleshooting of a call drop problem or
reestablishment problem immediately after a handover, the first RRC CONN RECFG
message after the handover is of concern. Strictly speaking, the reconfiguration message after
a handover is irrelevant to the handover and the message is unpredictable.
Figure 1-2 Signaling messages over the Uu interface during a handover
The causes of abnormal signaling over the Uu interface are as follows:
1. Loss of a measurement report. The possible causes are:

 Measurement reports are lost between layers inside the UE. For example, when L3 sends
a measurement report to L2, L2 fails in processing the report.
 The UE fails to receive the uplink scheduling grant for sending the measurement report.
The PDCCH is restricted.
 The measurement report sent by the UE is not received by the eNodeB, or received with
CRC errors. The PUSCH is restricted.
2. Loss of a handover command. The possible causes are:
 The eNodeB does not deliver a handover command due to errors in handover processing,
as caused by missing definition of neighboring cells or insufficient resource.
 The UE fails in demodulating the PDCCH.
 The UE fails in demodulating the PDSCH.
3. Loss of a handover completion message. The possible causes are:
 The preamble sent by the UE at the target cell is not received by the eNodeB.
 The UE fails to receive the random access response (RAR). The PDSCH is restricted.
 The handover completion message sent by the UE is not received by the eNodeB. The
PUSCH is restricted.
The transmission over the Uu interface is wireless transmission. The channel quality can be
analyzed from the downlink and uplink. If a UE can obtain the RSRP, SINR, IBLER,
downlink scheduling assignments, and uplink scheduling grants, and work with the network
to implement signaling trace, the channel quality on the uplink and downlink can be
determined. The channel quality can be evaluated from the following points:
 RSRP: RSRP refers to the downlink pilot received power. Though the pilot channel
quality is different from the traffic channel quality, the RSRP and SINR of the pilot
channel roughly reflect the traffic channel quality. Generally the RSRP is more than -85
dBm for UEs near an eNodeB, equal to -95 dBm for UEs at the middle of the eNodeB,
and less than -105 dBm for UEs distant from the eNodeB. The position of a UE relative
to the eNodeB cannot fully reflect the UE's channel quality. This is especially so for
loaded scenarios, where the channel quality of the UEs at the middle of or near the
eNodeB is still unsatisfactory. This is because when the RSRP of the neighboring cell is
near the RSRP of the serving cell, the interference is large. In such cases, other counters
need to be used to determine the channel quality.
 SINR: SINR refers to the downlink pilot SINR. The pilot SINR roughly reflects the
traffic channel quality. If SINR is less than 0 dB, the downlink channel quality is poor. If
SINR is less than -3 dB, the downlink channel quality is very poor and close to the
demodulation threshold, which can easily cause loss of handover signaling messages and
handover failure. The uplink SINR can be obtained from the user performance tracing on
the LMT.
 IBLER: Generally IBLER should be near the target value of 10%. When the channel
quality is very good, IBLER is close to or equal to 0%. If IBLER is very high, the
channel quality is poor with bit errors and can cause call drops, handover failures, or
long handover delay. The downlink IBLER can be obtained from the UE Probe and the
uplink IBLER can be obtained from the user performance tracing on the LMT, the latter
being more accurate than the former.
 Uplink scheduling grants and downlink scheduling assignments over the PDCCHs: The
number of PDCCHs correctly demodulated by a UE can be calculated from the downlink
scheduling assignments. When there are enough uplink and downlink data sources, such
as uplink and downlink UDP injection at maximum rate, the eNodeB schedules users in
each TTI, and the number of PDCCHs is 1000. If the number of uplink grants is 999 or
1000, the PDCCHs are demodulated correctly and the channel quality is good. If the
number of uplink grants is too low, the PDCCHs are demodulated incorrectly and the
channel quality is poor.
Poor uplink channel quality may cause loss of downlink signaling; poor downlink channel
quality may cause loss of uplink signaling. For example, poor downlink channel quality not
only affects demodulation of the downlink signaling; the incorrectly demodulated PDCCHs
also affects the uplink scheduling, leading to loss of uplink signaling. Poor channel quality is
generally caused by weak coverage or interference.
The causes of air interface problems are categorized into coverage (weak coverage or cross-
cell coverage), interference, missing definition of neighboring cell, and delayed handover. If
the causes are clear, solutions can be available.
4.1.2 Abnormal Signaling over the X2 Interface

Only inter-eNodeB X2-based handovers have the following signaling messages over the X2
interface: HANDOVER REQUEST, HANDOVER REQUEST ACK, SN STATUS
TRANSFER, and UE CONTEXT RELEASE, as indicated by the red arrows in Figure 1-1.
Figure 1-1 Signaling messages over the X2 interface during an inter-eNodeB X2-based handover
The causes of abnormal signaling over the X2 interface are as follows:
1. Loss of a HANDOVER REQUEST message. The possible causes are:

 Processing of a measurement report by eNodeB is abnormal, as may be caused by
missing definition of neighboring cell or failure of the internal module.
 Abnormal transmission over the X2 interface, such as loss of packets.
2. Loss of a HANDOVER REQUEST ACK. The possible causes are:
 The source cell is abnormal. Specifically, the source cell sends a HANDOVER CANCEL
message to the target cell over the X2 interface before the target cell sends a
HANDOVER REQUEST ACK message.
 Handover preparation in the target cell is abnormal. In this case, the target cell sends a
HANDOVER PREPARATION FAILURE message to the source cell over the X2
interface.

3. Loss of an SN STATUS TRANSFER message. The possible causes are:
 The source cell is abnormal.
4. Loss of a UE CONTEXT RELEASE message. The possible causes are:
 The target cell fails in processing the received handover completion message, leading to
S1 path switching failure.
 S1 path switching fails.
Abnormal messages over the X2 interface are generally caused by transmission failure at a
higher probability or processing errors of the eNodeB at a lower probability. It is difficult to
identify a transmission failure. The packets transmitted between the two ends need to be
captured for further analysis.
4.1.3 Abnormal Signaling over the S1 Interface

For inter-eNodeB X2-based handovers, there are S1AP PATH SWITCH REQ message and
S1AP PATH SWITCH REQ ACK message over the S1 interface. For inter-eNodeB S1-based
handovers, there are more signaling messages over the S1 interface of the target cell and the
S1 interface of the source cell. The signaling messages over S1 are indicated by green arrow
in Figure 1-1and Figure 1-2
Figure 1-1 Signaling messages over S1 during an inter-eNodeB X2-based handover

Figure 1-2 Signaling messages over S1 during an inter-eNodeB S1-based handover
Abnormal signaling over the S1 interface is caused by the following factors:
1. Loss of S1AP PATH SWITCH REQ during an inter-eNodeB X2-based handover. The
possible causes are:
 The target eNodeB fails in processing the handover completion message.
 Abnormal transmission over the S1 interface, such as loss of packets.
2. Loss of S1AP PATH SWITCH REQ ACK during an inter-eNodeB X2-based handover.
The possible causes are:
 The core network fails in processing the S1AP PATH SWITCH REQ message.
3. Loss of the S1AP HANDOVER REQUIRED message during an inter-eNodeB S1-based
handover. The possible causes are:
 The source cell does not deliver an S1AP HANDOVER REQUIRED message due to
errors in handover processing, as caused by missing definition of neighboring cells or
insufficient resource.
 Abnormal transmission over S1, leading to loss of packets.
4. Loss of the S1AP HANDOVER REQUEST message during an inter-eNodeB S1-based
 The core network fails in processing the S1AP HANDOVER REQUIRED message.
 Abnormal transmission over S1, leading to loss of packets.
5. Loss of the S1AP HANDOVER REQUEST ACK during an inter-eNodeB S1-based
 The target cell fails in processing the S1AP HANDOVER REQUEST, as caused by
insufficient resources.
 Abnormal transmission over the S1 interface, leading to loss of packets.
6. Loss of an S1 HANDOVER CMD during an inter-eNodeB S1-based handover. The
possible causes are:
 The core network fails in processing the S1AP HANDOVER REQUEST ACK.
7. Loss of an S1AP ENB STATUS TRANSFER message during an inter-eNodeB S1-based
 The source cell fails n processing the S1 HANDOVER CMD.
8. Loss of an S1AP MME STATUS TRANSFER message during an inter-eNodeB S1-
based handover. The possible causes are:
 The core network fails in processing the S1AP ENB STATUS TRANSFER message.
9. Loss of an S1AP HANDOVER NOTIFY message during an inter-eNodeB S1-based
 The target cell fails in processing the HANDOVER CMP message.
10. Loss of an S1AP UE CONTEXT RELEASE command during an inter-eNodeB S1-based
 The core network fails in processing the S1AP HANDOVER NOTIFY message.
11. Loss of an S1AP UE CONTEXT REL CMP message during an inter-eNodeB S1-based
 The source cell fails in processing the S1AP UE CONTEXT REL CMD.
Abnormal messages over the S1 interface are generally caused by transmission failure at a
higher probability or processing errors of the network devices at a lower probability. It is
difficult to pinpoint a transmission failure. The packets transmitted between the two ends need
to be captured for further analysis.
4.2 Identifying the Causes of Handover Delays

Handover delays are categorized into control plane handover delays and user plane handover
delays.
4.2.1 Identifying the Causes of Control Plane Handover Delays

Control plane handover delays can be measured from the network or the terminal. In both
cases, a control plane handover delay refers to the delay between a handover command and a
handover completion message. Due to the fact that the control plane handover delay measured
from the network includes the delay of two times of transmission over the air interface, this
delay is larger than the delay measured from the terminal. The clocks of an inter-eNodeB
handover cannot be aligned for calculating the control plane handover delay measured from
the network. Therefore, only the control plane handover delay of intra-eNodeB handovers is
measured from the network. Taking Samsung UE as an example, the control plane handover
delay measured from the terminal is 31 ms (or 8 ms for Huawei UE); the delay measured from
the network (for intra-eNodeB handovers) is 38 ms.
The control plane handover delay measured from the terminal consists of signaling processing
delay, target cell synchronization delay, and target cell access delay, where the last one is the
majority. The control plane handover delay measured from the network consists of the control
plane handover delay measured from the terminal and the delay in transmission of two
signaling messages over the air interface. The causes of large control plane handover delay
are as follows:
 The handover command is retransmitted over the air interface. This delay is included on
the network side.
 The terminal attempts to access the target cell for multiple times. This delay is included
on both the network and UE sides.
 Large period of PRACH scheduling increases the delay.
To identify the causes of a control plane handover delay, you need to trace the detailed
internal messages of both the terminal and the network. At present, these internal messages
are mostly the TTI data from the network and terminal.
4.2.2 Identifying the Causes of User Plane Handover Delays

There are different definitions of a user plane handover delay, depending on where the delay
is measured. The one most closely related to user experience is the application layer delay. In
practice, this delay is measured at the IP layer of the server or the terminal. The application
layer delay traverses the access network, core network, and public network. The user plane
handover delay of the access network can be measured from the RLC layer of the access
network. This is referred to as the RLC layer delay, in contrast to the application layer delay.
A handover delay consists of two directions: uplink and downlink. Due to the time alignment
problem, the RLC layer delay of the access network in the uplink and downlink directions can
be measured only from the terminal. In the future, if required, we can provide RLC layer
delay measured from the eNodeB for intra-eNodeB handovers. The downlink RLC layer
delay measured by Huawei UE is 34 ms. The IP layer delay fluctuates substantially, which is
120 ms for the uplink and 60 ms for the downlink.
The causes of the user plane handover delays of the access network are as follows:
 The handover command delivered by an eNodeB is retransmitted, leading to suspended

downlink user plane data transmission.
 The air interface at the handover area is of poor quality, leading to retransmitted
downlink or uplink user plane data.
 It takes a long time for the UE to access the target cell, leading to slow recovery of the
user plane data.
 The transmission over the X2 or S1 interface is prolonged, mainly affecting the
application layer delay.
 Large period of PRACH scheduling increases the signaling delay.
To identify the causes of a user plane handover delay, you need to trace the detailed messages
of both the terminal and the network. At present, these messages are mostly the TTI data from
the network and terminal.
LTE Handover Troubleshooting and Optimization Guide 7 Operations for Handover Fault Identification
5 Operations for Handover Fault

Identification
Before troubleshooting a handover problem, determine whether this problem is on the control
plane or the user plane. To identify the causes of a handover failure or control plane handover
delay, you need to analyze the signaling interactions; to identify the causes of a user plane
handover delay, you need to analyze the scheduling of the user plane data.
5.1 Observing the Signaling

Signaling can be observed from both the network and the terminal. In case of a handover
failure or control plane handover delay, you need to trace the signaling.
5.1.1 Observing the Signaling from the Network

You can observe the signaling over the Uu, X2, and S1 interfaces from the eNodeB on the
LMT or trace a single UE on the M2000. Then, identify the causes of the problems by
referring to 4 "Handover Fault Identification Methods." For an inter-eNodeB handover, clocks
of the two eNodeBs cannot be aligned. Therefore, the control plane delay of an inter-eNodeB
handover cannot be calculated. The control plane delay of an intra-eNodeB handover can be
calculated from the messages over the Uu interface traced on the LMT. The control plane
handover delay shown in Figure 1-1is calculated as follows: 7568473 – 7530630 = 37843 μs,
or 37.843 ms.
Figure 1-1 Handover signaling interaction over the Uu interface traced from the network
5.1.2 Observing the Signaling from the UE

You can observe the signaling from the terminal by using Huawei UE Probe or Samsung UE
X-CAL. Then, identify the causes of the problems by referring to 4 "Handover Fault
Identification Methods." The control plane handover delay can be calculated from the
messages over the Uu interface traced by Huawei UE Probe. The control plane handover
delay shown in Figure 1-2is calculated as follows: 597054419 – 597047103 = 7316 μs, or
7.316 ms.
Figure 1-2 Handover signaling interaction traced from Huawei UE Probe
5.2 Observing the User Plane Handover Delay

In practice, the IP layer delay is calculated using the same method as the user plane handover
delay. That is, an IP packet capturer is installed on the terminal (laptop) or the server to
calculate the IP layer delay. To highlight the delay of the access network, the RLC layer delay
is used.
5.2.1 Observing the Application Layer Delay

The application layer delay can be calculated by using the time when the IP packets are
captured. This is applied to both uplink and downlink. In the downlink, the terminal (for
example, a laptop) captures the packets; in the uplink, the server captures the packets.
Common packet capturers are Ethereal and Wireshark.
Figure 1-3 Packet capture at the IP layer
The difference between the actual handover delay and the IP layer delay calculated from the
packet capturer is more than a millisecond. Therefore, the IP layer delay may not be very
accurate.
You can use Samsung UE X-CAL to calculate the downlink IP layer delay. Choose Message
> Packet Capture View > File Menu > Manual Capture, and select a UE to trace data
packets.
Figure 1-4 Packet capture by X-CAL
5.2.2 Observing the RLC Layer Delay

The uplink and downlink RLC layer delays can be calculated from the UE or the network.
Following describes the detailed operations.
Assume that Probe and Huawei UEs are used. Log in to Huawei OMT and set L2 Interrupt
Time. This function is disabled by default due to the fact that reporting of the handover delay
affects the peak rate test.
Figure 1-5 Setting L2 Interrupt Time on the OMT

When L2 Interrupt Time function is enabled, the Probe shows the statistics of the handover
delays, including the uplink RLC layer delay, which is indicated by
RLCHoULInterruptTime in Figure 1-6, and the downlink RLC layer delay, which is
indicated by RLCHoDLInterruptTime in Figure 1-6. This figure shows that the value of
RLCHoDLInterruptTime is 29197 μs, or 29.197 ms, and the value of
RLCHoULInterruptTime is 17181 μs, or 17.181 ms.
Figure 1-6 User plane handover delay traced from the Probe
5.3 Solutions
The causes of handover problems can be classified into transmission, internal processing,
coverage (weak coverage or cross-coverage), interference, missing definition of neighboring
cells, and delayed handover. After the causes are identified, solutions can be proposed and
actions can be taken.
If a handover problem is caused by transmission, particularly trans-city transmission that is

error prone, capture packets from a terminal nearest to the eNodeB and analyze the result. If a
handover problem is caused by internal processing, analyze the logs of the concerned network
devices. If a handover problem is caused by weak coverage, cross coverage, interference,
missing definition of neighboring cell, or delayed handover, the signaling messages may be
lost. These are radio interface problems, and the corresponding solutions are described as
follows:
 In case of weak coverage, adjust the antenna or power, or add more sites to increase the
coverage.
 In case of cross coverage, adjust the antenna to avoid the cross coverage.
 In case of interference, remove any external interference; enable ICIC or frequency

selective scheduling under multi-user scenario or loaded scenario.
 In case of missing definition of neighboring cell, add the neighboring cell from the
operation and maintenance terminal.
 In case of delayed handover, adjust the handover-related parameters such as handover
threshold, hysteresis, time-to-trigger, and CIO to adjust the handover time.
LTE Handover Troubleshooting and Optimization Guide 7 Reference Cases
6 Reference Cases
The following are cases extracted from LTE eRAN1.1 Handover Troubleshooting and
Optimization Guide V1.1 for reference. The troubleshooting methods for handover failures
and user-plane handover delay are as follows:
Figure 1-7 Handover failure analysis process

Figure 1-8 User-plane delay analysis process
The following table lists troubleshooting methods for various problems.
Cause of
Handover Troubleshooting Method
Failure
Use the Probe to observe the RSRP, SINR, IBLER, downlink scheduling assignments, and
Channel
uplink scheduling grants; Use the LMT to trace user performance and analyze the uplink and
quality
downlink channel quality.
Network
Analyze the network plan for cross coverage; adjust the tilt of the RET antenna, and configure
optimization
the neighboring cell relationship at the cluster border correctly.
problem
Run MML commands to display missing definition of neighboring cells, X2 configuration,
Configuration
random access configuration (Ncs_index, where cs refers to cycle shift), and authentication
problem
configuration.
Transmission Check the alarms for link break; check transmission stability. This problem is probabilistic and
problem cannot be analyzed from the logs.
Bugs of the wireless products and core network products may cause probabilistic handover
Product
failure. Imperfect functions lead to poor handover performance. Consult the R&D engineers to
problem
further analyze the problem.
Cause of Long Handover Delay Solution
Retransmission of Incorrect CRC of source eRAN1.0 B060SPC350 provides the following functions:
data packets data packets
 Upon reception of a measurement report, the source L3
instructs L2 to use low-order MCS on succeeding data.
 MCS order is configurable.
 The corresponding PDCCH power is increased.
Cause of Long Handover Delay Solution

 The control channel element (CCE) aggregation is
fixed to eight.
eRAN1.0 B060SPC350 provides the following functions:
 After a handover is complete at the target, a timer is
started. Before the timer expires, data is transmitted at
low-order MCS. The MML command is as follows:
Incorrect CRC of target data SET HOMCSPARAM: MCSHOSTATIC=0,
packets HOCQIRPTTIMER=60ms;
 MCS order is configurable by MML commands.
 The CCE aggregation is fixed to eight.
Frequency-selective
scheduling is enabled during eRAN1.0 B060SPC340 corrects this as follows: No
HARQ retransmission of the frequency-selective scheduling during HARQ
handover command (a bug retransmission.
of the software codes)
eRAN 1.0 B060SPC350 corrects this as follows:
Retransmission of  The PDCCH power corresponding to a handover
the handover command is increased. The CCE aggregation is fixed to
command eight.
Handover-command-related
PDCCH and PDSCH are  The PDSCH power corresponding to a handover
restricted. command is increased, and MCS 1 is used to transmit
the handover command.
 HARQ and ARQ retransmissions are enabled on the
eNodeB. These functions are disabled by default due to
the commercial terminal capability.
Coverage is optimized and handover parameters are
Preamble retransmission during a random access adjusted to provide better channel quality at the handover
area and to reduce retransmissions.
Check the X2 configuration, such as X2 interface and
X2 configuration
IPPATH.
eRAN1.0 B060SPC360 UE provides the following
function:
UE processing procedure  If an RRC CONN RECFG message is received during

a system message update, the update procedure is
interrupted and the RRC CONN RECFG message is
processed in higher priority.
6.1 Handover Failures
6.1.1 After Sending Multiple Measurement Reports, a UE Fails to

Receive a Handover Command.
When the automatic neighbor relation (ANR) function is disabled, the UE cannot perform
handover if the neighbor relationship is not configured.
Check whether the configuration on the eNodeB is faulty and whether a neighboring cell is
missing. For example, when a UE wants to hand over from cell A to cell B and sends
measurement reports, the measurement reports are not processed if cell A has not configured
cell B as neighboring cell. Therefore, no handover command is delivered, and the handover
fails. In this case, if the UE moves farther away from the serving cell, the signal worsens, until
the call drops.
Run the following commands to check for missing definition of neighboring cells:
LST EUTRANEXTERNALCELL (for listing external cells)
LST EUTRANINTRAFREQNCELL (for listing intra-frequency neighboring cells)
In eRAN1.0, intra-frequency neighboring cells must be configured for a UE to perform intra-

eNodeB handovers; external cells and intra-frequency neighboring cells must be configured to
perform inter-eNodeB handovers. Generally, external cells and intra-frequency neighboring
cells must be mutually configured on cell A and cell B for the UE to perform bidirectional
handover.
In eRAN1.1, there is no need to configure intra-frequency neighboring cells for a UE to

perform intra-eNodeB handovers; only external cells need to be configured to perform inter-
eNodeB handovers.
6.1.2 Random Access Fails During a Handover.

Check parameter settings. The random access performance is related to the Ncs_Index; an
Ncs_Indexes is mapped to a maximum theoretical access radius. If a UE initiates a random
access outside the maximum theoretical access radius, there is a high likelihood that the
preamble does not match the RAR, leading to random access failure. The reason is as follows:
After propagating the wireless channel, the preamble arrives the eNodeB late; and the
previous preamble ID is demodulated by the eNodeB in the reception window, leading to
inconsistent RAR and preamble.
When this problem occurs, the OMT displays the following information.
The following table lists the maximum theoretical access radius of each Ncs_Index.
If a cell coverage is large (as in suburb areas), the distance between the handover place and
the target cell may be more than the maximum theoretical access radius, leading to random
access failure and subsequent handover failure. This problem can be solved by increasing
Ncs_Index.
6.1.3 Problems in Encryption and Integrity Check Lead to Failure

in Decoding Messages.
The live network has multiple eNodeBs. Generally a network has multiple tracking area lists
(TALs), each of which has multiple tracking area codes (TACs), each of which has multiple
cells. When the UE performs an inter-TAC handover while moving, the UE performs tracking
area update (TAU).
If a drive test shows that handovers always fail after a TAU, the symptom being the target
eNodeB fails to receive the handover completion message from the UE, run LST
S1SECPARA to check the parameter settings in the core network.
The inter-TAU authentication and intra-TAU authentication as circled in red in the preceding
figure should be disabled. USN1.1 has not provided these two authentication functions.
If the inter-TAU and intra-TAU authentications are enabled, the core network notifies the
eNodeB to update the key; the UE has to update the key accordingly. At present, none of the
core network, eNodeB, and UE supports TAU authentication, leading to handover failure after
TAU by the UE. The reason is as follows: The UE has not updated the key and still uses the
old key to send the handover completion message; the target eNodeB uses the new key to
demodulate the handover completion message and fails in integrity check.
If the setting of the security encryption algorithm on the source cell is inconsistent with that in
the target cell, the target cell L2 fails to perform integrity check and asks L3 to release the UE.
The baseband unit of the target cell receives the handover completion message, the message
fails to be decoded due to integrity check failure. The signaling trace shows that the UE sends
a handover completion message but the eNodeB does not receive this message. In this case,
run DSP ENODEBSECCAP to check the setting of the encryption algorithm.
The setting of the encryption algorithm in the source eNodeB should be consistent with that in
the target eNodeB.
6.1.4 Measurement Reports Are Lost.

Check whether the loss of measurement reports is caused by poor uplink channel quality.
The following are two cases of loss of measurement reports caused by poor downlink channel
quality in loaded downlink scenarios.
Case 1: In a drive test of a live network, measurement reports are lost for eight times. In each
time, the S_RSRP is within -115 dBm; under the situation that the uplink of other cells is
unloaded (no uplink interference), the uplink is not limited when S_RSRP is within -115
dBm. Therefore, loss of measurement reports is not caused by poor uplink channel quality.
Case 2: In a drive test of a live network, measurement reports are lost for eight times. In each
time, the downlink channel quality is poor; the SINR is a negative value near the
demodulation threshold; IBLER is abnormal; and the number of downlink scheduling
assignments is too low. Under the situation of downlink packet injection at full capacity, the
number of downlink scheduling assignments demodulated by the UE should be 1000 or 999.
If this value is too low, there is a problem with PDCCH demodulation. If the number of uplink
scheduling grants is too low, the number of uplink scheduling grants demodulated by the UE
is decreased due to the PDCCH demodulation problem.
The following figures show the UL grant count.
01:45:06.296 PCI56->PCI65
02:08:11.796 PCI264->PCI295
The UE inter-layer message trace shows that when the UE is required to send measurement
reports, the number of scheduling request retransmissions reaches the maximum value,
triggering D_RRC_MAC_RA_IND, and that the random access triggered by the scheduling
requests fails, starting the RRC random access. The fact that the number of scheduling request
retransmissions reaches the maximum value indicates that the uplink scheduling grants have
not been demodulated for sending the measurement reports.
In summary, loss of the measurement reports is not caused by poor uplink channel quality.
Rather, the downlink channel quality deteriorates in the loaded scenario, leading to failure of
the UE in demodulating the PDCCH. Therefore, the UE fails to demodulate the uplink
scheduling grants and to send the measurement reports.
This conclusion can be verified by a test: After the uplink pre-allocation is enabled, the
number of lost measurement reports is decreased significantly.
6.1.5 Handover Commands Are Lost.

The following is drive test data in the scenario of 50%Load_woICIC.
23:45:59.062 PCI48->PCI50 UE fails to receive the handover command.
The neighboring cell signal at this handover area rises sharply by 6 dB, causing high
interference to the serving cell; the downlink SINR is -5 dB; the UE cannot demodulate the
handover command correctly.
This problem can be solved by adjusting the antennas and modifying the CIO of the two cells
to advance the handover.
6.1.6 Due to Poor Downlink Channel Quality, UE Fails to Receive

RAR After Sending the Preamble for a Maximum of Times.
The following analyzes the channel quality at the handover area:
The drive test shows that in 100% loaded scenario, there are twelve handovers where the
eNodeB fails to receive the handover completion message. The S_RSRP at each handover
place is high. In the unloaded uplink scenario, the uplink is not restricted. The downlink
channel quality is analyzed as follows: The SINRs are low and are negative values; the
downlink IBLERs are not at normal range, indicating that in 100% downlink loaded scenario,
the downlink interference is large and the channel quality is poor.
The OMT trace shows that the UE fails to receive the RAR after sending the preamble for a
maximum of times.
The following figure shows the places where random access fails in the scenario of
100%Load_woICIC and 100%Load_ICIC. In all these places, the distance between the UE
and the target eNodeB is less than 1 km. In cluster 6, the cell coverage is small and the
Ncs_Index is 2, corresponding to a maximum access radius of 2.15 km. This value is
appropriate for the random access performance.
In summary, in loaded downlink scenario, failure to receive the handover completion message
is caused by random access failure. The downlink channel quality is poor, leading to failure of
the UE to demodulate the RAR. When the UE sends the preamble for a maximum of times,
the random access fails.
6.1.7 eNodeB Delivers an RRC Signaling Message, Waits for UE

Response, and Does Not Process a Handover Command.
The eNodeB delivers an RRC signaling message, such as the MIMO reconfiguration message.
Due to poor downlink channel quality, the UE fails to demodulate the signaling message.
When handover conditions are satisfied, the UE sends measurement reports, but the eNodeB
is waiting for the response to the last RRC signaling message. Therefore, the eNodeB does not
process the measurement reports. If the eNodeB fails to receive the UE response two seconds
after the eNodeB sends the RRC signaling message, the eNodeB releases the connection and
sends an RRC_CONN_REL message. Figure 1-9shows the trace from the eNodeB and Figure
1-10shows the trace from the UE.
Figure 1-9 Trace from the eNodeB
Figure 1-10 Trace from the UE
6.1.8 Incorrect X2 IPPATH Configuration Leads to Handover

Failure.
In a drive test, the message HANDOVER_PREPARATION_FAILURE is repeatedly
displayed for the handovers at site OSL355, as shown in the following figure.
The trace message indicates that the possible cause of the handover preparation failure is
insufficient transmission resource, no configuration of IPPATH, or incorrect configuration of
the IPPATH. There are not many users, the cause should be related to IPPATH configuration.
To confirm, perform the following operations:
12. From the eCGI, the eNodeB ID is 100123, which is OSL123. Check whether the cell of
PCI 4 belongs to OSL123. If yes, the site is OSL123; if not, check for the eNodeB that
the cell of PCI 4 belongs to.
13. Check whether the X2 IPPATH of OSL123 is configured. If yes, check whether the X2
interface ID is consistent with the ID configured in the X2 IPPATH.
 Run LST SCTPLNK to display the SCTP link ID of the target eNodeB.
 Using the SCTP link ID as a parameter, run LST X2INTERFACE to display the X2
interface ID.
 Using the X2 interface ID as a parameter, run LST IPPATH to check whether the
IPPATH configuration is correct.
The result shows that though an X2 interface to OSL355 is configured on OSL123, the
corresponding IPPATH is not configured. When OSL355 sends a handover request over the
X2 interface to OSL123, the OSL355 receives a handover preparation failure message. After
the X2 IPPATH is configured, the handover succeeds.
6.1.9 The Handover Place Is Distant From the Target Cell and Is
Out of the Maximum Theoretical Access Radius Specified By
Ncs_Index.
eRAN1.0 Ncs_Index is 2 by default, corresponding to a maximum theoretical access radius of
2.15 km. In the live network, there are various coverage sizes. Some cells have small
coverage, as in densely populated city areas where eNodeBs are densely deployed; some cells
have large coverage, as in suburb areas where eNodeBs are sparsely deployed. If one
Ncs_Index is used for the whole network, this Ncs_Index is not applicable to all eNodeBs. For
example, if Ncs_Index is 2, the access performance and handovers in downtown and city areas
are normal; accesses and handovers in suburb areas may fail when the handover place or
access place is distant from the eNodeB, out of the theoretical access radius. The following
figure shows an LTE commercial network in Norway. The Ncs_Index of this network is
uniformly 2. Handovers in suburb areas fail because of random access failure.
6.1.10 In an Inter-eNodeB X2-based handover, the Source Cell

Sends Handover Request But Fails to Receive Response.
In the following figure, the left part shows the messages transmitted to and from the source
eNodeB; the right part shows the messages transmitted to and from the target eNodeB.
Sometimes, the source eNodeB receives the HANDOVER_REQUEST_ACK late (near the
order of a second); the handover time is crossed, leading to handover failure.
6.1.11 In an Inter-eNodeB X2-based handover, the Target Cell

Sends S1AP_PATH_SWITCH_REQ and Fails to Receive a
Response.
The target cell sends S1AP_PATH_SWITCH_REQ and fails to receive response, leading to
handover failure. Meanwhile, the eNodeB does not process the succeeding handover
measurement reports, leading to failure of the newly triggered handovers.
6.1.12 Long Time in Inter-eNodeB X2-based handover Preparation

Crosses the Handover Time.
The Probe shows that the UE fails to receive the handover command after sending multiple
measurement reports. The whole-network trace information obtained from the eNodeB shows
that source eNodeB initiates a handover request over the X2 interface. It takes a long time for
the source eNodeB to receive the handover request ACK. During this period, the signal at the
target eNodeB fades quickly and the target eNodeB fails to receive the handover completion
message; the handover fails. After the UE reconnects to the network successfully, the eNodeB
sends a DRB reconfiguration message, which is not received by the UE. The RLC layer of the
eNodeB reaches the maximum retransmission times and directly releases the UE.
After the UE fails in handover, it fails to receive the DRB reconfiguration message after a
successful reestablishment. It initiates a reestablishment again. Because the RLC layer of the
eNodeB has released the user context after reaching the maximum number of retransmissions,
the second initiation of the UE is rejected, leading to abnormal release.
The RSRP signal of PCI 345 is good. During the inter-eNodeB X2-based handover
preparation period, the signal of the neighboring cell fades quickly and the UE fails in random
access. The target eNodeB fails to receive the handover completion message and the handover
fails. Long time in inter-eNodeB X2-based handover preparation results in a failure to find the
best handover time, leading to call drop during reestablishment.
[Solution]
The handover failure caused by S1 link intermittence or restricted transmission is probabilistic

and is hard to locate. This problem results in deteriorated handover performance during a
drive test.
The handover preparation takes a long time. The whole-network trace information obtained
from the eNodeB shows that it takes 3s in X2 signaling transmission. The one-key log of the
eNodeB has not recorded the X2 link fault. If the bottom-layer SCTP fails to receive the ACK
one second after it sends the message, it retransmits the message. If the retransmission fails
for 10 consecutive times, an SCTP link alarm is reported and the SCTP is disconnected. The
preliminary conclusion is that X2 signaling retransmission leads to large signaling
transmission delay. As confirmed by the customer, the transmission network has been
adjusted recently, deteriorating the transmission performance.
The lesson is that the engineers need to consult the customer about transmission problems
before seeking other possibilities.
6.1.13 When a UE Processes a System Message, It Does Not

Process a Handover Command.
UEs of eRAN1.0 SPC360 and earlier versions do not process a handover command when
receiving a system message, leading to handover failure. The following figure shows the
message trace.
6.1.14 For Intra-eNodeB Handovers Where S_RSRP and N_RSRP

Are High, a Small HO_TTT (64 Ms) Can Trigger Handover
Timely Before Signal Deterioration.
Test 1: 20100504 22:55:40.218 PCI48->PCI50, UE fails to receive handover commands.
This problem is analyzed as follows:
14. This handover is an intra-eNodeB handover. The S_RSRP and N_RSRP at the handover
area are high. In loaded downlink scenario, the target cell has strong interference on the
source cell. The pilot SINR is less than 0 dB and the downlink IBLER is more than 20%,
indicating that the downlink channel quality at the handover area is poor, leading to loss
of the handover command.
15. The handover threshold is 2 dB. In the measurement report sent by the UE, N_RSRP –
S_RSRP = 3 dB. In this scenario where the S_RSRP and N_RSRP are high, the
downlink is loaded, and the downlink channel quality at the handover area is poor, the
intra-eNodeB handover needs to be triggered timely and finished before the channel
quality deteriorates quickly.
16. To increase the handover timeliness, the HO_TTT is shortened from 128 ms to 64 ms.
After the HO_TTT is changed to 64 ms, the test result shows that the handover at that
place succeeds.
After the handover timeliness is increased, the channel quality of the place where the
measurement report is sent is improved; the SINR is significantly decreased to about 2 to 3
dB and is greater than the demodulation threshold; the downlink IBLER is 15%, near the
normal value 10%. The downlink channel quality is satisfactory and can ensure the correct
demodulation of the handover command. The following figures show the result of test 2 and
test 3, which are successful handovers.
Test 2: 20100505 23:52:33.140 PCI48->PCI50, handover succeeds (HO_TTT 64 ms)

Test 3: 20100505 01:06:09.937 PCI48->PCI50, handover succeeds (HO_TTT 64 ms)

Conclusion:
For intra-eNodeB handovers where the S_RSRP and N_RSRP are high and the channel
quality at the handover place deteriorates quickly, it is desirable to increase the handover
timeliness. You are advised to decrease the handover threshold from 3 dB to 2 dB and shorten
the Time-To-Trigger from 128 ms to 64 ms.
6.1.15 In Signal Overlapping Areas Where a Handover Can Be

Easily Triggered, Frequent Incoming and Outgoing Handovers
Result in Sharply-Deteriorated Signals and Handover Failures.
Analysis in section 6.1.14 shows that for intra-eNodeB handovers where the S_RSRP and
N_RSRP are high, the HO_TTT64ms can increase the handover success rate. HO_TTT64ms
is not universally applicable. In the following test 2, the HO_TTT of the whole network is
changed to 64 ms, leading to new handover failure. When the HO_TTT is restored to 128 ms,
handovers succeed.
[Case 1]
Test 2 20100504 23:47:14.812 PCI9->PCI56, target cell fails to receive the handover
completion message (random access failure)
17. When the value of HO_TTT is 64 ms, handovers are quickly triggered. Whenever the
signal of PCI 56 is high enough, a handover is triggered. This signal fades quickly
because the target RSRP is lower than the source RSRP, leading to random access failure
(failure to receive the RAR).
18. In test 1 and test 3, where the value of HO_TTT is 128 ms, the handovers at the same
place succeed and there is no situation that the target RSRP is suddenly lower than the
source RSRP.
[Case 2]
Test 2: 20100505 00:02:17.328 PCI50->PCI266, UE fails to receive the handover command.
1. Handovers are more easily triggered when HO_TTT is 64 ms than 128 ms. Handovers
frequently take place in signal overlapping area. Near the handover place, the signal of
PCI 50 rises sharply, hence the successful PCI 266->PCI 50 handover; this signal falls
sharply, triggering PCI 50->PCI 266 handover. Due to the poor downlink channel
quality, the handover command is lost. If there is no PCI 266->PCI 50 handover when
the signal of PCI 50 rises sharply, there is no PCI 50->PCI 266 handover that fails.
2. When the HO_TTT is 128 ms, the handover sequence at that area is PCI 264->PCI 266-
>PCI 50, avoiding frequent outgoing and incoming handovers at PCI 50.
6.1.16 After the Handover Threshold Is Decreased, the Number of

Ping-Pong Handovers Is Increased. Due to Handover Timeliness,
the Number of Handover Failures Is Decreased.
Comparative tests in the same road with different handover thresholds (2 dB versus 3 dB) are
described as follows:
3. When the handover threshold is 3 dB, the drive test data shows that the number of
handovers is 103; this figure is 130 for a handover threshold of 2 dB.
4. When the handover threshold is 2 dB, ping-pong handovers more easily take place,
resulting in increased number of handovers. Also, the decreased handover threshold
improves the handover timeliness, so that the UE triggers handover before the downlink
channel quality obviously deteriorates, increasing the handover success rate.
6.2 Large User Plane Handover Delay
6.2.1 Incorrect X2 IPPATH Configuration Leads to Long Handover

Delay.
During a cluster acceptance test in Norway, the RLC layer delay of inter-eNodeB handovers
between OSL071 and OSL186 is generally more than 60 ms, or sometimes even 1s.
To find out the cause of this problem, a new UE version is used. The following symptom is
found: Transmission of data packets by the target cell is delayed; the first data packet is
transmitted more than 100 ms after the random access. This can be caused by one of the
following two situations: 1. It takes a long time for the data to be forwarded from the source
cell to the target cell; 2. The source cell has forwarded the data to the target cell, but the target
cell does not timely transmit the data.
Huawei laboratory test shows that the eNodeB has received the packets forwarded over the
X2 interface 20 ms before the eNodeB receives the handover completion message from the
UE. The onsite trace file shows no data forwarded over the X2 interface. In a comparative test
over two eNodeBs where the handover delay is normal, there are data packets forwarded over
the X2 interface. Now the focus is on the X2 interface between OSL071 and OSL186.
The engineers check the X2_IPPATH between OSL071 and OSL186 and compare the
configured IP address with that in the engineering parameter table. They find that X2_IPPATH
is configured as the OM IP address. They modify the IP address and perform inter-eNodeB
X2-based handover. The handover delay becomes normal (about 30 ms).
[Solution]
If there is long handover delay near the order of a second, check whether the transmission is
correct and whether the X2 configuration (interface number, local IP address, and peer IP
address) is correct.
6.2.2 Retransmission of a Handover Command Leads to Long

Handover Delay.
During a drive test in Norway, there is a long handover delay of 70 ms. The time stamps from
the UE show that the interval between the last data packet of the source cell and the handover
command is large, indicating that the handover command is received late. The handover
command may be ARQ retransmitted.
When the channel quality at the handover area worsens, the PDCCH or PDSCH
corresponding to the handover command is restricted, leading to HARQ or ARQ
retransmission of the handover command.
The Probe shows that the interval between the MacRxLastSrb and MacRxLastDrb is large.
This can be caused by one of the following two problems: 1. The source cell receives the data
packets (handover command) of the last signaling radio bearer (SRB) late; 2. The data packets
over the data radio bearer (DRB) are retransmitted.
[Solution]
eRAN 1.0 B060SPC350 provides the following functions to improve the reliability of the
handover signaling transmission by the eNodeB and to ensure correct delivery of the
handover command.
 The PDCCH power corresponding to the handover command is increased for

transmission of the handover command. The CCE aggregation is fixed to eight.
 The PDSCH power corresponding to the handover command is increased, and MCS 1 is
used to transmit the handover command.
 HARQ and ARQ retransmissions are enabled on the eNodeB. These functions are
disabled by default due to the commercial terminal capability.
6.2.3 Consecutive CRC Errors of the Data Packets at the Source

Cell Lead to Long Handover Delay.
When the signals in the handover area fluctuate and the CQI adjustment algorithm is not
prompt, consecutive CRC errors may be generated in the source cell before the handover,
resulting in a large delay. The Probe shows that the source cell receives the packets of the last
DRB late.
[Solution]
eRAN1.0 B060SPC350 provides the following functions to ensure that the source cell
transmits data reliably:
 Upon reception of a measurement report, the source L3 instructs L2 to use low-order

MCS on succeeding data. The MCS order is configurable.
 The control channel element (CCE) aggregation is fixed to eight.
6.2.4 Consecutive CRC Errors of the Data Packets at the Target

Cell Lead to Long Handover Delay.
When a UE hands over to the target cell, high interference from the neighboring cell leads to
consecutive CRC errors.
After the UE hands over to the target cell, there is no CQI report for some time; the eNodeB
uses MCS 5 for scheduling. High interference from the neighboring cell leads to consecutive
CRC errors.
The Probe shows that at the handover point, the RSRP, SINR, and PDCCH DL grant count are
low; the IBLER is high; and the interval between the handover completion message and the
first data packet received is large (122.455 ms).
[Solution]
eRAN1.0 B060SPC350 provides the following functions to ensure that the target cell
transmits data reliably:
 After a handover is complete at the target cell, a timer is started. Before the timer
expires, the data is transmitted at low-order MCS.
 MCS order is configurable by MML commands.
 The CCE aggregation is fixed to eight.
Run the following command on the LMT to set the post-handover timer to 60 ms and fix the
MCS order to 0.
SET HOMCSPARAM: MCSHOSTATIC=0, HOCQIRPTTIMER=60ms;
6.2.5 Retransmission of Preamble During Random access Leads to

Long Handover Delay.
During a random access, retransmissions of preamble lead to long handover delay.
The preamble retransmission period is 20 ms and the maximum number of retransmissions is

5 (including initial transmission). The number of preamble retransmissions has a positive
correlation with the handover delay. A retransmission can increase the delay by 20 ms.
Case 1: In this handover, the preamble is retransmitted for four times during the random
access. Due to the retransmissions, the interval between MacRxLastSrbTime (handover
command) and MacSendMsg3Time (handover completion message) is large. Also in this
handover, the interval between the last data packet and the handover command is large
(15.786 ms) and the interval between the handover completion message and the first data
packet is large (28.482 ms). The total handover delay is more than 100 ms.
Case 2: The preamble is retransmitted for two times and the handover delay is 51.739 ms.
[Solution]
There are two reasons for preamble retransmission: 1. poor uplink channel quality. 2. poor
downlink channel quality, leading to failure in receiving the RAR and preamble
retransmission. The coverage and handover parameters are adjusted so that the UE has good
channel quality at the moment it hands over to the target cell, reducing the number of
retransmissions.
6.2.6 UE Fails to Send or Is Late in Sending PDCP Status Report.

A UE fails to send or is late in sending PDCP status report, leading to retransmission when the
timer of the target eNodeB expires, prolonging the handover delay.
Run LST TYPDRBRLCPDCP to check whether the value of

PDCPSTATUSREPORTREQUIRE is FALSE.
If yes, the UE does not send status report after the handover is complete; upon reception of
the handover completion message, the target eNodeB immediately forwards the data from the
source eNodeB to the UE. These data contain the data packets that the UE has received. In
this sense, the eNodeB sends duplicate packets, leading to prolonged PDCP layer delay.
Because the eNodeB immediately forwards the data packets, the RLC layer delay is normal.
You are advised to set PDCPSTATUSREPORTREQUIRE to TRUE to reduce the PDCP

layer delay.
When PDCPSTATUSREPORTREQUIRE is TRUE, the UE sends the handover completion

message that contains the status report to the target eNodeB. Upon reception of the end
marker of the data packets from the source eNodeB, the target eNodeB starts a timer and
waits for the status report from the UE. If due to poor channel quality, the handover
completion message is retransmitted, the target eNodeB is late in receiving the status report
and in sending data to the UE, increasing the RLC layer and PDCP layer delays.
[Solution]
 Set PDCPSTATUSREPORTREQUIRE to TRUE.

 Reduce the retransmission of random access signaling and handover completion message
to reduce the RLC layer and PDCP layer delays.
6.3 Handover Failure Analysis Based on CHRs

CHR-based handover measurement is used in eRAN2.1SPC400B050 and later versions and
handover problems can be analyzed by using CHRs. This section describes how to analyze
handover problems by using CHRs.
6.3.1 Intra-eNodeB Handover Failure Caused by a Random Access

Failure
The release cause value contained in the CHR is as follows:
usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT
To check the reason of an intra-eNodeB handover failure based on the CHR, perform the
following operations:
Step 2 Analyze the last ten messages before the service drop.
Note that the Insightsharp does not support parsing of the last ten messages before the service
drop but the UMAT supports.
View the CallID of the service drop in the CHR and obtain records related to the CallID by
using the UMAT. The last ten messages before the service drop in the CHR show that the
eNodeB sends a release request to the EPC after the 5s timer governing the period in which
the eNodeB waits for a handover completion message expires.
Step 3 Analyze the L2_SRB_LOG to check whether the UE receives the handover command.
The HARQ state is 1, indicating ACK, that is, the UE receives the handover command, as
shown in the following figure.
Step 4 View the L2_L1_DEDI_PREAMBLE to analyze whether the random access is successfully
completed.
The number of received dedicated preambles (ucRcvNum) is 10 (the maximum number of

preamble retransmissions is configured as 10). It indicates that the UE does not receive the
RAR and retransmits the preamble for 10 times.
The preceding analysis result shows that the intra-eNodeB handover failure is caused by a
random access failure.
6.3.2 Intra-eNodeB Handover Failure Caused by the Lost Handover

Complete Message
usRelCause: UEM_UECNT_REL_HO_WAIT_RECFG_RSP_TIMEOUT
Step 5 Analyze the last ten signaling messages before the service drop.
The eNodeB does not receive a handover completion message after sending a handover
command to the UE. (Obtain the CallID from the CHR and then obtain the data related to
CallID by using the UMAT.
Step 6 Analyze the L2_SRB_LOG to check whether the UE receives the handover command.
The HARQ state is 1, indicating ACK, that is, the UE receives the handover command, as
shown in the following figure.
Step 7 View the L2_L1_DEDI_PREAMBLE to analyze whether the random access is successfully
completed.
One dedicated preamble is received, indicating that the UE received the RAR after sending
one preamble.
The preceding analysis result shows that the handover failure is caused by the lost handover
completion message. In this case, the handover failure may also be caused by a random access
failure if the UE does not receive the RAR and the eNodeB does not receive preambles
retransmitted by the UE.
6.3.3 X2-based Handover Failure Caused by the Reason that the

Source eNodeB Fails to Receive a Context Release Command
Before the Timer Expires
usRelCause: UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL
To check the reason of an X2-based handover failure based on the CHR, perform the
The last ten messages show that the source eNodeB does not receive the context release
command over the X2 interface from the target eNodeB and the UE is released after the 15s
timer expires.
Step 9 Analyze the handover procedure.
1. The L2_SRB_LOG field in the CHR of the source eNodeB shows that the HARQ status
for the handover command is 1, indicating ACK, that is, the UE received the handover
command.
2. View the cell_RR_RSP field in the CHR of the source eNodeB to find the CRNTI being
630.
3. View the Ho In info field in the CHR of the target eNodeB to find the SRS CRNTI being
630. This problem cannot be further analyzed because the information of this period in
the CHR of the target eNodeB has been overwritten. If information of the target eNodeB
is available, analyze whether the random access is successful and whether the handover
is completed.
6.3.4 X2-based Handover Failure Caused by an S1 Path Switch

Failure
Step 10 Analyze the CHR of the source eNodeB.
1. The HARQ state is 1, indicating ACK, that is, the UE received the handover command.
2. The CRNTI in the CHR of the source eNodeB is 1457.
The handover measurement report shows "S_RSRP = –112 dBm" and "N_RSRP = –108
dBm."
The last ten messages before the service drop show that the handover fails because the
UE is released after the timer waiting for the X2_Context_Rel_CMD message expires.
Further analyze the reason of the handover failure by using the CHR of the target eNodeB.
Step 11 Analyze the CHR of the target eNodeB.
1. View the usSrsCrnti field whose value is 1457 from the HoInInfo, that is, information
about this handover on the target eNodeB.
2. The last ten messages before the service drop show that the target eNodeB receives the
handover completion message and the handover fails because the EPC sends an
S1_PATH_SWITCH_REQ_FAIL message.
The preceding analysis result shows that this handover failure is caused by an S1 path switch
failure, but not a fault on the radio network side.
6.3.5 Service Drop Caused by a Connection Reestablishment Failure

During the Connection Reestablishment Process Triggered by a
Random Access Failure in a Handover
To check the reason of a service drop following a connection reestablishment failure based on
the CHR, perform the following operations:
Step 12 The last ten messages before the service drop show that the UE initiates a connection
reestablishment procedure on the source eNodeB after the handover fails, and the eNodeB
releases the UE because of the failure to receive a reestablishment completion message before
the 5s timer expires.
Step 13 Analyze the reestablishment to find that the connection reestablishment is caused by a random
access failure.
6.3.6 Service Drop Caused by Deteriorating Channel Quality due to

the eNodeB Failing to Respond to the Handover Measurement
Report from the UE
To check the reason of a service drop caused by deteriorating channel quality based on the
CHR, perform the following operations:
The UE keeps reporting the handover measurement report (the PCI of the target cell is 320)
and the eNodeB does not send a handover command (neighboring relationships may not be
configured). The measurement report shows that the downlink signal quality of the serving
cell is poor as the RSRP approximates to –122 dBm.
Step 15 Analyze causes of the service drop.
UEM_UECNT_REL_UE_RLC_UNRESTORE_IND /* indicates unrestoring when L2

reports maximum RLC retransmissions
This release cause occurs in the following two scenarios:
1. SRB retransmissions reaches the maximum number.

2. DRB retransmissions reaches the maximum number.
The L2_SRB_LOG field records the scheduling status of the last eight downlink SRBs before
L2 detects the fault (for example, RLC retransmissions reaches the maximum number).
The DRB_64MS (size=16) field records the scheduling status of downlink DRBs during the
16 x 64 ms duration before L2 detects the fault (for example, RLC retransmissions reaches the
maximum number).
The following figure shows that, SRBs are normal before the service drop and then DRBs
encounters a great number of NACK/DTXs (DRB_64MS (4 to 16) indicates NACK/DTX).
The preceding analysis result shows that the eNodeB does not respond to the measurement
report from the UE, causing deterioration of the channel quality. The service drop occurs after
DRB retransmissions reaches the maximum, that is, the eNodeB releases the UE in about 30s
after detecting that RLC retransmissions reaches the maximum number.
6.3.7 Handover Failure Caused by a Lost Handover Command
The release cause value contained in the CHR is

UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL.
To check the reason of a handover failure based on the CHR, perform the following
operations:
Step 16 Analyze the last 10 messages before the service drop.
command over the X2 interface from the target eNodeB and the UE is released after the timer
expires.
The maximum number of HARQ retransmissions reaches, that is, ucHarqReTransTimes = 4,

and the HARQ state is 2, indicating DTX, that is, the UE does not receive a handover
command.
The preceding analysis result shows that the handover failure is caused by the lost handover
command message.
6.3.8 X2-based Handover Failure Caused by a Lost Preamble
The release cause value contained in the CHR is

UEM_UECNT_REL_HO_OUT_X2_REL_BACK_FAIL.
timer expires.
1. The HARQ state is 1, indicating ACK, that is, the UE receives the handover command.
2. The CRNTI (usCrnti) in the RbCellRrRsp field is 524.
1. The usSRSCRnti in the HoInInfo field is 524.

2. There is no preamble reported by L1. L2 and L3 preambles are released at an interval of
2s from the preamble assigned, indicating that the preamble is lost.
The preceding analysis result shows that the handover failure is caused by the lost preamble.
6.3.9 X2-based Handover Failure Caused by the Reason that the

Target eNodeB Does Not Receive the S1PathSwitchAck
Message Before the Timer Expires
timer expires.
1. The HARQ state is 1, indicating ACK, that is, the UE receives the handover command.
2. The CRNTI in the RbCellRrRsp field is 1006.
1. The usSRSCRNTI in the HoInInfo field included in the CHR of the target eNodeB is
1006.
2. The last ten messages on the target eNodeB show that, the target eNodeB receives the
handover completion message but releases the UE due to failing to receive the
S1PathSwitchAck message after the 15s timer expires.
The preceding analysis result shows that the EPC does not send an S1PathSwitchReq message
to the target eNodeB during the X2-based handover process, resulting in a handover failure.
6.3.10 Service Drop Caused by a Lost Connection Reestablishment

Completion Message During the Connection Reestablishment
Triggered by a Random Access Failure in a Handover
The release cause value contained in the CHR is:
ucRestCause: 1
Indicating a handover failure. That is to say that the connection reestablishment is

triggered by a handover failure.
To check the reason of a service drop based on the CHR, perform the following operations:
Step 24 Analyze the last ten messages before the service drop. The ten messages show that the UE
initiates a connection reestablishment procedure on the source eNodeB after the handover
fails, and the eNodeB releases the UE because failing to receive a reestablishment completion
message before the 5s timer expires.
Step 25 Analyze the reestablishment to find that the connection reestablishment is caused by a random
access failure.
6.3.11 Intra-eNodeB Handover Failure Caused by a Connection

Reestablishment Failure During the Connection Reestablishment
Triggered by a Random Access Failure
1. The measurement report shows "S_RSRP = –112 dBm" and "N_RSRP = –110 dBm"
2. Engineering parameters show that the serving cell with the PCI being 198 and the target
cell with the PCI being 200 are under the same eNodeB and that is an intra-eNodeB
handover.
3. The connection reestablishment is triggered by a handover failure but fails. The UE may
access another cell, resulting in a UE release initiated by the MME.
Step 27 Analyze the reestablishment to find that the connection reestablishment to the target cell is
caused by a random access failure.
Step 28 Analyze the CHR of the source eNodeB and find that the HARQ state is 1, indicating ACK,
that is, the UE receives the handover command.
Step 29 Analyze the CHR of the target eNodeB and find that L1 reports the preamble for 24 times,
indicating that the UE does not receive the RAR.
The preceding analysis result shows that the handover failure is caused by the lost RAR and
triggers connection reestablishment. Then, the failure in connection reestablishment leads to a
service drop.
6.3.12 Service Drop Caused by a Connection Reestablishment Failure

During the Connection Reestablishment Triggered by a Lost
Handover Completion Message in an Intra-eNodeB Handover
To check the reason of a service drop based on the CHR, perform the following operations:
1. The measurement report shows "S_RSRP = –103 dBm" and "N_RSRP = –101 dBm"
2. Engineering parameters show that the serving cell with the PCI being 314 and the target
cell with the PCI being 313 are under the same eNodeB and that is an intra-eNodeB
handover.
3. The connection reestablishment is triggered by a handover failure but fails. The UE may
access another cell, resulting in UE release initiated by the MME.
Step 31 Analyze the cause value of the connection reestablishment and find "ulCellId=1 (PCI=313)"
in the reestablishment request, indicating that the connection is reestablished to the target cell.
The cause value of ucReestablishmentCause=2 in the reestablishment request indicates other
failures. That is to say, the connection reestablishment is not triggered by a random access
failure.
Step 32 Analyze the CHR of the source eNodeB and find that the HARQ state is 1, indicating ACK,
that is, the UE receives the handover command.
L1 reports one received preamble and the UE receives the RAR after sending a dedicated
preamble. The random access is successfully completed.
The preceding analysis result shows that the handover failure is caused by a lost handover
completion message and triggers connection reestablishment. Then, the failure in connection
reestablishment to the target cell leads to a service drop.
LTE Handover Troubleshooting and Optimization Guide 7 Reference
7 Reference
LTE eRAN1.1 Handover Troubleshooting and Optimization Guide V1.1.doc

LTE Handover Troubleshooting and Optimization Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE Handover Troubleshooting and Optimization Guide

Uploaded by

Copyright:

Available Formats

Doc.

LTE Handover Troubleshooting

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2012. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

People's Republic of China

2.1.2 Signaling Interaction for Intra-eNodeB Handover...................................................................................4

2.1.3 Signaling Interaction for Inter-eNodeB X2-based handover....................................................................5

2.1.4 Signaling Interaction for Inter-eNodeB S1-based handover....................................................................6

2.2 Handover-Related Parameters...........................................................................................................................7

2.2.1 Handover Threshold.................................................................................................................................7

2.3 Handover Interaction on the User Plane..........................................................................................................10

3.2 Control Plane Handover Delay........................................................................................................................12

3.3 User Plane Handover Delay.............................................................................................................................13

3.3.2 Uplink Application Layer Delay.............................................................................................................14

3.3.3 Downlink Application Layer Delay........................................................................................................14

3.3.4 Delay at the Uplink RLC Layer of the Network....................................................................................14

3.3.5 Delay at the Downlink RLC Layer of the Network................................................................................15

3.3.6 Delay at the Uplink RLC Layer of the Terminal....................................................................................15

3.3.7 Delay at the Downlink RLC Layer of the Terminal...............................................................................15

4 Handover Fault Identification Methods.................................................................................16

4.1.1 Abnormal Signaling over the Uu Interface.............................................................................................16

4.1.2 Abnormal Signaling over the X2 Interface.............................................................................................19

4.1.3 Abnormal Signaling over the S1 Interface.............................................................................................20

4.2 Identifying the Causes of Handover Delays....................................................................................................24

4.2.1 Identifying the Causes of Control Plane Handover Delays....................................................................24

4.2.2 Identifying the Causes of User Plane Handover Delays.........................................................................24

5 Operations for Handover Fault Identification.......................................................................26

5.1.1 Observing the Signaling from the Network............................................................................................26

5.1.2 Observing the Signaling from the UE....................................................................................................27

5.2 Observing the User Plane Handover Delay.....................................................................................................27

5.2.1 Observing the Application Layer Delay.................................................................................................28

5.2.2 Observing the RLC Layer Delay............................................................................................................29

6.2.2 Random Access Fails During a Handover..............................................................................................35

6.2.4 Measurement Reports Are Lost..............................................................................................................38

6.2.5 Handover Commands Are Lost..............................................................................................................41

6.2.8 Incorrect X2 IPPATH Configuration Leads to Handover Failure..........................................................44

6.3 Large User Plane Handover Delay..................................................................................................................59

6.3.1 Incorrect X2 IPPATH Configuration Leads to Long Handover Delay...................................................59

6.3.2 Retransmission of a Handover Command Leads to Long Handover Delay...........................................60

6.3.6 UE Fails to Send or Is Late in Sending PDCP Status Report.................................................................65

6.4 Handover Failure Analysis Based on CHRs....................................................................................................65

6.4.1 Intra-eNodeB Handover Failure Caused by a Random Access Failure..................................................65

6.4.4 X2-based Handover Failure Caused by an S1 Path Switch Failure.......................................................73

6.4.7 Handover Failure Caused by a Lost Handover Command.....................................................................80

6.4.8 X2-based Handover Failure Caused by a Lost Preamble.......................................................................82

Acronyms and Abbreviations

Abbreviation Full Spelling

A characteristic of wireless communications is mobility control. When a UE moves across

2.1 Handover Signaling Interaction

 The source eNodeB controls the UE measurement by sending an RRC CONNECT

Figure 1-1 A reconfiguration command for handover

Figure 1-2 A reconfiguration command for measurement control

After a UE accesses a cell, the measurement control information is delivered to the UE

2.1.1 Signaling Interaction for Intra-eNodeB Handover

Figure 1-3 Signaling interaction for intra-eNodeB handover

2.1.2 Signaling Interaction for Inter-eNodeB X2-based handover

Figure 1-4 Signaling interaction for inter-eNodeB X2-based handover

2.1.3 Signaling Interaction for Inter-eNodeB S1-based handover

Figure 1-5 Signaling interaction for inter-eNodeB S1-based handover

2.2 Handover-Related Parameters

2.2.1 Handover Threshold

Entering condition: Mn + Ofn + Ocn – Hys > Ms + Ofs + Ocs + Off