

Revision History

Date Revision

Version Description Author

August 28,

2006 1.00 First draft is finished. Zuo Yanzhong

September

24, 2006 1.1

Some errors are revised and subsequent

optimization parts are simplified according to review

comments. The emphasis is to find problems.

Analysis based on observation points and

subsequent analysis data requirements are added.

He Fengming

October 20,

2006 1.2

The document is revised according to the review

comments of the CCB. He Fengming

October 28,

2006 1.3 Alarm analysis is added. He Fengming

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

NCP NodeB Control Port



Abbreviation Full Spelling

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

“Parameter 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:

1) Signaling flows of the UTRAN, such as RRC connection establishment flow, RAB

establishment flow, and soft handover flow.

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

1) Advanced Training for W Network Planning----Signaling Flow.ppt

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



1) 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.2 “Example of Analysis Based on

Observation Point”.

2) Analyze the relations between traffic statistics PIs and network problems. Define

the nature of such problems.

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

Actual Cause of

Call Drop

Traffic

Statistics PIs for Call Drop

RF Cause

Uplink Interference

Overload

Flow

Transmission

Abnormal

Equipment

Abnormal Mobile

Phone

OM Operation

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 Huawei’s 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:

1) Customization and second query of PI

2) Optimization solution to Intra-frequency adjacent cell



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

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

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

6) Configuration verification

7) 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 2 Normal performance KPI of network

AMR DL12.2 Erlang

VP DL Erlang

CS Erlang

PS UL Erlang

PS DL Erlang

PS UL Throughput

Traffic

PS DL Throughput

RRC Connection Setup Success Rate (service) (>98%)

RRC Connection Setup Success Rate (other) (>95%)

AMR RAB Assignment Success Rate (>98%)

Video Call RAB Assignment Success Rate (>98%)

Access

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

CS Inter-RAT Handover Success Rate (from UTRAN to GSM)

(>96%)

HO

PS Inter-RAT Handover Success Rate (from UTRAN to GSM)

(>92%)

CS AMR Call Drop Rate (<1.5%)

R99

CDR

VP Call Drop Rate (<3%)



PS Service Drop Rate (<5%)

HSDPA RLC Traffic Volume (MBytes)

HSDPA Mean UE Traffic

HSDPA RLC Throughput (Mbps)

Access HSDPA RAB Setup Success Rate (>97%)

HS-DSCH Service Cell Change Success Rate (with SHO)(>99%)

HS-DSCH Service Cell Change Success Rate (with Intra

HHO)(>95%)

HS-DSCH Service Cell Change Success Rate (with Inter

HHO)(>95%)

HS-DSCH to DCH Handover Success Rate (>95%)

HO

DCH to HS-DSCH Handover Success Rate (>95%)

HS

DP

A:

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.



Chart 9. Drop Call Rate

0.0%

0.5%

1.0%

1.5%

2.0%

2.5%

3.0%

3.5%

2006

-01-

16

2006

-01-

21

2006

-01-

26

2006

-01-

31

2006

-02-

05

2006

-02-

10

2006

-02-

15

2006

-02-

20

2006

-02-

25

2006

-03-

02

2006

-03-

07

2006

-03-

12

2006

-03-

17

2006

-03-

22

2006

-03-

27

2006

-04-

01

2006

-04-

06

2006

-04-

11

2006

-04-

16

2006

-04-

21

2006

-04-

26

2006

-05-

01

2006

-05-

06

2006

-05-

11

2006

-05-

16

2006

-05-

21

2006

-05-

26

2006

-05-

31

2006

-06-

05

2006

-06-

10

2006

-06-

15

2006

-06-

20

2006

-06-

25

2006

-06-

30

2006

-07-

05

Drop Call Rate Voice(3G)

Drop Call Rate Video(3G)

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 3 PS call drop analysis of top 10 cells

PS Call Drop(2006-08-18) PS Call Drop Rate(2006-08-18)

CellId CellName

PS Call

Drops CellId CellName

PS Call

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)

CellId CellName

PS Call

Drops CellId CellName

PS Call

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

1 2006.01.02

Change the maximum permissible uplink transmit power to 24

because some mobile phones support the maximum transmit

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

3 2006.02.04 Change the intra-frequency rerouting starting threshold to -4

dBm. See the table “Cell_SelReselParas_CR”.

4 2006.02.05

Change the admission and congestion parameter settings of

Hong Kong Island. For details, see CELL_CACPara and

CELL_LCCPara.

5 2006.02.06

Change intra-frequency measurement parameters including

Layer 3 filtering coefficient, 1A1B relative threshold, and delay

trigger time and so on. See the table

“Cell_IntraFreqHOMrParas_CR”.

6 2006.02.07

For some cells to tunnels and underground 3G-2G handover

and change of inter-RAT measurement starting threshold and

decision threshold, see the table

“Cell_IntraFreqHOMrParas_CR”.

7 2006.02.08

Turn on the common channel flow control switch of the IUR

interface because an IUR interface is configured between the

RNC1 and RNC2 of the current SUNDAY.

8 2006.03.09

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.

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.

10 2006.03.11

The static transition switch is turned off to avoid the possible

call drop caused by some mobile phones not supporting static

transition.

11 2006.03.12

The downlink blind detection switch is turned off to avoid

one-way audio caused by some mobile phones not supporting

blind detection.

12 2006.04.13 T314 and T315 are set to 0. Disable Cell Update caused by





RLFAILURE.

13 2006.04.14 Change the number of continuous synchronization indication to

1. See the table “CellBasicInfo”.

14 2006.04.15 Change the minimum access quality to -20 dB. See the table

“Cell_SelReselParas_CR”.

15 2006.04.16 Change times of random access preamble retransmission to 20

times. See the table “CellPrachParas”.

16 2006.05.17

To avoid poor streaming quality caused by code transmit power

limit, the maximum service code transmit power of PS 144 is

increased by 2 dB and is the pilot channel power +2 dB. See

the table “Celltrafficpower”.

17 2006.05.18

To check the adjacent cells that miss configuration or potential

adjacent cells, turn on the monitoring set reporting switch. See

the table “SWITCH”.

18 2006.05.19

The uplink BE service rate negotiation threshold is 8K and the

downlink BE service rate negotiation threshold is 64K. See the

table “SWITCH”.

19 2006.06.20

Add cell location configuration information. The maximum

coverage distance of a cell antenna is 500 m. Activate the

AGPS location activation identifier. See “CellSMLCParas”.

20 2006.06.21 The maximum retransmission times of location measurement

can be set to 0. See the table “SWITCH”.

21 2006.07.22 The hard handover hysteresis is 6 (3 dB). 2D trigger time is 640

ms.

22 2006.07.23 NBMULCACALGOSELSWITCH uplink admission switch is

turned off. See the table “SWITCH”.

23 2006.07.24

Change inter-RAT cell reselecting starting threshold

(Ssearchrat) to 3, inter-frequency cell reselecting starting

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.

1) Important holidays: During important holidays, such as the Spring Festival,

Christmas Day, Buddha’s 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.

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

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

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

2) Traffic statistics data

3) Configuration data

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

5) RTWP data (optional). It is chiefly used for interference analysis. It may be

omitted if interference analysis is definitely unnecessary.

6) IOS data (optional). It is used for an in-depth location analysis of many network

abnormality problems, such as coverage.

7) 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.2 “General Idea of Performance

Analysis and Quality Early Warning” from historical experiences. According to the

general idea, section 3.3.3 “Quick 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:

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

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

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

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



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

Deterioration of network quality

Collect and analyze alarm

information

Does the alarm affect KPI?

Analysis of

other problems

Does the alarm correlate to the decreased KPI?

Find out and recover major

alarms

Does KPI resume to normal?

End

Yes

Yes

Yes

Yes

No

No

No



Table 4 Alarm influence

Alarm Type Performance Impact

Trunk alarm

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




Signaling alarm

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

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

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

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.




Hardware alarm

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

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.




Running alarm

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

alarm

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

normal service running.

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.




Environment

alarm

An environment alarm generally does not affect the service and

KPI of the system. But some environment alarms deteriorate

product performance or functions of some products. They will be

analyzed accordingly. Among the environment alarms of RNC,

GPS antenna alarm affects only location service instead of any

other service.

Power alarm

Generally, power alarm does not affect service at all, but

hardware alarm caused by power alarm may make service

abnormal. This case will be analyzed accordingly.

Processing error

alarm Processing error alarm involves only RNC instead of NodeB.

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

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

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

3) 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 2 points 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:

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

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

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

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



5) 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.2 “Preparation

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.



Figure 6 Performance analysis flow

(1) Overall analysis of network KPI

Is there any KPI deterioration?

(2) RNC equipment/IU transmission/parameter

Is there any equipment

problem/transmission fault?

(3) KPI analysis of TopN cells

Is there any cell equipment problem?

Solve RNC equipment/IU transmission problems.

Solve cell equipment problems

(5) Analysis of cell load problems

Is there any overload problem?

Whole-network traffic statistics

Traffic statistics Alarm

Cell traffic statistics

(4) Analysis of cell-related equipment

Cell traffic statistics RNC and Node B alarm

Traffic statistics: IUB bandwidth CE resource Equipment resource Radio resource

Solve overload problems

A

END

Y

N

N

Y

Y

N

N

Y



Figure 7 Performance analysis flow (Continued)

(6) Analysis of cell interference problems

Is there any interference

problem? Solve cell interference problems

A

CHR: NodeB RTWP Cell load information Special interference analysis

(7) Analysis of cell coverage problems

Is there any coverage problem?

CHR: Pilot pollution Extraction of coverage information IOS Trace: Analysis of cell coverage quality

Solve cell coverage problems

(8) Analysis of cell parameter problems

Is there any parameter problem?

CHR: Optimization of adjacent cells Configuration verification Parameter optimization

Solve parameter problems

(9) CHR flow/terminal performance

Is there any terminal performance

problem? Terminal defect list

CHR: Statistical analysis of mobile phone problems

B

N

Y

Y

N

Y

N

Y

N



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 5 Overall analysis of network KPIs

AMR DL12.2 Erlang 13.08 (11:00–12:00)

VP DL Erlang 0.39 (17:00–18:00)

CS Erlang 15.86 (18:00 – 19:00)

PS UL Erlang 167.19 (21:00–22:00)

PS DL Erlang 554.03 (21:00–22:00)

PS UL Throughput 2675.06 (21:00–22:00)

Traffic

PS DL Throughput 8864.55 (21:00–22:00)

RRC Connection Setup Success Rate

(service) (>98%) 99.78% (135343/135638)

RRC Connection Setup Success Rate

(other) (>95%) 99.31% (170930/172122)

R99

Access

AMR RAB Assignment Success Rate

(>98%) 99.66% (18595/18659)



Video Call RAB Assignment Success

Rate (>98%) 99.57% (230/231)

PS RAB Assignment Success Rate

(>97%) 99.59% (95524/95918)

Soft Handover Factor based on Radio

Link Number (<50%) 22.66%

Soft Handover Success Rate (>99%) 99.72% (318538/319439)

Inter-Freq Hard Handover Success

Rate (>95%) N/A (0/0)

CS Inter-RAT Handover Success Rate

(from UTRAN to GSM) (>96%) 98.76% (6198/6276)

HO

PS Inter-RAT Handover Success Rate

(from UTRAN to GSM) (>92%) 96.10% (44834/46653)

CS AMR Call Drop Rate (<1.5%) 0.35% (66/18595)

VP Call Drop Rate (<3%) 0.87% (2/230) CDR

PS Service Drop Rate (<5%) 5.08% (4854/95524)

HSDPA RLC Traffic Volume (MBytes) 19373

HSDPA Mean UE 68.18 (18:00–19:00) Traffic

HSDPA RLC Throughput (Mbps)

Access HSDPA RAB Setup Success Rate

(>97%) 98.24% (14360/14617)

HS-DSCH Service Cell Change

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


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


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

HS-DSCH to DCH Handover Success

Rate (>95%) 99.38% (961/967)

HO

DCH to HS-DSCH Handover Success

Rate (>95%) 83.28% (792/951)

HS

DP

A

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.3 “Network 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.2 “Mastery 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.

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

2. Do indexes satisfy the

requirements?

3. Subdivide into cell equipment

problems

4. Query equipment alarm

5. Coverage quality problem

9. Cell reselecting problem

11. Overload admission problem

6. Ec/Io analysis

7. Overshoot analysis

8. Missing configuration of

adjacent cell

10. Analysis of adjacent cell

coverage quality

12. Load and interference

analysis

Y

N

Y

N

1. Query RRC establishment by using the

network performance analysis function



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.



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

2. Do indexes satisfy the

requirements?

3. Subdivide into cell equipment

problems

4. Query equipment

alarm

5. Coverage quality

problems

8. Intra-frequency

handover problem

10. Overload admission

problems

6. Ec/Io

analysis

7. Missing configuration of

adjacent cell

9. Analysis of adjacent cell

coverage quality

11. Load and interference

analysis

Y

N

Y

N

1. Query RAB establishment success rate by using the performance

analysis function



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:

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

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

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

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

1) RRC establishment analysis observation point

2) RAB establishment analysis observation point

3) Soft handover analysis observation point

4) Call drop analysis observation point

5) CS/PS intersystem handover analysis observation point

6) Traffic analysis observation point

7) Key interface process analysis observation point

8) 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 10 Special topic analysis

4.1 Observation Points of Typical Problems

4.1.1 RRC Establishment Analysis Observation Point

Table 6 RRC Establishment Observation Point

Observation

Point Condition

Possible

Cause Analysis Idea

Categories of

RRC

establishment

requests

Observe various

types of RRC

connection

establishment

requests and

their proportional

distribution. If any

abnormality, we

need to give an

early warning.

If there are many streaming class called

service requests (accounting for over 10%

of total connection establishment

requests), we need to pay much attention

to them. This is because when UE changes

from DCH status into IDLE status, PS

needs to transmit packets, then ps paging

occurs and the corresponding RRC

requests are streaming class called service

requests. If there are too many requests of

this type, it is possible that the timer from

DCH status to IDLE status is not properly

set.

AAL2

establishment

failure

It is generally caused by insufficient

transmission resource or transmission

fault. You may query the cell downlink

throughput at the moment from associated

traffic statistics indexes. If it is lower than

200 kbps, transmission fault may occur.

RRC

establishment

failure

Number of RRC

connection

establishment

failures (>=5);

RRC connection

establishment

failure rate

(>=10%)

RL

establishment

failure

It may be caused by NodeB fault or

insufficient NodeB resource. You may

query the maximum downlink CE of a cell



Observation

Point Condition

Possible

Cause Analysis Idea

from associated traffic statistics index. If

the maximum uplink CE is less than 20,

then traffic is not high and the problem lies

in abnormal NodeB equipment.

Power

congestion

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

maximum TCP of the cell to confirm uplink

congestion or downlink congestion and

judge whether any expansion is necessary.

Meanwhile, we should check whether

related admission strategy settings, such

as DCCC, are proper.

Uplink CE

congestion

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

equipment.

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.

Downlink CE

congestion

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

NodeB equipment.





Observation

Point Condition

Possible

Cause Analysis Idea






Code

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

You may query the effective 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.

Other

congestion

leads to RRC

rejection.

Generally the congestion caused by

unknown insufficient resources. For

example, license resource and high CPU

utilization make flow control and FMR

processing capacity insufficient. In addition,

E1 fault also appears. This cause value is

dotted.

Transmission

congestion

Transmission congestion is mainly caused

by insufficient transmission resource. You

may query the downlink cell throughput

from associated traffic statistics indexes. If

the downlink cell throughput is lower than

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.

Other factors

lead to RRC

rejection.

Abnormal causes. We need to make

in-depth location based on RNC logs. The

known problem is that the system

redirection function of the network is

enabled. During redirection, a mobile

phone does not support GSM and thus



Observation

Point Condition

Possible

Cause Analysis Idea

failure rejection occurs.

No response

from UE

This is generally caused by poor coverage.

The downlink FACH and RACH have

unbalanced coverage.

Other factors

lead to RRC

establishment

failure.

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

access DSP of node B. The RRC

CONNECTION SETUP REQUEST

message fails to be sent to RNC. The

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 7 RAB establishment observation point

Observation

Point Condition

Possible

Cause Analysis Idea

Transmission

network

Generally transmission equipment fault or

insufficient transmission capacity. You

need to query the transmission utilization of

that time.

Migration

In starting migration, RNC receives a RAB

establishment request, but does not

process it. This is mainly caused by flow

nesting and seldom occurs. It is related to

user behavior sequence. This is generally

avoided in a core network.

CS/PS RAB

establishment

failure

Number of

CS/PS RAB

establishment

failures (>=5);

CS/PS RAB

establishment

failure rate

(>=10%)

Power

congestion

RRM admission decision cannot establish

any new RRC connection due to too high

radio load within a cell. In this case, you



Observation

Point Condition

Possible

Cause Analysis Idea

need to query the maximum RTWP and the

maximum TCP of the cell to make sure of

uplink congestion or downlink congestion

and judge whether any expansion is

necessary. Meanwhile, we should check

whether related admission strategy

settings, such as DCCC, are proper.

Uplink CE

congestion

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

equipment.








Downlink CE

congestion

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 abnormal

NodeB equipment.










Observation

Point Condition

Possible

Cause Analysis Idea

Code

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

You may query the effective 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

Transmission congestion is mainly caused

by insufficient transmission resource. You

may query the downlink cell throughput

from associated traffic statistics indexes. If

the downlink cell throughput is lower than

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.

Others Abnormal causes. We need to make an

in-depth location based on RNC logs.

Air interface

failure

The air interface failure occurring during

RB establishment is generally caused by

poor coverage or mobile phone

compatibility.

Configuration

not supported

The compatibility of a mobile phone itself

becomes faulty in some unknown

scenarios. For example, when a Huawei

mobile phone drops network abnormally, it

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.

Physical

channel failure

This generally occurs when FACH migrates

to DCH and sets up RB. The downlink

physical layer of a terminal is not



Observation

Point Condition

Possible

Cause Analysis Idea

synchronized, which leads to RB

establishment failure. This is mainly caused

by poor coverage.

Cell update

The Cell Update flow occurs during RB

establishment. This nested flow leads to

RB establishment failure.

Illegal

configuration

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 at once goes onhook. RB SETUP

failure may also occur at this time. The

cause is illegal configuration.

No response

from UE

Generally poor coverage makes UE unable

to receive any RB establishment command.

Parameter error

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

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 8 CS/PS call drop observation point

Observation

Point Condition

Possible

Cause Analysis Idea

CS/PS call

drop

High CS/PS call

drop rate OM intervention

Call drop caused by operation and

maintenance. For example, the execution

of TRG RABRel on LMT causes users to

be released.



Observation

Point Condition

Possible

Cause Analysis Idea

RAB

preemption

High-priority users preempt low-priority

users when admission is rejected. This

causes a link to be released. This kind of

call drop occurs in the case of load and

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.

Uplink/downlink

RLC reset

Uplink or downlink signaling RB reaches

the maximum retransmission times and

resets. This causes a link to be released.

This case is mainly caused by poor

coverage quality (including missing

configuration of adjacent cells and small

handover area).

Uplink

synchronization

failure

RNC receives RL Failure reported by

NodeB, which causes a link to be

abnormally released. In this case, poor

coverage quality (including missing

configuration of adjacent cells and small

handover area) makes UE abnormally shut

down the transmitter, or uplink

demodulation out-of-sync.

Downlink

synchronization

failure

Receive the Cell Update message reported

by a mobile phone. The cause is downlink

RL Failure, which makes a link abnormally

released. In this case, poor coverage

quality (including missing configuration of

adjacent cells and small handover area)

makes UE abnormally shut down the

transmitter, or uplink demodulation

out-of-sync.



Observation

Point Condition

Possible

Cause Analysis Idea

The UU

interface makes

no response.

RNC delivers a message and waits for the

response from a mobile phone, but timeout

occurs. For example, waiting for RB

reconfiguration completion message times

out and waiting for active set update

completion times out. This case is

generally caused by poor coverage.

Other RF

causes RF cause; due to poor coverage quality

Abnormal AAL2

link

RNC finds that the AAL2 Path of the IU CS

interface is abnormal and starts abnormal

release. It is possible that the transmission

equipment of the Iu interface is abnormal.

The known problem is that immediate

normal release during RB establishment is

classified by traffic statistics into abnormal

release.

Abnormal

GTPU

RNC finds that the GTPU of the IU PS

interface is abnormal and starts abnormal

release. The cause may be equipment fault

or defect.

Others

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

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 9 Soft handover analysis observation point

Observation

Point Condition

Possible

Cause Analysis Idea

Soft

handover

rate

Soft handover

rate based on

cell resource

allocation and

soft handover

rate based on

IUB transmission

resource

allocation.

Possible causes of too high (>= 40%) a

soft handover rate:

1) Handover parameter setting makes

addition easy, but deletion difficult.

2) In the early days of network

construction, there are few base

stations and insufficient coverage.

Therefore, capacity gives way to

quality.

3) The CN side of some partners does

not deliver Iu release. After a user’s

dial-up access is disconnected, there

is only user plane release instead of

signaling plane release. Users have

soft handover even after a network is

disconnected.

Configuration

not supported

UE considers that the content of the active

set update of RNC adding/deleting a link is

not supported. Generally, this scenario will

not appear in commercial use.

Synchronization

reconfiguration

not supported

UE gives the feedback that the softer/soft

handover process of RNC adding/deleting

a link is incompatible with other concurrent

processes. RNC has guaranteed serial

flow processing. Soft handover execution

failure is mainly caused by the problematic

processing of some mobile phones.

Soft

handover

execution

failure

Number of

soft/softer

handover failures

(>=5) and

soft/softer

handover failure

rate (>=10%)

Illegal

configuration

UE considers that the content of the active

set update of RNC adding/deleting a link is

illegal. Generally, this scenario will not

appear in commercial use..



Observation

Point Condition

Possible

Cause Analysis Idea

No response

from UE

RNC does not receive the active set

update command response for

adding/deleting a link. This is the main

cause of softer/soft handover failure. This

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 10 Intersystem handover observation point

Observation

Point Condition Possible Cause Analysis Idea

Hard

handover

preparation

failure

Preparation

failures (>=5) of

hard handover

into this cell and

preparation

failure rate

(>=10%) of hard

handover into

this cell

Radio link establishment failure occurs

during RL establishment. For details, see

the RL establishment process analysis of

the IUB interface.

For other causes, we need to make a

further analysis based on RNC logs.

A target cell has

no wireless

network

resource

available.

A target cell has no resource available, or

there is some RNC parameter

configuration error. We need to make an

analysis based on RNC logs.

Transition

timeout of target

system

The problem often lies in CN parameter

configuration or a related link connection.

We need to make an analysis based on

RNC logs.

Preparation

failure of

transition out

of cell

accompanied

by hard

handover

Preparation

failures (>=5) of

transition out of

cell accompanied

by hard handover

and preparation

failure rate

(>=10%) of

transition out of

cell accompanied

by hard handover Transition failure

in the target

CN/RNC or

system

It generally corresponds to core network

configuration error.



Observation


Transition in the

target CN/RNC

or system not

supported

Generally, RNC does not support some

hard handover parameters. We need to

make an analysis based on RNC logs.

Transition

objective not

allowed

Often an MSC parameter configuration

error. We need to check the parameter

configuration of a core network.

OM intervention Failure caused by operation and

maintenance

No available

resource

Often an MSC parameter is configured

incorrectly, or a target RNC has no

resource available.

Undefined Failure causes are not defined in traffic

statistics.

Others We need to make an analysis based on

RNC logs.

Waiting for

transition

command

timeout

A core network does not return a

corresponding command of handover

preparation request. In this case, there is

some problem with the parameter

configuration or related link connection of

a core network. We need to analyze the

cause according to the signaling trace of

the core network and BSS.

Preparation

failure of

RNC-level

foreign

outgoing

handover

Preparation

failures (>=5) of

RNC-level

CS/PS domain

intersystem

outgoing

handover,

preparation

failure rate

(>=10%)of CS

domain

intersystem

outgoing

handover Transition

cancelled

Upon requesting handover preparation,

RNC receives the release command from

a core network. Two cases: intersystem

handover request occurs during signaling

process like location update. The location

update flow has been finished before one

flow is finished. The core network starts

release; the user who sets up a call goes

onhook during handover preparation, and

the core network starts release. No

handover is finished in either case, but

either is normal flow nesting.



Observation


Transition

timeout


configuration error. We need to analyze

the cause according to the signaling

tracing of a core network and a BSS.

Transition failure

in the target

CN/RNC or

system

The problem often lies in the parameter



cause according to the signaling tracing of

a core network and a BSS.

Unknown target

RNC

The problem often lies in an MSC

parameter configuration error. That is, the

LAC of the target cell fails to be

configured. We need to check the

parameter configuration of a core network.

This case is often seen after the

adjustment of 2 G network.

No available

resource

The problem often lies in an MSC

parameter configuration error, or BSC has

no resource available. We need to analyze

the cause according to the signaling

tracing of a core network and a BSS.

Others

We need to analyze the cause according

to the signaling tracing of a core network

and a BSS.

Transition

timeout

The problem often lies in the parameter



cause according to the signaling tracing of

a core network and a BSS.

Preparation

failure of

Cell-level

foreign

outgoing

handover

Preparation

failures (>=5) of

CELL-level CS

domain

intersystem

outgoing

handover and

preparation

failure rate

(>=10%) of CS

Transition failure

in the target

CN/RNC or

system


configuration error or BSS not supporting.



and a BSS.



Observation


Transition in the

target CN/RNC

or system not

supported

In this case, a BSC does not support some

parameters of intersystem handover

requests. We need to analyze the cause

according to the signaling tracing of a core

network and a BSS.

domain

intersystem

outgoing

handover.

Others



and a BSS.

Configuration

not supported

UE considers that the command for hard

handover out of a cell is not supported.

The problem generally lies in the

compatibility of a mobile phone.

Physical channel

failure

Possibly poor coverage or severe

interference

Synchronization

reconfiguration

not supported

UE gives the feedback that hard handover

process is incompatible with other

concurrent processes. The problem may

lie in the compatibility of a mobile phone

itself.

Cell Updating

Procedure

Cell update happens during hard

handover out of a cell. This flow nesting

leads to the failure of hard handover out of

a cell.

Illegal

configuration

UE considers that the command for hard

handover out of a cell is illegal. The

problem generally lies in the compatibility

of a mobile phone.

Outgoing

hard

handover

failures within

NODE B,

between

different

NodeBs

within RNC,

and between

RNCs

Failures (>=5) of

hard handover

out of a cell,

failure rate

(>=10%) of hard

handover out of a

cell

Others We need to make a further analysis based

on RNC logs.

Failure of

transition out

of a cell

accompanied

by hard

Execution

failures (>=5) of

transition out of a

cell accompanied

by hard

Configuration

not supported

UE considers that the command for

transition out of a cell accompanied by

hard handover is not supported. The


of a mobile phone.



Observation


Physical channel

failure

Possibly poor coverage or severe

interference

Synchronization

reconfiguration

incompatible

UE gives the feedback that the hard

handover process of RNC adding a link is

incompatible with other concurrent

processes. The problem may lie in the

compatibility of a mobile phone itself.

Illegal

configuration

UE considers that the command for

transition out of a cell accompanied by

hard handover is illegal. This case seldom

occurs.

Configuration

not finished

handover handover,

execution failure

rate (>=10%) of

transition out of a

cell accompanied

by hard handover

Others We need to make a further analysis based

on RNC logs.

Configuration

not supported

The handover command terminal in a

network does not provide support. The


of a mobile phone.

CS/PS

foreign

handover

failure

CS/PS domain

intersystem

handover failures

(>=5), CS/PS

domain

intersystem

handover failure

rate (>=10%)

Physical channel

failure

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

those of a BSC. We need to compare

and confirm the parameters of a

terminal and those of a BSC. Physical

channel failure generally occurs in a

network with partners’ equipment as

the CN. We need to check the

encryption algorithm configuration of

an MSC and an SGSN.



Observation


Others

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

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 11 Traffic analysis observation point

Observation

Point Condition Analysis Idea

Uplink CE

Lay an emphasis upon

the analysis of “average

uplink CE resource

occupied” and “the

maximum uplink CE

resource occupied”.

Observe whether “the maximum uplink CE

resource occupied” approaches 128. If it does, an

early warning needs to be given to expansion.

Normally, when the “average uplink CE resource

occupied” is less than 60 CE Erlang,

whole-network busiest-hour cell traffic is very

small.

Downlink CE

Lay an emphasis upon

the analysis of “average

downlink CE resource

occupied” and “the

maximum downlink CE

resource occupied”

Observe whether “the maximum downlink CE

resource occupied” approaches 128. If it does, an

early warning needs to be given to expansion.

Normally, when the “average downlink CE

resource occupied” is less than 60 CE Erlang,

whole-network busiest-hour cell traffic is very

small.

Average transmit

power of cell

List the average TCP,

the maximum TCP and

the minimum TCP of a

cell.

If the average transmit power of a cell is large and

there is small traffic, it indicates that there is poor

downlink coverage.

Maximum

transmit power of

cell

List the average TCP,

the maximum TCP and

the minimum TCP of a

cell.

If the maximum transmit power of a cell is large

and there is small traffic, it indicates that power

peak shock may lead to power congestion.



Observation


Minimum

transmit power of

cell

Observe whether the

minimum transmit power

of a cell is abnormal.

If the minimum transmit power of a cell is

abnormal, the transmit channel may become

faulty.

Average RTWP

List the average RTWP,

the maximum RTWP,

and the minimum RTWP

of a cell.

If the average RTWP of a cell is higher than -95

dBm, there may be downlink interference.

Maximum RTWP Observe whether there

are many peaks.

Among various items, RTWP peaks, for example,

-70 dBm, often appear. This may be caused by the

power of access process or handover process.

Minimum RTWP

Observe whether the

minimum RTWP is less

than -105.5 dBm.

If the minimum RTWP is lower than -108 dBm, a

channel fails to be corrected, or a base station

encounters power-down.

Effective

utilization of

codes

Observe whether the

code utilization is

abnormal.

If the effective utilization of codes is not high (<=

30%), but code congestion leads to access failure,

it is possible that the code distribution algorithm is

abnormal.

Uplink

throughput of cell

Observe the uplink

throughput of a cell.

Observe whether the uplink throughput of a cell is

great. If it amounts to 75% of the transmission

capability of a base station, transmission

expansion needs to be considered.

Downlink

throughput of cell

Observe the downlink

throughput of a cell.

Observe whether the downlink throughput of a cell

is great. If it amounts to 75% of the transmission

capability of a base station, transmission

expansion needs to be considered..

Cell status

monitoring

List the cell unavailability

duration and its

proportion.

This is generally caused by transmission

interruption or intermittent transmission failure.

Some offices are greatly influenced by weather

due to the use of microwave transmission.

Thunder storm always leads to intermittent

transmission failure.

Missing

configuration of

adjacent cell

List the number of cell

1A events.

If 1A events often happen within many

consecutive days, there may be missing

configuration of adjacent cells.



Observation


Excess

configuration of

adjacent cells

Pilot Pollution: List the number of cell

1C events.

If 1C events often happen within many

consecutive days, there may be pilot pollution.

4.1.7 Key Interface Flow Analysis Observation Point

Table 12 Key interface flow analysis observation point

Observation

Point Condition

Possible

Cause Analysis Idea

Radio

network layer

The problem may lie in the compatibility

of a mobile phone. A mobile phone

terminal may detect the SQN error of in

an AUTN message, which leads to

failure. Cause value: Synch failure!

Respective encryption modes of CS

domain and PS domain may also lead to

a security mode failure.

Transmission

layer

Correspond to transmission link

abnormality.

Network

optimization

Security mode

flow failure

IU security mode

failures, IU

security mode

failure rate

Undefined

OM

intervention

RL failure of IUR interface caused by

operation and maintenance

Hardware

failure

This generally corresponds to equipment

abnormality. We should first query

related equipment alarm.

RL

establishment

failure of the IUR

interface

RL

synchronization

configuration

failure of the IUR

interface

RL addition

failure of the IUR

List the number of

RL establishment

failures (>= 5) of

the Iur interface of

the SRNC, RL

establishment

failure rate (>=

10%) of the Iur

interface of the

SRNC, and main

failure causes.

RNC resource

unavailable

This is caused by insufficient RNC

internal resource. You need to query the

quantity of related users to judge

whether there is any equipment

abnormality.



Observation

Point Condition

Possible

Cause Analysis Idea

Configuration

not supported

UE considers that the RL configuration

content of RNC establishment is not

supported. The problem lies in the

compatibility of a mobile phone.

Others Abnormal causes. We need to make an

analysis based on RNC logs.

interface

No response


abnormality. We need to query whether

there is any power-down.

Configuration

not supported

The problem lies in the compatibility of a

mobile phone itself in some unknown

scenarios.

No available

resource

Insufficient RNC internal resource or

abnormal RNC equipment. You need to

query cell CE resource from relevant

parameters to judge whether there is any

equipment abnormality. Equipment is

known to encounter repeated power

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

fault


abnormality. We should first query

related equipment alarm.

OM

intervention

RL establishment failure caused by

operation and maintenance (for example,

cell blocking)

NodeB makes

no response

The problem may lie in cell unavailability

or equipment fault. You need to query

the cell unavailability duration from

relevant parameters to judge whether

there is any equipment fault.

RL

establishment

failure of the

IUB interface RL

reconfiguration

failure of the IUB

interface

RL addition

failure of the IUB

interface

List the number of

RL establishment

failures of the IUB

interface, RL

establishment

failure rate of the

Iub interface, and

main failure

causes.

Others RL establishment failure caused by

abnormal factors. We need to make an



Observation

Point Condition

Possible

Cause Analysis Idea

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

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.

Configuration

not supported

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

is reestablished next time, this case may

occur. This case also happens to SE

V800 mobile phone. Or when some UEs

implement VP and high-speed (greater

than or equal to 64K) PS service, failure

may also due to unsupported capability.

Physical

channel

failure

This generally occurs when FACH

migrates to DCH and establishes RB.

The downlink physical layer of a terminal

is not synchronized, which leads to RB

establishment failure. This is mainly

caused by poor coverage.

Cell update

The Cell Update flow occurs during RB

establishment. This nested flow leads to

RB establishment failure.

RB

establishment

failure

RB

reconfiguration

failure

RB deletion

failure

RB establishment

failure generally

corresponds to

poor air interface

coverage or a

mobile phone

compatibility

problem.

Illegal

configuration

UE considers parameter configuration

illegal. Network and terminals have an

inconsistent understanding of parameter

processing. If RB establishment failure



Observation

Point Condition

Possible

Cause Analysis Idea

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

resides in a GSM network and does not

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.

No response

from UE

Generally poor coverage makes UE

unable to receive any RB command. In

Hong Kong, the balance mechanism of

IUB once made signaling established on

one E1, but service was established on

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

distribution of

uplink/downlink

service

Uplink/downlink

RB bearer

distribution of BE

service

Observe whether

the number of

various types of

RB service bearer

and the

proportion are

abnormal. If there

is any

abnormality, an

early warning

needs to be given

PS has a large amount of 128k, 144k,

and 384k RB bearer. This will consume a

large number of resources and there is

poor coverage. We need to verify

whether RB bearer is consistent with

actual demands with first-line personnel.

Observe whether the RB distribution of

BE service is rational. According to the

distribution, DCCC strategy and related

system parameters can be adjusted.



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 10 the task window of the Nastar is embedded with the special

topic analysis of call completion rate——RRC 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 11 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 12 Distribution of RRC setup scenario

Figure 13 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 13, 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 14 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 14 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:

1) Consolidate signaling flow and deepen an understanding of each UTRAN PI.

Performance analysis has a more definite object in view.

2) Basic special topic analysis enables us to make a preliminary analysis of network

performance and locate simple problem causes.

3) 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 Department—RAN 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

WCDMA Network Performance Analysis Guide

Documents

Transcript of WCDMA Network Performance Analysis Guide