Wcdma kpi-analysis

W-Handover and Call Drop Problem Optimization Guide For internal use only
Product name Confidentiality level
WCDMA RNP For internal use only
Product version
Total 202 pages
3.3
W-Handover and Call Drop Problem
Optimization Guide
(For internal use only)
Prepared by Jiao Anqiang Date 2006-03-16
Reviewed by Xie Zhibin, Dong Yan, Hu
Wensu, Wan Liang, Yan Lin,
Ai Hua, Xu Zili, and Hua
Yunlong
Date
Reviewed by Wang Chungui Date
Approved by Date

Huawei Technologies Co., Ltd.
All Rights Reserved
Revision Records
Date Version Description Author
2005-02-01 2.0
Completing V2.0 W-Handover and Call Drop
Problems.
Cai Jianyong,
Zang Liang, and
Jiao Anqiang
2006-03-16 3.0
According to V3.0 guide requirements, reorganizing
and updating V2.0 guide, focusing more on operability
of on-site engineers. All traffic statistics is from RNC
V1.5. The update includes:
Updating flow chart for handover problem optimization
Moving part of call drop due to handover problem to
handover optimization part
Specifying operation-related part to be more applicable
to on-site engineers
Updating RNC traffic statistics indexes to V1.5
Integrating traffic statistics analysis to NASTAR of the
network performance analysis
Optimizing some cases, adding new cases, and
removing outdated cases and terms
Moving content about handover and call drop to the
appendix, and keeping operations related to them in the
body
Adding explanations to SRB&TRB and RL FAILURE.
Jiao Anqiang
2006-04-30
3.1
Adding HSDPA-related description HSDPA handover
DT/CQT flow, definitions of traffic statistics in
HSDPA handover, HSDPA handover problems.
Adding algorithms and flows of HSDPA handover.
Zhang Hao and
Li Zhen
2006-10-30
3.11
Adding V17-related handover description as below:
Changes in signaling flow for H2D HHO
Changes in triggering events of H2D and D2H
D2H handover in HSDPA based on traffic and timers
Wang Dekai

Date Version Description Author
Updating description of HSDPA serving cell and traffic
statistics of HSDPA-DCH handover
Adding call drop indexes in HSDPA DT/statistics
2007-08-09 3.2 Adding HSUPA-related description. Zhang Hao
2008-12-15
3.3
Adding MBMS-related description.
Yearly review
WangDekai /
Hu Wensu

Contents
2.1 Handover Performance Indexes 15
2.2 Call Drop Performance Indexes 18
3.1 DT/CQT Index Optimization Flow 19
3.1.1 SHO DT Index Optimization Flow 19
3.1.2 HHO CQT Flow 23
3.1.3 Inter-RAT Handover CQT Flow 26
3.1.4 DT/CQT Flow for HSDPA Handover 28
3.1.5 DT/CQT Flow for HSUPA Handover 31
3.1.6 SHO Ratio Optimization 31
3.1.7 MBMS Mobility Optimization 31
3.2 Traffic Statistics Analysis Flow 33
3.2.1 Analysis Flow for SHO Traffic Statistics 34
3.2.2 Analysis Flow of HHO Traffic statistics 35
3.2.3 Traffic Statistics Analysis Flow for Inter-RAT Handover 36
3.2.4 Traffic Statistics Analysis for HSDPA Handover 39
3.2.5 Traffic Statistics Analysis for HSUPA Handover 40
3.3 SHO Cost Optimization 42
4.1 Definition of Call Drop and Traffic Statistics Indexes 43
4.1.1 Definition of DT Call Drop 43
4.1.2 Descriptions of Traffic Statistics Indexes 43
4.2 DT/CQT Optimization Flow 44
4.2.1 Call Drop Cause Analysis 45
4.2.2 Frequently-adjusted Non-handover Algorithm Parameters 47
4.2.3 Judgment Tree for Call Drop Causes 48
4.3 Traffic Statistics Analysis Flow 49
4.3.1 Analyzing RNC CDR 50
4.3.2 Analyzing Causes to Call Drop 50
4.3.3 Check Cells 51
4.3.4 Further DT for Relocating Problems 51
4.4 Optimization Flow for Tracing Data 51
4.4.1 Obtaining Single Subscriber Tracing Message 52
4.4.2 Obtaining Information about Call Drop Point 53

4.4.3 Analyzing Call Drop due to SRB Reset 53
4.4.4 Analyzing Call Drop due to TRB Reset 53
4.4.5 Analyzing Abnormal Call Drop 54
4.4.6 Performing CQT to Recheck Problems 54
4.5 Optimization Process for MBMS Call Drop 54
5.1 SHO Problems 56
5.1.1 Over High SHO Rate due to Improper SHO Relative Threshold 56
5.1.2 Delayed Handover due to Over Great Intra-frequency Filter Coefficient
57
5.1.3 Missing Neighbor Cell 58
5.1.4 Redundant Neighbor Cells 62
5.1.5 Pilot Pollution 65
5.1.6 Turning Corner Effect 71
5.1.7 Needlepoint Effect 74
5.1.8 Quick Change of Best server Signal 75
5.2 HHO Problems 77
5.2.1 Intra-frequency Ping-pong HHO due to Improperly Configured 1D
Event Hysteresis 77
5.2.2 Delayed Origination of Inter-frequency Measurement due to Improper
Inter-frequency Measurement Quantity 78
5.3 Inter-RAT Handover Problems 80
5.3.1 Ping-pong Reselection 80
5.3.2 PS Inter-RAT Ping-pong Handoff 81
5.3.3 Failure in handoff from 3G to the 2G network 82
5.3.4 Inter-RAT Handover Call Drop 84
5.4 Call Drop Problems 91
5.4.1 Over Weak Coverage 91
5.4.2 Uplink Interference 92
5.4.3 Abnormal Equipment 95
5.5 HSDPA-related Problems 97
5.5.1 HSDPA Handover Problems 97
5.5.2 HSDPA Call Drop 98
5.6 HSUPA Problems 100
7.1 SRB&TRB Reset 102
7.1.1 RAB 102
7.1.2 SRB 103
7.2 RL FAILURE 105
7.3 SHO Flow 110
7.3.1 Analyzing Signaling Flow for Adding Radio Link 110
7.3.2 Analyzing Signaling Flow for Deleting Radio Link 113
7.3.3 Analyzing Signaling Flow for Adding and Deleting Radio Link 114

7.3.4 SHO Algorithm 117
7.4 Ordinary HHO Flow 124
7.4.1 Ordinary HHO (lur Interface and CELL_DCH State) 124
7.4.2 Inter-CN HHO Flow 126
7.5 HHO Algorithm 129
7.5.1 Intra-frequency HHO Algorithm 129
7.5.2 Inter-frequency HHO Algorithm 129
7.6 Concept and Classification of HSDPA Handover 131
7.6.1 Concept of HSDPA Handover 131
7.6.2 Classification of HSDPA Handover 131
7.6.3 Signaling Flow and Message Analysis of HSDPA Handover 132
7.6.4 HS-PDSCH Serving Cell Update due to DPCH SHO 133
7.6.5 HS-PDSCH Serving Cell Update due to DPCH HHO 140
7.6.6 DPCH Intra-frequency HHO with HS-DSCH Serving Cell Update 141
7.6.7 DPCH Inter-frequency HHO with HS-DSCH Serving Cell Update 142
7.6.8 Handover Between HSDPA and R99 144
7.6.9 Handover between HSDPA and GPRS 153
7.6.10 Direct Retry of HSDPA 153
7.6.11 Switch of Channel Type 155
7.7 Concept and Classification of HSUPA Handover 158
7.7.1 Basic Concepts 158
7.7.2 Classification of HSUPA Handover 159
7.7.3 Signaling Flow and Message Analysis of HSUPA Handover 159
7.7.4 SHO from a HSUPA Cell to a Non-HSUPA Cell 165
7.7.5 SHO from a Non-HSUPA Cell to a HSUPA Cell 170
7.7.6 Handover Between a HSUPA Cell and a GSM/GPRS Cell 173
7.7.7 Direct Retry of HSUPA 173
7.7.8 Switch between Channel Types 175
7.8 Handover from WCDMA to GSM 176
7.9 Handover from GSM to WCDMA 180
7.10 Handover from WCDMA to GPRS 183
7.11 Handover from GRPS to WCDMA 187
7.12 Parameters of Handover from 3G to 2G Network 190
7.13 Data Configuration for Supporting Bi-directional Roaming and Handover
Between WCDMA and GSM/GPRS 193

SHO DT data analysis flow 20
Optimization flow for HHO CQT 25
Inter-RAT handover CQT flow 27
DT/CQT flow for HSDPA handover 30
Movement of the MBMS UE between PTM cells 31
Analysis flow for handover traffic statistics data 34
Voce inter-RAT outgoing handover flow 37
Flow chart for analyzing call drop 45
Judgment tree for call drop causes 48
Flow for analyzing call tracing 52
SHO relative threshold 57
Signaling flow recorded by UE before call drop 59
Scrambles recorded by UE active set and scanner before call drop 59
Scrambles in UE active set before call drop 60
UE intra-frequency measurement control point before call drop 61
Analyzing signaling of UE intra-frequency measurement control before call drop
61
Confirming missing neighbor cell without information from scanner 62
Location relationship of 2G redundant neighbor cells 64
Pilot pollution near Yuxing Rd. 65
Best ServiceCell near Yuxing Rd. 65
The 2nd best ServiceCell near Yuxing Rd. 66
The 3rd best ServiceCell near Yuxing Rd. 66
The 4th best ServiceCell near Yuxing Rd. 67
Composition of pilot pollution near Yuxing Rd. 67
RSSI near Yuxing Rd. 68
RSCP of Best ServiceCell near Yuxing Rd. 68
RSCP of SC270 cell near Yuxing Rd. 69
Pilot pollution near Yuxing Rd. after optimization 70
Best ServiceCell near Yuxing Rd. after optimization 70
RSCP of best ServiceCell near Yuxing Rd. after optimization 71

RSCP of SC270 cell near Yuxing Rd. after optimization 71
Turning corner effect-signals attenuation 72
Turning corner effect-signal attenuation recorded by the UE 72
Turning corner effect-traced signaling recorded by the RNC 73
Needle point-signal variance 74
Call drop distribution of PS384K intra-frequency hard handover 75
Signal distribution of cell152 vs. cell88 (signal fluctuation in handover areas) 76
Reporting 1D event 77
Increasing hysteresis to reduce frequently reporting of 1D event 78
Attenuation relationship of RSCP and Ec/No 79
Indoor 3G RSCP distribution 83
Analyzing weak signals 91
Uplink interference according to RNC signaling 93
Uplink interference according to UE signaling 93
Uplink interference information recorded by UE 94
RTWP variation of the cell 89767 94
RTWP variation of the cell 89768 95
Pilot information recorded by scanner 97
UMTS QoS structure 103
SRB and TRB at user panel 103
Signaling flow for adding radio link 111
Signaling flow for deleting radio link 113
SHO signaling flow for adding and deleting radio link 115
Measurement model 117
Example 1A event and trigger delay 119
Periodic report triggered by 1A event 120
Example of 1C event 121
Example 1D event 122
Restriction from hysteresis to measurement report 122
Example of 1E event 123
Example of 1F event 123

Ordinary HHO flow (lur interface and CELL_DCH state) 125
Ordinary inter-CN HHO flow 127
Intra-NodeB synchronization serving cell update 134
Inter-NodeB synchronization serving cell update 136
Inter-NodeB HS-DSCH cell update after radio link is added 138
Inter-NodeB HS-DSCH cell update during HHO (single step method) 140
DPCH intra-frequency HHO with HS-DSCH serving cell update 142
DPCH inter-frequency HHO with HS-DSCH serving cell update 143
handover from HSDPA to R99 144
Intra-frequency handover from R99 to R5 144
DPCH SHO with handover from HSDPA to R99 (inter-NodeB) 146
DPCH SHO with handover from R99 to HSDPA 147
Inter-NodeB SHO with handover from HSDPA to R99 (V17) 148
Intra-frequency HHO with handover from R5 to R99 149
Intra-frequency HHO with handover form R99 to R5 149
Intra-frequency HHO with handover from R5 to R99 (V17) 150
Inter-frequency HHO from HS-PDSCH to DCH 151
Inter-frequency HHO from DCH to HS-PDSCH 152
Handover between HSDPA and GPRS 153
Flow for direct retry during setup of a service 154
Direct retry triggered by traffic 154
Switch of channel type 156
Intra-frequency SHO between two HSUPA cells 160
Signaling for HSUPA cell update triggered by a 1D event 160
Signaling for HSUPA cell update triggered by a 1D event (reported by the
monitor set) 161
Intra-frequency HHO between two HSUPA cells 161
Signaling for intra-frequency HHO between two HSUPA cells 162
Inter-frequency HHO between two HSUPA cells 162
Signaling for inter-frequency HHO between two HSUPA cells 163
Inter-RNC HSUPA handover 164

SHO from a HSUPA cell to a non-HSUPA cell 166
Addition of an R99 cell when the service is on the E-DCH 167
Intra-frequency HHO from a HSUPA cell to a non-HSUPA cell 168
Signaling for intra-frequency HHO from a HSUPA cell to a non-HSUPA cell 168
Inter-frequency HHO from a HSUPA cell to a non-HSUPA cell 169
Signaling for inter-frequency HHO from a HSUPA cell to a non-HSUPA cell 170
SHO from a non-HSUPA cell to a HSUPA cell 171
SHO from a non-HSUPA cell to a HSUPA cell (triggered by a 1B event) 171
Intra-frequency HHO from a non-HSUPA cell to a HSUPA cell 172
Signaling for intra-frequency HHO from a non-HSUPA cell to a HSUPA cell 172
Inter-frequency HHO from a non-HSUPA cell to a HSUPA cell 173
Direct retry from an R99 cell to a HSUPA cell 174
Direct retry from a HSUPA cell to an R99 cell 174
Direct retry from a HSUPA cell to another HSUPA cell 175
Switch between HSUPA channel types 175
Signaling flow for handover from WCDMA to GSM 177
Tracing signaling of handover from WCDMA to GSM 177
Signaling flow for handover from GSM to WCDMA 180
Tracing signaling of handover from GSM to WCDMA 181
Flow of handover from WCDMA to GPRS (1) 184
Flow of handover from WCDMA to GPRS (2) 184
Tracing signaling of handover from WCDMA to GPRS 185
Signaling flow for handover from GPRS to WCDMA (1) 187
Signaling flow for handover from GPRS to WCDMA (2) 188
Data configuration in the location area cell table 194
Data configuration of neighbor cell configuration table 195
Configuration table for external 3G cells 197
Configuration table for GSM inter-RAT neighbor cells 198
Configuration table for 2G reselection parameters 199
Parameter configuration table for inter-RAT handover 200

Tables
Handover performance indexes and reference values 15
HSDPA handover performance indexes and reference value 16
HSUPA handover performance indexes and reference value 16
CDR index and reference value 18
SHO failure indexes 35
HHO failure indexes 35
Traffic statistics indexes of CS inter-RAT handover preparation failure 37
Traffic statistics indexes of PS inter-RAT outgoing handover failure 38
Types of CDR indexes 44
Thresholds of EcIo and Ec 45
Traffic statistics indexes for analyzing causes to call drop 50
Relationship between the filter coefficient and the corresponding tracing time 58
2G handover times 63
Best servers and other cells 67
Timers and counters related to the synchronization and asynchronization 105
Timers and counters related to call drop at lub interface 108
Flow of serving cell update triggered by different events in SHO 133
Scenarios of handover between HSDPA and R99 (V17) 145
Handover between two HSUPA cells 159
Handover between a HSUPA cell and a non-HSUPA cell 164
Parameters of handover from 3G to 2G 191
W-Handover and Call Drop Problem Optimization Guide
Key words:

Handover, call drop, and optimization
Abstract:
This document, aiming at network optimization of handover success rate and call drop rate, details the
specific network operation flow. In addition, it analyzes common problems during network
optimization.
Acronyms and abbreviations:
Acronyms and
Abbreviations
Full Spelling
AMR Adaptive MultiRate
CHR Call History Record
CDR Call Drop Rate
DCCC Dynamic Channel Configuration Control
RAN Radio Access Network
RNP Radio Network Planning
SRB Signaling Radio Bearer
TRB Traffic Radio Bearer
SHO Soft Handover
HHO Hard Handover
PCH Physical Channel
CN Core Network
O&M Operation and maintenance
MNC Mobile Network Code

MCC Mobile Country Code
LAC Location Area Code
CIO Cell Independent Offset
HSUPA High Speed Uplink Packet Access
E-DCH Enhanced uplink Dedicated Channel
E-AGCH E-DCH Absolute Grant Channel
E-RGCH E-DCH Relative Grant Channel

1 Introduction
This document aims to meet the requirements by on-site engineers on solving handover and
call drop problems and making them qualified during network optimization. It describes the
methods for evaluating network handover and call drop performance, testing methods,
troubleshooting methods, and frequently asked questions (FAQs).
The appendix provides fundamental knowledge, principles, related parameters, and data
processing tools about handover and call drop. This document serves to network KPI
optimization and operation and maintenance (O&M) and helps engineers to locate and solve
handover and call drop problems.
The RRM algorithms and problem implementation in this document are based on V16 RNC.
If some RRM algorithms are based on V17 RNC, they will be highlighted. HSUPA is
introduced in V18 RNC, so the algorithms related to HSUPA are based on RNC V18. The
following sections are updated:
y Traffic Statistics Analysis for HSDPA Handover
y Handover Between HSDPA and R99
y Direct Retry of HSDPA
y Switch of Channel Type
Actually handover is closely relevant to call drop. Handover failure probably leads to call
drop. Therefore handover-caused call drop is arranged in handover success rate
optimization part. The CDR optimization includes all related to call drop except handover-
caused call drop.
This document does not include usage of related tools.
This document includes the following 12 chapters:
y 1Introduction
y 2Handover and Call Drop Performance Indexes
y 3Handover Index Optimization
y 4CDR Index Optimization
y 5FAQs Analysis
y 6Summary
y 7Appendix
The traffic statistics analysis is based on RNC V1.5 counter. It will be updated upon the
update of RNC counters.

2 Handover and Call Drop Performance Indexes
2.1 Handover Performance Indexes
According to RNA KPI baseline document, 2.1 lists the handover performance indexes and
reference values.
1. Handover
performance
indexes and
reference
values
Index Service
Statistics
method
Reference
value
SHO success
rate
CS&PS DT&Stat. 99%
Intra-frequency
HHO success
rate
Voice DT&Stat. 90%
VP DT&Stat. 85%
PS UL64K/DL
64K
DT&Stat. 85%
PS UL64K/DL
144K
DT&Stat. 80%
PS UL64K/DL
384K
DT&Stat. 75%
Inter-frequency Voice DT&Stat. 92%

HHO success
rate
VP DT&Stat. 90%
PS UL64K/DL
64K
DT&Stat. 90%
PS UL64K/DL
144K
DT&Stat. 87%
PS UL64K/DL
384K
DT&Stat. 85%
Inter-RAT
handover
success rate
Voice handover
out
DT&Stat. 95%
PS handover out DT&Stat. 92%
SHO ratio N/A DT 35%
SHO cost N/A Stat. 40%
2.1 lists the HSDPA handover performance indexes and reference value.
2. HSDPA
handover
performance
indexes and
reference value
Index Service
Reference
value
HSDPA-HSDPA intra-
frequency serving cell update
PS (HSDPA) 99%
HSDPA-HSDPA inter-
frequency serving cell update
PS (HSDPA) 92%

Index Service
Reference
value
HSDPA-R99 intra-frequency
handover
PS (HSDPA) 99%
HSDPA-R99 inter-frequency
handover
PS (HSDPA) 90%
Success rate of R99-to-HSDPA
cell handover
PS (HSDPA) 85%
HSDPA-to-GPRS inter-RAT
handover
PS (HSDPA) 92%
Note: The HSDPA handover KPIs are to be updated after formal issue by WCDMA&GSM Performance
Research Department.
3. HSUPA
handover
performance
indexes and
reference value
Index Service
Reference
value
Success rate of inter-cell
SHO in HSUPA (including
adding, replacing, and
deleting)
PS (HSUPA) ±
SHO serving cell update
in HSUPA
PS (HSUPA)
±
Success rate of DCH-to-
E-DCH reconfiguration in
SHO mode (including
replacing and deleting)
PS (HSUPA)
±

Index Service
Reference
value
Success rate of E-DCH-
to-DCH reconfiguration in
SHO mode (including
replacing and deleting)
PS(HSUPA)
±
intra-frequency HHO in
HSUPA
PS (HSUPA)
±
Success rate of intra-
frequency HHO from a
HSUPA cell to a non-
HSUPA cell
PS (HSUPA)
±
Success rate of DCH-to-
E-DCH reconfiguration in
single-link mode (the
second step of inter- or
intra-frequency HHO from
a non-HSUPA cell to a
HSUPA cell)
PS (HSUPA)
±
inter-frequency HHO in
HSUPA
PS (HSUPA)
±
Success rate of inter-
frequency HHO from a
HSUPA cell to a non-
HSUPA cell
PS (HSUPA)
±
Success rate of HSUPA-
to-GPRS inter-RAT
handover
PS (HSUPA) 92%
Note:
The HSUPA handover KPIs are unavailable and to be updated after formal issue by WCDMA&GSM
Performance Department.
Decide the specific value according to project requirements or contract requirements of commercial
network

2.2 Call Drop Performance Indexes
2.2 lists the CDR index and reference value.
4. CDR index and
reference value
Index Service
Statistics
method
Reference
value
CDR
Voice DT&Stat.&CQT 2%
VP DT&Stat.&CQT 2.5%
PS planned full
coverage rate
DT&CQT 3%
PS (UL DCH full
coverage rate/DL
HSDPA)
DT 3%
PS Stat. 10%
PS (UL HSUPA/DL
HSDPA)
DT 3%
The values listed in 2.2 are only for reference. Decide the specific value according to project
requirements or contract requirements of commercial network.
The call drop rate of HSDPA is not defined yet, so engineers use call drop
rate of PS temporarily.

3 Handover Index Optimization
3.1 DT/CQT Index Optimization Flow
DT and CQT are important to network evaluation and optimization. DT/CQT KPIs act as
standards for verifying networks. Overall DT helps to know entire coverage, to locate missing
neighbor cells, and to locate cross-cell coverage. HHO and inter-RAT handover are used in
coverage solutions for special scenarios, in while CQT is proper.
The following sections describe the DT/CQT index optimization flow in terms of SHO, HHO,
and inter-RAT handover.
3.1.1 SHO DT Index Optimization Flow
3.1.1 shows the SHO DT data analysis flow.

2. SHO DT data
analysis flow
Inputting Analysis Data
Perform DT. Collect DT data, related signaling tracing, RNC CHR, and RNC MML scripts.
Obtaining When and Where the Problem
Occurs
During the test, SHO-caused call drop might occur or SHO might fail, so record the location
and time for the problem occurrence. This prepares for further location and analysis.

Missing Neighbor Cell
During the early optimization, call drop is usually due to missing neighbor cell. For intra-
frequency neighbor cells, use the following methods to confirm intra-frequency missing
neighbor cell.
y Check the active set Ec/Io recorded by UE before call drop and Best
Server Ec/Io recorded by Scanner. Check whether the Best Server
scramble recorded by Scanner is in the neighbor cell list of intra-
frequency measurement control before call drop. The cause might be
intra-frequency missing neighbor cell if all the following conditions
are met:
y The Ec/Io recorded by UE is bad.
y The Best Server Ec/Io is good.
y No Best Server scramble is in the neighbor cell list of measurement control.
y If the UE reconnects to the network immediately after call drop and
the scramble of the cell that UE camps on is different from that upon
call drop, missing neighbor cell is probable. Confirm it by
measurement control (search the messages back from call drop for
the latest intra-frequency measurement control message. Check the
neighbor cell list of this measurement control message)
y UEs might report detected set information. If corresponding
scramble information is in the monitor set before call drop, the cause
must be missing neighbor cell.
Missing neighbor cell causes call drop. Redundant neighbor cells impacts network
performance and increases the consumption of UE intra-frequency measurement. If this
problem becomes more serious, the necessary cells cannot be listed. Therefore pay
attention to redundant neighbor cells when analyzing handover problems. For redundant
neighbor cells, see 5.
Pilot Pollution
Pilot pollution is defined as below:
y Excessive strong pilots exist at a point, but no one is strong enough
to be primary pilot.
According to the definition, when setting rules for judging pilot pollution, confirm the following
content:
y Definition of strong pilot
Whether a pilot is strong depends on the absolute strength of the
pilot, which is measured by RSCP. If the pilot RSCP is greater than a
threshold, the pilot is a strong pilot. Namely,
.
y Definition of "excessive"
When judging whether excessive pilots exist at a point, the pilot

number is the judgment criteria. If the pilot number is more than a
threshold, the pilots at a point are excessive. Namely,
y Definition of "no best server strong enough"
When judging whether a best server strong enough exist, the
judgment criteria is the relative strength of multiple pilots. If the
strength different of the strongest pilot and the No. strong
pilot is smaller than a threshold, no best server strong enough exists
in the point. Namely,
y
Based on previous descriptions, pilot pollution exists if all the following conditions are met:
y The number of pilots satisfying is more
than .
y
Set , , and , the judgment
standards for pilot pollution are:
y The number of pilots satisfying is larger
than 3.
y
Improper Configuration of SHO Algorithm
Parameters
Solve the following two problems by adjusting handover algorithm parameters.
y Delayed handover
According to the signaling flow for CS services, the UE fails to receive active set update
command (physical channel reconfiguration command for intra-frequency HHO) due to
the following cause. After UE reports measurement message, the Ec/Io of original cell
signals decreases sharply. When the RNC sends active set update message, the UE
powers off the transmitter due to asynchronization. The UE cannot receive active set
update message. For PS services, the UE might also fail to receive active set update
message or perform TRB reset before handover.
Delayed handover might be one of the following:
y Turning corner effect: the Ec/Io of original cell decreases sharply and that of the target cell
increases greatly (an over high value appears)
y Needlepoint effect: The Ec/Io of original cell decreases sharply before it increases and the
Ec/Io of target cell increase sharply for a short time.
According to the signaling flow, the UE reports the 1a or 1c measurement report of
neighbor cells before call drop. After this the RNC receives the event and sends the active
set update message, which the UE fails to receive.

y Ping-pong Handover
Ping-pong handover includes the following two forms
y The best server changes frequently. Two or more cells alternate to be the best server. The
RSCP of the best server is strong. The period for each cell to be the best server is short.
y No primary pilot cell exists. Multiple cells exist with little difference of abnormal RSCP. The
Ec/Io for each cell is bad.
According to the signaling flow, when a cell is deleted, the 1A event is immediately
reported. Consequently the UE fails because it cannot receive the active set update
command.
Abnormal Equipment
Check the alarm console for abnormal alarms. Meanwhile analyze traced message, locate
the SHO problem by checking the failure message. For help, contact local customer service
engineers for confirm abnormal equipment.
Reperforming Drive Test and Locating
Problems
If the problem is not due to previous causes, perform DT again and collect DT data.
Supplement data from problem analysis.
Adjustment and Implementation
After confirming the cause to the problem, adjust the network by using the following pertinent
methods:
y For handover problems caused by pilot pollution, adjust engineering
parameters of an antenna so that a best server forms around the
antenna. For handover problems caused by pilot pollution, adjust
engineering parameters of other antennas so that signals from other
antennas becomes weaker and the number of pilots drops. Construct
a new site to cover this area if conditions permit. If the interference
is from two sectors of the same NodeB, combine the two cells as
one.
y For abnormal equipment, consult customer service engineer for
abnormal equipment and transport layer on alarm console. If alarms
are present on alarm console, cooperate with customer service
engineers.
y For call drop caused by delayed handover, adjust antennas to expand
the handover area, set the handover parameters of 1a event, or
increase CIO to enable handover to occur in advance. The sum of
CIO and measured value is used in event evaluation process. The
sum of initially measured value and CIP, as measurement result, is
used to judge intra-frequency handover of UE and acts as cell border
in handover algorithm. The larger the parameter is, the easier the

SHO is and UEs in SHO state increases, which consumes resources.
If the parameter is small, the SHO is more difficult, which might
affects receiving quality.
y For needle effect or turning corner effect, setting CIO to 5 dB is
proper, but this increases handover ratio. For detailed adjustment, see
SHO-caused call drop of FAQs Analysis.
y For call drop caused by Ping-pong handover, adjust the antenna to
form a best server or reduce Ping-pong handover by setting the
handover parameter of 1B event, which enables deleting a cell in
active set to be more difficult. For details, increase the 1B event
threshold, 1B hysteresis, and 1B delay trigger time.
3.1.2 HHO CQT Flow
HHO Types
HHO includes the following types:
y Intra-frequency HHO
The frequency of the active set cell before HHO is the same as that of the cell after HHO.
If the cell does not support SHO, HHO might occur. HHO caters for cross-RNC intra-
frequency handover without lur interface, limited resources at lur interface, and handover
controlled by PS service rate threshold of handover cell. The 1D event of intra-frequency
measurement events determines intra-frequency HHO.
y Inter-frequency HHO
The frequency of the active set cell before HHO is different from that of the cell after
HHO. HHO helps to carry out balanced load between carriers and seamless proceeding.
Start compression mode to perform inter-frequency measurement according to UE
capability before inter-frequency HHO. HHO judgment for selecting cell depends on
period measurement report.
y Balanced load HHO
It aims to realize balanced load of different frequencies. Its judgment depends on
balanced load HHO.
Inter-frequency coverage usually exists in special scenarios, such as indoor coverage, so
CQT are used. The following section details the optimization flow for inter-frequency CQT.
Optimization Flow of HHO CQT
3.1.2 shows the optimization flow for HHO CQT.

1. Optimization flow for
HHO CQT
Adjustment
The optimization flow for HHO is similar with that of SHO and the difference lies in parameter
optimization.
Confirming inter-frequency missing neighbor cell is similar to that of intra-frequency. When
call drop occurs, the UE does not measure or report inter-frequency neighbor cells. After call
drop, the UE re-camps on the inter-frequency neighbor cell.
HHO problems usually refer to delayed handover and Ping-pong handover.
Delayed HHO usually occurs outdoor, so call drop occurs when the UE is moving. There are
three solutions:
y Increase the threshold for starting compression mode.
The compression mode starts before inter-frequency or inter-RAT handover. Measure the
quality of inter-frequency or inter-RAT cell by compression mode. Compression mode
starts if the CPICH RSCP or Ec/Io meets the conditions. RSCP is usually the triggering
condition.
The parameter "inter-frequency measurement quantity" decides to use CPICH Ec/No or
Ec/Io as the measurement target for inter-frequency handover. When setting "inter-
frequency measurement quantity", check that the cell is at the carrier coverage edge or in
the carrier coverage center. If intra-frequency neighbor cells lie in all direction of the cell,
the cell is defined as in the carrier coverage center. If no intra-frequency cell lies in a

direction of the cell, the cell is defined as at the carrier coverage edge.
In the cell at the carrier coverage edge, when UE moves along the direction where no
intra-frequency neighbor cell lies, the CPICH Ec/No changes slowly due to the identical
attenuation rate of CPICH RSCP and interference. According to simulation, when CPICH
RSCP is smaller than the demodulation threshold (±100 dBm or so), the CPICH Ec/No
can still reach ±12 dB or so. Now the inter-frequency handover algorithm based on
CPICH Ec/No is invalid. Therefore, for the cell at the carrier coverage edge, using CPICH
RSCP as inter-frequency measurement quantity to guarantee coverage is more proper.
In the cell in the carrier coverage center, use CPICH RSCP as inter-frequency
measurement quantity, but CPICH Ec/No can better reflect the actual communication
quality of links and cell load. Therefore use CPICH Ec/No as inter-frequency
measurement quantity in the carrier coverage center (not the cell at the carrier coverage
edge), and RSCP as inter-frequency measurement quantity in the cell at the carrier
coverage edge.
In compression mode, the quality of target cell (inter-frequency or inter-RAT) is usually
measured and obtained. The mobility of MS leads to quality deterioration of the current
cell. Therefore the requirements on starting threshold are: before call drop due to the
quality deterioration of the current cell, the signals of the target cell must be measured
and reporting is complete. The stopping threshold must help to prevent compression mode
from starting and stopping frequently.
The RNC can distinguish CS services from PS services for inter-frequency measurement.
If the RSCP is smaller than ±95 dBm, compression mode starts. If the RSCP is greater
than ±90 dBm, compression mode stops. Adjust RSCP accordingly for special scenarios.
y Increase the CIO of two inter-frequency cells.
y Decrease the target frequency handover trigger threshold of inter-
frequency coverage.
For Ping-pong HHO problems, solve them by increasing HHO hysteresis and delay trigger
time.
The intra-frequency HHO optimization is similar to that of inter-frequency. Decrease the
hysteresis and delay trigger time of 1D event according to local radio environment to
guarantee timely handover.
3.1.3 Inter-RAT Handover CQT Flow
Flow Chat
3.1.3 shows the inter-RAT handover CQT flow.

1. Inter-RAT handover
CQT flow
Data Configuration
Inter-RAT handover fails due to incomplete configuration data, so pay attention to the
following data configuration.
y GSM neighbor configuration is complete on RNC. The configuration
includes:
y Mobile country code (MCC)
y Mobile network code (MNC)
y Location area code (LAC)
y GSM cell identity (CELL ID)
y Network color code (NCC)
y Base station color code (BCC)
y Frequency band indicator (FREQ_BAND)
y Frequency number
y Cell independent offset (CIO)
Guarantee the correctness of the previous data and GSM network.

y Add location area cell information near 2G MSC to location area cell
list of 3G MSC. The format of location area identity (LAI) is MCC +
MNC + LAC. Select LAI as LAI type. Select Near VLR area as LAI
class and add the corresponding 2G MSC/VLR number. The cell
GCI format is: MCC + MNC + LAC + CI. Select GCI as LAI type.
Select Near VLR area as LAI class and add the corresponding 2G
MSC/VLR number.
y Add data of WCDMA neighbor cells on GSM BSS. The data
includes:
y Downlink frequency
y Primary scramble
y Main indicator
y MCC
y MISSING NEIGHBOR CELL
y LAC
y RNC ID
y CELL ID
According to the strategies of unilateral handover of inter-RAT handover, if the data
configuration is complete, the inter-RAT handover problems are due to delayed handover. A
frequently-used solution is increasing CIO, increasing the threshold for starting and stopping
compression mode, increasing the threshold to hand over to GSM.
Causes
The causes to call drop due to 3G-2G inter-RAT handover are as below:
y After the 2G network modifies its configuration data, it does not
inform the 3G network of modification, so the data configured in two
networks are inconsistent.
y Missing neighbor cell causes call drop.
y The signals fluctuate frequently so call drop occurs.
y Handset problems causes call drop. For example, the UE fails to
hand over back or to report inter-RAT measurement report.
y The best cell changes upon Physical channel reconfiguration.
y Excessive inter-RAT cell are configured (solve it by optimizing
number of neighbor cells).
y Improperly configured LAC causes call drop (solve it by checking
data configuration).
3.1.4 DT/CQT Flow for HSDPA Handover

Type
According to the difference of handover on DPCH in HSDPA network, the HSDPA handover
includes:
y SHO or softer handover of DPCH, with HS-PDSCH serving cell
update
y Intra-frequency and inter-frequency HHO of DPCH, with HS-
PDSCH serving cell update
According to different technologies used in the serving cell before and after handover,
HSDPA handover includes:
y Handover in HSDPA system
y Handover between HSDPA and R99 cells
y Handover between HSDPA and GPRS cells
Methods
For HSDPA service coverage test and mobility-related test (such as HHO on DPCH with HS-
PDSCH serving cell update, handover between HSDPA and R99, and inter-RAT handover),
perform DT to know the network conditions.
For location of HSDPA problems and non-mobility problems, perform CQT (in specified point
or small area).
Flow
When a problem occurs, check R99 network. If there is similar problem with R99 network,
solve it (or, check whether the R99 network causes HSDPA service problems, such as weak
coverage, missing neighbor cell. Simplify the flow).
3.1.4 shows the DT/CQT flow for HSDPA handover.

1. DT/CQT flow for
HSDPA handover
The problems with handover of HSDPA subscribers are usually caused by the faulty
handover of R99 network, such as missing neighbor cell and improper configuration of
handover parameters. When the R99 network is normal, if the handover of HSDPA
subscribers is still faulty, the cause might be improper configuration of HSDPA parameters.
Engineers can check the following aspects:
y Whether the HSDPA function of target cell is enabled and the
parameters are correctly configured. Engineers mainly check the
words of cell and whether the power is adequate, whether the HS-
SCCH power is low. These parameters might not directly cause call
drop in handover, but lead to abnormal handover and lowered the
user experience.
y Whether the protection time length of HSDPA handover is proper.
Now the baseline value is 0s. Set it by running SET HOCOMM.
y Whether the threshold for R99 handover is proper. The handover
flow for HSDPA is greatly different from that of R99, so the
handover of R99 service may succeed while the HSDPA handover

may fail. For example, in H2D handover, when the UE reports 1b
event, it triggers RB reconfiguration in the original cell, reconfigures
service bearer to DCH, and updates the cell in active set. If the
signals of the original cell deteriorate quickly now, the
reconfiguration fails.
y Whether the protection time length of D2H handover is proper. Now
the baseline value is 2s. Set it by running SET HOCOMM.
3.1.5 DT/CQT Flow for HSUPA Handover
The DT/CQT flow for HSUPA handover is similar to that for HSDPA. For details, refer to
DT/CQT Flow for HSDPA Handover.
For the test of HSUPA service coverage and mobility-related tests (such as the test of
success rate of HSUPA serving cell update), perform DT to know the network conditions. For
locating HSUPA problems and the problems unrelated to mobility, perform CQT (in specified
spot or area).
3.1.6 SHO Ratio Optimization
This part is to be supplemented.
3.1.7 MBMS Mobility Optimization
Currently, the radio network controller (RNC) V18 supports only the broadcast mode of the
multimedia broadcast multicast service (MBMS); the MBMS user equipment (UE) moves
only between point-to-multipoint (PTM) cells.

2. Movement of the
MBMS UE between
PTM cells
The movement of the MBMS UE between PTM cells is similar to the movement of UE
performing PS services in the CELL-FACH state. The UE performs the handover between
cells through cell reselection and obtains a gain through soft combining or selective
combining between two cells to guarantee the receive quality of the service. The UE first
moves to the target cell and then sends a CELL UPDATE message to notify the serving
radio network controller (SRNC) that the cell where the UE stays is changed. The SRNC
returns a CELL UPDATE CONFIRM message. The UE receives an MBMS control message
from the MCCH in the target cell and determines whether the MBMS radio bearer to be
established is consistent with that of the neighboring cell. If they are consistent, the original
radio bearer is retained. The MBMS mobility optimization, which guarantees that the UE
obtains better quality of service at the edge of cells, covers the following aspects:
y Optimize cell reselection parameters to guarantee that the UE can be
reselected to the best cell in time.
y Guarantee that the power of the FACH in each cell is large enough to
meet the coverage requirement of the MBMS UE at the edge of the
cells.

y Guarantee that the transmission time difference of the UE between
different links meets the requirement of soft combing or selective
combining*.
y Guarantee that the power, codes, transmission, and CE resources of
the target cell are not restricted or faulty, and that the MBMS service
is successfully established.
The UE can simultaneously receive the same MBMS service from two
PTM cells and combine the received MBMS service. The UE supports two
combining modes:
Soft combining: The transmission time difference between the current cell
and the neighboring cell is within (one TTI + 1) timeslots and the TFCI in
each transmission time interval (TTI) is the same.
Selective combining: The transmission time difference between the current
cell and the neighboring cell is within the reception time window stipulated
by the radio link controller (RLC). The SCCPCH is decoded and the
transmission blocks are combined in the RLC PDU phase

3.2 Traffic Statistics Analysis Flow
The traffic statistics data is important to network in terms of information source. In addition, it
is the major index to evaluate network performance.
The handover traffic statistics data is includes RNC-oriented data and cell-oriented data.
RNC ±oriented data reflects the handover performance of entire network, while cell-oriented
data helps to locate problematic cells.
The analysis flow for SHO, HHO, inter-RAT handover, and HSDPA handover is similar, but
the traffic statistics indexes are different from them.
3.2 shows the analysis flow for handover traffic statistics data.

3. Analysis flow for
handover traffic
statistics data
3.2.1 Analysis Flow for SHO Traffic Statistics
The SHO success rate is defined as below:
SHO success rate = SHO successful times/SHO times
According to the flow, SHO includes SHO preparation process and SHO air interface
process. The SHO preparation process is from handover judgment to RL setup completion.
The SHO air interface process is active set update process.
y Check the SHO success rate of entire network and cell in busy hour.
If they are not qualified, analyze the problematic cells in details.
y Sort the SHO (or softer handover) failure times of the cell by TOP N
and locate the cells with TOP N failure times. List the specific

indexes of failure causes. If locating specific causes from traffic
statistics is impossible, analyze the corresponding CHR.
3.2.1 lists the detailed traffic statistics indexes to SHO (or softer handover) failure and
analysis.
1. SHO failure
indexes
Failure causes Analysis
Configuration nonsupport
The UE thinks the content of active set update for RNC to add/delete links does not
support SHO. This scenario seldom exists in commercial networks.
Synchronization
reconfiguration nonsupport
The UE feeds back that the SHO (or softer handover) for RNC to add/delete links is
incompatible with other subsequent processes. The RNC guarantees serial
processing upon flow processing. This cause is due to the problematic UE.
Invalid configuration
The UE thinks the content of active set update for RNC to add/delete links is
invalid. This scenario seldom exists in commercial networks.
No response from UE
The RNC fails to receive response to active set update command for
adding/deleting links. This is a major cause to SHO (or softer handover) failure. It
occurs in areas with weak coverage and small handover area. RF optimization must
be performed in the areas.
y Perform DT to re-analyze problems. The traffic statistics data
provides the trend and possible problems. Further location and
analysis of problems involves DT and CHR to the cell. DT is usually
performed on problematic cells and signaling flow at the UE side
and of RNC is traced. For details, see 3.1.3.
3.2.2 Analysis Flow of HHO Traffic statistics
The HHO traffic statistics includes outgoing HHO success rate and incoming HHO success
rate:
y Outgoing HHO Success Rate = Outgoing HHO Success
Times/Outgoing HHO Times
y Incoming HHO Success Rate = Incoming HHO Success
Times/Incoming HHO Times
Upon HHO failure, pay attention to indexes related to internal NodeB, between NodeBs, and
between RNCs.
3.2.2 lists the HHO failure indexes.

2. HHO failure
indexes
Failure
cause
Analysis
HHO preparation failure
Radio link setup failure Analyze RL setup failure.
Other causes Analyze the problem further based on CHR logs.
Internal NodeB/Between NodeBs/Between RNCs HHO failure
Configuration
nonsupport
The UE thinks it cannot support the command for outgoing
HHO, because it is incompatible with HHO.
PCH failure The cause is probably weak coverage and strong interference.
Synchronization
reconfiguration
nonsupport
The UE feeds back HHO is incompatible with other consequent processes due to
compatibility problems of UE.
Cell update
Cell update occurs upon outgoing HHO. These two processes lead to outgoing HHO
failure.
Invalid configuration
The UE thinks the command for outgoing HHO as invalid. This is a compatibility
problem of UE.
Other causes Analyze the problem further based on CHR logs.
3.2.3 Traffic Statistics Analysis Flow for Inter-RAT Handover
The inter-RAT handover success rate includes voice inter-RAT handover success rate and
PS inter-RAT handover success rate.
Voice Inter-RAT Outgoing Handover Success Rate = Voice Inter-RAT Outgoing Handover
Success Times/Voice Inter-RAT Outgoing Handover Attempt Times
Voice Inter-RAT Outgoing Handover Success Times: when the RNC sends a RELOCATION
REQUIRED message.
Voice Inter-RAT Outgoing Handover Attempt Times: during CS inter-RAT outgoing, when the
RNC receives an IU RELEASE COMMAND message, with the reason value Successful
Relocation, or Normal Release.

PS Inter-RAT Outgoing Handover Success Rate = PS Inter-RAT Outgoing Handover
Success Times/PS Inter-RAT Outgoing Handover Implementation Times
PS Inter-RAT Outgoing Handover Success Times: the RNC sends a CELL CHANGE
ORDER FROM UTRAN message to UE.
PS Inter-RAT Outgoing Handover Implementation Times: when the RNC receives an IU
RELEASE COMMAND message, with the reason value Successful Relocation, or Normal
Release.
Voice Inter-RAT Outgoing Handover
Success Rate
The voice inter-RAT outgoing handover includes handover preparation process and
implementation process.
3.2.3 shows the voice inter-RAT outgoing handover flow.
1. Voce inter-RAT
outgoing handover
flow
During CS inter-RAT outgoing handover process, when the RNC sends a RELOCATION
REQUIRED message to CN, if the current CS service is AMR voice service, count it as an
inter-RAT handover preparation. When the RNC receives the IU RELEASE COMMAND
message replied by CN, count it as inter-RAT outgoing handover success according to the
SRNC cell being used by UE.
If CS inter-RAT handover fails, check the failure statistics indexes listed in 3.2.3.
1. Traffic
statistics
indexes of CS
inter-RAT
handover

preparation
failure
Failure
cause
Analysis
RNC-level inter-RAT outgoing handover preparation failure
Expiration of waiting
for SRNS relocation
command
The CN does not respond the corresponding command for handover
preparation request, because the CN parameter configuration or the
corresponding link connection is problematic. To solve this problem, analyze
the causes according to CN and BSS signaling tracing.
SRNS relocation
cancellation
After the RNC requests handover preparation, it receives the release command
from CN. This includes the following two cases:
y The inter-RAT handover request occurs during
signaling process like location update, so the flow is
not complete before location update is complete.
Finally the CN sends a release message.
y The subscribers that are calling hang UE before
handover preparation, so the CN sends a release
message.
The previous two cases, despite incomplete handover, are normal nesting
flows.
SRNS relocation
expiration
It corresponds to incorrect configuration of CN, so you must analyze the
causes according to CN and BSS signaling tracing.
SRNS relocation failure
in target
CN/RNC/system
It corresponds to incorrect configuration of CN or BSS nonsupport, so you
must analyze the causes according to CN and BSS signaling tracing.
Unknown target RNC
It corresponds to incorrect configuration of MSC parameters without
information like LAC of target cell, so you must check the parameter
configuration. It occurs easily after adjustment of 2G networks.
Unavailable resource
It corresponds to incorrect configuration of MSC parameters or unavailable
BSC resources, so you must analyze the causes according to CN and BSS
signaling tracing.
Other causes Analyze the causes according to CN and BSS signaling tracing.
Cell-level inter-RAT outgoing handover preparation failure
SRNS relocation
expiration
The CN parameter configuration or the corresponding link connection is
problematic, so you must analyze the causes according to CN and BSS

signaling tracing.
SRNS relocation failure
in target
CN/RNC/system
It corresponds to incorrect configuration of CN or BSS nonsupport, so you
must analyze the causes according to CN and BSS signaling tracing.
SRNS relocation
nonsupport in target
CN/RNC/system
The BSC fails to support some parameters of inter-RAT handover request, so
you must analyze the causes according to CN and BSS signaling tracing.
Other causes Analyze the causes according to CN and BSS signaling tracing.
RNC-level/CELL-level inter-RAT outgoing handover failure
Configuration
nonsupport
The UE fails to support the handover command in the network, so the UE is
incompatible with the handover command.
PCH failure
The 2G signals are weak or the interference is strong so the UE fails to connect
to the network.
Other causes
Analyze the problem further according to CHR logs and CN/BSS signaling
tracing.
PS Inter-RAT Handover Success Rate
After the RNC sends the CELL CHANGE ORDER FROM UTRAN message, the PS inter-
RAT outgoing handover fails if it receives the CELL CHANGE ORDER FROM UTRAN
FAILURE message. You must check the indexes listed in 3.2.3.
1. Traffic
statistics
indexes of PS
inter-RAT
outgoing
handover
failure
Failure
cause
Analysis
RNC-level/CELL-level PS inter-RAT outgoing handover preparation failure

Configuration
nonsupport
The UE fails to support the handover command of the network, because the
UE is incompatible with the command.
PCH failure
The 2G signals are weak or the interference is strong, so the UE fails to
access the network.
Radio network layer
cause
The UE is probably incompatible. The UE detects that the sequence number
of SNQ in the AUTN message is correct, so the handover fails. The value is
synchronization failure.
Transport layer cause The corresponding transport link is abnormal.
Other causes You must analyze the causes according to CN and BSS signaling tracing.
3.2.4 Traffic Statistics Analysis for HSDPA Handover
HSDPA switch includes
y H-H (HS-DSCH to HS-DSCH) intra-frequency serving cell update
y H-H inter-frequency serving cell update
y HSDPA-R99 intra-frequency switch
y HSDPA-R99 inter-frequency switch
y HSDPA-GPRS switch
The traffic statistics indexes are defined as below:
y Success rate of H-H intra-frequency serving cell update = (Times of
successful update of serving cell)/(attempt times update of serving
cell)
When the RNC sends UE the PHYSICAL CHANNEL RECONFIGURATION message,
if the serving cell is updated, engineers count the attempt times of serving cell in the
original serving cell. When the RNC receives the PHYSICAL CHANNEL RECFG
COMPLETE message, if the serving cell changes, the RNC counts the times of successful
update of serving cells in the original serving cell when the UE is in the SHO mode not in
the HHO mode.
y Success rate of H-H inter-frequency serving cell update = Times of
successful outgoing inter-frequency HHO from HS-DSCH to HS-
DSCH/Times of requested outgoing inter-frequency HHO from HS-
DSCH to HS-DSCH
When the RNC sends UE the PHYSICAL CHANNEL RECONFIGURATION message,
and the inter-frequency HHO is from HS-DSCH to HS-DSCH, the RNC counts the times
of requested outgoing inter-frequency HHO from HS-DSCH to HS-DSCH. When the
RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message from UE, and
the inter-frequency HHO is from HS-DSCH to HS-DSCH, engineers count the times of
successful outgoing inter-frequency HHO from HS-DSCH to HS-DSCH.

y Success rate of H-H inter-frequency serving cell update = successful
times of outgoing inter-frequency HHO from HS-DSCH to HS-
DSCH/attempt times HHO from DCH to HS-DSCH in the cell
When the RNC sends the UE the PHYSICAL CHANNEL RECONFIGURATION
message, if the switch is the inter-frequency HHO from HS-DSCH to HS-DSCH, the
RNC counts the successful times of inter-frequency HHO from HS-DSCH to HS-DSCH
in the cell.
y Success rate of H-to-R99 intra-frequency SHO = successful times of
switch from HS-DSCH to DCH in multi-link mode in the
cell/attempt times switch from HS-DSCH to DCH in multi-link
mode in the cell.
Success rate of R99-to-H intra-frequency SHO = successful times of
switch from DCH to HS-DSCH in multi-link mode in the
cell/attempt times switch from DCH to HS-DSCH in multi-link
mode in the cell.
In the DCCC or RAB MODIFY process, if the RNC decides to switch the channel in the
cell, it sends the UE the RF RECONFIGURATION message. According to the channel
state of the UE before and after reconfiguration, the RNC counts the previous indexes in
the HSDPA serving cell.
y Success rate of H-to-R99 intra-frequency HHO = successful times of
outgoing intra-frequency HHO from HS-DSCH to DCH in the
cell/attempt times outgoing intra-frequency HHO from HS-DSCH to
DCH in the cell.
message, if the switch is the intra-frequency switch from HS-DSCH to DCH, the RNC
counts the attempt times of inter-frequency HHO from HS-DSCH to DCH in the cell.
When the RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message
from the UE, if the switch is the intra-frequency HHO from HS-DSCH to DCH, the RNC
counts the successful times of outgoing intra-frequency HHO from HS-DSCH to DCH in
the cell.
Success rate of H-to-R99 inter-frequency switch update
The RNC algorithm is unavailable now, so this index is unavailable.
y Success rate of H-to-R99 inter-frequency switch update = successful
times of outgoing HHO from HS-DSCH to DCH in the cell/attempt
times outgoing inter-frequency HHO from HS-DSCH to DCH in the
cell
message, if the switch is the inter-frequency switch from HS-DSCH to DCH, the RNC
counts the attempt times inter-frequency HHO from HS-DSCH to DCH in the cell. When
the RNC receives the PHYSICAL CHANNEL RECFG COMPLETE message from the
UE, if the switch is the inter-frequency HHO from HS-DSCH to DCH, the RNC counts
the successful times of outgoing inter-frequency HHO from HS-DSCH to DCH in the
cell.
Success rate of R99-to-H
The RNC algorithm is unavailable now, so this index is unavailable.

y Success rate of R99-to-H switch = successful times of switch from
DCH to HS-DSCH in the cell/attempt times of switch from DCH to
HS-DSCH in the cell
In the DCCC or RAB MODIFY process, if the RNC decides to switch the channel in the
cell, it sends the UE the RF RECONFIGURATION message. According to the channel
state of the UE before and after reconfiguration, the RNC counts the attempt times of
switch from DCH to HS-DSCH in the HSDPA serving cell. In the DCCC or RAB
MODIFY process, if the RNC receives the RB RECONFIGURATION COMEPLTE
message from UE, and the reconfiguration enables UE to switch from the DCH to HS-
DSCH in the same cell, the RNC counts the successful times of switch from DCH to HS-
DSCH in the HSDPA serving cell.
y Success rate of H-to-GPRS handover update
The traffic statistics does not include the index, and the index will be supplemented later.
The causes to failure and analysis methods will be summarized later.
3.2.5 Traffic Statistics Analysis for HSUPA Handover
The traffic statistics indexes for HSUPA are defined as below:
y Success rate of SHO between HSUPA cells (including adding,
replacing, and deleting) = attempt times of active set
update/complete times of active set update.
y Success rate of SHO serving cell update between HSUPA cells =
successful times of SHO serving cell update/attempt times of SHO
serving cell update.
y Success rate of reconfiguration from DCH to E-DCH in the cell
(SHO, intra-frequency HHO, and inter-frequency HHO) = successful
times of handover from DCH to E-DCH/attempt times of handover
from DCH to E-DCH.
y Success rate of reconfiguration from E-DCH to DCH in the cell
(including adding and replacing) = successful times of handover
from E-DCH to DCH in SHO mode/attempt times of handover from
E-DCH to DCH in SHO mode.
y Success rate of intra-frequency HHO serving cell between HSUPA
cells = successful times of intra-frequency HHO serving cell
between HSUPA cells/attempt times of intra-frequency HHO serving
cell between HSUPA cells.
y Success rate of intra-frequency HHO from E-DCH to DCH from a
HSUPA cell to a non-HSUPA cell = successful times of intra-
frequency HHO from E-DCH to DCH/attempt times of intra-
frequency HHO from E-DCH to DCH.
y Success rate of inter-frequency HHO serving cell update between
HSUPA cells = successful times of inter-frequency HHO serving cell

update between HSUPA cells/attempt times of inter-frequency HHO
serving cell update between HSUPA cells.
y Successful times of inter-frequency HHO from a HSUPA cell to a
non-HSUPA cell = successful times of inter-frequency HHO from E-
DCH to DCH/request times of inter-frequency HHO from E-DCH to
DCH.

3.3 SHO Cost Optimization
To be supplemented.

4 CDR Index Optimization
4.1 Definition of Call Drop and Traffic Statistics Indexes
4.1.1 Definition of DT Call Drop
According to the air interface signaling recorded at the UE side, during connection, DT call
drop occurs when the UE receives:
y Any BCH message (system information)
y The RRC Release message with the release cause Not Normal.
y Any of the CC Disconnect, CC Release Complete, CC Release
message with the release cause Not Normal Clearing, Not Normal, or
Unspecified.
4.1.2 Descriptions of Traffic Statistics Indexes
A generalized CDR consists of CN CDR and UTRAN CDR. RNO engineers focus on UTRAN
CDR, so the following sections focus on KPI index analysis at UTRAN side.
The related index at UTRAN side is the number of RAB for each service triggered by RNC. It
consists of the following two aspects:
y After the service is set up, the RNC sends CN the RAB RELEASE
REQUEST message.
y After the service is set up, the RNC sends CN the IU RELEASE
REQUEST message. Afterwards, it receives the IU RELEASE
COMMAND sent by CN.
Upon statistics, sort them by specific services. Meanwhile, traffic statistics includes the
cause to release of RAB of each service by RNC.
CS CDR is calculated as below:
PS CDR is calculated as below:
The failure cause indexes are sorted in 4.1.2.

2. Types of CDR
indexes
CDR
type
Cause
Corresponding signaling
process
Due to air
interface
RF RLC reset and RL Failure
Expiration of
process timer
RB RECFG
Expiration of PHY/TRCH/SHO/ASU
HHO failure
Not due to air
interface
Hardware failure
The transport failure between RNC and
NodeB. NCP reports failure.
FP synchronization failure.
Transport layer
failure
ALCAP report failure
Subscribers are
released by force
by MML
O&M intervention
The definition of RAN traffic statistics call drop is according to statistics of lu interface
signaling, including the times of RNC's originating RAB release request and lu release
request. The DT call drop is defined according to the combination of messages at air
interface and from non-access lay and cause value. They are inconsistent.
4.2 DT/CQT Optimization Flow
4.2 shows flow chart for analyzing call drop.

2. Flow chart for
analyzing call drop
4.2.1 Call Drop Cause Analysis
Call drop occurs usually due to handover, which is described in chapter 3. The following
sections describe the call drop not due to handover.
Weak Coverage
For voice services, when CPICH Ec/Io is greater than ±14 dB and RSCP is greater than ±
100 dBm (a value measured by scanner outside cars), the call drop is usually not due to
weak coverage. Weak coverage usually refers to weak RSCP.
4.2.1 lists the thresholds of Ec/Io and Ec (from an RNP result of an operator, just for
reference).

1. Thresholds of
EcIo and Ec
Ser
vic
e
Bit
rat
e
of
ser
vic
e
D
L
E
b
N
o
EcIo
thres
holds
Ec
thres
holds
CS 12.2 12.2 8.7 ±13.3 ±103.1
CS 64 64 5.9 ±11.9 ±97.8
PS 64 64 5.1 ±12.7 ±98.1
PS 128 128 4.5 ±13.3 ±95.3
PS 384 384 4.6 ±10.4 ±90.6
Uplink or downlink DCH power helps to confirm the weak coverage is in uplink or downlink
by the following methods.
y If the uplink transmission power reaches the maximum before call
drop, the uplink BLER is weak or NodeB report RL failure
according to single subscriber tracing recorded by RNC, the call
drop is probably due to weak uplink coverage.
y If the downlink transmission power reaches the maximum before call
drop and the downlink BLER is weak, the call drop is probably due
to weak downlink coverage.
In a balanced uplink and downlink without uplink or downlink interference, both the uplink
and downlink transmit power will be restricted. You need not to judge whether uplink or
downlink is restricted first. If the uplink and downlink is badly unbalanced, interference
probably exists in the restricted direction.
A simple and direct method for confirming coverage is to observe the data collected by
scanner. If the RSCP and Ec/Io of the best cell is low, the call drop is due to weak coverage.
Weak coverage might be due to the following causes:
y Lack of NodeBs
y Incorrectly configured sectors
y NodeB failure due to power amplifier failure

The over great indoor penetration loss causes weak coverage. Incorrectly configured sectors
or disabling of NodeB will occur, so at the call drop point, the coverage is weak. You must
distinguish them.
Interference
Both uplink and downlink interference causes call drop.
In downlink, when the active set CPICH RSCP is greater than ±85 dBm and the active set
Ec/Io is smaller than ±13 dB, the call drop is probably due to downlink interference (when the
handover is delayed, the RSCP might be good and Ec/Io might be weak, but the RSCP of
Ec/Io of cells in monitor set are good). If the downlink RTWP is 10 dB greater than the
normal value (±107 to ±105 dB) and the interference lasts for 2s±3s, call drop might occur.
You must pay attention to this.
Downlink interference usually refers to pilot pollution. When over three cells meets the
handover requirements in the coverage area, the active set replaces the best cell or the best
cell changes due to fluctuation of signals. When the comprehensive quality of active set is
bad (CPICH Ec/Io changes around ±10 dB), handover failure usually causes SRB reset or
TRB reset.
Uplink interference increases the UE downlink transmit power in connection mode, so the
over high BLER causes SRB reset, TRB reset, or call drop due to asynchronization. Uplink
interference might be internal or external. Most of scenario uplink interference is external.
Without interference, the uplink and downlink are balanced. Namely, the uplink and downlink
transmit power before call drop will approach the maximum. When downlink interference
exists, the uplink transmit power is low or BLER is convergent. When the downlink transmit
power reaches the maximum, the downlink BLER is not convergent. It is the same with
uplink interference. You can use this method to distinguish them.
Abnormality Analysis
If the previous causes are excluded, the call drop might due to problematic equipment. You
need to check the logs and alarms of equipment for further analysis. The causes might be as
below:
y An abnormal NodeB causes failure of synchronization, so links
keeps being added and deleted.
y The UE does not report 1a measurement report so call drop occurs.
You need to focus on the call drop due to abnormal testing UE, which occurs easily during
CQT. Namely, the data recorded in DT does not contain the information reported by UE for a
period.
HSPA Call Drop Analysis
For HSPA call drop analysis, refer to previous causes to R99 call drop.
4.2.2 Frequently-adjusted Non-handover Algorithm Parameters
The frequently-adjusted non-handover algorithm parameters in call drop are as below:
Maximum Downlink Transmit Power of
Radio Link
Configuring the transmit power of dedicated link to a great value helps to eliminate call drop
points due to weak coverage, but it brings interference. The power of a single subscriber is

allowed to be great, so the subscriber might impact other subscribers or lower downlink
capacity of system when the subscriber consumes great power at the edge of a cell.
The configuration of downlink transmit power is usually provided by link budget. An increase
or decrease of 1±2 dB has little impact on call drop in signal DT, but it can be seen from
traffic statistics indexes. The CDR of some cells is high due to weak coverage, you can
increase the maximum transmit power of DCH. The access failure probability of some cells is
high due to over high load, you can lower the maximum downlink transmit power of radio
link.
Maximum Retransmission Times of
Signaling and Services
When the BLER of the channel is high, the signaling is reset because the retransmission
reaches the maximum times. A reset of signaling causes call drop. The services using AM
mode for service transmission will also retransmit signaling. If the retransmission reaches the
maximum times, the signaling is reset. The system configures the maximum reset times.
When the reset times reaches the maximum, the system starts to release the service, which
causes call drop.
The default configuration of system guarantees that burst blocks will not cause abnormal call
drop, and call drop occurs when UE moves to an area with weak coverage and when the
reset is time, so the system releases resources. In some scenarios, burst interference or
needle effect exists, so 100% block error occurs during burst interference. If you want have
less call drop, increase the retransmission times improper to resist burst interference.
This parameter is configured for RNC.
4.2.3 Judgment Tree for Call Drop Causes
Based on various causes to call drop, the judgment tree for analyzing call drop is as shown
in 4.2.3.

1. Judgment tree for call
drop causes
Preparing Data
The data to be prepared include:
y Data files collected by DT
y Single subscriber tracing recorded by RNC
y CHR recorded by RNC
Obtaining Call Drop Location
You need to use special software to process DT data. For example, the software Assistant
helps to obtain call drop time and location, PICH data collected by scanner, information
about active set and monitor set collected by UE, and the signaling flow.
Analyzing Signal Variation of Best server
From Scanner
Analyze the signal variation of best server from scanner.

y If the signals of best server are stable, analyze RSCP and Ec/Io.
y If the signals of best server fluctuate sharply, you must analyze the
quick variation of best server signals and the situation without best
server. Consequently you can analyze call drop due to ping-pong
handover.
Analyzing RSCP and Ec/Io of Best cell
Observe the RSCP and Ec/Io of best cell according to scanner.
y If both RSCP and Ec/Io are bad, call drop must be due to weak
coverage.
y If RSCP is normal but Ec/Io is bad (delayed handover is excluded,
intra-frequency neighbor cell interference), call drop must be due to
downlink interference.
y If both RSCP and Ec/Io are normal,
When the cell in UE active set is inconsistent with the best cell according to scanner, call
drop must be due to missing neighbor cell and delayed handover.
When the cell in UE active set is consistent with the best cell according to scanner, call
drop must be due to uplink interference or must be abnormal.
Re-perform DT to Solve Problems
A DT might not help to collect all information needed to locate call drop problems, so further
DTs are needed. In addition, you can confirm whether the call drop point is random or fixed
by further DT. You must eliminate fixed call drop points, but you can choose to eliminate
random call drop points.
4.3 Traffic Statistics Analysis Flow
When analyzing traffic statistics indexes, you need to check RNC call drop indexes and
master the overall situation of network operation. Meanwhile, you must analyze the cell
concern for detailed call drop indexes. You can obtain call drop of different services and
approximate causes to call drop by using traffic statistics analyzers.
To analyze traffic statistics indexes, you must analyze the cells with obviously abnormal
indexes. If the KPIs of the cell are good, there must be problems with version, hardware,
transport, antenna-feeder, or data. Based on alarms, you can check these aspects.
If there are no abnormalities, you can form a list of cells with bad KPIs by classifying sector
carriers. Analyze traffic statistics indexes of these cells (such as more indexes related,
analyzing the interval between two periods, indexes leading to call drop, and handover
indexes), and check the causes to call drop based on CHR. When solving problems, you
need to focus on one index and combine other indexes.
When the traffic volume reaches a certain level, the traffic statistics indexes work. For
example, a CDR of 50% does not indicate a bad network. Only when the absolute value of
call times, call success times, and total times of call drop is meaningful in terms of statistics,
the traffic statistics indexes work.
The flow for analyzing traffic statistics is as below.

4.3.1 Analyzing RNC CDR
The RNC CDR involves the number of RAB of each service triggered by RNC, including two
aspects:
y After a service is established successfully, the RNC sends CN the
RAB RELEASE REQUEST message.
y After a service is established successfully, the RNC sends CN the IU
RELEASE REQUEST message, and then receives the IU RELEASE
COMMAND message sent by CN.
AMR CDR = VS.RAB.Loss.CS.RF.AMR / VS.RAB.SuccEstab.AMR.
VP CDR = VS.RAB.Loss.CS.Conv64K / VS.RAB.SuccEstCS.Conv.64.
To analyze PS call drop of various rates, you can analyze the following indexes:
y VS.RAB.Loss.PS.64K / VS.RAB.SuccEstPS.64
Based on analysis of previous indexes, you can obtain the performance of various services
and rates in the network, as well as SHO/HHO call drop. More important, you can obtain the
cells with bad indexes and periods.
4.3.2 Analyzing Causes to Call Drop
In traffic statistics analysis, you must analyze the major causes to call drop.
4.3.2 lists the major indexes for analyzing traffic statistics.
1. Traffic
statistics
indexes for
analyzing
causes to call
drop
Failure
cause
Analysis
OM interference The O&M tasks cause call drop.
Causes due to RAB
preemption
High-priority preemption causes release of CS links. This kind of call drop occurs
when the load and resources are limited. Performing expansion depends on the times
of occurrence.
Causes due to UTRAN
The causes due to UTRAN in the cell lead to abnormal release of link. This
corresponds to abnormal process, so you must further analyze it based on CHR.

Uplink RLC reset
Uplink RLC reset causes release of links, because the coverage quality (including
missing neighbor cell and over mall handover area) is bad.
Downlink RLC reset
Downlink SRB reset causes release of links, because the coverage quality (including
missing neighbor cell and over mall handover area) is bad.
Uplink synchronization
failure
Uplink synchronization failure causes abnormal release of links. The coverage
quality (including missing neighbor cell and over mall handover area) is bad, so the
UE powers off the transmitter abnormally or uplink demodulation is asynchronous.
Downlink synchronization
failure
Downlink synchronization failure causes abnormal release of links. The coverage
quality (including missing neighbor cell and over mall handover area) is bad, so the
UE powers off the transmitter abnormally or uplink demodulation is asynchronous.
No response of UU port
The UE air interface fails to respond the command transmitted by system, because
the coverage is bad.
Other RF causes It is due to RF causes and the coverage quality is bad.
Abnormal AAL2 link
The RNC detects that AAL2 Path at CS lu interface is abnormal, so the system
originates an abnormal release. The problem might be due to abnormal transport
equipment. Immediate normal release during RB establishment is counted by
statistics as abnormal release as the cause.
Abnormal GTPU
The RNC detects the GTPU at PS lu interface is abnormal, so the system originates
an abnormal release. The problem is due to equipment failure.
Other causes You need to analyze the abnormal call drop based on RNC logs.
You can classify the previous indexes 4.3.2 by the classification of previous chapters. They
fall into air interface causes (RF and flow expiration) and not due to air interface causes
(hardware failure, transport failure, and subscribers' interference). Therefore you can have
an overall master of network and obtain the major causes impacting the network.
4.3.3 Check Cells
If the previous KPIs of the cell are normal, check the alarms. By this, you can exclude the
causes due to abnormal cells.
4.3.4 Further DT for Relocating Problems
Analyzing traffic statistics indexes helps to expose potential problems. To locate and analyze
problems, you need to use DT and CHR. For problematic cells, the cell-oriented DT is
performed to trace the signaling flow at UE side and of RNC. For details, see 3.1.
4.4 Optimization Flow for Tracing Data

Analysis traced data includes analyzing single subscriber tracing message and performance
monitoring. Based on the combination of single subscriber message and data at UE side
recorded by data collection tools, you can locate basic call drop problems. For more complex
problems, you need to use CHR and performance monitoring.
By single subscriber tracing data, you need to locate and analyze problems concerning
commercial UEs or key subscribers which are not recorded at UE side.
Single subscriber tracing involves recording the following information:
y Signaling message (lu, lur, lub, and Uu) of single subscriber
y Performance tracing of CPICH RSCP and Ec/Io
y UE transmit power
y Uplink SIR, SIRTarget
y Uplink BLER
y Downlink code transmit power
y Uplink and downlink traffic and throughput (for data services)
4.4 shows the flow for analyzing call tracing.

2. Flow for analyzing
call tracing
4.4.1 Obtaining Single Subscriber Tracing Message
You must first trace single subscriber tracing message on RNC or M2000 and then record
the corresponding messages. For detailed tracing methods, see W-Equipment Room
Operations Guide. Usually analyzing call drop problems by message for tracing IMSI is
enough.
4.4.2 Obtaining Information about Call Drop Point
According to single subscriber tracing messages, the call drop is defined as:
y The RNC originates RAB release (the message is
RANAP_RAB_RELEASE_REQ)
y The RNC originates IU release (the message is
RANAP_IU_RELEASE_REQ)
The former corresponds to call drop caused by TRB reset. The latter corresponds to call
drop caused by SRB reset. By searching for the previous two messages, you can obtain the
call drop time and the signaling message before call drop for further analysis.
4.4.3 Analyzing Call Drop due to SRB Reset

The call drop due to SRB reset is that the UE or RNC fails to receive signaling transmitted in
confirmation mode, and consequently SRT reset occurs, so the connection is released. SRB
reset occurs probably if the UE fails to receive the following messages in downlink:
y Security mode process
y Authentication and encryption process
y Measurement control
y Active set update
y Physical channel reconfiguration
y Transport channel reconfiguration
y RB reset
y Handover command from 3G to 2G (HANDOVER FROM UTRAN
COMMAND)
Confirm that the UE receives these messages by tracing messages at UE side.
SRB reset occurs probably if the UE fails to receive the following messages in uplink:
y Measurement report
y Active set update complete
y Physical channel reconfiguration complete
y Transport channel reconfiguration complete
y RB reconfiguration complete
Confirm that the UE receives these messages by tracing messaged at RNC side.
4.4.4 Analyzing Call Drop due to TRB Reset
TRB reset usually occurs in PS services. It seldom occurs in voice and VP services. Confirm
TRB reset by the UE transmit power upon call drop and downlink code transmit power.
When only one link exists in active set, uplink asynchronization causes RL failure which
consequently causes lu release originated by RNC. Downlink asynchronization causes UE to
power off transmitter, which consequently causes uplink asynchronization. To judge whether
uplink asynchronization or downlink asynchronization causes release, you must analyze the
UE transmit power before call drop and downlink code transmit power monitored in real-time
state.
Weak downlink coverage, strong downlink interference or uplink interference causes TRB
reset. If the retransmission times of data services are improperly configured, TRB reset
occurs before SRB reset upon delayed handover. Pay attention to this.
4.4.5 Analyzing Abnormal Call Drop
Abnormal call drop can neither be located from coverage and interference nor be explained
by TRB reset or SRB reset. It is caused by abnormal equipment or UE. For example, it might
be caused by the following factors:
y Abrupt transmission failure
y Abnormal NodeB equipment
y Abrupt breakdown of UE

Analyze abnormal transmission by analyzing CHR or checking alarms. Confirm that the
NodeB equipment is abnormal by querying NodeB state. Locate abnormal UE problems by
analyzing data recorded by UE.
4.4.6 Performing CQT to Recheck Problems
When the data is inadequate for locating call drop problems, you must start more detailed
data tracing. The best method is to perform CQT at call drop points to recheck problems for
further analysis.
4.5 Optimization Process for MBMS Call Drop
Currently, the RNC V18 or V29 supports only the broadcast mode. In broadcast mode, the
MBMS receives a control message from the MCCH to establish the MBMS service and radio
bearer, without signaling interaction with the RNC. Therefore, we can substitute the MBMS
session drop rate for the MBMS call drop rate. The MBMS session drop rate is defined as
follows:
MBMS session drop rate = number of MBMS session drop times/total number of successes
of MBMS-on-demand x 100%
Number of MBMS session drop times: One MBMS session drop time is counted once the
MBMS service is exceptionally interrupted or the UE is in the buffering state for more than
one minute.
Total number of successes of MBMS on demand: Total number of
successes of MBMS-on-demand originated by the UE.
You can see from the terminal interface whether the MBMS service is exceptionally
interrupted, and you need to use the drive test software to observe whether the UE is the
buffering state for more than one minute. Currently, the software tool used for this purpose is
Qualcomm drive test software QXDM.
The possible causes for a high MBMS deactivation rate are as follows: The network
coverage is poor. The RSCP and Ec/Io in the position where the UE is located are both low.
In addition, a block error rate (BLER) of the FACH of the MBMS service also exists.
The cell is in the preliminary congestion state and the channel power of the
MBMS service is reset to the minimum; or the cell is in the over-congestion
state and the MBMS service with a lower priority is released by force. The
channel power can, however, be automatically recovered to the maximum
or the service can be re-established through periodic detection.
The UE is at the edge of the cells, and the neighboring cells are not
configured for the cell in which the UE is located. As a result, the UE is
unable to obtain a gain through soft combining or selective combining.
Run the DSP CELLMBMSSERVICE command to query the status of the
current MBMS service. If the MBMS service is not established
successfully, the failure cause is displayed.
You can improve the coverage rate by optimizing the RF, adding NodeBs, or adjusting the
antennas. If the coverage does not improve, increase the maximum power of the MBMS
traffic channel. If a neighboring cell is not configured, configure it.

5 FAQs Analysis
5.1 SHO Problems
5.1.1 Over High SHO Rate due to Improper SHO Relative Threshold
Description
The SHO rate in traffic statistics indexes is over high. More than two cells exist in active set
most of the time during DT and are in SHO state.
Analysis
Analyze the relative threshold of 1A and 1B event, namely, reporting range.
5.1.1 shows the SHO relative threshold
1. SHO relative
threshold
According to 5.1.1, the greater the reporting range is, the more easily a neighbor cell is listed
into active set and the more difficult it is deleted from active set. This causes over high SHO
rate.

A general method is to configure the threshold of 1A and 1B different. Configure the
threshold of 1A event small (such as 3 dB) and keep the threshold of 1B threshold the same
(5 dB). In this way, the cells with bad quality cannot be listed into active set easily and the
cells with good quality can be listed into active set. Therefore the SHO rate is lowered based
on normal SHO.
5.1.2 Delayed Handover due to Over Great Intra-frequency Filter
Coefficient
Description
SHO hysteresis is serious in DT: though the signals of a neighbor cell are strong, the cell can
be listed into active set after a long time. If the DT car moves quickly, call drop occurs due to
delayed handover.
Analysis
Layer 3 filter reduces the impact by frequently-fluctuating signals and avoids ping-pong
handover.
The filter of measurement values is calculated as below:
Wherein,
Fn: the measurement resulted update after filter is processed.
Fn-1: the measurement result of last point after filter is processed.
Mn: the latest measurement value received in physical layer.
a = (1/2)(k/2)
. The k is from Filter coefficient, namely, FilterCoef. If K = 0 and a = 1, there is
no layer 3 filter.
The filter coefficient ranges from 0 to 6 (integers). The greater it is, the stronger the capability
of smoothing burr is and the weaker the capability of tracing signals is. You must make a
balance.
According to simulation, 5.1.2 lists the relationship between the filter coefficient and the
corresponding tracing time.

1. Relationship
between the
filter
coefficient and
the
corresponding
tracing time
Filter
coefficient
0 1 2 3 4 5 6 7 8 9 11
Intra-
frequency
tracing time
(s)
0.2 0.4 0.6 1 1.4 2 3 4.2 6 8.4 17
The distance between sites in dense urban areas is short and the handover time is short, so
you must reduce the tracing time, namely, the filter coefficient. The value 2 is usually proper
for filter coefficient of layer 3.
5.1.3 Missing Neighbor Cell
Description
The call drop point is related to signaling flow before call drop.
5.1.3 shows the signaling flow recorded by UE before call drop.

1. Signaling flow
recorded by UE
before call drop
Analysis
Check the pilot test data from UE and scanner at call drop points. 5.1.3 shows the scrambles
recorded by UE active set and scanner before call drop. In 5.1.3, the measurement result of
UE active set and canner is inconsistent and the SC 170 of scanner does not exist in UE
active set.

1. Scrambles recorded
by UE active set and
scanner before call
drop
The cause might be missing neighbor cell or delayed handover. Check scrambles in UE
active set. 5.1.3 shows the scrambles in UE active set before call drop. No SC 170 cell exists
in UE monitor set, because this is possibly due to missing neighbor cell.

2. Scrambles in UE
active set before call
drop
Continue to check the neighbor cell list sent by RNC to UE before call drop, as shown in
5.1.3 and 5.1.3. According to the latest measurement control before call drop, no SC 170
exists in the neighbor cell list, because the call drop is due to missing neighbor cell of SC 6
and SC 170.

3. UE intra-frequency
measurement control
point before call drop

4. Analyzing signaling
of UE intra-frequency
measurement control
before call drop
If only the UE recorded information during test, without scanner information, confirm that call
drop is due to missing neighbor cell by using the following method, as shown in 5.1.3:
y Confirm the scrambles of all cells in active set and the scrambles of
cells in monitor set measured by UE before call drop.
y Compare the scramble information of the cell where the UE camps
on after reselection after call drop and the scrambles in UE active set
and monitor set before call drop.
If the former scramble is not in the scramble list of active set and
monitor set before call drop, the call drop is probably due to missing
neighbor cell.
y Check the neighbor cell list.
This applies for solving call drop due to missing neighbor cell on
site.

5. Confirming missing
neighbor cell without
information from
scanner
Solution
Add neighbor cells. Because the RNC updates measurement control according to the best
cell which is obtainable by searching for intra-frequency measurement report with 1D event
before measurement control is sent. Usually they are configured to bi-directional neighbor
cells.
5.1.4 Redundant Neighbor Cells
According to the protocol, the maximum number of neighbor cell is 32 and the host cell is
also included in these cells, so the actual intra-frequency neighbor cell is 31 at most. The
intra-frequency neighbor cells of S subject are based on data of 2G neighbor cells. In the
dense urban areas, the densely-located sites and combine make the intra-frequency
neighbor cell list large. If the intra-frequency neighbor cells reach or exceed 31, a necessary
neighbor cell found during optimization fails to be listed as an inter-frequency neighbor cell.
For this, you must delete some redundant neighbor cells.
You must be cautious to delete abundant neighbor cells. Deleting necessary neighbor cells
leads to call drop. Following the principles below:
y Before deleting neighbor cells, check the revision record of neighbor
cells. Check that the cells to be deleted are not the ones that were
added during previous DT and optimization.
y After deleting neighbor cells, perform comprehensive test, including
DT and CQT in important indoor spots. From this, you can check the
variation of traffic statistics result of the corresponding cells. The

traffic statistics result includes setup success rate, CDR, and
handover success rate. Ensure there is no abnormality. Otherwise
restore the configuration.
If no reliable 3G handover times can serve as judgment at the network construction stage,
you can estimate the handover probability by using the handover times of 2G neighbor cells.
5.1.4 lists the 2G handover times.
1. 2G handover
times
Assist_GSM_HO_Count
SERVCELL NCELL HOCOUNT
12531 10121 417
12531 10161 3262
12531 10162 2070
12531 10301 381
12531 10321 265
12531 12061 9
12531 12101 961
12531 12111 16
12531 12251 2
12531 12291 4
12531 12292 0
12531 12330 1082

12531 12391 1063
12531 12451 17019
12531 12532 16030
12531 12540 74
12531 12591 926
12531 12592 20994
12531 14051 2
12531 14072 2
12531 14091 211
12531 14111 1
12531 14460 321
12531 56361 16
12531 56362 0
12531 56820 0
12531 56910 206
Search for the neighbor cells with few handover times and even no handovers, such as cell
12531±12292. 5.1.4 shows the location relationship of 2G redundant neighbor cells.

2. Location relationship
of 2G redundant
neighbor cells
According to 5.1.4, multiple NodeBs are located between the cell 12531 and the cell 12292,
so the handover probability is small. Therefore, delete the neighbor cell relationship.
The judgment principles based on 2G statistics might have mistakes, so you must confirm
that no call drop occurs after deleting the neighbor cell relationship.
After network launch, the handover times in traffic statistics according to statistics reflects the
real handovers, so deleting abundant neighbor cells by using the handover times in traffic
statistics according to statistics is more reliable. You need to register the traffic statistics
tasks of two cells on traffic statistics console of RNC.
5.1.5 Pilot Pollution
Description and Analysis
y Locating pilot pollution point
5.1.5 shows the pilot pollution point near Yuxing Rd. SC270 cell is planned to cover the
area with pilot pollution.

1. Pilot pollution near
Yuxing Rd.
y Analyzing signal distribution of cells near pilot pollution point
2. Best ServiceCell near
Yuxing Rd.

3. The 2nd best
ServiceCell near
Yuxing Rd.
4. The 3rd best
ServiceCell near
Yuxing Rd.

5. The 4th best
ServiceCell near
Yuxing Rd.
6. Composition of pilot
pollution near Yuxing
Rd.
From 5.1.5, 5.1.5, 5.1.5, 5.1.5, and 5.1.5, though SC20 cell is planned to cover the area,
but the best ServiceCell is as listed in 5.1.5.
1. Best servers
and other cells
Best
ServiceCell
Primary Others
1st
best ServiceCell SC220 SC260 and SC270

2nd best ServiceCell SC270 SC260, SC220, and SC200
3
rd
4
th
y Analyzing RSSI distribution near pilot pollution point.
5.1.5 shows the RSSI near Yuxing Rd..
7. RSSI near Yuxing
Rd.
5.1.5 shows the RSCP of Best ServiceCell near Yuxing Rd..

8. RSCP of Best
ServiceCell near
Yuxing Rd.
As shown in 5.1.5, the RSSI of the areas with pilot pollution is not large, about ±100 dBm
to ±90 dBm. As shown in 5.1.5, the RSCP of Best ServiceCell is between ±105 dBm to ±
100 dBm. The pilot pollution of the area is caused by no strong pilot, so you can solve the
problem by strengthening a strong pilot.
y Analyzing RSCP Distribution of Related Cells
5.1.5 shows the RSCP of SC270 cell near Yuxing Rd.
9. RSCP of SC270 cell
near Yuxing Rd.
The SC270 cell is planned to cover the area. 5.1.5 shows RSCP of RSCP distribution of
SC270 cell. The signals from SC270 cell are weak in the area with pilot pollution.

Solution
According to on-site survey, the residential area is densely distributed by 6-floor or 7-floor
buildings. The test route fails to cover the major streets, and is performed in narrow streets
with buildings around, so the signals are blocked. The suggestion is to adjust the azimuth of
SC270 cell from 150° to 130° and the down tilt from 5° to 3°. This enhances the coverage of
SC270 cell.
After analysis of DT data, the expected result after adjustment is that the coverage area by
SC270 cell increases and the coverage is enhanced.
5.1.5 shows the pilot pollution near Yuxing Rd. after optimization.
1. Pilot pollution near
Yuxing Rd. after
optimization
5.1.5 shows the best ServiceCell near Yuxing Rd. after optimization.

2. Best ServiceCell near
Yuxing Rd. after
optimization
5.1.5 shows the RSCP of best ServiceCell near Yuxing Rd. after optimization.
3. RSCP of best
ServiceCell near
Yuxing Rd. after
optimization
5.1.5 shows the RSCP of SC270 cell near Yuxing Rd. after optimization.

4. RSCP of SC270 cell
near Yuxing Rd. after
optimization
According to the DT data, the pilot pollution near Yuxing Rd. after optimization is eliminated,
the signals from SC270 cell after optimization are stronger, and the SC270 becomes the
best ServiceCell. This complies with the expected result.
5.1.6 Turning Corner Effect
The turning corner effect exists in the following situation:
The signals of original cell attenuates sharply, and the signals of target cell increases
sharply, so the UE cannot receive the active set update messages, and consequently call
drop occurs.
The variance of Ec/Io is shown in 5.1.6 (the interval between two points is 0.5s).
1. Turning corner effect-
signals attenuation

According to 5.1.6, the signals of original cell attenuate 10 dB sharply within 1s, and the
signals of target cell increase 10 dB. If the signals are weak before attenuation, and 1a event
is configured to easily-triggered state, the measurement report is sent according to traced
signaling of the UE, and the RNC receives the measurement report according to signaling
traced by the RNC.
When the RNC sends the active set update message, the UE cannot receive it due to weak
signals of original cell, so the signaling is reset, and call drop occurs. If 1a event is slowly
triggered (such as configuring great hysteresis or triggering time), TRB reset occurs before
the UE sends the measurement report.
5.1.6 shows an example of turning corner effect.
signal attenuation
recorded by the UE
According to 5.1.6, before turning corner, the signals of active set scramble 104 and 168
attenuate to smaller than ±17 dB, but that of 208 is strong (±8 dB). According to the signaling
traced by the RNC, and the UE reports the 1a event of the cell of scramble 208, and sends
the active set update message. The UE does not receive the completion message, so the
call drop occurs, as shown in 5.1.6.

traced signaling
recorded by the RNC
Solution
To solve turning corner effect problems, do as follows:
y Configure 1a event parameter of a cell to enable handover to be
triggered more easily.
If you lower the triggering time to 200ms, you can reduce hysteresis.
You must configure the triggering time for a specified cell, because
the change of the parameter might lead to easily occurrence of
handover between the cell and other cells without turning corner
effect, or frequent ping-pong handover.
y Configure the CIO between two cells with turning corner effect to
add the target cell more easily. The CIO only affects the handover
between two cells, with less impact, however, it impacts handover.
The configuration leads to an increase of handover ratio.
y Adjust antenna to enable the antenna of target cell cover the turning
corner. This helps avoid fast variance of signals, and avoid call drop.
Actually experiences help judge whether the adjustment of
engineering parameters can cover the turning corner, so using this
method is difficult.
Based on previous analysis, the first method prevails. If it fails, use the second method. If the
second method fails, use the third method (the third method is the best solution, especially in
areas where you can adjust antenna easily).

5.1.7 Needlepoint Effect
The needlepoint effect is that affected by the strong signals of target cell in a short time, the
original cell attenuates sharply, and then increase. The variance of Ec/Io is shown in 5.1.7
(the interval between two points is 0.5s).
1. Needle point-
signal variance
The needlepoint effect cause call drop in the following situations:
y If the needlepoint lasts for a short period, unable to meet the
handover conditions and to affect call drop, it will lead to
deterioration of quality of service (QoS), such as over great BLER
exists in downlink.
y If handover occurs in the target cell, and the signals of the original
cell is over weak, so the UE cannot receive active set update
messages, and consequently call drop occurs.
y If the needlepoint lasts for a short period, and the handover
conditions are difficult to meet, so the signaling or service RB reset
occurs due to weak downlink signals before handover. Finally, call
drop occurs.
y If the target cell completes handover, and becomes a cell in the
active set, call drop occurs because the cell can exit the active set
before completing a handover with the needlepoint disappearing
quickly.
Compared with turning corner effect, the needlepoint effect is more risky due to two
handovers, and failure of one of the two causes call drop. The needlepoint lasts for a short
period, so call drop may not occur if QoS is lowered (for example, configure a greater
retransmission times). The turning corner effect causes an absolute call drop because the
signals of original cell will not recover after turning corner.
Observe the needlepoint effect by scramble distribution diagram of the best cell recorded by
Scanner. If two antennas cover two streets respectively, at the crossing point, needlepoint
effect occurs easily.

5.1.7 shows the call drop distribution of PS384K intra-frequency hard handover (it is the best
cell). Wherein, call drop point drop4, drop5, drop6, drop7, drop15, and drop16 are caused by
needlepoint effect.
2. Call drop distribution
of PS384K intra-
frequency hard
handover
Solution
To solve problems caused by needlepoint effect, you can refer to the solution to turning
corner effect. The key to adjust antenna is not to enable original signals attenuate sharply
and not to enable target signals increase sharply. In addition, you can increase the
retransmission times to resist to attenuation of signals so that CDR is lowered.
5.1.8 Quick Change of Best server Signal
Description
5.1.8 shows signal distribution of cell52 vs. cell88 (signal fluctuation in handover areas).

1. Signal distribution of
cell152 vs. cell88
(signal fluctuation in
handover areas)
After the UE hands over from cell 152 to cell 88, the signals of cell 152 are stronger than that
of cell 88. In 5.1.8, after the signals of cell 152 keep weaker than that of cell 88, the signals
of cell 152 become stronger than that of cell 88 for continuous 2s.
Analysis
When the UE hands over from cell 152 to cell 88, and the signals of cell 152 become better
than that of cell 88. This is similar to the needlepoint effect in 5.1.7. Therefore quick change
of best server signals causes the same handover failures as the needlepoint effect causes,
as follows:
y Ho Req SRB Reset
y Ho Failure
y TRB Reset
To sole the problem, optimize RF engineering parameters and 1D event parameters to avoid
ping-pong handover.

5.2 HHO Problems
5.2.1 Intra-frequency Ping-pong HHO due to Improperly Configured 1D
Event Hysteresis
Description
The UE keeps performing intra-frequency HHO at the cell border, so the call quality declines
and even call drop occurs.
Analysis
Reporting the 1D event triggers the inter-frequency HHO. The 1D event is reported when the
best cell changes, as shown in 5.2.1.
1. Reporting 1D event
The UE is at the border of two cells, so the signals from the two cells are equivalently strong.
Signal fluctuation easily causes ping-pong handover to best cells. Frequent report 1D event
triggers inter-frequency HHO.
To avoid intra-frequency ping-pong HHO caused by 1D event triggered by frequent
fluctuation of signals if the channels are similar, you can increase the hysteresis, as shown in
5.2.1.

Wcdma kpi-analysis

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Wcdma kpi-analysis

Similaire à Wcdma kpi-analysis (20)

Plus de a8us

Plus de a8us (20)

Dernier

Dernier (20)

Wcdma kpi-analysis