G KPI Monitoring and Improvement Guide 20081230 a 1.0

GSM KPI Monitoring and Improvement Guide INTERNAL

2011-3-24 Huawei Confidential of 50

Product Name Confidentiality Level

GSM RNP INTERNAL

Product Version Total 50 Pages

1.0

GSM KPI Monitoring and Improvement Guide

(For Internal Use Only)

Prepared by: Xu Kaiping, Guo Hao Date 2008-12-25

Reviewed by: GSM Technical Support

Center Date 2008-12-26

Approved by: Date

Huawei Technologies Co., Ltd.

All rights reserved



Revision Record

Date Revision

Version

Change Description Reviewer Author

2008-12-30 1.0 First Version. Tao Maodi Xu Kaiping, Guo

Hao



Contents

1 Overview ......................................................................................................................................... 8

2 KPI Monitoring and Optimization ............................................................................................ 9

2.1 Recommended KPIs for Monitoring ................................................................................................................ 9

2.2 Measurements Correlating with KPI .............................................................................................................. 12

2.2.1 Measurements Related to TCH Drop Rate ............................................................................................ 12

2.2.2 Measurements Related to Handover Success Rate ................................................................................ 13

2.2.3 Measurements Related to Congestion ................................................................................................... 14

2.2.4 Measurements Related to TBF Call Drop Rate ..................................................................................... 15

3 Evaluation Standard of KPI Monitoring ................................................................................ 16

3.1 KPI Monitoring Standards.............................................................................................................................. 16

3.1.1 KPIs Specified in the Contract .............................................................................................................. 16

3.1.2 Default Bottom Line in the Guide ......................................................................................................... 16

3.2 Default KPI Bottom Line ............................................................................................................................... 16

3.2.1 KPI Bottom-Line Concept .................................................................................................................... 16

3.2.2 Correlation of Bottom Line ................................................................................................................... 17

3.2.3 Default KPI Red Line ........................................................................................................................... 17

3.2.4 Suggested KPI Selection for Field Monitoring ..................................................................................... 19

3.3 Requirements for KPI Monitoring Data ......................................................................................................... 20

3.3.1 Credibility of KPI Monitoring Data ...................................................................................................... 20

3.3.2 Suggested Collection Period of KPI ..................................................................................................... 20

4 Strategy of KPI Monitoring and Optimization ..................................................................... 22

4.1 Methods for KPI Monitoring and Optimization ............................................................................................. 22

4.2 Monitoring and Optimization of Network-Level KPI .................................................................................... 23

4.3 Monitoring and Optimization of Cluster-level KPI ........................................................................................ 24

4.4 Selection of TopN Bad Cells .......................................................................................................................... 24

5 Analysis on KPI Monitoring and Optimization ................................................................... 26

5.1 Analysis on the Availability of the CS Domain .............................................................................................. 26

5.2 Analysis on the Resources Utilization in the CS Domain .............................................................................. 27

5.2.1 SDCCH Congestion Rate ...................................................................................................................... 27

5.2.2 TCH Congestion Rate ........................................................................................................................... 28

5.3 Analysis on the Call Drop Rate in the CS Domain......................................................................................... 29



5.4 Analysis on the Handover Success Rate ......................................................................................................... 29

5.5 Analysis on the Accessibility of the CS Domain ............................................................................................ 30

5.6 Analysis on the Paging Success Rate in the CS Domain ................................................................................ 30

5.7 Analysis on the Accessibility of the PS Domain ............................................................................................ 31

5.7.1 TBF Congestion Rate ............................................................................................................................ 31

5.7.2 PDCH Allocation Success Rate ............................................................................................................ 31

5.7.3 TBF Establishment Success Rate .......................................................................................................... 31

5.8 Analysis on the TBF Drop Rate in the PS Domain ........................................................................................ 32

5.9 Analysis on the TBF Retransmission Rate in the PS Domain ........................................................................ 32

6 Implementation of KPI Monitoring on NASTAR ................................................................ 33

6.1 Daily/Weekly/Monthly Report of NASTAR GSM ......................................................................................... 33

6.2 Network Monitoring Report (CS Services) .................................................................................................... 37

6.3 PCU Monitoring Report ................................................................................................................................. 41

6.4 Exporting and Analysis of the Bad Cells ........................................................................................................ 44

6.5 Comprehensive Analysis on the GSM Network Expansion ........................................................................... 46

7 Summary ....................................................................................................................................... 50



Figures

Figure 4-1 Process of KPI monitoring and optimization ..................................................................................... 23

Figure 6-1 Daily report menus ............................................................................................................................ 34

Figure 6-2 Setting of daily report ........................................................................................................................ 35

Figure 6-3 Advanced setting of the daily report exporting .................................................................................. 36

Figure 6-4 Format of the output daily report ....................................................................................................... 37

Figure 6-5 Network monitoring report menus ..................................................................................................... 38

Figure 6-6 Basic setting of network monitoring report ....................................................................................... 39

Figure 6-7 Advanced setting of the network monitoring report .......................................................................... 40

Figure 6-8 Monitoring report output ................................................................................................................... 41

Figure 6-9 PCU monitoring report menu ............................................................................................................ 42

Figure 6-10 Setting of the PCU monitoring report .............................................................................................. 43

Figure 6-11 PCU monitoring report .................................................................................................................... 44

Figure 6-12 Setting of enhanced traffic statistics ................................................................................................ 45

Figure 6-13 Traffic statistics report output .......................................................................................................... 46

Figure 6-14 Setting of the network expansion report .......................................................................................... 47

Figure 6-15 Setting of the query object ............................................................................................................... 48

Figure 6-16 Wireless Resource Optimization Report .......................................................................................... 49



Tables

Table 2-1 Recommended KPIs for monitoring in the CS domain ......................................................................... 9

Table 2-2 Recommended KPIs for monitoring in the PS domain ........................................................................ 10

Table 2-3 Measurements related to the TCH call drop rate ................................................................................. 13

Table 2-4 Measurements related to handover success rate .................................................................................. 13

Table 2-5 Measurements related to the TCH congestion rate .............................................................................. 14

Table 2-6 Measurements related to the TBF drop rate ......................................................................................... 15

Table 3-1 Baseline values of network-level KPIs for monitoring and optimization-CS service ......................... 17

Table 3-2 Baseline values of network-level KPIs for monitoring and optimization-PS service .......................... 18

Table 3-3 KPIs that should be monitored ............................................................................................................ 19

Table 3-4 Suggested data collection period of different KPIs ............................................................................. 20

Table 4-1 KPI parameters for selecting TopN cells ............................................................................................. 25

Table 5-1 Causes of low availability and optimization actions ............................................................................ 26



GSM KPI Monitoring and Improvement Guide

Keywords: GSM KPI, TopN cell

Abstract: The GSM KPI monitoring and optimization guide is intended to guide the field engineers and

cooperation engineers through KPI monitoring, judgment, and problem sorting. For further analysis,

this document also provides the optimization manual name for reference based on the problem type.



1 Overview

With the expansion of the GSM network, the focus of routine maintenance is changing. It

becomes increasingly difficult to identify problems through drive tests (DTs), call quality tests

(CQTs), and user complaints. How to monitor the running of a network, evaluate the quality

of the network, and handle the problems on the network?

This guide describes the objectives of key performance indicators (KPIs), the method for

determining whether the quality of a network should be improved according to the KPIs, and

the method for locating a fault when a KPI is abnormal. This document also guides the

readers to determine the basic conditions and choose the required KPI Optimization Manual

according to the actual problems.

To ensure that the monitoring can be implemented properly, this document focuses on the

analysis of the monitoring and optimization of the exported KPIs. The KPIs in the DT and

CQT are not included.

Chapter 1 describes the purpose and content of the document. Chapter 2 describes the KPIs

for monitoring the network performance and the definitions. Chapter 3 describes the strategy

for monitoring and optimizing KPIs. Chapter 4 describes the KPI monitoring and

optimization flow. Chapter 5 describes the classification of KPIs for optimization and the

relevant guides. Chapter 6 describes the implementation of the KPI monitoring strategy

through the NASTAR. Chapter 7 provides the summary.



2 KPI Monitoring and Improvement

A KPI indicates the performance of the network or network element (NE) from a specific

aspect. Based on the actual value and evaluation method, you can determine whether the

performance is good and whether the performance should be optimized

2.1 Recommended KPIs for Monitoring

Which KPIs should be monitored? The definitions of KPIs for evaluating the network quality

vary with carriers. This document provides the KPIs that are commonly used by most carriers

and that can effectively indicate the network quality. To facilitate KPI evaluation at the site,

the selected KPIs should be recapitulating and typical.

Table 2-1 Recommended KPIs for monitoring in the CS domain

KPI

BSC Level/Cell Level

KPI Formula

SDCCH

Availability

ZTR105A/RR300

SDCCH Availability = (Mean Number of Available Channels

(SDCCH) × 100%)/Mean Number of Dynamically Configured

Channels (SDCCH)

TCH Availability

ZTR109A/RR307

TCH Availability = (Mean Number of Available Channels (TCH) ×

100%)/Mean Number of Dynamically Configured Channels (TCH)

SDCCH

Congestion Rate

ZTR103A/RR370

Failed SDCCH Seizures due to Busy SDCCH = (Failed SDCCH

Seizures due to Busy SDCCH × 100%)/SDCCH Seizure Requests

TCH Congestion

Rate(Overflow)

ZTR106A/K3045

TCH Congestion Rate(Overflow) = ((Failed TCH Seizures due to Busy

TCH (Signaling Channel) + Failed TCH Seizures due to Busy TCH

(Traffic Channel) + Failed TCH Seizures in TCH Handovers due to

Busy TCH (Traffic Channel)) × 100%)/(TCH Seizure Requests

(Signaling Channel)+TCH Seizure Requests (Traffic Channel)+TCH

Seizure Requests in TCH Handovers (Traffic Channel))



KPI

BSC Level/Cell Level

KPI Formula

Immediate

Assignment

Success Rate

(CS)

ZTR110A/RA303

G

Success Rate of Call Setup (Immediate Assignment) = (Call Setup

Indications (CS Service) × 100%)/Immediate Assignment Requests

Success Rate of

TCH Assignment

ZTR102A/RCA3

13

Success Rate of TCH Assignment = (Successful Assignments ×

100%)/Assignment Requests

Call Drop Rate on

SDCCH

ZTR104A/ZTR10

4C

Call Drop Rate on SDCCH = (Call Drops on SDCCH ×

100%)/Successful SDCCH Seizures

TCH Call Drop

Rate(including

Handovers)

ZTR107A/ZTR30

4

TCH Call Drop Rate(including Handovers) = (Traffic Channel per BSC

× 100%)/(Successful TCH Seizures (Signaling Channel) + Successful

TCH Seizures (Traffic Channel) + Successful TCH Seizures in TCH

handovers (Traffic Channel))

Handover

Success Ratio per

BSC

ZK3180/RH303

Handover Success Ratio per BSC = (Successful Incoming Internal

Inter-Cell Handovers + Successful Outgoing External Inter-Cell

Handovers)/(Incoming Internal Inter-Cell Handover Requests +

Outgoing External Inter-Cell Handover Requests)

Traffic

Volume(ERL)

ZK3014/K3014

None

Paging Success

Rate

Paging Success Rate = ((Number of Responses Upon First Paging +

Number of Responses Upon Second Paging) × 100%)/Number of First

Pagings. The statistics of this measurement are collected on the MSC.

TCH Call Drop Rate (including Handovers) helps analyze the NEs of each level (BSC

and cell). Hence, it is recommended in this guide. If the standard is different from the

field standard, the field KPI definition needs to be observed.

The paging success rate is a concerned item. Monitor this item if it can be retrieved.

Table 2-2 Recommended KPIs for monitoring in the PS domain

KPI KPI Formula

TBF Drop Rate

TBF Drop Rate = Number of TBF Drops (uplink and downlink

GPRS/EGPRS)/Number of Successful TBF Establishments

(uplink and downlink GPRS/EGPRS)



KPI KPI Formula

Uplink TBF Setup

Success Rate

Uplink TBF Setup Success Rate = Number of Successful Uplink

TBF Establishments/Number of Uplink TBF Establishment

Attempts

Downlink TBF Setup

Success Rate

Downlink TBF Setup Success Rate = Number of Successful

Downlink TBF Establishments/Number of Downlink TBF

Establishment Attempts

PDCH Allocation

Success Rate

PDCH Allocation Success Rate = 1 – (Number of Failed Uplink

TBF Establishments due to MS No Response + Number of Failed

Downlink TBF Establishments due to MS No Response)/(Number

of Uplink TBF Establishment Attempts + Number of Downlink

TBF Establishment Attempts)

Uplink TBF

Congestion Rate

Uplink TBF Congestion Rate = Number of Failed Uplink TBF

Establishments due to No Channel/Number of Uplink TBF

Establishment Attempts

Downlink TBF

Congestion Rate

Downlink TBF Congestion Rate = Number of Failed Downlink

TBF Establishments due to No Channel/Number of Downlink

TBF Establishment Attempts

Uplink EGPRS TBF

Congestion Rate

Uplink EGPRS TBF Congestion Rate = Number of Failed Uplink

EGPRS TBF Establishments due to No Channel/Number of

Uplink EGPRS TBF Establishment Attempts

Downlink EGPRS

TBF Congestion Rate

Downlink EGPRS TBF Congestion Rate = Number of Failed

Downlink EGPRS TBF Establishments due to No

Channel/Number of Downlink EGPRS TBF Establishment

Attempts

Retransmission Rate

of RLC Uplink Data

Block

Retransmission Rate of RLC Uplink Data Block = (Total Number

of Uplink RLC Data Blocks Using CS1 through CS4 - Total

Number of Valid Uplink RLC Data Blocks Using CS1 through

CS4)/Total Number of Uplink RLC Data Blocks Using CS1

through CS4

Retransmission Rate

of RLC Downlink

Data Block

Retransmission Rate of RLC Downlink Data Block = (Total

Number of Downlink RLC Data Blocks Using CS1 through CS4 -

Total Number of Valid Downlink RLC Data Blocks Using CS1

through CS4)/Total Number of Downlink RLC Data Blocks

Using CS1 through CS4

Retransmission

EGPRS Rate of RLC

Uplink Data Block

Retransmission EGPRS Rate of RLC Uplink Data Block = (Total

Number of Uplink EGPRS MCS1 through MCS9 RLC Data

Blocks - Total Number of Valid Uplink EGPRS MCS1 through

MCS9 RLC Data Blocks)/Total Number of Uplink EGPRS MCS1

through MCS9 RLC Data Blocks

Retransmission

EGPRS Rate of RLC

Downlink Data Block

Retransmission EGPRS Rate of RLC Downlink Data Block =

(Total Number of Downlink EGPRS MCS1 through MCS9 RLC

Data Blocks - Total Number of Valid Downlink EGPRS MCS1

through MCS9 RLC Data Blocks)/Total Number of Downlink

EGPRS MCS1 through MCS9 RLC Data Blocks



The monitoring of the GPRS\EGPRS services is subject to the actual condition, that is,

whether certain services are activated.

The required KPIs must be monitored regardless of whether they are mentioned in the preceding

table or not.

If a KPI is defined in the field, use the field KPI formula. If no KPI is defined or put forward for

evaluation in the field, use the default definition of Huawei equipment. If no default definition is

available, see the suggested formula.

If the KPIs listed in the contract contain the suggested KPIs, or the performance indexes are the

same, use the KPIs listed in the contract.

2.2 Measurements Correlating with KPI

The parameters used to evaluate a measurement vary with stages. Monitoring the entire

network and different NEs involves different measurement statistical items. The selected KPIs

in the monitoring are recapitulative and comprehensive. During analysis, the measurement

statistical items related to the monitored KPI must be taken into account. When you obtain the

values of a KPI, you must concern the related sub-performance.

The sub-performance is used to assist analysis after you find abnormal KPIs. It does not

serve as the standard for evaluation or monitoring.

2.2.1 Measurements Related to TCH Drop Rate

The TCH call drop involves the following counters:

Call Drops on Radio Interface in Stable State (Traffic Channel)

Call Drops on Radio Interface in Handover State (Traffic Channel)

Call Drops due to No MRs from MS for a Long Time (Traffic Channel)

Call Drops due to Abis Terrestrial Link Failure (Traffic Channel)

Call Drops due to Equipment Failure (Traffic Channel)

Call Drops due to Forced Handover (Traffic Channel)

Call Drops Due to Loopback Start Failure

Call Drops Due to Handover Failure During the Loopback

Call Drops Due to Failures to Return to Normal Call from Loopback

The common call drops are classified into call drops on the radio interface in stable state and

call drops on the radio interface in handover state. During analysis, more detailed call drop

types are available, for example, error indication of call drops on the radio interface in stable

state, connection failure, and release indication. During analysis of a specific problem,

determine the call drop classification first, and then query the optimization guide to quickly

locate the problem.

Learning the general reasons of call drops before analyzing the TCH drop rate helps quickly

locate a problem.



Table 2-3 Measurements related to the TCH call drop rate

KPI KPI Formula

Radio Drop Rate of

TCH

Radio Drop Rate of TCH = (Call Drops on Radio Interface in

Stable State (Traffic Channel) + Call Drops on Radio Interface in

Stable State (Signaling Channel))/(Successful TCH Seizures

(Signaling Channel) + Successful TCH Seizures (Traffic Channel)

+ Successful TCH Seizures in TCH handovers (Traffic Channel))

Handover Drop Rate

of TCH

Handover Drop Rate of TCH = Call Drops due to Handover

Failure/(Successful TCH Seizures (Signaling Channel) +

Successful TCH Seizures (Traffic Channel) + Successful TCH

Seizures in TCH handovers (Traffic Channel))

Traffic Call Drop

Ratio

Traffic Call Drop Ratio = Traffic Volume of TCHs × 60/Call

Drops on Traffic Channel

2.2.2 Measurements Related to Handover Success Rate

The handover is classified into many types according to the following two statistical

objectives: handover reasons and handover directions. The handover is classified into the

following types according to the handover direction: Incoming inter-cell handover and

outgoing inter-cell handover. The handover is classified into the following types according to

the homing of the source cell and the target cell: intra-cell handover, intra-BSC inter-cell

handover, and inter-BSC inter-cell handover. The handover can also be classified according to

the cell frequency band and the function of the concentric cells. The rate of successful radio

handover excludes the handover failure due to the restriction of radio resources and link

losses, and it takes the Handover Command message as the start point. The success rate is for

quickly locating whether the handover failure is generated on the air interface, that is, Um

interface.

Table 2-4 Measurements related to handover success rate

KPI KPI Formula

Success Rate of

Incoming Inter-Cell

Handover

Success Rate of Incoming Inter-Cell Handover = Successful

Incoming Inter-Cell Handovers/Incoming Inter-Cell Handover

Requests

Success Rate of

Outgoing Inter-Cell

Handover

Success Rate of Outgoing Inter-Cell Handover = Successful

Outgoing Inter-Cell Handovers/Outgoing Inter-Cell Handover

Requests

Internal Handover

Success Ratio Internal Handover Success Ratio = Successful Internal Handovers

(all)/Internal Handover Requests (all)

Intra-BSC Radio

Handover Success

Rate

Intra-BSC Radio Handover Success Rate = Successful Internal

Handovers (all)/Internal Handover Commands (all)

External Outgoing

Radio Handover

Success Ratio

External Outgoing Radio Handover Success Ratio = Successful

Outgoing External Inter-Cell Handovers/Outgoing External

Inter-Cell Handover Requests



KPI KPI Formula

External Outgoing

Radio Handover

Success Ratio

Success Rate of Outgoing Radio Handover = Successful Outgoing

External Inter-Cell Handovers/Outgoing External Inter-Cell

Handover Commands

Success Rate of

Incoming BSC

Handover

Success Rate of Incoming External Inter-Cell Handover =

Successful Incoming External Inter-Cell Handovers/Incoming

External Inter-Cell Handover Requests

External Incoming

Radio Handover

Success Ratio

External Incoming Radio Handover Success Ratio = Successful

Incoming External Inter-Cell Handovers/Incoming External

Inter-Cell Handover Commands

Dual-Band Handover

Success Ratio per

cell(900/850-1800/19

00)

Dual-Band Handover Success Ratio per cell(900/850-1800/1900)

= Successful Handovers (900->1800) /Handover

Requests(900->1800)

Dual-Band Handover

Success Ratio per

cell(1800/1900-900/8

50)

(1800->900)

Dual-Band Handover Success Ratio per cell(1800/1900-900/850)

= Successful Handovers (1800->900) /Handover

Requests(1800->900)

Success Rate of

Internal Intra-Cell

Handover (Overlay to

Underlay)

Success Rate of Internal Intra-Cell Handover (Overlay to

Underlay) = Successful Internal Intra-Cell Handovers (Overlay to

Underlay)/Internal Intra-Cell Handover Requests (Overlay to

Underlay

Success Rate of

Internal Intra-Cell

Handover (Underlay

to Overlay)

Success Rate of Internal Intra-Cell Handover (Underlay to

Overlay) = Successful Internal Intra-Cell Handovers (Underlay to

Overlay)/Internal Intra-Cell Handover Requests (Underlay to

Overlay)

2.2.3 Measurements Related to Congestion

The channel congestion is caused by traffic burst in some cases. But the performance analysis

and the capacity expansion suggestion are intended to take the carried traffic as the base. The

following measurement items should be calculated in the congestion analysis.

Table 2-5 Measurements related to the TCH congestion rate

KPI KPI Formula

Traffic Volume per

TCH(ERL)

Traffic Volume per TCH(ERL) = TCH Traffic

Volume(ERL)/Mean Number of Available Channels(TCH)

TCH Traffic

Volume(ERL)

Null

Mean Number of

Available

Channels(TCH)

Null



2.2.4 Measurements Related to TBF Call Drop Rate

The PS services in the uplink and the downlink are asymmetric. In addition, the GPRS and

EGPRS services are distributed on different channels and carrier frequencies. Hence, statistics

of TBF drop rate of different service types help quickly locate the problem.

Table 2-6 Measurements related to the TBF drop rate

KPI KPI Formula

Uplink TBF Drop

Rate

Uplink TBF Drop Rate = (Number of Uplink TBF Drops ×

100%)/Number of Successful Uplink TBF Establishments

Downlink TBF Drop

Rate

Downlink TBF Drop Rate = (Number of Downlink TBF Drops ×

100%)/Number of Successful Downlink TBF Establishments

Uplink GPRS TBF

Drop Rate

Uplink GPRS TBF Drop Rate = (Number of Uplink GPRS TBF

Drops × 100%)/Number of Successful Uplink GPRS TBF

Establishments

Downlink GPRS TBF

Drop Rate

Downlink GPRS TBF Drop Rate = (Number of Downlink GPRS

TBF Drops × 100%)/Number of Successful Downlink GPRS TBF

Establishments

Uplink EGPRS TBF

Drop Rate

Uplink EGPRS TBF Drop Rate = (Number of Uplink EGPRS

TBF Drops × 100%)/Number of Successful Uplink EGPRS TBF

Establishments

Downlink EGPRS

TBF Drop Rate

Downlink EGPRS TBF Drop Rate = (Number of Downlink

EGPRS TBF Drops × 100%)/Number of Successful Downlink

EGPRS TBF Establishments



3 Evaluation Standard of KPI Monitoring

3.1 KPI Monitoring Standards

3.1.1 KPIs Specified in the Contract

The KPIs in the contract are the bottom-line that should be achieved before delivery. Hence,

the KPIs in the contract are the objectives of the network optimization. The requirements in

the contract are the objective of the KPI improvement. Monitoring tasks is intended for

monitoring of the KPIs that do not meet the standard requirement. More attention should be

paid to these KPIs. In a maintenance project, KPI monitoring helps detect the network

degradation in certain KPIs. As a result, the performance optimization can be started quickly.

3.1.2 Default Bottom Line in the Guide

The evaluation standards of important KPIs are not provided by certain carriers or in certain

projects. To facilitate field implementation and to generally control the network KPI, the

Radio Network Planning Department makes the bottom line for use in case no evaluation

standard is available.

The default bottom line of the KPI does not classify the network types. As the reference

standard, it is not mandatory. If the KPI is defined on site or the onsite KPI is better or worse

than the default bottom line, the onsite RNP team should make the evaluation standard

according to the actual network conditions.

3.2 Default KPI Bottom Line

When the KPI for monitoring is determined, you should have a standard to evaluate the KPI.

Different networks may have different good standards. But many bad KPIs may impact the

network significantly. The two bottom lines including the yellow line (pre-warning) and the

red line (optimization is required) are defined on both the network-wide level and the cell

level.

3.2.1 KPI Bottom-Line Concept

Red line: The minimum requirement for delivery specified in the contract. The value may

cause accidents or intolerable network quality.



Yellow line: Close to the evaluation standard, but it is not sure whether the performance will

be degraded to the pre-warning value.

When the KPI is degraded to the yellow line, the monitor engineer starts to shorten the

monitoring period of the KPI. At the same time, the engineer reports the performance

pre-warning to the RNP team. Check the performances that affect the KPI. If the degradation

is caused by a cause or certain cells, handle the cells or the cause. If the value is close to the

red line, handle the problem in advance. Otherwise, keep the pre-warning according to the

network conditions.

When the cell KPI is degraded to the yellow line, put the cell into the options of TopN cells.

For details, see section 4.4 "Selection of TopN Bad Cells".

If the value is close to the red line, or the number of yellow-line cells is small, refer to the

method for handling the red line. If the cell is a VIP cell or is in the TopN cells of the KPI,

you should also handle the cell as a red-line cell, that is, to optimize the performance in time.

If a KPI is better than the yellow-line value in the entire network, you need to handle

only the TopN cells in red line.

3.2.2 Correlation of Bottom Line

Definition of 0.8X, X, 1.5X, and 2X: In the evaluation of KPI, the red-line value of the entire

network is set to X.0.8X is to identify the failure which is 80% of the red line. In the case of

the failure KPI, if the red line value of the drop rate is 1%, 0.8X indicates 0.8%. In the case of

success rate, if the red line value of the handover success rate is 90%, 0.8X indicates that the

failure rate is 0.8 times of the original value, that is, the handover failure rate is 0.8 × (1-90%),

which means that the required handover success rate is 92%.

Network-wide red line: The red line value (X) of the network-wide KPI is the default value

defined in the contract, performance event, and the guide.

Network-wide yellow line: The KPI fluctuates, and the value of the yellow line is set to 80%

of the red-line degradation value (0.8X).

Cell red line: The value of the cell red line is set to 2X. When the network-wide KPI is

degraded to the red-line value, and the number of red-line cells exceeds 5% of the

network-wide value, it is hard to solve the problem through the TopN cells because the

problem is general in the entire network. If the red-line cells are less than 5% (or less), the

problem is generated by certain cells. When the network-wide performance is better than the

yellow line, the rate of the red-line cells is less than 1%. Analyze and handle the red-line cell

one by one.

Cell yellow line: It is a standard for selecting the TopN cells. The value is set to 1.5X. When

the network-wide performance is better than the yellow line, you do not need to handle the

yellow-line cells.

3.2.3 Default KPI Red Line

The baseline values of the network-level KPIs are as follows:

Table 3-1 Baseline values of network-level KPIs for monitoring and optimization-CS service

Type KPI Red Line

Availability SDCCH Availability 90%

TCH Availability 90%



Type KPI Red Line

Utilization SDCCH Congestion Rate(Overflow) 5%

TCH Congestion Rate(Overflow) 5%

Traffic Volume (ERL) Increase of decrease by

more than 20%

Accessibility Immediate Assignment Success Rate(CS) 96%

TCH Assignment Success Rate 96%

SDCCH Drop Rate 1%

Retainability TCH Call Drop Rate (including

Handovers)

1%

Mobility Handover Success Ratio 93%

Paging

Performance

Paging Success Rate 85%

Table 3-2 Baseline values of network-level KPIs for monitoring and optimization-PS service

Type KPI Red Line

Retainability TBF Drop Rate 8%

Accessibility Uplink TBF Setup Success Rate 90%

Downlink TBF Setup Success Rate 85%

PDCH Allocation Success Rate 92%

Uplink TBF Congestion Rate 5%

Downlink TBF Congestion Rate 5%

Uplink EGPRS TBF Congestion Rate 5%

Downlink EGPRS TBF Congestion Rate 5%

Um Interface

Transmission

Retransmission GPRS Rate of RLC Uplink Data

Block

10%

Retransmission GPRS Rate of RLC Downlink Data

Block

10%

Retransmission EGPRS Rate of RLC Uplink Data

Block

20%

Retransmission EGPRS Rate of RLC Downlink Data

Block

20%



The retransmission rate of GPRS/EDGE data block is heavily affected by the radio

environment and the transmission quality, the KPI for retransmission rate is fluctuating

and the evaluation requirement varies. The monitoring engineer should adjust the

standard of the red line according to the radio environment of the country. If the radio

environment and the transmission environment are good, refer to the ordinary network

standard of China: The retransmission rate of GPRS/EDGE RLC uplink data block < 5%

and the retransmission rate of RLC GPRS/EDGE downlink data block < 8%.

3.2.4 Suggested KPI Selection for Field Monitoring

The KPI monitoring should consider the requirements of the contract. After determining the

KPI monitoring task, you should make the content of the monitoring KPI and the monitoring

standard according to the KPI suggested in the guide and the requirement of the contract.

The monitoring standard should contain the name of the KPI to be monitored and the set red

line (required value in the contract or the default value).

Optional items: KPI formula, KPI yellow line, KPI red line, and whether the value reaches the

standard. The following table is a sample.

Table 3-3 KPIs that should be monitored

Name of KPI Bad Baseline

Normal Baseline

Definition of KPI

RATE_TCH_CALL_

DROP_INCLUDE_H

O

1% 0.8% TCH Call Drop Rate(including

Handovers) = (Call Drops on TCH /

(Successful TCH Seizures (Signaling

Channel) + Successful TCH Seizures

(Traffic Channel) + Successful TCH

Seizures in TCH handovers (Traffic

Channel)) × 100%

other contracted KPIs xx xx

RATE_SDCCH_Con

gestion

5% 4%

RATE_TCH_Congest

ion

5% 4%

RATE_immediately_

Assignment_Success(

CS)

96% 96.8%

RATE_Assignment_S

uccess

96% 96.8%

HO_SUCC_RATE 98% 98.4%



3.3 Requirements for KPI Monitoring Data

3.3.1 Credibility of KPI Monitoring Data

The NE disruption or hardware fault may cause sudden KPI changes. Hence, the statistics of

KPI in this case are incredible. When the availability KPI (TCH availability, SDCCH

availability, the same hereinafter) is not normal, you must adopt proper measures to obtain

credible KPI data (except for the case that the low availability is caused by the redundant BSC

data, which does not affect the network KPI).

When the availability KPI exceeds the yellow line, you should extract the KPI of the recent

period for reference.

If the availability KPI is worse than the red line or is worse than the yellow line for

consecutive days, report to the maintenance personnel for examination, and stop NE

optimization. In the network-wide KPI, eliminate the NE and the impact of the NE.

If the network-wide availability KPI is low, and the problem is not caused by a single NE or

redundant data, you should check whether the performance data is complete, or whether any

OMC software fault occurs in the network. If any problem is detected, start monitoring KPIs

after the problem is solved.

3.3.2 Suggested Collection Period of KPI

The number of samples determines the accuracy of the data, that is, more data, more accurate.

But a great amount of data is hard to process, and thus the operability is decreased. A balance

point must be chosen between the accuracy and the operability.

Due to the features of system export performance, the statistical periods are: busy hours, busy

hours of seven days, 24 hours, 24 hours of seven days.

Busy hours: The hours defined by the carrier (for example, 9:00-10:00 or 17:00-18:00), or the

real busy hours of the network-wide traffic. In this case, the KPI statistics of one record of one

hour in the specific period are collected. If two busy hours or records are defined in one day,

each record should be collected in separate hours.

24 hours: Summarize the records of 24 hours into one record. This is suitable for the statistics

of individuals with light traffic. The 24-hour statistics can prevent the impact of burst

problems in a period. This is suitable for the analysis of long-term problems, such as

congestion analysis.

Busy hours of seven days: Summarize the records of busy hours in seven days into a record.

This is suitable for the analysis of radio resources utilization. For example, analyze the

capacity expansion according to the performance summary of the busy hours in a week, or

analyze the network capacity adjustment according to the performance in the busiest hours of

a week.

24 hours of seven days: This is the statistical period for the object with light traffic and the

KPI and object without restrict processing period. For example, the PS service performance

statistics of the single cells in the remote rural areas.

Table 3-4 Suggested data collection period of different KPIs

Objective Heavy Traffic Normal Traffic Light Traffic

Network-wid

e level Busy hours Busy hours 24 hours



Objective Heavy Traffic Normal Traffic Light Traffic

Cluster-level

(beyond

BSC)

Busy hours Busy hours 24 hours

Cluster-level

(less than 10

BSCs)

Busy hours 24 hours 24 hours

Cell level Busy hours 24 hours 24 hours of 7 days

Analysis and

statistics of

radio

resources

Busy hours of 7 days

To ensure the accuracy of KPI, 24-hour statistics are recommended in all cases. Comparison

of the seven records of the statistical data of seven days improves the accuracy of the KPI

analysis.

When you export the performance data by using the M2000, you can choose to export the

records with the granularity of an hour (24 hours of seven days) by cells. You can calculate

the performance of the entire network or any period (greater than an hour) by using the

EXCEL.



4 Strategy of KPI Monitoring and Improvement

4.1 Methods for KPI Monitoring and Improvement

The task of the network monitoring is to find the problem, locate the problem, and report and

solve the problem. According to different KPIs and scopes in which problems arise, two

methods are provided:

For the cluster-level: Whether any problem exists in the network Which NE is faulty on the

network What is the problem?

For the monitoring of each KPI: Whether the KPI is faulty What is the impact of the

relevant KPI? How to solve the problem?

The integration of the two methods generates many combinations. According to the traditional

methods of performance monitoring, the common method is recommended: From the level of

the network topology, monitor the entire KPI and then the cell KPI; in the same NE, monitor

the KPI to the relevant KPI. The process of KPI monitoring is as follows:



Figure 4-1 Process of KPI monitoring and optimization

Network-levelKPI should be

optimized

Export and analyze

KPI data

The cluster-levelKPI should be

optimized

Yes

Yes

YesThe KPI of TopNcells should be

optimized

Optimize the KPI

Optimize the KPI

of the entire

network

Optimize the

cluster-level KPI

Process the

TopN cells

The KPI problem is solved

No

Sta

rtnew

perio

dica

lKP

Im

onito

ring

No

No

Process of KPI Monitoring

and Optimization

Paging success rate

increased

Assignment success

rate increased

TCH drop rate

decreased

PS performance

improved

Congestion

problem solved

4.2 Monitoring and Improvement of Network-Level KPI

The task of the network monitoring is to determine whether the KPIs of the network reach the

standard, that is, check whether the KPI is worse than the red line or yellow line. The

monitoring of network-level KPI involves small number of specifications. Therefore, it is

good for locating the network-level problems and improving the judgment and response speed

to important problems.

If the KPI is worse than the red line, unless otherwise specified (problems in certain cells are

caused by known reasons, or the carrier specifies that the problem can be ignored, or the



problem cannot be processed because resources are limited), start the network-level KPI

optimization.

If the KPI is worse than the yellow line, you should determine whether the KPI is close to or

decreasing to the red line, whether the problem is caused by a type of problem or caused by

problems of certain NEs.

If the KPI is tending to the red line or it may be degraded, refer to the method of

processing the KPI worse than the baseline value.

If a certain problem affects the entire network, optimize KPIs that cause the problem.

If certain NEs are affected, analyze the distribution of the NEs, optimize the cluster-level

KPIs or the TopN cells.

If a special problem is detected, monitor only this KPI.

4.3 Monitoring and Improvement of Cluster-level KPI

The cluster-level problem can be defined by the network topology, for example, the base

stations in the BSC/BM or in a transmission ring encounter the same problem. You can also

define the cluster-level problem according to the distribution of cells, for example, the

problems occurred in cells of an express way or an administrative region.

When yellow line occurs in the network-level KPI, and the faulty NEs are distributed in a

specific region, monitor the network-level KPI as the cluster-level KPI.

When you process the TopN cells independently, if the cells are distributed in a specific

region, process them as regional problems.

When the cluster-level KPIs are faulty, choose the related NE KPIs of the region to

summarize, and then analyze and take this region as the entire network. You can also start the

optimization of the cluster-level KPIs directly.

When you monitor and optimize the cluster-level KPIs, for the determination baseline of the

KPIs, refer to the network-level baseline standard.

4.4 Selection of TopN Bad Cells

Selecting TopN cells is to sort by each KPI, and then take the worst N cells. How many cells

should be taken? Does the processing order agree with the sort order?

1. For the number of TopN cells, 5% of the entire network cells are recommended. The

value should not exceed 50, and no specific number is required. Do not take the cells

better than the yellow line as the TopN cells. If all cells in the network are better than the

yellow line, do not perform TopN cell handling for the KPI.

2. If the cell KPI is worse than the red line (2X), process the KPI using TopN bad cells. For

the cells reaching the red line frequently, more attention should be paid, and the cells

must be processed in time. If the number exceeds 5% or 50, process the KPI as

network-wide/cluster problems. If the number of red-line cells exceeds 5% and the

number is greater than 50, optimize the KPI as cluster/network-wide problems.

3. For the cells worse than the yellow line, determine the processing order according to the

weight item. Put 10 or less than 2% of the cells into the TopN bad cells. For the cells



ranking behind 20% of the weight items or ranking behind 50, if no resources are

available, do not process these cells.

In the process of cell analysis, if the number of yellow-line cells is less than 10, put

them into the TopN cells.

The processing method is as follows:

For example, when you select the TopN bad cells based on the TCH drop rate, determine

whether the bad cells should be processed with priority according to the ratio of call drops to

call drops on the entire network. If the rank by the call drop rate is in TopN, but the number of

call drops is one, do not process the cell.

Table 4-1 KPI parameters for selecting TopN cells

Type KPI Weight

Utilization TCH Congestion Rate(Overflow) TCH congestions

SDCCH Congestion

Rate(Overflow)

SDCCH congestions

Accessibility Immediate Assignment Success

Rate(CS)

Immediate assignment failures (CS

service)

TCH Assignment Success Rate TCH assignment successes

Mobility Handover Success Ratio Handover failures

Retainability TCH Drop Rate TCH drops

SDCCH Drop Rate SDCCH drops

PS Domain TBF Drop Rate TBF drops

TBF setup success rate TBF setup failures

PDCH Allocation Success Rate Times of TBF setup failures due to

no-response of MS

TBF Congestion Rate Times of TBF setup failures due to

lack of channel resources

Retransmission rate of TBF Number of RLC data blocks ×

Retransmission rate of TBF



5 Analysis on KPI Monitoring and Improvement

According to the principle of from the entire cell and major KPIs to the secondary KPIs, when

you perform the entire analysis of the KPIs, the analysis order of the CS domain based on the

impact of different KPI is as follows: availability, congestion rate (utilization), call drop rate

(retainability), handover success rate (mobility), and accessibility. As an independent item, the

paging success rate should be monitored independently or should not be monitored. The

analysis order of the PS domain is as follows: access performance, TBF drop rate,

retransmission rate of TBF.

For each analysis, the order is monitoring KPI first and the related KPI second. Finally,

correlate the analysis with the optimization operation guide.

5.1 Analysis on the Availability of the CS Domain

Before the KPI analysis, the most concerned factors are the integrity and credibility of the

data. In the case of the credibility, check whether any incredible KPI is generated by problems

such as equipment interruption in the entire network. When the availability (TCH availability,

SDCCH availability) is lower than the yellow line, determine whether the interrupted

equipment affects the network. Different actions should be taken according to different

reasons.

Table 5-1 Causes of low availability and optimization actions

Availability Problem

Cause Optimization Actions for Monitoring

Lower than

the yellow

line

The data is redundant

(*The cell data configured

for a test, but actually no equipment is running, the

equipment is faulty)

Continue analyzing the monitoring KPI.

Contact the equipment engineers to delete

the redundant data.



Availability Problem

Cause Optimization Actions for Monitoring

Certain sites are faulty. Ignore the sites and continue monitoring

the entire KPIs. List the faulty sites in the

TopN cells and then the equipment

maintenance personnel process the faulty

sites.

The fault prevails in most

sites (occasionally).

Skip the faulty period to continue the KPI

monitoring analysis.


sites (frequently).

Process the problems in time in the

equipment maintenance side. The KPI

monitoring analysis is meaningless and

can be stopped.

Lower than

the red line

The data is redundant Check the software problems in the

equipment side, and then retrieve the data

to analyze the KPI monitoring.

Certain sites are faulty. Process the problems in time. Analyze

only the irrelevant NE KPIs.


sites (occasionally).

After determining that no import problems

are encountered in the equipment side,

analyze the KPI monitoring and skip the

faulty period.


sites (frequently).

Determine the network problem from the

equipment side. The monitoring analysis is

not required.

5.2 Analysis on the Resources Utilization in the CS Domain

The performances of the network with heavy traffic are degraded. Therefore, analyze the

congestion rate KPI with priority. The related KPIs will be improved automatically after the

congestion is solved.

The resources utilization in the CS domain involves the SDCCH congestion rate and the TCH

congestion rate.

The congestion rate analysis in this section is performed after the availability problem is

excluded. The congestion rate exceeds the yellow line due to the availability problem. Hence,

process the equipment fault first.

5.2.1 SDCCH Congestion Rate

No big problems are caused by the number of SDCCHs after the network planning, and the

resource consumption of the SDCCH is not large. When the congestion occurs due to lack of

channel resources, the maintenance engineers increase the SDCCHs. As a result, it is rare that



the SDCCH congestion rate does not reach the standard in the entire network, and the

measurement will not be degraded to the yellow line.

When the SDCCH congestion rate is lower than the yellow line, determine whether the

problem is common or the problem is caused by certain cells.

When the problem is common, it is caused by the traffic burst. In certain cases, the problem is

caused by the network-wide interference, the fault beyond the BSC, or the software bug. If the

problem is caused by network-wide interference or fault beyond the BSC, many severe

problems may occur in the entire network. The symptoms are indicated before the periodical

KPI monitoring analysis (such as complaints and critical alarms). To determine whether the

traffic burst exists, you should generate the trend chart of the traffic volume. Use the trend

chart of 24 hours of 7 days and every hour of each day to find the period of traffic burst. Then

determine the cause of the traffic burst.

For the congestion caused by traffic burst, you can enable the "SDCCH dynamic allocation"

and "Immediate allocate to the TCH" functions in the BSS side. If the problem persists, the

carrier should balance the traffic burst. If the traffic burst cannot be removed, allocate the

service traffic to a long period. For example, to transmit all greeting short messages in a

certain region (such as a city) in five minutes, you can increase the transmission time to one

hour or longer. For the requirements of group-sending short messages in a province, the SMS

side cannot deliver the messages consecutively by the flag bit of the area code. For the

domestic numbers, sort them by the last 4 digits or 3 digits. Extend the service of each region

(LAC) to the entire period instead of a shorter period.

If the problem is caused by certain cells, make a comparison according to the cell-level KPI

bottom line to choose the TopN cells with high SDCCH congestion rate. In the case of the

number of the TopN cells, see section 4.4 "Selection of TopN Bad Cells." First, check whether

the cells with high SDCCH congestion rate are caused by the load. If the congestion is in a

short period, enable the SDCCH dynamic allocation function. If the congestion due to load

occurs in many periods in a day, increase the SDCCHs. Enabling the immediate assignment

TCH function can release the SDCCH congestion to some extent. But the enabling of the

function may cause the waste of channels, and the evaluation KPIs defined by carriers may be

affected. This function is not recommended unless required.

After you obtain the causes of the high SDCCH congestion rate, process the problem by

referring to the GSM BSS Network KPI (SDCCH Congestion Rate) Optimization Manual.

If the SDCCH congestion rate of the entire network reaches the standard, you can process

only the cells worse than the red line in the TopN cells.

5.2.2 TCH Congestion Rate

The analysis of the TCH congestion rate should first consider the KPI "TCH congestion rate

(including handover)". The guide determines the red line to evaluate the congestion of the

network. Considering the overflow of the network channel resources, the parameter "TCH

congestion rate (overflow)" should also be taken into consideration.

When the TCH congestion rate (including handover) does not reach the standard, and this

value is close (the difference is less than 1%) to the value of TCH congestion rate (overflow),

the TCH congestion is caused by the load of the network. After you find the problem of TCH

congestion rate (overflow), refer to the GSM BSS Network KPI (TCH Congestion Rate)

Optimization Manual.



The TCH congestion rate can be classified into cell congestion rate, but considering the implementation

period of the capacity expansion, when the TCH congestion rate of the entire network reaches the yellow

line, you can suggest the network capacity expansion in the stage of overall analysis. If the entire

network cannot be expanded because the frequency resources are limited, put forward the scheme of

dual-band network and concentric cells.

If the TCH congestion rate of the entire network reaches the yellow line, except the load, the

problem is caused by the external interference of the entire network, bugs or faults of the NEs

beyond BSC. When the special cases occur, many obvious symptoms may occur in the entire

network. In this case, refer to the GSM Interference Analysis Guide

(http://support.huawei.com/Knowledge Center/Radio/Radio Performance and Network

Planning and Optimization). The GBSS engineers can also process the fault through the

workflow for major faults.

5.3 Analysis on the Call Drop Rate in the CS Domain

The drop rate can be classified into the TCH drop rate and the SDCCH drop rate. In the KPI

monitoring, you should monitor the TCH drop rate (including handover) and the SDCCH

drop rate. The causes of the SDCCH drop and the TCH drop are the same and they occur at

the same time. Hence, process the two problems at the same time.

The drop rate (TCH drop rate and the SDCCH drop rate) is a KPI concerned by all carriers.

The evaluation requirements of the carrier increase gradually (every half a year or every

quarter). Hence, when you monitor the KPI in the local network, the value of the red line for

the drop rate should be increased according to the network conditions.

It is rare that the drop rate of the entire network is not qualified. If the occasional

network-wide or BSC-level drop rate decreasing problems become common, you should

consider the settings of the parameters. For the common network, drop rate optimization is to

analyze the TopN cells. The GSM BSS Network KPI (TCH Call Drop Rate) Optimization

Manual provides details for the analysis of the drop rate.

In addition, the requirements of carriers for the KPI of drop rate are strict. If the KPI

monitoring of the entire network passes the evaluation (network level and the cell level

indexes are better than the KPI yellow line). If the time is sufficient, choose certain bad cells

to process. When you choose the bad cells, you should consider the rank of drop rate and the

effect of the drops. Determine the TopN bad cells according to the product of the two items.

For details, see section 4.4 "Selection of TopN Bad Cells."

5.4 Analysis on the Handover Success Rate

In the entire KPI, the handover success rate can be classified into the following types: internal

handover success ratio, success rate of outgoing inter-BSC handover, success rate concentric

cell handover, and dual-band handover success rate. During the analysis, you should first

consider the handover success rate of the overall performance, in which, the handovers are

integrated. If the handover success rate reaches the standard, when a single handover type

does not reach standard, it is special cases of certain cells.

The KPI monitoring of the handover success rate is different from that of other KPIs. For

other KPIs, the TopN cells can be chose according to the KPIs, and then analyze the

distribution. When you analyze the handover success rate, you can determine the area of the

TopN bad cells according to the handover success rate of a single type (such as inter-BSC



outgoing handover, if the handover problem is on the BSC edge, the dual-band handover can

be located in the corresponding area). At the same time, you can choose the TopN cells

according to the KPIs (such as the handover success rate), and then determine the direction to

analyze the problem according to the single handover type of the cell.

If the problem of handover success rate is common, first analyze the impact of the single

handover type of the entire network. For example, the inter-BSC outgoing handover

difference causes that the network-wide KPI is lower than the bottom line, and the handover

success rate of the dual-band network is bad. If the problem is not of a certain type of

handover, you should consider whether the planning of the adjacent area is reasonable and

whether the setting of the handover timer is reasonable.

For the analysis on the handover success rate of a single cell and how to process the problem,

refer to the GSM BSS Network KPI (Handover Success Rate) Optimization Manual.

5.5 Analysis on the Accessibility of the CS Domain

The accessibility KPI reflects the performance from the MS accessibility to the channel

allocation in the CCCH. Different carriers pay different attention to the KPI owing to the

retransmission mechanism and the difference of transmission quality. The principles for

monitoring the accessibility KPI are as follows: Record the yellow line only, and pay attention

to the TopN cells lower than the red line. Pay no attention to the sites where the transmission

cannot be ensured or reduce the evaluation standard. Do not evaluate the satellite site.

When the accessibility KPI of the cell is faulty, the handover is also faulty. Hence, the

problems occurring at the same time must be processed with higher priority. In the new

network, the accessibility analysis help find the quality of the project.

For the methods of optimizing the accessibility KPI, refer to the GSM BSS Network KPI (Assignment Success Rate) Optimization Manual, GSM BSS Network KPI (Immediate

Assignment Success Rate) Optimization Manual, and GSM BSS Network KPI (Call Setup

Success Rate) Optimization Manual.

5.6 Analysis on the Paging Success Rate in the CS Domain

The paging success rate is a KPI of the overall performance of the mobile network. The

statistical unit is the location area. Hence, the analysis should be performed in the global level.

The performance cannot be calculated in the BSS. In the KPI monitoring, we should collect

and process the performance statistics according to the actual condition. When the KPI is

degraded, ask the local office to give a pre-warning or ask the carrier to optimize the product.

The statistical data of the paging success rate is limited and it cannot be extracted on the BSS

side. Hence, for the monitoring and optimization of the KPI, adjust the parameters through the

cooperation between the BSS side and the NSS side. In addition, optimize the performance of

the network-wide coverage.

To optimize the paging success rate, refer to the GSM BSS Network KPI (Paging Success Rate) Optimization Manual.



5.7 Analysis on the Accessibility of the PS Domain

The accessibility KPI in the PS domain includes the TBF establishment success rate, the TBF

congestion rate, and the PDCH allocation success rate. The TBF establishment success rate

covers the process from the TBF establishment attempt to the TBF establishment success. The

TBF congestion rate and the PDCH allocation success rate describe radio channel resources

failure and the radio channel setup failure. Except the failure described in the TBF congestion

rate and the PDCH allocation success rate, the TBF establishment success rate also describes

the failures in the process of TBF establishment due to the faulty transmission channel,

equipment, and the retransmission mechanism.

5.7.1 TBF Congestion Rate

According to the definition, the degradation of the TBF congestion rate is caused by the

insufficient channel resources. When the problem occurs, try to increase the PS channel

resources. In the cells configured with dynamic PDCHs, try to change the channels into static

PS channels, or put forward the suggestions for expanding the capacity according to the CS

service.

When the TBF congestion rate is high but the cell throughput is low, check whether the

problem is caused by the MSs. If the problem persists, contact experts for support.

5.7.2 PDCH Allocation Success Rate

According to the definition, the PDCH allocation success rate indicates the case that the BSS

side does not receive the response from the MS side after the TBF establishment assignment

message (immediate assignment message) is delivered. In this case, the MS side may fail to

transmit the message (the MS is faulty), or the radio link quality is not good enough, which

causes the problem that the BSS side cannot receive the MS response.

With the TBF drop rate, TBF retransmission rate, or the MR report of the carrier frequency in

the CS side, you can determine the quality of the carrier frequency radio link of the PS

channel. When you determined that the problem is caused by the radio quality, you can adjust

the RF. For details, see the GSM RF Optimization Guide

(http://support.huawei.com/Kowledge Center/Radio/Radio Performance and Network

Planning and Optimization).

If the MS is faulty, you can trace the specific MS type and then choose measures according to

the actual conditions. If many MSs encounter the same problem, you can contact the company

for any customized solution.

5.7.3 TBF Establishment Success Rate

The TBF establishment success rate is affected by the TBF congestion rate and the PDCH

allocation failure. When you locate the problem, you can first exclude the TBF congestion

rate and the PDCH allocation success rate, then, the analysis on decrease of the TBF success

rate becomes easier. For the TBF establishment success rate, concern the equipment and the

parameter setting. In addition, the CCCH congestion may also cause the decrease of the TBF

establishment success rate. Moreover, the problem is not indicated in the two KPIs including

PDCH allocation success rate and the TBF congestion rate.

When the TBF establishment success rate is degrading, refer to the GSM BSS Network KPI

(TBF Downlink Setup Success Rate) Optimization Manual and the GSM BSS Network KPI

(Accessibility) Optimization Manual.



5.8 Analysis on the TBF Drop Rate in the PS Domain

The TBF drop rate involves the uplink and downlink of the GPRS and EGPRS services. At

the same time, the drop rate can be classified into the N3101, N3103, and N3105 overflow

drops according to the timer. Majority of the TBF drops is generated because the CS service

preempts the dynamic channels.

When the TBF drop rate is degrading, check the GPRS or the EGPRS service according to the

service type. If a service is faulty, the setting or the related parameter is incorrect.

If the problem occurs in certain cells, check whether the cell is configured with the dynamic

PDCH. To solve the problem, disable the dynamic PDCH temporarily (or change the dynamic

PDCH into the static PDCH).

If the problem is not caused by the incorrect setting, check whether the accessibility of each

cell is of the same level. Then, determine whether the radio quality is affected according to the

drop rate in the CS domain.

For how to check and process the TBF drop rate, refer to the GSM BSS Network KPI (TBF

Drop Rate) Optimization Manual.

Owing to the unbalanced development of the GPRS service, the KPI in the PS domain of

certain cells in the network cannot reach the standard, especially when the handover is not

enabled in the PS service. As a result, the drop rate is high in certain cells and the problem

cannot be processed. In this case, provides the carrier with a written report according to the

actual condition. You need not process the problem.

5.9 Analysis on the TBF Retransmission Rate in the PS Domain

The TBF retransmission rate is the direct reason affecting the PS service speed. The

degradation of the retransmission rate draws the attention of users. In general, the radio

quality affects the TBF retransmission rate. Check whether the radio network is faulty

according to the PDCH allocation success rate and the CS service. Then, process the problem

by referring to the GSM RF Optimization Manual (http://support.huawei.com/Knowledge

Center/Radio/Radio Performance and Network Planning and Optimization). In specific cases,

if the radio quality cannot be improved, you can decrease the coding scheme to process the

problem.

For details of analysis and optimization, refer to the GSM BSS Network KPI (Retransmission

Rate) Optimization Manual.



6 Implementation of KPI Monitoring on NASTAR

6.1 Daily/Weekly/Monthly Report of NASTAR GSM

The daily report is for the onsite maintenance personnel to monitor the performance of the

network. In the early stage of the network application, the onsite maintenance personnel need

to learn the running status of the network frequently. The daily report helps find and locate

certain network problems.

The weekly and monthly reports are for the network operators to learn the change trend of the

network performance. The operators can analyze and optimize the degrading indexes and then

make the optimization and operation strategy. The weekly and monthly reports focus on the

change trend of each KPI on the KPI page.

The procedure for exporting the daily report is as follows:

Step 1 Create a project, import the traffic statistics, and then choose Analysis Reports > Daily

Report, as shown in the following figure. For creating a project and importing the traffic

statistics, refer to the GENEX NASTAR GSM User Manual.



Figure 6-1 Daily report menus

Step 2 In the displayed setting page, you can set the path for saving the reports, the BSC to be

monitored, and the date of the report.



Figure 6-2 Setting of daily report

Step 3 On the Advanced tab page, set the TopN cells, busy cell, free cell, and the worst cell. Click

Cell Group Manage to edit the VIC cell group.



Figure 6-3 Advanced setting of the daily report exporting

Step 4 Click OK to generate the daily report. The daily report includes the cover, KPI, TopN of BSC,

traffic trend chart in 24 hours, VIC, hot cells, busy and free cells, worst cells, and other KPI

trend pages. The font color of the abnormal counter in the report is red. For the value of the

abnormal counter, refer to the GENEX NASTAR GSM User Manual.



Figure 6-4 Format of the output daily report

The operation of the weekly report and the monthly report is similar to the operation of the

daily report.

The weekly report includes the cover, KPI, TopN of the entire network or BSC, VIC, traffic

trend chart in a week, radio complete rate in a week, drop rate trend chart in a week, TCH

congestion rate trend chart in a week, SDCCH congestion rate trend chart in a week, TCH

availability trend chart in a week, SDCCH availability trend chart in a week, and the CPU

load trend chart in a week.

The monthly report includes the cover, KPI, TopN of the entire network or BSC, worst cells,

traffic trend chart in a month, radio complete rate in a month, drop rate trend chart in a month,

TCH congestion rate trend chart in a month, SDCCH congestion rate trend chart in a month,

TCH availability trend chart in a month, SDCCH availability trend chart in a month, and the

CPU load trend chart in a month.

6.2 Network Monitoring Report (CS Services)

The network monitoring report is for the onsite engineering management personnel. The

engineering management personnel can monitor the network through the network monitoring

report. For different requirements, the engineer (BSC/Cell) report, TL (network/BSC) report,

and the network monitoring comparison report are output.

The engineering report is frequently used in the KPI monitoring. The report provides the

details of each performance index, including the KPI ranks and chart analysis from the BSC

to the cell. This report facilitates the engineers to learn the general performance of the

network and the performance trend, and thus, the problems can be located. The procedure for

obtaining the engineering report of the network monitoring report is as follows.



Step 1 Choose Analysis Reports > Network Monitoring Report.

Figure 6-5 Network monitoring report menus

Step 2 On the Basic Setting tab page, set the path for saving the reports, the query object, report type,

date range, and statistic time. When you create the engineer report, you should select

Engineer Report for the Report Type.



Figure 6-6 Basic setting of network monitoring report

Step 3 On the Advanced Setting tab page, set the value of N in the TopN bad cells, filtering setting

for bad cells, VIC cell group, and the KPI baseline. The default value of N in TopN is 10. The

filtering conditions are not set. In practice, for the value of N, 5% (not more than 50) of the

cell quantity is recommended. At the same time, set the red line and yellow line to filter the

TopN cells.

In the KPI, set the lower threshold of the good network and the lower threshold of the normal

network to the yellow line and the red line. Mark the KPIs exceeding the red line and the

yellow line with colors in the exported report.

The current NASTAR cannot distinguish the cell baseline from the entire network baseline.

You can set the entire network baseline and the cell baseline separately, and export the report

one by one. You can also set the entire network baseline, and select the cell baseline manually.



Figure 6-7 Advanced setting of the network monitoring report

Step 4 Click OK to generate the network monitoring report. In the network monitoring report, the

monitoring KPIs include accessibility, mobility, retainability, and the resource utilization.



Figure 6-8 Monitoring report output

6.3 PCU Monitoring Report

The PCU monitoring report provides analysis and statistics of traffic KPIs (such as connection,

call drop, and data volume) of PCU. Through this report, you can monitor the operating

quality of the data service timely and comprehensively. The PCU monitoring report, the same

as the network monitoring report, can be classified into the engineering report, team leader

report, and comparison report. In the routine network monitoring, the engineering report is

commonly used. The procedure for generating the engineer report is as follows.

Step 1 Choose Analysis Reports > PCU Network Monitoring Report.



Figure 6-9 PCU monitoring report menu

Step 2 In the PCU Network Monitoring Report dialog box, set the path for saving the reports, the

query object, report type, date range, and the statistic time.



Figure 6-10 Setting of the PCU monitoring report

Step 3 After setting the parameters, click OK to generate the report. The PCU monitoring report

includes KPIs of the accessibility, retainability, Um interface transmission, Gb interface

transmission, and the resource utilization.



Figure 6-11 PCU monitoring report

6.4 Exporting and Analysis of the Bad Cells

The TopN bad cells of each monitoring KPI are available in the daily/weekly/monthly report,

network monitoring report, and the PCU monitoring report. You can also use the enhanced

traffic statistics to customize the statistical traffic. As a result, the monitoring and optimization

are facilitated. The procedure for generating the enhanced traffic statistics is as follows:

Step 1 Choose Analysis Reports > Enhanced Traffic Statistics.

Step 2 Set the related parameters in the displayed page. Choose the desired objects and KPIs

according to the actual conditions.

If the type is whole, the selected KPIs are summarized and a record is generated. The

summarizing mode (by the sum or by the maximum value) is determined by the calculation

mode of the selected KPIs. The calculation modes of the KPIs are different. For the selected

type, the details in the range are provided.



Figure 6-12 Setting of enhanced traffic statistics

Step 3 Click Report Output to generate the traffic statistics report. In the Excel generated, choose

the TopN bad cells according to actual conditions.



Figure 6-13 Traffic statistics report output

6.5 Comprehensive Analysis on the GSM Network Expansion

The analysis report of the NASTAR GSM network capacity expansion provides the utilization

of the radio resources. The utilization of the network resources is obtained through the

comparison of the resource configuration, available network resources, network traffic, and

the designed network capacity. After you provide the suggestions for network capacity

expansion, you can ignore the analysis of TCH congestion rate (overflow). After the network

capacity is expanded, the TCH congestion rate does not reach the standard, then, refer to the

GSM BSS Network KPI (TCH Congestion Rate) Optimization Manual. The procedure for

generating the network expansion report of the NASTAR GSM network is as follows.

Step 1 Choose Analysis Reports > Network Expansion Report. The page for setting the

parameters is displayed.



Figure 6-14 Setting of the network expansion report

Step 2 In the displayed page, set the start date, end date, BH traffic statistics mode, capa_cell

expansion figure (%), TCH margin, TCHs per TRX, Capa_cell definition, and Erl_B GOS

(%). The Erl_B GOS (%) is subject to the requirement of the carrier and the value 2 is

recommended. For other parameters, use the default values.

Step 3 In the Query Object, select the object type.



Figure 6-15 Setting of the query object

Step 4 Click OK to generate the radio resource optimization report.



Figure 6-16 Wireless Resource Optimization Report



7 Summary

Thanks go to colleagues of each department for their support in the development of GSM KPI Monitoring and Optimization Guide. It is the first KPI monitoring guide of the radio product.

The document intends to focus on the practical operation, but the theory still weights a lot

owing to limited foundation. Especially for the output of the monitoring report, the report

specification is not available because the plan is not implemented. The monitoring method is

not implemented onsite for long term. Hence, no complete KPI analysis case is provided in

this document.

After the guide is put into practice in the field, we plan to choose the KPI monitoring and

optimization cases based on M2000 and NASTAR (new version of 2009). Each case should

be chosen from the monitored KPI. The case describes the making of monitoring standard, the

detection of KPI problems, and the processing method. The segments of the monitoring report

about the KPI monitoring problems are added, which guides readers to master the method of

monitoring KPIs and processing the problems. As a result, comprehensive monitoring and

optimization report can be generated timely.

The improvement of the guide relies on the practice onsite. If you have any suggestions or

operation cases, please send your feedback to us. Your experience is of great importance and

is helpful for other users.

G KPI Monitoring and Improvement Guide 20081230 a 1.0

Documents

Transcript of G KPI Monitoring and Improvement Guide 20081230 a 1.0