You are on page 1of 231

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 Date


Wensu, Wan Liang, Yan Lin,
Ai Hua, Xu Zili, and Hua
Yunlong

Reviewed by Wang Chungui Date


Approved by Date

Huawei Technologies Co., Ltd.


All Rights Reserved

Revision Records
Date Version Description Author

Cai Jianyong,
Completing V2.0 W-Handover and Call Drop
2005-02-01 2.0 Zang Liang, and
Problems.
Jiao Anqiang

According to V3.0 guide requirements, reorganizing Jiao Anqiang


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
2006-03-16 3.0
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.

2006-04-30 3.1 Adding HSDPA-related description HSDPA handover Zhang Hao and
DT/CQT flow, definitions of traffic statistics in HSDPA Li Zhen
handover, HSDPA handover problems. Adding
Date Version Description Author

algorithms and flows of HSDPA handover.

2006-10-30 Adding V17-related handover description as below: Wang Dekai


Changes in signaling flow for H2D HHO
Changes in triggering events of H2D and D2H
3.11 D2H handover in HSDPA based on traffic and timers
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 Adding MBMS-related description. WangDekai /


3.3
Yearly review 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
Figures
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
Full Spelling
Abbreviations

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:

Traffic Statistics Analysis for HSDPA Handover


Handover Between HSDPA and R99
Direct Retry of HSDPA
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:

1Introduction
2Handover and Call Drop Performance Indexes
3Handover Index Optimization
4CDR Index Optimization
5FAQs Analysis
6Summary
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

Statisti
Ind Servi Referen
cs
ex ce ce value
method

SHO success
CS&PS DT&Stat. 99%
rate

Voice DT&Stat. 90%

VP DT&Stat. 85%

PS UL64K/DL
Intra-frequency DT&Stat. 85%
64K
HHO success
rate
PS UL64K/DL
DT&Stat. 80%
144K

PS UL64K/DL
DT&Stat. 75%
384K
Voice DT&Stat. 92%

VP DT&Stat. 90%

PS UL64K/DL
Inter-frequency DT&Stat. 90%
64K
HHO success
rate
PS UL64K/DL
DT&Stat. 87%
144K

PS UL64K/DL
DT&Stat. 85%
384K

Voice handover
Inter-RAT DT&Stat. 95%
out
handover
success rate
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

Reference
Index Service
value

HSDPA-HSDPA intra-frequency
PS (HSDPA) 99%
serving cell update
Reference
Index Service
value

HSDPA-HSDPA inter-frequency
PS (HSDPA) 92%
serving cell update

HSDPA-R99 intra-frequency
PS (HSDPA) 99%
handover

HSDPA-R99 inter-frequency
PS (HSDPA) 90%
handover

Success rate of R99-to-HSDPA


PS (HSDPA) 85%
cell handover

HSDPA-to-GPRS inter-RAT
PS (HSDPA) 92%
handover

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

Reference
Index Service
value

Success rate of inter-cell


SHO in HSUPA (including
PS (HSUPA)
adding, replacing, and
deleting)

Success rate of inter-cell


SHO serving cell update PS (HSUPA)
in HSUPA
Reference
Index Service
value

Success rate of DCH-to-


E-DCH reconfiguration in
PS (HSUPA)
SHO mode (including
replacing and deleting)

Success rate of E-DCH-


to-DCH reconfiguration in
PS(HSUPA)
SHO mode (including
replacing and deleting)

Success rate of inter-cell


intra-frequency HHO in PS (HSUPA)
HSUPA

Success rate of intra-


frequency HHO from a
PS (HSUPA)
HSUPA cell to a non-
HSUPA cell

Success rate of DCH-to-


E-DCH reconfiguration in
single-link mode (the
second step of inter- or PS (HSUPA)
intra-frequency HHO from
a non-HSUPA cell to a
HSUPA cell)

Success rate of inter-cell


inter-frequency HHO in PS (HSUPA)
HSUPA

Success rate of inter-


frequency HHO from a
PS (HSUPA)
HSUPA cell to a non-
HSUPA cell

Success rate of HSUPA-


to-GPRS inter-RAT PS (HSUPA) 92%
handover

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

Statisti
Referen
Ind Servi cs
ce
ex ce metho
value
d

Voice DT&Stat.&CQT 2%

VP DT&Stat.&CQT 2.5%

PS planned full
DT&CQT 3%
coverage rate

CDR
PS (UL DCH full
coverage rate/DL DT 3%
HSDPA)

PS Stat. 10%

PS (UL HSUPA/DL
DT 3%
HSDPA)

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.

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:
The Ec/Io recorded by UE is bad.

The Best Server Ec/Io is good.

No Best Server scramble is in the neighbor cell list of measurement control.

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

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:

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

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,

Based on previous descriptions, pilot pollution exists if all the following conditions are met:

The number of pilots satisfying is more


than .

Set , , and , the judgment standards


for pilot pollution are:

The number of pilots satisfying is larger


than 3.

Improper Configuration of SHO


Algorithm Parameters
Solve the following two problems by adjusting handover algorithm parameters.

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:

Turning corner effect: the Ec/Io of original cell decreases sharply and that of the target cell
increases greatly (an over high value appears)
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.

Ping-pong Handover
Ping-pong handover includes the following two forms
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.

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:

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

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.

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.

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:

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.

Increase the CIO of two inter-frequency cells.


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.

GSM neighbor configuration is complete on RNC. The configuration


includes:
Mobile country code (MCC)

Mobile network code (MNC)

Location area code (LAC)

GSM cell identity (CELL ID)

Network color code (NCC)

Base station color code (BCC)

Frequency band indicator (FREQ_BAND)

Frequency number
Cell independent offset (CIO)
Guarantee the correctness of the previous data and GSM network.

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.
Add data of WCDMA neighbor cells on GSM BSS. The data
includes:
Downlink frequency

Primary scramble

Main indicator

MCC

MISSING NEIGHBOR CELL

LAC

RNC ID

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:

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.
Missing neighbor cell causes call drop.
The signals fluctuate frequently so call drop occurs.
Handset problems causes call drop. For example, the UE fails to
hand over back or to report inter-RAT measurement report.
The best cell changes upon Physical channel reconfiguration.
Excessive inter-RAT cell are configured (solve it by optimizing
number of neighbor cells).
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:

SHO or softer handover of DPCH, with HS-PDSCH serving cell


update
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:

Handover in HSDPA system


Handover between HSDPA and R99 cells
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:

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.
Whether the protection time length of HSDPA handover is proper.
Now the baseline value is 0s. Set it by running SET HOCOMM.
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.
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:

Optimize cell reselection parameters to guarantee that the UE can be


reselected to the best cell in time.
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.
Guarantee that the transmission time difference of the UE between
different links meets the requirement of soft combing or selective
combining*.
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.

Check the SHO success rate of entire network and cell in busy hour.
If they are not qualified, analyze the problematic cells in details.
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

The UE thinks the content of active set update for RNC to add/delete links does not
Configuration nonsupport
support SHO. This scenario seldom exists in commercial networks.

The UE feeds back that the SHO (or softer handover) for RNC to add/delete links is
Synchronization
incompatible with other subsequent processes. The RNC guarantees serial
reconfiguration nonsupport
processing upon flow processing. This cause is due to the problematic UE.

The UE thinks the content of active set update for RNC to add/delete links is
Invalid configuration
invalid. This scenario seldom exists in commercial networks.

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
No response from UE
occurs in areas with weak coverage and small handover area. RF optimization must
be performed in the areas.

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:

Outgoing HHO Success Rate = Outgoing HHO Success


Times/Outgoing HHO Times
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
Analysis
cause

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 The UE thinks it cannot support the command for outgoing


nonsupport HHO, because it is incompatible with HHO.

PCH failure The cause is probably weak coverage and strong interference.

Synchronization
The UE feeds back HHO is incompatible with other consequent processes due to
reconfiguration
compatibility problems of UE.
nonsupport

Cell update occurs upon outgoing HHO. These two processes lead to outgoing HHO
Cell update
failure.

The UE thinks the command for outgoing HHO as invalid. This is a compatibility
Invalid configuration
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
Analysis
cause

RNC-level inter-RAT outgoing handover preparation failure

The CN does not respond the corresponding command for handover


Expiration of waiting
preparation request, because the CN parameter configuration or the
for SRNS relocation
corresponding link connection is problematic. To solve this problem, analyze
command
the causes according to CN and BSS signaling tracing.

After the RNC requests handover preparation, it receives the release command
from CN. This includes the following two cases:

The inter-RAT handover request occurs during


signaling process like location update, so the flow is
not complete before location update is complete.
SRNS relocation Finally the CN sends a release message.
cancellation
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 It corresponds to incorrect configuration of CN, so you must analyze the
expiration causes according to CN and BSS signaling tracing.

SRNS relocation failure


It corresponds to incorrect configuration of CN or BSS nonsupport, so you
in target
must analyze the causes according to CN and BSS signaling tracing.
CN/RNC/system

It corresponds to incorrect configuration of MSC parameters without


Unknown target RNC information like LAC of target cell, so you must check the parameter
configuration. It occurs easily after adjustment of 2G networks.

It corresponds to incorrect configuration of MSC parameters or unavailable


Unavailable resource 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

The CN parameter configuration or the corresponding link connection is


SRNS relocation
problematic, so you must analyze the causes according to CN and BSS
expiration
signaling tracing.

SRNS relocation failure


It corresponds to incorrect configuration of CN or BSS nonsupport, so you
in target
must analyze the causes according to CN and BSS signaling tracing.
CN/RNC/system

SRNS relocation
The BSC fails to support some parameters of inter-RAT handover request, so
nonsupport in target
you must analyze the causes according to CN and BSS signaling tracing.
CN/RNC/system

Other causes Analyze the causes according to CN and BSS signaling tracing.

RNC-level/CELL-level inter-RAT outgoing handover failure

Configuration The UE fails to support the handover command in the network, so the UE is
nonsupport incompatible with the handover command.

The 2G signals are weak or the interference is strong so the UE fails to connect
PCH failure
to the network.

Analyze the problem further according to CHR logs and CN/BSS signaling
Other causes
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

Failur
e Analysis
cause

RNC-level/CELL-level PS inter-RAT outgoing handover preparation failure

Configuration The UE fails to support the handover command of the network, because the
nonsupport UE is incompatible with the command.

The 2G signals are weak or the interference is strong, so the UE fails to


PCH failure
access the network.

The UE is probably incompatible. The UE detects that the sequence number


Radio network layer
of SNQ in the AUTN message is correct, so the handover fails. The value is
cause
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

H-H (HS-DSCH to HS-DSCH) intra-frequency serving cell update


H-H inter-frequency serving cell update
HSDPA-R99 intra-frequency switch
HSDPA-R99 inter-frequency switch
HSDPA-GPRS switch
The traffic statistics indexes are defined as below:

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.

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.

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.

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.

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.
When the RNC sends the UE the PHYSICAL CHANNEL RECONFIGURATION
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.

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
When the RNC sends the UE the PHYSICAL CHANNEL RECONFIGURATION
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.

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.

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:

Success rate of SHO between HSUPA cells (including adding,


replacing, and deleting) = attempt times of active set
update/complete times of active set update.
Success rate of SHO serving cell update between HSUPA cells =
successful times of SHO serving cell update/attempt times of SHO
serving cell update.
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.
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.
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.
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.
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.
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:

Any BCH message (system information)


The RRC Release message with the release cause Not Normal.
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:

After the service is set up, the RNC sends CN the RAB RELEASE
REQUEST message.
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

CD
Corresponding signaling
R Cause
process
type

RF RLC reset and RL Failure

Due to air
RB RECFG
interface Expiration of
Expiration of PHY/TRCH/SHO/ASU
process timer
HHO failure

The transport failure between RNC and


Hardware failure NodeB. NCP reports failure.
FP synchronization failure.

Not due to air Transport layer


interface ALCAP report failure
failure

Subscribers are
released by force O&M intervention
by MML

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

B
i
t
r
a
S D
t EcI
e L Ec
e o
r thr
o thr
v E esh
f esh
i b old
s old
c N s
e s
e o
r
v
i
c
e

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.

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

Lack of NodeBs
Incorrectly configured sectors
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 2s3s, 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:

An abnormal NodeB causes failure of synchronization, so links


keeps being added and deleted.
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 12 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:

Data files collected by DT


Single subscriber tracing recorded by RNC
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.
If the signals of best server are stable, analyze RSCP and Ec/Io.
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.

If both RSCP and Ec/Io are bad, call drop must be due to weak
coverage.
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.
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:

After a service is established successfully, the RNC sends CN the


RAB RELEASE REQUEST message.
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:

VS.RAB.Loss.PS.64K / VS.RAB.SuccEstPS.64
VS.RAB.Loss.PS.128K / VS.RAB.SuccEstPS.128
VS.RAB.Loss.PS.384K / VS.RAB.SuccEstPS.384
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
Analysis
cause

OM interference The O&M tasks cause call drop.

High-priority preemption causes release of CS links. This kind of call drop occurs
Causes due to RAB
when the load and resources are limited. Performing expansion depends on the times
preemption
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 causes release of links, because the coverage quality (including
Uplink RLC reset
missing neighbor cell and over mall handover area) is bad.

Downlink SRB reset causes release of links, because the coverage quality (including
Downlink RLC reset
missing neighbor cell and over mall handover area) is bad.

Uplink synchronization failure causes abnormal release of links. The coverage


Uplink synchronization
quality (including missing neighbor cell and over mall handover area) is bad, so the
failure
UE powers off the transmitter abnormally or uplink demodulation is asynchronous.

Downlink synchronization failure causes abnormal release of links. The coverage


Downlink synchronization
quality (including missing neighbor cell and over mall handover area) is bad, so the
failure
UE powers off the transmitter abnormally or uplink demodulation is asynchronous.

The UE air interface fails to respond the command transmitted by system, because
No response of UU port
the coverage is bad.

Other RF causes It is due to RF causes and the coverage quality is bad.

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
Abnormal AAL2 link
equipment. Immediate normal release during RB establishment is counted by
statistics as abnormal release as the cause.

The RNC detects the GTPU at PS lu interface is abnormal, so the system originates
Abnormal GTPU
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:

Signaling message (lu, lur, lub, and Uu) of single subscriber


Performance tracing of CPICH RSCP and Ec/Io
UE transmit power
Uplink SIR, SIRTarget
Uplink BLER
Downlink code transmit power
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:

The RNC originates RAB release (the message is


RANAP_RAB_RELEASE_REQ)
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:

Security mode process


Authentication and encryption process
Measurement control
Active set update
Physical channel reconfiguration
Transport channel reconfiguration
RB reset
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:

Measurement report
Active set update complete
Physical channel reconfiguration complete
Transport channel reconfiguration complete
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:

Abrupt transmission failure


Abnormal NodeB equipment
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 0 1 2 3 4 5 6 7 8 9 11
coefficient

Intra- 0.2 0.4 0.6 1 1.4 2 3 4.2 6 8.4 17


frequency
tracing time
(s)
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:

Confirm the scrambles of all cells in active set and the scrambles of
cells in monitor set measured by UE before call drop.
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.
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:

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


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.

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
Primary Others
ServiceCell

1st best ServiceCell SC220 SC260 and SC270


2nd best ServiceCell SC270 SC260, SC220, and SC200

3rd best ServiceCell SC200 SC270 and SC260

4th best ServiceCell SC200 SC270 and SC260

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.

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

Description and Analysis


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.

2. 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.
3. Turning corner effect-
traced signaling
recorded by the RNC

Solution
To solve turning corner effect problems, do as follows:

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

Description and Analysis


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:

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

Ho Req SRB Reset


Ho Failure
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.
2. Increasing hysteresis
to reduce frequently
reporting of 1D event

According to 5.2.1, the second times does not reach the hysteresis, so reporting 1D event is
not triggered.

5.2.2 Delayed Origination of Inter-frequency Measurement due to


Improper Inter-frequency Measurement Quantity

Description
When the UE moves to an inter-frequency cell, it fails to start compression mode to start
inter-frequency measurement. It camps on the inter-frequency cell after disconnection.

Analysis
The cell mentioned previously is configured as the carrier central cell after querying cell
configuration. Namely, the 2D event, 2F event, and inter-frequency measurement all take
Ec/No as measurement quantity.
The measured value of pilot Ec/No depends on the following two aspects:

CPICH RSCP strength


Downlink interference
The downlink interference in the WCDMA network includes the interference from downlink
signals of intra-frequency cells (the host cell and neighbor cells) and the background noise.
Wherein, the downlink interference strength of intra-frequency cells is impacted by path loss
and slow attenuation. It is similar to the attenuation that UE receives useful signals (such as
CPICH RSCP).
At the coverage edge of a carrier, when UE moves from the current cell to another cell, the
CPICH RSCP attenuates at the same speed as the attenuation of interference (the
background noise is not impacted by path loss, so the CPICH RSCP attenuates a little faster
than interference attenuates. However, the difference between the two speeds is close
(depending on the strength of background noise). Therefore the UE receives the signals the
CPICH Ec/Io of which changes slowly. According to the simulation and on-site test, When the
CPICH RSCP is about 110 dBm, the CPICH Ec/Io can reach about 12 dB.

1. Attenuation
relationship of RSCP
and Ec/No

If you take Ec/Io as the measurement quantity for 2D event, the 2D event will be triggered
before call drop. Therefore adopting Ec/Io as the measurement quantity for 2D event will not
trigger 2D event upon call drop of UE, so the inter-frequency measurement will not be
started.
In this case, configure the cell to carrier coverage edge cell and take RSCP as the
measurement quantity for 2D/2F event so that inter-frequency measurement is originated in
time.
5.3 Inter-RAT Handover Problems
5.3.1 Ping-pong Reselection

Description
In part of the office building of a commercial deployment, the UMTS-GSM dual-mode MS
performs frequent ping-pong reselection of cells between 3G and the 2G network in the idle
state. 2G and 3G flag are displayed in the screen of Siemens U15 and Moto A835 MSs.
WCP and GCP are displayed in the screen of the Qualcomm test MS frequently. The
reselection from the 3G network to the 2G network takes 1min on average. The reselection
from the 2G network to the 3G network takes 12 minutes on average. During the testing,
the location of the MS and the circumstance keep fixed.

Analysis
The reselection from the 3G network to the 2G network is as follows:

When the pilot signal quality Ec/Io in 3G cells minus Qqualmin is


less than the inter-RAT measurement start threshold SsearchRAT, the
UE started to measure the 2G neighbor cell.
When the quality of signal in 2G neighbor cells satisfies the cell
reselection criteria and lasts for Treselection, the UE selects 2G cells.
3G RSCP is below 90 dBm at the borders of 3G network. However the 2G RSCP ranges
from 60 dBm to 70 dBm with signals of good quality. Therefore, once the UE starts to
measure the 2G neighbor cells and the signal in the cell fails to be better in Treselection, the
UE reselects the 2G cells.
The key parameter in reselection from the 3G network to the 2G network in test is
SsearchRAT. The rational configuration of the reselection delay timing parameter
Treselection helps solve ping-pong reselection.
The reselection from the 2G network to the 3G network is as follows:

When the signal strength of 2G serving cell satisfies the inter-RAT


start threshold Qsearch_I, the 3G neighbor cells are measured. From
optimized 3G strategy, the current configuration is 7 (always start).
When the signal strength RSCP of the 3G cell minus the current
RLA_C (the average signal strength in 2G serving and non-serving
cells) is greater than FDD_Qoffest, and it lasts 5s, the 3G cell can
serve as the target cell to be reselected. The current FDD_Qoffset is
7 (always reselect 3G cells).
When the signal quality Ec/Io of the 3G cell is greater than or equal
to FDD_Qmin threshold, the 3G cell can serve as the target cell to be
reselected.
In the cells that satisfy the previous conditions, the UE select the cell
of best quality as the target cell to be reselected.
Therefore, the key parameter in from the 2G network to 3G is FDD_Qmin. The default
configuration is 12 dB.

Solutions
In network optimization, the operator can take the following adjustment:

The operator increases the interval between SsearchRAT and


FDD_Qmin. According to the default parameters, if 3G CPICH
Ec/Io is greater than 12 dB in the GSM system, the UE reselects the
3G network. If 3G CPICH Ec/Io is less than or equal to 14 dB, the
UE reselects the GSM network from 3G network. In the current
parameters configuration, the signal fluctuation of 3G CPICH Ec/Io
decides the frequency of cell reselection. If the signal fluctuation is
over 1 dB, the ping-pong reselection occurs. In field test of 3G cells,
if Ec/Io is less than 14 dB, the UE drops off the network easily, so
the SsearchRAT cannot be less, and FDD_Qmin can be increased.
The value range of FDD_Qmin is over small, so it can be only set to
its maximum value 13 dB. Since the protocol of September 2003,
the value range of FDD_Qmin is increased through CR GP-032221
(see 5.2 for details). If the UE is updated according to GP-032221,
the FDD_Qmin is increases completely. If FDD_Qmin is set to 8
dB, compared with the start measurement threshold 14 dB of
reselection from the 3G network to 2G network, FDD_Qmin has a
space of 6 dB. In this way, the ping-pong reselection caused by
signal fluctuation is less likely.
Treselection is increased. If the default configuration is 1s, the
Treselection can be set to 5s. In this way, the reselection between the
3G network and the 2G network is reduced.
5.3.2 PS Inter-RAT Ping-pong Handoff

Description
The UE performing PS domain services hands off between the 3G network and the 2G
network.

Analysis
For inter-RAT handoff of CS and PS, the services for CS and PS are different in handoff
between the 2G network and the 3G network.

In CS service, after handoff from the 3G network to the 2G network


and after release of services in the 2G network, the UE reside again
in the 3G cell through reselection from the 2G network to the 3G
network or reselection of PLMN.
In PS service, after the reselection from the 3G network to the 2G
network started by the network, the UE re-accesses the 2G network.
In services transmission, the UE performing PS services may return
to the 3G network through reselection between the 2G network and
the 3G network. According to the analysis of 3.1, in the reselection
of the cells performing PS domain services from the 2G network to
3G network, the actual working factor is the configuration of
FDD_Qmin (measuring Ec/Io). If Ec/Io is greater than FDD_Qmin,
the UE reselects 3G network. Whether the UE has handed off from
the 3G network to the 2G network is judged through measuring
RSCP in condition of the cell as a border cell. Measuring RSCP
cannot assure that Ec/Io is greater than FDD_Qmin, so no
mechanism can avoid ping-pong handoff.
The solutions lie in as follows:

The measurement target of 2G and the 3G network is unified. If this


cannot be performed, the following method is adopted.
The start parameters in compression mode and reselection threshold
from the 2G network to the 3G network is adjusted.

Solutions
Unification of measurement target in the 3G network and the 2G
network
When there are more than one 3G cells, the change of Ec/Io indicates
the change of 3G cell quality. If the cell property is configured as
carrier center cell and the measurement target in 2D event is Ec/Io,
the measurement target between 3G and the 2G network is Ec/Io.
The default parameter of 2D/2F with the measurement target Ec/Io is
24 dB. The parameter can be adjusted to 12/10 dB to avoid ping-
pong handoff.
In addition, the new 3GPP TS 05.08 protocol defines the RSCP
(FDD_RSCP) that can measure the 3G network in reselection from
the 2G network to the 3G network. Now only Ec/Io can be tested.
The adjustment fits the 3G cells the cell property of which is carrier
border cell. However many current NEs does not support this.
Adjustment of start parameters in compression mode and reselection
threshold from 2G to 3G network
The adjustment fits the 3G cells the property of which is carrier
border cell. Only 3G Ec/Io can be measured in reselection from the
2G network to 3G network. The start/stop threshold in compression
mode can be lowered to 105/100 dBm.
5.3.3 Failure in handoff from 3G to the 2G network

Description
In the office building of a commercial deployment, when the UE originates a call in areas
covered by the 3G network and moves towards the areas covered by the 2G network, the
call drops easily. The call succeeds one or two times every ten times.

Analysis
The 2G neighbor cells configuration of the 3G network cells that cover the office building in
the WCDMA network parameters is examined. The 2G cells that cover office building need to
be confirmed in the 2G neighbor cells list. UMTS outdoor macrocells are used to perform 3G
coverage in the office building, the test route is switched by passing two iron doors. After the
operator opens the door, enters, and closes the door, the signal attenuates sharply. 5.3.3
shows the UMTS signal distribution observed by a scanner.
The signal attenuates sharply, so the handoff is not performed in time, and then the call
drops. The key solution is to adjust the inter-RAT switching parameters. This leads to an
earlier and faster handoff.
The operator does as follows:

Change the cell independent offset (CIO) in the GSM neighbor cell
from 0 dB to 5 dB. The UE hands off to the GSM cell more easily.
Call still drops in test.
Change 2D RSCP Threshold from 95 dBm to 85 dBm to 75
dBm. The inter-RAT measurement starts earlier. Call still drops in
test.
Change GSM RSSI from 90 dBm to 95 dBm. The UE hands off to
GSM cells more easily. Call still drops in test.
Change 2D Trigger Time from 640ms to 320ms to 0ms. The inter-
RAT measurement starts more easily. Call still drops in test. Change
the parameter back to 640ms.
Change the cell location property from carrier border to carrier
center (the associated measurement changes from RSCP to Ec/Io).
Change 2D Ec/Io Threshold from 24 dB to 10 dB. Call still drops
in test.
Change Inter RAT handover trigger time from 5000ms to 2000ms.
The UE performs inter-RAT more quickly. Call drop is improved.
Recover the parameter changed in Step 5 as it was.
Change Inter RAT handover trigger time from 2000ms to 1000ms.
The UE performs inter-RAT handoff more quickly. Call drop is
solved.
The adjustment results in that the change to the parameter Inter RAT handover trigger time
is the most effective to complete inter-RAT handoff.

1. Indoor 3G RSCP
distribution

Solutions
The operator checks as follows:

Check that 2G neighbor cells are validly configured.


Reduce TimeToTrigForVerify (TimeToTrigForNonVerify needs no
change. The current protocol defines that the UE needs not to report
on NonVerify) to make UE hand off to the 2G network more quickly.
Increase GSM CIO. This increases the possibility of handoff to the
2G network, but increases the coverage of the 2G network and
reduces the coverage of 3G, therefore this step need consideration.
Increase the GSM RSSI handoff threshold. This increases the
coverage of the 2G network, but reduces the coverage of 3G
network, therefore this step needs consideration.
Increase 2D/2F threshold in compression mode to start compression mode earlier.
5.3.4 Inter-RAT Handover Call Drop

Missing Neighbor Cell


Confirm the call drop due to missing neighbor cell by 3G cell information displayed on M
testing cell. You must check whether the neighbor cells are missing in the following
situations:

The signals of 3G cell are weak.


Ec is smaller than 110 dBm.
Ec/Io is smaller than 10 dB.
A 2G testing UE detects that the 2G signals of indoor DAS are
strong
The UE starts compression mode for measurement
The UE does not sent the measurement report of 2G neighbor cells.
The following are two examples.

Example 1:
14:24:17(12): According to RB Setup, the UE accesses the network by PSC 417.
14:25:36(02): The UE does not report 2D measurement report until call drop. The RNC
does not send measurement control report.
Conform that no inter-RAT neighbor cells are configured by examining parameters. If the
cells are added, call drop problems are solved.

Example 2:
16:38:18(18): The UE reports 1D event of cell 273, and cell 273 becomes the best cell.
However, the BCCH 538 indoor 2G cell is not configured as an inter-RAT neighbor cell
of cell 273.
16:38:40(20): The UE keeps sending measurement reports, but detects that the signals of
other GSM neighbor cells are weak. Therefore the RNC does not start handover, and then
call drop occurs.
The cell of PSC273 and PSC 264 alternate to be the best server. Indoor GSM neighbor
cells are configured as the inter-RAT neighbor cells of the cell of PSC264, but the cell of
PSC273 is not configured with any neighbor cells. When the UE enters indoor, the cell of
PSC273 becomes the best server, so call drop occurs. After indoor GSM neighbor cells
are configured as the inter-RAT neighbor cells of the cell of PSC273, no call drop occurs.

Abundant Inter-RAT Neighbor Cells


According to the signaling, the phenomena of excessive inter-RAT neighbor cells are as
follows:
After the RNC sends Physical channel reconfiguration and inter-RAT measurement control
messages, the UE keeps sending the measurement report of Nonverified until call drop.
In S subject, for convenient configuration of parameters, the original 2G neighbor cell
information is used to configure inter-RAT neighbor cells. All the inter-RAT cells are
configured as the neighbor cells of 3G cells. Inter-RAT cell offset is configured to enable the
UE to hand over to the target cell and to disable the UE to hand over to the undesired cell.
If excessive neighbor cells are configured, the UE must spend more time on inter-RAT
measurement. The measurement internal of UE is limited, excessive neighbor cells delay UE
to measure available neighbor cells, so call drop occurs.
Example :
11:30:11(92): The RNC sends measurement control messages (23 inter-RAT neighbor
cells)
11:32:22(61): The UE keeps reporting to BSIC Nonverified cell until 2 minutes before
call drop.
Configure the inter-RAT neighbor cells to the needed four neighbor cells, the MotoA835
hands over successfully.

Improper Configuration of LAC


Confirm improper configuration of LAC by signaling. The CN replies the No Resource
Available messages, so examining data configuration before test is necessary. In addition, if
the mobile switching center (MSC) fails in assigning related resources, such as inter-MSC
trunk resources, the T resource to MGW, control table resource, the CN might reply the No
Resource Available messages.
Example :
10:53:23(29): The RNC sends the Relocation Require message due to the No Resource
Available message.
10:53:23(71): The CN replies the Relocation Failure message due to the No Resource
Available message.
The RNC keeps sending Relocation Require message due to No Resource Available
message until call drop, and is rejected. The actual LAC is 21000. After adjustment, the
UE succeeds in handover.

No Measurement Report by UE
If the UE does not send measurement report, the UE performs the same as when the
neighbor cells are missing. The phenomena are as follows:

The signals of 3G cell is weak


Ec is smaller than 110 dBm.
Ec/Io smaller than 10 dB.
A 2G testing UE detects that the 2G signals of indoor DAS are
strong
The UE does not hand over.
Check the signaling to confirm whether the UE send measurement report messages. If you
compare it with terminals of other types, confirming the problem is easier and more accurate.
Example :

Moto A835 handset:


16:38:05(99): The UE sends 2D measurement reports.
16:38:06(06): The RNC sends Physical channel reconfiguration (active sets contains
PSC46, PSC492, and PSC36)
16:38:07(19): The RNC receives Physical channel reconfiguration completion, and then
sends measurement control messages.
16:38:08(75): The cell of PSC 492 reports 1D and becomes the best server. It sends new
measurement control messages after 1.5s.
16:39:19(73): The system does not receive the UE inter-RAT measurement report before
call drop.

Qualcomm 6250 handset


16:38:42(16): The UE sends 2D measurement reports.
16:38:42(49): The RNC sends Physical channel reconfiguration (active set contains
PSC46 and PSC492)
16:38:43(43): The RNC receives Physical channel reconfiguration completion message,
and it sends measurement control messages.
16:38:47(74): The UE report BCCH 847 BSIC Verified, and the level is 67 dBm.
16:38:48(88): The RNC sends HO CMD message, so the handover succeeds.
In the test of handover between outdoor 3G to indoor 2G DAS, the Moto A835 handset does
not send inter-RAT the measurement report for multiple times. The IOT engineers think that
the version of out handset is not updated, and they recommend updating handset version.

Delayed Handover
According to signaling of the RNC, a normal inter-RAT handover takes 5s. The following are
the time needed by the RNC, longer than that on UE. If the walking speed is 3 km/h, it takes
45 meters. The time depends on different scenes.
16:21:06(30): The UE sends the 2D measurement report.
16:21:06(37): The RNC sends the Physical channel reconfiguration message.
16:21:07(46): The UE sends the Physical channel reconfiguration completion message.
16:21:09(72): The UE sends the inter-RAT measurement reports.
16:21:10(48): The system sends the UE HO FROM UTRAN CMD GSM message.
16:21:11(11): The RNC sends the Iu interface Release Command message.
When the UE moves outdoor to indoor with the 3G signals fluctuating sharply, call drop
occurs due to delayed handover. According to the signaling, the phenomena of delayed
handover are as follows:

During the handover process, the RNC originates lu Release


because:
The NodeB reports RL Failure.

The NodeB does not report RL failure, but SRB reset occurs.

The CN originates lu Release command, due to treloccomplete


expire.
Other situations: 3G signaling is normal, but actually the call drops.
You can only know whether the UE confronts call drop problems by
checking the UE call drop recorded in test.
Example 1:
Moto handset:
15:26:27(87): The RNC sends Physical channel reconfiguration (active set contains
PSC201 and PSC16).
15:26:30(30): The UE report BCCH 844 BSIC Nonverified, and the level is 87 dBm.
15:26:31(26): The UE report BCCH 844 BSIC verified, and the level is 88 dBm.
15:26:32(13): The RNC sends the HO CMD message.
15:26:34(25): The UE sends inter-RAT measurement reports, but does not hand over. This
is because the UE does not receive HO CMD sent by the RNC, or the UE fails in
accessing the 2G network. The CN sends lu Release due to treloccomplete expire
(normally successful relocation causes lu Release, and the UE succeeds in accessing the
2G network).

Qualcomm handset in the same test period:


15:26:27(43): The RNC sends Physical channel reconfiguration (active set contains
PSC201 and PSC16).
15:26:30(90): The UE report BCCH 844 BSIC verified, and the level is 79 dBm.
15:26:32(13): The RNC sends HO CMD, and the handover succeeds.
Here is the entrance to parking yard of Taigu Shopping Hall. Before call drop, the Moto
handset indexes as follows:

Ec is smaller than 110 dBm.


Ec/Io is small than 15 dB.
In addition, according to comparison of two terminals, they are different in measuring GSM
level (Qualcomm 6250 uses an external antenna, while Moto A835 uses a built-in camera).
This affects the inter-RAT measurement.
Example 2:

Moto handset:
17:08:59(61): The UE sends 2D measurement reports, and the RNC sends Physical
channel reconfiguration.
17:09:00(78): The RNC receives Physical channel reconfiguration completion, and sends
measurement control messages.
17:09:04(35): The NodeB is out of synchronization, so call drop occurs, and no inter-RAT
the measurement report is sent.
17:09:20(89): The RNC originates Iu Release due to Radio Connection with UE lost.

Qualcomm handset in the same test period:


17:08:59(29): The UE sends 2D measurement reports, and the RNC sends Physical
channel reconfiguration.
17:09:00(33): The RNC receives Physical channel reconfiguration completion, and sends
measurement control messages.
17:07:58(81): The RNC receives the measurement report from UE, BCCH 853, and the
level is 61dBm.
17:08:00(25): The RNC sends HO CMD.
17:08:00(90): The CN sends Iu Release Command (successful relocation).
Actually, call drop occurs during handover.
Now the starting threshold of compression mode is as high as 95 dBm. Do not change it to
avoid impact on other parts of the network so that the handover occurs earlier.

Change of Best Cell in Physical


Channel Reconfiguration
According to the test result, if the best cell changes, the handover is delayed, so call drop
occurs in the following situations:

Between RNC sending Physical channel reconfiguration and


receiving Physical channel reconfiguration completion sent by UE
(about 1s).
After Physical channel reconfiguration process is complete.
Example 1:
14:06:18(75): The best server PSC201 report 2D event (meanwhile, PSC16 is in the
active set).
14:06:18(82): The RNC sends Physical channel reconfiguration.
14:06:18(95): The UE reports 1D event of PSC16 cell.
14:06:19(95): The RNC receives Physical channel reconfiguration completion from UE,
and it sends inter-RAT measurement control message of PSC201 cell, and inter-
frequency and intra-frequency measurement control of PSC16 cell.
14:06:20(94): The UTRAN sends 1B event to the UE to delete PSC 201.
14:06:21(45): The RNC sends inter-RAT measurement control to the cell of PSC16 (3s
delay compared with 1D event).
14:06:22(83): The UE reports the GSM cell 852 (BSIC Verify) according to the new
measurement control, and the RSSI is 79 dBm. The RNC does not process the report (to
prevent UE from handing over to incorrect cell, the RNC must process UE measurement
report 3s after sending new measurement control)
14:06:28(94): NodeB is out of synchronization, so call drop occurs.
Example 2: Qualcomm handset:
14:53:08(63): The UE sends 2D measurement reports, and the RNC sends Physical
channel reconfiguration (the cell 144 is the best server)
14:53:09(67): The RNC receives Physical channel reconfiguration completion, and sends
measurement control messages.
14:53:16(58): The UE sends 1D measurement reports, and cell 137 becomes the best
server. Therefore the RNC sends the measurement control messages of best server 137,
including inter-RAT neighbor cells (the neighbor cell list is different from that of cell 144)
14:53:16(62): The RNC does not receive the measurement report from UE, and ensures
that the cell ID is in the list of neighbor cells of cell 144. The RNC does not process the
reports
14:53:19(99): The RNC originates Iu Release.
If different interRATCellID is used in inter-RAT measurement control, will the RNC avoid this
problem?
UE Hand Back Failure
Other abnormalities in handover might cause handover failure.
Example :
14:07:37(38): The UE reports BCCH the measurement report of cell 852, Nonverified
BSIC.
14:07:38(38): The TimeToTrigger of Nonverified is 1s, and after 1s, the RNC sends
Relocation to CN.
14:07:38(38): The UE sends BCCH the measurement reports of cell 852, verified BSIC.
14:07:38(74): The CN replies that Relocation Prepare fails (no radio resources).
14:07:38(78): The UE sends the measurement report before failure, so the RNC again
originates Relocation to CN.
14:07:40(12): The CN replies Relocation to RNC, and RNC sends HO CMD to UE.
14:07:40(79): However, the UE replies HO FAIL.
Late, the UE keeps deleting cell 201 which is the best server, so the RNC does not process
the request. The 3G signals are weak, so call drop occurs.

Delayed Starting of Compression


Mode
Description:
The UE cannot hand over from the 3G network to the 2G network smoothly. In details,
the UE originates a call in 3G coverage areas or uses PS services, and then enters 2G
coverage areas. However, it fails in handing over to 2G networks, so call drop occurs.
Analyze the signaling process at RNC side, and check the causes to handover failure. The
causes include:

The network side fails in receiving 2D report from UE, so compression mode is not started.
Consequently 2G cells are not measured, and then asynchronization or SRB/TRB reset cause
call drop.

The network side receives 2D report, but compression mode is not started. The reason is that
the network side sends a PHY_CH_RECFG message, but the UE fails in sending ACK
message or PHY_CH_RECFG_CMP, so SRB is reset, and call drop occurs.

The network side receives Verified measurement reports. After it sends UE the handover
messages, the UE fails in receiving it, so call drop occurs (also for other reasons).
The above cases are due to delayed starting of compression mode, so the quality of
signals of the original cell becomes weak. Therefore subsequent starting compression
mode and handover process cannot proceed normally.

Analysis:
Starting compression mode is affected by 2D event configuration of ID2 measurement
control sent by the network side. You can enable 2D event to be reported more quickly by
the following methods:

Increasing the threshold of 2D event

Reducing hysteresis
Reducing delayed triggering time
Now the back system can configure different starting threshold of inter-RAT compression
mode for signaling, CS and PS services.
5.4 Call Drop Problems
5.4.1 Over Weak Coverage

Description and Analysis


5.4.1 shows the call drop due to coverage problems.

1. Analyzing weak
signals

5.4.1 describes the following indexes:

Scrambles, Ec/Io, and RSCP of cells in active set before call drop
Scrambles and Ec/Io of cells in monitor set
Transmit power of UE, BLER of transport channel, and call drop
time
The DT data analysis software Analyzer provides the previous data.
According to the data before call drop, the Ec/Io of active set is smaller than 15 dB and the
RSCP is close or smaller than 110 dBm, so the call drop must be due to downlink weak
coverage. After call drop, the UE camps on the cell of SC 232 the quality of which is bad, so
the call drop must not be due to missing neighbor cell.
According to the 5.4.1, the transmit power of UE approaches 21 dBm and the downlink
BLER before call drop reaches 100% (due to the comprehensive effect by inner loop and
outer loop, the downlink code transmit power reaches the maximum. Confirm this by using
the data for tracing the performance of RNC). According to previous analysis, the uplink and
downlink are balanced. To sum up, the call drop is due to bad coverage.

Solution
To solve coverage problems, you must adjust engineering parameters of antennas or
construct new sites.

5.4.2 Uplink Interference

Description and Analysis


Uplink interference leads to unbalanced uplink and downlink, so call drop occurs.
5.4.2 shows the uplink interference according to RNC signaling.
1. Uplink interference
according to RNC
signaling

According to 5.4.2, the RNC sends a CC Connect message, but the UE


does not respond to the CC Connect message. This causes the call drop.

2. Uplink
interference according
to UE signaling

The UE receives the CC connect message sent by RNC and then replies with CC connect
Acknowledge message which the RNC fails to receive.
The following paragraphs describe the signals before and after call drop.
5.4.2 shows the uplink interference information recorded by UE.
3. Uplink interference
information recorded
by UE

From the UE side, the downlink PCICH Ec and Ec/Io are good, but the uplink transmit power
approaches the maximum. Therefore it is probably an uplink problem.
Interference:
The problematic site is the site 90640. The cells involve the cell 24231 and 24232. The
RTWP of the cell fluctuates sharply.
4. RTWP variation of the
cell 89767

5. RTWP variation of the


cell 89768

Solution
Locate the sources of interference t solve uplink interference problems.

5.4.3 Abnormal Equipment


Summarizing call drop problems due to abnormal equipment is difficult. Generally abnormal
CN, RNC, NodeB, and UE will lead to call drop. Some call drop problems can be further
analyzed and located only in research and development (R&D) environment. The following
paragraphs described the call drops that occurred before. You can refer to them.
Abnormal Uplink Synchronization of
NodeB
According to the test, at a fixed spot (at the corner under an overhead), call drop occurs in
the test car when it passes the spot every time. Each call drop occurs in the cell of SC 160.
The call drop location is special, so the call drop is probably due to turning corner effect.
Based on repeated DT, a conclusion forms that call drop occurs within 5s when the signals
measured by scanner in the cell are from only one cell (SC 160).
According to signaling flow, the cell of SC 160 keeps being added because the UE reports
the measurement. It also keeps being deleted because the NodeB is asynchronous, so the
link is deleted 5s after expiration of timer. At the same time, the access to the cell also fails.
Strangely the downlink signals of the cell is normal (because the cell can measure the pilot
signals and send a report), but the uplink is problematic. The NodeB logs and alarms involve
no prompts. After reset of board one by one, the problem is solved.

Abnormal UE
Failure to report 1a event by UE
Call drop occurs easily with a version of Qualcomm 6250 during
test. According to the analysis of data, the Ec/Io and RSCP recorded
by scanner are good upon every call drop. The signals of the active
set recorded are weak, but there are cells with qualified signals.
According to the signaling flow, the UE does not send the 1a event
measurement report of the cell in monitor set, so finally call drop
occurs. After the UE is updated, the problem is solved.
Missing of messages recorded by UE
When Moto A835 records signaling messages, it loses some
signaling before call drop easily. This leads to incorrect judgment of
call drop problems. The signaling before call drop is key for
analyzing call drop. If it is missing, you must analyze call drop
problems based on the combination of messages form UE and
information about RNC.
Abnormal Moto handset due to continuous CQT
After tens of or hundreds of CQTs, the calling or called Moto
handset is likely to confront problems, so calls fail. After reset of the
handset, it becomes normal. There is another problem. When the
handset is called, it does not ring and consequently call drop occurs.
However, the screen displays an unanswered call. To avoid this, reset
the handset after continuous CQT.
Failure to hand over from the 3G network to the 2G network
The 3G signals received by a Sony-Ericsson handset attenuate
slowly at the subway entrance and finally no signals are received.
The 2G signals are received at the subway entrance and inside
subways. Therefore, the handset fails to hand over to the 2G
network. The Moto handset and Nokia handset can succeed in
handover. The handover failure is probably due to excessive 2G
neighbor cells are configured. After excessive 2G neighbor cells are
deleted and only one 2G neighbor cell is kept, the Sony-Ericsson
handset succeeds in handover. When two 2G neighbor cells with the
same frequency and different BSIC exists, the handset will stop
handover because it is not specified with the BSIC and the target 2G
neighbor cell when it is sending the measurement report.
5.5 HSDPA-related Problems
5.5.1 HSDPA Handover Problems
A connected HSDPA subscriber uses the following channels:

HS-PDSCH
HS-SCCH
HS-DPCCH
DPCH as associated channel.
When the R99 subscribers have handover problems, the HSDPA subscribers cannot
smoothly hand over. Therefore, when the HSDPA subscribers fail to hand over, engineers
need to check R99 handover. If R99 subscribers have handover problems, solve the
problems as previously mentioned. The call drop problems currently in test is usually caused
by R99 problems.

ADCH SHO with Serving Cell Update


When SHO occurs on the associated DCH, the HS-DSCH serving cell is updated. This is
triggered by reporting 1D event by UE. If now the SHO on the associated DCH is faulty, call
drop occurs with HSDPA subscribers. The causes is as mentioned in 5.1
The following paragraphs describe a case: missing neighbor cell causes handover on
associated DCH fails, and this consequently causes call drop of HSDPA subscribers.

Description and Analysis


Before call drop, the cell of SC 11 serves HSDPA subscribers.
5.5.1 shows the pilot information recorded by scanner.

1. Pilot information
recorded by scanner

The active set does not list the cells of SC 25 and SC 26. After call drop, the UE camps on
the cell of SC 26. Meanwhile, the quality of signals from the cell of SC 11 declines
sharply.
According to previous description, the call drop is probably due to missing neighbor cell.
For detailed analysis, see 5.1.

Solution
To solve the problem, add the corresponding neighbor cell.

ADCH HHO with Serving Cell Update


Call drops due to ping-pong handover.
While the HHO occurs on ADCH, the HS-PDSCH serving cell is updated.
When the HHO occurs on ADCH:

If the 1D event is improperly configured, intra-frequency ping-pong HHO occurs on ADCH,


and the HS-PDSCH serving cell is frequently updated. This leads to decline of QoS, and even
call drop.

If the 2D/2F and handover threshold is improperly configured, ping-pong handover occurs,
and consequently QoS declines.

Handover between HS-PDSCH and


DPCH
Related causes are to be supplemented.

Handover between HSDPA and


GPRS
For the handover between HSDPA and GPRS, refer to 5.3.4.

5.5.2 HSDPA Call Drop

Weak Coverage
After HSDPA technology is used, the downlink load of cell increases. This has some impact
on coverage radius of cell. If the load of original R99 cell is light, the coverage scope
decreases sharply after HSDPA technology is used. Pay attention to cell coverage and call
drop problems caused by decrement of handover areas after R99 network is upgraded to
HSDPA network.
HS-DPCCH is used in uplink of HSDPA, so the HSDPA UE consumes more power than R99
UE, and consequently, the HSDPA UE at the cell edge reaches the maximum transmit power
more quickly than R99 UE at the cell edge. This is uplink power restriction.

The maximum transmit power of some R99 UEs and HSDPA UEs are the
same, 24 dBm.

Description and analysis


In test, before call drop the Ec/Io of active set before call drop is below 15 dB, and the
RSCP is below 110 dBm. After call drop, the UE camps on a new cell, where the Ec/Io
is also above 15 dB and RSCP is above 110 dBm. The transmit power of UE before call
drop approaches 24 dBm (terminal is data card E620), so the problems is caused by weak
coverage.

Solution
To solve the problem, adjust engineering parameters or construct sites.

Call Drop due to Improper


Configuration of Parameters
The call drops due to strong uplink interference if all the following conditions are met:

The power of HS-DPCCH is over high


The uplink admission threshold is low
There are excessive subscribers
The signaling flow for HSDPA service handover is more complex than that of R99 service
handover. In some occasions, the handover parameters are differently configured for these
two networks. For example, in turning corner, the UE is required to respond messages from
UTRAN more quickly; in ping-pong handover areas, the protection time is longer.

Abnormal Call Drop


The early versions of HUAWEI E620 are faulty in inter-frequency handover. After reporting
2D event, the UE responds measurement control failure, so the call drops due to handover
failure.
5.6 HSUPA Problems
To be supplemented.
6 Summary

Based on related guides to handover and call drop, this guide is complete. It focuses on
operability by on-site engineers. In addition, it describes operation steps in details for the
actual handover and call drop problems in forms of flow chart.
The fundamental knowledge and preparation knowledge are placed in the appendix.
Operations are in the body.
V3.1 supplements HSDPA knowledge, including:

DT/CQT flow for HSDPA handover


Definition of traffic statistics indexes for HSDPA handover
HSDPA handover problems
Algorithm and flow for HSPDA handover
The traffic statistics of HSDPA is to be supplemented. HSDPA networks are not commercially
used in a large scale, so more cases will be supplemented.
The SHO ratio analysis will be supplemented after enough RNO experienced are collected.
7 Appendix

7.1 SRB&TRB Reset


7.1.1 RAB
RAB is the carrier at the subscriber plane. It is used in transmitting voice, data, and
multimedia services between UE and CN. The RAB assignment is originated by CN. It is a
function of RNC.
RB is ratio bearer between SRNC and UE. It includes layer 2 and above. It is the service
provided to layer 2.
7.1.1 shows the UMTS QoS structure. It provides the part that RAN and RB play in the
UMTS network.

1. UMTS QoS structure

7.1.2 SRB
The SRB carries the signaling at U-Net interface. The TRB carries the services at the Uu
interface and it is the radio bearer at the user plane.
7.1.2 shows the structure of SRB and TRB at the user plane.
2. SRB and TRB at
user panel

The SRB and TRB carriers signaling and services as blow:

SRB0 for all messages sent on CCCH (needless of configuration)


SRB1 for all messages sent on the DCCH that uses unconfirmed
RLC
SRB2 for all messages sent on the DCCH that uses confirmed RLC
(excluding initial direct transfer and uplink/downlink direct transfer)
SRB3/SRB4 for confirming downlink and uplink direct transfer
messages of RLC transferred on DCCH
TRB in the AM mode for carrying PS services
TRB in the UM mode for carrying CS services
The SRB reset involves the SRB in the AM mode. The AM mode uses the confirmation-
retransmission method. The sender will perform polling to check periodically that the receiver
has received the PDU with a method. After sending PDU, the sender sends a polling frame
and waits for the ACK frame from the receiver. If the waiting timer expires and the sender
fails to receive the ACK frame, it keeps sending PDU. If it still fails to receive the ACK frame
after sending for maximum retransmitting times, it triggers RLC AM entity reset or discards
the PDU to be sent. Discarding PCU is not configured now and only triggering RLC AM entity
occurs. This is the RB reset.
During RLC AM entity reset, the sender sends a RESET frame to the receiver and waits for
RESET ACK frame. If the timer expires, the sender will resend the frame. After sending for
maximum retransmission times, the sender will report "unreasonable error" to a high layer
and stop resending. SRB leads to triggering the release process at signaling plane. TRB
leads to triggering the release process at user.
7.2 RL FAILURE
When a cell sets up a new radio link, there is a process for uplink and downlink
synchronization. After UE succeeds in uplink synchronization, it powers on the transmitter,
and then the NodeB performs uplink synchronization. If the NodeB succeeds in
synchronization, it sends the RNC an RL RESTORE message. If it fails, it sends the RNC
the RL FAILURE message. When the RNC receives the RL FAILURE message or fails to
receive RL RESTORE message, it releases the resources related to the radio link. If the
active set uses only one radio link, the RNC then originates the release at signaling plane.

7.2 lists the timers and counters related to the synchronization and asynchronization.

1. Timers and
counters related
to the
synchronization
and
asynchronizatio
n

Paramete Paramete
Description
r ID r Name

T302 Timer 302 Value range: D100, D200, D400,


D600, D800, D1000, D1200,
D1400, D1600, D1800, D2000,
D3000, D4000, D6000, and D8000
Actual value range: 100, 200, 400,
600, 800, 1000, 1200, 1400, 1600,
1800, 2000, 3000, 4000, 6000, and
8000
Physical unit: ms
Content: When the UE sends CELL
UPDATE/URA UPDATE
messages, start timer T302. When
the UE receives CELL UPDATE
CONFIRM/URA UPDATE
CONFIRM messages, stop time
T302.
When T302 expires,
If V302 N302, the UE resends
CELL UPDATE/URA UPDATE
messages.
If not, the UE enters idle mode.
Recommended value: D2000

Value range: 07
Content: This parameter indicates
the maximum retransmission times
N302 Constant 302 of sending CELL UPDATE/URA
UPDATE messages. The default
value is 3.
Recommended value: 3

Value range: 115


Physical unit: s
Content: When the UE starts DCH,
start T312. When the UE detects
T312 Timer 312 312 continuous synchronization
indicators, stop T312. When T312
expires, the DCH connection fails.
The default value is 1.
Recommended value: 1

Value range: D1, D2, D4, D10,


D20, D50, D100, D200, D400,
D600, D800, and D1000
Actual value range: 1, 2, 4, 10, 20,
50, 100, 200, 400, 600, 800, and
1000
N312 Constant 312
Physical unit: none
Content: It indicates the maximum
times continuous synchronization
indicators received from L1. The
default value is 1.
Recommended value: D1

T313 Timer 313 Value range: 115


Physical unit: s
Content: When the UE detects from
L1 continuous N313
asynchronization indicators, start
T313. When the UE detects from
L1 continuous N315
asynchronization indicators, stop
T313. When T313 expires, the
radio link fails. The default value is
3.
Recommended value: 3

Value range: D1, D2, D4, D10,


D20, D50, D100, and D200
Actual value range: 1, 2, 4, 10, 20,
50, 100, and 200
Physical unit: none
N313 Constant 313
Content: It indicates the maximum
times continuous synchronization
indicators received from L1. The
default value is 20.
Recommended value: D50

T314 Timer 314 Value range: D0, D2, D4, D6, D8,
D12, D16, and D20
Actual value range: 0, 2, 4, 6, 8, 12,
16, and 20
Physical unit: none
Content: When the principle of
radio link failure is met, and the
radio bearer only related to T314
exists, start T314. When the cell
update is complete, stop T314. The
default value is 12.
When the UE of CELL_DCH fails
in radio links, start T314 (or T315),
and send CELL UPDATE
messages. Before T314 (or T315)
corresponding to services expires,
if the radio link reconfiguration
configured by CELL UPDATE
CONFIRM message fails, resend
CELL UPDATE messages to
reconfigure the radio link (related
to T302 and N302). Based on this,
configure T314 > T302 N302.
When T314 expires, the service RB
of corresponding timers is deleted.
Recommended value: D20

Value range: D0, D10, D30, D60,


D180, D600, D1200, and D1800
Actual value range: 0, 10, 30, 60,
180, 600, 1200, and 1800
Physical unit: s
Content: When the principle of
radio link failure is met, and the
radio bearer only related to T315
exists, start T315. When the cell
update is complete, stop T314. The
default value is 180.
When the UE of CELL_DCH fails
T315 Timer 315 in radio links, start T315 (or T314),
and send CELL UPDATE
messages. Before T315 (or T314)
corresponding to services expires,
if the radio link reconfiguration
configured by CELL UPDATE
CONFIRM message fails, resend
CELL UPDATE messages to
reconfigure the radio link (related
to T302 and N302). Based on this,
configure T315 > T302 N302.
When T315 expires, the service RB
of corresponding timers is deleted.
Recommended value: D30

N315 Constant 315 Value range: D1, D2, D4, D10,


D20, D50, D100, D200, D400,
D600, D800, and D1000
Actual value range: 1, 2, 4, 10, 20,
50, 100, 200, 400, 600, 800, and
1000
Physical unit: s
Content: It indicates the maximum
times continuous synchronization
indicators received from L1. The
default value is 1.
Recommended value: D1

7.2 lists the timers and counters related to call drop at lub interface.

1. Timers and
counters related
to call drop at
lub interface

Paramete Paramete
Description
r ID r Name

Value range: 1256


Actual value range: 1256
Physical unit: none
Content: The value indicates the
times of continuous
synchronization indicators needed
by the timer to trigger radio link
Times of continuous recovery process. The radio link
NINSYNCIND synchronization set keeps in initial state until the
indicator NodeB receives NINSYNCIND
continuous synchronization
indicator. Now the NodeB triggers
radio link recovery process, and
radio link set is synchronized.
When the radio link recovery
process is triggered, the radio link
set is in synchronization state.
Recommended value: 5

NOUTSYNCIND Times of continuous Value range: 1256


asynchronization
indicator
Actual value range: 1256
Physical unit: none
Content: The value indicates the times
of continuous asynchronization
indicators needed by the timer to
trigger radio link failure process. When
the radio link set keeps in
synchronization state, after the NodeB
receives NINSYNCIND continuous
failure indicators, start radio link failure
timer. After receiving continuous
NINSYNCIND synchronization
indicators, the NodeB must stop and
reset radio link failure timer. If the
radio link failure timer expires, the
NodeB triggers radio link failure
process, and indicate the radio link
sets which are in asynchronization
state.
Recommended value: 5

Value range: 0255


Actual value range: 025.5, and
the step is 0.1
Physical unit: s
Content: The value indicates the timer
period of radio link failure. When the
radio link set keeps in synchronization
state, after the NodeB receives
Radio link failure timer NINSYNCIND continuous failure
TRLFAILURE indicators, start radio link failure timer.
period
After receiving continuous
NINSYNCIND synchronization
indicators, the NodeB must stop and
reset radio link failure timer. If the
radio link failure timer expires, the
NodeB triggers radio link failure
process, and indicate the radio link
sets which are in asynchronization
state.
Recommended value: 50
7.3 SHO Flow
You can analyze SHO-related signaling flow by three typical flows. The three flows include
adding radio link, deleting radio link, and combination of adding and deleting radio links.
SHO is valid for FDD mode. The following three flows are SHO with lur signaling. The SHO
flow under the same RNC is simpler, which deletes the parts between SRNC and DRNC.
The following three cases are typical. The actual signaling flow depends on the actual
situation.

7.3.1 Analyzing Signaling Flow for Adding Radio Link


The conditions of SHO signaling flow for adding radio link are:

The UE has one or more radio links with SRNC.


The UE sets up a new radio link through new NodeB and new RNC.
The UE can set up only one link with UTRAN, so there is no macro diversity
combination/splitting.

Signaling Flow for Adding Radio


Link
7.3.1 shows the signaling flow for adding radio link.
1. Signaling flow for
adding radio link

Steps of Signaling Flow for Adding


Radio Link
The signaling flow proceeds as below:

The SRNC decides to set up a new radio link and the new cell to
which the link belongs is under the control of another RNC (DRNC).
The SRNC sends DRNC a Radio Link Setup Request message, and
requires DRNC to prepare the corresponding radio resources. The
new radio link is the first link set up between UE and DRNC, so a
new lur signaling connection is required. The lur signaling
connection carries UE-related RNSAP signaling.
The Radio Link Setup Request message includes parameters as below:

Cell ID

TFS

TFCS

Frequency

Uplink Scramble

According to radio resources, the DRNC judge whether the


requested radio resource can be met. If yes, the DRNC send the
NBAP message, namely, Radio Link Setup Request, to NodeB to
which the DRNC belongs. After this, the NodeB starts to receive
messages in uplink.
The Radio Link Setup Request message includes parameters as
below:
Cell ID

TFS

TFCS

Frequency

The NodeB allocates radio resources as required. If it succeeds, the


NodeB reports an NBAP message, namely, the Radio Link Setup
Response message, to DRNC.
The Radio Link Setup Response message includes two parameters:
signaling termination and transport layer addressing information
(AAL2 addressing, AAL2 bound ID for data transmission and
bearer)
The DRNC sends the Radio Link Setup Response message to SRNC
through RNSAP.
The Radio Link Setup Response message includes two parameters:
transport layer addressing information (AAL2 addressing, AAL2
bound ID for transmitting and carrying data) and information about
adjacent cells.
The SRNC starts lur/lub data transmission and bearer through the
ALCAP protocol. The request includes AAL2 bound ID for binding
lub data transmission and bearer, and DCH.
or 7) The NodeB and SRNC set up synchronization of data
transmission and bearer by exchanging the corresponding DCH FP
frame Downlink Synchronization and Uplink Synchronization. The
NodeB starts downlink transmission.
The SRNC sends UE the Active Set Update message on DCCH. The
message includes content on adding radio link.
The parameters include:
Update type

Cell ID

Downlink scramble

Power control information

Adjacent cells

The UE configures the corresponding parameters according to RRC


signaling. It sends SRNC the RRC message, namely, Active Set
Update Complete message.
7.3.2 Analyzing Signaling Flow for Deleting Radio Link
The conditions of SHO signaling flow for deleting radio link are:

The UE has one or more radio links with SRNC.


Delete the link connecting UE and SRNC through DRNC.

Signaling Flow for Deleting Radio


Link
7.3.2 shows the signaling flow for deleting radio link.
1. Signaling flow for
deleting radio link

Steps of Signaling Flow for Deleting


Radio Link
The signaling flow for deleting radio link proceeds as below:

The SRNC decides to delete a radio link. The SRNC sends UE the
Active Set Update message on DCCH. This message includes the
content about deleting radio link.
The parameters include update type and cell ID.
The UE deactivates the downlink receiver of radio link to be deleted
and sends SRNC the Active Set Update Complete message.
The SRNC sends the Radio Link Deletion Request to DRNC on
through.
The parameters include cell ID and transport layer addressing
information.
The DRNC sends NodeB the NBAP message, namely, the Radio
Link Deletion Request message. The NodeB stops receiving and
sending.
The parameters include cell ID and transport layer addressing
information.
The NodeB deactivates radio resources and sends DRNC the NBAP
message, namely, the Radio Link Deletion Response message.
The SRNC starts releasing lur/lub data bearer through the ALCAP
protocol.
7.3.3 Analyzing Signaling Flow for Adding and Deleting Radio Link
The conditions of SHO signaling flow for adding and deleting radio link are:

The UE has one or more radio links with SRNC.


The UE sets up a new radio link through new NodeB and new RNC.
Delete the previous link connecting UE and SRNC through the
NodeB which belongs to SRNC.
The UE can set up only one link with UTRAN, so there is no macro diversity
combination/splitting.

SHO Signaling Flow for Adding and


Deleting Radio Link
7.3.3 shows the SHO signaling flow for adding and deleting radio link.
1. SHO signaling flow
for adding and
deleting radio link

Steps of SHO signaling Flow for


Adding and Deleting Radio Link
The SHO signaling flow for adding and deleting radio link proceeds as below:

The SRNC decides to set up a new radio link and the new cell to
which the link belongs is under the control of another RNC (DRNC).
The SRNC sends DRNC a Radio Link Setup Request message, and
requires DRNC to prepare the corresponding radio resources. The
new radio link is the first link set up between UE and DRNC, so a
new lur signaling connection is required. The lur signaling
connection carries UE-related RNSAP signaling.
The Radio Link Setup Request message includes parameters as
below:
Cell ID

TFS

TFCS

Frequency

Uplink Scramble

According to radio resources, the DRNC judge whether the


requested radio resource can be met. If yes, the DRNC send the
NBAP message, namely, Radio Link Setup Request, to NodeB to
which the DRNC belongs. After this, the NodeB starts to receive
messages in uplink.
The Radio Link Setup Request message includes parameters as
below:
Cell ID

TFS

TFCS

Frequency

The NodeB allocates radio resources as required. If it succeeds, the


NodeB reports an NBAP message, namely, the Radio Link Setup
Response message, to DRNC.
The Radio Link Setup Response message includes two parameters:
signaling termination and transport layer addressing information
(AAL2 addressing, AAL2 bound ID for data transmission and
bearer)
The DRNC sends the Radio Link Setup Response message to SRNC
through RNSAP.
The Radio Link Setup Response message includes two parameters:
transport layer addressing information (AAL2 addressing, AAL2
bound ID for transmitting and carrying data) and information about
adjacent cells.
The SRNC starts lur/lub data transmission and bearer through the
ALCAP protocol. The request includes AAL2 bound ID for binding
lub data transmission and bearer, and DCH.
or 7) The NodeB and SRNC set up synchronization of data
transmission and bearer by exchanging the corresponding DCH FP
frame Downlink Synchronization and Uplink Synchronization. The
NodeB starts downlink transmission.
The SRNC sends UE the Active Set Update message on DCCH. The
message includes content on adding and removing radio link.
The parameters include:
Update type

Cell ID

Downlink scramble

Power control information

Adjacent cells

The UE configures the corresponding parameters according to RRC


signaling, deactivates the downlink receiver of the link to be deleted,
actives the downlink receiver to be added, and sends SRNC the
Active Set Update Complete message.
The SRNC sends NodeB the NBAP message, namely, the Radio
Link Deletion Request message. The NodeB stops receiving and
sending.
The parameters include cell ID and transport layer addressing
information.
The NodeB deactivates radio resources and sends SRNC the NBAP
message, namely, the Radio Link Deletion Response message.
The SRNC starts releasing lur/lub data bearer thought the ALCAP
protocol.
7.3.4 SHO Algorithm
Intra-frequency Measurement
Model
When the UE is in CELL_DCH connection mode (for example, voice talk starts), the RNC
sends the MEASUREMENT CONTROL command to command UE to measure and report
events (the event threshold, hysteresis, delay trigger time are included in signaling). When
the best cell is updated (including occurrence of intra-frequency HHO and inter-frequency
HHO), the measurement control of 1X (including 1A, 1B, 1C, and 1D) event must be
updated.
7.3.4 shows the WCDMA measurement model according to protocol 25.302.

1. Measurement model

In 7.3.4,

Point A is the direct measurement result of physical layer.


Point B is the filtered measurement result at physical layer and it is
also the measurement result provided to upper layer from physical
layer.
Point C is the measurement result for event judgment after upper
layer filtering.
FilterCoef is filtering factor of measured values and weights the
measurement results of physical layer at different points. It is used in
event report and period report. The filtering of measured values is
calculated as below:

Wherein,

Fn: filtered updated measurement result

Fn-1: filtered previous measurement result at last point

Mn: the latest measured value received from physical layer

= 1/2(k/2). The k is from Filter coefficient, namely, the handover parameter FilterCoef.
FilterCoef is configured in intra-frequency, inter-frequency, and inter-RAT handover
measurement. When is 1 (accordingly k = 0), there is no layer 3 filtering.
From previous measurement model, the filtering occurs before event judgment and
measurement report. In addition, the measured values in cell Measurement
results and Measurement results on RACH of UE's report are filtered. The layer 3 filtering
controlled by network layer caters for measurement event judgment and measurement report
only. The cell reselection when UE is in the idle mode and connection mode does not
support layer 3 filter controlled by network layer.

Intra-frequency Measurement
Events
In the measurement control message, the UTRAN indicates the events to trigger
measurement report. The intra-frequency measurement report events are marked by "1X".
1. 1A event: a Primary Pilot Channel Is in Reporting Range
In the measurement report mechanism domain, the network requires UE to report the 1A
event (for example, the UE enters the Cell_DCH state), the UE sends the measurement
report when a primary pilot channel enters the reporting range. According to protocols, for 1A
event, the UE can report multiple cells of trigger event in a measurement report. The cells
are included in the list of trigger event. The UE sorts the cells good to bad in terms of quality
(CPICH Ec/No). If less than 3 cells are listed in the active set, the network judges to add
links. If the active set is full of cells, no operation is performed.
When the measured value meets the following formula, the UE judges that a primary pilot
channel is in the reporting range.
The path loss is:

For other measurement values:

In the previous formulas:

MNew is the measurement result of cells in the reporting range.


Mi is the measurement result of cells in the active set.
NA is the number of cells in the active set.
MBest is the measured value of the best cell in the active set.
W is the weighting factor.
R is the reporting range, with signal strength as an example. It is
equal to the signal strength of the best cell in the active set minus a
value.
H1a is the hysteresis of 1A event.
A parameter TIME-TO-TRIGGER is used to reduce the signalling flow for measurement
report. After the primary pilot enters the reporting range and remains for a specified
period, the UE triggers measurement report. The parameter is also used in other events.
1 shows the 1A event and trigger delay.
1. Example 1A event
and trigger delay

Usually, if the 1A event is triggered, the UE sends a measure report to UTRAN. The UTRAN
sends an Active Set Update message for updating active set. Probably No response is
received after UE sends measurement report (for example, due to limited capacity). The UE
changes from sending event-triggered report to periodic report. The measure report contains
the information about the cells in the active set and cells in the monitored set in reporting
range. Only when the cell is successfully listed in the active set and leaves the reporting
range will UE stop sending periodic reports.
2. Periodic report
triggered by 1A event

2. 1B Event: a Primary Pilot Channel Leaves the Reporting


Range
When the following formulas are met, the UE judges that a primary pilot channel leaves the
reporting range. For 1B event and for event-triggered cells,

If more than one links are in the active set, the UE judges to delete
the links.
If only one links is in the active set, the UE performs no operation.
The path loss is:

For Other measure values:

In the previous formulas:

MOld is the measurement result of cells in the reporting range.


Mi is the measurement result of cells in the active set.
NA is the number of cells in the active set.
MBest is the measured value of the best cell in the active set.
W is the weighting factor.
R is the reporting range.
H1a is the hysteresis of 1B event.
If multiple cells meet the reporting conditions at the same time, and reach the trigger delay,
the UE sorts the cells in terms of measured value and then reports them.
3. 1C Event: a Non-active Set Primary Pilot Channel
3 shows the 1C event.

3. Example of 1C event

In 3, the cells where the PCPICH 1, PCPICH 2, and PCPICH 3 serve are in the active set but
the cell where PCPICH 4 serves is not in the active set. If the cells in the active set reach or
exceeds the replacement threshold of active set, the event is used for replacing bad cells in
the active set.
When the 1C event is triggered, the UE reports the replacing cell and the cell to be replaced
in the event trigger list. The UE also sort the reported cells good to bad in terms of quality
(CPICH Ec/No). After the RNC receives the 1C event trigger list reported by UE, it replaces
the cell to be replaced with the replacing cell in the active set.
4. 1D Event: the Best Cell Changes
4. Example 1D event

When channels have little difference, the 1D event might be triggered due to fluctuating
signals. This leads to unnecessary increase of signaling flow at the air interface. The
hysteresis value helps to avoid this, as shown in 4.

5. Restriction from
hysteresis to
measurement report

The second time fails to reach the hysteresis condition, so no 1D event report is triggered.
This parameter also applied in other events.
According to protocols, the 1D event can report only one triggered cell which can be in active
set or monitored set. Therefore the cells in the monitored set must be added to the active
set. If the active set is full, the system deletes a cell that is not the best cell. Consequently
the system adds the best cell to the active set. Finally the system marks the cell as the best
cell.
5. 1E Event: a Measured Value of Primary Pilot Channel
Exceeds the Absolute Threshold
5 shows an example of 1E event.

6. Example of 1E event

The 1E event triggers measurement report of the cells not monitored when the UE fails to
receive the neighbor cell table.
6. 1F Event: the Measured Value of Primary Pilot Channel
Is Lower than the Absolute Threshold Value
6 shows an example event.

7. Example of 1F event
7.4 Ordinary HHO Flow
7.4.1 Ordinary HHO (lur Interface and CELL_DCH State)
The following HHO flow is based on the lur interface when the UE is in the CELL_DCH state.

Ordinary HHO (lur Interface and


CELL_DCH State)
7.4.1 shows the ordinary HHO flow (lur interface and CELL_DCH state).
1. Ordinary HHO flow
(lur interface and
CELL_DCH state)

Signaling Flow Analysis


The signaling flow proceeds as below:

The SRNC sends the Radio Link Setup Request message to request
radio link setup.
The parameters include target RNC identity, s-RNTI, cell ID, TFS,
and TFCS.
The target RNC allocates RNTI and radio resources for RRC
connection and radio links. In addition, it sends the NBAP message,
namely, the Radio Link Setup Request message to the target NodeB.
The parameters include cell ID, TFS, TFCS, frequency, uplink
scramble, power control, and so on.
The target NodeB allocates radio link resources, starts physical-layer
receiver, and sends the target NodeB the Radio Link Setup Response
message.
The parameters include signaling termination and transport layer
addressing for lub data transmission and bearer.
The target RNC starts setting up lub data transmission and bearer
according to ALCAP protocol. The request contains that the AAL2
bound ID is for binding lub data transmission and bearer, as well as
transport channel DCH. The NodeB confirms the request.
When the target RNC completes preparations, it sends SRNC the
Radio Link Setup Response message.
The SRNC starts setting up lub data transmission and bearer
according to ALCAP protocol. The request contains that the AAL2
bound ID is for binding lub data transmission and bearer, as well as
transport channel DCH. The RNC confirms the request.
The SRNC send UE the Physical Channel Reconfiguration message.
When the UE switches from using the original link to using the new
one, the original NodeB detects that the original link fails in
synchronization. Then the original NodeB sends the NBAP message,
namely, the Radio Link Failure Indication message to the source
RNC.
The SRNC sends the original SRNC the RNSAP message, namely,
the Radio Link Failure Indication.
When the UE completes setting up RRC connection with target RNC
and the related radio resources are allocated, the UE sends SRNC the
RRC message, namely, the Physical Channel Reconfiguration
Complete message.
The SRNC sends source RNC the RNSAP message, the Radio Link
Deletion Request message. This requires the RNC to release the
corresponding resources used by original link.
The source RNC sends original NodeB the NBAP message, the
Radio Link Deletion Request message.
The parameters include cell ID and transport layer addressing
information.
The source NodeB releases radio resources used by original link and
sends source RNC the NBAP message, the Radio Link Deletion
Response message.
The source RNC starts releasing lur data transmission and bearer
according to the ALCAP protocol.
When the source RNC completes releasing lur data transmission and
bearer, it sends SRNC the RNSAP message, the Radio Link Deletion
Response message.
The SRNC starts releasing lur data transmission and bearer
according to the ALCAP protocol. The request includes AAL2 bound
ID for binding lur data transmission and bearer and the transport
channel DCH. The release request is confirmed by the target RNC.
7.4.2 Inter-CN HHO Flow
7.4.2 shows the inter-CN (between core networks) HHO flow.
1. Ordinary inter-CN
HHO flow

The ordinary inter-CN HHO flow proceeds as below:

or 2) The SRNC sends the Relocation required message to the nodes


of the source CN and the target CN.
or 4) After the CN makes necessary preparations, it sends the
Relocation Required message to the target RNC to allocating the
corresponding resources.
The transmission and bearer at the lur interface is set up at the target
RNC and CN.
or 7) or 8) The target RNC allocates RNTI and radio resources for
RRC connection and radio links, and then sends target NodeB the
NBAP message, the Radio Link Setup Request message. The target
NodeB allocates radio link resources starts physical layer receiver,
and sends target RNC the NBAP message, the Radio Link Setup
Response message.
The parameters include cell ID, TFS, TFCS, frequency, uplink
scramble, power control, and so on.
or 10) When the RNC completes preparations, the RNC sends CN
the Relocation Required Acknowledge message.
or 12) The CN completes preparations and sends SRNC the
Relocation Command message.
The SRNC sends UE the RRC message, the Physical Channel
Reconfiguration message.
or 15) or 16) When the target RNC detects UE, it sends two nodes of
CN the Relocation Detect message. When the UE switches from
using the original radio link to the new one, the source NodeB sends
source RNC the Radio Link Failure Indication message upon
detection of RL error by source NodeB.
When the UE completes setting up RRC connection with target RNC
and the corresponding radio resources are allocated, it sends target
RNC the RRC message, the Physical Channel Reconfiguration
Complete message.
or 19) After the UE succeeds in handing over to the target RNC and
is allocated with resources, the RNC sends all CNs the Relocation
Complete message.
or 21) The CN sends SRNC the Lu Release Command message.
The lu transmission and bearer between the original RNC and CN is
released.
or 24) The original RNC sends CN the Lu Release Complete
message for confirming release.
7.5 HHO Algorithm
7.5.1 Intra-frequency HHO Algorithm
The intra-frequency HHO occurs in the following two situations:

The intra-frequency neighbor cells belong to different RNCs, but no


lur interface is between the RNCs.
The handover of high-speed PS Best Effort service which exceeds
the speed threshold. The reason is that SHO takes excessive forward
capacity.
The 1D event is a judgment evidence for the intra-frequency HHO, namely, the triggering cell
of 1D event is the target cell for handover.

7.5.2 Inter-frequency HHO Algorithm

Fundamental Concepts
The cell at the carrier coverage edge refers to the cell covered by a carrier in the most
peripheral areas. The cell features that no intra-frequency neighbor cells are present in a
direction of the cell.
The cells in the carrier center area are the rest cells. The cell features that intra-frequency
neighbor cells are present in all directions of the cell.
In the cell at the carrier coverage edge, when the UE moves towards the direction with no
intra-frequency neighbor cells, the CPICH Ec/No fluctuates slowly due to the same
attenuating speed of CPICH RSCP and interference. According to simulation, when the
CPICH RSCP is lower than the demodulation threshold (110 dBm), the CPICH Ec/No can
reach about 12 dB. Now the inter-frequency handover algorithm based on CPICH Ec/No
measurement is invalid. Therefore, using CPICH RSCP as inter-frequency measurement
quantity is more proper and valid for cells at the carrier coverage edge.
The CPICH RSCP might serve as inter-frequency measurement quantity for cells in the
carrier center area, but the CPICH Ec/No is better to reflect the actual communication quality
of links and cell load.

Starting/Stopping Inter-frequency
Measurement
The inter-frequency measurement might use the compression mode which impacts the link
quality and system capacity, so starting the inter-frequency measurement is not
recommended. The inter-frequency measurement in only recommended if needed. Reporting
2D and 2F events determines starting/stopping inter-frequency measurement on V1.2 RNCs.
When the UE enters the CELL_DCH state or the best cell changes, if the inter-frequency
handover algorithm switch is enabled and the best cell is present in the list of inter-frequency
neighbor cells, the measurement of 2D and 2F events is configured. The absolute threshold
for 2D and 2F events is the staring/stopping inter-frequency measurement. The CPICH
Ec/No or RSCP measurement quantity and threshold is respectively used according to the
position property (as previously mentioned, there are carrier coverage center and carrier
coverage edge) of the best cell in the active set:
If the quality of measurement quantity is worse than the starting
threshold, the 2D event is reported and then the periodic inter-
frequency measurement is started through judgment.
If the quality of active set is higher than the stopping threshold, the
2F event is triggered and inter-frequency measurement is stopped.

Inter-frequency HHO Judgment


Now the inter-frequency measurement is reported periodically. The inter-frequency handover
judgment on RNCs uses the absolute threshold judgment method based on cell property.
According to the different cell properties (cell at the carrier coverage edge or in the carrier
coverage center), the handover judgment uses different physical measurement quantity
(CPICH RSCP and CPICH Ec/No) and handover threshold.
If the measurement quantity keeps greater than the absolute threshold and hysteresis until
trigger delay, the reported cell becomes the target handover cell. After this, according to the
inter-frequency measurement result, the RNC carries out inter-frequency HHO threshold.

Note:
No dedicated control strategy in compression mode is available, so it is
recommended that the inter-frequency handover caters for the compulsory
handover caused by in continuous coverage by carrier. Now you can only
consider starting compression mode at the carrier coverage edge. In the
carrier coverage center, forbid the compression mode from starting by
configuring parameters (set the absolute threshold of 2D event to the
minimum value) and forbid inter-frequency HHO.
7.6 Concept and Classification of HSDPA Handover
7.6.1 Concept of HSDPA Handover
For a subscriber, if an RAB is mapped on the HS-DSCH of a cell, the cell becomes the HS-
DSCH serving cell for the subscriber, and the radio link of the cell is the HS-DSCH serving
radio link.
As the signals of HSDPA serving cell are weaker and weaker, the network switches the
service to a HSDPA cell with better signals, namely, the update of HSDPA serving cell. For
the handover of HSDPA subscribers,HS-DSCH serving cell update describes HS-DSCH
handover, and handover describes DCH handover.
If other cells do not support HSDPA, the system switches the service to R99 cells. An RAB is
mapped on the HS-DSCH of a cell only, so SHO is unavailable on HS-PDSCH bearing
HSDPA, but available on associated DCH. The HS-PDSCH does not support SHO, so the
major impact on mobility management (MM) after use of HSDPA is as below:

How to select and change the serving cell of HS-DSCH


How to obtain best performance of data transmission.
Without violating the coverage handover rules, engineers must give priority to the HSDPA-
supported cells for a service. For example, if multiple radio links are present for SHO, and
only partial cells support HSDPA, the HSDPA service can be used in the non-superior cells. If
the subscriber only for service that is carried on HSDPA, the RNC enable the UE to camps
on HSDPA-supporting cell by direct retry and blind handover.

7.6.2 Classification of HSDPA Handover

By Different Handover Types on


Associated DPCH
According to different handover on the associated DPCH in HSDPA network, the HSDPA
handover includes the following types:

Update the serving cell of HS-PDSCH in active set


Update the serving cell of HS-PDSCH by SHO or softer handover on
DPCH
Update the serving cell of HS-PDSCH by HHO on DPCH

By Different Technologies Used in


Serving Cell before and after
Handover
By different technologies used in serving cell before and after handover, the HSDPA
handover includes the following types:

Handover in HSDPA system


Handover between HSDPA and R99
Handover between HSDPA and GRPS

By Location of Cells for HSDPA


Handover
By location of cells for HSDPA handover, the HSDPA handover includes the following types:

Handover under the same NodeB


Handover under different NodeBs of the same RNC
Handover under different RNCs
7.6.3 Signaling Flow and Message Analysis of HSDPA Handover
During mobility procedures of HSDPA, the UE is connected to a cell by HS-DSCH, so the
connection is different from DCH SHO. In CELL_DCH state, the move from source HS-
DSCH cell to target HS-DSCH cell is decided according to measurement reports of UE and
other information at network side.
A typical handover proceeds as below:

Measurement control
Measurement report
Handover judgment
Handover implementation
New measurement control
The serving cell update of HSDPA subscribers is with DCH handover.
When the serving cell is updated,

The DPCH configuration and active set remains;


Or the DPCH is set up, released, and reconfigured;
Or the active set upon SHO is updated.
At measurement control and measurement report stage, the handover messages for HSDPA
are similar to these of R99 and R4.
The signaling related to HSDPA in HSDPA handover includes:
During NBAP:

Radio Link Setup


Synchronized Radio Link Reconfiguration Preparation
Physical Shared Channel Reconfiguration
Synchronized Radio Link Reconfiguration Commit
Bearer Re-arrangement
Radio Link Parameter Update
At UU interface:

RADIO BEARER SETUP


RADIO BEARER RECONFIGURATION
RADIO BEARER RELEASE
TRANSPORT CHANNEL RECONFIGURATION
PHYSICAL CHANNEL RECONFIGURATION
7.6.4 HS-PDSCH Serving Cell Update due to DPCH SHO

Description
When the HS-PDSCH serving cell is updated due to DPCH SHO, the UE reports the
following events listed in 7.6.4. The system will respond accordingly.

1. Flow of serving
cell update
triggered by
different events
in SHO

Event Action

1D event, the best server is listed Change the radio link ID by reconfiguring
in active set radio link

Update the serving cell in active set, and


1B event, the HS-DSCH serving
perform DCH SHO to delete the cell
cell is to be deleted
corresponding to 1B event

1C event, the current HS-DSCH Update the HS-DSCH in active set to


serving cell is the worst cell in support the best server of HS-DSCH, and
active set then replace the cell

The best server to trigger 1D Perform DPCH SHO to add radio link, and
event is not listed in active set, update the HS-DSCH serving cell in active
and the active set is not full set

The best server to trigger 1D Perform DCH SHO to replace radio link,
event is not listed in active set, and update the serving cell in active set
and the active set is full. The
serving cell is not the worst cell

1D event, the active set is full,


Replace the second worst cell in active set,
the cell to be replaced is the
and update the serving cell
serving cell

HS-DSCH Serving Cell Update


(intra-NodeB) upon Fixed Active Set
of UE
7.6.4 shows the intra-NodeB synchronization serving cell update.

1. Intra-NodeB
synchronization
serving cell update

The update process is based on the following conditions:

The DPCH and active set are fixed.


Assume that the parameters like transport channel and radio bearer
are fixed.
The update does not involve MAC layer, so the entity of MAC-hs needs no reconfiguration.
The intra-NodeB synchronization serving cell is updated as below:

When the SRNC decides to update the HS-DSCH serving cell, it


sends DRNC the RADIO LINK RECONFIGURATION PREPARE
message. The message contains the identity of target HS-DSCH
serving cell.
The DRNC commands NodeB to perform synchronized radio link
reconfiguration. The NodeB must reconfigure the resource transition
from source HS-DSCH radio link to target HS-DSCH radio link. The
message contains the necessary information about setting up HS-
DSCH link in target HS-DSCH cell, like UE ID.
The serving NodeB sends the RADIO LINK RECONFIGURATION
READY message.
The DRNC sends SRNC the RADIO LINK RECONFIGURATION
READY message. The message contains the following information:
HS-SCCH set information

Scramble of target SCCH cell

UE ID of HS-DSCH

The SRNC sends DRNC the RADIO LINK RECONFIGURATION


COMMIT message. The message contains the activation time of
SRNC in CFN.
The DRNC sends the serving NodeB the RADIO LINK
RECONFIGURATION COMMIT message. The message contains
its activation time. At the activation time, the NodeB commands the
source HS-DSCH cell to stop sending HS-DSCH data to UE. The
target HS-DSCH cell sends UE the HS-DSCH data.
The SRNC sends UE the PHYSICAL CHANNEL
RECONFIGURATION message. The message contains the
following information:
Activation time

MAC-HS RESET indicator

Link ID of the serving HS-DSCH

HS-SCCH set indicator


UE ID of HS-DSCH

In the specified activation time, the UE resets HS-DSCH. It stops


receiving HS-DSCH data from the source HS-DSCH cell, and starts
receiving HS-DSCH data from target HS-DSCH cell. The UE
responds SRNC the PHYSICAL CHANNEL RECONFIGURATION
COMPLETE message.

HS-DSCH Serving Cell Update


(inter-NodeB) upon Fixed Active Set
of UE
7.6.4 shows the inter-NodeB synchronization serving cell update.

1. Inter-NodeB
synchronization
serving cell update

The update process is based on that the DPCH and active set are fixed.
The inter-NodeB synchronization serving cell is updated as below:

a) After SRNC decides to update HS-DSCH cell, it sends DRNC the


RADIO LINK RECONFIGURATION PREPARE message. The
message contains the identity of HS-DSCH target cell.
The DRNC sends the source NodeB the RADIO LINK
RECONFIGURATION PREPARE message.
The NodeB responds RADIO LINK RECONFIGURATION
READY message. The message contains the indicator of RESET
MAC-hs after reconfiguration.
The source NodeB responds the RADIO LINK
RECONFIGURATION PREPARE to the target NodeB. The message
indicates NodeB to perform synchronized radio link reconfiguration,
namely, to add resource to target HS-DSCH radio link. The message
contains necessary information to set up HS-DSCH resource in target
cell, like UE ID.
The target NodeB responds RADIO LINK RECONFIGURATION
READY message.
The DRNC responds RADIO LINK RECONFIGURATION READY
message to SRNC. The message contains the following information:
HS-SCCH set information

Scramble of target HS-SCCH cell

UE ID of HS-DSCH

After setting up the HS-DSCH transport bearer to the target NodeB,


the SRNC sends the RADIO LINK RECONFIGURATION
COMMIT to DRNC, including the activation time of SRNC in CRN.
The DRNC sends the RADIO LINK RECONFIGURATION
COMMIT message to the source NodeB and target NodeB. The
message contains its activation time. In the activation time, the
source NodeB stops and target NodeB starts sending HS-DSCH data.
The SRNC sends UE the PHYSICAL CHANNEL
RECONFIGURATION message to UE. The message contains the
following information:
Activation time

MAC-hs RESET indicator

Link ID of the serving HS-DSCH

HS-SCCH set indicator

UE ID of HS-DSCH

In the specified activation time, the UE resets MAC-hs. It stops


receiving the HS-DSCH data from the source HS-DSCH cell, and
starts receiving the data from target HS-DSCH cell. It responds the
PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message to SRNC. The HS-DSCH transport bearer to source NodeB
is released.
The signaling is in the attachment below (the corresponding RNC version is
V100R005C01B061):

DPCH SHO with HS-DSCH Serving


Cell Update
7.6.4 shows the inter-NodeB HS-DSCH cell update after radio link is added.
1. Inter-NodeB HS-
DSCH cell update
after radio link is
added

Setting a newly-added radio link to HS-DSCH radio link involves two steps:

Add a new link to active set


The HS-DSCH transmits to the new radio link
After radio link is added, the inter-NodeB HS-DSCH cell is updated as below:

The SRNC decides to add new radio link. The radio link will be the
HS-DSCH link. The SRNC sends DRNC the RADIO LINK
ADDITION REQUEST message. The message indicates DRNC to
set up a radio link without HS-DSCH resource.
The DRNC allocates resources for the new radio link. It sends the
RADIO LINK SETUP REQUEST message to the target NodeB. The
message contains the information to set up DPCH. It indicates the
target NodeB to set up new radio link.
The target NodeB allocates resources. It receives information at the
physical layer of the new DPCH. It responds the RADIO LINK
SETUP RESPONSE message.
The DRNC responds the RADIO LINK SETUP RESPONSE
message to SRNC. The DCH transport bearer is set up.
The SRNC sends UE the ACTIVE SET UPDATE message. The
message contains the new radio link ID.
The UE adds the new radio link to active set, and then responds the
ACTIVE SET UPDATE COMPLETE message to SRNC.
The SRNC sends the RADIO LINK RECONFIGURATION
REQUEST message to DRNC. The message indicates the target HS-
DSCH cell.
Assume that the target HS-DSCH and source HS-DSCH are
controlled by different NodeBs. The DRNC sends the RADIO LINK
RECONFIGURATION message to source NodeB. The message
indicates NodeB to perform synchronized radio link reconfiguration,
excluding the resource of original HS-DSCH radio link.
The source NodeB responds the RADIO LINK
RECONFIGURATION READY message to DRNC.
The DRNC sends the RADIO LINK RECONFIGURATION
REQUEST message to target NodeB. The message indicates target
NodeB to perform synchronized radio link reconfiguration to
allocate resources to target HS-DSCH link.
The target NodeB responds the RADIO LINK
RECONFIGURATION READY message.
The DRNC sends the RADIO LINK RECONFIGURATION
READY message to SRNC. The message contains the following
information:
HS-SCCH set information

Scramble of target HS-SCCH cell

UE ID of HS-DSCH
The HS-DSCH transport bearer to target NodeB is set up. The SRNC
sends the RADIO LINK RECONFIGURATION COMMIT message
to DRNC. The message contain the activation time in CFN.
The DRNC sends the RADIO LINK RECONFIGURATION
COMMIT message to the source NodeB and the target NodeB. In the
specified activation time, the source NodeB stops sending HS-DSCH
information to UE, and then the target NodeB starts sending HS-
DSCH information to the UE.
The SRNC sends the PHYSICAL CHANNEL
RECONFIGURATION message to UE. The message contains the
following information:
Activation time

MAC-hs RESET indicator

Link ID of the HS-DSCH

HS-SCCH code set

UE ID of HS-DSCH

In the specified time, the UE resets MAC-hs. It stops receiving HS-


DSCH data from source HS-DSCH cell, and starts receiving HS-
DSCH data from target HS-DSCH cell. The UE responds the
PHYSICAL CHANNEL RECONFIGURATION COMPLETE
message to SRNC. The transport bearer to source NodeB is released.
7.6.5 HS-PDSCH Serving Cell Update due to DPCH HHO

Description
The combination of HHO and HS-PDSCH serving cell update is simple. Namely, they occur
simultaneously.
The intra- and inter-NodeB HHO with serving cell update have the same process. New radio
link is set up in new cell with HS-DSCH. Consequently, the physical channel is reconfigured,
and old link is deleted.

Handover Flow
7.6.5 shows the inter-NodeB HS-DSCH cell update during HHO (single step method).
1. Inter-NodeB HS-
DSCH cell update
during HHO (single
step method)

The inter-NodeB HS-DSCH cell during HHO (single step method) is updated as below:

The SRNC decides to perform HHO and update HS-DSCH cell. It


sends the RADIO LINK SETUP REQUEST message to target
DRNC. The message indicates the target cell for HHO and the
information to set up HS-DSCH resource in target HS-DSCH cell.
The DRNC allocates resources for new radio link. It sends the
RADIO LINK SETUP REQUEST message to target NodeB. The
message contains the information to set up DPCH and that to set up
HS-DSCH.
The target NodeB allocates resources to set up DPCH link. It starts
receiving data from physical layer. It responds the RADIO LINK
SETUP RESPONSE message. The message contains the information
about HS-SCCH code set, and HS-DSCH flow control.
The DRNC responds the RADIO LINK SETUP RESPONSE
message to SRNC. The DCH and DSCH transport bearer is set up at
lub and lur interface. The message contains the following
information:
HS-SCCH code set

HS-DSCH flow control

UE ID

The SRNC sends UE the PHYSICAL CHANNEL


RECONFIGURATION message. The message contains the
following information:
Activation time

DPCH of target cell

MAC-hs RESET indicator

Link ID of the HS-DSCH

HS-SCCH code set

UE ID of HS-DSCH

In the specified time, the UE deletes the current active set, and sets
up DPCH link to target cell, RESET MAC-hs, and after it
synchronize with target cell at the physical layer, it starts receiving
and sending DPCH data, and receiving HS-DSCH data of target cell.
The UE responds the PHYSICAL CHANNEL
RECONFIGURATION COMPLETE message to SRNC.
The SRNC sends the RADIO LINK DELETION REQUEST
message to source DRNC. The message indicates the cell to be
deleted.
The target DRNC sends the RADIO LINK DELETION REQUEST
message to source NodeB.
The source NodeB releases original radio link resource, and responds
the RADIO LINK DELETION RESPONSE message to source
DRNC.
The source DRNC responds RADIO LINK DELETION RESPONSE
message to SRNC. The DCH and HS-DSCH transport bearer
resource to source NodeB are released.
7.6.6 DPCH Intra-frequency HHO with HS-DSCH Serving Cell Update
7.6.6 shows the signaling when DPCH intra-frequency HHO with HS-DSCH serving cell
update.
2. DPCH intra-
frequency HHO with
HS-DSCH serving
cell update

The flows for intra-frequency HHO and HS-PDSCH serving cell update are simple. They
occur simultaneously. After the UE reports 1D event, the physical channel reconfiguration
triggers the HHO of DPCH and HS-DSCH serving cell update.
The following attachment includes the signaling, according to V100R005C01B061).

7.6.7 DPCH Inter-frequency HHO with HS-DSCH Serving Cell Update


7.6.7 shows the DPCH inter-frequency HHO with HS-DSCH serving cell update.
3. DPCH inter-
frequency HHO with
HS-DSCH serving
cell update

In 7.6.7,

Message 98: the UE sends RNC the 2D measurement report.


Messages 99105: the UE and NodeB starts compression mode.
Messages 112143: the UE sends the measurement report. The report
meets the HHO threshold. The flow for physical channel
reconfiguration occurs. HHO is complete. The HS-PDSCH serving
cell is updated.
The following attachment contains the signaling, according to V100R005C01B061.

7.6.8 Handover Between HSDPA and R99

Description
When the UE moves from a HSDPA cell to an R99 cell, the service that is born on HS-DSCH
channel is remapped on DCH to guarantee the continuity of service. The HS-DSCH set in
HSDPA cell is deleted.
7.6.8 shows the handover from HSDPA to R99.

1. handover from
HSDPA to R99

The Case 1 is intra-frequency handover from R5 to R99. The Case 2 is inter-frequency


handover from R5 to R99.
When a UE moves from an R99 cell to a HSDPA cell, if the original DCH bears packet data
service, an HS-DSCH is set up in the link between UE and HSDPA cell, and the data service
is remapped on the new HS-DSCH. This helps provide more qualified services for data
services.
7.6.8 shows the intra-frequency handover from R99 to R5.

2. Intra-frequency
handover from R99 to
R5

The strategy for handover between HSDPA and R99 in V17 differs from that in V15 and V16.
If both an R99 cell and a HSDPA cell are available in the active set of the UE, the UE
decides that the service is borne over the HS-DSCH or over the DCH depending on whether
the best cell supports HSDPA or not.
In V17, four scenarios of handover between HSDPA and R99 exist as listed in 7.6.8.

1. Scenarios of
handover
between
HSDPA and
R99 (V17)

No
Scenario
.

If the UE moves to an R
cell from a HSDPA cell:
A 1D event occurs and t
new best cell does n
1
support HSDPA.
A 1B or 1C event occurs a
the new best cell does n
support HSDPA.

The UE moves to an R99 c


of another frequency from
2
HSDPA cell, then an inte
frequency HHO occurs.

The UE moves to a HSDP


cell from an R99 cell:
A 1D event occurs and t
new best cell suppo
3
HSDPA.
A 1B or 1C event occurs a
the new best cell suppo
HSDPA.

4 The UE moves to a HSDP


cell of another frequen
from an R99 cell, then
inter-frequency HHO occur
Intra-frequency SHO Between
HSDPA Cell and R99 Cell
7.6.8 shows DPCH SHO with handover from HSDPA to R99 (inter-NodeB).

1. DPCH SHO with


handover from
HSDPA to R99 (inter-
NodeB)

The meanings of messages shown in 7.6.8 are as below:


Message 19: the UE sends the 1A measurement report to RNC. The
report indicates that the signals from R99 cell are stronger than the
signals required by threshold. Therefore the R99 cell requires being
added to active set.
Messages 20, 21, and 22: the RNC sets up a radio link to NodeB.
Messages 2326: the RNC sends UE the active set update message,
and the associated DCH can receive the message in two RLs. After
the UE receives the message, it sends the active set update complete
message, which the RNC can receive in two RLs.
Messages 27 and 28: the network sends UE a new measurement
control message, updated measurement parameters, and neighbor
cell list.
Messages 29 and 30: the RNC informs NodeB of perform dedicated
measurement in new link.
Messages 31 and 32: the R99 cell is listed in active set, so the HS-
PDSCH parameters need changing. RL is reconfigured, and HS-
PDSCH parameters are changed.
Message 33: the physical channel is reconfigured, and physical
parameters of HSPDA are changed.
Message 40: the UE sends 1D measurement report, and the R99 cell
becomes the best server. Now the HS-PDSCH serving cell remains
the same.
Message 44: the UE sends 1B measurement report.
Message 50: the RB is reconfigured, and the service is reconfigured
from HS-PDSCH to DCH.
Messages 5660: the RL of original HS-PDSCH is deleted from
active set.
7.6.8 shows the DPCH SHO with handover from R99 to HSDPA.
2. DPCH SHO with
handover from R99 to
HSDPA

In 7.6.8, in the handover from R99 to R5 HSDPA, after the UE reports 1A event, it first adds
the RL of HS-PDSCH, and then reconfigures the service born on DCH to HS-PDSCH.
The following attachment contains the previous signaling, according to V100R005C01B061.
3. Inter-NodeB SHO
with handover from
HSDPA to R99 (V17)

In V17, the signaling flow for SHO from HSDPA to R99 is as follows:

The UE accesses a HSDPA cell.


The UE reports a 1A event of the R99 cell (message 18), and the R99 cell is added to the
active set.

The UE reports a 1D event of the R99 cell (message 26), and the R99 changes into the best
cell.

The RNC hands over the UE from the HSDPA cell to the R99 cell (message 34).
In V17, the signaling flow for SHO from R99 to HSDPA is similar to that for SHO from HSDPA
to R99:

The UE accesses an R99 cell.


The UE reports a 1A event of the HSDPA cell, and the HDSPA cell is added to the active set.

The UE reports a 1D event of the HDSPA cell, and the HSDPA cell changes into the best cell.

The RNC hands over the UE from the R99 cell to the HSDPA cell.
The following attachment contains the signaling for handover from HSDPA to R99, according
to V17C01B060.
Intra-frequency HHO Between HS-
PDSCH Cell and R99 Cell
7.6.8 shows the intra-frequency HHO with handover from R5 to R99 (intra-NodeB).

1. Intra-frequency HHO
with handover from
R5 to R99

The meanings of messages are as below:

Message 31: the UE reports 1A event, requiring network side to add


the link for R99 cell.
Message 32: the network side prohibits SHO and neglects 1A event.
The UE reports 1D event.
Message 35: after RB reconfiguration, the born service is configured
from HS-PDSCH to DCH of the current cell.
Messages 3944: R99 HHO occurs, the UE hands over to a new cell.
7.6.8 shows the intra-frequency HHO with handover form R99 to R5 (intra-NodeB).
2. Intra-frequency HHO
with handover form
R99 to R5

Intra-frequency HHO occurs on DPCH while the handover from R99 to R5 occurs. The intra-
frequency HHO of R99 occurs, and then the service is reconfigured from DCH to HS-PDSCH
in the new HSDPA cell.
The following attachment contains the signaling, according to V100R005C01B061.

3. Intra-frequency HHO
with handover from
R5 to R99 (V17)

In V17, the signaling flow for intra-frequency HHO from HSDPA to R99 is as follows:

The UE accesses a HSDPA cell.


The UE reports a 1A event of the R99 cell (messages 18 to 22). The RNC does not perform
any processing because the SHO is not supported.

The UE reports a 1D event of the R99 cell (message 23), and the R99 cell changes into the
best cell.

The RNC hands over the UE from the HSDPA cell to the R99 cell through HHO (line 34).
This step differs from that in the earlier versions. In earlier versions, the RNC re-allocates the
service from HSDPA to R99, and then hands over the service to another R99 cell through
intra-frequency HHO.
The signaling flow for intra-frequency HHO from R99 to HSDPA in V17 is the same as that in
the earlier versions.
The following attachment contains the preceding signaling, according to V17C01B060.

Inter-frequency HHO Between HS-


PDSCH and R99
7.6.8 shows the inter-frequency HHO from HS-PDSCH to DCH.
1. Inter-frequency HHO
from HS-PDSCH to
DCH

The meanings of previous messages are as below:

Message 20: the UE reports 2D measurement report to RNC.


Messages 2127: the UE and NodeB start compression mode.
Messages 2835: the UE sends measurement report.
Message 3666: the UE sends measurement report. The report
indicates that the inter-frequency HHO threshold is met. The UE
reconfigures the service to be born on R99 DCH in RB
reconfiguration, and then R99 HHO occurs.
7.6.8 shows the inter-frequency HHO from DCH to HS-PDSCH.

2. Inter-frequency HHO
from DCH to HS-
PDSCH

The meanings of previous message are as below:

Message 76: the UE sends 2D measurement report to RNC.


Messages 7783: the UE and NodeB starts compression mode.
Messages 8491: the UE sends measurement report.
Messages 92121: the UE sends measurement report, and the inter-
frequency HHO threshold is met. The inter-frequency HHO occurs.
The service is born on HS-DSCH in RB reconfiguration in target
cell, and the inter-frequency HHO from DCH to HS-PDSCH is
complete.
The following attachment contains the signaling, according to V100R005C01B061.

In the signaling flow for inter-frequency HHO from HSDPA to R99 in V17, only the HHO from
a HSDPA cell to an R99 cell differs from that in the earlier version. In earlier versions, the
RNC re-allocates the service from HSDPA to R99, and then hands over the service to
another R99 cell through intra-frequency HHO. In V17, the handover from the HSDPA cell to
the R99 cell completes in one step.
The signaling flow for inter-frequency HHO from R99 to HSDPA in V17 is the same as that in
the earlier versions.
The signaling is to be implemented.

7.6.9 Handover between HSDPA and GPRS


The handover between HSDPA and GPRS is similar to that of R99. For details, see the
Appendix 5.
7.6.9 shows the handover between HSDPA and GRPS.

3. Handover between
HSDPA and GPRS

7.6.10 Direct Retry of HSDPA


In V16, direct retry of HSDPA includes the following two types:

Inter-frequency direct retry of


HSDPA during setup of a service
When the R99 cells and HSDPA cells cover the same geographic area, the system allocates
all data services to the HS-DSCH of HSDPA cells. When the UEs originate to access the
network from R99 or HSDPA cells, it can share the HSDPA resource of HSDPA cells
however it is an R99 UE or a HSDPA UE. Thus, it can use resource better.

1. Flow for direct retry


during setup of a
service

Inter-frequency direct retry


triggered by 4A events
When an R99 cell and a HSDPA cell cover the same geographic area, the system allocates
the data traffic to the HS-DSCH of the HSDPA cell through direct retry if a 4A event occurs
due to increase of data traffic of the UE in the R99 cell.
In this case, the R99 cell shares HSDPA resources with the HSDPA cell. Thus, the resources
are better used.
1. Direct retry triggered
by traffic

In V17, the following types of inter-frequency direct retry of HSDPA are available:

Inter-frequency direct retry of HSDPA during setup of a service


Scenario 1
An R99 cell overlaps with an inter-frequency R5 cell with the same coverage. If the
UE that supports HSDPA originates a request for setup of a service that is fit for
HSDPA in the R99 cell, the service is sent to the R5 cell through direct retry during
RAB setup.

Scenario 2
An R5 cell has an inter-frequency R99 cell with the same coverage.
If the UE that supports HSDPA originates a request for setup of a service that HSDPA
cannot bear in the R5 cell, or the UE that does not support HSDPA originates a request
for setup of a service on HSDPA in the R5 cell, the request is sent to the R99 cell
through direct retry during RAB setup.

The service setup here must be the first service setup of the UE or the
existing services are over the FACH. Thus, the new service does not impact
the existing services.

Inter-frequency direct retry in the case admission rejection


Suppose an R5 has an inter-frequency R5 cell with the same coverage. The UE that
supports HSDPA originates a request for setup of a service that is fit for HSDPA or
originates an RAB reconfiguration request (channel type) in an R5 cell. If the request is
rejected by the local cell, the request is sent to the other R5 cell through an inter-
frequency direct retry.

Inter-frequency direct retry triggered by 4A events


The current service that is fit for the HS-DSCH is over the DCH for some reason (such as
admission rejection), the UE supports HSDPA but the best cell does not. An inter-
frequency R5 cell with the same coverage is available. In this case, the system re-
allocates the service from the DCH to the HS-DSCH in the inter-frequency R5 cell with
the same coverage if the data traffic of the UE increases (the RNC receives a 4A event
measurement report).

Inter-frequency direct retry triggered by a timer


The current service that is fit for the HS-DSCH is over the DCH for some reason (such as
admission rejection), the UE supports HSDPA but the best cell does not. An inter-
frequency R5 cell with the same coverage is available. In this case, the system re-
allocates the service from the DCH to the HS-DSCH in the inter-frequency R5 cell with
the same coverage if the channel type fit for service mapping has conflicted with the type
of the current serving channel for a period of time (as specified by the HSDPA direct retry
timer).
To set the expiry time of the timer, run the command SET
COIFTIMER:HRetryTimerLen=5000;.
The signaling is to be supplemented.

7.6.11 Switch of Channel Type


When the HSDPA is used, a new state appears compared with R99, the CELL_DCH state on
HS-DSCH.
The switch of channel type between HS-DSCH and FACH/DCH includes:

HS-DSCH <-> FACH


HS-DSCH <-> DCH
7.6.11 shows the switch of channel type.

2. Switch of channel
type

HS-DSCH <-> FACH


The UE with HSDPA channel uses DPCH resource of certain bandwidth. If all services of
HSDPA UE are BE services, the all service (including the service on DCH and HS-DSCH)
are without data transmission for a long time, the system triggers state transition to reduce
consumption of DPCH resource. Therefore, the UE transits from CELL_DCH (HS-DSCH)
state to CELL_FACH state.
Whereas, the data service is more active (the network receives the 4a event of service
measurement quantity), the UE is triggered to switch from CELL_FACH state to HS-DSCH.
The attachment below contains the signaling.

HS-DSCH <-> DCH


In V16, the handover between HS-DSCH and DCH might occur in any of the following cases:

One cause to handover between HS-DSCH and DCH is coverage.


This case includes that UE moves from an R99 cell to a HSDPA cell
or from a HSDPA cell to a R99 cell.
If the service set up by UE fits for HS-DSCH, the RNC triggers switch of channel type after
the HSDPA cell is added to actives set of UE. The RNC reallocate the data service to HS-
DSCH. This is due to mobility of UE.

D2H channel type switch triggered by traffic


Scenario 1: A 4A event triggers switch between D2H channel types in a cell.
The current service that is suitable for the HS-DSCH is over the DCH for some reason
(such as admission rejection). Both the UE and the best cell support HSDPA. The rate
of the service on the current DCH is lower than 384 Kbps. In this case, the system re-
allocates the service from the DCH to the HS-DSCH in the best cell if the data traffic
of the UE increases (the RNC receives a 4A event measurement report).

Scenario 2: A 4A event triggers D2H switch between two cells at different frequencies but
with the same coverage. See 7.6.10.
In V17, the switch between HS-DSCH and DCH might occur in any of the following cases:

The reason for handover between HS-DSCH and DCH is coverage.


This case includes that the UE moves from an R99 cell to a HSDPA
cell or from a HSDPA cell to a R99 cell.
D2H channel type switch triggered by traffic
Scenario 1: A 4A event triggers D2H channel type switch in a cell.
The current service that is fit for the HS-DSCH is over the DCH for some reason (such
as admission rejection). Both the UE and the best cell support HSDPA. The rate of the
service on the current DCH is lower than 384 Kbps. In this case, the system re-
allocates the service from the DCH to the HS-DSCH in the best cell if the data traffic
of the UE increases (the RNC receives a 4A event measurement report).

Scenario 2: A 4A event triggers D2H switch between two cells at different frequencies but
with the same coverage. See 7.6.10.

If the rate of service on the current DCH equals to 384 Kbps, no 4A event
occurs. In this case, a timer is needed to trigger the D2H switch.
The following attachment contains D2H switch signaling, according to V17C01B060:

D2H channel type switch triggered by a timer


Scenario 1: The timer triggers D2H switch in a cell.
The current service that is suitable for the HS-DSCH is over the DCH for some reason
(such as admission rejection). Both the UE and the best cell support HSDPA. In this
case, the system re-configures the service from the DCH to the HS-DSCH in the best
cell if the channel type fit for service mapping has conflicted with the type of the
current serving channel for a period of time (as specified by the HSDPA direct retry
timer).

Scenario 2: The timer triggers D2H switch in the case of inter-frequency direct retry. See
7.6.10.
To set the expiry time of the timer, run the command SET
COIFTIMER:HRetryTimerLen=5000;.
The following attachment contains signaling in the case that the timer triggers D2H switch in
a cell, according to V17C01B060:
7.7 Concept and Classification of HSUPA Handover
7.7.1 Basic Concepts
If the HSUPA is used, the following two types of links may coexist between a subscriber and
the network:

HSUPA link: Each UE can have only one HSUPA link with the
network. Different from the HSDPA, the HSUPA supports SHO. The
HSUPA handover requires management of the HSUPA serving cell.
DPCH link: The handover functions supported by the DPCH link are
the same as those supported by the R99 system, including SHO,
HHO, and handover between systems

HSUPA Serving Cell


The E-DCH active set has three types of RL:

Serving E-DCH Cell: The UE receives AG scheduling from the


serving E-DCH cell.
Serving E-DCH RLS: It refers to a cell set that contains at least the
serving E-DCH cell. The UE can receive serving RGCH from such
cells and perform softer combination. That is, the cells in the serving
E-DCH RLS and the serving E-DCH cell belong to the same NodeB.
Non-Serving RL: It means cells that belong to the E-DCH active set
but to the serving E-DCH RLS. The UE can receive RGCH from
these cells.
The UE can receive the AGCH message from only one cell. This cell is the serving cell of the
HSUPA. According to the protocol, the HSUPA serving cell and HSDPA serving cell for a
subscriber must be the same one. If the best cell in the active set changes due to changes of
the radio environment, the serving cell changes. That is, the serving cell is updated.

HSUPA Channel Selection Policy


If all cells in the active set support the HSUPA, the E-DCH bears the
uplink services. In other cases, the DCH bears the uplink services.
If all cells in the active set belong to the SRNC, the E-DCH bears the
uplink services. In other cases, the DCH bears the uplink services
(The lur interface in phase 1 of the product does not support the
HSUPA).
For these reasons, if a new cell added to the active set does not support the HSUPA or the
new cell belongs to the DRNC, the channel type changes from the E-DCH to the DCH. In
some cases, the channel type changes from the the DCH to the E-DCH.
7.7.2 Classification of HSUPA Handover
The HSUPA handover includes the following types:

Handover between two HSUPA cells


Handover between a HSUPA cell and a non-HSUPA cell
Handover between a HSUPA cell and a GSM/GPRS cell
7.7.3 Signaling Flow and Message Analysis of HSUPA Handover

Handover Between Two HSUPA Cells


The handover between two HSUPA cells includes three scenarios as listed in 7.7.3.

1. Handover
between two
HSUPA cells

No
Scenario
.

Intra-frequency SHO betw


two HSUPA cells
A 1A, 1B, 1C, or 1D e
1 occurs.
No non-HSUPA cell exist
the active set before and
the active set is updated.

Intra-frequency HHO betw


2 two HSUPA cells
A 1D event occurs.

3 Inter-frequency HHO betw


two HSUPA cells
A 2D event occurs and
compressed mode is enab
The handover also migh
triggered by a 2B event
periodic measurement repor
No
Scenario
.

Intra-frequency SHO Between Two


HSUPA Cells
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at the same
frequency. All cells in the active set support the HSUPA. Another HSUPA cell becomes the
best cell as the UE moves, so a 1D event occurs. The RNC updates the HSUPA serving cell,
and the HSUPA link of the UE is handed over to Cell 2 from Cell 1.

1. Intra-frequency SHO
between two HSUPA
cells

7.7.3 shows the related signaling.


2. Signaling for HSUPA
cell update triggered
by a 1D event

If the monitor set reports a 1D event, the HSUPA serving cell also is updated. For example,
the service is over the E-DCH in HSUPA 1 that works as the serving cell. The signals of
HSUPA 2 in the monitor set become stronger. In this case, the UE reports a 1D event and
the RNC adds HSUPA 2 to the active set. At last, the RNC updates the serving cell is
updated by re-configuring the physical channel. 7.7.3 shows the related signaling:
3. Signaling for HSUPA
cell update triggered
by a 1D event
(reported by the
monitor set)

Intra-frequency HHO Between Two


HSUPA Cells
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at the same
frequency. The signals of the current HSUPA serving cell (Cell 1) become weak and those of
Cell 2 become stronger as the UE moves. In this case, a 1D event occurs. The RNC re-
configures the physical channel to finish the intra-frequency HHO.
1. Intra-frequency HHO
between two HSUPA
cells

7.7.3 shows the related signaling:

2. Signaling for intra-


frequency HHO
between two HSUPA
cells

Inter-frequency HHO Between Two


HSUPA Cells
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at different
frequencies. The signals of the current HSUPA serving cell (Cell 1) become weak and those
of Cell 2 become stronger as the UE moves. In this case, a 2D event occurs. The UE starts
the compression mode and performs inter-frequency measurement. If the target cell meets
the handover requirements and the E-DCH allows the service setup, the RNC allocates the
UE from Cell 1 to Cell 2 by re-configuring the physical channel and sets up the HSUPA link of
the UE on the E-DCH of Cell 2.

1. Inter-frequency HHO
between two HSUPA
cells

7.7.3 shows the related signaling:


2. Signaling for inter-
frequency HHO
between two HSUPA
cells

Inter-RNC HSUPA Handover


HSUPA Phase 1 does not support HSUPA handover between lur interfaces. If a DRNC cell is
added to the active set, the service must be allocated to the DCH from the E-DCH. After the
migration, all cells in the active set belong to the SRNC. In this case, the service is allocated
to the E-DCH from the DCH, provided all cells in the active set support the HSUPA. 7.7.3
shows the inter-RNC HSUPA handover:
1. Inter-RNC HSUPA
handover

Handover Between a HSUPA Cell


and a Non-HSUPA Cell
In the initial stage of use of the HSUPA, usually it is hard to implement continuous coverage
of HSUPA cells. In this case, handover between a HSUPA cell and a non-HSUPA cell occurs
when the UE moves. The handover between a HSUPA cell and a non-HSUPA cell includes
six scenarios as listed in 7.7.3.

1. Handover
between a
HSUPA cell
and a non-
HSUPA cell

No
Scenario Rules
.

The RNC updates the active set


SHO from a HSUPA cell to based on the measurement
a non-HSUPA cell report, and then allocates the
1
A 1A, 1C, or 1D event service from the E-DCH to the
occurs. DCH through RB
reconfiguration.
Intra-frequency HHO from
a HSUPA cell to a non- The RNC allocates the service
2 HSUPA cell from the E-DCH to the DCH
through RB reconfiguration.
A 1D event occurs.

The UE reports a 2D event to


Inter-frequency HHO from start the compression mode and
a HSUPA cell to a non- perform inter-frequency
HSUPA cell measurement. If the target cell
meets the handover
3 A 2b event occurs. The requirements and its DCH
handover also might be allows service setup, the RNC
triggered by a periodic allocates the service from the E-
measurement report. DCH to the DCH through RB
reconfiguration.

The RNC updates the active set


based on the measurement
SHO from a non-HSUPA report. If all cells in the updated
cell to a HSUPA cell active set support the HSUPA,
4
the channel mapping policy
A 1B or 1C event occurs. determines whether the service
is allocated to the E-DCH
through RB reconfiguration.

The intra-frequency HHO of the


DCH is complete through
Intra-frequency HHO from reconfiguration of the physical
a non-HSUPA cell to a channel. If the target cell allows
5 HSUPA cell the HSUPA access, the RNC
A 1D event occurs. allocates the service to the E-
DCH through RB
reconfiguration.

6 Inter-frequency HHO from The UE reports a 2D event to


a non-HSUPA cell to a start the compression mode and
HSUPA cell perform inter-frequency
A 2b event occurs. The measurement. If the target cell
handover also might be meets the handover
triggered by a periodic requirements, the handover is
measurement report. complete through the following
two steps:
The intra-frequency HHO of the
DCH is complete through
reconfiguration of the physical
channel.
If the target cell allows the
HSUPA access, the RNC
allocates the service to the E-
DCH through RB
reconfiguration.

7.7.4 SHO from a HSUPA Cell to a Non-HSUPA Cell


Cell 2 and Cell 1 are adjacent cells at the same frequency. If signals of Cell 2 become strong
enough to trigger a 1A or 1C event as the UE moves, the RNC adds Cell 2 to the active set.
In this case, non-HSUPA cells exist in the active set. The RNC allocates the service from the
E-DCH to the DCH through RB reconfiguration according to the HSUPA channel selection
policy.

2. SHO from a HSUPA


cell to a non-HSUPA
cell

7.7.4 shows the handover signaling:


3. Addition of an R99
cell when the service
is on the E-DCH

Intra-frequency HHO from a HSUPA


Cell to a Non-HSUPA Cell
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at the same
frequency. If signals of Cell 2 become stronger as the UE moves, the UE reports a 1D event.
In this case, the RNC allocates the service to the DCH from the E-DCH through RB
reconfiguration (The intra-frequency HHO from a HSUPA cell to an R99 cell is complete in
one step).
1. Intra-frequency HHO
from a HSUPA cell to
a non-HSUPA cell

7.7.4 shows the related signaling:

2. Signaling for intra-


frequency HHO
from a HSUPA cell to
a non-HSUPA cell

Inter-frequency HHO from a HSUPA


Cell to a Non-HSUPA Cell
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at different
frequencies. If a 2D event occurs as the UE moves, the UE starts the compression mode
and performs the inter-frequency measurement. If the target cell meets the handover
requirements, the RNC hands over the UE from Cell 1 to Cell 2 (HHO) through RB
reconfiguration.

1. Inter-frequency HHO
from a HSUPA cell to
a non-HSUPA cell

7.7.4 shows the related signaling:


2. Signaling for inter-
frequency HHO
from a HSUPA cell to
a non-HSUPA cell

7.7.5 SHO from a Non-HSUPA Cell to a HSUPA Cell


The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at the same
frequency. The DPCH of Cell 1 bears the BE service of the UE. If signals of Cell 1 become
weak enough to trigger a 1B event as the UE moves, the UE reports the 1B event. In this
case, the RNC delete Cell 1 from the active set. All cells in the updated active set support the
HSUPA. If the service is fit for the E-DCH, the RNC allocates the service from the DCH to the
E-DCH through RB reconfiguration.
3. SHO from a non-
HSUPA cell to a
HSUPA cell

7.7.5 shows the related signaling:


4. SHO from a non-
HSUPA cell to a
HSUPA cell (triggered
by a 1B event)

Intra-frequency HHO from a Non-


HSUPA Cell to a HSUPA Cell
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at the same
frequency. If signals of Cell 2 become strong enough as the UE moves, the UE reports a 1D
event. At first, the intra-frequency HHO of the DCH is competed through reconfiguration of
the physical channel. The target cell then determines whether the service can be set up on
the E-DCH if the service is fit for the E-DCH. If the E-DCH of the target cell allows setup of
the service, the RNC allocates the service to the E-DCH through RB reconfiguration (The
intra-frequency HHO from an R99 cell to a HSUPA cell is complete through two steps: Carry
out intra-frequency HHO from a DCH to another DCH, and then perform RB reconfiguration
from the DCH to the E-DCH in the HSUPA cell).
1. Intra-frequency HHO
from a non-HSUPA
cell to a HSUPA cell

7.7.5 shows the related signaling:


2. Signaling for intra-
frequency HHO from
a non-HSUPA cell to a
HSUPA cell

Inter-frequency HHO from a Non-


HSUPA Cell to a HSUPA Cell
The UE moves from Cell 1 to Cell 2. Cell 2 and Cell 1 are adjacent cells at different
frequencies. The UE is connected to the DPCH of Cell 1. If signals of Cell 2 become strong
enough as the UE moves, a 2D event occurs and the UE starts the compression mode. If the
target cell meets the handover requirements, the inter-frequency HHO of the DCH is
complete. The target cell then determines whether the service can be set up on the E-DCH if
the service is fit for the E-DCH. If the E-DCH of the target cell allows setup of the service, the
RNC allocates the service to the E-DCH through RB reconfiguration.
1. Inter-frequency HHO
from a non-HSUPA
cell to a HSUPA cell

The signaling is to be supplemented.

7.7.6 Handover Between a HSUPA Cell and a GSM/GPRS Cell


The handover between different systems is caused by coverage or service. The use of the
HSUPA does not impact triggering conditions and decision of the handover between different
systems. Thus, the handover between a HSUPA cell and a GPRS cell is similar to that
between an R99 cell and a GPRS cell.
The signaling flow is as follows:

The UE starts the compression mode.


The UE measures the GPRS cell.
The RNC carries out handover from a HSUPA cell to a GPRS cell
based on the measurement report from the UE.
For details, see the related section earlier in this document.

7.7.7 Direct Retry of HSUPA


The direct retry of the HSUPA can balance load between an R99 cell and a HSUPA cell at
different frequencies or between different HSUPA cells. Direct retry of the HSUPA includes
the following three scenarios:

Direct retry from an R99 cell to a HSUPA cell


Direct retry from a HSUPA cell to an R99 cell
Direct retry from a HSUPA cell to another HSUPA cell
Direct Retry from an R99 Cell to a
HSUPA Cell
An R99 cell and a HSUPA cell are at different frequencies but with the same coverage. Direct
retry from an R99 cell to a HSUPA cell might occur in any of the following cases:

In the R99 cell, the UE originates a service that is fit for the E-DCH.
The traffic of the UE that is over the FACH in the R99 cell increases
and the service is fit for the E-DCH.
A service that should have been set up over the E-DCH according to
the service mapping rules is over the DCH of the R99 cell. The
system periodically checks the services that conflict with the bearer
policy and attempts to retry the services to the E-DCH.
The system periodic measurement uses the HSDPA retry timer (ms). The related MML
is SET COIFTIMER.

1. Direct retry from an


R99 cell to a HSUPA
cell

Direct Retry from a HSUPA Cell to


an R99 Cell
Direct retry from a HSUPA cell to an R99 cell might occur if the UE requests for setup of the
CS service in the HSUPA cell.
1. Direct retry from a
HSUPA cell to an R99
cell

Direct Retry from a HSUPA Cell to


another HSUPA Cell
Direct retry between two HSUPA cells at different frequencies but with the same coverage
might occur in any of the following cases:

The HSUPA UEs request for setup of the PS service is rejected by


the HSUPA cell.
The switch from the FACH to the E-DCH in the case of traffic
increase is rejected by the HSUPA cell.
The switch from the DCH to the E-DCH is rejected by the HSUPA
cell.

1. Direct retry from a


HSUPA cell to another
HSUPA cell

7.7.8 Switch between Channel Types


After the HSUPA is used, a channel state is added: the CELL_DCH state of the E-DCH. The
HSUPA related switch between channel types involves switch between the CELL_FACH and
the CELL_DCH (DCH).
The direct retry algorithm might trigger switch between the CELL_FACH and the CELL_DCH
(DCH). In addition, a timer for periodic measurement is available in the system. Once the
timer expires, the system checks whether the current bearer mode conflicts with the bearer
policy. If a conflict exists, the system triggers switch between channel types.
Traffic triggers switch between the CELL_DCH (E-DCH) and the CELL_FACH. Measurement
reports (4A) sent by the UE trigger switch from the CELL_FACH to the CELL_DCH. The
internal measurement of the RNC triggers switch from the CELL_DCH(E-DCH) and the
CELL_FACH (According to the current protocol, the UE measurement report does not
support measurement of the E-DCH).

2. Switch between
HSUPA channel types
7.8 Handover from WCDMA to GSM
If the UE performs inter-RAT handover for CS domain services, the flow for CS domain
handover from WCDMA to GSM is followed.

Description to Typical Handover


Flow from WCDMA to GSM
The typical handover flow includes stages as below:
Measurement control > measurement report > handover judgment > handover
implementation.

During the measurement control stage, the network informs UE of


parameters to be measured by sending the measurement control
message.
During the measurement report stage, the UE sends the measurement
control message to the network.
During the handover judgment stage, the network decides to
handover according measurement report.
During handover implementation, the UE and network follow the
signaling flow and respond according to signaling.
When dual-mode UE moves at the edge of WCDMA system and might perform inter-RAT
handover, the WCDMA RNC informs UE of starting inter-RAT measurement. After the UE
performs inter-frequency measurement and reports measurement result, the RNC judges
whether to start signaling flow for inter-frequency handover according to measurement
result.
The WCDMA system uses code division multiple access (CDMA) technology for access, so
the connected UE in all time works with a specified frequency. When the dual-mode UE
needs to perform inter-RAT measurement and keeps a conversation, it and the WCDMA
system might start compression mode (if the UE has a transceiver, the starting compression
mode is compulsory. If the UE has two transceivers, the UE can test GSM cells without
starting compression mode).

Flows of Handover from WCDMA to


GSM
7.8 shows the signaling flow for handover from WCDMA to GSM.
1. Signaling flow for
handover from
WCDMA to GSM

7.8 shows the tracing signaling of handover from WCDMA to GSM

2. Tracing signaling of
handover from
WCDMA to GSM

Signaling Flow at UTRAN Side


The signaling flow at UTRAN side proceeds as below:
When the UE moves outwards at the edge of a cell in the WCDMA
network and the conditions for report 2D event meet the RNC
configuration, the UE sends a measurement report of occurrence of
2D event. This report indicates that the signals at the serving
frequency in the WCDMA network are weak and other frequencies
or signals of other systems are required.
The RNC starts compression mode to perform inter-frequency and
inter-RAT measurement. The RNC sends the RL RECONFIG
PREPARE message to NodeB to prepare for starting compression
mode. The message contains the sampling sequence of compression
mode and related parameters of sampling sequence of compression
mode, including TGSN, TGL, TGD, TGPL, compression mode
method, downlink compression frame type, and power control
parameters in compression mode.
After the NodeB prepares resources, it sends the RL RECONFIG
READY message to the RNC.
The RNC sends PHYSICAL CHANNEL RECONFIG message to
UE and prepare for starting compression mode. This includes the
activation time, the sampling sequence of compression mode and
related parameters of sampling sequence of compression mode. The
parameters include TGCFN, TGMP, TGSN, TGL, TGD, TGPL, RPP,
ITP, compression mode method, downlink compression frame type,
and power control parameters in compression mode.
After the RNC confirmed that the UE has received the PHYSICAL
CHANNEL RECONFIG message, it sends NodeB the RL
RECONFIG COMMIT message, indicating the time for NodeB to
start compression mode.
After the UE completes related configuration according to new
configuration data, it sends RNC the PHYSICAL CHANNEL
RECONFIG COMPLETE message. Now the compression mode is
available.
The RNC immediately sends the measurement control message,
which commands UE to perform inter-RAT measurement. The
message includes measurement parameters like the list of GSM cells,
the information about frequency of cells, measurement filter
coefficient.
The UE sends a measurement report, indicating the RSSI
measurement value of GSM cells.
The UE sends a measurement report, indicating the BSCI
confirmation of GSM cells.
After the handover conditions are met according to judgment, the
RNC sends a SRNS relocation request to CN. The request includes
SRNS relocation type (the UE must participate in inter-RAT
handover), reason for SRNS relocation (usually relocation desirable
for radio reasons), source PLMN, source SAI, and target CGI
(including PLMN and LAC).
After the GSM side allocates related resources, the CN sends RNC
the RELOCATION COMMAND, which includes the IE layer 3
information. The IE contains the related resources allocated by GSM
network.
The RNC sends UE the HANDOVER FROM UTRAN COMMAND
message. The message includes the RAB ID, activation time, GSM
frequency, and GSM messages in forms of BIT string.
The UE powers off the transmitter according to GSM configuration,
so no signals are in uplink. Consequently the NodeB sends the SIR
ERROR report. This message is optional in the flow.
After the UE accesses the GSM network, the CN sends the IU
RELEASE COMMAND message to inform RNC of releasing
resources used by UE in the WCDMA network.
The RNC immediately sends CN the IU RELEASE COMPLETE
message. The message 16 and message 17 are to release the radio
resources of NodeB. What is different from normal releasing flow is
that the air interface does not send the RRC connection release
message, because the UE is using WCDMA network. Therefore the
NodeB releases radio resources without informing UE of the release.
7.9 Handover from GSM to WCDMA

Description of Handover from GSM


to WCDMA
If a GSM cell has WCDMA neighbor cells, the measurement control is sent in system
information. The dual-mode UE performs inter-RAT measurement in idle slots and reports
the measurement result. According to the measurement result, the BSC judges to start
signaling flow for inter-RAT handover. The GSM network uses the time division multiple
access technology, so the inter-RAT measurement is performed in idle slots. The GSM
system is not involved in supporting compression mode.

Flows of Handover from GSM to


WCDMA
7.9 shows the signaling flow for handover from GSM to WCDMA.

1. Signaling flow
for handover from
GSM to WCDMA

7.9 shows the tracing signaling of handover from GSM to WCDMA


2. Tracing signaling of
handover from GSM
to WCDMA

Signaling Flow at UTRAN Side


According to the handover algorithm and measurement information
of the source BSS in the GSM network, the source BSS judges that
UE must hand over to the UTRAN cell. After the BSS sends CN the
handover request, the MSC sends RNC the
RANAP_RELOCATION_REQUEST massage. The message
contains the IMSI of UE, CN field identity, the identity of target cell,
encryption information, integrity protection information, IU
signaling connection ID, handover reason, RAB configuration, and
information about user plane.
The RNC allocates radio resources for the SRNS relocation and
configures NodeB during RL SETUP process. The NodeB start
transmitting and receiving radio signals.
After the NodeB sets up RL, it replies the RL SETUP RESPONSE
message.
The RNC allocates radio resources and other parameter packets. The
parameter packets include U-RNTI, RAB, transport layer
information, and physical layer information. The parameters are
configured to UE in three forms:
Complete configuration: clearly provide parameters in each layer

Pre-configuration (pre-defined): the system broadcast multiple sets of parameter templates in


the system information 16 and configure template number and necessary parameter to UE.
The UE listens to the system information of UTRAN and obtain the parameter configuration
according to template number.

Pre-configuration (default): The protocol 25.331 provides 10 sets of default parameters and
specifies an identity to each default parameter. The RNC configures the default identity and
other necessary information to UE.

The RNC sends the previous information through the IU interface


RELOCATION REQUEST ACKNOWLEDGE message (in the IE
RNC Container) to CN which forwards the information to the source
BSS. The source BSS sends the information to UE. According to the
default parameter identity configured by RNC, the UE obtains
related access parameters in the pre-configuration (default) in the
system information. After this, the UE synchronizes to NodeB
directly and later sends data in uplink.
After the NodeB detects uplink synchronization, it sends RNC the
RL RESTORE IND message.
After the RNC receives RL RESTORE IND message sent by NodeB,
it sends CN the RELOCATION DETECT message, indicating that
the UE has already handed over from the 2G network to the 3G
network. The message does not contain other contents.
The UE sends RNC the HANDOVER TO UTRAN COMPLETE
message, indicating the completion of handover. The message might
also contain the encrypted sequence number and its activation time
for each CN field.
After the RNC receives the HANDOVER TO UTRAN COMPLETE
message from UE, it immediately sends UE the UTRAN
MOBILITY INFORMATION message. This message contains the
values of timers used by UE, related information about CN field, UE
ID, and so on.
After the RNC receives the HANDOVER TO UTRAN COMPLETE
message from UE, it sends UE the UTRAN MOBILITY
INFORMATION while it sends CN the RELOCATION
COMPLETE message which contains nothing. After the RNC
receives the confirmation message from UE according to the 17th
message, the handover flow from the 2G network to 3G network is
complete. The following messages are about the measurement
control process of UE and NodeB, and about the UE's query of
capacity.
7.10 Handover from WCDMA to GPRS

Description of Handover form


WCDMA to GRPS
The inter-RAT handover from WCDMA to GRPS caters for the handover from WCDMA PS
domain service to GPRS system. The RNC initiatively commands UE to reselect an inter-
RAT cell with signaling, which triggers inter-RAT handover. If the traffic flow for slow-speed
PS services, the UE might be in CELL PCH or URA PCH state, the UE can perform inter-
RAT handover by initiatively originating cell reselection according to system information.

Flows of Handover form WCDMA to


GRPS
The inter-RAT handover flow initiatively originated by RNC proceeds as below:
7.10 and 7.10 shows the flow for handover from WCDMA to GPRS.
1. Flow of handover
from WCDMA to
GPRS (1)

2. Flow of handover
from WCDMA to
GPRS (2)
7.10 shows the tracing signaling of handover from WCDMA to GPRS.

3. Tracing signaling of
handover from
WCDMA to GPRS

Signaling Flow at UTRAN Side


The signaling flow at UERAN side proceeds as blow:

The UE sends the measured 2D report, indicating the quality of the


serving cell is worse.
The RNC sends NodeB the RL RECONFIG PREPARE message,
indicating NodeB to prepare for starting compression mode. The
message contains the sampling sequence of compression mode and
related parameters of sampling sequence of compression mode,
including TGSN, TGL, TGD, TGPL, compression mode method,
downlink compression frame type, and power control parameters in
compression mode.
After the NodeB prepares resources, it sends RNC the RL
RECONFIG READY message.
The RNC sends UE the PHYSICAL CHANNEL RECONFIG
message, indicating UE to prepare for starting compression mode.
The message contains TGCFN, TGMP, TGSN, TGL, TGD, TGPL,
RPP, ITP, compression mode method, downlink compression frame
type, and power control parameters in compression mode.
After the RNC confirms that the UE has received the PHYSICAL
CHANNEL RECONFIG message, it sends NodeB the RL
RECONFIG COMMIT message, indicating the time for start
compression mode.
After the UE completes related configuration according to the new
configuration data, it sends RNC the PHYSICAL CHANNEL
RECONFIG COMPLETE message. This indicates that the
compression mode is ready.
The RNC immediately sends the measurement control and
commands UE to perform inter-RAT measurement. The message
contains the list of GSM cells, the information about frequency of
cells, measurement filter coefficient.
The UE sends a measurement report, indicating the RSSI
measurement value of GSM cells.
The UE sends a measurement report, indicating the BSCI
confirmation of GSM cells.
After the conditions are met according to judgment, the RNC
originates the SRNS relocation flow and sends UE the CELL
CHANGE ORDER FROM UTRAN message. The message indicates
UE to handover to the GPRS network by originating cell reselection.
The message contains the IEs of target cell like BSIC and BAND
IND (900 or 1800), BCCH ARFCN, and NC mode.
Because the UE need to reselect a GRPS cell, it powers off the
transmitter to WCDMA network. The NodeB sends the SIR ERROR
report, which is optional in the flow.
Because the UE need to reselect a GRPS cell, it powers off the
transmitter to WCDMA network. The NodeB sends the RL
FAILURE report, which is optional in the flow.
After the UE accesses the inter-RAT cell,
If restoring the PDP context is not required, the RNC directly receives the IU RELEASE
COMMAND at the IU interface.

If restoring the PDP context is required, the UE obtains the SRNS CONTEXT information
from the source RNC. The source RNC will receive the SRNS CONTEXT REQUEST
message with mainly an RAB ID.

The RNC sends CN the SRNC CONTEXT RESPONSE message,


indicating the GTP of each RAB ID and the uplink and downlink
sequence number of PDCP.
The CN sends RNC the SRNS DATA FORWARD COMMAND
message, indicating user plane to transmit data. By the message, the
CN informs RNC of target transport layer address and tunnel ID of
each RAB data forward.
After data is transmitted, the CN sends RNC the IU RELEASE
COMMAND message, indicating RNC to release the sources of the
UE.
The RNC sends CN the IU RELEASE COMPLETE message. The
message 18 and message 19 are to release the radio resources of
NodeB. What is different from normal releasing flow is that the air
interface does not send the RRC connection release message,
because the UE is using WCDMA network. Therefore the NodeB
releases radio resources without informing UE of the release.
7.11 Handover from GRPS to WCDMA

Signaling Flows of Handover from


GRPS to WCDMA
7.11 and 7.11 shows the signaling flow for handover from GPRS to WCDMA.

1. Signaling flow
for handover from
GPRS to WCDMA (1)
2. Signaling flow
for handover from
GPRS to WCDMA (2)

Signaling Flow at UTRAN Side


The signaling flow at UTRAN side proceeds as below:

The UE reselects a UTRAN cell. During the reselection of UTRAN


cell, the UE originates the RRC connection setup process, with the
reason INTERRAT CELLRESELECTION.
After the RNC connection is set up, the UE initiatively originates the
INIT DT process and sets up the SCCP connection at IU interface
and the signaling connection in the CN NAS layer. Later the UE
NAS layer and CN NAS layer exchange messages by DT process.
The CN commands the RNC to allocate related resources by sends
the RAB ASSIGNMENT REQUEST message at the IU interface.
The message contains the RAB ID, QoS, uplink and downlink
sequence number of GPT-U, and sequence number of PDCP.
The RNC allocates related resources and informs NodeB by sending
RL SETUP message.
The RNC sends UE the RB SETUP REQUEST message to UE. The
message contains the downlink sequence number of PDCP.
The UE sends RNC the RB SETUP COMPLETE message. The
message contains the downlink sequence number of PDCP. The RNC
configure the uplink sequence number of PDCP from CN and the
downlink sequence number from UE to the PDCP sample
corresponding to the specified RAB.
The RNC sends CN the RAB ASSIGNMENT RESPONSE message.
While the traffic flow is being restored, the RNC PDCP sample
should drop CN' data packet of which the sequence number of
downlink PDCP is smaller than the sequence number of downlink
PDCP replied by UE. The UE should drop the data packet of which
the sequence number of uplink PDCP is smaller than the sequence
number of uplink PDCP configured by UTRAN/CN.
7.12 Parameters of Handover from 3G to 2G Network

Handover Judgment Process


Now the periodic report is used in inter-frequency handover judgment.
According to the protocol 25.331, the 2D event indicates that the quality of active set is lower
than a threshold. In the current handover algorithms (including inter-frequency handover
algorithm), the 2D event report serves as a rule for starting compression mode and
performing inter-frequency or inter-RAT measurement. Therefore, if the quality of UE active
set is worse in inter-RAT measurement, you need to measure the inter-RAT quality only. If
the quality of UE active set becomes better, namely, the UTRAN receives the 2F event
report, the UE stops compression mode and stops inter-RAT measurement. For the detailed
judgment of 2D/2F event, see the 3GPP TS 25.331.
The following paragraphs describe the inter-RAT handover judgment algorithm using periodic
reports.
After the network receives the periodic report filtered by layer 3, it compares the obtained
inter-RAT measurement result with the preset threshold. The network starts delay trigger
timer Trigger-Timer if the following formula is met:
Mother_RAT + CIO >= Tother_RAT + H/2 (formula 1)
Wherein,

Mother_RAT indicates the obtained inter-RAT measurement result.


CIO indicates the cell individual offset, namely, the offset configured
by the inter-RAT cell.
Tother_RAT indicates the inter-RAT quality threshold.
H indicates hysteresis. The hysteresis helps to reduce mal-operations
due to fluctuation of signals.
After the Trigger-Timer starts and before it expires, the Trigger-Timer is stopped and the
network keeps waiting for receiving inter-RAT measurement report if the following condition
is met:
Mother_RAT + CIO < Tother_RAT - H/2 (formula 2)
If the Trigger-Timer expires, the system judges for inter-RAT handover.

List of Handover Parameters


7.12 lists the parameters of handover from 3G to 2G.
1. Parameters of
handover from
3G to 2G

M
M
L
C
o
m
m
a
n
d A
p
s
p
f l
P o i
a M r c
r e m a
a a Default o t
m n configuratio d i
e i n if o
t n y n
e g i
r n s
c
g
o
a p
n e
d
q
u
e
r
y
i
n
g

Filter For RNCs: inter- RNC/Cell


coefficient at RAT handover
FilterCoef layer 3 of D3 algorithm
inter-RAT parameter: set
measurement RNCs by
executing SET
INTERRATHO,
GsmRSSICSThd query RNCs by
The judgment executing LST
,
threshold for INTERRATHO.
GsmRSSIPSThd, 21, namely, 90 dBm
inter-RAT
GsmRSSISIGTh For cells: inter-
handover
d RAT handover
algorithm
parameter: add
HystThd Inter-RAT 4, namely, 2 dB cells by
handover executing ADD
hysteresis

The time to
TimeToTrigForV trigger delay
0, namely, 0s
erify verified by
inter-RAT

Non-verified 65535, namely, handover to


TimeToTrigForN CELLINTERRA
delay trigger non-verified GSM cell is
onVerify THO, query cells
time prohibited.
by executing
LST
CELLINTERRA
Inter-RAT THO, and
PenaltyTimeForS
handover 30, namely, 30s modify cells by
ysHo
penalty time executing MOD
CELLINTERRA

InterRatCSThdF For RNCs: set RNC/Cell


The
or2DRSCP, The default values of them are RNCs by
starting/stoppi
InterRatPSThdFo as below: executing SET
ng threshold
r2DRSCP, INTERFREQHO
for inter-RAT InterRatCSThdFor2DRSCPInte
InterRatSigThdF and query RNCs
measurement rRatPSThdFor2DRSCP: 95;
or2DRSCP, by executing
with RSCP as InterRatCSThdFor2FRSCPInte
InterRatCSThdF LST
the rRatPSThdFor2FRSCP: 90;
or2FRSCP, INTERFREQHO
measurement InterRatSigThdFor2DRSCP
InterRatPSThdFo .
value (CS, PS, InterRatSigThdFor2FRSCP:
r2FRSCP, For cells: add
and single 115
InterRatSigThdF cells by
signaling)
or2FRSCP executing ADD
CELLINTERFR
EQHO, query
InterRATCSThd cells by
The
FOR2DEcNo, executing LST
starting/stoppi
InterRATPSThdF CELLINTERFR
ng threshold
OR2DEcNo, EQHO, and
for inter-RAT
InterRATSigThd modify cells by
measurement
FOR2DEcNo , executing MOD
InterRATCSThd
with Ec/No as 24, namely, 24 dBm CELLINTERFR
the
For2FEcNo, EQHO
measurement
InterRATPSThdF
value (CS, PS,
OR2FEcNo,
and single
InterRATSigThd
signaling)
FOR2FEcNo

HYSTTHD Hysteresis. 4
The hysteresis
and inter-RAT
quality
threshold
decides
whether to
trigger inter-
RAT handover
judgment. It
can be smaller
in areas with
small shadow
fading. It can
be greater in
areas with
great shadow
fading.

The individual
offset of inter- Set cells by
RAT handover executing ADD
cells. The UE INTERRATNCE
uses it with the LL, query cells
initial by executing
CellIndividalOffs measured LST
0 Cell
et value of the INTERRATNCE
cell as the LL, and modify
measurement it by executing
result for MOD
handover INTERRATNCE
judgment of LL
UE.

Note:
7.12 lists the starting/stopping threshold of compression mode and inter-
RAT handover threshold in terms of signaling, CS, and PS.
The new protocol CR defines that the UE will not report the not verified
GSM measurement.
7.13 Data Configuration for Supporting Bi-directional
Roaming and Handover Between WCDMA and
GSM/GPRS
To support bidirectional roaming and handover between 3G networks and GSM/GPRS, to
support PLMN selection, to support reselection from the 2G network to the 3G network by
UE, and to support reselection from the 3G network to the 2G network by UE, data
configuration is necessary in the 2G and 3G system.

2G MSC Data Configuration


If the system support the handover from the 2G network to the 3G network, data
configuration on the 2G MSC is necessary. According to the 2G-to-3G interoperation strategy
of Huawei, the handover from the 2G network to the 3G network supports cell reselection, so
data configuration on the 2G MSC is unnecessary.

Data Configuration on the 2G MSC


Data configuration on the 2G MSC proceeds as below:

Add the matching record of 3G MSC/VLR code corresponding to


RNC IDs in the list of cell in the location area. The RNC ID is in the
format of: MCC + MNC + LAC + RNC-ID. Select GCI as the type
of location area. Select Near VLR area as the property of location
area.
Add the corresponding LAI record and the corresponding 3G
MSC/VLR code. LAI = MCC + MNC + LAC. Select Near VLR area
as the property of location area.
Change the supported MAP version to PHASE 2PLUS in the MAP
function flow configuration table.
Configure the data at the MTP layer and guarantee the signaling
transmission between the 2G MSC and the 3G MSC.
Configure the data at the SCCP layer, configure the corresponding
record of the 3G MSC in the GT list, SCCP SSN list, and SCCP DSP
list, and guarantee the transmission of MAP handover-related
signaling between MSCs.
Configure inter-MSC trunk data like configuring common data.
The following paragraphs take Huawei 2G MSC as example. For the MSC, two tables are
used for data configuration: location area cell table and neighbor cell table.

Location Area Cell Configuration Table


7.13 shows the data configuration of target 3G cell in the location area cell table.

1. Data configuration in
the location area cell
table

Pay attention to the following fields:

GCI code

Location area MSC code

Location area VLR code

Type of location area

Property of location area


Content of GCI code: corresponding to LAI and RNC ID of the target 3G cell for
handover. Query the LAI by running the command LST AC. Query the RNC ID by
running the command LST RNCBASIC. You can also obtain the PLMN code of the
RNC by running the command LST RNCBASIC.
Content of location area MSC code: the code of MSC configured by MSOFTX3000 of
the corresponding 3G network. Query it by running the command LST INFOMSC
command on the MSOFTX3000 client.
Type of location area: LAI + RNC ID correspond to GCI.
Property of location area: the configuration is Near VLR area.
Neighbor Cell Configuration Table
7.13 shows the data configuration of neighbor cell configuration table.

2. Data configuration of
neighbor cell
configuration table

Pay attention to the following fields:

GCI code

Neighbor cells

The GCI code of 2G source cell corresponding to GCI code.

Fill from the neighbor cell 1 to the neighbor 2. The content to be filled in the neighbor cell
1 is the LAI + RNC ID of target 3G cell for handover. Query the LAI of target 3G cell by
running the command LST AC. Query the RNC ID by running the command LST
RNCBASIC.

Added Data Configuration on BSCs


SI for Supporting the Roaming from GSM to WCDMA
To support the roaming from GSM to WCDMA, the GSM BSS must complete sending
the following system information:

Add data of WCDMA cells, including downlink frequency, primary scramble, diversity
indicator, MCC, MNC, LAC, RNC ID, and CELL ID.

Add the information about inter-RAT cell measurement and roaming control in the idle mode.
The information contains the following parameters:
Qsearch_I: the level threshold for searching for 2G cells in the idle mode
FDD_Qoffset: the level offset of 3G cell reselection
FDD_Qmin: the level threshold of 3G cell reselection

The previous information contained in the system information 2ter and 2quater is sent to UE.
The UE perform inter-RAT cell reselection based on previous information.

SI for Supporting the Handover from GSM to WCDMA


To support the handover from GSM to WCDMA, the GSM BSS must complete sending
the following system information:
Add the data of the WCDMA cell. The data contains:

Downlink frequency point

Primary scramble

Diversity indicator

MCC

MNC

LAC

RNC ID

CELL ID

Level threshold for handing over to the cell


Add the measurement control information of inter-RAT cells for UE in the connection
mode, including Qsearch_C, namely, the level threshold for searching for 3G cells in
the connection mode.
The previous information contained in the system information MEASUREMENT
INFORMATION is sent to UE.
When the level of UE in the serving cell meets the conditions for Qsearch_C, the
system starts measure 3G cells and sends the periodic reports to BSC.
The BSC originates the handover to WCDMA.
The following paragraphs take the configuration of Huawei BSC as example.

Adding External 3G Cells


Adding external 3G cells proceeds as below:

Select setting up cells dynamically

Add external cells

Add external 3G cells, as shown in 7.13.


1. Configuration table
for external 3G cells

Pay attention to several fields: MCC, MNC, LAI, RNC ID, CELL ID, downlink
frequency point, and scramble. Using system defaults is recommended for unlisted fields.

MCC: query it by running the command LST RNCBASIC on the corresponding RNC client

MNC: query it by running the command LST RNCBASIC on the corresponding RNC client

LAI: query it by running the command LST AC on the corresponding RNC client

RNC ID: query it by running the command LST RNCBASIC on the corresponding RNC
client

CELL ID: query it by running the command LST CELL on the corresponding RNC client

Note:
The query result is decimal. It can be filled in the CELL ID field after it is
converted to hex and removed of the highest bit.

Downlink frequency point: query it by running the command LST CELL on the
corresponding RNC client and then inputting the corresponding CELL ID in the CELL
Scramble: query it by running the command LST CELL on the corresponding RNC client
and then inputting the corresponding CELL ID in the CELL

Configuring Target 3G Cells as the Inter-RAT Neighbor Cell of GSM


Configuring target 3G cells as the inter-RAT neighbor cell of GSM proceeds as below:

Select setting cells dynamically


Modify the property of external cells

Select external cells

Modify the neighbor relationship, as shown in 7.13.

2. Configuration table
for GSM inter-RAT
neighbor cells

Note:
The target cell for handover from the 3G network can be the directional
neighbor cell of GSM only.

Configuring Parameters for 2G Reselection


Configuring parameters for 2G reselection proceeds as below:

Select setting cells dynamically

Select the current cell

Modify the parameters for inter-RAT system information, as shown in 7.13.


3. Configuration table
for 2G reselection
parameters

The configuration table for 3G system information includes the following parameters:

Type of measurement reports: common measurement reports

Number of best cells in the GSM band: the default value is 3

Threshold for searching for 3G cells in the idle mode: the values range from 0 to 15

Offset of FDD cell reselection: When the mean receiver level of 3G cells is FDD_Qoffset
greater than that of the serving cell, the UE can reselect 3G cells. 0 = (always select a cell
if acceptable), 1 = 28 dB, 2 = 24 dB, , 15 = 28 dB. Select 0 for easy handover.

The minimum Ec/No threshold for FDD cell reselect: level threshold for 3G cell reselection:
when the receiver level of 3G cell is greater than the FDD_Qmin, the cell can be a candidate
cell for reselection.

Other default values

Configuring 2G Handover Parameters


7.13 shows the parameter configuration table for inter-RAT handover.
4. Parameter
configuration table
for inter-RAT
handover

Pay attention to the following parameters:

Handout permission: select it.

Permission for handover algorithm of a 3G better cell: select it.

2G/3G cell handover priority selection: select 3G cell for handover as priority

2G cell selection threshold: the greater the threshold is, the difficult the handover to 2G is.
The recommended value is 63.
RSCP threshold for handover to a better 3G cell: the smaller the value is, the difficult the
handover to 3G is. The recommended value is 10.
Ec/No threshold for handover to a better 3G cell: the smaller the value is, the difficult the
handover to 3G is. The recommended value is 10.
Statistics time for a better 3G cell: the recommended value is 5.
The lasting time for handover to a better 3G cell: the smaller the value is, the easier and
faster the handover is. Pay attention to frequent handover. The recommended value is 4.

Added Data Configuration on 3G MSCs


Added data configuration proceeds as below:

Add the cell information about location area near the 2G MSC to the list of cells of 3G MSC
location area. LAI = MCC + MISSING NEIGHBOR CELL + LAC. Select LAI as the type of
location area. Select Near VLR area as the property of location area. Add the corresponding
2G MSC/VLR code. GCI = MCC + MNC + LAC + CI. Select GCI as the type of location
area. Select Near VLR area as the property of location area. Add the corresponding 2G
MSC/VLR code.

If inter-PLMN cell reselection is necessary, the MSC must configure the equivalent PLMN
list: ADD EPLMN, and add the inter-PLMN MCC and MNC. The equivalent PLMN is the
PLMN which provides equivalent services to subscribers. The network side decides whether
to tell the control list to UE. The MSC sends the list to UE upon update acceptance and the
UE saves it. When the UE reselects an inter-PLMN cell, it reselects a cell from the list by
priority.

Configure the data at MTP layer and guarantee the signaling transmission between the 2G
MSC and the 3G MSC.

Configure the data at SCCP layer. Configure the corresponding record of 2G MSC in the GT
table, SCCP SSN table, and SCCP DSP table.

Configure the trunk data between MSCs in the same way as configuring common data.

Necessary Data Configuration for RNC


Data Configuration for Supporting Roaming from WCDMA to GSM/GPRS
To support the roaming from WCDMA to GSM/GPRS, the UTRAN must complete
sending the following system information:

Add GSM cells and configuration the following data:


MCC
MISSING NEIGHBOR CELL
LAC
CELL ID
NCC
BCC
FREQ_BAND
Frequency number
CIO
ADD GSMCELL: MCC="460", MNC="10", LAC="0x0fa0", CID="0x0102",
NCC=0, BCC=0, BCCHARFCN=60, BANDIND=DCS1800_BAND_USED,
RATCELLTYPE=GSM;
ADD INTERRATNCELL: CELLID=123, MCC="460", MNC="10", LAC="0x0fa0",
CID="0x0102", CELLINDIVIDALOFFSET=50, QOFFSET1SN=-50,
QRXLEVMIN=-58;

Configure the measurement point for FACH to inter-frequency FDD measurement, inter-
frequency TDD measurement, or inter-RAT measurement. If inter-RAT roaming is necessary,
configure the measurement point for FACH to inter-RAT measurement; otherwise, according
to SIB11, the RNC will not send RNC information about GSM neighbor cells.
MOD CELLMEAS: CELLID=123, INTERFREQINTERRATMEASIND=INTER_RAT,
FACHMEASIND=REQUIRE, FACHMEASOCCACYCLELENCOEF=3;

Configure the SearchRAT of the GSM network by running the command MOD
CELLSELRESEL.
After configuration of these information, the SsearchRAT contained in SIB3 is sent and
information about GSM neighbor cells contained in SIB11 are sent.

Data Configuration for Supportint Inter-RAT Handover from


WCDMA to GSM
To support the inter-RAT handover from WCDMA to GSM, configure the following
parameters:

Add GSM cells and configuration the following data:


MCC
MISSING NEIGHBOR CELL
LAC
CELL ID
NCC
BCC
FREQ_BAND
Frequency number
CIO

Configure inter-RAT measurement control by running the command MOD CELLMEAS.

2011-04-11 All rights reserved Page 202 of 202

You might also like