W Network Performance Analysis Guide 20081129 A 1.3

Guide to Analysis of WCDMA Network Performance For Internal Use Only
Product Name Confidentiality Level
WCDMA RNP For Internal Use Only
Product Version
Total 83 Pages
1.0
Guide to Analysis of WCDMA Network
Performance
(For Internal Use only)
Brainstorming and Case

Prepared by: Group Date: August 28, 2006
Reviewed by: Date:
Reviewed by: Date:
Approved by: Date:
2008-11-29 All Rights Reserved Page 1 of 83

Huawei Technologies Co., Ltd

All Rights Reserved

Revision History
Revision
Date Description Author
Version
August 28,
1.00 First draft is finished. Zuo Yanzhong
2006
Some errors are revised and subsequent

optimization parts are simplified according to review
September
1.1 comments. The emphasis is to find problems. He Fengming
24, 2006
Analysis based on observation points and
subsequent analysis data requirements are added.
October 20, The document is revised according to the review

1.2 He Fengming
2006 comments of the CCB.
October 28,
1.3 Alarm analysis is added. He Fengming
2006
2008-11-29 1.31 Review yearly Xiao Zhao

Contents
1 Overview........................................................................................................................................ 8
1.1 Purpose of the Document..................................................................................................... 8
1.2 Users of the Document......................................................................................................... 9
2 Necessary Conditions of Performance Analysis and Quality Early Warning........................10
2.1 Creating Network Planning and Network Optimization Parameter Archives.......................10
2.2 Signaling Flows of UTRAN and Basic Principles of WCDMA.............................................11
2.2.1 Mastery of Signaling Flows and Basic Principles.....................................................11
2.2.2 Fast Makeup of Knowledge Points..........................................................................12
2.3 Familiarization of UTRAN PIs............................................................................................. 12
2.4 Use of the Nastar Tool........................................................................................................ 13
2.4.1 Relations between Traffic Statistics PIs and Network Problems..............................14
2.4.2 Mastery of Advanced Functions of the Nastar Tool..................................................15
2.5 Summary............................................................................................................................ 16
3 Three Steps of Performance Analysis and Quality Early Warning.........................................17
3.1 Step 1: Knowledge of Network Conditions.........................................................................17
3.1.1 Historic Performance Index of Network...................................................................18
3.1.2 Parameter Revision History.....................................................................................21
3.1.3 Network Operation History.......................................................................................24
3.2 Step 2: Preparations for Performance Analysis..................................................................24
3.2.1 Starting Time of Performance Analysis and Quality Early Warning..........................24
3.2.2 Preparation of Master Data......................................................................................25
3.3 Step 3: Ideas and Methods of Performance Analysis and Quality Early Warning...............27
3.3.1 Conventional Methods of Performance Analysis......................................................27
3.3.2 Analysis Method of Alarm Data................................................................................28
3.3.3 Quick Analysis of Some PIs.....................................................................................34
3.3.4 Commonly Seen PIs and Corresponding Analysis Idea...........................................34
3.3.5 General Idea of Performance Analysis and Quality Early Warning..........................35
3.3.6 Procedures and Methods of Performance Analysis and Quality Early Warning.......36
4 Observation Point and Analysis Examples of Typical Problems............................................50
4.1 Observation Points of Typical Problems.............................................................................51
4.1.1 RRC Establishment Analysis Observation Point......................................................51
4.1.2 RAB Establishment Analysis Observation Point......................................................54

4.1.3 Call Drop Analysis Observation Point......................................................................57

4.1.4 Soft Handover Analysis Observation Point..............................................................60
4.1.5 CS/PS Intersystem Handover Analysis Observation Point......................................61
4.1.6 Traffic Analysis Observation Point...........................................................................66
4.1.7 Key Interface Flow Analysis Observation Point........................................................68
4.1.8 HSDPA Analysis Observation Point.........................................................................72
4.2 Example of Analysis Based on Observation Point..............................................................72
4.3 Summary............................................................................................................................ 77
5 Closing of Performance Analysis and Quality Early Warning................................................78
5.1 Basic Requirements for Analysis Conclusion.....................................................................78
5.2 Output Analysis Report....................................................................................................... 79
5.3 Summary............................................................................................................................ 79
6 References................................................................................................................................... 80

Figures
Figure 1 Measurement of performance index........................................................................13

Figure 2 Trend figure of call drop rate....................................................................................20
Figure 3 Revision history of baseline parameters..................................................................23
Figure 4 History of network operations...................................................................................24
Figure 5 Alarm analysis processing flow................................................................................29
Figure 6 Performance analysis flow.......................................................................................37
Figure 7 Performance analysis flow (Continued)...................................................................38
Figure 8 Performance analysis of RRC establishment success rate......................................45
Figure 9 Performance analysis of RAB establishment success.............................................47
Figure 10 Special topic analysis............................................................................................. 51
Figure 11 General information about RRC setup...................................................................73
Figure 12 Distribution of RRC setup scenario........................................................................74
Figure 13 Comparison of RRC setup scenario success rate..................................................74
Figure 14 Analyzing the cause of RRC rejection....................................................................75

Guide to Analysis of WCDMA Network Performance
Keywords
Performance analysis, quality early warning, KPI, Nastar tool
Abstract
Network performance analysis and quality early warning aim to accurately and
effectively find network performance and quality problems and give early warnings.
This document describes the general ideas, methods and procedures of UMTS
network performance analysis and quality early warning. It is intended to provide
reference for analysis operations and early warning actions of various regional
divisions and representative offices and to improve the efficiency of UMTS network
performance analysis and quality early warning.
Acronyms and Abbreviations
Abbreviation Full Spelling
ALCAP Access Link Control Application Part
APS ATM Protection Switching
CCP Communication Control Port
CDL Call Detail Log
CDR Call Drop Rate
CE Channel Element
CHR Call History Record
CHR Calling History Record
CN Core Network
GPS Global Positioning System
IOS Intelligent Optimization System
KPI Key Performance Index
MSP Multiplex Section Protection
MTP3B Message Transfer Part

Abbreviation Full Spelling
NCP NodeB Control Port
NEMU NodeB Environment Monitor Unit
NMON NodeB Monitor Unit
NodeB NodeB
PI Performance Index
RAB Radio Access Bearer
RF Radio Frequency
RNC Radio Network Controller
RRC Radio Resource Control
RRU Radio Remote Unit
SAAL Signaling ATM Adaptation Layer
SCCP Signaling Connection Control Part

1 Overview
A commercial network requires regular performance analysis and observation of QoS

and running status, together with a timely early warning of abnormal or potential risks.
Network performance analysis and quality early warning offer direct guidance to
network optimization and expansion.
Performance analysis and quality early warning aim to accurately and effectively find
network performance and quality problems and give early warnings. What skills must
network optimization engineers and network maintenance engineers master to
monitor a network effectively? What principles, flows and procedures must be
followed in performance analysis and quality early warning to ensure the accuracy
and timeliness of analysis results? Based on Huawei's performance analysis practice
in multiple commercial UMTS networks and the analysis experiences of the
Performance Dept. and the Tool Dept., this document expounds the flows and
procedures of performance analysis and quality early warning, together with other
related precautions.
In this document:
Version of the performance analysis tool: NastarV400R001C03B020
RNC version: BSC6800V100R006C01B071
NodeB version: BTS3812EV100R006C02B040
1.1 Purpose of the Document

In network performance analysis, engineers often encounter the following problems:
1) How to start network performance analysis? What skills are prerequisite to
effective network monitoring?
2) How to make performance analysis? How to make a fast, effective analysis by
using so many performance indexes (PIs) provided by traffic statistics tools? Is
there any reasonable flow?

3) I do not know much about internal implementation of product modules, nor can I
understand many CHRs. Can I make performance analysis? To what extent
does performance analysis depend on a mastery of CHR?
4) For multiple abnormal KPIs, the Nastar tool offers the causes such as
RF.RLCRst, RF.ULSync and UuNoReply. How to make further analysis?
5) If the call drop rate of a network PS is 5%, is any early warning needed? What
are the early warning principles?
Some other questions are not listed here.

In the first performance analysis, engineers tend to make a mistake: They expect to
find the one-to-one correspondence between traffic statistics PIs and causes of
problems. They first export a large quantity of traffic statistics indexes in analysis. For
example, they export WCDMA Performance Monitoring Report from the Nastar tool
once every week and pick out abnormal PIs. Then, they expect to find out the causes
of those abnormal PIs from an encyclopedia.
The causes of some problems, such as cell power resource congestion (Power.Cong)
and IUB bandwidth restricted (IUB.Band), can be directly found from the PIs of the
Nastar tool. But it is very hard to find out the causes of many network problems
simply by querying PIs. The complexity of a UMTS network determines that
performance analysis and quality early warning are comprehensive and systematic.
These jobs require that analysts should master necessary skills and use normalized
methods to analyze network performance while getting familiar with current network
conditions.
This document does not aim to provide a valuable book, through which performance
analysts can easily analyze the running quality and performance of a network simply
by querying traffic statistics KPIs. Instead, by expounding the general ideas and
necessary procedures of performance analysis, the document normalizes network
analysis and early warning actions and corrects network monitoring mistakes, to
improve the efficiency of performance analysis and quality early warning.
1.2 Users of the Document

This document is directly intended for the network optimization engineers and
network maintenance engineers of regional divisions and representative offices.
Performance analysis and quality early warning require a good knowledge of on-site
network conditions and network operations, and fast analysis and location of changes
in performance indexes.
This document can also be used for reference by other network monitoring engineers.
In remote network performance analysis, the engineers in the Headquarters or other
engineers need to get the latest traffic statistics data and know about the recent
network operations. To gain a decisive victory a thousand miles away, the first and

foremost prerequisite is to acquire a good knowledge of the war situation a

thousand miles away.

2 Necessary Conditions of
Performance Analysis and Quality Early

Warning
The necessary skills of performance analysis and quality early warning include being
familiar with signaling flow and basic principles, knowing about traffic statistics PIs of
product implementation, and mastering each function of the Nastar tool. The following
expounds these skills one by one, but the emphasis is laid on the extent of mastery
and the methods of a quick mastery.
2.1 Creating Network Planning and Network Optimization

Parameter Archives
Parameter monitoring is an important task of network monitoring as well as an
important means of knowing about network performance transition. For every
monitored network, we should first create initial network planning and network
optimization parameter archives. Then, we should make timely maintenance to keep
them consistent with actual system configuration. For a network managed by Huawei,
we may set up a flow or a mechanism to notify customers before changing any
parameter to synchronously update both parties parameters. Practice proves that this
may greatly reduce performance hazards caused by human factors. For other
networks, customers may maintain networks themselves by updating regularly, or
updating parameter archives in case of any big change in networks, such as upgrade
and problem optimization. For specific templates and parameter values, see Guide to
WCDMA Parameter Setting of the corresponding on-site RNC version. In actual
operations, we should keep complete operation records. For details, see
3.1.2Parameter Revision History.

2.2 Signaling Flows of UTRAN and Basic Principles of

WCDMA
2.2.1 Mastery of Signaling Flows and Basic Principles
Case: In several cells of a site, traffic statistics analysis shows that the success rate
of RRC connection establishment decreases and that the cause of RRC connection
failure is mainly RRC.Fail.ConnEstab.NoReply. In the performance analysis of this
problem, engineers wonder whether too small CCP bandwidth configuration of this
site makes RNC unable to receive any Complete response from UE. May I ask
whether the Complete message is related to restricted CCP bandwidth? How is an
RRC connection established based on the protocol stack of the Uu interface and the
Iub interface? When RRC is set up on dedicated channels and common channels
respectively, what are the differences in the signaling flow and protocol stack
implementation?
The Nastar tool provides the query of numerous indexes oriented to service process,
algorithm process and resource use. The counter implementation of these indexes in
a product is based on the following:
6) Signaling flows of the UTRAN, such as RRC connection establishment flow, RAB
establishment flow, and soft handover flow.
7) Specific statistics in protocol modules, such as counter statistics in
RLC/MAC/PDCP protocol modules and link measurement counter statistics in
SAAL/MTP3-B modules. We can achieve an accurate understanding of these
statistical points only if we have mastered the basic principles of WCDMA
network planning and got familiar with protocol stacks of standard interfaces.
A good knowledge of the protocol stacks and service flows of WCDMA enables
performance analysis to have a definite object in view. The Nastar template provides
the query functions oriented to basic PIs, but an analysis of these PIs alone cannot
easily help find network problems. If you are familiar enough with signaling flows and
basic principles, you can skillfully pick out other PIs from traffic statistics indexes and
make an auxiliary analysis. You can better understand the internal relations between
abnormal KPIs and coverage, uplink interference, load or transmission. This makes
your analysis go in a right direction.
Some engineers who have just come into contact with performance analysis say that
when they see some abnormal indexes from the daily report of the Nastar tool, they
do not know how to make an in-depth analysis. In this case, first ask yourself whether
you are familiar enough with basic signaling flows of the UTRAN and protocol stacks
of WCDMA. If no, you cannot but be at a loss and need to take this lesson as soon as
possible. If you have mastered related knowledge points, you may participate in the
discussion of performance analysis methodology. The prerequisite to Chapter 3 of this
document is engineers mastery of basic flows and principles.

To sum up, the mastery of signaling flows and basic principles is necessitated by the
following:
1) Abnormality location and analysis can have a definite object in view. We can
quickly search for other related indexes based on flows and basic principles and
make an auxiliary analysis.
2) Getting familiar with flows and principles helps associate abnormal PIs with
network problems (such as coverage and interference) and roughly determine
the nature of problems according to abnormal PIs, to select corresponding
special topic functions (coverage and interference) of the Nastar tool for an in-
depth analysis.
3) The mastery of signaling flows and basic principles helps analyze CHR. Although
CHR is the implementation of product internal modules, a good knowledge of
signaling and basic principles helps quickly get involved in CHR analysis.
2.2.2 Fast Makeup of Knowledge Points
Performance analysis requires that engineers should master basic signaling flows,
get familiar with protocol stacks of standard interfaces and know about related
algorithms for product implementation. For numerous RRM algorithms, engineers
need to know about their concepts even if they cannot acquire a good knowledge of
them. If the analyzed commercial networks contain some algorithms, engineers need
to learn them well.
Those engineers unfamiliar enough with flows and principles are suggested to learn
the following slides to acquire a quick knowledge of signaling flows of basic services
get familiar with protocol stacks of various WCDMA standard interfaces and know
about basic functions of various protocol modules.
4) Advanced Training for W Network Planning----Signaling Flow.ppt
5) Advanced Training for W Network Planning ----WCDMA Handover Principles.ppt
If a network to be analyzed involves DCCC, HSDPA or CMB, you need to obtain
related information to form a basic concept of these algorithms or services before
making any performance analysis.
2.3 Familiarization of UTRAN PIs

After you have mastered basic signaling flows, you need to know about the statistics
of the performance indexes of the current product. Performance analysis is directly
based on these PIs provided by the product. For example, the product version
RNCV100R006B071 does not make statistics of the causes of RB configuration and
RB reconfiguration failure of CMB service. Therefore, we cannot make an in-depth
analysis of the cause of RB failure during CMB performance analysis.
In performance analysis, engineers need to keep querying Performance Index
Reference Help and HUAWEI RAN KPI for Performance Management of a
corresponding version. We must be familiar with common performance indexes and

measurement points. Only in this way can the second query of traffic statistics or
auxiliary query of PIs have a definite object. At present, the common analysis indexes
include RNC integrated performance measurement and cell measurement shown
in the following figure. Performance analysis engineers first need to get familiar with
the PIs of both. They also need to know as much about other PIs as possible to
broaden the vision of performance analysis.
Figure 1 Measurement of performance index
2.4 Use of the Nastar Tool

The most essential functions of the Nastar tool are performance query and
performance report. Both of the functions do not need separate training. After the
Nastar tool is installed, nearly everyone can use them. Performance analysts tool
skills should not always remain at the use of both the functions because that is far
from enough.
Performance analysts mastery of the Nastar tool includes the following three levels:

6) Provide performance analysis results at the level of traffic statistics PIs. Make a
special topic analysis of each service flow based on the familiarization of
signaling flows and the UTRAN KPI, and find out abnormal observation points in
a network. Some abnormal observation points correspond to problem causes
such as Power.Cong while most cannot such as RLCRst, ULSync, UuNoReply,
and so on. Analysis examples are shown in 4.2Example of Analysis Based on
Observation Point.
7) Analyze the relations between traffic statistics PIs and network problems. Define
the nature of such problems.
8) Analyze real network problems by combining the advanced functions of the
Nastar.
2.4.1 Relationship Between Traffic Statistics PIs and Network Problems
Through observation point analysis, we have been able to make a preliminary

analysis of network performance. According to observation point indexes such as
power resource congestion, restricted transmission resource, and insufficient code
resource, we can give a simple quality early warning. But there are still many other
performance problems from which we cannot conclude directly.
For example, call drop analysis shows that many causes of call drop are RLCRst,
ULSync, and UUNoReply. How can we make an in-depth analysis? As shown in the
following table, the learning of signaling flows and basic principles, and topical
analysis practice may help summarize and analyze possible causes of abnormal PIs.
Table 1 Relationship between traffic statistics PIs and causes of call drop
Abnormal Mobile
Actual Cause of
OM Operation
Transmission
Interference
Equipment
Call Drop
Abnormal
RF Cause
Overload
Uplink
Phone
Flow
Traffic
Statistics PIs for Call Drop
VS.RAB.RelReqCS.OM
VS.RAB.RelReqCS.RABPreempt
VS.RAB.Loss.CS.RF.RLCRst
VS.RAB.Loss.CS.RF.ULSync
VS.RAB.Loss.CS.RF.DLSync
VS.RAB.Loss.CS.RF.UuNoReply
VS.RAB.Loss.CS.Aal2Loss
VS.Call.Drop.CS.Other

Other special topics, such as RRC access, soft handover, and CS foreign handover,
can also be summarized and analyzed similarly. Performance analysis itself is a
process of continuous experience summarization. We can directly find out the causes
of some PIs, but we can only define the scope of problems for some others and
determine the idea of subsequent analysis according to the scope. If you are not so
skilled in summarizing the relationship between traffic statistics PIs and network
problems, you may make a classified analysis as described in the above table. When
experience is accumulated to some extent, you can govern by doing nothing that
goes against nature. That is, upon seeing any abnormal PI, you can naturally
determine the scope of the problem, have a clear idea of next step and judge what
advanced function of the Nastar tool should be selected for an in-depth analysis (The
next section describes the advanced functions of the Nastar).
2.4.2 Mastery of Advanced Functions of the Nastar Tool
Problems: What functions does the Nastar for WCDMA tool have? Can you really
skillfully use the Nastar tool? Consultation to many performance analysis engineers
shows that not many of them can skillfully use each function of this tool. Many people
use the Nastar tool only for simple query of traffic statistics indexes and fast output of
reports.
The Nastar for WCDMA tool integrates years of Huaweis experiences in network
optimization of WCDMA. It uses the method of data analysis and data mining by
discarding the dross and selecting the essential and eliminating the false and
retaining the true. Fast and effectively, it analyzes network performance and locates
network fault. The Nastar tool is the crystallization of the wisdom of the R&D,
Performance Dept., Maintenance Dept. and Network Planning and Optimization Dept.
of Huawei. Powerful enough, this tool is not used only for fast output of reports and
customized query of traffic statistics indexes. Performance analysts must master each
function of the Nastar tool.
In an in-depth analysis of network performance, we need to use various functions of
the Nastar tool flexibly. To sum up, performance analysis is how to determine the
scope of problems from the whole to the part, how to define the nature of problems
from traffic statistics PIs and how to properly select related functions of the Nastar for
an in-depth analysis. Chapter 3 describes how to determine the scope and nature of
problems, but a skillful use of various functions of this tool is the basis for
performance analysis.
In an in-depth performance analysis, the following functions of the Nastar tool need to
be used:
9) Customization and second query of PI
10) Optimization solution to Intra-frequency adjacent cell

11) Pilot pollution solution. In pilot pollution analysis, no IOS data needs to be
imported, but CHR, PERF/engineering parameters and configuration files should
be imported.
12) Coverage analysis solutions. When traffic statistics analysis shows that there is
the problem of coverage within a cell, we need to make IOS tracing and import
the traced IOS data to Nastar for coverage analysis. This coverage analysis
includes common downlink pilot channel coverage analysis, link quality analysis,
and overshoot analysis.
13) Interference analysis solutions. Interference analysis helps effectively find out
external interference or internal problems of equipment. By means of main-
diversity signal strength analysis and according to certain algorithms, we can
locate multiple possible causes of radio interference or abnormal signal.
Interference analysis is a small but practical function. It helps on-site engineers
find problems. The master data of interference analysis includes RTWP data,
configuration data, and engineering parameters.
14) Configuration verification
15) CHR analysis means
The advanced functions of the Nastar will not be described further in this document. If
you need them, please query the Help of the Nastar tool and master each function
through repeated practices.
2.5 Summary
Chapter 2 mainly describes the knowledge and skills required for performance
analysis and quality early warning. It includes the understanding of UTRAN signaling
flow and basic principles, the familiarization of the UTRAN KPI and the mastery of the
functions of the Nastar tool. These three parts are associated with each other.
Signaling flow and principles are the very basis. We can understand each PI of a
product only when we have mastered signaling flow and principles. Based on the
familiarization of each PI, we can gradually master each function of this tool through
special topic practice of the Nastar.
Having laid a solid foundation, we can effectively make network performance analysis
and quality early warning by combining the methodology described in Chapter 3.

3 Three Steps of Performance
Analysis and Quality Early Warning
In reality, performance analysis and quality early warning include three steps:
knowledge of network conditions, preparations for performance analysis, and
methods and flows of performance analysis. Among the steps, there is a definite
sequential relationship. Each step helps gradually determine the scope and nature of
network problems. Then, we analyze, conclude and judge whether an early warning
to network quality is needed.
3.1 Step 1: Knowledge of Network Conditions

Case: An engineer undertook responsibility for the performance analysis of a network.
Two weeks later, I consulted him about the trend of voice call drop rate of this network
last month and difference between the call drop rate of workdays and that of holidays.
He answered he did not know. When I asked him what operations of upgrade or
cutover were made in this network last month, he answered he did not know. When I
asked him what modifications were made to the parameters of this network in the
past month, he answered he did not know. This engineer makes network analysis in
the following way: He exports the traffic statistics PIs of this network from the Nastar
tool once a week. Then, he browses various indexes, and gives an analytical
conclusion to those apparently abnormal PIs, such as transmission restricted and
power congestion. For those cells with abnormal PIs and with cause value equal to
other, he browses CHR to look for any clue.
Apparently, such performance analysis is too casual. An analysis and comparison of
performance indexes should be based on early records of this network. We should
not simply make a lateral comparison with other networks or apply baseline indexes
mechanically. The baseline indexes defined by Huawei are only for reference or final
standard requirements. At present, each network has respective coverage and

capacity. Accurate analysis and high-quality early warning must be based on the
present conditions of this network.
Before making performance analysis, we need to acquire a good knowledge of
present network conditions, including early network performance indexes,
modification records of network parameters, and operation history of networks.
3.1.1 Historic Performance Index of Network
Network performance analysis includes normal performance analysis and specific

performance analysis. Generally, a commercial network focuses on normal
performance. As shown in the following table, normal performance includes traffic
analysis, call completion rate analysis, handover analysis, and call drop rate analysis.
Table 1 Normal performance KPI of network
AMR DL12.2 Erlang
VP DL Erlang
CS Erlang
Traffic PS UL Erlang
PS DL Erlang
PS UL Throughput
PS DL Throughput
RRC Connection Setup Success Rate (service) (>98%)
RRC Connection Setup Success Rate (other) (>95%)

R99
Access AMR RAB Assignment Success Rate (>98%)
Video Call RAB Assignment Success Rate (>98%)
PS RAB Assignment Success Rate (>97%)
Soft Handover Factor based on Radio Link Number (<50%)
Soft Handover Success Rate (>99%)
Inter-Freq Hard Handover Success Rate (>95%)

HO
CS Inter-RAT Handover Success Rate (from UTRAN to GSM)
(>96%)
PS Inter-RAT Handover Success Rate (from UTRAN to GSM)

(>92%)
CDR CS AMR Call Drop Rate (<1.5%)

VP Call Drop Rate (<3%)
PS Service Drop Rate (<5%)
HSDPA RLC Traffic Volume (MBytes)
Traffic HSDPA Mean UE
HSDPA RLC Throughput (Mbps)
Access HSDPA RAB Setup Success Rate (>97%)
HS-DSCH Service Cell Change Success Rate (with SHO)(>99%)

HSDPA:
HS-DSCH Service Cell Change Success Rate (with Intra HHO)

(>95%)
HO HS-DSCH Service Cell Change Success Rate (with Inter HHO)

(>95%)
HS-DSCH to DCH Handover Success Rate (>95%)
DCH to HS-DSCH Handover Success Rate (>95%)
CDR HSDPA Service Drop Rate (<5%)
Specific performance analysis means that this network has specific functions or
algorithms and that specific attention should be paid to these functions or algorithms.
For example, if network provides HSDPA, HSUPA, and MPMS services, records of
performance indexes must contain corresponding KPI.
For each normal or specific performance which requires continuous observation and
analysis, engineers must keep history. They had better archive them in the form of
visual figures or trend tables (also save corresponding DATA), and update them
anytime. Keeping a record of performance indexes helps an overall observation of the
running quality of a network within a period of time, and makes engineers more acute
to analyze network indexes and judge whether any in-depth location analysis is
needed.
The following trend figure shows the voice call drop rate and VP call drop rate of a
network in a period of time.

Figure 2 Trend figure of call drop rate
The trend figure clearly shows the call drop trend of this network in the past months.
When we get any new data of call drop rate, we need to compare it with the recent
indexes in this figure to judge whether the call drop rate is abnormal.
In the early days of network commercialization, when indexes were not stable
enough, more information should be recorded for comparison. For example, when
analyzing call drop rate, we may record top 10 cells of a certain day or week. In a
subsequent comparative analysis of call drop rate, we have more pertinent
information.
The following table shows the PS call drop analysis of TOP10 cells in a network on a
certain day.
Table 1 PS call drop analysis of top 10 cells
PS Call Drop(2006-08-18) PS Call Drop Rate(2006-08-18)
PS Call PS Call
CellId CellName CellId CellName
Drops Drops rate
22192 KingNamH_CDE 116 58681 MKK_A 90.27%
58681 MKK_A 102 16181 Ellen_AB 35.39%
14282 EHTunnl_B 83 16351 ManHong_ABE 40.96%
16351 ManHong_ABE 77 16352 ManHong_CD 35.68%
16352 ManHong_CD 71 22191 KingNamH_AB 61.54%
22191 KingNamH_AB 64 22192 KingNamH_CDE 18.38%
16181 Ellen_AB 63 44441 TsLokEst_AD 36.59%

PS Call Drop(2006-08-18) PS Call Drop Rate(2006-08-18)
PS Call PS Call
CellId CellName CellId CellName
Drops Drops rate
44461 UWTSEst_A 56 44461 UWTSEst_A 30.11%
58111 DyPlzCi_A 40 58111 DyPlzCi_A 90.91%
44441 TsLokEst_AD 30 14282 EHTunnl_B 41.50%
In subsequent analysis of PS call drop rate, we may make a comparative analysis of

top ten cells and observe whether any change has taken place, whether the PS call
drop indexes of these cells rise abnormally. Based on recent network parameter
modifications and network operations, we judge whether any in-depth performance
analysis is needed.
Other KPIs that need a careful observation, such as call completion rate and foreign
handover success rate, need to be similarly recorded as described above.
3.1.2 Parameter Revision History
Parameter revision during network optimization requires clear records. The impact of
parameter revision on networks can be analyzed by combining revision history and
performance indexes of traffic statistics. If traffic is not heavy, the impact of regional
parameter revision on KPI may be unapparent, nor can it be easily observed. But
when traffic rises suddenly some day, if early parameters are unreasonable, the bad
impact of parameter revision on KPI will be clearly seen. A complete record of
parameter revision may contribute to network performance analysis.
For example, the following table shows the revision history of a network. When
creating a parameter revision history table, performance analysis engineers may give
flexible consideration, but the general principle is visual. Thus, query can be made in
the order of revision time. If the revision history involves any specific region, they
must be clearly marked.
Revision of On-Site Baseline Parameters
NO Date Problem Description
Change the maximum permissible uplink transmit power to 24

because some mobile phones support the maximum transmit
1 2006.01.02 power of 24 dBm. Increase this parameter to improve restricted
uplink coverage. See the tables Cell_SelReselParas_CR and
Cell_CACParas_CR.
2 2006.01.03 Adjust the maximum and the minimum downlink power of

voice, VP, PS64, PS144, and PS384 according to on-site

optimization to improve network quality and call drop. See the

table Cell_TrafficPower_CR.
Change the intra-frequency rerouting starting threshold to -4

3 2006.02.04
dBm. See the table Cell_SelReselParas_CR.
Change the admission and congestion parameter settings of

4 2006.02.05 Hong Kong Island. For details, see CELL_CACPara and
CELL_LCCPara.
Change intra-frequency measurement parameters including

Layer 3 filtering coefficient, 1A1B relative threshold, and delay
5 2006.02.06
trigger time and so on. See the table
Cell_IntraFreqHOMrParas_CR.
For some cells to tunnels and underground 3G-2G handover

and change of inter-RAT measurement starting threshold and
6 2006.02.07
decision threshold, see the table
Cell_IntraFreqHOMrParas_CR.
Turn on the common channel flow control switch of the IUR

7 2006.02.08 interface because an IUR interface is configured between the
RNC1 and RNC2 of the current SUNDAY.
Adjust the inter-frequency power of some cells from 33 dBm to

a smaller value. The reasons are as follows:
NodeB is a 10 W base station and its inter-frequency power is
30 dB.
8 2006.03.09
Share indoor distribution system and RF requirements with
other operators.
In network optimization, the inter-frequency power of some
cells is adjusted to 30 or 28 dBm.
9 2006.03.10 Turn on the UE state transition switch.
The static transition switch is turned off to avoid the possible

10 2006.03.11 call drop caused by some mobile phones not supporting static
transition.
The downlink blind detection switch is turned off to avoid one-

11 2006.03.12 way audio caused by some mobile phones not supporting blind
detection.
T314 and T315 are set to 0. Disable Cell Update caused by

12 2006.04.13
RLFAILURE.

Change the number of continuous synchronization indication to

13 2006.04.14
1. See the table CellBasicInfo.
Change the minimum access quality to -20 dB. See the table
14 2006.04.15
Cell_SelReselParas_CR.
Change times of random access preamble retransmission to 20

15 2006.04.16
times. See the table CellPrachParas.
To avoid poor streaming quality caused by code transmit power

limit, the maximum service code transmit power of PS 144 is
16 2006.05.17
increased by 2 dB and is the pilot channel power +2 dB. See
the table Celltrafficpower.
To check the adjacent cells that miss configuration or potential

17 2006.05.18 adjacent cells, turn on the monitoring set reporting switch. See
the table SWITCH.
The uplink BE service rate negotiation threshold is 8K and the

18 2006.05.19 downlink BE service rate negotiation threshold is 64K. See the
table SWITCH.
Add cell location configuration information. The maximum

19 2006.06.20 coverage distance of a cell antenna is 500 m. Activate the
AGPS location activation identifier. See CellSMLCParas.
The maximum retransmission times of location measurement

20 2006.06.21
can be set to 0. See the table SWITCH.
The hard handover hysteresis is 6 (3 dB). 2D trigger time is

21 2006.07.22
640 ms.
NBMULCACALGOSELSWITCH uplink admission switch is

22 2006.07.23
turned off. See the table SWITCH.
Change inter-RAT cell reselecting starting threshold

(Ssearchrat) to 3, inter-frequency cell reselecting starting
23 2006.07.24
threshold (Sintersearch) to 5 and intra-frequency cell
reselecting starting threshold (Sintrasearch) to 8.
Figure 3 Revision history of baseline parameters
Baseline parameter records may as well indicate known defects and patches of the
current version. There is no product version without any defect. Sometimes there is a
product BUG. Sometimes there may be restricted algorithm function. The network

analysis of a certain version demands a good knowledge of the known defects of a

product.
3.1.3 Network Operation History
Network operation records include the cutover of NodeB, the upgrade of RNC and
NodeB, and transmission expansion. They aim to help a comparative analysis of
traffic statistics index and a quick analysis of network performance.
Refer to the following network operation records.
Figure 4 History of network operations
When engineers start performance analysis, they must get related network operation
records. Generally, customers or on-site customer service will maintain a related
record table.
3.2 Step 2: Preparations for Performance Analysis

3.2.1 Starting Time of Performance Analysis and Quality Early Warning
3.2.1.1 Periodic Analysis
In a stable commercial network, performance analysis and quality early warning are
periodic. It generally includes daily report analysis and weekly report analysis. Daily
report analysis ensures timely network monitoring. It helps quickly find and eliminate
any burst KPI deterioration. In daily report analysis, users distribution (workdays and
holidays) and their calling habits (commuter time and working time) may cause small
KPI fluctuation in the observed time period. For a region with small traffic, call drop
rate, call completion rate, and handover success rate are of no statistical significance.
We should not analyze network performance problems according to them alone.

With a week as the unit, weekly report analysis has more statistical sample points.
According to one-week statistics, we may give an accurate early warning to traffic
change, transmission, power, and code resource. Thus, we can more easily find
network problems such as coverage, interference, and pilot pollution.
Performance monitoring requires that the same emphasis should be laid upon daily
report analysis and weekly report analysis. Daily report analysis helps eliminate burst
influence, such as base station reset and intermittent transmission failures. Weekly
report analysis helps locate network coverage problems and interference problems.
Quality early warning actions include comparative check of whole-network
parameters, check of whole-network unidirectional adjacent cells, and check of
whole-network missing adjacent cells and pilot pollution. These actions are
periodically executed. The period can be flexibly set according to the frequency of
network parameter modifications or operations. Quality early warning actions may be
fully executed once a month or a quarter.
3.2.1.2 Trigger Analysis
Normal performance monitoring period takes day as the minimum unit. Use the
Nastar tool to output Daily report to observe network KPI and judge whether an in-
depth analysis is needed. Several scenarios are triggered by events. When a
corresponding event happens, we need to get traffic statistics data and make a
detailed analysis. The granularity of traffic statistics data is generally less than 24
hours. We may need to analyze the traffic statistics data for half a day (or a whole
day) or several hours. In the following cases, traffic statistics KPI needs our major
concern.
16) Important holidays: During important holidays, such as the Spring Festival,
Christmas Day, Buddhas Birthday, and Pilgrimage to Mekka, the network traffic
of this region will climb to a new high. As to whether product equipment and
network design can withstand large-scale traffic shock, we need to upload traffic
statistics data hour by hour and monitor network performance at any moment.
17) Equipment upgrade and major parameter modification: For general upgrade and
parameter modification, we may analyze the network KPI by observing Daily
report. For highly risky upgrade and parameter modification, we need to get
traffic statistics data quickly and make an analysis with the granularity of 12 or
six hours.
18) Natural disaster: Earthquakes or typhoon may have a direct impact on networks.
To avoid affecting network communication, we need to analyze traffic statistics
data as soon as possible and observe the extent of the damage to networks.
3.2.2 Preparation of Master Data
The master data of performance analysis must be accurate, timely and integral.
Accuracy means that Nastar engineering parameters must be very accurate and will
be updated along with RF adjustment of network. Timeliness means that traffic

statistics data of network needs to be uploaded as soon as possible. Data integrity

means that no traffic statistics data should be omitted. Otherwise, there may be
relatively fewer call attempts and call drop times of a network or a cell, which cannot
fully reflect network quality.
Specifically speaking, master data includes:
19) Nastar engineering parameters. Multiple analysis functions of the Nastar tool,
such as missing adjacent cell analysis, interference analysis, and coverage
analysis, are closely related to engineering parameters. The accuracy of
engineering parameters determines the credibility of related analysis results of
the Nastar tool.
20) Traffic statistics data
21) Configuration data
22) CHR data. It is not used only for CHR analysis of the Nastar tool. In missing
adjacent cell analysis and unidirectional adjacent cell analysis, CHR data is
needed. If CHR data is only used for abnormal flow location analysis, we may
selectively import CHR data according to the frame number of a cell to be
analyzed.
23) RTWP data (optional). It is chiefly used for interference analysis. It may be
omitted if interference analysis is definitely unnecessary.
24) IOS data (optional). It is used for an in-depth location analysis of many network
abnormality problems, such as coverage.
25) General schedule of engineering parameters (optional). It is required for
geographic analysis.
CHR data records the information generated during a call. It will be recorded in the
call logs of the system if some conditions are satisfied. It may record the signaling
flow status before the call drop of a mobile phone, measurement report information
reported by a mobile phone before call drop and signal condition when a mobile
phone is accessed. In summary, CHR is oriented to all users involved in 3G services
and records the context information of a mobile phone in a conversation. It is output
when preset conditions are satisfied.
IOS sampling tracing is to start measurement oriented to one or more users within a
cell according to preset conditions. Sample data can be set. IOS sampling tracing is
active data collection initiated by users. It may require that a mobile phone should
actively report the measurement reports on the mobile phone side, such as downlink
pilot RSCP and EcIo, or require that NodeB and RNC should report special
measurement information.
In contrast, CHR data traces all the users within a RNC that satisfies tracing
conditions. It covers a large scope. IOS traces one or more users within a specific
cell. It covers a small scope, but goes deeper.
As to the use of RTWP data and IOS data, we generally determine whether to start
the interference analysis and coverage analysis of the Nastar tool for an in-depth

performance analysis according to early performance analysis. If it is really

necessary, we need to start tracing to get RTWP data and IOS data.
3.3 Step 3: Ideas and Methods of Performance Analysis and

Quality Early Warning
This part summarizes the early experiences of multiple commercial networks in
performance analysis, and educes section 3.3.2General Idea of Performance
Analysis and Quality Early Warning from historical experiences. According to the
general idea, section 3.3.3Quick Analysis of Some PIs systematically describes the
methods and procedures of performance analysis.
3.3.1 Conventional Methods of Performance Analysis
For different network problems, there are different methods of performance analysis.
Acquire a good knowledge of the running status and problems of existing network,
and then select one or more proper analytical methods. The commonly used methods
of performance analysis are as follows:
26) TOPN worst cell

According to traffic statistics indexes such as call drop rate, connection success rate,
and soft handover failure rate, get the busy-hour average or all-day average as
required, find out the worst N cells, and make them as the emphasis of fault analysis
and optimization. Or you may determine the priority order of optimization based on
this.
27) Time trend figure

Trend figure of traffic statistics index is a commonly used method of traffic analysis.
Analysis engineers may draw the change trend figure of one or more indexes of the
whole network, Cluster or a single cell by hour, day or week and find the change law
of traffic statistics indexes.
28) Region location

The change of network performance index always takes place in some regions.
Traffic increase, traffic model change, radio environment change, base station faults
or uplink/downlink interference leads to the index variation of these regions. The
index variation affects performance indexes of the whole network. We may compare
the network performance indexes before and after the variation, mark the base station
or sector with the greatest network performance variation on an electronic map, and
make a detailed analysis of problematic regions.
29) Contrast
A traffic statistics index is always affected by multiple factors. Some factors change
while others may not. We may properly select comparison objects, confirm the

existence of problems and analyze the causes. When observing indexes, we should
not focus on only their absolute values, but on their relative values.
Besides a longitudinal comparison, we should, if necessary, make a latitudinal
comparison of networks in different regions, for example, upgrade. We may refer to
the index change and causes after similar network upgrade.
3.3.2 Analysis Method of Alarm Data
Performance analysis is made by using the Nastar tool while alarm analysis is made
by using the Omstar. In the course of performance analysis, whether at the RNC level
or at the cell level, it is recommended to analyze alarm data first and confirm whether
any related equipment alarm affects PI. If equipment and transmission are both
normal, an in-depth analysis of specific PIs may greatly improve efficiency.
Alarm analysis methods must be used together with KPI analysis. An independent
analysis is meaningless, nor can it solve network quality problems effectively.
Generally speaking, the KPIs in our daily concern are traffic, access performance,
RAB establishment success rate, handover, and call drop. What alarms can these
KPIs be related to? We have simply classified service-related alarms as follows:
Performance of traffic: transmission congestion alarm, broken link alarm, and CE
resource congestion (DSP abnormality alarm)
RRC access performance: related to congestion alarm, such as CN congestion, CPU
congestion, base station baseband congestion, and IUB interface transmission
congestion
RAB establishment success rate: related to transmission congestion and RF
coverage
Handover performance: related to clock or resource congestion
Call drop rate: Call drop caused by RF and by unavailability of a cell or a base station
According to the above-mentioned characteristics, we associate KPIs with alarms
while analyzing problems. Then, we analyze traffic statistics indexes to determine
whether alarm is the root cause of the decrease in KPIs. If yes, recover alarm and
check whether performance indexes resume to normal.
In alarm analysis, there is no need to analyze the detailed cause of alarm generation.
We only need to analyze the extent of the impact of this alarm on network
performance. If this alarm does not affect network performance, analyze other
problems. If this alarm does affect network performance, we need to analyze how
alarm is associated with KPIs. If alarm is closely associated with KPIs, we need to
recover alarm to verify the correctness of analysis results. The general process is as
follows:

Deterioration of
network quality
Collect and
analyze alarm
information
No
Does the alarm
affect KPI?
Yes
Does the alarm No

correlate to the
decreased KPI?
Yes
Find out and

recover major
alarms
Yes
No
Does KPI resume Analysis of
to normal?
other problems
Ye
s
End
Figure 1 Alarm analysis processing flow
Network quality is always affected by one major alarm. In alarm analysis, we will find
that multiple alarms may affect service. Some of them are only accompanying alarms.
We need to distinguish between major alarms and accompanying alarms. Otherwise,
we cannot locate the root cause. The following table shows the impact of commonly
seen alarms on performance and is for your reference in problem solving.

Table 1 Alarm influence
Alarm Type Performance Impact
Trunk alarm has a fatal impact on network quality. If network

quality is worsened and there is any trunk alarm, it is generally
believed that it is trunk fault that causes worsening of the
network quality.
There are a variety of trunk alarms. Trunk alarm does not
necessarily lead to the worsening of network quality. This type of
alarm always has numerous accompanying alarms. We need to
combine associated alarms and make an analysis for accurate
location.
Some alarms will make a base station unavailable, thus causing
coverage hole. This may not be found from KPIs, but will cause
the cell of the base station adjacent to this base station to have a
greater probability of RF call drop. In the case of a large-scale
network, the impact is concealed. From the perspective of KPIs,
it can only be considered that this falls within the normal
fluctuation range. But the unavailability caused by this type of
Trunk alarm alarm will have a bad impact on users feelings. Maybe some
customers will make complaints. In this case, we should not
make an analysis only from the association of KPIs with alarm.
We need to focus on whether alarm makes a cell unavailable.
The impact of this alarm on KPI is implicit.
Loopback alarm, configuration alarm, and mismatch alarm do not
appear in network operation, so they do not deserve our
attention. Slip frame overrun alarm and high bit error alarm
depend on specific conditions. If they appear often, they will
have an impact on network quality. If they are seldom generated,
it can be believed that they have no impact on network quality.
Among the RNC alarms, the alarms about APS and MSP have
no impact on service. These are the alarms of additional
functions. If they are not used, this type of alarm does not appear
in network operation. Other alarms, more or less, affect service.
They affect capacity, access, handover, and call drop caused by
RF.

Most alarms may be signaling link alarms caused by trunk alarm.

In analyzing this type of alarm, we need to make clear whether
there is any trunk alarm. If there is any trunk alarm, we need to
analyze them by associating signaling link alarms with trunk
alarms. Note that NodeB categorizes AAL2PATH alarm as a
signaling alarm while RNC categorizes AAL2PATH alarm as a
trunk alarm.
Signaling alarm will unexceptionally have a certain impact upon
service, sometime a fatal impact. For example, NCP/ALCAP
alarm directly causes the unavailability of a base station, so a
coverage hole appears. The alarms of MTP3B link, SCCP and
SAAL link will have a direct impact on service availability. If the
Signaling alarm
link with a core network is interrupted, the link will also be
interrupted between UE and the core network. All related
services become unavailable.
Configuration error alarm, syntactical error alarm, unknown
message, and packet boundary-crossing may appear in
interconnecting partners equipment. But they will not affect
existing network quality if other processes are normal. The
system information 11 limiting adjacent cell data is an event
alarm. Handover is not affected either. Among RNC alarms,
there are some event alarms. If these event alarms are often
generated, they will affect network quality. If they seldom occur, it
can be believed that they do not affect network quality.
QoS alarm directly affects service communication quality and
KPIs.
For the alarms of NodeB, generally cell blocking appears in
network operation only when this cell is not needed. Therefore,
we need not pay any attention to this type of alarm. Simulated
load starting alarm is used for testing and does not appear in
network operation either. Cell unavailability will directly cause a
coverage hole. Call drop caused by RF will also appear. Too
QoS alarm small output power of a cell will also cause coverage problems
and there will be poor coverage in some places. This causes call
drop due to RF. From the perspective of KPIs, call drop rate rises
slightly.
The service alarm of RNC is an event alarm and affects service
slightly. But the loss of a large number of measurement results
may cause some algorithm problems, for example, power control
failure. If event alarms are often generated, they may affect
KPIs, but the impact is limited.

The alarms which involve a service board and a main control

board may affect service. The alarm of a board other than a
service board does not affect any network quality.
Among the hardware boards of NodeB, all the boards except the
NMON board are related to service. The alarms of these boards
may lead to deterioration of network quality. But the extent of
impact depends on alarm type. A RF board is also related to
Hardware alarm service and directly affects quality of the air interface of
networks.
All boards of RNC products are basically related to service.
Board hardware fault of the WRSS frame and WRBS frame may
deteriorate network quality. Power alarm and fan alarm do not
affect service. A faulty WGRU board affects location service, but
does not affect any other service or KPIs. Therefore, no
consideration should be given to this for the time being.
Software alarm Software alarm is generated by the running software part of a

product. It is unrelated to hardware structure, but closely related
to the software structure of the system. Among the software
parts of NodeB and RNC, some involve service while others are
not related to service, but related to equipment maintenance.
Software function alarms related to service need our attention.
Those alarms unrelated to service function do not need our
attention.
In analyzing the software alarm of NodeB, we need not pay any
attention to the alarms of the operation and maintenance part.
Other software alarms are generally unrelated to service and do
not appear in normal network operation. These alarms will be
involved only when there is any operation of system software
upgrade. But generally, the software upgrade of NodeB will
interrupt service.
In the software parts of RNC, the switching subsystem and the
service processing subsystem are related to service, but the
operation and maintenance subsystem is unrelated to service
and may not be considered.
The software alarms of RNC are mostly the alarms of the
operation and maintenance subsystem. That is, they are
associated with BAM database system. Host software alarm is
seldom seen and some are generated during network
construction. The alarms generated during network operation are

the KPIs which only affect network capacity and network access.
This type of alarm is generated when the software system runs

abnormally. Most of them are system abnormality caused by
software design defects after long-term running. They may also
be generated when system running exceeds software design
specifications. We need to know about product specifications
and functions before we analyze network quality well. Most
alarms are unrelated to service.
The running alarms of NodeB will mostly be seen during the
early days of network construction. This is because some
Running alarm configuration has not been fixed yet. These running alarms are
seldom seen during normal operation. LICENSE alarm and
DSP/CPU alarm will affect the capacity, access and handover of
the system.
The running alarms of RNC are mostly generated during network
construction because some configuration or parameter settings
are not fully frozen during network construction. These alarms
helps effectively analyze and solve some problems existing
during network construction. They will be eliminated in formal
network optimization to avoid affecting network quality.
Communication alarms are mainly internal communication

alarms of a product, especially the maintenance channel
communication between boards. Generally speaking,
maintenance channel fault does not affect any service, but
service channel fault is bound to affect service. When a
communication link generates any alarm, link fault will lead to
corresponding communication interruption.
The internal communication alarm of NodeB does not affect
Communication
normal service running.
alarm
The communication link of RNC is related to service, so the
interruption of internal links between corresponding boards will
have a certain impact as a trunk alarm does.
Among the communication alarms of RNC, BAM-related link fault
will not affect service, but the alarms which involve a board may
affect service. The impact is fatal and generally leads to the
unavailability of a cell or a base station. Thus, some coverage
hole problems appear.

An environment alarm generally does not affect the service and

KPI of the system. But some environment alarms deteriorate
Environment product performance or functions of some products. They will be
alarm analyzed accordingly. Among the environment alarms of RNC,
GPS antenna alarm affects only location service instead of any
other service.
Generally, power alarm does not affect service at all, but

Power alarm hardware alarm caused by power alarm may make service
abnormal. This case will be analyzed accordingly.
Processing error
Processing error alarm involves only RNC instead of NodeB.
alarm
3.3.3 Quick Analysis of Some PIs
According to the values of indexes, we can quickly analyze network performance

based on the following PIs:
Capacity PIs, such as downlink capacity, uplink capacity, effective utilization of
codes, and bandwidth utilization
Transmission index, such as aal2path
Cell unavailability duration VS.Cell.UnavailTime.OM
Before using the Nastar tool for an in-depth analysis, we may export the above-
mentioned commonly seen PIs and judge whether there is any problem with network.
This analysis method may greatly improve efficiency, but is not systematic enough.
3.3.4 Commonly Seen PIs and Corresponding Analysis Idea
30) Among the causes of call drop, if VS.RAB.Loss.CS.RF.RLCRst,

VS.RAB.Loss.CS.RF.ULSync, VS.RAB.Loss.CS.RF.DLSync, and
VS.RAB.Loss.CS.RF.UuNoReply take a large proportion, we should first analyze
RF problems.
31) Judge whether overload leads to abnormal release.
If VS.RAB.RelReqCS.RABPreempt leads to call drop for many times, it can be
confirmed that the cell load has reached the admission threshold. If congestion
makes many users released, it can be confirmed that the load of this cell has
reached the congestion threshold. We may also make an analysis by associating
call drop times with the downlink load of a cell. If the downlink load of a cell is
high within the period with much call drop (by viewing the indexes VS.MeanTCP,
VS.MinTCP, and VS.MaxTCP, or starting the downlink transmit power
measurement of this cell), start load problem analysis.

32) If call drop rate of the whole network suddenly becomes relatively high, generally
the following factors may lead to this and we need to make the following check:
(1) Iu interface transmission analysis: analyze alarms to see whether there is any
problem with the transmission for the Iu CS interface and the Iu PS interface. (2)
RNC equipment analysis: analyze alarms to see whether RNC boards reset and
whether there is any equipment fault. (3) whole-network traffic analysis: Find out
whether sudden increase in registered users and traffic leads to the increase in
call drop rate and check whether the system is upgraded or patched.

In dealing with special topic exercises, Chapter 2points out that there is need to
summarize the relationship between traffic statistics PIs and network problems
(section 2.4.1). This section summarizes commonly used experiences in analysis of
commercial networks. It also expounds the analysis idea of commonly seen PIs. The
abstraction of this experience forms the following parts:
3.3.5 General Idea of Performance Analysis and Quality Early Warning
By referring to the historical experience of performance analysis and considering the

analysis functions provided by the Nastar tool and the Omstar tool, we may
summarize the principles of performance analysis and quality early warning: gradually
narrow the scope of problems and define the nature of problems from the
macroscopical to the microscopical and from the whole to the part. For the problems
of different nature, we use respective functions of the Nastar tool for an in-depth
analysis and thus obtain analysis results.
Concretely speaking, the analysis idea can be summarized as follows:
33) First analyze RNC whole-network indexes macroscopically, and observe daily
reports and weekly reports to check whether KPIs are normal. Then, query other
PIs or cell indexes.
34) If KPIs are abnormal, it is recommended to make a comparative analysis of
TOPN cells and TOPN users. Observe whether regional deterioration or some
users leads to the decrease in whole-network KPIs and whether integral indexes
of network decrease. If there are a small number of on-net users, the abnormality
of an individual user or cell may probably affect whole-network KPI performance.
This is especially apparent in PS service.
35) If integral indexes of the network decrease, we need to analyze whether there is
any problem with RNC equipment or whether IU interface transmission is
restricted.
36) Whether RNC-level analysis or cell-level analysis, it is recommended to check
alarms first to make sure whether there is any problem with equipment and
transmission.
37) After defining the nature of problems, properly use different functions of the
Nastar tool for an analysis.

3.3.6 Procedures and Methods of Performance Analysis and Quality Early

Warning
3.3.6.1 Flowchart of Performance Analysis Procedures
According to the general idea, we may determine the specific procedures of

performance analysis and quality early warning. It is mentioned in 3.2.2Preparation
of Master Data that RTWP data and IOS data can be obtained only if there is specific
tracing, and is needed only at a specific stage of performance analysis.
The following flowchart shows the main procedures of performance analysis, but the
performance analysis flow is not completely a one-way process. From the perspective
of time, performance analysis is also a day-after-day process of gradual analysis,
repeated optimization and continuous observation. After a problem is analyzed,
possibly there is need to adjust parameters, increase transmission and solve
equipment problems. Upon finishing network optimization and network maintenance,
continue observing network indexes, contrastively adjust traffic statistics performance,
and confirm the effects after the change. From the perspective of flow, we may omit
some procedures or lay an emphasis upon the observation of a certain part according
to on-site scenarios.

(1) Overall analysis of Whole-

network KPI network
traffic
statistics
Is there any KPI N

deterioration?
END
Traffic
(2) RNC equipment/IU
statistics
transmission/parameter Alarm
Is there any Y
equipment Solve RNC equipment/IU
problem/transmission transmission problems.
fault?
N Cell traffic
(3) KPI analysis of TopN statistics
cells
Cell traffic statistics

(4) Analysis of cell-related
RNC and Node B
equipment
alarm
Is there any cell Y

Solve cell equipment
equipment
problem? problems
N
Traffic statistics: IUB
(5) Analysis of cell load bandwidth
problems CE resource
Equipment resource
Radio resource
Is there any Y
overload Solve overload problems
problem?
Figure 1 Performance analysis flow

CHR: NodeB RTWP

(6) Analysis of cell Cell load information
interference problems Special interference
analysis
Y
Is there any
interference Solve cell interference
problem? problems
N
CHR:
Pilot pollution
Extraction of coverage
(7) Analysis of cell information
coverage problems IOS Trace:
Analysis of cell coverage
quality
Y
Is there any Solve cell coverage
coverage
problem? problems
N
CHR:
Optimization of
(8) Analysis of cell adjacent cells
parameter problems Configuration
verification
Parameter optimization
Y
Is there any
parameter Solve parameter problems
problem?
N
CHR:
(9) CHR flow/terminal Statistical
performance analysis of
mobile phone
problems
Is there any terminal Y

performance Terminal defect list
problem?
Figure 2 Performance analysis flow (Continued)

1) Overall analysis of network KPI

Step 1 of performance analysis and quality early warning is to make an overall
analysis of network KPIs. The KPIs include, but are not limited to traffic, call
completion rate, handover success rate, and call drop rate, shown as follows.
For those which contain specific services, such as HSDPA and CMB, or specific
algorithms, we also need to observe the integral indexes of corresponding KPIs.
Analyze the KPI of daily report or weekly report as required. From WCDMA
Performance Monitoring Report output by the Nastar tool, we can also obtain a
visual overall analysis.
The judgment of whether the KPI is abnormal must be based on the comparison
with early history. We may observe the extent of relative change instead of the
absolute value of the KPI.
When there is no apparent change in the KPI, there are two processing modes:
End the current performance analysis and analyze TOPN cell. When there are a
large number of network cells, the performance deterioration of very few base
stations may not apparently affect the overall network KPI. These abnormal cells
can be found out by contrasting TOPN analysis.
When the relative value of the KPI is not apparently changed but its absolute
value always cannot reach standards and no analysis conclusion has been
drawn, we need to analyze specific causes according to traffic statistics data and
conduct quality early warning.
Table 1 Overall analysis of network KPIs
AMR DL12.2 Erlang 13.08 (11:0012:00)
VP DL Erlang 0.39 (17:0018:00)
CS Erlang 15.86 (18:00 19:00)
Traffic PS UL Erlang 167.19 (21:0022:00)
PS DL Erlang 554.03 (21:0022:00)
PS UL Throughput 2675.06 (21:0022:00)

R99
PS DL Throughput 8864.55 (21:0022:00)
Access RRC Connection Setup Success Rate

99.78% (135343/135638)
(service) (>98%)
RRC Connection Setup Success Rate

99.31% (170930/172122)
(other) (>95%)
AMR RAB Assignment Success Rate 99.66% (18595/18659)

(>98%)

Video Call RAB Assignment Success

99.57% (230/231)
Rate (>98%)
PS RAB Assignment Success Rate

99.59% (95524/95918)
(>97%)
Soft Handover Factor based on Radio

22.66%
Link Number (<50%)
Soft Handover Success Rate (>99%) 99.72% (318538/319439)
Inter-Freq Hard Handover Success

N/A (0/0)
HO Rate (>95%)
CS Inter-RAT Handover Success Rate

98.76% (6198/6276)
(from UTRAN to GSM) (>96%)
PS Inter-RAT Handover Success Rate

96.10% (44834/46653)
(from UTRAN to GSM) (>92%)
CS AMR Call Drop Rate (<1.5%) 0.35% (66/18595)
CDR VP Call Drop Rate (<3%) 0.87% (2/230)
PS Service Drop Rate (<5%) 5.08% (4854/95524)
HSDPA RLC Traffic Volume (MBytes) 19373
Traffic HSDPA Mean UE 68.18 (18:0019:00)
HSDPA RLC Throughput (Mbps)
HSDPA RAB Setup Success Rate

Access 98.24% (14360/14617)
(>97%)
HS-DSCH Service Cell Change

99.73% (10391/10419)
Success Rate (with SHO) (>99%)
HSDPA

N/A
Success Rate (with Intra HHO) (>95%)

HO N/A
Success Rate (with Inter HHO) (>95%)
HS-DSCH to DCH Handover Success

99.38% (961/967)
Rate (>95%)
DCH to HS-DSCH Handover Success

83.28% (792/951)
Rate (>95%)
CDR HSDPA Service Drop Rate (<5%) 1.39% (200/14360)

2) Analysis of RNC equipment problem/IU transmission problem/parameter

RNC equipment problem and IUR interface transmission problem may affect the
whole-network KPI.
IU interface transmission problem and core network problem will affect the
whole-network KPI directly.
If the performance indexes of network cells are universally deteriorated, basic
causes are related to the RNC board reset and restricted IU interface
transmission. Equipment problems and intermittent transmission failure can be
checked by the Omstar tool. Transmission bandwidth restricted can be checked
by observing transmission-related PIs from traffic statistics.
Another case of affecting the overall KPI of RNC: RNC-level parameter change.
If the whole-network KPI becomes apparently abnormal, we need to make sure
whether any RNC-level parameter change has been made recently and carefully
check the impact of this parameter on the network.
3) KPI analysis of TOPN cell

The number of TOPN cells can be increased according to the network scale. The
number of the Nastar tools is 10 by default. If there are too few TOPN cells,
some cells with abnormal performance may be ignored.
The WCDMA Performance Monitoring Report output by the Nastar tool lists the
TOPN with normal KPIs. According to this report, we may pick out important cells
from TOPN cells and make an in-depth analysis.
A comparison of the indexes of TOPN cells with those of history TOPN cells
helps judge whether cell performance indexes are normal. It is recommended to
use the above-mentioned trend analysis figure for comparison. Make sure
whether TOPN cell Id changes and what the amplitude of change in TOPN cell
KPI is. This is simple but visual.
TOPN cell problems must be analyzed together with cell traffic. For example, a
pure observation of the call drop rate of a cell is meaningless. If a cell has one
call drop, but there is only one call attempt, the call drop rate is 100%.
4) Cell equipment analysis:

Cell equipment analysis means analyzing the equipment of TOPN cells of last
step. Likewise, subsequent load problem analysis and interference problem
analysis are oriented to TOPN cells.
The equipment that affects cell performance KPI includes the antenna feeder
equipment and the uplink/downlink processing board of a base station.
Generally, related equipment alarms can be observed either on the NodeB side
or on the RNC side.
The transmission restricted and intermittent transmission failure of a base station
will affect related cell indexes. Intermittent transmission failure is observed by

using the Omstar tool. We make an auxiliary analysis by using the cell
unavailability PI (VS.Cell.UnavailTime.OM) provided by the Nastar tool.
5) Analysis of cell load problems

The indexes directly related to cell load include average uplink/downlink
occupied CE of a cell (VS.LC.ULCreditUsed.CELL/2,
VS.LC.DLCreditUsed.CELL) and the maximum uplink/downlink occupied CE
(VS.LC.ULCreditUsed.CELL.Max/2, VS.LC.DLCreditUsed.CELL.Max). When the
maximum uplink/downlink occupied CE approaches 128 or the average occupied
CE is around 60, expansion should be considered.
Causes for cell load problems include: change of traffic model; the main
coverage service of this cell is designed to be VP64, but actually there are a
large number of 384k services. During holidays, relatively concentrated
population leads to the increase in traffic.
High load may cause CE congestion, power congestion, code congestion, and
transmission congestion. We should make an analysis by observing
corresponding PI.
In load problem analysis, when much power congestion occurs, actual load is not
necessarily very high. In this case, we need to analyze admission strategy and
judge whether admission parameters are properly set.
6) Analysis of cell interference problems

Causes of interference: UE self-correlation interference. If there are many UEs in
a conversation within a cell, interference will increase. Interference is also
caused by external interference source and by pilot pollution.
Whether there is any uplink interference within a cell can be judged by observing
the RTWP indexes in traffic statistics, that is, the average RTWP of a cell and the
maximum RTWP of a cell. If the average RTWP of a cell is as high as -95 dBm
or higher, it is possible that there is uplink interference. Observe the maximum
RTWP. If RTWP peak, such as -70 dBm, is often seen, the cause may be the
power of access process or handover process.
An in-depth interference analysis requires that the interference analysis function
of the Nastar should be started. If a cell has severe interference, we need to
trace its RTWP data. Import the RTWP data, configuration data and engineering
parameter to the Nastar tool, and start the interference analysis function. In this
way, we can effectively find external interference or internal equipment problems.
This function locates multiple possible causes of radio interference or abnormal
signals by analyzing main-diversity signal strength and according to certain
algorithm categorization.

7) Analysis of cell coverage problems

Coverage problems include poor coverage, excessive coverage, pilot pollution,
and missing configuration of adjacent cells.
Poor coverage leads to poor performance of an air interface. In traffic statistics, a
large number of PIs, such as RF.RLCRst, RF.ULSync and UuNoReply, are
related to poor coverage.
For an in-depth analysis of poor coverage and excessive coverage, we need to
provide the IOS data of the analyzed cell and enable the coverage analysis
function of the Nastar to make a statistical analysis of the coverage strength of
the pilot and the link quality of service.
Pilot pollution analysis does not need any IOS data. The pilot pollution analysis
function of the Nastar tool needs CHR data, engineering parameter,
configuration data, and traffic statistics data. The principles of pilot pollution
analysis are to make statistics according to 1C measurement reports and signal
quality of active set and monitoring set when 1C reports are reported, together
with the number of branches of cell power splitting output in engineering
configuration parameters.
The intra-frequency adjacent cell check of the Nastar tool can be fully used to
find those adjacent cells that miss configuration. In using this function, we need
to turn on the detection set reporting switch. The principles of this function are to
judge whether any adjacent cell misses configuration by making statistics of
detection set reports and cell signal strength reported.
8) Analysis of parameter problems: (What factors lead to parameter change?

Insufficient bandwidth, missing configuration of adjacent cells, comparison of
cutover tool with the Nastar tool)
If the KPI deterioration of a cell is not closely related to equipment, load,
interference or coverage, we need to check cell parameters carefully.
We need to make sure whether the history (see 3.1.3Network Operation
History) of network operations contains any parameter adjustment related to this
cell, including adjustment of adjacent cell relationship and RF parameter
adjustment. If cell parameter adjustment has been made recently, we need to
make a careful analysis. Meanwhile, the impact of early parameter adjustment
on the recent KPI should not be eliminated. We also need to check whether
there is a big increase in the traffic of this cell. If traffic increases sharply, the
unreasonableness of cell parameters will be easily found.
The configuration verification function of the Nastar tool can help quickly check
the parameter changes of the same version made on a different day.
9) Analysis of CHR process and terminal performance problems

The prerequisite to network planning performance analysis is stable product
performance and normal equipment. But the bug of actual networks and
products always exists. We need to define whether the problem lies in product
implementation through performance analysis.

In the early performance analysis, many RAN equipment problems have been
found. In cell performance analysis, sometimes abnormal access or call drop still
occurs even if there is no high load, a cell has normal signal coverage and there
is correct parameter configuration. In this case, we need to enable the CHR
analysis function of the Nastar tool and use signaling process to make an
analysis. The dot information of CHR involves the implementation of a product
internal module. CHR analysis does not aim to accurately locate a problem, but
to determine the scope of the problem and failure location of abnormal
processes. Then, feedback the result to product R&D personnel to provide
auxiliary information about the location by the R&D personnel.
Besides RAN equipment problem, terminal problems cannot be excluded in
performance analysis. Many of them have been found in an actual network.
Sometimes, a terminal transmits at a fixed power and the conditions that a
terminal satisfies measurement reports fail to be reported in time. For the sake of
query, terminal problems found in existing network can be classified and included
in a list.
RAN equipment problems and terminal problems seldom appear, therefore they
are put at the end of performance analysis. In analyzing abnormal PIs, after
excluding multiple possible causes, we should dare to doubt equipment
problems and give reasonable evidence based on CHR.
3.3.6.2 Proper Use of Functions of the Nastar
The previous section describes the processes and procedures of performance

analysis. In one word, performance analysis is proper use of the Nastar tool. This
document first describes performance analysts necessary skills and then expounds
related preparations for performance analysis. Finally, one thing is certain. That is, we
should know how to analyze a complex network by using a specific function of the
Nastar.
The Help document of the Nastar tool describes main related functions of the Nastar:
Quick index query
Output reports based on a template
Coverage analysis, interference analysis, and configuration verification analysis
A tool is only a platform. How to make an effective analysis with this tool requires
continuous summarization of experiences. Now take for example the analysis of RRC
establishment success rate and RAB establishment success rate to expound when
the Nastar functions should be used in performance analysis. This serves as the
example of performance analysis methods.
The Nastar functions are described in section 2.4.2Mastery of Advanced Functions of
the Nastar Tool. For the sake of the figure analysis as follows, these functions are
summarized as [Query Function], [Customization Query], [Daily Report Output],
[TOPN Query], [Coverage Analysis], [Cross Coverage], [Missing Configuration of
Adjacent Cell], [Load Analysis], [Interference Analysis], and [Configuration

Verification]. The difference between [Query Function] and [Customization Query] is

that the former can be directly exported from the performance analysis template of
the Nastar tool while the latter is customized as required.
1. Performance analysis of RRC establishment success rate
Query TOPN cells with the most RRC establishment failures with the Nastar. Make
the following performance analysis in terms of each TOPN cell.
1. Query RRC
establishment by using the
network performance
analysis function
2. Do indexes Y
satisfy the
requirements?
3. Subdivide Y 4. Query equipment

into cell
alarm
equipment
problems
N
5. Coverage quality 9. Cell reselecting 11. Overload admission

problem problem problem
6. Ec/Io 7. Overshoot 8. Missing 10. Analysis of 12. Load and

analysis configuration of adjacent cell interference
analysis adjacent cell coverage quality analysis
Figure 1 Performance analysis of RRC establishment success rate
1) [Daily Report Output] Use a network optimization tool to analyze RNC traffic
statistics data, output daily reports and get related indexes of RRC establishment
success rate, mainly including RRC establishment success rate of service and
non-service.
2) Judge whether the KPI satisfies network requirements according to the defined
threshold or a comparison of the history.

3) [TOPN Query] Subdivide RNC-level indexes into cell-level indexes and find out
10 cells with the worst indexes.
4) [Customization Query] and [Omstar query] Customize the unavailability indexes
of the queried cell or find equipment alarm information with the Omstar, and
judge whether the problem lies in equipment or transmission.
5) [Customization Query] Query results indicate that possible performance
problems include coverage problems, cell reselecting problems and admission
problems (We need to determine the type of problems according to the previous
basic KPI analysis. Then, we use the Nastar tool for a corresponding analysis.)
6) [Coverage Analysis] Enable cell coverage quality analysis to exclude coverage
problems.
7) [Overshoot Analysis] Enable overshoot analysis to exclude possible overshoot.
8) [Missing Configuration of Adjacent Cell] Enable the analysis of missing adjacent
cells to exclude the possibility of missing configuration of adjacent cells.
9) [Configuration Verification] Enable parameter analysis to exclude parameter
configuration problems.
10) [Coverage Analysis] Adjacent cell coverage quality analysis.
11) [Customization Query][Configuration Verification] Query the PIs with load
admission failure and check parameters to judge whether load admission is too
high.
12) [Customization Query][Interference Analysis] Query cell load PIs or enable the
interference analysis function to eliminate interference problems and overload
problems.
2. Performance analysis of RAB establishment success rate

Query TOPN cells with the most RAB establishment failures by using Nastar. Make
the following performance analysis in terms of each TOPN cell.

1. Query RAB
establishment success rate
by using the performance
analysis function
2. Do indexes Y
satisfy the
requirements?
3. Subdivide Y 4. Query equipment

into cell alarm
equipment
problems
N
5. Coverage quality 8. Intra-frequency 10. Overload admission

problems handover problem problems
6. Ec/Io 7. Missing 9. Analysis of 11. Load and

analysis configuration of adjacent cell interference
adjacent cell coverage quality analysis
Figure 1 Performance analysis of RAB establishment success
1) [Query Function] First use the network performance analysis and query function
of a network optimization tool to query the RAB establishment success rate of
various RNC-level services, including AMR service, VP service, and PS service
with a typical rate.
2) Judge whether each RAB establishment KPI satisfies requirements based on the
history.
3) [TOPN Query] Subdivide RNC-level indexes into cell-level indexes and find out
10 cells with the worst indexes. Among cell-level indexes, some statistical points
of RAB establishment failure can be used for the isolation of equipment problems
or network performance problems.
4) [Customization Query] or [Omstar tool query] We can use the Omstar tool to
query equipment problems or transmission problems. We may customize PI
query, for example, query the index VS.Cell.UnavailTime.OM.

5) [Customization Query] RAB failure causes can be categorized as coverage

problems, handover problems and overload rejection problems. For the standard
for the categorization, refer to Table 1 in section 2.4.1.
6) [Coverage Analysis] Enable cell coverage quality analysis to exclude coverage
problems.
7) [Missing Configuration of Adjacent Cell] Enable the analysis of missing adjacent
cells to exclude the problem of missing configuration of adjacent cells.
8) [Customization Query] Query related PIs to make sure whether the problem lies
in handover.
9) [Configuration Verification] Enable parameter optimization analysis to exclude
handover parameter configuration problems.
10) [Customization Query] Query related PIs to make sure whether there is any
overload.
11) [Customization Query] and [Interference Analysis] Query load-related PIs and
enable interference analysis to exclude interference problems and overload
problems.
3.3.6.3 Routine Analysis and Quality Early Warning
This document does not distinguish between performance analysis and quality early
warning. Quality early warning is defaulted to occur during performance analysis. We
confirm whether quality early warning is necessary according to performance analysis
results.
Quality early warning includes performance KPI deterioration early warning and
potential quality risk early warning. When any KPI deterioration is found during
performance analysis, we give a timely early warning, find network problems and
optimize network to avoid continuous deterioration of network performance. Potential
risk early warning is not driven by any KPI deterioration event. Therefore, we need to
make routine network check according to certain rules and give an early warning to
those that do not conform to rules.
Routine analysis and quality early warning include the following aspects:
12) Check unidirectional adjacent cells. Normally, the intra-frequency adjacent cell
relationship of the UMTS network is configured as bi-directional. If some cells are
only configured with unidirectional adjacent cell relationship, we need to give an
early warning to those scenarios that cannot give special reasons for their
particularity.
13) Check the adjacent cells that miss configuration. Using the missing adjacent cell
check function, regularly check whole-network adjacent cell relationship. We
need to give an early warning to the adjacent cells that apparently miss
configuration.
14) Check RTWP. Regularly check the average RTWP and the maximum RTWP of
whole-network cell. It is found from actual network that some cells have a
relatively high RTWP, but their call drop rate and call drop times are not
necessarily quite deteriorated. No matter what the KPI performance of a cell is,

we need to give an early warning to the cells with a relatively high RTWP and
find out corresponding causes.
15) Check pilot pollution. Actual measurement and theoretical analysis have given us
a conclusion. Pilot pollution is not necessarily linked to call drop, but we need to
optimize the regions with severe pilot pollution. We should regularly check
whole-network pilot pollution with the Nastar and give an early warning to the
regions with severe pilot pollution.
Routine check is also based on the basic query function and advanced special topic
function of the Nastar. Its period can be flexibly set according to existing network
conditions. For example, routine check can be made once a month or a quarter.
Another trigger factor of routine check and quality early warning is network cutover.
When large-scale relocation and cutover occur in a network, be sure to make routine
check by using the configuration verification function and missing adjacent cell check
function of the Nastar. The complexity of the UMTS network parameters determines
the fact that whole-network check is necessary in case of large-scale relocation. A
quality early warning should be given as soon as possible to parameter inconsistency
or parameter omission.

4 Observation Point and Analysis
Examples of Typical Problems
An observation point is a PI which reflects a specific performance problem. The

analysis based on an observation point is a process that goes deeper based on the
familiarization of the UTRAN PI. Observation point analysis associates signaling
process with performance index. Observation points are categorized as follows:
16) RRC establishment analysis observation point
17) RAB establishment analysis observation point
18) Soft handover analysis observation point
19) Call drop analysis observation point
20) CS/PS intersystem handover analysis observation point
21) Traffic analysis observation point
22) Key interface process analysis observation point
23) HSDPA analysis observation point
An in-depth performance analysis can be made only after you have gained a mastery
of observation points. The Nastar tool provides special topic query of most
observation points. We may also make special topic query of other observation points
by means of customization. Special topic drilling analysis of basic observation point
helps deepen the understanding of signaling processes and various PIs and
strengthen the mastery of the Nastar tool.

Figure 1 Special topic analysis
4.1 Observation Points of Typical Problems

4.1.1 RRC Establishment Analysis Observation Point
Table 1 RRC Establishment Observation Point
Observation Possible
Condition Analysis Idea
Point Cause
If there are many streaming class called

service requests (accounting for over 10%
Observe various
of total connection establishment
types of RRC
requests), we need to pay much attention
connection
to them. This is because when UE changes
Categories of establishment
from DCH status into IDLE status, PS
RRC requests and
needs to transmit packets, then ps paging
establishment their proportional
occurs and the corresponding RRC
requests distribution. If
requests are streaming class called service
any abnormality,
requests. If there are too many requests of
we need to give
this type, it is possible that the timer from
an early warning.
DCH status to IDLE status is not properly
set.
RRC Number of RRC AAL2 It is generally caused by insufficient

establishment connection establishment transmission resource or transmission
failure establishment failure fault. You may query the cell downlink
failures (>=5); throughput at the moment from associated
RRC connection traffic statistics indexes. If it is lower than
establishment 200 kbps, transmission fault may occur.

Point Cause
It may be caused by NodeB fault or

insufficient NodeB resource. You may
RL query the maximum downlink CE of a cell
establishment from associated traffic statistics index. If
failure the maximum uplink CE is less than 20,
then traffic is not high and the problem lies
in abnormal NodeB equipment.
RRM admission decision cannot establish

any new RRC connection due to too high
radio load within a cell. In this case, you
need to query the maximum RTWP and the
Power maximum TCP of the cell to confirm uplink
congestion congestion or downlink congestion and
judge whether any expansion is necessary.
Meanwhile, we should check whether
failure rate related admission strategy settings, such
(>=10%) as DCCC, are proper.
Uplink CE resource admission congestion

within an RNC. You need to query the
number of uplink CEs of a cell from
relevant parameters and judge whether to
expand CE. If the number of uplink CEs is
less than 20, then traffic is not high and the
problem may lie in abnormal NodeB
Uplink CE
equipment.
congestion
At present, RNC does not make an
accurate estimate of CE resource. It is
quite possible that RNC judges CE to be
sufficient, but actual NodeB CE resource is
insufficient. In addition, inconsistent
capability of RNC and NodeB may also
lead to NodeB RL establishment failure.

Point Cause
Downlink CE resource admission

congestion within an RNC. You need to
query the number of downlink CEs of a cell
from relevant parameters and judge
whether to expand CE. If the number of
uplink CEs is less than 40, traffic is not
high and the problem may lie in abnormal
Downlink CE
NodeB equipment.
congestion
Code resource fails to be allocated during

RRC connection establishment. Code
congestion is generally caused by too
many network users. It may be seen in
high traffic scenarios with microcell
Code
coverage. You may query the effective
congestion
utilization of codes from associated traffic
statistics indexes. If the effective utilization
of codes is lower than 30%, it is possible
that the code distribution algorithm is
abnormal.
Generally the congestion caused by

unknown insufficient resources. For
Other
example, license resource and high CPU
congestion
utilization make flow control and FMR
leads to RRC
processing capacity insufficient. In addition,
rejection.
E1 fault also appears. This cause value is
dotted.

Point Cause
Transmission congestion is mainly caused

by insufficient transmission resource. You
may query the downlink cell throughput
from associated traffic statistics indexes. If
Transmission the downlink cell throughput is lower than
congestion 200 kbps, it is possible that there is
abnormal equipment. The power-down of a
base station once led to transmission
interruption, but the cause in traffic
statistics is transmission congestion.
Abnormal causes. We need to make in-

depth location based on RNC logs. The
Other factors known problem is that the system
lead to RRC redirection function of the network is
rejection. enabled. During redirection, a mobile
phone does not support GSM and thus
failure rejection occurs.
This is generally caused by poor coverage.

No response
The downlink FACH and RACH have
from UE
unbalanced coverage.
This is generally caused by an RNC fault.

At present, there is a problem with traffic
statistics mode, which may lead to some
wrong dotting of this cause.
There was a problem with the designated
Other factors
access DSP of node B. The RRC
lead to RRC
CONNECTION SETUP REQUEST
establishment
message fails to be sent to RNC. The
failure.
RACH packet decoding of this cell fails. We
may make a judgment by checking
whether the index
VS.MAC.CRNCIubBytesRACH.Tx is
abnormal.

4.1.2 RAB Establishment Analysis Observation Point
Table 2 RAB establishment observation point
Point Cause
Generally transmission equipment fault or

Transmission insufficient transmission capacity. You need
network to query the transmission utilization of that
time.
In starting migration, RNC receives a RAB

establishment request, but does not
process it. This is mainly caused by flow
Migration
nesting and seldom occurs. It is related to
user behavior sequence. This is generally
avoided in a core network.
RRM admission decision cannot establish

any new RRC connection due to too high
radio load within a cell. In this case, you
Number of need to query the maximum RTWP and the
CS/PS RAB Power maximum TCP of the cell to make sure of
establishment congestion uplink congestion or downlink congestion
CS/PS RAB and judge whether any expansion is
failures (>=5);
establishment necessary. Meanwhile, we should check
CS/PS RAB
failure whether related admission strategy
establishment
failure rate settings, such as DCCC, are proper.
(>=10%) Uplink CE resource admission congestion
within an RNC. You need to query the
number of uplink CEs of a cell from
relevant parameters and judge whether to
expand CE. If the number of uplink CEs is
less than 20, then traffic is not high and the
problem may lie in abnormal NodeB
Uplink CE
equipment.
congestion

Point Cause
Downlink CE resource admission

congestion within an RNC. You need to
query the number of downlink CEs of a cell
from relevant parameters and judge
whether to expand CE. If the number of
uplink CEs is less than 40, then traffic is
not high and the problem may lie in
Downlink CE
abnormal NodeB equipment.
congestion
Code resource fails to be allocated during

RRC connection establishment. Code
congestion is generally caused by too
many network users. It may be seen in
high traffic scenarios with microcell
Code
coverage. You may query the effective
congestion
utilization of codes from associated traffic
statistics indexes. If the effective utilization
of codes is lower than 30%, it is possible
that the code distribution algorithm is
abnormal.
Transmission congestion is mainly caused

by insufficient transmission resource. You
may query the downlink cell throughput
from associated traffic statistics indexes. If
Transmission the downlink cell throughput is lower than
congestion 200 kbps, it is possible that there is
abnormal equipment. The power failure of
a base station once led to transmission
interruption, but the cause in traffic
statistics is transmission congestion.
Abnormal causes. We need to make an in-

Others
depth location based on RNC logs.

Point Cause
The air interface failure occurring during

Air interface RB establishment is generally caused by
failure poor coverage or mobile phone
compatibility.
The compatibility of a mobile phone itself

becomes faulty in some unknown
scenarios. For example, when a Huawei
Configuration mobile phone drops network abnormally, it
not supported may not release any RB. When PS RB is
set up next time, this case may occur. This
case also happens to the SE V800 mobile
phone.
This generally occurs when FACH migrates

to DCH and sets up RB. The downlink
Physical physical layer of a terminal is not
channel failure synchronized, which leads to RB
establishment failure. This is mainly caused
by poor coverage.
The Cell Update flow occurs during RB

Cell update establishment. This nested flow leads to
RB establishment failure.
UE considers parameter configuration

illegal. Network and terminals have an
inconsistent understanding of parameter
processing. If RB establishment failure
Illegal
occurs in the domain of CS, it is possible
configuration
that a user dials a wrong telephone number
and at once goes onhook. RB SETUP
failure may also occur at this time. The
cause is illegal configuration.
Generally poor coverage makes UE unable

No response
to receive any RB establishment
from UE
command.

Point Cause
RNC considers the parameter delivered by

a core network invalid. You need further
cell signaling tracing to determine the
cause. Among the known causes is that the
uplink subscription and activation
Parameter error
application information of user PS service
exceeds the capacity of a mobile phone, or
that the network negotiation rate in PDP
activation acceptance messages is less
than the minimum guaranteed rate.
4.1.3 Call Drop Analysis Observation Point
Table 3 CS/PS call drop observation point
Point Cause
CS/PS call High CS/PS call Call drop caused by operation and
drop drop rate maintenance. For example, the execution
OM intervention
of TRG RABRel on LMT causes users to
be released.
High-priority users preempt low-priority

users when admission is rejected. This
causes a link to be released. This kind of
RAB
call drop occurs in the case of load and
preemption
insufficient resource. Determine whether
expansion is necessary according to the
number of occurrences.
UTRAN Within a cell, UTRAN leads to abnormal

link release. This case generally
corresponds to processing abnormality. We
need to make a further analysis by means
of CDL.

Point Cause
Uplink or downlink signaling RB reaches

the maximum retransmission times and
resets. This causes a link to be released.
Uplink/downlink
This case is mainly caused by poor
RLC reset
coverage quality (including missing
configuration of adjacent cells and small
handover area).
RNC receives RL Failure reported by

NodeB, which causes a link to be
abnormally released. In this case, poor
Uplink
coverage quality (including missing
synchronization
configuration of adjacent cells and small
failure
handover area) makes UE abnormally shut
down the transmitter, or uplink
demodulation out-of-sync.
Receive the Cell Update message reported

by a mobile phone. The cause is downlink
RL Failure, which makes a link abnormally
Downlink released. In this case, poor coverage
synchronization quality (including missing configuration of
failure adjacent cells and small handover area)
makes UE abnormally shut down the
transmitter, or uplink demodulation out-of-
sync.
RNC delivers a message and waits for the

response from a mobile phone, but timeout
The UU occurs. For example, waiting for RB
interface makes reconfiguration completion message times
no response. out and waiting for active set update
completion times out. This case is
generally caused by poor coverage.
Other RF
RF cause; due to poor coverage quality
causes

Point Cause
RNC finds that the AAL2 Path of the IU CS

interface is abnormal and starts abnormal
release. It is possible that the transmission
Abnormal AAL2 equipment of the Iu interface is abnormal.
link The known problem is that immediate
normal release during RB establishment is
classified by traffic statistics into abnormal
release.
RNC finds that the GTPU of the IU PS

Abnormal interface is abnormal and starts abnormal
GTPU release. The cause may be equipment fault
or defect.
Possibly the call drop (but traffic statistics

does not dot) occurring during flow
interaction or cell update, or abnormal call
drop and cell blocking caused by the
transmission fault of the Iub interface, RNC
internal cause, and Bug. There may be call
Others
drop for abnormal causes. We need to
make an analysis based on RNC logs. The
call drop caused by violent change (corner
effect or driving out from the shadow area
of a building) of uplink signal is known to
be classified into this cause.
4.1.4 Soft Handover Analysis Observation Point
Table 4 Soft handover analysis observation point
Point Cause
Soft Soft handover Possible causes of too high (>= 40%) a

handover rate based on soft handover rate:
rate cell resource 1) Handover parameter setting makes
allocation and addition easy, but deletion difficult.
soft handover
2) In the early days of network
rate based on
construction, there are few base
IUB transmission
stations and insufficient coverage.

Point Cause
Therefore, capacity gives way to

quality.
3) The CN side of some partners does
not deliver Iu release. After a users
resource
dial-up access is disconnected, there
allocation.
is only user plane release instead of
signaling plane release. Users have
soft handover even after a network is
disconnected.
UE considers that the content of the active

Configuration set update of RNC adding/deleting a link is
not supported not supported. Generally, this scenario will
not appear in commercial use.
UE gives the feedback that the softer/soft

handover process of RNC adding/deleting
Synchronization a link is incompatible with other concurrent
reconfiguration processes. RNC has guaranteed serial
Number of not supported flow processing. Soft handover execution
soft/softer failure is mainly caused by the problematic
Soft
handover failures processing of some mobile phones.
handover
(>=5) and
execution UE considers that the content of the active
soft/softer
failure
handover failure Illegal set update of RNC adding/deleting a link is
rate (>=10%) configuration illegal. Generally, this scenario will not
appear in commercial use..
RNC does not receive the active set

update command response for
adding/deleting a link. This is the main
No response
cause of softer/soft handover failure. This
from UE
happens in the region with poor coverage
or a small handover area. It needs RF
optimization.

4.1.5 CS/PS Intersystem Handover Analysis Observation Point
Table 5 Intersystem handover observation point
Observation
Condition Possible Cause Analysis Idea
Point
Preparation
failures (>=5) of
Radio link establishment failure occurs
hard handover
Hard during RL establishment. For details, see
into this cell and
handover the RL establishment process analysis of
preparation
preparation the IUB interface.
failure rate
failure For other causes, we need to make a
(>=10%) of hard
further analysis based on RNC logs.
handover into
this cell
Preparation Preparation A target cell has

A target cell has no resource available, or
failure of failures (>=5) of no wireless
there is some RNC parameter
transition out transition out of network
configuration error. We need to make an
of cell cell accompanied resource
analysis based on RNC logs.
accompanied by hard available.
by hard handover and
The problem often lies in CN parameter
handover preparation Transition
configuration or a related link connection.
failure rate timeout of target
We need to make an analysis based on
(>=10%) of system
RNC logs.
transition out of
cell accompanied Transition failure
by hard in the target It generally corresponds to core network
handover CN/RNC or configuration error.
system
Transition in the
Generally, RNC does not support some
target CN/RNC
hard handover parameters. We need to
or system not
make an analysis based on RNC logs.
supported
Transition Often an MSC parameter configuration

objective not error. We need to check the parameter
allowed configuration of a core network.
OM intervention Failure caused by operation and

maintenance

Observation
Point
Often an MSC parameter is configured

No available
incorrectly, or a target RNC has no
resource
resource available.
Failure causes are not defined in traffic

Undefined
statistics.
We need to make an analysis based on

Others
RNC logs.
A core network does not return a

corresponding command of handover
Waiting for preparation request. In this case, there is
transition some problem with the parameter
command configuration or related link connection of
timeout a core network. We need to analyze the
cause according to the signaling trace of
the core network and BSS.
Preparation Upon requesting handover preparation,

failures (>=5) of RNC receives the release command from
RNC-level a core network. Two cases: intersystem
CS/PS domain handover request occurs during signaling
Preparation intersystem process like location update. The location
failure of outgoing Transition update flow has been finished before one
RNC-level handover, cancelled flow is finished. The core network starts
foreign preparation release; the user who sets up a call goes
outgoing failure rate onhook during handover preparation, and
handover (>=10%)of CS the core network starts release. No
domain handover is finished in either case, but
intersystem either is normal flow nesting.
outgoing
handover It generally corresponds to core network
Transition configuration error. We need to analyze
timeout the cause according to the signaling
tracing of a core network and a BSS.
The problem often lies in the parameter

Transition failure
configuration or related link connection of
in the target
a core network. We need to analyze the
CN/RNC or
cause according to the signaling tracing of
system
a core network and a BSS.

Observation
Point
The problem often lies in an MSC

parameter configuration error. That is, the
LAC of the target cell fails to be
Unknown target
configured. We need to check the
RNC
parameter configuration of a core network.
This case is often seen after the
adjustment of 2 G network.
The problem often lies in an MSC

parameter configuration error, or BSC has
No available
no resource available. We need to analyze
resource
the cause according to the signaling
tracing of a core network and a BSS.
We need to analyze the cause according

Others to the signaling tracing of a core network
and a BSS.
The problem often lies in the parameter

configuration or related link connection of
Transition
a core network. We need to analyze the
timeout
Preparation cause according to the signaling tracing of
failures (>=5) of a core network and a BSS.
CELL-level CS
domain It generally corresponds to core network
Transition failure
Preparation intersystem configuration error or BSS not supporting.
in the target
failure of outgoing We need to analyze the cause according
CN/RNC or
Cell-level handover and to the signaling tracing of a core network
system
foreign preparation and a BSS.
outgoing failure rate In this case, a BSC does not support
handover (>=10%) of CS Transition in the
some parameters of intersystem handover
domain target CN/RNC
requests. We need to analyze the cause
intersystem or system not
according to the signaling tracing of a core
outgoing supported
network and a BSS.
handover.
We need to analyze the cause according
Others to the signaling tracing of a core network
and a BSS.

Observation
Point
UE considers that the command for hard

Configuration handover out of a cell is not supported.
not supported The problem generally lies in the
compatibility of a mobile phone.
Physical Possibly poor coverage or severe

channel failure interference
Outgoing
hard UE gives the feedback that hard handover
handover Failures (>=5) of Synchronization process is incompatible with other
failures within hard handover reconfiguration concurrent processes. The problem may
NODE B, out of a cell, not supported lie in the compatibility of a mobile phone
between failure rate itself.
different (>=10%) of hard Cell update happens during hard
NodeBs handover out of Cell Updating handover out of a cell. This flow nesting
within RNC, a cell Procedure leads to the failure of hard handover out of
and between a cell.
RNCs
UE considers that the command for hard
Illegal handover out of a cell is illegal. The
configuration problem generally lies in the compatibility
of a mobile phone.
We need to make a further analysis based

Others
on RNC logs.
UE considers that the command for

Execution
transition out of a cell accompanied by
failures (>=5) of Configuration
hard handover is not supported. The
transition out of a not supported
problem generally lies in the compatibility
Failure of cell accompanied
of a mobile phone.
transition out by hard
of a cell handover, Physical Possibly poor coverage or severe
accompanied execution failure channel failure interference
by hard rate (>=10%) of
UE gives the feedback that the hard
handover transition out of a
Synchronization handover process of RNC adding a link is
cell accompanied
reconfiguration incompatible with other concurrent
by hard
incompatible processes. The problem may lie in the
handover
compatibility of a mobile phone itself.

Observation
Point
UE considers that the command for

Illegal transition out of a cell accompanied by
configuration hard handover is illegal. This case seldom
occurs.
Configuration
not finished
We need to make a further analysis based

Others
on RNC logs.
The handover command terminal in a

Configuration network does not provide support. The
not supported problem generally lies in the compatibility
of a mobile phone.
1) Poor 2 G signal or severe interference

leads to UE access failure.
2) The channel parameters, including
the encryption mode sent from
network to UE, are inconsistent with
CS/PS domain
those of a BSC. We need to compare
intersystem Physical
and confirm the parameters of a
CS/PS handover failures channel failure
terminal and those of a BSC. Physical
foreign (>=5), CS/PS
channel failure generally occurs in a
handover domain
network with partners equipment as
failure intersystem
the CN. We need to check the
handover failure
encryption algorithm configuration of
rate (>=10%)
an MSC and an SGSN.
We need to make a further analysis

according to RNC logs, together with the
signaling tracing of a core network and a
BSS. Improper service capability
Others
configuration of 2 G cell makes high-rate
service unable to start a pressing mould,
which leads to system PS handover
failure.

4.1.6 Traffic Analysis Observation Point
Table 6 Traffic analysis observation point
Observation
Point
Lay an emphasis upon Observe whether the maximum uplink CE

the analysis of average resource occupied approaches 128. If it does, an
uplink CE resource early warning needs to be given to expansion.
Uplink CE
occupied and the Normally, when the average uplink CE resource
maximum uplink CE occupied is less than 60 CE Erlang, whole-
resource occupied. network busiest-hour cell traffic is very small.
Observe whether the maximum downlink CE

Lay an emphasis upon
resource occupied approaches 128. If it does, an
the analysis of average
early warning needs to be given to expansion.
downlink CE resource
Downlink CE Normally, when the average downlink CE
occupied and the
resource occupied is less than 60 CE Erlang,
maximum downlink CE
whole-network busiest-hour cell traffic is very
resource occupied
small.
List the average TCP,

If the average transmit power of a cell is large and
Average transmit the maximum TCP and
there is small traffic, it indicates that there is poor
power of cell the minimum TCP of a
downlink coverage.
cell.
List the average TCP,

Maximum If the maximum transmit power of a cell is large
the maximum TCP and
transmit power of and there is small traffic, it indicates that power
the minimum TCP of a
cell peak shock may lead to power congestion.
cell.
Minimum Observe whether the If the minimum transmit power of a cell is

transmit power of minimum transmit power abnormal, the transmit channel may become
cell of a cell is abnormal. faulty.
List the average RTWP,

the maximum RTWP, If the average RTWP of a cell is higher than -95
Average RTWP
and the minimum RTWP dBm, there may be downlink interference.
of a cell.
Among various items, RTWP peaks, for example,

Observe whether there
Maximum RTWP -70 dBm, often appear. This may be caused by the
are many peaks.
power of access process or handover process.

Observation
Point
Observe whether the If the minimum RTWP is lower than -108 dBm, a
Minimum RTWP minimum RTWP is less channel fails to be corrected, or a base station
than -105.5 dBm. encounters power-down.
If the effective utilization of codes is not high (<=

Effective Observe whether the
30%), but code congestion leads to access failure,
utilization of code utilization is
it is possible that the code distribution algorithm is
codes abnormal.
abnormal.
Observe whether the uplink throughput of a cell is

Uplink Observe the uplink great. If it amounts to 75% of the transmission
throughput of cell throughput of a cell. capability of a base station, transmission
expansion needs to be considered.
Observe whether the downlink throughput of a cell

Downlink Observe the downlink is great. If it amounts to 75% of the transmission
throughput of cell throughput of a cell. capability of a base station, transmission
expansion needs to be considered..
This is generally caused by transmission

interruption or intermittent transmission failure.
List the cell unavailability
Cell status Some offices are greatly influenced by weather
duration and its
monitoring due to the use of microwave transmission.
proportion.
Thunder storm always leads to intermittent
transmission failure.
Missing If 1A events often happen within many

List the number of cell
configuration of consecutive days, there may be missing
1A events.
adjacent cell configuration of adjacent cells.
Excess
configuration of
adjacent cells
List the number of cell If 1C events often happen within many

Pilot Pollution:
1C events. consecutive days, there may be pilot pollution.

4.1.7 Key Interface Flow Analysis Observation Point
Table 7 Key interface flow analysis observation point
Point Cause
The problem may lie in the compatibility

of a mobile phone. A mobile phone
terminal may detect the SQN error of in
Radio an AUTN message, which leads to
network layer failure. Cause value: Synch failure!
Respective encryption modes of CS
IU security mode
domain and PS domain may also lead to
Security mode failures, IU
a security mode failure.
flow failure security mode
failure rate Transmission Correspond to transmission link
layer abnormality.
Network

optimization
Undefined
OM RL failure of IUR interface caused by

intervention operation and maintenance
This generally corresponds to equipment

Hardware
abnormality. We should first query
failure
related equipment alarm.
RL
List the number of
establishment This is caused by insufficient RNC
RL establishment
failure of the IUR internal resource. You need to query the
failures (>= 5) of RNC resource
interface quantity of related users to judge
the Iur interface unavailable
RL whether there is any equipment
of the SRNC, RL
synchronization abnormality.
establishment
configuration
failure rate (>= UE considers that the RL configuration
failure of the IUR
10%) of the Iur Configuration content of RNC establishment is not
interface
interface of the not supported supported. The problem lies in the
RL addition
SRNC, and main compatibility of a mobile phone.
failure of the IUR
failure causes.
interface
Abnormal causes. We need to make an
Others
analysis based on RNC logs.

No response abnormality. We need to query whether
there is any power-down.

Point Cause
RL List the number of The problem lies in the compatibility of a

Configuration
establishment RL establishment mobile phone itself in some unknown
not supported
failure of the failures of the IUB scenarios.
IUB interface RL interface, RL
Insufficient RNC internal resource or
reconfiguration establishment
abnormal RNC equipment. You need to
failure of the IUB failure rate of the
query cell CE resource from relevant
interface Iub interface, and
parameters to judge whether there is any
RL addition main failure
equipment abnormality. Equipment is
failure of the IUB causes. No available
known to encounter repeated power
interface resource
failure and air-conditioner fault due to
thunder storm. As a result, high
temperature leads to abnormality of
various kinds. Besides, the NLPA board
encounters shutdown.

Equipment
abnormality. We should first query
fault
related equipment alarm.
RL establishment failure caused by

OM
operation and maintenance (for
intervention
example, cell blocking)
NodeB makes The problem may lie in cell unavailability

no response or equipment fault. You need to query
the cell unavailability duration from
relevant parameters to judge whether
there is any equipment fault.

Point Cause
RL establishment failure caused by

abnormal factors. We need to make an
analysis based on RNC logs
RL reconfiguration failure caused by
abnormal factors. We need to make an
analysis based on RNC logs. The known
causes are that transmission congestion
(Received Iub AAL2 type1 setup
response message from AL but result is
Others
5 not success!) and improper T314/T315
parameter setting make there not be any
opportunity of RL reconfiguration. RL
addition failure caused by abnormal
factors. We need to make an analysis
based on RNC logs. It is known that RL
addition failure caused by restricted IUB
transmission bandwidth will be classified
into this cause value.
The problem lies in the compatibility of a
mobile phone itself in some unknown
scenarios. For example, when a Huawei
mobile phone drops network abnormally,
it may not release any RB. When PS RB
Configuration
is reestablished next time, this case may
not supported
RB RB establishment occur. This case also happens to SE
establishment failure generally V800 mobile phone. Or when some UEs
failure corresponds to implement VP and high-speed (greater
RB poor air interface than or equal to 64K) PS service, failure
reconfiguration coverage or a may also due to unsupported capability.
failure mobile phone This generally occurs when FACH
RB deletion compatibility migrates to DCH and establishes RB.
Physical
failure problem. The downlink physical layer of a terminal
channel
is not synchronized, which leads to RB
failure
establishment failure. This is mainly
caused by poor coverage.
The Cell Update flow occurs during RB
Cell update establishment. This nested flow leads to
RB establishment failure.

Point Cause
UE considers parameter configuration

illegal. Network and terminals have an
inconsistent understanding of parameter
processing. If RB establishment failure
occurs in the domain of CS, it is possible
that a user dials a wrong telephone
number and immediately goes onhook.
RB SETUP failure may also occur at this
time. The cause is illegal configuration.
Or when a 3 G terminal as the caller
implements VP service, the called party
Illegal resides in a GSM network and does not
configuration support VP service. Thus, after RNC
receives an RAB assignment request, a
core network immediately delivers the
Disconnect command upon Call
Proceeding (the cause is Bearer
capability not authorized). But UE has
just received an RB_SETUP command
at this time and has no time to complete
RB establishment. Upon receiving this
Disconnect command, UE initiates a
response RB establishment failure and
RNC returns RAB establishment failure.
Generally poor coverage makes UE
unable to receive any RB command. In
Hong Kong, the balance mechanism of
IUB once made signaling established on
No response
one E1, but service was established on
from UE
another E1. Thus, there has been no
problem with signaling, but RB
establishment may fail. In this case, it is
this cause value that is returned.
RB bearer Observe whether PS has a large amount of 128k, 144k,
distribution of the number of and 384k RB bearer. This will consume a
uplink/downlink various types of large number of resources and there is
service RB service bearer poor coverage. We need to verify
Uplink/downlink and the whether RB bearer is consistent with
RB bearer proportion are actual demands with first-line personnel.
distribution of BE abnormal. If there Observe whether the RB distribution of

Point Cause
is any
BE service is rational. According to the
abnormality, an
service distribution, DCCC strategy and related
early warning
system parameters can be adjusted.
needs to be given
4.1.8 HSDPA Analysis Observation Point
RNC1.6 version supports the following KPI monitoring: HSDPA service establishment
success rate, HSDPA call drop rate, HSDPA cell throughput, H <-> H intra-/inter-
frequency serving cell update success rate and H <-> R99 intra-frequency handover
success rate. It does not support the following KPI monitoring: HSDPA average uplink
and downlink throughput for a single user, H <-> R99 inter-frequency handover
success rate, H -> GPRS intersystem handover success rate, statistics of the causes
for HSDPA service establishment failure, statistics of the causes for HSDPA call drop
failure, statistics of the causes for H <-> H intra-/inter-frequency serving cell update
failure, statistics of the causes for H <-> R99 intra-/inter-frequency handover failure,
statistics of the causes for H -> GPRS intersystem handover failure. Therefore, we
cannot use traffic statistics for HSDPA all-KPI monitoring and analysis, but need to
use other supplementary means. It is recommended to use driving test and signaling
tracing for routine monitoring of the indexes not supported by RNC1.6 version.
Meanwhile, analyze and locate KPI abnormality.
RNC1.7 traffic statistics is being collated and remains to be supplemented.
4.2 Example of Analysis Based on Observation Point

Take RRC establishment problem analysis for example.
1. Overall analysis of RRC establishment
As shown in Figure 1 the task window of the Nastar is embedded with the special
topic analysis of call completion rateRRC Setup Analysis. Double click to start
this query to get the general information about RNC-level RRC establishment. As
shown in the following figure, RRC establishment success rate reaches 98.84%. Most
of RRC establishment failure is because there is no response to RRC Setup
command delivery (7,373 times). Eighteen failures are because of RRC Setup Reject.

Figure 2 General information about RRC setup
The main cause of the exemplified RRC establishment failure is that there is no
response to RRC Setup command delivery. It is unbalanced coverage of downlink
FACH and uplink RACH. For an early network, coverage cannot be guaranteed, so
there are a large number of areas with poor coverage quality. These areas with poor
coverage always correspond to intersystem rerouting areas. On the other hand,
where there are many users or equipment problems within a cell, RRC establishment
rejection is also a major cause of RRC establishment failure.
2. Analysis of RRC establishment scenario
One important reason for RRC establishment failure is poor coverage. We may make
a further analysis by using the establishment cause distribution and success rate of
different RRCs establishment. Get results by starting related query and selecting
Scenario Analysis to present a selected RNC in the form of a pie chart and a bar
chart.

Figure 3 Distribution of RRC setup scenario
Figure 4 Comparison of RRC setup scenario success rate
Scenario Analysis makes a comparative analysis of several commonly used

scenarios. The pie chart shows the RRC establishment distribution of a main
scenario. The example in the chart indicates that RRC establishment requests mainly
exist in network registration with REG as the cause. When an LAC area is not well
planned or there is poor coverage (the margin of LAC division is in a prosperous
area), there may be a lot of registration. On the other hand, the cause of RRC
establishment during intersystem reselecting of this mobile phone is registration. A
large number of mobile phones fail to be registered due to poor coverage and will try
again and again. Thus, the cause of RRC establishment is registration in many cases.
This indicates that there is poor network coverage in some areas.

As shown in Figure 4, the bar chart compares the RRC establishment success rates
of various main scenarios. It can be seen from the examples in the figure that the
called voice service has the highest RRC establishment success rate while the calling
voice has the lowest success rate (which corresponds to a large amount of UENoRsp
analyzed earlier). The RRC establishment success rate of registration is also
relatively low. In Huawei networks, the present resident threshold is Ec/Io greater than
-18 dB. The intersystem reselecting starting threshold is Ec/Io less than -14 dB. A low
registration success rate indicates that some terminals have attempted to register at a
network in the areas without good coverage (Ec/Io is between -14 dB and -18 dB).
The called RRC establishment success rate is as high as 99.3%. If the called party
starts RRC establishment, it indicates that he is covered by a PCH. From another
point of view, this indicates that the RRC establishment success rate of expected
network coverage area may be very high.
3. Analysis of RRC establishment rejection
Another cause of RRC establishment failure is RRC establishment rejection. In the
case of RRC establishment rejection, generally too many users lead to admission
rejection, or cell equipment fault leads to access failure. RRC establishment rejection
always corresponds to some areas instead of a large network area. RRC
establishment rejection is generally analyzed based on problematic areas. In the
query results of RRC Setup Analysis, start related query to make TOPN query of Cell
RRC Analysis. Query results cover two pages, which respectively list 10 cells with the
most VS.RRC.FailConnEstab.Cell and VS.RRC.SuccConnEstab.Rate.Cell. For the
10 cells with the most RRC establishment failures and the cells with the most Rej,
start Cell RRC Reject Analysis of related query to analyze the causes for rejection.
Figure 5 Analyzing the cause of RRC rejection

According to the results of Cell RRC Reject Analysis, draw a pie chart of cause
distribution for a selected cell. Figure 5 is an exemplified pie chart of cause
distribution of RRC rejection. In this example, two RRC rejections of a cell are
because of Power Congestion. The following shows the commonly seen causes of
rejection:
1) Power Congestion: RRM makes an admission algorithm decision. Downlink
admission decision occurs. Therefore, RRM starts RRC establishment rejection.
This often occurs when heavy network load leads to congestion. Further, we may
start Cell Traffic Load Analysis of related query, pay much attention to the
maximum RTWP and the maximum TCP of this cell and make sure whether
there is uplink congestion or downlink congestion. For congestion, we may check
whether a threshold is properly set and judge whether there is any radio
interference, whether expansion is necessary.
2) CE Congestion: This is mainly because RNC considers CE resource insufficient.
CE congestion always corresponds to many users. These users exceed CE
capacity and we need to expand the capacity of this area. Further, we may start
Cell Traffic Load Analysis of related query, know about the quantity of DCH User
and predict the required CEs according to the traffic model.
3) RL Fail: During RRC establishment, NodeB considers establishment fails. This
may be NodeB fault or insufficient NodeB resource. Further, we may start Cell
Traffic Load Analysis of related query and know about the quantity of DCH users.
Determine whether the problem lies in insufficient resource or equipment fault by
analyzing the board configuration, CE configuration and logs of a corresponding
NodeB.
4) AAL2 Fail: This is mainly the AAL2 Path establishment failure of an Iub interface.
It is generally caused by insufficient transmission resource or transmission
problems. Further, we may start Cell Traffic Load Analysis of related query, know
about the quantity of DCH users and compare it with the AAL2 Path bandwidth of
transmission configuration. Thus, we can determine whether the problem lies in
equipment or insufficient transmission resource.
5) Redir.Inter.Att: Inter-frequency redirection failure starts rejection.
6) Redir.Intrat: Foreign redirection failure starts rejection.
7) Code Congestion: This is mainly because of insufficient resource. Insufficient
code resource may be seen in high traffic scenarios with microcell coverage, and
expansion is necessary. Cell OVSF Code Allocation Analysis of related query
helps analyze the use of channel codes and clarify main services.
8) Other: This is mainly an RNC internal processing problem. Its cause needs to be
confirmed according to R&D logs.

4.3 Summary
Make a similar analysis of several other special topics according to the above-
mentioned idea of the RRC connection analysis. Keep summarizing experiences in
your analysis. Special topic analysis will help greatly improve basic skills of
performance analysis.
Basic special topic analysis practice contributes to the following aspects:
9) Consolidate signaling flow and deepen an understanding of each UTRAN PI.
Performance analysis has a more definite object in view.
10) Basic special topic analysis enables us to make a preliminary analysis of network
performance and locate simple problem causes.
11) Summarize the relationship between performance KPIs and network problems,
and lay a foundation for the use of other Nastar functions and an in-depth
analysis of network performance.

5 Closing of Performance Analysis
and Quality Early Warning
5.1 Basic Requirements for Analysis Conclusion

Performance early warning analysis is a key step to find problems accurately and
timely. It is also the basis for subsequent problem location and problem solving as
well as the prerequisite to formulating a subsequent scheme. If on-site personnel and
a regional division are unable to locate a problem, it is quite possible that the
Headquarters needs to participate in the location. Even the R&D personnel should be
organized to tackle this problem. To improve efficiency and avoid duplication of labor,
we have put forward the following requirements for an analysis conclusion:
Do verify related observation points of an early warning problem one by one, and
draw a basic conclusion.
Do make a definite description of equipment alarm.
Do have a definite location of analysis range, for example, what cells and what
UEs are problematic and whether there is any problem with transmission.
Do expound carefully the deduction process of an early warning conclusion.
Do provide subsequent test methods, suggested solutions, and candidate
schemes.
Do make a preliminary judgment of the signaling flow that may be involved, for
example, signaling flow abnormality, location of abnormality, or cause
distribution.
If a problem is estimated to escalate to a higher level, do carry necessary data.
For details, refer to respective problem location guides and provide pertinent
excerpts. For example, there is no need to send back whole-day driving test data
and use it for the analysis of a call drop point. There should be a simple
description of data, such as point of time of problem occurrence and the mapping
between the time and sequence number of different data.

5.2 Output Analysis Report

If any abnormality problem or quality risk occurs during performance analysis, we
need to work out a report in time. The report should include performance problem
description and suggestions on problem solving.
For the call drop caused by other, if we cannot find out the cause from CHR
information, we need to include the dotting information of CHR in the report and
submit analysis suggestions to the product R&D personnel. The R&D personnel will
analyze the specific cause.
5.3 Summary
According to network performance analysis results, formulate optimization strategies,
implement optimization schemes, and compare the indexes before and after the
optimization to obtain optimization implementation effects. In this way, one
performance analysis is closed. But performance analysis and quality early warning
come full circle. The increase in network registration users, change in traffic model,
and equipment transmission abnormality require that engineers should show
continuous concern for network performance, summarize experiences and use proper
methods to improve the efficiency of performance analysis.

6 References
UTRAN KPI Analysis Guide-20051010-A-1.0

UMTS Performance DepartmentRAN Performance Optimization Idea
GENEX Nastar WCDMA User Manual (CHN)
Guide to Analysis of UMTS Network Planning Remote Network Performance
-20060524
UMTS Radio Performance Department Commercial Network Index
Optimization_Call Drop Rate Optimization (V1.0)
Alarm Analysis Guide

W Network Performance Analysis Guide 20081129 A 1.3

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

W Network Performance Analysis Guide 20081129 A 1.3

Загружено:

Авторское право:

Доступные форматы

Guide to Analysis of WCDMA Network Performance For Internal Use Only

Product Name Confidentiality Level

WCDMA RNP For Internal Use Only

Guide to Analysis of WCDMA Network

Brainstorming and Case

Reviewed by: Date:

Reviewed by: Date:

Approved by: Date:

2008-11-29 All Rights Reserved Page 1 of 83

Huawei Technologies Co., Ltd

2008-11-29 All Rights Reserved Page 2 of 83

Some errors are revised and subsequent

October 20, The document is revised according to the review

2008-11-29 1.31 Review yearly Xiao Zhao

2008-11-29 All Rights Reserved Page 3 of 83

2008-11-29 All Rights Reserved Page 4 of 83

4.1.3 Call Drop Analysis Observation Point......................................................................57

2008-11-29 All Rights Reserved Page 5 of 83

Figure 1 Measurement of performance index........................................................................13

2008-11-29 All Rights Reserved Page 6 of 83

Guide to Analysis of WCDMA Network Performance

Acronyms and Abbreviations

Abbreviation Full Spelling

ALCAP Access Link Control Application Part

APS ATM Protection Switching

CCP Communication Control Port

CDL Call Detail Log

CDR Call Drop Rate

CHR Call History Record

CHR Calling History Record

GPS Global Positioning System

IOS Intelligent Optimization System

KPI Key Performance Index

MSP Multiplex Section Protection

MTP3B Message Transfer Part

2008-11-29 All Rights Reserved Page 7 of 83

Abbreviation Full Spelling

NCP NodeB Control Port

NEMU NodeB Environment Monitor Unit

NMON NodeB Monitor Unit

RAB Radio Access Bearer

RNC Radio Network Controller

RRC Radio Resource Control

RRU Radio Remote Unit

SAAL Signaling ATM Adaptation Layer

SCCP Signaling Connection Control Part

2008-11-29 All Rights Reserved Page 8 of 83

A commercial network requires regular performance analysis and observation of QoS

1.1 Purpose of the Document

2008-11-29 All Rights Reserved Page 9 of 83

Some other questions are not listed here.

1.2 Users of the Document

2008-11-29 All Rights Reserved Page 10 of 83

foremost prerequisite is to acquire a good knowledge of the war situation a

2008-11-29 All Rights Reserved Page 11 of 83

Performance Analysis and Quality Early

2.1 Creating Network Planning and Network Optimization

2008-11-29 All Rights Reserved Page 12 of 83

2.2 Signaling Flows of UTRAN and Basic Principles of

2008-11-29 All Rights Reserved Page 13 of 83

2.2.2 Fast Makeup of Knowledge Points

2.3 Familiarization of UTRAN PIs

2008-11-29 All Rights Reserved Page 14 of 83