UMTS QoS Monitoring Process

UMTS QoS Monitoring Process

LEGAL INFORMATION

By accepting this certain document of ZTE CORPORATIN you agree to the following terms. If you do
not agree to the following terms, please notice that you are not allowed to use this document.

Copyright © 2009 ZTE CORPORATION. Any rights not expressly granted herein are reserved. This
document contains proprietary information of ZTE CORPORATION. Any reproduction, transfer,
distribution, use or disclosure of this document or any portion of this document, in any form by any
means, without the prior written consent of ZTE CORPORATION is prohibited.

and are registered trademarks of ZTE CORPORATION. ZTE’s company name, logo
and product names referenced herein are either trademarks or registered trademarks of ZTE
CORPORATION. Other product and company names mentioned herein may be trademarks or trade
names of their respective owners. Without the prior written consent of ZTE CORPORATION or the
third party owner thereof, anyone’s access to this document should not be construed as granting, by
implication, estopped or otherwise, any license or right to use any marks appearing in the document.

The design of this product complies with requirements of environmental protection and personal
security. This product shall be stored, used or discarded in accordance with product manual, relevant
contract or laws and regulations in relevant country (countries).

This document is provided “as is” and “as available”. Information contained in this document is subject
to continuous update without further notice due to improvement and update of ZTE CORPORATION’s
products and technologies.

ZTE CORPORATION

Address: NO. 55
Hi-tech Road South
ShenZhen
P.R.China
518057
Website: http://support.zte.com.cn
Email: doc@zte.com.cn

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. I

 UMTS QoS Monitoring Process

Key Words:
KPI (key performance indicator), indicator definition, formula, KPI monitoring flow, KPI
optimization, KPI classification

Abstract:
This guide mainly describes the formulae, KPI classification, KPI monitoring methods and
flows, and KPI optimization methods.

Abbreviations
Abbreviation Full name
ATM Asynchronous Transfer Mode
CDR Call Drop Rate
CE Channel Element
CN Core Network
CPICH Common Pilot Channel
CQI Channel Quality Indicator
CQT Call Quality Test
DT Drive Test
E-DCH Enhanced uplink Dedicated Channel
HSDPA High Speed Downlink Packet Access
HS-DSCH High Speed Downlink Shared Channel
HS-SCCH High Speed Shared Control Channel
HSUPA High Speed Uplink Packet Access
ICMP Internet Control Message Protocol
IP Internet Protocols
IPoA Internet Protocols Over ATM
KPI Key Performance Index
LAN Local Area Network
MAC Media Access Control
Multimedia Broadcast and Multicast
MBMS
Service
NodeB Node B
OMC Operation & maintenance Centre
PDP Packet data protocol
PI Performance Index
PPP Point to Point Protocol
PS Packet-Switched domain

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. II

 UMTS QoS Monitoring Process

Abbreviation Full name

QoS Quality of Service
RAB Radio Access Bearer
RF Radio Frequency
RNC Radio Network Controller
RRC Radio Resource Control
RRU Radio Remote Unit
RSCP Received Signal Code Power
RTWP Received Total Wideband Power
SAAL Signaling ATM Adaptation Layer
SCCP Signaling Connection Control Part
SNR Signal to Noise Ratio
TB Transport Block
TCP Transfer Control Protocol
UDP User Datagram Protocol
UE User Equipment
VIP Very Important People
VP Video Phone
WAN Wide Area Network

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. III
 UMTS QoS Monitoring Process

About This Document

Summary
Chapter Description
1 Overview Brief introduction to KPI optimization
2 KPI Monitoring Process KPI monitoring process
3 KPI Analysis Methods Common KPI analysis methods, basic KPI analysis skills,
and general process for KPI optimization analysis
4 KPI Optimization Analysis KPI Optimization Analysis on CS call drops, PS call drops,
accessibility indicators, mobility indicators, and resource
indicators

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. IV

 UMTS QoS Monitoring Process

TABLE OF CONTENTS

1 Overview ......................................................................................................... 1

2 KPI Monitoring Process ................................................................................. 2

2.1 KPI Monitoring Process .................................................................................... 2
2.2 Routine KPI Monitoring Process ....................................................................... 3
2.3 KPI Monitoring Process During Parameter Modification .................................... 4
2.4 KPI Monitoring During RNC or NodeB Version Upgrade................................... 5
2.5 KPI Monitoring During Cutover ......................................................................... 6

3 KPI Analysis Methods .................................................................................... 6

3.1 KPI Analysis Methods ....................................................................................... 6
3.1.1 TOP N Worst Cells Method............................................................................... 7
3.2 Basic KPI Analysis Skills ................................................................................ 10
3.2.1 KPI Monitoring Tools ...................................................................................... 11
3.2.2 KPI Analysis Tools .......................................................................................... 11
3.3 General Process of KPI Optimization Analysis................................................ 12

4 KPI Optimization Analysis ........................................................................... 16

4.1 CS Call Drop Optimization .............................................................................. 16
4.1.1 Definition of Call Drop ..................................................................................... 16
4.1.2 CS Call Drop Analysis Flowchart .................................................................... 17
4.2 PS Call Drop Optimization .............................................................................. 19
4.2.1 Optimization Flowchart ................................................................................... 19
4.3 Optimization of Accessibility Indicators ........................................................... 21
4.3.1 Definition of Access Failure ............................................................................ 21
4.3.2 Analysis on RRC Connection Failures ............................................................ 22
4.3.3 Analysis on RAB/RB Setup Failures ............................................................... 27
4.4 Optimization of Mobility Indicators .................................................................. 35
4.4.1 Optimization of Soft Handovers ...................................................................... 35
4.4.2 Optimization of Hard Handovers ..................................................................... 41
4.4.3 Optimization of Inter-RAT Handovers ............................................................. 46
4.5 Optimization of Resource Indicators ............................................................... 49
4.5.1 Resource Indicator Optimization Flowchart..................................................... 51
4.5.2 Code Resource Optimization .......................................................................... 52
4.5.3 Monitoring CE Resource ................................................................................. 52
4.5.4 Optimization of Power Control ........................................................................ 53
4.5.5 Speeding up Rate Downgrade ........................................................................ 53
4.5.6 Monitoring and Optimizing Uplink Capacity..................................................... 53
4.5.7 Optimization of Uplink Capacity at the Whole Network Level .......................... 54
4.5.8 Optimization of Uplink Capacity for a Single Cell ............................................ 54

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. V

 UMTS QoS Monitoring Process

FIGURES

Figure 1-1 Joint KPI analysis................................................................................................ 1

Figure 2-1 Routine KPI monitoring process .......................................................................... 3
Figure 2-2 KPI monitoring process during parameter modification ....................................... 4
Figure 2-3 KPI monitoring workflow during RNC or NodeB version upgrade ........................ 5
Figure 3-1 RF configuration at HIC site ................................................................................ 8
Figure 3-2 Antenna energy distribution at HIC site ............................................................... 9
Figure 3-3 KPI optimization analysis process ..................................................................... 15
Figure 4-1 CS call drop analysis flowchart ......................................................................... 17
Figure 4-2 PS call drop optimization flowchart.................................................................... 19
Figure 4-3 Analysis flowchart of RRC connection setup failures ......................................... 24
Figure 4-4 Analysis flowchart of RAB setup failures ........................................................... 29
Figure 4-5 Soft handover optimization flowchart................................................................. 36
Figure 4-6 Hard handover optimization flowchart ............................................................... 43
Figure 4-7 Inter-RAT handover optimization flowchart........................................................ 48
Figure 4-8 Resource indicator optimization flowchart ......................................................... 51

TABLES

Table 3-1 List of CS TOP N Worst Cells............................................................................... 7

Table 3-2 Indicators Related with CS Call Drop ................................................................... 9
Table 4-1 Parameters That 2G Shall Provide to 3G ........................................................... 47
Table 4-2 Parameters That 3G Shall Provide to 2G ........................................................... 47
Table 4-3 Resource KPIs and Alarm Thresholds ................................................................ 50
Table 4-4 Adjusting Code Resource Allocation .................................................................. 52
Table 4-5 Example of Parameter Modification for Rate Downgrade ................................... 53
Table 4-6 Example of Power Control Parameter Modification ............................................ 54
Table 4-7 Example of Power Control Parameter Modification for Heavy-Traffic Cell .......... 54

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. VI

 UMTS QoS Monitoring Process

1 Overview
The radio network KPIs directly reflect the network quality, and KPI monitoring is an
important means to locate the faults. KPI monitoring and optimization are mostly
performed during the network operation and maintenance stage. Abnormal events are
supposed to be detected as early as possible and handled with proper solutions so that
sound voice and data services can be ensured for the subscribers.

At the beginning of the network construction, the optimization team should put more
emphasis on the RF adjustment rather than the optimization of KPIs except for CS call
drop rate, the PS call drop rate, and the RTWP indicator. During the network operation
and maintenance stage, KPI optimization (also called parameter optimization) plays the
main role, that is, the optimization team should optimize a certain indicator through
integrated parameter adjustment so as to meet the customer’s requirements.

KPI data comes from NetNumenT31, the network management system in the operation
and maintenance center (OMC). Based on the analysis on KPIs, the current states of
those indicators are learned and they are important reference for assessing the network
performance. The KPIs include the network service retaining capacity, accessibility,
mobility, system capacity, and so on. According to the current values of these indicators,
for example, some site has congestion, some site has a call drop rate of 10%, or some
RNC has a certain worst cell proportion, busy cell proportion, cell code resource
availability, access success rate, call delay and handover success rate, the optimization
team should judge and locate the area, scope and severity of the fault.

KPIs are divided into service KPIs and network KPIs by the statistic sources. Service
KPIs are collected through field drive tests (DTs) while network KPIs are collected from
the unified network management system. This article mainly discusses the analysis on
network KPIs. Usually, the final solution is made based on the joint analysis on the OMC
KPI data, alarms, subscribers’ complaints, and DT results.

Figure 1-1 Joint KPI analysis

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 1

 UMTS QoS Monitoring Process

2 KPI Monitoring Process

The purpose of KPI monitoring is to find out abnormal events that affect services as well
as subscribers’ perception and solve the problems as early as possible. For instance, if
the call drop rate at a certain site goes over 50%, we need to find the problem and work
out the solution in the earliest time.

As it is very urgent and important to locate KPI problems, we need a whole set of
scientific KPI monitoring mechanism and problem shooting process, as well as
appropriate monitoring tool and analysis tool to help us find the call drops caused by
transmission problems, resource congestion, cells service interruption, serious
interference, hardware fault with NodeB, wrong configuration of RNC parameters in time.

We classify KPI monitoring into four categories: routine KPI monitoring, KPI monitoring
during the process of parameter modification, KPI monitoring during the RNC or NodeB
version upgrade, and KPI monitoring during the process of cutover. Routine KPI
monitoring should be performed every day and be recorded in a KPI daily report, which
should involve the worst CS cell, the worst PS cell, the cell with the lowest RRC
connection rate, the cell with the most serious resource limit, and so on.

2.1 KPI Monitoring Process

KPI monitoring falls into four categories: routine KPI monitoring, KPI monitoring during
the process of parameter modification, KPI monitoring during the version upgrade of
RNC or NodeB, and KPI monitoring during the process of cutover. Each type of
monitoring has its own monitoring items and output form. For instance, the output of the
routine KPI monitoring should be a daily report, while the output of other KPI monitoring
types should be a KPI comparison report. Different types of KPI monitoring should have
different time granularities according to the requirement of problem location.

Routine KPI monitoring should be done persistently and be recorded in a daily report,
which should include a collection of the cells worst in different aspects, and be sent to
relevant person by email.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 2

 UMTS QoS Monitoring Process

2.2 Routine KPI Monitoring Process

Figure 2-1 Routine KPI monitoring process

EMS exports the

one-day
granularity of the
whole network

Screen out the

worst cells with
KPI tool

Output KPI daily

report in Excel

Send email in
fixed format to
relevant
personnel

Problem handling
Hand to the team classifies, Hand to
network collects and locates R&D dept.
optimization the worst cells or customer
personnel service dept.
Equipment/
Coverage problem version
problem
Classification
of the worst
cells

Parameter problem

Hand to the planning

personnel

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 3

 UMTS QoS Monitoring Process

2.3 KPI Monitoring Process During Parameter

Modification

Figure 2-2 KPI monitoring process during parameter modification

Old parameter
Yes
configuration

Rollback or
not?

Configure data
according to the
worksheet

Notify the person

in charge by mail
Network KPI
or phone
monitoring (15-
minute granularity)

Locate the worst

Whether the
cells, and check if
KPIs at the
they are caused No
RNC level are
by the parameter
No normal.
modification.

Yes

Keep on
monitoring (15-
minute granularity)

Output a report in
Word (hourly
granularity KPIs
before and after
the parameter
modification)

End

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 4

 UMTS QoS Monitoring Process

2.4 KPI Monitoring During RNC or NodeB Version

Upgrade

Figure 2-3 KPI monitoring workflow during RNC or NodeB version upgrade

Current version

Yes
No
Rollback or
not
Execute the
worksheet to
upgrade version

Send mail to or
call the person
in charge
Network KPI
monitoring
（15 minutes time
Locate the worst granularity）
cells. Determine
whether they are
related with the
version update.

No Whether the
RNC-level KPI
is normal

Yes

Keep on monitoring
(15 minutes
granularity)

Output formal Word report

(Compare the hourly
granularity KPIs before and
after the parameter
modification, and output the
result every hour.)

End

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 5

 UMTS QoS Monitoring Process

2.5 KPI Monitoring During Cutover

For the network on which the equipment needs to be replaced (for instance, HongKong
CSL network, for which we replaced Nokia’s equipment with ZTE’s), after the network
optimization is completed, the subscribers on the existing network should be cut over to
our network gradually. During the cutover, there will be subscribers registering on our
network constantly, which will cause load increase on the network. In this case, we
should watch KPI changes closely. The monitoring process, items, method and report are
the same as those described in section 2.4, “KPI Monitoring During RNC or NodeB
Version Upgrade.” Please read it for reference.

3 KPI Analysis Methods

3.1 KPI Analysis Methods

Different network problems require different performance analysis methods. Choose one
or more appropriate methods after learning the running state of the existing network and
the problems with it. Common analysis methods are as follows:

TOP N worst cells method: Based on the traffic statistics indicators we care about (such
as the call drop rate, connection rate, and soft handoff failure rate), choose N worst cells
whose average indicator values in the peak hours or of the whole day are the lowest as
the target of fault analysis and optimization. Or prioritize objects of optimization against
these indicator values.

Time tendency chart method: Tendency chart of indicator change is commonly used in
the traffic analysis. The analysis engineer can work out an hourly, daily or weekly
tendency chart of one or more indicators of the whole network, a cluster, or a single cell,
and find out the change rule of traffic statistics indicators.

Regional location method: The change of network performance indicators often occurs in
some regions. The indicators in these regions may be worsened by traffic increase, traffic
mode change, radio environment change, faults with a small number of stations, or
uplink/downlink interference, which will therefore affect the performance indicators of the
whole network. By comparing the network performance indicators before and after the
change, we can mark out the station or the sector with the greatest indicator change on
an electronic map, and take these problem regions as the analysis focus.

Comparison method: A single traffic statistics indicator may be affected by many factors.
While some factors change, others may not. Choose a proper object for comparison to
confirm the existence of problems, and then analyze the causes of the problems. When
examining an indicator, do not care whether the absolute indicator value is high or low
only, pay more attention to whether the value is high or low compared to other indicators
instead.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 6

 UMTS QoS Monitoring Process

3.1.1 TOP N Worst Cells Method

During the whole process of KPI optimization analysis, TOP N worst cells analysis
method is the most effective one, which can be used throughout the whole optimization
phase. By focusing on the TOP N worst cells, you can solve the major problems with the
network. Abnormal call drop events may happen every day, and these events may
represent problems of a kind. After solving the problems with TOP N cells, you can solve
the problems of the same kind. Therefore, focusing on TOP N cells is one of the most
effective ways to solve problems.

TOP N worst cells analysis method is applicable to the optimization analysis of all the
indicators. Choose TOP N worst cells according to a certain threshold, which varies
depending on different indicators. N stands for the number of the worst cells. When the
worst cells are too many to be worked on, the number of the worst cells can be
decreased so that you can focus on them. TOP N cells analysis method includes the
following steps:

Step 1: Screen out TOP N cells according to the condition of the indicators you care
about.

Step 2: Conduct a health check for TOP N cells. Check whether there are any problems
with transmission or boards, and check whether the worst cells are caused by external
abrupt incidents, such as terrible weather, gatherings, or holiday (because during
gatherings and holidays the traffic is usually heavy).

Step 3: Check the radio parameters configuration of these cells, the radius of these cells
and their neighboring cells, and compare them with the normal cells.

Step 4: Export the indicator relevant most closely with the indicators you care about and
analyze it to find the problem indirectly.

For instance, one day, CS call drop rate of a whole network was high. We analyzed the
problem by the TOP N cells analysis method.

Step 1: Screen out TOP N cells according to the condition of the indicators you care
about.

We used the CNO KPI analysis function to screen out TOP N cells (other tools can be
also used), and selected 10 cells with the highest CS call drop rate.

Table 3-1 List of CS TOP N Worst Cells

Call drop Number of call

Index Cell RNS subnet ID Cell ID
rate, CS AMR drop, voice
1 ZBL1U-AI-1 (201) 12911 41.58% 553
2 ZBL1U-AI-3 (201) 12913 39.55% 545
3 HKE1U-5H- (203) 30461 15.56% 370

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 7

 UMTS QoS Monitoring Process

Call drop Number of call

Index Cell RNS subnet ID Cell ID
rate, CS AMR drop, voice
1
HKE1U-5H-
4 (203) 30463 15.81% 360
3
LAK1U-9M-
5 (202) 11063 3.39% 282
3
6 HIC1U-9R-1 RNC101(101) 10891 2.26% 216
LAK1U-9M-
7 (202) 11061 2.49% 215
1
EBP1U-9R-
8 RNC101(101) 12823 2.30% 205
3
SRS1U-5H- RNC102-CSL(10
9 12091 3.92% 169
1 2)
HRM1U-6R- RNC102-CSL(10
10 20671 3.41% 167
1 2)

Step 2: Check the transmission and hardware of the TOP N cells and check whether they
are caused by external abrupt incidents, such as terrible whether, gatherings, or holidays
when traffic is usually heavy.

And then, we conducted a health check for each cell and paid attention to routine alarms
and BPC board problems. We found there were broken associations in some HKE sites.

Step 3: Check the radio parameters configuration of these cells, the radius of these cells
and their neighboring cells, and compare them with the normal cells.

(1)Problem with the cell radius: After the check, we found the cell radius of the LAK site
was 2.5 km. Because the LAK site was situated by the sea and the antenna was placed
very high, the radius of 2.5 km was far from enough. So we changed the cell radius to 10
km, and the problem of high call drop rate was thus solved.

(2)Problem with configuration: HIC site is an indoor POI site. The RRU RxTx port and the
RRU Rx port were configured reversely, which is the cause of high call drop rate. After
modifying HIC, we found that signals of the second RRU were received by the Rx port.
So we changed the configuration of the RxTx port and the Rx port, the problem of high
call drop rate was thus solved.

Figure 3-1 RF configuration at HIC site

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 8

 UMTS QoS Monitoring Process

Figure 3-2 Antenna energy distribution at HIC site

Step 4: Export the indicator relevant most closely with the indicators you care about and
analyze it to find the problem indirectly.

Table 3-2 Indicators Related with CS Call Drop

RAB release
RAB release RAB release
RAB release number for Iu
number for Iu number for Iu
number for Iu connection
connection connection
connection release
release request release Average
release request request by
by UTRAN for request by cell freq
Index Cell by UTRAN for UTRAN for
CS domain in UTRAN for RTWP
CS domain in CS domain in
cell, failure in CS domain in (dbm)
cell, radio cell, release
the radio cell,
connection due to
Interface unspecified
with UE lost overload
procedure failure
control
ZBL1U-
1 482 43 0 29 -104.177
AI-1
ZBL1U-
2 473 40 0 33 -104.125
AI-3
HKE1U-
3 346 16 0 8 -105.908
5H-1
HKE1U-
4 330 18 0 13 -106.0777
5H-3
LAK1U-
5 69 196 0 18 -103.1906
9M-3
6 HIC1U- 100 100 0 16 -101.5404

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 9

 UMTS QoS Monitoring Process

RAB release
RAB release RAB release
RAB release number for Iu
number for Iu number for Iu
number for Iu connection
connection connection
connection release
release request release Average
release request request by
by UTRAN for request by cell freq
Index Cell by UTRAN for UTRAN for
CS domain in UTRAN for RTWP
CS domain in CS domain in
cell, failure in CS domain in (dbm)
cell, radio cell, release
the radio cell,
connection due to
Interface unspecified
with UE lost overload
procedure failure
control
9R-1
LAK1U-
7 64 131 0 20 -103.1934
9M-1
EBP1U-
8 98 90 0 17 -101.413
9R-3
SRS1U-
9 87 59 0 22 -104.3528
5H-1
HRM1U
10 42 111 0 13 -102.7697
-6R-1

3.2 Basic KPI Analysis Skills

Be able to use the KPI statistics tool and the analysis tool

 Use tools to learn about the running state of the whole network quickly, and screen
out TOP N worst cells quickly.

 Use different analysis tools to find problems from different aspects and locate the
problem quickly.

 Understand the signaling process and basic principle

In the process of abnormity location, keep a clear aim in mind, and be able to apply the
process and basic principle to check the other relevant indicators rapidly to facilitate the
analysis.

Be familiar with the process and basic principle and be able to make logical association
between abnormal KPI problems and network problems (such as the coverage problem
and the interference problem). Be able to determine the problem nature according to the
abnormal KPI, and then choose the appropriate tool to analyze the problem in depth.

Performance analysis requires engineers to understand basic signaling process, be

familiar with the protocol stacks of standard interfaces, and know relevant algorithms to
realize the product functions. Engineers should at least have a concept about the various
algorithms. If the analysis of a commercial network involves some algorithms, engineers
should study these algorithms in depth.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 10

 UMTS QoS Monitoring Process

3.2.1 KPI Monitoring Tools

 Network management tool NetNumenT31: count KPI original data, alarm data,
radio parameter configuration in cells, and parameter configuration on the
earth.

 KPI daily report generating tool: classify key indicators according to a certain
condition, and screen out the worst cells.

3.2.2 KPI Analysis Tools

 CNO Tool: CNO tool has the KPI analysis function. So using it, you can screen
out the worst cells according to various conditions, and point out the
corresponding counter of an indicator.

 SignalTrace: Trace the signaling (RNL signaling and RNL signaling) of RNC
interfaces, which includes the Iu interface, the Iur interface, the Iub interface
and the Uu interface (the signaling flow between RNC and UE at RRC layer).
And RNL signaling trace is a common way for locating the KPI problem. Being
able to trace the RNC signaling is a basic requirement for the on-site KPI
optimization engineers and the network optimization and maintenance
engineers. This signaling tracing tool is very powerful, which can trace
signaling according to the UE cell and IMSI in the KPI analysis. According to
the UE cell, it can trace the signaling of multiple subscribers, while according to
IMSI, it can trace the signaling of only one subscriber. However, if the RRC
connection is not established yet, signaling cannot be traced. That is because
only when RRC connection has been established, can the RNC obtain the
subscriber’s IMSI from the CN.

 RNC ASS Log: ASS log is usually applied when there is abnormity and RNC
signaling is out of trace. In this case, use ASS log to analyze the signaling
before and after the abnormity occurs. Abnormity can be queried according to
IMSI or cell ID. ASS log can be also used to collect various abnormities.

 NodeB LMT: NodeB local operation and maintenance tool. Apart from all the
operation functions of the OMCB, this tool can collect more detailed
information about cells and UE. NodeB local maintenance terminals include:
EOMS, EFMS, DMS, and PMS.

 NodeB Abnormity Probe: On the site of WCDMA commercial office, NodeB

abnormity probe is an effective tool to monitor the running state of the NodeB.
Every module of NodeB can record the abnormal information automatically,
which makes it easy to locate problems. However this method requires
professional knowledge, such as knowledge about the function and interface of
each module or board. If the on-site engineers cannot make the simple
analysis, they can just obtain the abnormity probe and send it to the R&D
engineers at the rear side. The abnormities reported on the NodeB will be

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 11

 UMTS QoS Monitoring Process

stored at the OMCB server according to different RNCs. To conduct NodeB

abnormity probe analysis, you need to download abnormity probe files from
different OMCB servers and then use the abnormity probe tool to make a
comprehensive analysis.

 CTS Tool: CTS is a tool developed by the CN department, which can trace
signaling in depth according to IMSI, and trace signaling across RNCs. So this
is particularly suitable to trace VIP subscribers. In this case, CTS is easier to
use than SignalTrace, which can only trace signaling of RNCs one by one.
CTS can trace the interactive signaling between network elements (NEs) within
the CN, as well as the signaling of the Iu interface and the Uu interface. This
kind of signaling tracing is what we called in-depth tracing. The work principle
of CTS is to set up an IMSI task on the CTS server and send it to the CN front
side, which will then send this task to each CN module via the interfaces
dedicated to the CN modules and the RNC, and then each module, after
receiving the signaling related to the IMSI task, will send the signaling back to
the CTS server via the CN front side. The interfaces mentioned above are
private interfaces, so this tool can only support our own CN and RNC. CTS
signaling can be checked and analyzed with an offline tool, but the offline tool
does not work very well because of the lack of continuous optimization and
perfection.

 UE log: DT test is also an important auxiliary way in analyzing KPI indicators.

There are many problems that cannot be located by tracing signaling at the
network side, and can only be located by the use of UE log. The commonly
used drive test software includes: QXDM/APEX (QCAT), CNT/CAN and TEMS.
CNT/CAN and TEMS are often used for network optimization. For the use of
CNT/CAN, please refer to the corresponding help file and the instruction
document publicly released by the Network Optimization Tool Department.
QXDM and the analysis tool APEX (QCAT) provided by Qualcomm is very
powerful, which have contributed a lot for the stability and maturity of our
system for many years.

3.3 General Process of KPI Optimization Analysis

Basic analyzing ideas:

KPI optimization is a process to find and solve problems. KPI optimization during the
operation and maintenance stage is mainly to pick out the performance data that needs
special attention from the OMC, classify these performance data, and then compare the
value of these data with that required by the operator. If the value of an indicator is lower
than the operator’s requirement, analyze this indicator and find out the factor that affect
the indicator, and then propose a solution to the operator. If the values are higher than
the operator’s requirement, there’s no need to pay special attention to them.

KPI analysis is a process from the whole to the part.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 12

 UMTS QoS Monitoring Process

Step 1: Check the key indicators from the view of the whole network. If there is not any
problem, just ignore them. Otherwise, try to locate the RNC NE that has the problem.

Step 2: Analyze the indicators of the corresponding RNC to find out the RNC whose
indicators have the problem.

Step 3: Analyze the indicators of the cell under the problem RNC to find out the worst
cells or TOP N cells. If the indicators of all the cells under the RNC are tend to be low, it is
a common problem probably caused by parameter configuration. And then check
whether the radio parameter configuration in the cells under this RNC is the same as that
in the cells under the normal RNCs.

Step 4: Make a comprehensive analysis on the KPIs, alarms, DT test data, and customer
complains of the worst cells to find out a solution.

Analysis method:

After learning the KPI analysis ideas, we must know some common KPI analysis
methods to rule out causes of problems from the obvious ones to the hidden ones.

For example, we found that the TCP code words were strictly limited at eight sites near a
park, and the call drop rate rose suddenly. How to solve this problem?

Method one: First, we checked whether the alarms, transmission, and boards of these
sites were normal. After they are proved all normal, we sent some engineers to the site to
do test. And meanwhile, we traced the RNC signaling at the OMC. It turned out that the
test result was normal, and the indicators of these sites of that day did not have any
problem and code words were not limited. And later we knew from the news that there
was a big gathering of about one million people at the park at that moment. Until then we
came to know that the congestion was caused by too many users using the network at
the same time.

Method two: First, because the eight sites went worse all of a sudden, it was unlikely that
the problem lied in the hardware. Then we checked whether the radio parameters had
been modified the day before. The result is no worksheet had been issued to modify
those parameters, and no alarm was found at those sites. Therefore, we excluded the
possibility of hardware problem. Then we checked the traffic trend graph of the last few
days (over seven days) and found that the high call drop rate might be caused by high
traffic. The graph showed that traffic of each site rose suddenly on the day before. Thus
we came to the conclusion that this was an abnormal abrupt event, which may have been
caused by a gathering. And later we were told that there was a big gathering at the park.
So we were assured the code words limitation and high call drop rate at the eight sites
were caused by too many subscribers using the network at the same time.

By comparing the two methods above, we can find that although the first one (sending
engineers to the site, without the consideration of abnormal events) is commonly used, it
is inefficient and costs more resource. The second method (analyzing the problem by the
means of exclusion and association) is more efficient. From this case, we would like to

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 13

 UMTS QoS Monitoring Process

emphasize that KPI analysis is a process of problem exclusion. Using the comprehensive
methods (like Method One) at the first brush may be making a detour.

 Exclusion method: Check the alarms on the OMC to learn about the state of
the RNC, NodeB, BPC board, and the transmission. If there are obvious
broken link in transmission or hardware problem, the cause of the problem is
easy to locate.

 Incident association: If the problem is with a great number of sites, take abrupt
incidents into account, such as large-scale gathering, terrible weather of
incorrect operation. These incidents will put influence of different levels and
ranges on the network indicators.

 Comparison of radio parameters: If some site goes wrong in a sudden, check

whether the radio parameter configuration of this site is consistent with that of
other normal sites. If not, change it as that of the normal sites, because the
indicator decrease may be caused by an incorrect modification of radio
parameters.

 Relevant indicators association: If a certain indicator is in poor condition, check

its relevant indicators and find the common problem from these relevant
indicators.

 Comprehensive problem location: When the above reasons are excluded, use
DT data, KPI data, RNC signaling analysis data to locate the problem with
indicators comprehensively.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 14

 UMTS QoS Monitoring Process

Figure 3-3 KPI optimization analysis process

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 15

 UMTS QoS Monitoring Process

4 KPI Optimization Analysis

This chapter mainly demonstrates how to analyze the indicator problems from the aspect
of OMC data, and provides flowcharts for KPI optimization. The detailed analyzing
method and cases of every special subject can be checked in the optimization guides of
all the subjects.

4.1 CS Call Drop Optimization

The CS call drop rate is the most important indicator in KPI optimization.

4.1.1 Definition of Call Drop

After checking the signaling on the Uu interface at the UE side, the engineer can judge
the situation a call drop if the Uu interface message satisfies one of the following three
conditions during the calling process (in connection).

RNC Release is not received, but the UE condition changes from CELL_DCH to IDLE.

RRC Release is received and the released cause value is Not Normal.

One of the following three messages — CC Disconnect, CC Release Complete, and CC

Release — is received, and the released cause value is Not Normal Clearing or Not
Normal, Unspecified.

In a board sense, the call drop includes the call drop rates of CN and UTRAN. The call
drop of UTRAN includes the following two aspects:

After the successful service establishment, RNC sends the RAB Release Request to CN.

After the successful service establishment, RNC sends the IU Release Request to CN.
Later, RNC receives the IU Release Command from CN.

Note that RAN call drop statistics, which is defined from the aspect of lu interface
signaling, means the launching times of RAB Release Request and lu Release Request
of RNC. And the DT call drop statistics is defined from the aspects of the Uu interface
message, non-access stratum message and cause value. RAN call drop statistics and
DT call drop statistics are not exactly the same.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 16

 UMTS QoS Monitoring Process

4.1.2 CS Call Drop Analysis Flowchart

Figure 4-1 CS call drop analysis flowchart

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 17

 UMTS QoS Monitoring Process

Counter list：
C310271752 Number of RNC initiate RAB release by for CS-Speech by uesr inactive
C310271753 Number of RNC initiate RAB release by for CS-Speech by repeat integrity check
C310271754 Number of RNC initiate RAB release by for CS-Speech by UE initiate release
C310271755 Number of RNC initiate RAB release by for CS-Speech by lost UE connection
Number of RNC initiate RAB release by for CS-Speech by relocation complete timer
C310271756
exceed
C310271757 Number of RNC initiate RAB release by for CS-Speech by radio interface fail
C310271765 Number of RNC initiate RAB release by for CS-Speech by OMC intervention
C310271766 Number of RNC initiate RAB release by for CS-Speech by overload control
C310271767 Number of RNC initiate RAB release by for CS-Speech by RAB pre-empty
C310271768 Number of RNC initiate RAB release by for CS-Speech by IUUP fail
C310271769 Number of RNC initiate RAB release by for CS-Speech by UTRAN generating
C310271770 Number of RNC initiate RAB release by for CS-Speech by unspecific fail

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 18

 UMTS QoS Monitoring Process

4.2 PS Call Drop Optimization

4.2.1 Optimization Flowchart

Figure 4-2 PS call drop optimization flowchart

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 19

 UMTS QoS Monitoring Process

Counters：
Number of RNC initiate release for PS-R99 with standerd failure causes
C310261591 Number of RNC initiate release for PS-R99 by uesr inactive
C310261592 Number of RNC initiate release for PS-R99 by repeat integrity check
C310261593 Number of RNC initiate release for PS-R99 by UE initiate release
C310261594 Number of RNC initiate release for PS-R99 by lost UE connection
C310261595 Number of RNC initiate release for PS-R99 by relocation complete timer exceed
C310261596 Number of RNC initiate release for PS-R99 by radio interface fail
C310261604 Number of RNC initiate release for PS-R99 by OMC intervention
C310261605 Number of RNC initiate release for PS-R99 by overload control
C310261606 Number of RNC initiate release for PS-R99 by RAB pre-empty
C310261607 Number of RNC initiate release for PS-R99 by IUUP fail
C310261608 Number of RNC initiate release for PS-R99 by UTRAN generating
C310261609 Number of RNC initiate release for PS-R99 by unspecific fail
Number of RNC initiate RAB release by release request for PS-HSDPA with standerd Failure causes
C310281889 Number of RNC initiate RAB release by release request for PS-HSDPA by uesr inactive
C310281890 Number of RNC initiate RAB release by release request for PS-HSDPA by repeat integrity check
C310281891 Number of RNC initiate RAB release by release request for PS-HSDPA by UE initiate release
C310281892 Number of RNC initiate RAB release by release request for PS-HSDPA by lost UE connection
Number of RNC initiate RAB release by release request for PS-HSDPA by relocation complete
C310281893
timer exceed
C310281894 Number of RNC initiate RAB release by release request for PS-HSDPA by radio interface fail
C310281902 Number of RNC initiate RAB release by release request for PS-HSDPA by OMC intervention
C310281903 Number of RNC initiate RAB release by release request for PS-HSDPA by overload control
C310281904 Number of RNC initiate RAB release by release request for PS-HSDPA by RAB pre-empty
C310281905 Number of RNC initiate RAB release by release request for PS-HSDPA by IUUP fail
C310281906 Number of RNC initiate RAB release by release request for PS-HSDPA by UTRAN generating
C310281907 Number of RNC initiate RAB release by release request for PS-HSDPA by unspecific fail
Number of RNC initiate RAB release by release request for PS-HSUPA with standerd Failure causes

C310281908 Number of RNC initiate RAB release by release request for PS-HSUPA by uesr inactive
C310281909 Number of RNC initiate RAB release by release request for PS-HSUPA by repeat integrity check
C310281910 Number of RNC initiate RAB release by release request for PS-HSUPA by UE initiate release
C310281911 Number of RNC initiate RAB release by release request for PS-HSUPA by lost UE connection
Number of RNC initiate RAB release by release request for PS-HSUPA by relocation complete
C310281912
timer exceed
C310281913 Number of RNC initiate RAB release by release request for PS-HSUPA by radio interface fail
C310281921 Number of RNC initiate RAB release by release request for PS-HSUPA by OMC intervention

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 20

 UMTS QoS Monitoring Process

C310281922 Number of RNC initiate RAB release by release request for PS-HSUPA by overload control
C310281923 Number of RNC initiate RAB release by release request for PS-HSUPA by RAB pre-empty
C310281924 Number of RNC initiate RAB release by release request for PS-HSUPA by IUUP fail
C310281925 Number of RNC initiate RAB release by release request for PS-HSUPA by UTRAN generating
C310281926 Number of RNC initiate RAB release by release request for PS-HSUPA by unspecific fail

4.3 Optimization of Accessibility Indicators

Accessibility performance includes the success rate of RRC connection setup and the
success rate of CS/PS RAB assignment. These two kinds of KPIs play important roles in
the network optimization and directly influence the success rate of CS/PS service
establishment. In this document, this kind of problems are found from the aspect of OMC
data, and solved through parameter optimization.

4.3.1 Definition of Access Failure

For the mobile originated call in the CS domain, the access failure event means that the
UE sends RRC REQUEST, and IE establish cause is Originating Conversational Call, but
alerting of the direct transfer message is not received.

The relevant events are defined as follows in the access failure stage.

RRC connection setup failure: After considering the resending times and the waiting time,
the UE sends RRC CONNECTION REQUEST, and does not receive the response from
RNC or RRC CONNECTION REJECT delivered by RNC.

Initial direct transfer and security mode establishment failure: After sending RRC
CONNECTION SETUP COMPLETE, the UE does not send NAS SETUP.

RAB assignment failure: After receiving CALL PROCEEDING, the UE does not receive
RB SETUP delivered by RNC. Or the UE replies with RB SETUP FAIL after receiving RB
SETUP. Or the UE receives DISCONNECT with the cause value not being Normal
Release after receiving RB SETUP. At this time, the UE has not reported RB SETUP
CMP.

Failure after RAB assignment: After the UE sends RB SETUP COMPLETE, the
originating UE receives DISCONNECT/RELEASE from CN. Or the UE waits CONNECT
or ALERTING overtime, and launches the Call Clearing process; Or the UE becomes
IDLE before receiving Alerting, and starts to receive the system message.

For the mobile terminated in the CS domain, the access failure event means that the
terminating UE receives the paging of paging type 1, and does not send RRC
CONNECTION REQUEST with the cause value being Terminating Conversational Call.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 21

 UMTS QoS Monitoring Process

Or the UE does not send the alerting of direct transfer message to CN after sending RRC
CONNECTION REQUEST.

The relevant events are defined as follows in the access failure stage.

RRC connection setup failure: After sending RRC CONNECTION REQUEST, the UE
does not receive the response from RNC or RRC CONNECTION REJECT delivered by
RNC.

Initial direct transfer and security mode establishment failure: After sending RRC
CONNECTION SETUP COMPLETE, the UE does not receive the SETUP direct transfer
message. Or the UE sends RELEASE COMPLETE. Or the UE receives DISCONNECT
from CN.

RAB assignment failure: The UE does not receive RB SETUP delivered by RNC after
sending CALL CONFIRM. Or the UE replies with RB SETUP FAIL after receiving RB
SETUP. Or the UE receives DISCONNECT with the cause value not being Normal
Release after receiving RB SETUP. At this time, the UE has not reported RB SETUP
CMP.

Failure after RAB assignment: After the UE sends RB SETUP COMPLETE, the
terminating UE receives DISCONNECT/RELEASE from CN.

4.3.2 Analysis on RRC Connection Failures

The problem of RRC connection setup failure can be analyzed through the UE signaling
flow and RNC single-user tracing. The RRC connection setup includes the following
steps:

The UE sends RRC Connection Request through the RACH channel.

RNC sends RRC Connection Setup through the FACH channel.

The UE sends RRC Connection Setup Complete through the dedicated uplink channel
after the downlink dedicated channel is established and synchronized.

RRC connection setup failures are always caused by following issues:

Uplink RACH problem

Problem about downlink FACH power allocation proportion

Parameter reselection problem of the cell

Low downlink dedicated initial transmitting power

Uplink initial power control problem

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 22

 UMTS QoS Monitoring Process

Congestion

Equipment malfunctions

Among these issues, the problems of uplink RACH, downlink FACH power allocation
proportion, parameter reselection of the cell and equipment malfunctions appear more
frequently.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 23

 UMTS QoS Monitoring Process

4.3.2.1 Analysis Flowchart of RRC Connection Setup Failures

Figure 4-3 Analysis flowchart of RRC connection setup failures

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 24

 UMTS QoS Monitoring Process

Counters：
Failure causes
C310080063 Number of failed RRC connection preparation,NodeB
C310080066 Number of failed RRC connection preparation,Due To Admission Control
C310080072 Number of failed RRC connection preparation,Due To RNC Internal Reasons
C310080076 Number of failed RRC connection preparation,Due To Trans
C310086446 Number of failed RRC connection preparation,Due To CN
C310080167 Number of failed RRC connection access,due to Radio Interface Synch.
C310080168 Number of failed RRC connection access,due to timeout of UU interface
C310080169 Number of failed RRC connection access,due to RNC Inner Reasons
Failed RRC connection preparation,Due To Admission Control
C310080067 Number of failed RRC connection preparation,Due To Codes
C310080068 Number of failed RRC connection preparation,Due To DL POWER Shortage
C310080069 Number of failed RRC connection preparation,Due To UL Interfere
C310080070 Number of failed RRC connection preparation,Due To UL CE Shortage
C310080071 Number of failed RRC connection preparation,Due To DL CE Shortage

4.3.2.2 UE sends RRC Connection Request, but RNC does not receive it
 If the Ec/Io of downlink CPICH is relatively low, it is the problem of coverage.
 If the Ec/Io of downlink CPICH is not very low (for example, the value is larger than
-14 dB). Usually, it is the problem of RACH, and the following issues may cause the
problem:

 The power of Preamble does not rise to a required value, and the rising times
of Preamble should be increased.

 The output power of UE is lower than the required value, which is caused by
poor UE performance. In this case, the UE should be changed.

 The NodeB equipment has a standing wave and the engineer should check
whether NodeB has any SWR alarm.

 The radius of the cell is set improperly. If the radius parameter of the cell is set
too small, the NodeB can not synchronize the UE beyond the range of the
radius, and the access fails. This problem often happens in the places with
large coverage, such as the rural areas and the suburbs.

4.3.2.3 RNC delivers RRC Connection Reject after receiving RRC Setup Request.

When RRC Connection Reject appears, the engineer should check the specific reject
cause value. Usually, there are two kinds of causes:

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 25

 UMTS QoS Monitoring Process

The CPU load of RNC control plane board is too heavy and more boards should be
added.

DCH and FACH admission is rejected. However, this situation does not always happen.

4.3.2.4 UE does not receive RRC Connection Setup delivered by RNC

This problem may be caused by the following reasons:

Poor coverage

Improper parameters of cell selection and reselection

Checking method: The engineer should check the Ec/Io of CPICH. If the value is lower
than -12 dB (Ec/Io is -12 dB by default), and there is no cell of better quality in the monitor
set, the cause of this problem is poor coverage. If there is better cell in the monitor set,
cell reselection may cause this problem.

Poor coverage can be improved by coverage enhancement, such as adding some sites
to cover the places without signal coverage and adjusting the engineering parameters. If
the coverage can not be improved, the engineer can enhance the FACH power according
to the PCPICH Ec/Io coverage of the current network. For example, if all the pilot Ec/Io
values are larger than -12 dB in the coverage area, the power proportion of the common
channel should be configured on the basis of the situation that the Ec/Io value is larger
than -12 dB. And so, the success rate of the idle UE assessment can be ensured.

As for the access problem caused by cell selection and reselection, the engineer can
speed up the cell selection and reselection by adjusting the cell selection and reselection
parameters, and the problem of RRC connection setup failure caused by improper cell
selection and reselection parameters can be solved.

Note:

The RRC Connection Setup message is borne by FACH. RRC Connection Request sent
by the UE is received by UTRAN at the preamble of PRACH, and then it is sent from the
RACH channel based on the current preamble power. And the transmit power of
preamble can rise all the time until the response is received (There is a limitation for the
maximum number of preamble retransmissions). Therefore, in the areas with poor
coverage, the RACH coverage and FACH coverage may become unbalanced, and as a
result, UTRAN can receive RRC Connection Request sent by the UE but the UE can not
receive RRC Connection Setup sent by RNC.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 26

 UMTS QoS Monitoring Process

4.3.2.5 UE receives RRC Connection Setup and does not send RRC Setup
Complete

If the downlink signal quality is normal, this problem may be caused by the abnormal
condition of the cell phone.

Another reason of this problem may be the downlink synchronization failure caused by
the low initial power of downlink dedicated channel. You can solve this problem by
adjusting the service downlink Eb/No.

4.3.2.6 RNC does not receive RRC Setup Complete sent by UE

Because the uplink initial power control may increase the UE transmit power, this kind of
problem seldom appears. If it appears, the engineer can increase the Constant Value of
the dedicated channel properly to raise the uplink DPCCH initial transmission power of
the UE.

At the same time, this problem is also relevant with the uplink SIR initial target value
configuration because this value may affect the uplink initial synchronization at the initial
stage of link setup. If the value of the parameter is set too large, there will be too much
uplink inference brought by the initial setup of the link. If the value is set too small, the
uplink synchronization will take longer time, and the initial synchronization may even fail.
This parameter is an RNC-level parameter, which has a great influence on network
performance. Therefore, the engineer should be cautious while adjusting this parameter.

Note:

RRC Connection Setup Complete is sent through uplink DPCH, and the UE calculates
the initial power of uplink DPCCH according to the received IE”DPCCH_Power_offset”
and the measured CPICH_RSCP value.

DPCCH_Initial_power = DPCCH_Power_offset - CPICH_RSCP

DPCCH_Power_offset = Primary CPICH DL TX Power + UL Interference + Constant

Value. The Constant Value can be configured in the OMC. If this value is set too small,
the UE may not have enough power to send RRC Connection Setup Complete.

4.3.3 Analysis on RAB/RB Setup Failures

When RAB or RB setup fails, RNC will send RAB Assignment Fail in the RAB
Assignment Response signaling. The engineer can find out the specific failure reason
from the failure cause value carried in relevant cells. The reasons for common RAB/RB
setup failures include:

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 27

 UMTS QoS Monitoring Process

 RNC directly rejecting RAB Setup Request because of wrong parameter

configuration

 Admission reject

 RAB setup failure because the UE fails to respond to RB Setup Request

 RAB setup failure because the Uu interface fails to set up RB

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 28

 UMTS QoS Monitoring Process

4.3.3.1 Analysis Flowchart of RAB Setup Failures

Figure 4-4 Analysis flowchart of RAB setup failures

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 29

 UMTS QoS Monitoring Process

Counters：
Number of failed RAB assignment setup in cell for CS domain with Failure causes
C310110325 Number of failed RAB assignment setup in cell for CS domain,Invalid RAB Parameters Value
C310110326 Number of failed RAB assignment setup in cell for CS domain,failed in the Radio Interface Procedure
C310110329 Number of failed RAB assignment setup in cell for CS domain,TQUEUING Expiry
C310110330 Number of failed RAB assignment setup in cell for CS domain,Requested Traffic Class not Available
C310110331 Number of failed RAB assignment setup in cell for CS domain,Requested Guaranteed Bit Rate not Available
C310110334 Number of failed RAB assignment setup in cell for CS domain,No Resource Available
C310110347 Number of failed RAB assignment setup in cell for CS domain,Access Restricted Due to Shared Networks
C310110348 Number of failed RAB assignment setup in cell for CS domain,IUUP failed
C310110349 Number of failed RAB assignment setup in cell for CS domain, Directed Retry
Number of failed RAB assignment setup in cell for CS domain, Iu Transport Connection Number of failed to
C310110350
Establish
C310110354 Number of failed RAB assignment setup in cell for PS domain,Non-Standard Cause
C310110377 Number of failed RAB assignment setup in cell for CS domain,Unspecified failed
Number of failed RAB assignment setup in cell for CS domain- No Resource available
C310110335 Number of failed RAB assignment setup in cell for CS domain,No Resource Available In SRNC
C310110336 Number of failed RAB assignment setup in cell for CS domain,Downlink CE Congestion
C310110337 Number of failed RAB assignment setup in cell for CS domain,Downlink CE Congestion
C310110338 Number of failed RAB assignment setup in cell for CS domain,Downlink Power Resource Congestion
C310110339 Number of failed RAB assignment setup in cell for CS domain,Other Downlink Resource Congestion
C310110340 Number of failed RAB assignment setup in cell for CS domain,Uplink CE Congestion
C310110341 Number of failed RAB assignment setup in cell for CS domain,Uplink Power Resource Congestion
C310110342 Number of failed RAB assignment setup in cell for CS domain,Other Uplink Resource Congestion
C310110343 Number of failed RAB assignment setup in cell for CS domain,DCH user number limit
C310110344 Number of failed RAB assignment setup in cell for CS domain,HSDPA user number limit
C310110345 Number of failed RAB assignment setup in cell for CS domain,HSUPA user number limit
C310110346 Number of failed RAB assignment setup in cell for CS domain,No Resource Available In DRNC

Number of failed RAB assignment setup in cell for PS domain with Failure causes
C310110382 Number of failed RAB assignment setup in cell for PS domain,Invalid RAB Parameters Value
C310110383 Number of failed RAB assignment setup in cell for PS domain,failed in the Radio Interface Procedure
C310110386 Number of failed RAB assignment setup in cell for PS domain,TQUEUING Expiry
C310110387 Number of failed RAB assignment setup in cell for PS domain,Requested Traffic Class not Available
C310110388 Number of failed RAB assignment setup in cell for PS domain,Requested Guaranteed Bit Rate not Available
Number of failed RAB assignment setup in cell for PS domain,Requested Guaranteed Bit Rate for DL not
C310110389
Available
Number of failed RAB assignment setup in cell for PS domain,Requested Guaranteed Bit Rate for UL not
C310110390
Available
C310110391 Number of failed RAB assignment setup in cell for PS domain,No Resource Available
C310110404 Number of failed RAB assignment setup in cell for PS domain,Access Restricted Due to Shared Networks
C310110405 Number of failed RAB assignment setup in cell for PS domain,IUUP failed
C310110406 Number of failed RAB assignment setup in cell for PS domain, Directed Retry
Number of failed RAB assignment setup in cell for PS domain, Iu Transport Connection Number of failed to
C310110407
Establish
C310110411 Number of failed RAB assignment setup in cell for PS domain,Non-Standard Cause

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 30

 UMTS QoS Monitoring Process

C310110434 Number of failed RAB assignment setup in cell for PS domain,Unspecified failed

Number of failed RAB assignment setup in cell for CS domain- No Resource available
C310110335 Number of failed RAB assignment setup in cell for CS domain,No Resource Available In SRNC
C310110336 Number of failed RAB assignment setup in cell for CS domain,Downlink CE Congestion
C310110337 Number of failed RAB assignment setup in cell for CS domain,Downlink CE Congestion
C310110338 Number of failed RAB assignment setup in cell for CS domain,Downlink Power Resource Congestion
C310110339 Number of failed RAB assignment setup in cell for CS domain,Other Downlink Resource Congestion
C310110340 Number of failed RAB assignment setup in cell for CS domain,Uplink CE Congestion
C310110341 Number of failed RAB assignment setup in cell for CS domain,Uplink Power Resource Congestion
C310110342 Number of failed RAB assignment setup in cell for CS domain,Other Uplink Resource Congestion
C310110343 Number of failed RAB assignment setup in cell for CS domain,DCH user number limit
C310110344 Number of failed RAB assignment setup in cell for CS domain,HSDPA user number limit
C310110345 Number of failed RAB assignment setup in cell for CS domain,HSUPA user number limit
C310110346 Number of failed RAB assignment setup in cell for CS domain,No Resource Available In DRNC

Number of failed HSDPA RAB assignment setup in cell for PS domain with Failure causes
C310170621 Number of failed HSDPA RAB assignment setup in cell for PS domain,Invalid RAB Parameters Value
C310170622 Number of failed HSDPA RAB assignment setup in cell for PS domain,failed in the Radio Interface Procedure
C310170625 Number of failed HSDPA RAB assignment setup in cell for PS domain,TQUEUING Expiry
C310170626 Number of failed HSDPA RAB assignment setup in cell for PS domain,Requested Traffic Class not Available
Number of failed HSDPA RAB assignment setup in cell for PS domain,Requested Guaranteed Bit Rate not
C310170627
Available
C310170629 Number of failed HSDPA RAB assignment setup in cell for PS domain,No Resource Available
Number of failed HSDPA RAB assignment setup in cell for PS domain,Access Restricted Due to Shared
C310170641
Networks
C310170642 Number of failed HSDPA RAB assignment setup in cell for PS domain,Non-Standard Cause
Number of failed HSDPA RAB assignment setup in cell for PS domain-No resource available
C310170630 Number of failed HSDPA RAB assignment setup in cell for PS domain,No Resource Available In SRNC
C310170631 Number of failed HSDPA RAB assignment setup in cell for PS domain,Downlink Code Congestion
C310170632 Number of failed HSDPA RAB assignment setup in cell for PS domain,Downlink CE Congestion
C310170633 Number of failed HSDPA RAB assignment setup in cell for PS domain,Downlink Power Resource Congestion
C310170634 Number of failed HSDPA RAB assignment setup in cell for PS domain,Other Downlink Resource Congestion
C310170635 Number of failed HSDPA RAB assignment setup in cell for PS domain,Uplink CE Congestion
C310170636 Number of failed HSDPA RAB assignment setup in cell for PS domain,Uplink Power Resource Congestion
C310170637 Number of failed HSDPA RAB assignment setup in cell for PS domain,Other Uplink Resource Congestion
C310170638 Number of failed HSDPA RAB assignment setup in cell for PS domain,HSDPA user number limit
C310170639 Number of failed HSDPA RAB assignment setup in cell for PS domain,HSDPA user number limit
C310170640 Number of failed HSDPA RAB assignment setup in cell for PS domain,No Resource Available In DRNC
Number of failed HSUPA RAB assignment setup in cell for PS domain with Failure causes
C310170666 Number of failed HSUPA RAB assignment setup in cell for PS domain,Invalid RAB Parameters Value
C310170667 Number of failed HSUPA RAB assignment setup in cell for PS domain,failed in the Radio Interface Procedure
C310170670 Number of failed HSUPA RAB assignment setup in cell for PS domain,TQUEUING Expiry
C310170671 Number of failed HSUPA RAB assignment setup in cell for PS domain,Requested Traffic Class not Available
Number of failed HSUPA RAB assignment setup in cell for PS domain,Requested Guaranteed Bit Rate not
C310170672
Available

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 31

 UMTS QoS Monitoring Process

C310170674 Number of failed HSUPA RAB assignment setup in cell for PS domain,No Resource Available
Number of failed HSUPA RAB assignment setup in cell for PS domain,Access Restricted Due to Shared
C310170686
Networks
C310170687 Number of failed HSUPA RAB assignment setup in cell for PS domain,Non-Standard Cause
C310170710 Number of failed HSUPA RAB assignment setup in cell for PS domain,Unspecified failed

Number of failed HSUPA RAB assignment setup in cell for PS domain-No resource available

C310175815 Number of failed HSUPA RAB assignment setup in cell for CS domain,No Resource Available In SRNC
C310175816 Number of failed HSUPA RAB assignment setup in cell for CS domain,Downlink CE Congestion
C310175817 Number of failed HSUPA RAB assignment setup in cell for CS domain,Downlink CE Congestion
Number of failed HSUPA RAB assignment setup in cell for CS domain,Downlink Power Resource
C310175818
Congestion
C310175819 Number of failed HSUPA RAB assignment setup in cell for CS domain,Other Downlink Resource Congestion
C310175820 Number of failed HSUPA RAB assignment setup in cell for CS domain,Uplink CE Congestion
C310175821 Number of failed HSUPA RAB assignment setup in cell for CS domain,Uplink Power Resource Congestion
C310175822 Number of failed HSUPA RAB assignment setup in cell for CS domain,Other Uplink Resource Congestion
C310175823 Number of failed HSUPA RAB assignment setup in cell for CS domain,HSUPA user number limit
C310175824 Number of failed HSDPA RAB assignment setup in cell for CS domain,HSDPA user number limit
C310175825 Number of failed HSUPA RAB assignment setup in cell for CS domain,No Resource Available In DRNC

4.3.3.2 RNC Directly Rejecting RAB Setup Request Because Of Wrong Parameter
Configuration

The case that RNC responds with RAB Setup Failure directly is seldom caused by invalid
parameter configuration in the business network. Usually, this case is caused by special
operations of the special users.

The main scenario is that the subscription information of the user’s PS service is beyond
the capability of the UE, which leads to the direct refusal from RNC. For example, a
special user’s subscription rates of uplink and downlink are 384 K, but the maximum
uplink rate of the UE is only 64 K. The maximum uplink and downlink rates of the QoS
message used for activating PDP set by the AT command or mobile terminal software
used by the user are 384 K, so the RNC will find the maximum uplink rate is beyond the
UE’s capability, directly reply with RAB Setup Failure and will not launch the RB setup
process, when it receives RAB Assignment Request.

After the RAB setup fails because the parameter configuration is beyond the UE’s
capability, SGSN will negotiate again to launch the new RAB assignment until the UE has
the capability to support the assignment, and the RAB assignment is finished. For the
users, the PDP activation is still successful, and the actual maximum rate is the maximum
rate the UE can support.

However, if the minimum guaranteed bit rate required by the QoS setting in the UE’s PDP
activation request is beyond the UE’s capability, though the network negotiates a lower
rate to accept the UE’s PDP activation request, the UE will launch the request of

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 32

 UMTS QoS Monitoring Process

deactivating PDP when it finds that the rate negotiated by the network in PDP activation
accept request is lower than the minimum guaranteed bit rate, and finally the PDP
activation can not be completed.

4.3.3.3 Admission Reject

For the non-HSDPA user, if there are insufficient system resources (including power,
channel code, lub transmission resource and CE), the call establishment failure will be
caused by the admission reject. At this time, it is necessary to check the network load,
code resource, lub transmission resource and CE resource occupation to make sure the
congestion is caused by the limitation of a certain kind of resource. What is more, the
engineer should plan the corresponding expansion method.

If the cell does not support the HSDPA service, the R99 user admission is judged
according to the fixed R99 admission threshold. If the cell supports the HSDPA service,
and the HSDPA and R99 dynamic power is allocated, the uplink admission of
non-HSDPA is judged based on RTWP or the equivalent user number. If the uplink load
is too heavy, the non-HSDPA user admission will also fail.

If the bandwidth configuration on the lub interface is insufficient, the lub interface will
reject the R99 data service activation because of limited bandwidth.

The admission control of the NodeB Credit resource is similar to the power admission
control. Whether the remaining Credit can support the currently requested service or not
can be judged according to the spectrum spreading factor of the new access user.
According to the condition of the RAB Downsizing Switch, RNC will deal with the issue in
the corresponding way.

For the HSDPA user, in the dynamic power allocation mode, besides the mentioned
system resources such as the power, channel code, lub transmission resource and CE,
the admission reject should take into consideration whether the number of H users
supported by NodeB and the number of H users supported by the cell are over the
regulated threshold or not into consideration.

For the HSDPA user, when the bandwidth configuration on lub interface is insufficient,
the admission reject will not happen, but the rate will be reduced. What is more, the
AAL2PATHs of HSDPA and R99 are configured respectively, and the HSDPA
AAL2PATH must be configured to the HSDPA_RT or HSDPA_NRT type. If the HSDPA
AAL2PATH is configured to RT or NRT of R99 AAL2PATH type, the RAB assignment
failure will not happen, but RNC will establish the HSDPA service as R99 384 Kbps.

For the downlink power admission,

Besides whether the R99 service load is over the non-HSDPA service threshold, DCH
service should take into consideration whether non-HSDPA power and HSDPA GBP (the
minimum power needed for the guaranteed bit rate) are over the general power threshold
of the cell.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 33

 UMTS QoS Monitoring Process

For the HSDPA service, it is necessary to check whether the throughput rate provided by
the cell is over the sum of all the users’ GBR thresholds, or whether the GBPs of the
stream service and the background service are over the HSDPA power of the cell. At the
same time, whether the non-HSDPA power and the HSDPA GBP (the minimum power
needed for the guaranteed bit rate) are over the overall power threshold of the cell should
be also taken into consideration.

For the lub admission,

For the DCH service, the admission is made according to the multiplication of the peak
rate and the service activation factor.

For HSDPA service, the admission is made according to the GBR.

If the lub exceeds the congestion threshold, the DCCC rate reduction will be triggered.
And if the RLC_AM retransmission rate is over a certain threshold, the Iub Overbooking
switch can be opened to trigger the TF which limits R99 or to reduce the rate of HSDPA
service by a certain factor.

4.3.3.4 RAB Setup Failure Because the UE Fails to Respond to RB Setup

The UE fails to respond to RB setup mainly because of the user’s operation.

Take the following cases as examples:

 When the user already has had the downlink 12 K data service, he receives RB
Setup Request of the VP service (either the originated call in the VP domain or the
terminated call in the VP domain). Because the UE does not support the VP and
high-speed PS service in the downlink at the same time, it directly replies with RB
Setup Failure, and the cause value is unsupported configuration.
 Compared with the WCDMA subscriber originating the VP service, the terminating
subscriber resides in the GSM network, and so it does not support the VP service.
After RNC receives RAB Assignment Request, the core network will deliver the
Disconnect command right after call proceeding, and the cause value is Bearer
capability not authorized. At this time, the UE has just received the RB SETUP
command and has no enough time to finish the RB setup. So the UE will reply with
RB Setup Failure after it receives the Disconnect command, and the RNC will reply
with RAB Setup Failure, with the cause value being failure in radio interface
procedure.

4.3.3.5 RAB Setup Failure Because the Uu Interface Fails to Set Up RB

RNC sends the Radio Bearer Setup command to the UE but fails to receive Radio Bearer
Setup Compete. This kind of situation (RB setup failure) often appears in the cells with
weak signals. There are two causes of weak signals: one is that the UE does not reside in
the best server to launch the access, and the other is poor coverage.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 34

 UMTS QoS Monitoring Process

 If the UE does not reside in the best server to launch the access, it will hope to enter
the best server through active set update in the RB setup process (At the same
time, the fast signal change will drastically weaken the signals in the cell), but the
active set update can only be processed after the RB setup is completed, because
the procedures can not be processed alternately (Neither the network nor the
terminal supports it). Therefore, RB can only be set up in the cell with weak signals,
and the setup is easy to fail. As for this situation, the starting threshold and speed of
co-frequency cell reselection should be increased to make the UE reside in the best
server and launch the access as soon as possible.

 RB setup failure may be caused by the poor downlink/uplink coverage. If the failure
is caused by downlink coverage, the UE can not receive the Radio Bearer Setup
command, which may be caused by the uplink interference, and this can be fixed
through checking RTWP. The poor downlink coverage is partly caused by the bad
UE demodulation performance, and other causes should be solved by RF
optimization.

4.4 Optimization of Mobility Indicators

Mobility indicators mainly fall into three categories — soft handovers, hard handovers
and inter-RAT handovers. The handover problems usually happen in the following cases.

 The best server changes too fast or there is no best server due to pilot pollution.

 The handover is not prompt or there are pingpong handovers due to improper
parameter configuration.

Adjust the engineering parameters for antennas in areas with severe pilot pollution. And
adjust the handover parameters, such as the values of 1A, 1B, CIO, TTT (time to trigger),
Hysteresis and so on, to solve the problem that the handover is not prompt or there are
pingpong handovers. This section tries to solve this kind of problems through OMC data
analysis and parameter optimization.

4.4.1 Optimization of Soft Handovers

Missed neighboring cell configuration, pilot pollution, improper soft handover parameter
configuration, and equipment malfunctions are the major causes of soft handover failures.
To confirm the problems, the field DTs are required.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 35

 UMTS QoS Monitoring Process

4.4.1.1 Soft Handover Optimization Flowchart

Figure 4-5 Soft handover optimization flowchart

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 36

 UMTS QoS Monitoring Process

Counters:
Number of failed active set update to add cell with failure causes
C310322222 Number of failed active set update to add cell,configuration unsupported
C310322223 Number of failed active set update to add cell,Physical Channel failed
Number of failed active set update to add cell,Incompatible Simultaneous
C310322224
Reconfiguration
C310322225 Number of failed active set update to add cell,Compress Mode Error
C310322226 Number of failed active set update to add cell,Protocol Error
C310322227 Number of failed active set update to add cell,Cell Update Occurred
C310322228 Number of failed active set update to add cell,invalid configuration
C310322229 Number of failed active set update to add cell,configuration incomplete
C310322230 Number of failed active set update to add cell,No Reply
C310322231 Number of failed active set update to add cell,Other failed

Number of failed active set update to del cell with failure causes

C310322235 Number of failed active set update to del cell,configuration unsupported

C310322236 Number of failed active set update to del cell,Physical Channel failed
Number of failed active set update to del cell,Incompatible Simultaneous
C310322237
Reconfiguration
C310322238 Number of failed active set update to del cell,Compress Mode Error
C310322239 Number of failed active set update to del cell,Protocol Error
C310322240 Number of failed active set update to del cell,Cell Update Occurred
C310322241 Number of failed active set update to del cell,invalid configuration
C310322242 Number of failed active set update to del cell,configuration incomplete
C310322243 Number of failed active set update to del cell,No Reply
C310322244 Number of failed active set update to del cell,Other failed

4.4.1.2 Checking Missed Neighboring Cell Configuration

Generally speaking, most of the call drops at the beginning of the optimization are
caused by missed neighboring cell configuration. The following methods are often used
to judge whether the call drops are caused by missed configuration of co-frequency
neighboring cells.

 Observe the active set Ec/Io information recorded by the UE and the Best Server
Ec/Io information recorded by the Scanner before the call drop. If the former record
is very bad but the latter record is very good, then check whether the Best Server
scrambling code recorded by the Scanner appears in the latest list of the

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 37

 UMTS QoS Monitoring Process

neighboring cells under intra-frequency measurement control. If it does not, then the
call drop is caused by missed neighboring cell configuration.

 If the UE re-accesses immediately after the call drop and the cell scrambling codes
during the UE reaccess and those during the call drop are different, then the call
drop may also be caused by missed neighboring cell configuration. You can confirm
it through measurement control (look backwards from the message of the call drop
event for the latest intra-frequency measurement control message and check the
neighboring cell list of this message).

 Some UE may report the Detected Set information. If the corresponding scrambling
code appears in the Detected Set information before the call drop, then the call drop
is caused by missed neighboring cell configuration.

4.4.1.3 Checking Pilot Pollution

Definition of pilot pollution: Excessive strong pilot signals exist at a certain point, but
none of them is strong enough to be the best server. To form pilot pollution, the following
points in this definition should be satisfied.

 Strong pilot signal: The absolute pilot signal strength is used to judge whether the
pilot signal is a strong one. The pilot signal strength can be evaluated through the
pilot RSCP. If the pilot RSCP exceeds a threshold, it is considered a strong pilot
signal. The formula is:

CPICH _ RSCP  ThRSCP _ Absolute

 Excessive: The number of pilot signals is used to judge whether there are
excessive pilot signals at a certain point. If the number exceeds a threshold, it is
regarded that excessive pilot signals exist at this point. The formula is:

CPICH _ Number  ThN

 None of them is strong enough to be the best server: The relative strength of a
pilot signal is a key factor in judging whether the pilot signal is strong enough. Based
on the above definition and formulae, if the difference between the strength of the
strongest pilot signal and that of the (Th N  1) strongest pilot signal at this point is
less than a threshold, it is regarded that there is no pilot signal strong enough to be
the best server at this point. The formula is:

(CPICH _ RSCPbest  CPICH _ RSCP(ThN 1) th )  ThRSCP _ Re lative

According to the above description, it is regarded that pilot pollution exists if the following
conditions are both satisfied.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 38

 UMTS QoS Monitoring Process

 The number of pilot signals that meet the condition

CPICH _ RSCP  Th RSCP _ Absolute Th N .
is more than

(CPICH _ RSCPbest  CPICH _ RSCP(ThN 1) th )  ThRSCP _ Re lative



For example, during the network optimization, suppose:

Th RSCP _ Absolute  95dBm , Th N  3 , and ThRSCP _ Re lative  5dB , if the following

conditions are both satisfied, then it is regarded that pilot pollution exists.

 The number of the pilot signals that meet the condition

CPICH _ RSCP  95dBm is more than 3.


(CPICH _ RSCPbest  CPICH _ RSCP4th )  5dB

4.4.1.4 Adjusting Soft Handover Algorithm Parameters

You can solve the following kinds of problems by adjusting handover algorithm
parameters:

1. The handover is not prompt.

 From the perspective of the CS service signaling flow, the symptom of this problem
is that the UE cannot receive Active Set Update (physical channel reallocation in the
case of the intra-frequency hard handover) because after the UE reports the
measurement report, the source cell has a fast reduction in Ec/Io. When the RNC
sends Active Set Update, the UE has closed the transmitter due to the loss of
downlink synchronization. Viewed from the UE side, it cannot receive Active Set
Update. In the PS services, if the UE cannot receive Active Set Update or TRB
resets before the handover, the handover will also fail.

 From the perspective of signals, the following phenomena may accompany this
problem.

 Corner effect: Ec/Io of the source cell decreases drastically, and Ec/Io of the
target cell increases sharply (very high when it appears).

 Fast fading: Ec/Io of the source cell decreases quickly for a while and then
increases, and Ec/Io of the target cell increases for a short while.

2. Pingpong handovers. The following phenomena may accompany this problem.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 39

 UMTS QoS Monitoring Process

 The best server changes quickly: Two or more cells take turns to be the best server.
But as the best server, none of the cells can last long though they has good RSCPs
and Ec/Ios.

 There is no best server: There are multiple cells. Their RSCPs are normal and
similar to each other. But Ec/Io of every cell is very bad.

From the perspective of the signaling flow, Event 1A is reported immediately after one
cell is deleted. Because the UE cannot receive Active Set Update from the RNC, the
handover fails.

4.4.1.5 Equipment Malfunctions

First check the alarm console to see whether there are abnormal alarms, and analyze the
message traces at the same time. Find out in which step the soft handover fails. Check
the failure message, and contact the local product maintaining engineer to confirm
whether the equipment has malfunctions.

4.4.1.6 Solutions

Corresponding adjustments should be taken for the confirmed problems.

 Handover failures caused by pilot pollution: Adjust the engineering parameters of a

certain antenna to set this antenna as the best server in this interfered location. If
the power of one of its sectors is reduced, then Io of the pilot pollution area will
decrease; even if the powers of other pilots are not adjusted, Ec/Io will also
increase. Thereby the Ec/Io differences with other scrambling codes in the active set
will become larger and pilot pollution will be eliminated. Through a lot of research,
ZTE has proved that the reduction in the pilot transmit power will not change cell
capacity greatly. If condition allows, new base stations can be added to cover this
area.

 Equipment malfunctions: Consult the customer service engineers, and ask them to
help check whether there are alarms and whether the transport layer is abnormal. If
there are alarms, coordinate with the customer service engineers and the
engineering personnel to solve the problems.

 Call drops because the handovers are not prompt:

 Adjust the antenna to expand the handover zone.

 Configure the Event 1A handover parameters to make the handover easier to

happen.

 Increase CIO to make the handover happen earlier in the target cell. The sum
of CIO and the actually measured value is used for judging the UE events,

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 40

 UMTS QoS Monitoring Process

including the UE intra-frequency handover. CIO helps shift the cell border in
the handover algorithm. If CIO is configured with a larger value, the handover
will be easier to happen and there will be more UE in the soft-handover status,
but more resources will be occupied. If CIO is configured with a smaller value,
the soft handover will be more difficult to happen and the receiving quality may
be impaired. A CIO of about 5dB is quite good for eliminating the fast fading
and the corner effect, but this configuration has some side effects, such as the
increase of handover proportion.

 Call drops caused by pingpong handovers: Adjust the antenna to form a best server
in its coverage zone or set the Event 1B handover parameters (increase the
threshold of Event 1B, the Event 1B hysteresis or the time to trigger Event 1B) to
increase the difficulty in deleting the active set.

4.4.2 Optimization of Hard Handovers

4.4.2.1 Classification of Hard handovers

Hard handovers mainly fall into two classifications:

 Intra-frequency hard handovers: The intra-frequency hard handover is triggered

only when the intra-frequency soft/softer handover cannot be performed, and it is
applicable to the following circumstances.

 Inter-RNC intra-frequency cell handovers when there is no Iur interface.

 Insufficient Iur interface resources though there is the Iur interface.

 Handovers controlled by the threshold of the PS service rate in the handover

cell.

The intra-frequency soft/softer handovers can not be performed (intra-frequency

hard handover should be triggered) in the following scenarios.

 When the intra-frequency handover happens, the UE is using the transmit

diversity in the active set cell but the target cell does not support the transmit
diversity.

 The intra-frequency measurement report does not contain OFF and TM of the
target cell.

 When the intra-frequency handover happens between RNCs, the Iur interface
is unavailable.

 The UE performs the multiuser detection in the active set cell, but the target
cell does not support the multiuser detection.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 41

 UMTS QoS Monitoring Process

 The target cell and the original cell belong to different classifications (The cells
of R99, R5+R99, and R6+R5+R99 belong to the same classification while the
cells of R5 and R6+R5 belong to another classification).

 Inter-frequency hard handovers: The inter-frequency hard handover means a UE

connection is handed over from a cell of a UTRAN frequency to a cell of another
frequency. Many factors, including the radio quality, the load, and the speed of the
moving UE, may trigger inter-frequency hard handovers.

For example, the radio quality triggers the inter-frequency hard handover in the
following way:

When the quality of the UE radio frequency becomes lower, the inter-frequency
measurement will be triggered, and according to the measurement result, the UE
connection will be handed over to a better frequency.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 42

 UMTS QoS Monitoring Process

4.4.2.2 Hard Handover Optimization Flowchart

Figure 4-6 Hard handover optimization flowchart

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 43

 UMTS QoS Monitoring Process

Counters:

KPI Name Formula

((C310332503+C310332525)-(C310332504+C310332505+C310332506+
Success Rate of Intra-RNC C310332507+C310332508+C310332509+C310332512+C310332513+C310
300463
Intra-Frequency Hard Handover 332526+C310332527+C310332528+C310332529+C310332530+C3103325
31+C310332534+C310332535))/(C310332503+C310332525)
Success Rate of Inter-RNC
(C310332547-(C310332548+C310332549+C310332550+C310332551+C3
300464 Intra-Frequency Outgoing Hard
10332552+C310332553+C310332556+C310332557))/C310332547
Handover
((C310332514+C310332536)-(C310332515+C310332516+C310332517+
Success Rate of Intra-RNC C310332518+C310332519+C310332520+C310332523+C310332524+C310
300465
Inter-Frequency Hard Handover 332537+C310332538+C310332539+C310332540+C310332541+C3103325
42+C310332545+C310332546))/(C310332514+C310332536)
Success Rate of Inter-RNC
(C310332558-(C310332559+C310332560+C310332561+C310332562+C3
300466 Inter-Frequency Outgoing Hard
10332563+C310332564+C310332567+C310332568))/C310332558
Handover

Counters for inter frequency failure

Number of outgoing inter-RNC intra frequency hard handover via Iur failed,configuration
C310332548
unsupported
Number of outgoing inter-RNC intra frequency hard handover via Iur failed,Physical
C310332549
Channel failed
Number of outgoing inter-RNC intra frequency hard handover via Iur failed,Incompatible
C310332550
Simultaneous Reconfiguration
Number of outgoing inter-RNC intra frequency hard handover via Iur failed,Compress Mode
C310332551
Error

C310332552 Number of outgoing inter-RNC intra frequency hard handover via Iur failed,Protocol Error

Number of outgoing inter-RNC intra frequency hard handover via Iur failed,Cell Update
C310332553
Occurred

C310332556 Number of outgoing inter-RNC intra frequency hard handover via Iur failed,No Reply

C310332557 Number of outgoing inter-RNC intra frequency hard handover via Iur failed,Other Causes

C310332536 Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover attempt

Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover

C310332537
failed,configuration unsupported
Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,Physical
C310332538
Channel failed
Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover
C310332539
failed,Incompatible Simultaneous Reconfiguration
Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,Compress
C310332540
Mode Error
Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,Protocol
C310332541
Error

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 44

 UMTS QoS Monitoring Process

Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,Cell

C310332542
Update Occurred
Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,invalid
C310332543
configuration
Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover
C310332544
failed,configuration incomplete

C310332545 Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,No Reply

Number of outgoing inter-NodeB,intra-RNC inter frequency hard handover failed,Other

C310332546
Causes

C310332514 Number of outgoing intra-NodeB inter frequency hard handover attempt

Number of outgoing intra-NodeB inter frequency hard handover failed,configuration

C310332515
unsupported
Number of outgoing intra-NodeB inter frequency hard handover failed,Physical Channel
C310332516
failed
Number of outgoing intra-NodeB inter frequency hard handover failed,Incompatible
C310332517
Simultaneous Reconfiguration

C310332518 Number of outgoing intra-NodeB inter frequency hard handover failed,Compress Mode Error

C310332519 Number of outgoing intra-NodeB inter frequency hard handover failed,Protocol Error

C310332520 Number of outgoing intra-NodeB inter frequency hard handover failed,Cell Update Occurred

Number of outgoing intra-NodeB inter frequency hard handover failed,invalid

C310332521
configuration
Number of outgoing intra-NodeB inter frequency hard handover failed,configuration
C310332522
incomplete

C310332523 Number of outgoing intra-NodeB inter frequency hard handover failed,No Reply

C310332524 Number of outgoing intra-NodeB inter frequency hard handover failed,Other Causes

4.4.2.3 Hard Handover Optimization Methods

The optimization flow for the hard handover is similar to that of the soft handover. The
major differences are in the parameter optimization. To optimize intra-frequency hard
handovers, you can properly reduce the Event 1D hysteresis and the time to trigger
Event 1D according to the real radio environment to ensure timely handovers.

Inter-frequency coverage is often applied to some special scenarios such as indoor

coverage and tested through CQT. The method of judging whether there is missed
configuration of the inter-frequency neighboring cell is almost the same as that of the

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 45

 UMTS QoS Monitoring Process

co-frequency neighboring cell: when a call drop occurs, the UE fails to measure or report
the inter-frequency neighboring cell; after the call drop, the UE resides in the
inter-frequency neighboring cell again.

The common hard handover problems are:

1. The handover is not prompt. The common symptoms are frequent call drops in the
hard handovers when the UE moves.

Solutions:

 Increase the threshold of activating the compressing mode. The compressing mode
is usually activated before the inter-frequency handover or the inter-RAT handover,
and it is used to measure the quality of the inter-frequency or inter-RAT cell. You
can set a threshold of the CPICH RSCP or Ec/Io to activate the compressing mode.
And the RSCP is widely used.

 Requirements on setting the threshold of activating the compressing mode:

Before the cell quality becomes low enough to cause a call drop, the signal of
the target cell should be measured and reported, and the handover should be
performed.

 Requirement on setting the threshold of deactivating the compression mode:

Frequent activation/deactivation of the compression mode should be avoided.

 Increase CIOs of the inter-frequency cell pair.

Reduce the threshold of triggering the target frequency handover under the
inter-frequency coverage.

2. There are pingpong handovers.

Solution: Increase the hard handover hysteresis and the time to trigger the event.

4.4.3 Optimization of Inter-RAT Handovers

4.4.3.1 Configuring Basic Inter-RAT Parameters

Most of the inter-RAT handover failures are caused by incomplete parameter

configuration. The following parameters need special attention.

 Complete RNC parameter configuration for the GSM neighboring cell: The 2G
system shall provide the 3G system with the correct radio parameters based on
negotiation — MCC, MNC, LAC, ID (CI), NCC, BCC, frequency band indicator (900
or 1800), and BCCH.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 46

 UMTS QoS Monitoring Process

Table 4-1 Parameters That 2G Shall Provide to 3G

ID Frequency
MCC MNC LAC NCC BCC band BCCH
CI indicator
460 2 202 193 0 0 900 102

 Complete GSM BSC parameter configuration for the WCDMA neighboring cell: The
3G system shall provide the 2G system with the correct radio parameters based on
negotiation — MCC, MNC, LAC, RNC ID, cell ID (C_ID), downlink frequency,
scrambling code, and RAC.

Table 4-2 Parameters That 3G Shall Provide to 2G

RNC Cell ID Downlink Scrambling

MCC MNC LAC RAC
ID C_ID frequency code
460 3 20 18 51 10787 51 20

According to the current strategy of one-way inter-RAT handovers, if the parameter

configuration is complete, one probable cause of the inter-RAT handover failure is that
the handover is not prompt. The common parameter adjustment is to increase CIO, the
threshold to activate/deactivate the compressing mode, and the threshold to trigger the
WCDMA-to-GSM handover at the same time.

Call drops during the inter-RAT handovers between WCDMA and GSM may be caused
by:

 Inconsistent data configuration at the GSM side and the WCDMA side after
GSM modifies the configuration data but does not inform WCDMA.

 Missed configuration of neighboring cells, which can be solved by the correct

configuration of neighboring cells.

 Too fast signal changes.

 Pingpong reselection.

 Faults with the UE, for example, the UE fails to respond to the handover or
report the inter-RAT measurement report.

 Changes of the best server during the physical channel reallocation.

 Wrong LAC configuration, which can be located through data configuration

check.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 47

 UMTS QoS Monitoring Process

4.4.3.2 Inter-RAT Handover Optimization Flowchart

Figure 4-7 Inter-RAT handover optimization flowchart

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 48

 UMTS QoS Monitoring Process

Counters：
Number of failed outgoing CS inter-RAT handovers with failure causes
C310352946 Number of failed outgoing CS inter-RAT handovers,Configuration unacceptable
C310352947 Number of failed outgoing CS inter-RAT handovers,Physical Channel failed
C310352948 Number of failed outgoing CS inter-RAT handovers,Protocol Error
C310352949 Number of failed outgoing CS inter-RAT handovers,Inter-RAT Protocol Error
C310352950 Number of failed outgoing CS inter-RAT handovers,Unspecified failed
C310352951 Number of failed outgoing CS inter-RAT handovers,No Reply
Number of failed outgoing PS inter-RAT handovers with failure causes
C310352953 Number of failed outgoing PS inter-RAT handovers,Configuration unacceptable
C310352954 Number of failed outgoing PS inter-RAT handovers,Physical Channel failed
C310352955 Number of failed outgoing PS inter-RAT handovers,Protocol Error
C310352956 Number of failed outgoing PS inter-RAT handovers,Inter-RAT Protocol Error
C310352957 Number of failed outgoing PS inter-RAT handovers,Unspecified failed
C310352958 Number of failed outgoing PS inter-RAT handovers,No Reply
Number of failed outgoing PS inter-RAT handovers,Configuration
C310352960
unacceptable(Cell Change Order)
Number of failed outgoing PS inter-RAT handovers,Physical Channel
C310352961
failed(Cell Change Order)
Number of failed outgoing PS inter-RAT handovers,Protocol Error(Cell Change
C310352962
Order)
Number of failed outgoing PS inter-RAT handovers,Unspecified failed(Cell
C310352963
Change Order)
Number of failed outgoing PS inter-RAT handovers,No Reply(Cell Change
C310352964
Order)

4.5 Optimization of Resource Indicators

The resource indicators directly reflect the system capacity. Increasing subscribers will
consume more system resources and some resources may be limited; for example, the
code resource may be limited, the TCP access request may be rejected, and the CE
resource usage rate may exceed the threshold. Limited system resources have a
negative influence on the whole-network indicators and the subscribers’ perception; for
example, call drops may frequently happen and more TCP access requests may be
rejected during the voice services.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 49

 UMTS QoS Monitoring Process

Table 4-3 Resource KPIs and Alarm Thresholds

PI name Formula Expansion Threshold Unit

Average non HSDPA

Code Resource 1-KPI300802- KPI300805 >=50% %
Utilization
Average nonHSDPA
KPI300829 >=50% %
TCP Utilization Ratio
UL Noise rise KPI300840- PI300843 >=8dB dB
HSDPA user average
C310545121/(C310545123*Gr) <=300kbps kbps
throughput
HSDPA cell traffic
C310545121/(1000*8) >=135MB MB
volume
Node B Average CE
KPI300791 >=70% %
Utilization, UL
Node B Average CE
KPI300793 >=70% %
Utilization, DL
Maximum Utilization
Ratio of Uplink NodeB C310810034 >=90% %
CE
Maximum Utilization
Ratio of Downlink C310810038 >=90% %
NodeB CE

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 50

 UMTS QoS Monitoring Process

4.5.1 Resource Indicator Optimization Flowchart

Figure 4-8 Resource indicator optimization flowchart

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 51

 UMTS QoS Monitoring Process

4.5.2 Code Resource Optimization

The statistics of Number of rejected services and DCH no code, the average code
resource usage rate and the number of the HSDPA subscribers can be used to judge
whether the code resource in a cell is limited. If the code resource is limited, you can
adjust the code resource allocation to alleviate the situation.

Based on the system algorithm, when Formula 1 is satisfied, you can add an HS-PDSCH;
when Formula 2 is satisfied, then an HS-PDSCH is deleted.

Formula 1: OcuRateNoHspdsch + OcuRateHspdsch + DpchCodeHy + 32 <= 512

Formula 2: OcuRateNoHspdsch + OcuRateHspdsch + CodeUptHyA > 512

OcuRateHspdschHSPDSCH means the number of the codes of SF=512 blocked by the

HS-PDSCH, OcuRateNoHspdsch means the number of codes of SF=512 blocked by
other channels, DpchCodeHy means the number of codes of SF=512 reserved for the
DPCH, and CodeUptHyA is the threshold to decide whether to delete the HSPDSCH.

Therefore, to ensure the access of the R99 subscribers, you can make some adjustment
according to Table 4-4 when the code resource is limited, though the HSDPA rate may
decrease.

Table 4-4 Adjusting Code Resource Allocation

Range
Parameter Current Update
Abbreviation and Remark
name value value
step
To decrease the
DPCH Code number of rejected
DpchCodeHy 0..512 16 28
Hysteresis services for DCH no
code
Code To decrease the
Update number of rejected
CodeUptHyA 0..512 16 28
Hysteresis services for DCH no
A code

4.5.3 Monitoring CE Resource

The CE resource is mainly monitored through the maximum UE uplink/downlink usage
rate. If there is any problem, you can solve it by controlling the load or adding more
boards.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 52

 UMTS QoS Monitoring Process

4.5.4 Optimization of Power Control

4.5.4.1 Monitoring and Optimizing Downlink Power Control

Limited TCP in busy hours will not only increase access failures and call drops in the
local cell but also increase soft handover failures and call drops in the neighboring cells.
Number of rejected services and DCH downlink TCP limit are intuitive KPIs to judge
whether TCP is limited. Although limited uplink capacity and massive UE moves in the
rush hours may also cause call drops, the limited TCP is absolutely a key factor.

Based on the system algorithm MinHsdpaPower (MinHspaPwrRto) + NoHsPower >Node

B, if the safety threshold is used (MinHsdpaPower means the power reserved for HSPA),
then it will activate the downlink rate downgrade algorithm flow for the congestion (lower
the downlink DCH rate). Although the rate downgrade can ensure access of some
subscribers, it is an irregular action and will degrade the performance.

4.5.5 Speeding up Rate Downgrade

Considering that the cells with heavy load reject more access requests, you can speed
up the rate downgrade during the resource congestion to release the resources as soon
as possible and avoid call drops caused by access failures (this method is only applicable
to the cells with many PS service users but not those with only CS service users). Table
4-5 is an example of the parameter modification for the rate downgrade.

Table 4-5 Example of Parameter Modification for Rate Downgrade

Range and Current Update
Abbreviation Parameter name Remark
step value value
UlDnMaxStg Maximum [1, 8] 1 2 Downgrade
Number of from 384 Kbps
Degraded Uplink to 16 Kbps
Load Steps Every
Time
DlDnMaxStg Maximum [1, 8] 1 3 Downgrade
Number of from 384 Kbps
Degraded to 8 Kbps
Downlink Load
Steps Every Time

4.5.6 Monitoring and Optimizing Uplink Capacity

Handover Blocking Rate and RTWP can reflect the uplink capacity of the cell. Because
interference may also increase RTWP, this factor should be distinguished during the
RTWP monitoring. Another effective indicator is the voice service erl. If a cell has over 20
erls in busy hours, you should pay special attention to it.

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 53

 UMTS QoS Monitoring Process

4.5.7 Optimization of Uplink Capacity at the Whole Network Level

Case: The uplink capacity was limited in a large number of sites after the cutover, and
the symptoms are a sharp rise of RTWP and a high call drop rate during the rush hours.

After the following parameters were modified as shown in Table 4-6, the problem was
solved.

Table 4-6 Example of Power Control Parameter Modification

Parameter Current Update

Abbreviation Range
name value value
UL 3.4 K/13.6 K
Uplink Initial SIR
ULINITSIR signaling, UL 12.2 K 4-5 3.5
target (dB)
AMR
UL 3.4 K/13.6 K
Maximum Uplink
ULMAXSIR signaling, UL 12.2 K 15 10
SIR target (dB)
AMR
Uplink SIR UL 3.4 K/13.6 K
UlSirTargDnStep Target Down signaling, UL 12.2 K 0.1 0.2
Step Size (dB) AMR

4.5.8 Optimization of Uplink Capacity for a Single Cell

A lot of optimization measures can be taken to bring down the rising RTWP. However,
with increasing subscribers, the capacity may still be limited in some area while further
modification of SirTarget will obviously degrade the call quality of the whole network and
undermine the subscribers’ perception. In this case, you can adjust the power control
parameters for a single site that has heavy traffic in the following way: add one set of
DivPc parameters and use this set of parameters only for this site.

Case: Table 4-7 shows an example of the power control parameter modification. After
this modification, the call drop rate in the site with heavy traffic decreased to one quarter
of the original one.

Table 4-7 Example of Power Control Parameter Modification for Heavy-Traffic Cell

SRVTYPE ULINITSIR ULMAXSIR ULMINSIR

0 3.5->1.5 10.0->3.5 2.0->1.0
104 4.0->2.0 15.0->5.0 0.5->0
28 3.5->1.5 10.0->3.5 0.5->0
50 6.0->2.0 15.0->5.0 2.0->0
54 6.0->2.0 15.0->5.0 2.0->0

ZTE Confidential Proprietary © 2014 ZTE CORPORATION. All rights reserved. 54