LTE Handover Optimization

LTE Handover Optimization
All rights reserved. No distribution without prior permission of ZTE. © 2018 ZTE CORPORATION. I
Contents
1 HANDOVER OVERVIEW .................................................................................................. 1
1.1 NECESSITY FOR HANDOVER............................................................................... 1
1.2 HANDOVER PROCEDURE..................................................................................... 1
1.3 INTRA-LTE HANDOVER MEASUREMENT EVENTS ............................................ 1
1.4 HANDOVER CLASSIFICATION .............................................................................. 4
1.4.1 INTRA-SITE HANDOVER .............................................................................. 5
1.4.2 S1-BASED INTER-SITE HANDOVER ........................................................... 6
1.4.3 X2-BASED INTER-SITE HANDOVER ......................................................... 11
1.4.4 INTER-FREQUENCY HANDOVER ............................................................. 16
2 INTRA-LTE HANDOVER PROCEDURES AND ANALYSIS ......................................... 19

2.1 PROTOCOL-DEFINED HANDOVER PROCEDURE ............................................ 19
2.1.1 HANDOVER SIGNALING OBSERVED ON THE UE SIDE......................... 21
2.1.2 HANDOVER SIGNALING OBSERVED ON THE ENODEB SIDE .............. 21
2.2 MEASUREMENT CONTROL ................................................................................ 24
2.3 MEASUREMENT REPORTING............................................................................. 27
2.4 HANDOVER DECISION ........................................................................................ 29
2.5 HANDOVER PREPARATION ................................................................................ 29
2.6 HANDOVER EXECUTION..................................................................................... 29
2.7 HANDOVER COMPLETION .................................................................................. 31
3 HANDOVER PARAMETER SETTING INSTRUCTIONS ............................................... 32

3.1 NEIGHBOR CELL CONFIGURATION OVERVIEW .............................................. 32
3.1.1 NEIGHBOR CELL ........................................................................................ 32
3.1.2 NEIGHBOR RELATIONSHIP ...................................................................... 34
3.2 HANDOVER PARAMETER SETTINGS ................................................................ 36
3.2.1 EVENT A3–RELATED PARAMETERS IN MEASUREMENT CONFIGURATION
36
3.2.2 SERVING CELL INDIVIDUAL OFFSET ...................................................... 42
3.2.3 NEIGHBOR CELL INDIVIDUAL OFFSET ................................................... 43
3.2.4 HANDOVER TIMERS .................................................................................. 45
4 HANDOVER PROBLEM ANALYSIS .............................................................................. 49

4.1.1 SIGNALING ANALYSIS ON THE RADIO AIR INTERFACE SIDE ............. 49
4.1.2 HANDOVER FAILURE SYMPTOMS ........................................................... 54
All rights reserved. No distribution without prior permission of ZTE. © 2018 ZTE CORPORATION. II
4.1.3 X2 INTERFACE SIGNALING ANALYSIS .................................................... 56
4.1.4 S1 INTERFACE SIGNALING ANALYSIS .................................................... 58
5 HANDOVER PROBLEM POSITIONING ........................................................................ 60

5.1 PERFORMANCE STATISTICS ANALYSIS .......................................................... 60
5.2 HANDOVER KPI OPTIMIZATION ......................................................................... 61
5.3 HANDOVER PROBLEM RESOLVING PROCEDURE ......................................... 62
5.4 HANDOVER PROBLEM CHECKLIST................................................................... 63
All rights reserved. No distribution without prior permission of ZTE. © 2018 ZTE CORPORATION. III
1 Handover Overview
1.1 Necessity for Handover
Wireless communication has an important feature: mobility control. When a UE

moves to the edge of a cell, the system needs to hand over the UE to another cell
with better signal strength to ensure service continuity. During a handover, the UE
and network operate together to complete signaling interaction. Handovers in LTE
are hard handovers, meaning that there is a short service interruption when the
handover is performed. To ensure that services are not affected, the handover
success rate and handover throughput must be guaranteed. If a handover fails, user
experience is severely degraded.
1.2 Handover Procedure
Handover instructions are sent from the eNodeB side. UEs actively report their radio
conditions to the eNodeB, so that the eNodeB can determine that the UEs are
located on the cell edge. There are two types of reporting, event-triggered reporting
and periodic reporting. In most cases, event-triggered reporting is used, meaning that
the eNodeB sends predefined measurement control rules to UEs. If the
measurement result of a UE meets the threshold requirement in the rules, a
Measurement Report (MR) is triggered.
1.3 Intra-LTE Handover Measurement Events
The LTE system sends measurement control rules to UEs. For the details of the
measurement control rules, refer to 2.2 Measurement Control. Measurement event
types are specified by these rules.
Mobility measurement events in the E-UTRAN system include the following:
All rights reserved. No distribution without prior permission of ZTE. © 2018 ZTE CORPORATION. 1
1. Event A1: The serving cell quality is higher than an absolute threshold (serving >
threshold). It can be used for stopping an ongoing inter-frequency or inter-RAT
measurement and deactivating a gap.
2. Event A2: The serving cell quality is lower than an absolute threshold (serving <
threshold). It can be used for starting an inter-frequency or inter-RAT
measurement and activating a gap.
3. Event A3: The quality of a neighbor cell is higher than the serving cell (neighbor >
serving + offset). It can be used for coverage-based inter-frequency or
intra-frequency handover.
4. Event A4: The neighbor cell quality is higher than an absolute threshold. It can
be used for inter-frequency handover and load-based handover.
5. Event A5: The serving cell quality is lower than threshold 1 (serving <
threshold1), and the neighbor cell quality is higher than threshold2 (neighbor >
threshold2). It can be used for coverage-based inter-frequency or
intra-frequency handover.
The events are described as follows:
1. Event A1/A2 is often used for starting and stopping inter-frequency or inter-RAT
measurement. Inter-frequency and inter-RAT measurements have a large effect
on the current service rate, so the measurements should be started only when
necessary. Therefore, event A2 is defined. When a UE determines that the
serving cell quality is lower than a threshold, it reports an MR. When
inter-frequency or inter-RAT measurement is implemented for a UE, and the
signal quality of the UE is enhanced, no measurement is required. In this case,
the UE needs to notify the eNodeB of the signal quality, so event A1 is defined.
When the eNodeB receives the event A1 MR, it determines that the signal
quality is good, and inter-frequency or inter-RAT measurement can be stopped.
2. Event A3 is most commonly used, and is often used in intra/inter-frequency

measurement.
Entering condition for event A3: Mn  Ofn  Ocn  Hys  Ms  Ofs  Ocs  Off
Leaving condition for event A3: Mn  Ofn  Ocn  Hys  Ms  Ofs  Ocs  Off
Where
Mn: neighbor cell measurement result, not including any offset
Ofn: frequency-specific offset of the neighbor cell
Ocn: cell-specific offset of the neighbor cell
Hys: lag between entering and leaving of the event
Ms: local cell measurement result, not including any offset
Ofs: frequency-specific offset of the serving frequency point (frequency point of

the local cell)
Ocs: cell-specific offset of the local cell
Off: event A3 offset, which needs to be configured on a higher layer
Figure 1-1 Event A3 Measurement Conditions
As shown in the above figure, Mn strength is raising, and Ms strength is

declining. Under this obvious trend, Ofn, Ocn, and Hys are considered for
neighbor cell signal strength, and Ofs, Ocs, and Off are considered for serving
cell signal strength.
6. Event A4 means that the neighbor cell quality is higher than an absolute
threshold. Event A5 means that the serving cell quality is lower than threshold1
(serving < threshold1) and the neighbor cell quality is higher than threshold2.
Entering condition for event A4: Mn+Ofn+Ocn-Hys>Thresh
Leaving condition for event A4: Mn+Ofn+Ocn+Hys<Thresh
Entering condition for event A5: Ms  Hys  Thresh1 and

Mn  Ofn  Ocn  Hys  Thresh 2
Leaving condition for event A5: Ms  Hys  Thresh1 and

Mn  Ofn  Ocn  Hys  Thresh 2
1.4 Handover Classification
 Tips: Handover in LTE
Handovers in LTE are hard handovers.
Intra-LTE handovers refer to handovers within the LTE system, including LTE FDD
(or TDD) intra-frequency and inter-frequency handovers, and handovers between
LTE FDD and LTE TDD.
Inter-LTE handovers refer to handovers between LTE and other radio system modes
(such as UMTS, GSM, and CDMA2000).
Intra-LTE handovers can be classified from various aspects.
Depending on whether the system is changed, intra-LTE handovers can be classified

into intra-TD-LTE handovers, intra-FDD-LTE handovers, and handovers between
TD-LTE and FDD-LTE.
Depending on whether the eNodeB is changed, intra-LTE handovers can be

classified into intra-site handovers and inter-site handovers. Intra-site handovers can
be classified into S1 handovers and X2 handovers. For intra-EUTRAN handovers,
the system determines whether to use the X2 interface or S1 interface. If X2
interfaces exist between two eNodeBs, the system preferably chooses the X2
interfaces for handover.
Depending on whether the frequency is changed, intra-LTE handovers can be

classified into intra-frequency handovers and inter-frequency handovers. Different
from 2/3G networks, the inter-frequency handover procedure is implemented
between two cells with the same central frequency point but different bandwidth.
Depending on whether the UE is within the same MME, intra-LTE handovers can be
classified into intra-MME handovers and inter-MME handovers. In many cities, an
MME pool is used to establish the network, meaning that each eNodeB is connected
to multiple MMEs, so true inter-MME handovers rarely occur, and are not described
in this document.
Figure 1-2 LTE Handover Classification
Intra-FDD
handover
Per mode
FDD-LTE<-
>TD-LTE
intra site
handover
Per
Handover in LTE Enodeb inter site
handover
intra frequency
Per handover
frequency
inter frequency
handover
Hand over
CDMA<->LTE
Inter-RAT
UMTS<->LTE
handover
GSM<->LTE
1.4.1 Intra-Site Handover

Intra-site handovers refer to UE handovers between different cells within the same
eNodeB. The intra-site handover procedure is slightly different from the inter-site
handover procedure. Intra-site handover preparation messages are transmitted
between boards of the eNodeB instead of through the S1 or X2 interface.
The following figure shows the procedure.
Figure 1-3 Intra-eNodeB Handover Procedure
eNodeB
Source Target S1 S11 S5
UE MME S-GW PDN-GW
CELL CELL
Handover
decision
Preparation Phase
Handover Request
Radio Resource
allocation
Handover Request ACK
RRC Reconfiguration
(Handover Command)
Handover Confirm(Synchronization,
Execution Phase
RRC Reconfiguration Complete)
Release Resource
Radio Resource
Release
As shown in the above figure, when the UE reports an MR, the eNodeB determines
that an intra-site handover is required, and sends a handover request to the target
cell. If the target cell is prepared, it notifies the source cell of its resource information,
and the source cell sends a reconfiguration message to the UE through the Uu
interface, notifying the UE to implement handover. After the handover is completed, it
is not required to notify the core network, because no S1/X2 link is involved during
the handover process.
1.4.2 S1-Based Inter-Site Handover

The interface between the E-UTRAN and the EPC is defined as the S1 interface. The
S1 interface is composed of the S1-MME interface on the control plane and S1-U
interface on the user plane. The S1-MME interface is used between the eNodeB and
the MME, and the S1-U interface is used between the eNodeB and the S-GW. The
following figures show the protocol stacks of the S1-MME and S1-U interfaces.
Figure 1-4 S1 Control-Plane Protocol Stack
S1-AP
SCTP
IP
Data link layer
Physical layer
Figure 1-5 S1 User-Plane Protocol Stack
User plane PDUs
GTP-U
UDP
IP
Data link layer
Physical layer
The following figures show S1-based handover (S1 handover).
Figure 1-6 S1-Based Handover (a): Before Handover
MME
S1 S1
X2
eNodeB2
eNodeB1
Uu
Figure 1-7 S1-Based Handover (b): After Handover
MME
S1 S1
X2
eNodeB2
eNodeB1
Uu
As shown in the above figures, S1-based inter-eNodeB handover (S1 handover)

includes the following:
1. Interaction between the source eNodeB and the MME through the S1 interface
2. Interaction between the UE and the source eNodeB through the Uu interface
3. Interaction between the UE and the target eNodeB through the Uu interface
4. Interaction between the target eNodeB and the MME through the S1 interface
5. Data forwarding from the source eNodeB to the target eNodeB
During S1 handover, a direct data forwarding path may exist between the source
eNodeB and the target eNodeB. Data forwarding in S1 handover can be classified
into direct forwarding and indirect forwarding. In S1 handover, the source eNodeB
may have data not sent to the UE. After the handover, the data can be directly or
indirectly forwarded to the target eNodeB. Direct forwarding means that the data is
forwarded through the X2 interface, which is the interface built on the user plane
(data transmission channel), and indirect forwarding means that the data is
forwarded through the S1 interface.
Upon receiving an MR and determining that handover is required, the source cell
where the UE is located determines whether the source cell and target cell are within
the same eNodeB. If they are not within the same eNodeB, the source cell needs to
determine the handover type. If the source cell determines that no X2 handover can
be implemented, it initiates an S1 handover procedure.
The following figure shows the S1 handover procedure.
Figure 1-8 S1-Based Handover Procedure
UE eNB1 eNB2 MME

1 Measurement Report
2 handover Require
Determines 3 handover Request
S1 handover
Allocates dedicated
resources
4 handover Request ACK
5 handover Command
6 RRC connection Reconfiguration

7.eNB Status transfer
8.MME Status transfer
Detached from S-eNB
9 RA Preamble
10 RA Response
11 RRC connection Reconfiguration Complete

12 handover notify
13 UE context release Cmd
14 UE context release Complete

Deletes the
UE instance
 Tips: S1-Based Handover Procedure
A normal S1-based handover procedure includes the following phases:
 Handover preparation phase: steps 1–5 in the above figure
 Handover implementation phase: steps 6–11 in the above figure
 Handover completion phase: steps 12–14 in the above figure
The S1 handover procedure is described as follows:
1. The UE in RRC connection state sends an MR to the eNodeB. If the

measurement event is Neighbour + Offset > Serving (Offset is a negative value)
in the message, the target cell does not belong to the local eNodeB, no X2
association exists between the source eNodeB and the target eNodeB, and the
source and target eNodeBs belong to the same MME, S1 handover is
implemented.
2. The source eNodeB sends a Handover Required message to the MME through
the S1 interface. This message contains the eNB UE X2AP ID allocated by the
local eNodeB, MME UE S1AP ID allocated by the MME, and handover type,
handover cause, UE capability, and UE security information.
3. Upon receiving the Handover Required message, the MME sends a handover
request to the target eNodeB through the S1 interface. Upon receiving the
handover request, the target eNodeB creates a new DCI instance, allocates a
new GID and a new eNB UE S1AP ID, and stores UE parameters from the
source eNodeB.
4. The target eNodeB sends a handover response containing UE admission

information to the MME.
5. The MME sends a handover command to the source eNodeB, and establishes a
forwarding tunnel.
6. The source eNodeB retrieves RRC connection reconfiguration information from

the handover command, and sends it to the UE.
7. The source eNodeB forwards data and sends the PDCP SNs of uplink and
downlink services to the MME through a UE status message.
8. The MME sends the PDCP SNs of uplink and downlink services to the target
eNodeB through an MME status message.
9. The UE implements a random access to the target eNodeB.
10. The target eNodeB permits the access of the UE.
11. The UE notifies the target eNodeB that RRC connection reconfiguration is
completed.
12. The target eNodeB sends a handover notify message to the MME through the
S1 interface, and sends uplink data to the core network.
13. The MME sends a UE Context Release Command message to the source
eNodeB, notifying the source eNodeB to release resources for the UE.
14. The MME responds with a UE Context Release Complete message, and the
source eNodeB releases memory resources and deletes the UE instance.
1.4.3 X2-Based Inter-Site Handover
Figure 1-9 X2 Interface Protocol Stack
The X2 interfaces connect two eNodeBs for signaling interaction. Load or

interference information and handover information need to be transmitted between
two eNodeBs through the X2 interfaces.
The following figures show X2-based handover (X2 handover).
Figure 1-10 X2-Based Inter-eNB Handover (a): Before Handover
S1 S1
X2
eNodeB2
eNodeB1
Uu
Figure 1-11 X2-Based Inter-eNB Handover (b): After Handover
MME
S1 S1
X2
eNodeB2
eNodeB1
Uu Uu
As shown in the above figures, X2 handover includes the following:
1. Interaction between the source eNodeB and the MME through the S1 interface
2. Interaction between the UE and the source eNodeB through the Uu interface
3. Interaction between the UE and the target eNodeB through the Uu interface
4. Interaction between the target eNodeB and the MME through the S1 interface
5. Data forwarding from the source eNodeB to the target eNodeB
The entire procedure involves the source eNodeB and target eNodeB, MME/S-GW,
and UE.
Upon receiving an MR and determining that handover is required, the source cell
where the UE is located determines whether the source cell and target cell are within
the same eNodeB. If they are not within the same eNodeB, the source cell needs to
determine the handover type (whether based on the X2 interface or S1 interface). If
there is an X2 association between the source eNodeB and the target eNodeB, and
the two eNodeBs are connected to the same MME, then X2-based inter-eNodeB
handover is implemented. If there is no X2 association between them, S1 handover
is implemented.
The following figure shows the X2 handover procedure.
Figure 1-12 X2-Based Inter-eNodeB Handover Procedure
UE eNB1 eNB2 MME
Determines X2 handover
2 handover Request
Admits the UE and allocates
dedicated resources
5 SN Status transfer
Detach from S-eNB
6 RA Preamble
7 RA Response
9 Path Switch Request
10 Path Switch Request ACK

11 UE context release
Deletes the
UE instance
 Tips: X2-Based Handover Procedure
A normal X2-based handover procedure includes the following phases:
Handover preparation phase: steps 1–3 in the above figure
Handover implementation phase: steps 4–8 in the above figure
Handover completion phase: steps 9–11 in the above figure
The X2 handover procedure is described as follows:
1. The UE in RRC connection state sends an MR to the eNodeB. If the

measurement event is Neighbour + Offset > Serving (Offset is a negative value)
in the message, the target cell does not belong to the local eNodeB, an X2
association exists between the source eNodeB and the target eNodeB, and the
source and target eNodeBs belong to the same MME, X2 handover is
implemented.
2. The source eNodeB sends a handover request message to the target eNodeB
through the X2 interface, which contains Old eNB UE X2AP ID allocated by the
source eNodeB, MME UE S1AP ID allocated by the MME, UE capability, UE
security, and UE history information, list of E-RABs to be established, and
destination address on the core network side for each E-RAB.
Upon receiving the handover request message over the X2 interface, the target
eNodeB creates a new DCI instance, allocates a new GID and a new eNB UE
X2AP ID, stores UE parameters from the source eNodeB, queries the database
to obtain admission parameters, admits the UE, and creates a service bearer
channel.
3. The target eNodeB sends a Handover Request Ack message to the source
eNodeB through the X2 interface, which contains the New eNB UE X2AP ID,
Old eNB UE X2AP ID, D-eNB admission success or failure information, and a
handover command to be sent by the source eNodeB to the UE. If
non-competitive handover is implemented, an RACH preamble is contained in
the handover command.
4. The source eNodeB receives the Handover Request Ack message over the X2
interface, retrieves the RRC connection reconfiguration data, and sends it to the
UE.
5. The source eNodeB stops downlink data transmission over the Uu interface and
uplink transmission data over the S1 interface, collects uplink and downlink
PDCP SNs, and prepares for data forwarding. The source eNodeB sends uplink
and downlink PDCP SNs to the target eNodeB through an SN Status Transfer
message.
6. Upon receiving the handover command, the UE synchronizes the command to

the target eNodeB, and implements a random access to the target eNodeB.
Upon receiving the random access request, the dispatcher starts to work. The
target eNodeB returns a Random Access Response message to the UE, which
contains uplink authorization and TA information.
7. For details, refer to Step 6.
8. The UE sends an RRC Connection Reconfiguration Complete message to the

target eNodeB.
9. The target eNodeB sends a Path Switch Request message to the MME, which
contains the MME UE S1AP ID on the source side, eNB UE S1AP ID allocated
by the target eNodeB, Switch-required E-RAB information, and UE security
information.
10. The MME sends a Path Switch Request Ack message to the target eNodeB,
which contains Path Switch success or failure information. Upon receiving the
message, the target eNodeB determines whether the destination address on the
uplink transport layer on the core network side is changed. If the destination
address is changed, a bearer channel needs to be established.
11. The target eNodeB sends a UE Context Release message to the source
eNodeB through the X2 interface, notifying the source eNodeB to release the
resources and delete the UE instance.
The largest difference between the X2 and S1 handover procedures lies in the
moment of interaction between the radio access network and the core network. In S1
handover, the source eNodeB establishes a connection with the target eNodeB
through the core network. In X2 handover, the source eNodeB directly interacts with
the target eNodeB, and notifies the core network after handover.
Data configuration is the same for X2 and S1 handovers. The neighbor cell
parameter whether to support X2 handover is set to yes by default. Whether X2
handover or S1 handover is implemented depends on the existence of an X2
association. If there is an X2 association, the system preferably implements X2
handover.
1.4.4 Inter-Frequency Handover
In inter-frequency handover, the frequency point configuration of the source cell is
different from that of the target cell. It is considered as an inter-frequency handover if
any one of the following conditions is met: (1) the two cells have different frequency
bands, (2) the two cells have different central frequency points, and (3) the two cells
have the same frequency band and central point but different bandwidths.
The process of inter-frequency handover from the handover decision to the handover
completion is the same as that of intra-frequency handover. The measurement
phases of the two types of handovers are different. In intra-frequency handover, the
system requests the UE to keep intra-frequency measurement from the beginning of
call establishment. In inter-frequency handover, inter-frequency measurement is
started only after the UE reports an MR of event A2. If there is an ongoing
inter-frequency measurement, and the UE reports an MR of event A1, the system
requests the UE to stop the inter-frequency measurement.
E-UTRAN inter-frequency measurement is implemented as follows:
1. Inter-frequency measurement setup
(1) After event A2 is reported
2. Inter-frequency measurement release
(1) After event A1 is reported
(2) The UE state changes to RRC_IDLE (it is not required to notify the UE to
release measurement through a message. The eNodeB releases the
measurement).
E-UTRAN intra-frequency and inter-frequency measurements and handovers comply

with the following principles:
1. For intra-frequency measurement and inter-frequency measurement, different

A3 configurations and measurement IDs are used.
2. A new measurement configuration can be manually created to use event A4/A5.
3. Inter-frequency measurement and measurement gap are started by event A2

and stopped by event A1.
4. The priorities of intra-frequency and inter-frequency handovers depend on the

MR threshold configuration.
5. When inter-frequency neighboring relationships that the UE supports are
configured at the back end, or inter-frequency ANR is enabled, the eNodeB
delivers measurement configuration data through an RRC connection
reconfiguration message for starting inter-frequency measurement triggered by
event A2.
6. Event A2 reporting: inter-frequency measurement is started and a gap is

activated. Upon receiving event A2, the eNodeB sends event A1 measurement
configuration, so that the UE stops inter-frequency measurement when the cell
quality is good enough. After receiving the MR of event A2, the eNodeB sends
event A3-based inter-frequency measurement configuration data to the UE and
notifies the UE to start inter-frequency measurement. If the UE detects that the
event A3 condition is met, the UE reports an MR for inter-frequency handover.
This flow ends.
7. Event A1 reporting: The UE periodically implements inter-frequency

measurement within the gap, until the signal quality of the serving cell is good. If
the event A1 condition is met, the UE reports event A1, and the eNodeB notifies
the UE to stop inter-frequency measurement and deactivate the gap.
For inter-frequency handover measurement, the eNodeB needs to deliver event

A1-based and event A2-based measurement configuration data to the UE. The event
A2-based configuration is used for the UE to start inter-frequency measurement, and
the event A1-based configuration is used for the UE to stop inter-frequency
measurement. When the UE meets the event A2 condition, the UE reports an MR
message to the eNodeB, and the eNodeB sends new inter-frequency measurement
configuration (based on event A3) to notify the UE to periodically search for other
eNodeBs. When the signal strength of another eNodeB and the local cell meet event
A3 condition, the UE reports an MR message, and the eNodeB makes a handover
decision and starts inter-frequency handover.
For example,
If the thresholds for event A2 and event A1 are -115 dBm and -105 dBm respectively,
when the UE detects the RSRP of the serving cell is lower than -115 dBm, event A2
is triggered. The UE reports an MR message to the eNodeB, notifying the eNodeB
that the signal quality is poor. The eNodeB sends new measurement configuration
(based on event A3) to the UE, which contains the target frequency points to be
searched for (maximum: 8), search gap, A3 offset (for example, 3 dB), lag (for
example, 0), and TTT (for example, 320 ms). The eNodeB also sends event A1
measurement configuration, where the threshold is -105 dBm. When the UE detects
a PCI signal on a target frequency point and determines that the signal strength is 3
dB higher than the PCI signal strength of the serving cell, which lasts for 320 ms, the
UE resends an MR message to the eNodeB. The eNodeB makes an inter-frequency
handover decision.
If the UE fails to detect any strong inter-frequency signal, and the signal quality of the
serving cell becomes good when the UE moves (-100 dBm) and is higher than the
event A1 threshold -105 dBm, then event A1 is triggered. The UE reports a new MR
message to the eNodeB, and the eNodeB sends new measurement configuration to
the UE to stop the inter-frequency measurement (based on event A3), because the
inter-frequency measurement affects the service rate on the UE.
2 Intra-LTE Handover Procedures and
Analysis
2.1 Protocol-Defined Handover Procedure
The 3GPP 36.300 protocol describes the general procedure of inter-eNodeB

handover within the E-UTRAN system, and the 36.331 protocol describes handover
actions, signaling, messages, and measurements. The entire handover procedure
can be divided into the following phases:
Measurement control, measurement reporting, handover decision, handover

preparation, handover execution, and handover completion
Figure 2-1 Intra-LTE X2 Handover Procedure
UE Source eNB Target eNB MME Serving Gateway
0. Area Restriction Provided

1. Measurement Control
packet data packet data
UL allocation Legend
L3 signalling
2. Measurement Reports
L1/L2 signalling
3. HO decision
User Data
4. Handover Request
Handover Preparation
5. Admission Control
6. Handover Request Ack
DL allocation
RRC Conn. Reconf. incl.
7.
mobilityControlinformation
Detach from old cell
Deliver buffered and in transit
and
packets to target eNB
synchronize to new cell
Handover Execution
8. SN Status Transfer
Data Forwarding
Buffer packets from

Source eNB
9. Synchronisation
10. UL allocation + TA for UE
11. RRC Conn. Reconf. Complete
packet data
packet data
12. Path Switch Request
13. User Plane update
request
End Marker
14. Switch DL path
Handover Completion
packet data
End Marker
15.User Plane update
response
16.Path Switch Request Ack
17. UE Context Release
18. Release
Resources
When a UE enters RRC Connected state for the first time, the eNodeB sends the first
RRCConnectionReconfiguration message to the UE for configuring handover
measurement events. When the UE moves to the target cell, the UE detects that the
signal strength of the target cell is better than that of the source cell, and the
condition of measurement event reporting is met, so the UE sends an MR to the
source cell. The source cell requests handover resources from the neighbor cell with
the best signal quality. The neighbor cell with the best signal quality starts admission
control. If it admits the UE, a handover is implemented. If it rejects the UE, the source
cell requests handover resources from the neighbor cell with the second best signal
quality. The UE receives the RRCConnectionReconfiguration message containing
mobility control information from the source cell, and tries to access the target cell
(perform a handover). After the handover is completed, the UE sends an
RRCConnectionReconfigurationComplete message to the target cell.
It can be concluded that intra-LTE handover is led by the eNodeB and assisted by
the UE. The eNodeB sends measurement configuration information to determine
what and how the UE is to measure and report. Upon receiving the measurement
configuration information, the UE performs measurements and reports MRs when
necessary (event conditions are met). The eNodeB makes handover decisions or
other actions (for example, starting or stopping inter-frequency measurement) in
accordance with the measurement result that the UE reports.
2.1.1 Handover Signaling Observed on the UE Side

The following figure shows the handover signaling observed on the UE side.
Figure 2-2 Handover Signaling Observed on the UE Side
The above figure shows measurement control, measurement reporting, handover

execution, and handover completion. Handover decision and handover preparation
are performed on the eNodeB, and cannot be observed on the NE side.
2.1.2 Handover Signaling Observed on the eNodeB Side

This section gives an example of S1-based inter-eNodeB handover procedure
observed on the eNodeB side through signaling tracing. As shown in the following
figure, upon receiving an MR (①) from the UE, the source eNodeB sends a
Handover Required message through the S1 interface ( ② ) and receives the

Handover Command message from the core network (③). The eNodeB sends an
RRCConnectionReconfiguration message ( ④ ), and releases resources upon
receiving the UE context deletion command over the S1 interface (⑤–⑦).
Figure 2-3 S1 Handover Signaling (1): Handover Required Message (1)
The following information element is contained in a Handover Required message: 1)

TargetCell_ID, which has 28 bits, where the first 20 bits indicate the eNB ID, and the
last eight bits indicate the Cell ID.
Figure 2-4 S1 Handover Signaling (1): Handover Required Message (2)

UE_HistoryInformation, which has 28 bits, where the first 20 bits indicate the eNB ID,
and the last eight bits indicate the Cell ID.
Figure 2-5 S1 Handover Signaling (1): Handover Required Message from the eNodeB (3)

duration for which the UE resided in the cell (seconds). In this example, the UE
resided in the cell for 202 seconds.
Figure 2-6 S1 Handover Signaling (2): Handover Command Message Received by the eNodeB
The Handover Command message received over the S1 interface contains target
RRC resource information used for constructing an RRCConnectionReconfiguration
message.
Figure 2-7 S1 Handover Signaling (3): RRCConnectionReconfiguration Message Sent by the
eNodeB
The mobilityControlInfo parameter in the RRCConnectionReconfiguration message

is the same as that in the Handover Command message.
2.2 Measurement Control
The E-UTRAN sends the measurement configuration information to the UE in

RRC_CONNECTED state through an RRCConnectionReconfiguration message.
The UE measures the measurement object in accordance with the
RRCConnectionReconfiguration message, and sends an MR in accordance with the
measurement rules.
The eNodeB can request a UE to report intra-frequency measurement,

inter-frequency measurement, and inter-RAT (UTRA, GERAN, and CDMA2000)
measurement information.
The measurement configuration includes the following parameters:
1. Measurement objects: The objects on which the UE shall perform the

measurements.
(1) For intra-frequency or inter-frequency measurements within the LTE

system, a measurement object is an LTE frequency. Associated with this
carrier frequency, E-UTRAN can configure a list of cell specific offsets
and a list of blacklisted cells. Blacklisted cells are not considered in event
evaluation or measurement reporting.
(2) For inter-RAT UMTS measurements, a measurement object is a set of
cells on a UMTS frequency point.
(3) For inter-RAT GSM measurements, a measurement object is a set of

GSM frequency points.
(4) For inter-RAT CDMA2000 measurements, a measurement object is a set

of cells on a CDMA1X or HRPD frequency point.
Note: In some measurements, the measurement object may be only one cell, for
example, the measurement for reporting neighbor cell system information or
delay of transmission between the serving cell and the UE.
2. Reporting configuration information, including reporting criteria (for triggering

the UE to send an MR) and reporting format (for example, the number of cells to
be reported ).
3. Measurement identities (IDs): The measurement configuration includes a

measurement ID list. Each measurement identity links one measurement object
with one reporting configuration. By configuring multiple measurement identities,
it is possible to link more than one measurement objects to the same reporting
configuration, and to link more than one reporting configurations to the same
measurement object. A measurement ID is used as a reference number in the
measurement report.
4. Quantity configurations: One quantity configuration is configured per RAT type.

The quantity configuration defines the measurement quantities and associated
filtering used for all event evaluation and related reporting of that measurement
type.
5. Measurement gaps: periods that the UE may use to perform measurements,

meaning that no (UL, DL) transmissions are scheduled.
Note: Intra-frequency measurements have no effect on services. Inter-frequency

measurements have effects on services, which are described as follows:
According to Section 8.1.2.1 of the 3GPP 36.133 protocol, in gap mode 0, the
measurement window is 6 ms and the measurement period is 40 ms, and in gap
mode 1, the measurement window is 6 ms and the measurement period is 80 ms.
In addition, within the period of 4 ms before gap measurement, no downlink

transmission is allowed. In the case of full-cache download for a single user, the
heaviest loss of downlink throughput in gap mode 0 is 25%((4+6)/40) and
12.5%((4+6)/80) in gap mode 1.
The third parameter measurement identities (measurement IDs) are used as index
numbers and measurement object and configuration associations. For example, if
there are three measurement objects and two reporting configurations, then there are
a maximum of six measurement IDs.
The following figure shows a typical measurement configuration example. The

eNodeB sends the measurement configuration to the UE entering
RRC_CONNECTED state for the first time through the
RRCConnectionReconfiguration message.
Figure 2-8 Measurement Configuration Received by the UE
As shown in the above figure, the measurement configuration includes the following:
measurement object, reporting configuration, measurement ID, quantity configuration,
and s-Measure. There is only one MeasID (measurement ID), which links
measurement object 1 with reporting configuration 1.
The above figure shows an intra-RAT measurement, and no inter-frequency or
inter-RAT neighbor cells are configured, so the system does not send the gap
configuration (measGapConfig). Instead, the system sends the s-Measure field.
The s-Measure field is described as follows:
1. It is an optional protocol-specified field. This field defines when the UE is
required to perform measurements. If this field is configured and the RSRP
value of the serving cell after Layer-3 filtering is lower than the s-Measure, the
UE perform neighbor cell measurements.
2. Integer from 0 to 97, corresponding to actual RSRP values as shown in the

following table. The first column lists the s-Measure values, and the second
column lists the RSRP values. Their relationship can be roughly described as
follows: RSRP = -140 dBm + s-Measure. In this example (serving cell of another
vendor), s-Measurement is 97, which means the largest RSRP value. In this
case, the UE is requested to perform measurements at any time. This field in
the ZTE system is 70 by default, meaning that the UE performs measurements
after the RSRP value is lower than -70 dBm.
Table 2-1 RSRP Reported Value and Quantity Value Relationships
Reported value Measured quantity value Unit
RSRP_00 RSRP  -140 dBm
RSRP_01 -140  RSRP < -139 dBm
RSRP_02 -139  RSRP < -138 dBm
… … …
RSRP_95 -46  RSRP < -45 dBm
RSRP_96 -45  RSRP < -44 dBm
RSRP_97 -44  RSRP dBm
Note: Suppose the RSRP reported value is X, and the actual value is about X – 140
dBm (between (X – 141) dBm and (X – 140) dBm).
2.3 Measurement Reporting
In Figure 2-8, there is a MeasID parameter, which corresponds to the MeasID

parameter in the MR message, so that the system can determine the measurement
ID based on which the UE reports the MR message. As shown in Figure 2-9, MeasID
= 1.
Figure 2-9 Intra-LTE Intra-Frequency Handover Signaling (1): Handover Control
In the above figure, the MeasID parameter (MeasId = 1) corresponds to the MeasId
in the MR that the UE reports.
Figure 2-10 Intra- LTE Intra-Frequency Handover Signaling (2): MR Reporting
Note: 1) In the above figure, MeasID = 1, which corresponds to the ID in the

measurement configuration, 2) the PCI of the target neighbor cell in the MR message
is 94, 3) the RSRP of the serving cell is about –100 dBm, and the RSRP of the target
cell is –96 dBm.
2.4 Handover Decision
If the neighbor cell configuration is missing, the handover decision may fail. In some
cases where faults occur, the system may consider it unsuitable to perform handover.
These cases need to be further analyzed.
2.5 Handover Preparation
In handover preparation, the eNodeB of the serving cell requests the eNodeB of the
target cell to prepare handover resources through the X2 or S1 interface. In
intra-eNodeB handover, the serving cell requests the target cell to prepare handover
resources.
A timer is started for handover preparation. If no message is received from the target
eNodeB or MME within the timer duration, the system times out, and it is defined as a
failure.
If a rejection message is received from the target eNodeB or MME within the timer
duration, it is also defined as a preparation failure.
The following causes may result in preparation failure:
Resource congestion or license restriction on the target eNodeB
Abnormal target eNodeB (for example, hardware failure)
Incorrect neighbor cell configuration, for example, incorrect PCI or TAC, resulting in
that the MME cannot match the correct cell
Poor quality of the S1and X2 logical links, resulting in packet loss
These are common causes of preparation failure.
2.6 Handover Execution
Similar to measurement control, handover execution is implemented through a

command encapsulated in an RRCConnectionReconfiguration message. If the
MobilityControl field is contained in the message, it indicates that a handover
execution command is contained.
Figure 2-11 Intr-LTE Intra-Frequency Handover Signaling (3): RRCConnectionReconfiguration
Message Sent by the eNodeB
Note:
1. As shown in the above figure, the source cell sends the RRC resource
information of the target cell (PCI = 94), so that the UE can access the target
cell.
2. In this message, RRC_TransactionIdentifier = 1, which agrees with this field in

the RRCConnectionReconfiguration Complete message that the UE returns.
The following causes may result in handover execution failure:
1. The frequency and PCI of the neighbor cell are the same as the source cell,
resulting in the source being unable to deliver the MobilityControl field to the
correct target cell, so the UE cannot access the correct target cell. An RRC
connection is reestablished on the source cell.
2. In a high-speed scenario (high-speed rail or free way), the target cell with good
signal quality has a small coverage. When the source cell delivers the
MobilityControl parameter, the signal quality changes abruptly (very good to
very poor), and the UE cannot access the target cell, and an RRC connection is
reestablished on the source cell.
3. Strong external interference in uplink and downlink directions cause a large

number of handover execution failures, but handover preparations are
successful, and an extraordinary number of handover preparations are
performed (it may be caused by MR reporting exception due to strong
interference).
2.7 Handover Completion
Figure 2-12 Intra-LTE Intra-Frequency Handover Signaling (4): RRCConnectionReconfiguration

Complete Message from the UE
Note: The RRC_TransactionIdentifier field is 1, which agrees with the same field in
the corresponding RRCConnectionReconfiguration message.
3 Handover Parameter Setting Instructions
3.1 Neighbor Cell Configuration Overview
Neighbor cell configuration requires two steps: neighbor cell configuration on the
eNodeB layer, and neighbor relationship configuration on the cell layer, where
neighbor relationship configuration is a subset of the neighbor cell configuration.
3.1.1 Neighbor Cell

Select an eNodeB, and select Modify Area > Wireless Parameter > E-UTRAN FDD
Cell > Neighbor Cell. There are two child nodes under the Neighbor Cell node:
E-UTRAN FDD Neighbor Cell and E-UTRAN TDD Neighbor Cell. The E-UTRAN
FDD neighbor cell list includes FDD LTE intra-frequency and inter-frequency
neighbor cells, and the E-UTRAN TDD neighbor cell list includes TD-LTE
inter-frequency neighbor cells. See the following figure.
Figure 3-1 Neighbor Cell
The following uses the E-UTRAN FDD neighbor cell list as an example. Click the
New button at the left upper corner. The dialog box for adding a neighbor cell is
displayed.
Figure 3-2 Adding a Neighbor Cell
Some parameters in the above figure are described as follows:
 E-UTRAN FDD Neighbor Cell Id
 Cell ID
 Antenna Port1 Used By Cell: Set it as required. If it is a dual-channel neighbor

cell, set it to Yes. If it is a single-channel neighbor cell, set it to No.
Set the bandwidth and central frequency of the neighbor cell as required.
The parameters of an E-UTRAN TDD neighbor cell are the same as those of an
E-UTRAN FDD neighbor cell.
3.1.2 Neighbor Relationship
After neighbor cell configuration, select the eNodeB, and select Modify Area >
Wireless Parameter > E-UTRAN FDD Cell > Neighbor Relationship Config >
E-UTRAN Neighbor Relationship. See the following figure.
Figure 3-3 Neighbor Relationships
Double-click E-UTRAN Neighbor Relationship. The E-UTRAN neighbor

relationship list is displayed in the right, where the existing neighbor relationships are
listed. See the following figure.
Note: The neighbor relationship is specific to each cell, and the neighbor
relationships of all the cells are contained in the list.
FDD LTE intra-frequency and inter-frequency neighbor cells and TD-LTE neighbor
cells are contained in the list.
Figure 3-4 Neighbor Relationship List
Click the New button at the left upper corner. The dialog box for adding a neighbor
relationship is displayed.
Figure 3-5 Adding a Neighbor Relationship
In the above figure, three parameters are underlined, and correspond to the intra-site
neighbor cell, FDD LTE neighbor cell, and TD-LTE neighbor cell respectively. Click
next to each parameter to select a neighbor cell from the existing neighbor
cells. See the following figure.
Figure 3-6 Associating a Neighbor Relationship With a Neighbor Cell
Select a neighbor cell, and click OK. Set other parameters as required. In general,
keep the default settings for other parameters, and click .
3.2 Handover Parameter Settings
3.2.1 Event A3–Related Parameters in Measurement Configuration

The following figure shows parameters of event A3–based intra-frequency
measurement configuration.
Figure 3-7 Intra-Frequency Event A3 Parameters (Measurement Configuration ID = 52)
Some parameters are described as follows:
3.2.1.1 Report Criteria
 Description
A measurement report can be triggered by an event (when particular conditions

are met) or periodically.
 Setting
Intra-frequency handovers are set to be triggered by an event.
3.2.1.2 A3Offset
 Description
In accordance with 3.3, event A3 is triggered when the quality of a neighbor cell
is offset higher than the serving cell, and the offset is indicated as Off in the
following formula (also indicated as a3-Offset):
Mn  Ofn  Ocn  Hys  Ms  Ofs  Ocs  Off
 Setting
Based on the formula of entering condition for event A3, a larger a3-Offset value
requires a bigger difference of the signal strength between the neighbor cell and
the serving cell for triggering event A3–based handover, and means a later
reporting of the measurement result (handover request).
In general, a3-Offset is set to 3 or 4 dB, and it is not recommended that you set
it to any other value greater than 3 or 4 dB. To avoid frequent handovers,
a3-Offset cannot be too small. If you need to accelerate measurement reporting,
you can modify the neighbor cell individual offset parameter defined in Section
3.2.3.1.
3.2.1.3 TimeToTrigger
 Description
To avoid ping-pong handovers, the UE does not report event A3 immediately

when the signal quality of the neighbor cell is offset higher than the serving cell.
The UE sends a measurement report only if the signal quality of the neighbor
cell meets the entering condition for event A3 and is maintained for a period
specified by the TimeToTrigger (TTT) parameter.
 Setting
If TTT is set to a great value, measurement reporting is delayed, and the

number of handovers is reduced. In a mobile scenario (for example, drive
testing), the service rate may be reduced because the UE fails to be handed
over to a better neighbor cell. A small TTT value can accelerate measurement
reporting and may increase the number of handovers. In some areas with poor
signals, frequent UE handovers may also reduce the service rate.
This parameter is an enumerated type, and its options include 0, 40, 64, 80, 100,
128, 160, 256, 320, 480, 512, 640, 1024, 1280, 2560, and 5120.
3.2.1.4 Hysteresis
 Description
In accordance with the formulas of entering and leaving conditions for event A3
in Section 1.3, the Hysteresis parameter is a threshold for controlling the
entering and leaving of event A3, and decides the time for which the UE resides
in event A3. See the following figure.
Figure 3-8 Hysteresis Description
Mn  Ofn  Ocn
Enter
Hysteresis
Ms  Ofs  Ocs  Off

Hysteresis
Leave
Mn  Ofn  Ocn
 Setting
By default, this parameter is set to 1.5 dB.
This parameter determines the signal strength interval that makes the UE reside
in event A3. A greater value means a higher signal strength of the neighbor cell
required for entering of event A3 (meaning a later handover) and a lower signal
strength of the neighbor cell required for leaving of event A3 (meaning a long
period for which the UE resides in event A3). It is recommended that the default
value be kept for this parameter.
3.2.1.5 ReportOnLeave
 Description
This parameter specifies whether to send a measurement report when the UE
leaves event A3. Leaving condition for event A3:
Mn  Ofn  Ocn  Hys  Ms  Ofs  Ocs  Off .
 Setting
By default, this parameter is set to False, meaning that no measurement report

is sent when the UE leaves event A3.
3.2.1.6 ReportInterval and ReportAmount
 Description
For measurement reports triggered by an event, the reportInterval parameter

can be used together with the reportAmount parameter. If reportAmount is
greater than 1, reportInterval is valid. If an event satisfies the reporting criteria,
the UE sends a number of (specified by reportAmount) measurement reports
consecutively at intervals of reportInterval.
For measurement reports triggered periodically, reportInterval means the

reporting interval.
 Setting
ReportInterval is an enumerated-type parameter, and its options include 120,

240, 480, 640, 1024, 2048, 5120, 10240, 60000, 360000, 720000, 1800000,
and 3600000 (ms).
ReportAmount is an enumerated-type parameter, and its options include 1, 2, 4,

8, 16, 32, 64, and Infinity.
In accordance with optimization cases, when reportInterval is set to 480 ms and

reportAmount is set to Infinity, the handover success rate can be improved, and
whether any neighbor cell configuration is missing can be determined.
3.2.1.7 Layer 3 Filtering FilterCoefficient
 Description
In the LTE system, the measurement result reported by a UE is the value after
layer 3 filtering, and an L3 filter is used to avoid the contingency of a single
measurement. The UE uses the following formula to filter the measurement
result:
Fn  (1  a)  Fn1  a  M n
Where Mn is the measured value on the physical layer.
Fn is the filtered measured value, which is matched with the report criteria and
reported in the measurement report.
Fn-1 is the measured value obtained after the preceding filter is applied. It should
be noticed that F0 = M1, meaning that the first measurement result is the value
measured on the physical layer.
a = 1/2(k/4), where k is the filterCoefficient parameter.
 Setting
This parameter is an enumerated type, and its options include 0, 1, 2, 3, 4, 5, 6,

7, 8, 9, 11, 13, 15, 17, and 19. The filter coefficient is indicated by k in the above
formula. See the following figure.
Figure 3-9 Modifying Layer 3 Filter Coefficient (1)
Figure 3-10 Modifying Layer 3 Filter Coefficient (2)
If the filter coefficient is 0, layer 3 filtering is not applied, meaning that each value
reported by the UE is the value measured on the physical layer.
k = 1:
Fn  0.16Fn1  0.84M n
Fn  0.29Fn1  0.71M n
k = 2:
Fn  0.41Fn1  0.59M n
k = 3:
Fn  0.5Fn1  0.5M n
k = 4:
A larger filter coefficient means that the current measurement result on the physical
layer is less relevant to the filtered value (which is more relevant to historical
measurement results).
In a fast fading scenario (for example, at the corner or through a shadow area), it is
recommended that the layer 3 filter coefficient be reduced (set to 1 or 0), so that the
filtered value is more close to the current measurement result on the physical layer.
3.2.2 Serving Cell Individual Offset

 Description
This parameter is Ocs in the formula Mn  Ofn  Ocn  Hys  Ms  Ofs  Ocs  Off ,
and is used to accelerate or decelerate a handover. It is valid for all the neighbor
relationships involved in event A3 handovers.
 Setting
This parameter is an enumerated type, and its options include -24,-22,-20, -18,
-16, -14, -12, -10, -8, -6, -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16, 18,
20, 22, and 24 (dB).
3.2.3 Neighbor Cell Individual Offset
This parameter is set in the neighbor relationship list.
3.2.3.1 Neighbor Cell Individual Offset (CIO)
 Description
The a3-Offset is a parameter common to all the neighbor cells. It is not proper to
modify a3-Offset to increase the handover threshold flexibility and adjust the
thresholds for handovers to some specific neighbor cells. In this case, you can
set the CIO of a specific neighbor cell.
CIO of a neighbor cell is indicated by Ocn in the event A3 formulas.
Figure 3-11 Modifying the CIO of a Neighbor Cell (1)
Figure 3-12 Modifying the CIO of a Neighbor Cell (2)
 Setting
This parameter is an enumerated type, and its options include -24,-22,-20, -18,
-16, -14, -12, -10, -8, -6, -5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5, 6, 8, 10, 12, 14, 16, 18,
20, 22, and 24 (dB).
To accelerate handovers from the serving cell to a neighbor cell (reduce the
handover threshold), you can increase the CIO of the neighbor cell (which is
normally in the range of 1 to 3 dB). At corners or in deep fading scenarios, the
signal quality of the target cell is also not good. To avoid fast fading of the signal
strength of the serving cell that results in handover failure, you can modify the
CIO of the neighbor cell, so that the UE is handed over to the target cell earlier
before the signal quality of the serving cell declines.
3.2.4 Handover Timers

 Descriptions
Table 3-1 Timer Descriptions
Timer Description Start Stop At Expiry
In case of
cell
change
order from
E-UTRA
or intra
E-UTRA
handover,
initiate the
RRC
Criterion for
Reception of connectio
successful
RRCConnectionRec n
completion of
onfiguration re-establis
handover within
message including hment
Timer of waiting for E-UTRA, handover
the MobilityControl procedure;
T304 handover success to E-UTRA or cell
Info or reception of In case of
(ms) change order is met
MobilityFromEUTRA handover
(the criterion is
Command message to
specified in the
including E-UTRA,
target RAT in case of
CellChangeOrder. perform
inter-RAT).
the
actions
defined in
the
specificati
ons
applicable
for the
source
RAT.
Timer started after The target eNodeB

Reception of a Path
the eNodeB sends a sends a Path Switch Perform
pathSwitchT Switch response
PATH SWITCH Request message to exception
imer from the core
message to the the MME in an X2 handling.
network.
MME (ms) handover.
Reception of an
Timer of waiting for RRCConnectionRec
The eNodeB sends
the onfiguration
an Perform
rrcReCfgTi RRCConnectionRec Complete message
RRCConnectionRec exception
mer onfiguration from the UE or as
onfiguration handling.
Complete message stopped by the
message to the UE.
(ms) RRCConnectionRec
onfiguration request.
The source eNodeB

sends a Reception of a
Timer of waiting for Perform
s1HoPrepar handoverRequired handover command
an HO Command in exception
eTimer message to the core from the core
an S1 HO (ms) handling.
network in an S1 network.
handover.
Timer of waiting for The source eNodeB

Reception of a
the MME's release receives a handover Perform
s1HoOverAl release command
command after a command from the exception
lTimer from the core
successful S1 core network in an handling.
network.
handover S1 handover.
The source eNodeB

Reception of a
X2 handover sends a handover Perform
x2HoPrePar handover command
preparation timer request to the target exception
eTimer from the target
(ms) eNodeB in an X2 handling.
eNodeB.
handover.
The source eNodeB

Timer of waiting for a receives a Handover Reception of a
Perform
x2HoRelTim release command Request release command
exception
er after a successful X2 Acknowledge from the target
handling.
handover (ms) message in an X2 eNodeB.
handover.
The timer is started

when a UE is
handed over from
cell A to cell B.
Before the timer
pingPongT Ping-pong handover expires, the UE
Null
mr suppression timer cannot be handed
over back to cell A.
This timer is valid
when ping-pong
handover prevention
is enabled.
 Settings
Defaul
Timer Setting
t
t304 0:50, 1:100, 2:150, 3:200, 4:500, 5:1000, 6:2000 2000[6]
pathSwitchTimer [10..10000] step 10 5000
rrcReCfgTimer [10..16000] step 10 8000
s1HoPrepareTimer [10..20000] step 10 10000
s1HoOverAllTimer [10..30000] step 10 15000
x2HoPrePareTime [10..6000] step 10 5000

r
x2HoRelTimer [10..20000] step 10 10000
pingPongTmr [0..30] 2
4 Handover Problem Analysis
Handover problems are analyzed through signaling procedures.
4.1.1 Signaling Analysis on the Radio Air Interface Side

In a handover procedure, three signaling messages are transmitted over the Uu
interface: measurement report (MEASUREMENT REPORT), handover command
(RRC CONN RECFG), and handover completion (RRC RECFG CMP). For
immediate RRC connection release or reestablishment after a handover, the first
RRC CONN RECFG message after the handover should be checked. The
reconfiguration message after the handover is not related to the handover procedure,
and is unexpectable.
You can analyze problems in accordance with the following flow:
Figure 4-1 Signaling Analysis for Handover Failure
Start
Whether the No
eNB receives Refer to 0.
an MR?
Yes
Whether the No
eNB sends a Refer to 0.
handover
command?
Yes
Whether the eNB No

receives a
Refer to 7.
handover complete
message?
Yes
Collect failure
No Problem
info and send it
resolved?
to R&D
Yes
End
There are many handover failure causes. This document describes only common
causes. The general analysis flow is the same: Based on the typical signaling
procedure, analyze detected signaling messages and signaling messages traced on
the network management system, find exceptions, and determine the failure cause.
4.1.1.1 Measurement Report Loss
Figure 4-2 MR Loss Analysis Flow
Start
No
Measuremen
Check measurement control
t control?
Yes
Check coverage and

End
interference
You need to determine whether the UE sends an MR message.
1. If the UE sends an MR message, but the eNodeB does not receive the message,
it may be caused by the following:
(1) Uplink interference
(2) Poor coverage with a great path loss
(3) Poor downlink quality, resulting in that the UE fails to demodulate the
downlink, and cannot obtain the uplink scheduling information
2. If the UE does not send any MR message, perform the following checks:
(1) Check whether the configuration is proper.
(2) Check whether the control message is sent.
The UL grant in the measurement report that the UE sends is not received, and the
PDCCH is restricted.
The eNodeB does not receive the measurement report from the UE, or receives the
measurement report but the CRC is incorrect, and the PUSCH is restricted.
Data loss occurs between internal layers of the UE. For example, when the L3
requests the L2 to send a measurement report, the L2 fails.
The configuration is incorrect, resulting in that the measurement control rules fail to
be sent to the UE. The UE keeps initiating reestablishment requests and cannot
make a further step to send a measurement report.
4.1.1.2 Handover Command Loss
Figure 4-3 Analysis of eNodeB's Failure in Sending an RRCConnectionReconfiguration Message
Start
Handover No
Check whether the target
decision accepted
cell is configured or in
on the source
the blacklist?
side?
Yes
Handover Check resources and

preparation OK alarms on the target
on the target No eNodeB/cell
side?
Yes
End
1. Check whether the source eNodeB sends a handover request to the target
eNodeB or MME. If it sends a handover request, it indicates that the handover
decision on the source eNodeB is accepted. Check whether the neighbor cell is
configured or is in the handover blacklist.
2. If the target eNodeB sends a rejection message to the source eNodeB or MME, it
indicates that the handover preparation on the target eNodeB fails. Check
resources and X2/S1 link status.
3. The eNodeB has a fault in internal processing (for example, insufficient

resources or abnormal status), and does not send any handover command.
4. The UE PDCCH fails to be resolved, and the PDCCH is restricted.
5. The UE PDSCH fails to be resolved, and the PDSCH is restricted.
6. The neighbor cell configuration is missing, resulting in that the eNodeB resolves
the MR, but cannot know the cell corresponding to the PCI. Therefore, the
eNodeB fails to makes a handover decision and cannot send any handover
command.
7. The TAC configuration of the neighbor cell is different from that on the MME, so
no handover command is sent.
4.1.1.3 Handover Complete Signaling Loss
Figure 4-4 Analysis of the eNodeB's Failure in Receiving an RRCConnectionReconfiguration

Complete Message
The eNB sends a

handover command
to the UE
UE receives the No Improve downlink

HO command? coverage
Yes
1. Improve downlink coverage

UE sends No
2. Check parameters in the
HO complete to
reconfiguration message
eNB?
3. Check random access parameters
Yes
Improve uplink
coverage
After the eNodeB sends an RRCConnectionReconfiguration message, the UE

executes handover. Due to uncertainty of the air interface, most handover failures
occur at this step, and are related to the link coverage quality.
The eNodeB does not receive the PREAMBLE of the UE on the target cell, and the
uplink PRACH is restricted.
The UE fails to receive the RAR, and the PDSCH is restricted.
The UE sends a handover complete message, but the eNodeB does not receive the
message, and the PUSCH is restricted.
4.1.2 Handover Failure Symptoms

For radio transmission over the Uu interface, the channels can be divided into uplink
channels and downlink channels for quality analysis. If the RSRP, SINR, IBLER, and
DL/UL_GRANT information can be obtained on the UE side, uplink and downlink
problems can be analyzed together with signaling tracing on the network side. The
following parameters need to be checked for channel quality analysis:
RSRP: downlink pilot received power. The pilot channel quality is different from the
data channel quality. However, the data channel quality can be roughly learnt about
by referring to the pilot channel RSRP and SINR. If RSRP > –85 dBm, the user is at a
nearby place. If RSRP = –95 dBm, the user is at a middle-distance place. If RSRP <
–105 dBm, the user is at a far place. The user location cannot completely determine
the channel quality. In the load scenario, it is possible that users at the
middle-distance and nearby places still have poor channel quality (when the neighbor
cell's RSRP is close to the serving cell's RSRP, there is large interference). Other
parameters are required to determine the channel quality.
SINR: downlink pilot SINR. You can roughly learn about the data channel condition
through the pilot SINR. If SINR < 0 dB, it indicates that the downlink channel quality is
not good. If SINR < -3 dB, it indicates that the downlink channel quality is very bad,
easily causing handover signaling loss and resulting in handover failure.
BLER: In normal cases, the BLER should converge toward the target value (10%. If
the channel quality is very good, the BLER is close to or equal to 0%). If there is a
large BLER value, it indicates that the channel quality is not good and there are many
data errors, easily causing connection release, handover failure, or a large handover
delay. The downlink BLER can be obtained from front-end test data.
In RF optimization, when the neighbor cells and resources are normal, the following
cases may occur based on the handover parameters and coverage condition:
4.1.2.1 Early Handover
When the signal quality of the neighbor cell is improper or unstable, the eNodeB
initiates a handover, and this is called an early handover. Early handovers include
the following:
1. After the source cell sends a handover command, the signal quality of the target
cell is not good, and the UE fails to be handed over to the target cell. The UE
initiates RRC connection reestablishment to go back to the source cell. In this
case, the handover fails because the UE fails to be handed over to the target
cell by random access or sending msg3, and the UE initiates an RRC
connection reestablishment request to the source cell.
2. The UE is successfully handed over to the target cell, but downlink out-of-sync
occurs immediately, so the UE initiates an RRC connection reestablishment
request in the source cell. This is also defined as an early handover.
3. The UE is successfully handed over to the target cell, but it is handed over to a
third-party cell within a very short time. This is also defined as an early
handover.
4.1.2.2 Late Handover
Late handovers include the following:
1. In the 100% downlink load scenario, the service quality of the source cell is not
good (if SINR < –3, it is probable that handover commands may fail to be sent),
and the UE fails to receive a handover command or fails to perform random
access upon receiving the handover command. In this case, the UE initiates an
RRC connection reestablishment request to the target cell. A context is
established in the target cell, so the reestablishment can succeed.
2. Before the UE sends a measurement report, the signal quality of the source cell
abruptly declines, resulting in downlink out-of-sync. In this case, the UE directly
initiates an RRC connection reestablishment request to the target cell. No UE
context exists in the target cell, so the reestablishment is rejected.
4.1.2.3 Ping-Pong Handover
When a UE performs A->B and B->A back-and-forth handovers, after the UE is

handed over from cell A to cell B, the UE resides in cell B for a short time, and then is
handed over back to cell A. If the period between the UE's entering a target cell and
leaving the target cell is too short, for example, multiple handovers occur within one
second, they are considered as ping-pong handovers.
4.1.3 X2 Interface Signaling Analysis

Only inter-site handovers through the X2 interface have signaling messages
transmitted on the X2 interface. The following signaling messages are transmitted on
the X2 interface: HANDOVER REQUEST, HANDOVER REQUEST ACK, SN
STATUS TRANSFER, and UE CONTEXT RELEASE (see 2, 3, 5, and 11 in the
following figure).
Figure 4-5 X2 Interface Handover Signaling
UE eNB1 eNB2 MME
Determines X2 handover
2 handover Request
Admits the UE and allocates
dedicated resources
5 SN Status transfer
Detached from S-eNB
6 RA Preamble
7 RA Response
9 Path Switch Rrquest
10 Path Switch Rrquest ACK

11 UE context release
Deletes the
UE instance
Signaling failure on the X2 interface is analyzed as follows:
1. Handover request loss may be caused by the following:
(1) The eNodeB fails to process the measurement report, for example, the
neighbor cell configuration is missing or its internal module fails.
(2) The X2 interface does not operate properly, for example, packet loss
occurs.
2. Handover response loss may be caused by the following:
(1) The source cell does not operate properly. Before the target cell responds
to the handover request, the source cell sends a HANDOVER CANCEL
command to the target cell through the X2 interface.
(2) The target cell fails to prepare for handover. In this case, a HANDOVER
PREPRATION FAILURE message is transmitted through the X2
interface.
occurs.
3. Loss of the SN status transfer message may be caused by the following:
occurs.
(2) The source cell has an internal error.
4. The loss of the UE context release message may be caused by the following:
occurs.
(2) Upon receiving the handover complete message, the target cell fails to
process the message, resulting in failure in S1 PATH handover.
(3) S1 PATH handover failure
Message interaction errors on the X2 interface are normally caused by transmission

failure or internal errors of the eNodeB, and need to be notified to the R&D for
analysis by capturing packets from multiple NEs.
4.1.4 S1 Interface Signaling Analysis

All inter-eNodeB handovers have signaling messages transmitted on the S1 interface,
regardless of whether they are S1 handovers or X2 handovers. For X2 handovers,
there are two signaling messages transmitted on the S1 interface: S1AP PATH
SWITCH REQ and S1AP PATH SWITCH REQ ACK. For S1 handovers, multiple
signaling messages are transmitted between the source eNodeB and the target
eNodeB through the S1 interface. See the following figure.
Figure 4-6 S1 Interface Handover Signaling
Message interaction errors on the S1 interface are normally caused by transmission

failure or internal errors of the network devices.
If the device rejects the handover request, find out why the device rejects the
request.
If a response is not received, find out the following:
Does the related NE return a response message?
Is the response message lost during transmission?
For signaling message rejection or loss on the S1 interface, you need to trace
signaling of multiple NEs to locate the causes.
5 Handover Problem Positioning
5.1 Performance Statistics Analysis
The network management system provides lots of handover timers and performance
indicators. If the handover success rate is low, analyze the performance statistics to
find out reasons. Performance statistics analysis for LTE handover problems is
similar to that for 2G/3G handover problems. Determine the sub-scenario that has
the largest effect on general indicators, and perform related tests, analysis,
adjustment, and checks.
The handover success rate can be analyzed from the following aspects:
Time: Determine whether the handover failures occur periodically or occasionally, or

whether the signal quality gradually declines after a particular time point. If the
failures occur periodically, locate the causes by analyzing the period. If the signal
quality gradually declines after a particular time point, determine the event occurring
at this time point, for example, any version upgrade, key operation, or external
interference.
Location: Determine whether the problem occurs in a network-wide area or in a

specific area? If the problem occurs in a specific area, check the interference and
transmission. If the problem occurs in a network-wide area, check the common
parameters and version.
Failure causes: Determine the major failure causes, so that you can further
determine the specific step that causes the failure. For example, a handover includes
handover preparation and handover execution. Determine whether it is a handover
preparation failure or handover execution failure. If it is a handover preparation failure,
the failure is not related to the radio network.
Neighbor cells: If the handover success rates of a few cells are low, locate the
involved target cells through cell pair statistics. For example, if a cell can successfully
hand over UEs to target cells, but UEs cannot be handed over to this cell, then the
cell pair statistics show that the handover success rates are low of this cell serves as
the target cell.
Users: Find out the users with a high handover success rate and those with a low
handover success rate. This requires the assistance of CDT data.
Other associated features: Handovers are associated with many other features,
including the following:
 Uplink RSSI
 RRC connection release rate
 Number of RRC connection reestablishments and reestablishment success rate
 RRC connection success rate
 Number of users, and load
5.2 Handover KPI Optimization
Handovers cannot be optimized by modifying a specific parameter or enabling a

specific function. Full coverage optimization and neighbor cell optimization are
required. On this basis, handover parameters can be optimized on a fine basis.
1. Neighbor cell optimization
(1) Use drive testing software to check whether the neighbor cell
configuration is missing or incorrect.
(2) Determine the neighbor cells involved in a small number of handovers or

with a low success rate through the neighbor cell pair statistics of the
network management system. The missing of neighbor cell configuration
cannot be found in the neighbor cell pair statistics.
(3) Optimize neighbor cells through SON ANR.
(4) Analyze the CDT data, but there is no good tool.
(5) Check the data consistency of external cells, and check far neighbor cells,
nearby neighbor cells with missing configuration data, and PCI conflicts.
(6) Determine the missing neighbor cells through drive testing data.
2. RF optimization (cell power, RS power, and feeder adjustments)
3. Optimization of the intra-frequency handover parameters, threshold for starting

inter-frequency measurements, and threshold for inter-frequency handovers
4. SON algorithms (such as ANR, PCI, and MRO)
Modification of cells with improper PCI multiplexing
5.3 Handover Problem Resolving Procedure
Figure 5-1 Handover Problem Resolving Procedure
Handover Problem
Analysis
Whether 100%
handover failure?
Whether any fault Check

affecting performance hardware Whether any critical Check
exists fault exists hardware
Handle
Checkneighb
Whether congestion congestion
Whether neighbor cell or
improper relationship
configuration
Whether PCI/ PRACH Replan

parameters improper parameters
Whether target cell Handle target
ultra-far coverage cell coverage
Check
Whether handover handover
parameters improper parameters
Whether timer Handle delay

parameters improper problem
Handle
Whether coverage coverage
problem? problem
Handle the
Whether uplink/ uplink/
downlink interference downlink
interference
5.4 Handover Problem Checklist
This checklist is provided for reference only, and does not include all the conditions
that may cause handover failures. However, it includes common handover failure
causes.
Table 5-1 Handover Problem Checklist
Exception
No. Category Sub-Category Item Description
Handling
Check alarms in
Check whether
accordance with
the source and
Check the network
target
whether the management
eNodeBs have
target system or LTE
standing wave
eNodeB Product
eNodeB ratio alarms
1 operates Common Alarm
alarms and board
properly Handling
alarms,
through the Guide_R1.0.
including the
OMC alarm After the alarms
current alarms
module. are cleared,
and historical
perform service
alarms.
tests.
Check
Check whether
Hardware whether the
the RRU
Cell target cell
2 power output Diagnosis test.
hardware has
of the target
hardware
cell is proper.
faults.
Based on
performance
statistics, check
Check whether
whether MSG1 is
MSG1 and
proper. There are
3 MSG3 of the
lots of MSG1
target cell are
detection
proper.
success records.
The number of
times that the
Exception
Handling
eNodeB sends
MSG2 is nearly
0, the maximum
throughput on
the
downlink/uplink
PDCP layer is
nearly 0, and the
number of MSG1
detection
success records
is over 3000
times of the
number of times
that the eNodeB
sends MSG2.
Check whether
MSG3 is proper.
There are
thousands of
MSG1 detection
success records
and MSG2
transmissions,
the number of
MSG3 detection
success records
is nearly 0, the
maximum
throughput on
the
downlink/uplink
PDCP layer is
nearly 0, and the
number of MSG2
detection
success records
is over 3000
times of the
Exception
Handling
number of MSG3
detection
success records.
Check the
transmission Check whether
quality of the packet loss or IP channel check
Transmission
source a large delay in the diagnosis
quality
eNodeB and occurs during test.
target transmission.
eNodeB.
Check whether Check the

PRACH number of
resource preambles per
4
congestion second in
occurs on the performance
target cell. statistics.
Check the
performance
statistics. If there
is high usage,
check whether
Check whether the CFI
Check the
PDCCH parameter is
congestion
5 Resource Cell congestion dynamically
condition of
load congestion occurs on the adjusted, and
the target
target cell. check whether
cell.
congestion
occurs on the
cell based on
other
parameters.

the number of performance
RRC statistics. It is
6 connections of related to the
the target cell maximum
exceeds the number of RRC
threshold. connections
Exception
Handling
allowed for the

cell in the AC,
which is
specified by the
license.
Check the
performance
statistics. If the
PRB usage is
high, and the
traffic is heavy, it
indicates
congestion
occurs on the
cell. Increase the
Check the
difficulty of
7 PRB usage of
handover to the
the target cell.
cell and reduce
the difficulty of
handover from
the cell by
adjusting
handover
parameters, and
adjust heavy
traffic prevention
parameters.
Check the
performance
statistics.
Determine
Check the
whether
8 throughput of
congestion
the target cell.
occurs based on
the PRB usage
and number of
users.
9 Check the Check the
Exception
Handling
number of performance
activated statistics.
users.
Improper TAC
setting of the
neighbor cell
may cause
Check TAC access failure.
10 setting on the Check whether
target cell. the TAC setting
is proper
compared with
surrounding
sites.
Improper PLMN
setting may
cause access
Check PLMN
failure. The
Check settings
11 PLMN on the
handover involving the
core network
Radio parameters target cell.
Parameters side must be the
parameters on the source
same as that on
cell and
the target cell.
target cell.
If inter-frequency
Check whether
measurements
the threshold
are started late,
for starting
12 the signal quality
inter-frequency
of the source cell
measurements
may be very poor
is proper.
before handover.
Inter-frequency
Check whether measurement
the configuration is
inter-frequency used in intra-LTE
13
measurement redirection and
configuration ANR. If the
is proper. configuration is
improper,
Exception
Handling
inter-frequency
measurement
errors may occur.
Check the
central
frequency,
bandwidth, and
frequency offset.
Handover
configuration is
Check whether used for
intra-frequency handover
and decision. Check
inter-frequency whether the
14 handover delay and offset
configurations parameters are
are proper proper, and
(configuration whether the
IDs 50 and 70) handover event
and function are
correct.
For an
inter-OMMB
neighbor cell
relationship, if
Check the PCI of the
neighbor cell cell in OMMB A
parameters in is modified, the
Check the
neighbor cell PCI of the cell
neighbor cell
16 relationships under OMMB B
relationship
are the same and the PCI in
configuration.
as those in the the neighbor cell
existing relationship for
network. the cell under
OMMB A are not
changed and
need to be
manually
Exception
Handling
adjusted. In
addition, check
the TAC, PLMN,
and eNodeBID
parameters.

a neighbor cell neighbor cell
17 with the same relationship list,
frequency and and change the
PCI exists. conflicting PCI.
Check whether
there is any PCI
Check the PCI with a very short
18 multiplexing multiplexing
distance. distance based
on CDO or other
tools.
A PRACH
parameter
conflict increases
the probability of
Preamble
Check PCI detection failure.
PRACH PRACH
planning. parameters can

be bound with
Check whether
PCI. Check
PRACH
19 whether the
parameters
PRACH
are proper.
parameters of
the source and
target cells
conflict, and
whether the logic
root sequence,
NCS, and prach
configuration
index
Exception
Handling
parameters of
the two cells are
the same.
Trace signaling
based on
front-end logs
and back-end
network
management
Check whether system data.
Check the the Check whether
control-plane control-plane timer timeout is
20
and UE and UE timers caused by the S1
timers. are properly or X2 delay.
set. Check
rrcReCfgTimer
and T304
settings, and
adjust the
settings if
necessary.
Optimize
parameters
including CIO to
accelerate
Check whether
handover at
21 there is a
corners, to avoid
corner.
handover failure
Check
due to abrupt
Radio coverage
Coverage signal
environment problems of
deterioration.
outdoor sites.
Improve
coverage by
Check whether adjusting power
22 there is poor and the antenna
coverage. downtilt angle,
and increasing
sites.
Exception
Handling
Improve the
coverage
condition by
adjusting the
power and
antenna downtilt
angle. For
inter-vendor
super-far
coverage
Check whether
(restricted by the
there is
23 time alignment
super-far
parameter of the
coverage.
other vendor),
you can adjust
the CIO of the
source cell for
the neighbor cell
of the other
vendor, and
disable ANR
self-deletion for
the source cell.
Check whether
pilot pollution Adjust the power
24 causes and antenna
frequent downtilt angle.
handovers.
Optimize indoor
coverage,
indoor-to-outdoor
Check whether CIO, and
Check indoor
there is indoor inter-frequency
25 distribution
distribution measurement
coverage.
signal leakage. parameters.
Reduce or avoid
handover of an
outdoor UE to an
Exception
Handling
indoor cell.
Uplink: Use a Shut down the

real-time site. Use a
statistics tool frequency
(UDT) to analysis tool for
collect clear frequency
26
interference testing, and
data, and positioning and
check whether clearing the
the RSSI is interference
Check
high. source.
external
Downlink:
interference
Interference Check whether Reduce inter-cell
in uplink and
there is interference
downlink
interference through proper
directions.
between cells, coverage
there are other optimization, and
27 UE downlink reduce UE
services downlink service
nearby, the interference by
RSRP is good, setting
and the SINR parameters
is not properly.
satisfactory.

LTE Handover Optimization

Uploaded by

Copyright:

Available Formats

LTE Handover Optimization

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 Optimization

Uploaded by

Copyright:

Available Formats

LTE Handover Optimization

2 INTRA-LTE HANDOVER PROCEDURES AND ANALYSIS ......................................... 19

3 HANDOVER PARAMETER SETTING INSTRUCTIONS ............................................... 32

4 HANDOVER PROBLEM ANALYSIS .............................................................................. 49

5 HANDOVER PROBLEM POSITIONING ........................................................................ 60

1.1 Necessity for Handover

Wireless communication has an important feature: mobility control. When a UE

1.2 Handover Procedure

1.3 Intra-LTE Handover Measurement Events

Mobility measurement events in the E-UTRAN system include the following:

The events are described as follows:

2. Event A3 is most commonly used, and is often used in intra/inter-frequency

Mn: neighbor cell measurement result, not including any offset

Ocn: cell-specific offset of the neighbor cell

Hys: lag between entering and leaving of the event

Ms: local cell measurement result, not including any offset

Ofs: frequency-specific offset of the serving frequency point (frequency point of

Ocs: cell-specific offset of the local cell

Off: event A3 offset, which needs to be configured on a higher layer

Figure 1-1 Event A3 Measurement Conditions

As shown in the above figure, Mn strength is raising, and Ms strength is

Leaving condition for event A4: Mn+Ofn+Ocn+Hys<Thresh

Entering condition for event A5: Ms  Hys  Thresh1 and

Leaving condition for event A5: Ms  Hys  Thresh1 and

1.4 Handover Classification

 Tips: Handover in LTE

Handovers in LTE are hard handovers.

Intra-LTE handovers can be classified from various aspects.

Depending on whether the system is changed, intra-LTE handovers can be classified

Depending on whether the eNodeB is changed, intra-LTE handovers can be

Depending on whether the frequency is changed, intra-LTE handovers can be

Figure 1-2 LTE Handover Classification

1.4.1 Intra-Site Handover

The following figure shows the procedure.

1.4.2 S1-Based Inter-Site Handover

Data link layer

Figure 1-5 S1 User-Plane Protocol Stack

User plane PDUs

Data link layer

The following figures show S1-based handover (S1 handover).

Figure 1-7 S1-Based Handover (b): After Handover

As shown in the above figures, S1-based inter-eNodeB handover (S1 handover)

5. Data forwarding from the source eNodeB to the target eNodeB

The following figure shows the S1 handover procedure.

Figure 1-8 S1-Based Handover Procedure

UE eNB1 eNB2 MME

6 RRC connection Reconfiguration

11 RRC connection Reconfiguration Complete

13 UE context release Cmd

14 UE context release Complete

 Tips: S1-Based Handover Procedure

A normal S1-based handover procedure includes the following phases:

 Handover preparation phase: steps 1–5 in the above figure

 Handover completion phase: steps 12–14 in the above figure

The S1 handover procedure is described as follows:

1. The UE in RRC connection state sends an MR to the eNodeB. If the

4. The target eNodeB sends a handover response containing UE admission

6. The source eNodeB retrieves RRC connection reconfiguration information from

9. The UE implements a random access to the target eNodeB.

10. The target eNodeB permits the access of the UE.