Internal

UMTS CS Call Drop Analysis Guide

Version: V2.0

ZTE UMTS Radio Network Planning & Optimization

Department

UMTS Network Planning & Optimization Guidebook

Release Notes:
Version

Date

V1.0

2009/4/23

V2.0

2009/11/25

Author
Qin Jianhan
Zhou Changjing

Reviewed by
None
Yin Jianhua, Gan Yi, Xu
Zhexian

Revision History
Draft
2nd edition

Key words:
CS, Call drop

Abstract:
This document introduces ways to evaluate, test, analyze and solve the call drop
problem.

Abbreviation:
None

Reference:
None

Table of Contents
1 Introduction ....................................................................................................................................... 1
2 Definition ............................................................................................................................................ 2
2.1

Definition of Call Drop from Drive Test Aspect............................................................................. 2

2.2

Definition of Call Drop in OMC Side............................................................................................. 2

3 Call Drop Analysis ............................................................................................................................. 4

3.1

Call Drop Reasons .......................................................................................................................... 4

3.1.1

Call Drops Caused by Insufficient Coverage ........................................................................ 4

3.1.2

Call Drop Caused by Neighbor Cells .................................................................................... 5

3.1.3

Call Drop Caused by Interference ......................................................................................... 6

3.1.4

Call Failure Caused by Two Cells Using the Same PSC....................................................... 7

3.1.5

Call Drops Caused by Engineering Causes ........................................................................... 9

3.1.6

Call Drops Caused by 2G/3G Interoperability .................................................................... 12

3.1.7

Call Drops Caused by the System ....................................................................................... 13

3.2

Analyzing Call Drops by DT ........................................................................................................ 13

3.3

Analyzing Call Drops by Traffic Statistics ................................................................................... 15

3.4

3.3.1

Procedure of KPI Analysis .................................................................................................. 16

3.3.2

Basic Methods to Analyze KPIs .......................................................................................... 17

3.3.3

KPI Analysis Tolls............................................................................................................... 19

Radio Parameters Involved During Optimization......................................................................... 21

3.4.1

Radio Parameters Related with CS Call Drops ................................................................... 21

3.4.2

Timer and Counter Related with Call Drop ........................................................................ 24

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal

Figures
Figure 1

Scenario one that may cause the same PSC problem ...................................................... 7

Figure 2

Scenario two that may cause the same PSC problem ...................................................... 8

Figure 3

Scenario three that may cause the same PSC problem .................................................... 9

Figure 4

Measurement of antenna power through PMS .............................................................. 10

Figure 5

Flow chart to test call drops by DT ............................................................................... 14

Figure 6

Flow chart for top cell selection .................................................................................... 17

Figure 7

PMS cell performance measurement figure .................................................................. 19

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

II

Internal

Tables
Table 1

RSCP and Ec/Io threshold for different services ..................................................................... 4

Table 2

Common E1 faults and handling suggestions ....................................................................... 11

Table 3

Timer and counter related to the UE ..................................................................................... 24

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

III

Internal

1 Introduction
This document is compiled to guide the network optimization engineers to solve the
call drop problem, to reduce the call drop rate, and to improve the quality of the
network. It also introduces ways to evaluate, test, analyze and solve the call drop
problem. In addition, it also includes some typical cases. In the actual network
optimization activities, handover and call drop are strongly related. In most cases,
handover failure would lead to call drops. For this kind of call drops, you may refer to
the guidebook for call drops caused by handover. This document mainly focuses on call
drops which are not caused by handover failures.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal

2 Definition
2.1 Definition of Call Drop from Drive Test Aspect
Air interface signaling at the UE side: Call drops refer to call releases caused by Not
Normal Clearing, Not Normal, or Unspecified when the message on the air interface
satisfying any of the following three conditions:

The UE receives any BCH information (system information).

The call is released for Not Normal and the UE receives the RRC

Release information.

The UE receives CC Disconnect, CC Release Complete, and CC

Release information.
Signaling recorded at the RNC side: Call drops refer to call releases when the RNC has
sent the Iu Release Request to the CN through the Iu interface, or when the RNC has
sent the RAB Release Request information to the CN through the user panel.

2.2 Definition of Call Drop at OMC Side

The definition of call drop in a broad sense contains the call drop rates at both the CN
and UTRAN sides. Since the network optimization focuses on the call drop rate at the
UTRAN side, this document only focuses on the KPI analysis at the UTRAN side.
The KPIs at the UTRAN side refers to the number of released RABs of different
services triggered by the RNC. Two aspects are involved: (1) After the RAB is
established, the RNC sends the RAB RELEASE REQUEST information to the CN. (2)
After the RAB is established, the RNC sends the IU RELEASE REQUEST to the CN,
and then it receives the IU RELEASE COMMAND from the CN. The statistics can be
collected based on specific services.
Meanwhile the traffic statistics also imply reasons that the RNC triggers the release of
the RABs of different services.
The call drop rate can be calculated by the following formula:

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal

CS _ CDR

CSRabrelTriggedByRNC *100%
CSRABSetupSuccess

CSRabrelTriggedByRNC contains the number of RABs included in RAB RELEASE

REQUEST for CS services and that included in IU RELEASE REQUEST for CS
services.

PS _ CDR

PSRabrelTriggedByRNC *100%
PSRABSetupSuccess

RabrelTriggedByRNC contains the number of RABs included in RAB RELEASE

REQUEST for PS services and that included in IU RELEASE REQUEST for PS
services.
It should be specified that the RNC traffic statistics calculates the times of call drops
through the signaling at the Iu interface, and counts the number of RAB RELEASE
REQUEST and the number of IU RELEASE REQUEST initiated by the RNC. While
call drops in the drive test aspect emphasizes the information at the air interface and
non-access stratum and their cause value. It is different from call drops at the OMC
side.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal

3 Call Drop Analysis

Many reasons may lead to the call drop problem, and call drop is an expression of the
deep network problems. This chapter focuses on the call drop reasons, commonly-used
call drop analysis methods, and main call-drop optimization instruments.

3.1 Call Drop Reasons

3.1.1 Call Drops Caused by Poor Coverage
In the definition of network coverage, the requirements of effective coverage for a
certain sampling point is that its RSCP and Ec/Io should be better than the specified
threshold. In this section, bad coverage is represented by poor RSCP value. Note that
coverage at cell edges is a special case. Coverage at cell edges would have bad RSCP
value and excellent Ec/Io owing to little cell number, but still the coverage in these cell
edges is defined as bad coverage.
In UMTS network, initiation and maintenance of different services would have
different requirements on coverage. Table 1 lists the reference values.
Table 1 RSCP and Ec/Io threshold for different services
Service Type

RSCP [dBm]

Ec/Io [dB]

AMR12.2K

-105

-13

CS64K

-100

-11

PS384K

-95

-10

HSDPA

-90

-8

The coverage condition at the UL and DL of the network can be estimated through the
power of the dedicated channels for the UL and DL before call drops, which can be
performed through the following methods.
If the UL TX power before the call drop has reached the maximum value and the UL
BLER is bad, or it is found out through the single user tracing record at the RNC that
the NodeB has reported RL failure, then the call drop is caused by bad UL coverage. If
the DL TX power before the call drop has reached the maximum value and the DL
BLER is bad, then the call drop is caused by bad DL coverage.
This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal
For the coverage optimization method, see the WCDMA Radio Network Optimization
Guide.

3.1.2 Call Drop Caused by Neighbor Cells

1.

Missed neighbor cell

Neighbor cell optimization is an important link of radio network optimization. If

certain cells should be included but excluded from the neighbor cell list of one cell,
then call drop would happen and the interference in the network would also increase
and system capacity would be impacted. Therefore, neighbor cell optimization is an
important part of the engineering optimization.
It is easy to estimate whether the cell is configured with any neighbor cell, and you can
playback the call drop data, perform NCOS analysis, and analyze the scanner data.

Use ZTE CNA to playback the call drop data. If the blue pillar

(representing the detected set) in the histogram of the pilot signals is the
longest, then the missed neighbor cell problem exists.

Use the automatic analysis tool of ZTE NCOS, it would study the

handover data of the network, and automatically add the missed neighbor cell.
For details, see the operation guide of NCOS.

During the drive test, the UE would acquire the neighbor cell list from

the NodeB, and the scanner would scan the 512 PSCs and record the Ec/Io. If
one of the PSCS is not included in the neighbor cell list, and its pilot strength
is stronger than the threshold, and the phenomenon lasts for a few seconds,
then the missed neighbor cell problem exists.
2.

Removal of key neighbor cells caused by combination of macro diversity

Assign the priority of the neighbor cell when performing the initial neighbor cell
planning, then optimize the priority and number of neighbor cells periodically with
NCOS as the traffic volume increases.
3.

Untimely update of the external cell information

Check the external cells of the RNC periodically, and ensure the cells in the list are
correct.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal
3.1.3 Call Drop Caused by Interference
Distinguish the UL and DL interferences.
The interferences from the UL and DL would both lead to call drop. Generally, when
the CPICH RSCP of the active set is large than -85dBm, and the comprehensive Ec/Io
is lower than -13dB, call drop occurs, then the call drop is caused by the DL
interference. Note that when the handover is not timely, the RSCP of the serving cell
may be good, but the Ec/Io is bad. However, the RSCP and Ec/Io of the monitored set
are both excellent under this condition. When the UL RTWP is 10dB higher than the
normal value, which is -107~-105, and the interference duration is 2s or 3s longer, call
drop may happen and the problem must be solved.
Two reasons may cause DL interferences, which are pilot pollution and missed
neighbor cell. The missed neighbor cell has already been discussed in the above part
and would not be repeated here. In the pilot pollution area, signals of multiple cells
exist, the RSCP of these cells is good, while Ec/Io is bad, the UE would frequently
reselect the neighbor cell or perform the handover, and the incoming and outcoming of
calls can hardly reach the UE. Generally, three factors would lead to pilot pollution in
the network.

Overshooting of sites at a high location

NodeBs in ring-shaped distribution

Wave-guide effect, large reflectors, and some other effects that may

cause the distortion of signals.

The typical feature of DL call drops is that the RNC sends the Active Set Update
message, while the UE cannot receive it, then the call is dropped for RL Failure.
You can judge whether the UL interferences exist by the Average RTWP and Max
RTWP on the OMC-R. For an idle cell, the Average RTWP is about -105dBm; for a
cell carrying 50% of UL load, the Average RTWP is around -102dBm. If the Average
RTWP of an idle cell exceeds -100dBm, we can believe that UL interferences exist.
The UL interferences make the UL TX power of the cell in connected mode increase,
and then an excessively high BLER is generated. Then call drop happens. During
handover, the newly-added link is out of sync for UL interferences, which further leads

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal
to failed handovers and call drops. The UL interference may be intra-RAT or inter-RAT
interferences. In most cases, the UL interferences are inter-RAT interferences.
When DL interference exists, the UL TX power is very small or the UL BLER may
converge, however, when the DL TX power of the UE reaches the maximum value, the
DL BLER does not converge. If UL interferences exist, the same problem would insist.
Thus, in actual analysis, this method can be used to distinguish whether interferences
exist.
For methods to investigate the interferences, see the UMTS Interference Investigation
Guidebook.

3.1.4 Call Failure Caused by Two Cells Using the Same PSC
3.1.4.1

Scenario One

Figure 1 Scenario one that may cause the same PSC problem

Cell A and Cell B (source cell) are configured as neighbor cell for each other, however,
the geographical distance between Cell A and Cell B is huge. Cell A and Cell C has the
same PSC, and Cell C and Cell B (source cell) is very close, however, Cell C and Cell
B are not configured as neighbor cells for each other.
Under this situation, the UE detects signals from Cell C and sends Event 1A request to
be soft handed over to Cell C. The PSC in the Event 1A request is 123. After receiving
the Event 1A request, the RNC checks from the neighbor cell list of Cell B (source cell)
for cells with PSC of 123, then it finds Cell A. Then the RNC tries to build the radio

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal
link on Cell A. The RNC instructs the UE to add Cell A to its active set. Then, the
update of the active set times out for the cell measured by the UE is different from the
cell where the radio link is built.
3.1.4.2

Scenario Two

Figure 2 Scenario two that may cause the same PSC problem

In this scenario, the UE has established the radio link with two cells, Cell B and Cell C.
Cell A is the neighbor cell of Cell B, and Cell D is the neighbor cell of Cell C, and
these two cells have the same PSC. When the UE is in soft handover state, the RNC
would combine the neighbor cell lists of Cell B and Cell C, then the same PSC problem
would happen.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal
3.1.4.3

Scenario Three

Figure 3 Scenario three that may cause the same PSC problem

Cell B and Cell D are not configured as neighbor cell for each other, however, these
two cells are both included in the active set owing to the third-party handover among
Cell B, Cell C, and Cell D. Cell A is the neighbor cell of Cell B, and Cell E is the
neighbor cell of Cell D, and these two cells have the same PSC. The RNC would
combine the neighbor cells of Cell B, Cell C, and Cell D in the active set, then the
same PSC problem may occur.

3.1.5 Call Drops Caused by Engineering Causes

1.

Reversely-connected antenna

You can check whether the diversity is reversely connected by the PSC distribution
figure of the drive test data. For the connection of the diversity, the PMS can be used to
measure the cell performance. The antenna would only generate power when UEs try
to access the network, and the measured value of the power equals to the demodulation
power. You can check the ratio of two antennas, if the power of one antenna is lower
than the other one in a long period of time, then the diversity must be reversely
connected.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

Internal

Figure 4 Measurement of antenna power on PMS

The balance level checking of two antennas in whole network can be implemented by
OMCB measurement. However, you need to manually process the acquired data.
2.

An excessive VSWR

You can check the VSWR of the current site at the RNC SDR. If the VSWR is large
than or equals to 1.4, then it must be adjusted.
3.

Multi-band antenna problem

In the network of some cities, multi-band antennas exist. The operator usually refuses
to adjust the parameters of the multi-band antenna for fearing of affecting the
subscribers of the existing 2G network. Then pilot pollution or overshooting may occur.
To solve this problem, you should try to persuade the operator to change the antenna,
so that 2G and 3G networks can have separate antennas. If these antennas cannot be
changed, then the specific environment must be carefully studied before taking any
actions. You can optimize the neighbor cells to avoid call drops.
4.

Leakage of signals from indoor distribution system

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

10

Internal
In most cities, call drops caused by signal leakage from indoor distribution system exist.
You should persuade the operator to reconstruct the indoor distribution system. Or, the
indoor distribution system can be merged to the whole network, which can be done by
optimizing of the coverage of the ambient outdoor cells and addition of neighbor cells.
5.

Call drop caused by unsteady transmission

As the bottom level of transmission medium, E1 would report the loss of E1 electrical
signals and reception failures at the remote end. Meanwhile, several E1s would be
bound together as a group, and then E1 would report the fault of IMA group in
non-operating mode.
The following table lists several E1 faults that must be handled and the related
handling suggestions.
Table 2 Common E1 faults and handling suggestions
Fault
Lost of E1
electrical signals

Causes

Solutions

The RX end detects no line circuit pulse or

1. Check whether the SA board is

cannot detect logic 1 within continuous

secure, and whether the E1 adapter

periods, then the LOS alarm is reported. This

is slack.

alarm is generally caused by the RX fault of

the E1/T1 or broken lines, then the E1/T1
cannot detect the signals from the remote end.

2. Check whether the pins of the

adapter are damaged.
3. Check

whether

the

joint

connector of the E1 cable is

damaged, and whether the joint
connector is securely connected
with the E1 cable.
4. Check whether the cabling of
the

E1

cable

satisfies

the

engineering specification, whether

the E1 cable bears any external
force.
5. Use the E1 self-loop cable to
recycle the line, if the alarm is
cleared, then check the E1 cable at
the peer end.
Remote reception

It indicates the E1/T1 remote alarm. This

1. The TX line is faulty or

failure of the E1

alarm indicates the abnormal receptions at the

broken. Check whether the TX line

remote end. The remote end inserts the RAI

is correctly connected. For details,

indicator bit to the signals and then sends it to

see the Handling suggestions for the

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

11

Internal
the local end, and the local end reports the
alarm after detecting the alarm.

LOS Alarm.

The remote

reception error is reported.

2. Check whether the frame

structures of the E1 frame at the
local end and remote match. The E1
frame at both ends must both work
at dual-frame or multi-frame mode.
3. Check for error codes at the
TX line.

E1 frame out of
sync

The first bit of slot 0 of both E1 and T1

carries the synchronous clock signals, which

1. Whether E1 and T1 work at the

same state.

inform the RX end of the start of one frame. If

2. Check whether E1 frames are

the RX ends of the E1 and T1 are out of sync,

of

then data frames would be lost and the LOF

(dual-frame/multi-frame).

alarm is reported.

the

same

modes

3. Check whether the impedance

modes of E1/T1 matches.
4. Check for interferences from
digital devices around E1/T1.
5. Check whether the clock
signals are normal.

SSCOP link error

This alarm is caused by that the SSCOP

signaling link is unsuccessfully established or

See the handling suggestions for

E1 faults.

the SSCOP signaling from the remote end is

not received within a certain period. Then the
SSCOP link would be broken off, and this
alarm is reported.
IMA group in

After the IMA group is successfully

non-operating

configured, if IMA remains in non-operating

mode

mode for over 1s, then this alarm is reported.

See the handling suggestions for

E1 faults.

Currently, some sites are configured with IP transmission. Therefore, the alarm of
"Lack Ethernet electrical signals" also should be handled on site.

3.1.6 Call Drops Caused by 2G/3G Interoperability

1.

Optimization of 2G neighbor cells configured for 3G cells

If the 2G cells are congested, or interfered, then the success rate of 3G -> 2G
handovers is low. During the neighbor cell optimization, this kind of neighbor cells
must be removed from the list.
2.

Parameters must be refined based on different scenarios.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

12

Internal
To improve 3G->2G handover success rate, the parameters must be detailed planned
based on different scenarios.
3.

Compatibility of UEs

The 2G->3G handovers of some cells are slow. This is because some smuggled 3G
handsets have some difficulties in supporting the 2G network.
4.

2G/3G data synchronization

To support 2G/3G handovers, the 2G/3G cells must be configured as the neighbor cells
for each other firstly. If the cell information is updated timely, then the handover would
fail and cell reselection cannot be performed. Therefore, the data of 2G/3G network
should be synchronized timely.

3.1.7 Call Drops Caused by the System

If the alarm is not caused by the causes listed in the above section, then it may be
caused by the system. You need to check the alarm information of the equipment and
system logs to further analyze reasons that cause call drops.

For example, an

abnormal NodeB would lead to the synchronization failures, which would lead to
frequent removal and addition of radio links, and then call drops may happen; call
drops caused by poor DL signals may be because of abnormal RF module, and call
drops caused by that the UE fails to report the measurement report Event 1A.
It should be noted that in many foreign countries, the TX environment is bad and
unstable. Therefore, influences of call drops caused by TX problem are huge.

3.2

Analyzing Call Drops by DT

The following figure describes the flow chart for using DT and CQT to test call drops.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

13

Internal

Figure 5 Flow chart to test call drops by DT

1.

Call drop data

The call drop data refers to the CNT test data and RNC signaling tracing data.
2.

Call drop spots

Use CNA to analyze the call drops to acquire the location where call drops happen.
Then acquire the following data: pilot data collected before and after call drops, active
set and monitoring set information collected by the cell phone, and signaling flow.
3.

Stability of the primary serving cell

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

14

Internal
The stability of the primary serving cell refers to its changes. If the primary serving cell
is stable, then analyze RSCP and Ec/Io. If the primary serving cell changes frequently,
then the handover parameters should be changed to avoid the ping-ping effect.
4.

RSCP and Ec/Io of the primary serving cell

Check the RSCP and Ec/Io of the optimal cell, and then

When the RSCP is bad, the coverage is poor.

When the RSCP is normal, while the Ec/Io is bad, pilot pollution or DL

interference exists.

When RSCP and Ec/Io are both normal, if cells in the active set of the

UE are not the optimal cells (which can be checked through playback of data),
then the call drops may be caused by missed neighbor cell or untimely
handovers; if cells in the active set of the UE are the optimal cells, then call
drops may be caused by UL interferences or abnormal call drops.
5.

Reproducing of problems with DT

Since you cannot collect all necessary information by one DT, then multiple DTs shall
be performed to collect sufficient data. In addition, multiple DTs can also help to
ascertain whether the call drop is random or always happens at the same spot.
Generally, if call drops always happen at the same spot, this problem must be solved,
or if call drops happen randomly, multiple DTs must be performed to find inner
reasons.

3.3 Analyzing Call Drops by Traffic Statistics

When analyzing the traffic statistics, check the call drops index on the RNC firstly to
learn the operating status of the whole network. Meanwhile, a cell-by-cell analysis can
be performed to acquire the detailed call drop indexes of each cell. During the analysis,
the traffic statistic analyzing tool can be used to analyze the call drop situations of
different services and the possible causes.
Acquire data about cells with abnormal KPIs through the traffic statistics. If KPIs of
these cells used to be normal, then the abnormal KPIs may be brought by software
version, hardware, transmission, antenna, or data, then you can check these aspects

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

15

Internal
based on the alarms. If no obvious abnormal cells exist, the statistics can be classified
based on the carrier in each sector, then cells with poor KPIs can be screened out.
Further analyze the traffic statistics of these cells, such as analyzing more related KPIs,
such as analyzing data at a shorter interval, or analyzing KPIs that are more likely to
cause call drops, such as handover. Meanwhile, you can analyze the reasons for call
drops based on system logs. During the analysis, you should consider the effect of
other KPIs when focusing on a certain KPI. It should be specified that the result of
traffic statistics is meaningful only when the traffic volume reaches a certain amount.
For example, a 50% of call drop rate does not mean that the network is bad. This value
is meaningful only when the calling number, succeed calling number, call drop times
all make statistical significances.

3.3.1 Procedure of KPI Analysis

The commonly used KPI analysis method is the TOP cell method, which means the top
cells will be screened out according to certain index, then these top cells are optimized
and then the top cells are selected again. After several repetitions, the related KPI can
be speedily converged. At the initial stage of network construction, there are few
subscribers in the network. At this stage, the KPIs of many cells might be unstable,
such as call drop rate. You can collect the data in seven days or longer periods, then
select the top cell and then perform the optimization. For example, optimization of call
drop rate of CS services. When selecting top cells, you can select the cell with call drop
numbers exceeding the specified threshold, and then arrange the priority based on the
call drop rate.
The procedures of top cell selection are the same as the procedures of handling input
information from other team of engineers (complains or single site acceptance), and are
shown in the following figure.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

16

Internal

Figure 6 Flow chart for top cell selection

3.3.2 Basic Methods to Analyze KPIs

3.3.2.1

Speedily Collecting the Field Data

To locate the problem, you have collect data from many different spots between the UE
and the pdn server. While, speedy and accurate collection of the field data is essential
to locate and solve the problem and to improve the KPIs. Data collection can be
divided into multiple layers.
1.

Collecting UE log, RNC signaling, KPI data, alarms, abnormal probes, and packet

captured at the Iub interface

2.

NodeB and RNC debug log

Some common skills are required to collect data of the first layer, and the network
optimization & maintenance personnel can easily master these skills. At present, most
This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

17

Internal
field questions can be located through the data analysis at this layer. Collection of the
debug log of the second layer should be performed or remotely supported by the
relative R&D engineers. Data at this layer can help to solve some deep layer problems.
The following chapter focuses on the data collection tool and method for the first layer
data, and only gives a brief introduction to that of the second layer.
3.3.2.2

Health Check of Sites

For sites where alarms are reported, you should first perform the health check for the
site, which mainly covers the following aspects:

Alarms

Frequently added or removed common transport channels

UL & DL power

Radio link restore

Balance level between two antennas

Statistics of service failures

The RL restore rate is shown by the NodeB cell measurement recorded by PMC as
shown in the following figure, and is accumulated since the establishment of cells. If
the RL restore rate of a cell is lower than 80%, the cell is treated as abnormal, and the
possible causes are as follows:

UL interferences

Insufficient cell radius or overshooting

Reuse of the same PSC

Abnormal UL RF channel

For these possible causes, you may check them combining other measurement results
and data analysis.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

18

Internal

Figure 7 PMS cell performance measurement figure

3.3.3 KPI Analysis Tools

3.3.3.1

Signal Trace
This tool traces signaling of RNC, you can trace the signaling at the Iu, Iur, Iub, and Uu
interfaces, TNL signaling, and RNL signaling through this tool. The most commonly
used method to check the KPIs is to trace the RNL signaling. This tool is very useful,
and can trace the signaling on the basis of cell (trace signaling of multiple UEs) and
IMSI (trace signaling of one UE).
It should be emphasized that signaling tracing by cells can only trace the UE that
initiates the call from this cell. The UE can be traced as long as it remains in the same
RNC, even if it is handed over to other cells. However, if a UE initiates the call from
other cells and then is handed over this call, and its call drop happens in this cell, it
cannot be traced. Therefore, when you trace the signaling of a cell with high call-drop
rate, the signaling of cells in close handover relation with this cell should also be traced,
then the result would be more comprehensive.
The RNC R&D engineers also develop a RNC signaling tracing tool, WinSigAn, which
can mark the call drop spots more clearly.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

19

Internal
3.3.3.2

RNC Association Log

This tool helps to record the context of the abnormal system flow, and then the context
would be counted and analyzed to locate the network problem.
It is usually used when the system is abnormal and no RNC signaling is traced. It can
help to locate the problem by the time when the system exception happens. The
exception can be queried on the basis of IMSI and CELL ID.

3.3.3.3

NodeB LMT
Besides all functions of OMCB, NodeB Local Maintenance Terminal (LMT) can also
provide detailed cell and UE information.
The NodeB LMT consists of EOMS, EFMS, DMS, and PMS.

3.3.3.4

NodeB Exception Probe

In the field of the WCDMA commercial network, this tool can effectively help to
monitor the operating status of the NodeB. Different modules of the NodeB would
record the information when exceptions happen, thus facilitating the location of
problems. However, specialized knowledge is required. You have to understand the
functions and interfaces of different boards. If the field engineers cannot analyze the
report, they can simply send these data to the R&D engineers.
The exception probe reported by different NodeBs can be saved on different OMCB
servers based on the RNC they belong to. Then, this tool would download the file from
different OMCB FTP, and then analyze them.

3.3.3.5

CTS
CTS is the tool for the CN, and it can be used to perform deep signaling by IMSI.
Unlike SignalTrace, which is applicable to the signaling tracing within one RNC, CTS
can perform the signaling tracing across the RNC border, Therefore, it is applicable to
the signaling tracing of VIPs.
CTS can trace the interactive signaling among different NEs within the CN, and can
trace the signaling at the Iu and Uu interfaces, and this is called deep tracing. The
working principles of CTS is as follows: First establish an IMSI task on CTS server,
and then sent this IMSI task to the CN, which is further sent to different modules
through the arranged interfaces, then each module collects the signaling related to IMSI,

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

20

Internal
and then the collected signaling is transmitted back to the CTS server through the CN.
The above interfaces are all private interfaces, thus this tool only work on ZTE CN and
RNC.
3.3.3.6

UE Log
DT is an important means to analyze KPIs. Many problems, signaling tracing at the
network side and tracing of problems which are hard to be located, can be finally
located after combining the UE logs. The commonly used DT software is
QXDM/APEX(QCAT), CNT/CNA, and TEMS.

3.4 Radio Parameters Involved During Optimization

3.4.1 Radio Parameters Related with CS Call Drops
Time To Trigger
Time To Trigger is the interval between the moment that the events (1A, 1B, 1C, and
1D) are monitored and the moment that the events are reported. The setting of TTT
would influence timely handover.
The adjustment of handover parameters should first ensure that this cell is overlapped
by other cells, then you can adjust the related radio parameters to ensure that the time
that the UE passes the handover area is longer than the handover delay of the whole
system, thus ensuring the continuity of the services. The other is to ensure that the
handover area ascertained by the signals and radio parameters cannot be too large to
avoid the increase of handover overhead and reduction of resource utilization ratio.
For areas where the signals may change greatly, the trigger time of Event 1A must be
reduced, and that of Event 1B must be increased. Meanwhile, the CIO of the
corresponding neighbor cells should be adjusted so that Event 1A can happen earlier
and Event 1B would happen later, thus ensuring successful handovers.
For highways, the cells are sparsely distributed. If the vehicles drive too quickly and
cannot access the new cell in time, call drops would happen. The optimization is the
same as that for the optimization for street corners in dense urban, which is to make
cells with good signals join the active set speedily to ensure continuity of services.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

21

Internal
For the adjustment of the related parameters, a whole new set of parameters must be
assigned to the target cell.
3.4.1.1

Cell Individual Offset

The sum of the value of Cell Individual Offset (CIO) and the actually measured value
is used in the evaluation of the events of the UE. The UE would use the original
measurement value of this cell plus the CIO as the measurement result for the
intra-frequency handover judgment. CIO can help to ascertain the cell edge.
The larger this parameter is set, the easier the soft handover will be, and more UEs will
be in soft handover state. However, more resources are consumed. This smaller is
parameter is set, the more difficult the soft handover is.
CIO is valid only for the neighbor cell. For Event 1A, the CIO can be set in the
neighbor cell; for Event 1B, the CIO can be set in the cell to be removed. The formula
is as follows:
Formula of Event 1A triggering:

NA
10 LogM New CIONew W 10 Log M i (1 W ) 10 LogM Best ( R1a H 1a / 2),

i 1
MNew is the measurement of the to-be-evaluated cells that has entered the report range.
Mi is the mean measurement result of cells (exclude the best cell) in an active set.
NA is the current cell number (exclude the best cell) in the active set.
MBest is the measurement result of the optimal cell in the active set.
W is the weight proportion of the best cell to the rest cells in the active set.
R1a is the reporting range of Event 1A.
H1a is the reporting hysteresis of Event 1A.
Formula of Event 1B triggering:

NA

10 LogM Old CIOOld W 10 Log M i (1 W ) 10 LogM Best ( R1b H1b / 2),

i 1

Mnew is the measurement of the to-be-evaluated cells that has entered the report range.
Mi is the mean measurement result of cells (exclude the best cell) in an active set.
NA is the current cell number (exclude the best cell) in the active set.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

22

Internal
MBest is the measurement result of the optimal cell in the active set.
W is the weight proportion of the best cell to the rest cells in the active set.
R1bis the reporting range of Event 1B.
H1b is the reporting hysteresis of Event 1B.
3.4.1.2

Start/Stop Threshold for Compressed Mode

Compressed mode is frequently used during inter-frequency and inter-RAT handovers.
The compressed mode is started before the handover, and the system can use the time
slot brought by compressed mode to perform the signal quality test on the
inter-frequency or inter-RAT neighbor cells. In the current system, the compressed
mode is started through Event 2D, and stopped through Event 2F. The measurement
value of RSCP or Ec/Io can be selected. Currently, the default value is RSCP.
Generally, the quality and other related information of the target cell (inter-frequency
or inter-RAT) must be acquired for the compressed mode. Meanwhile, the moving of
the UE would lead to the deteriorate of the quality of the cell, therefore, the start
threshold of the compressed mode should satisfy the condition that the UE can finish
the measurement of the target cell and report for handover before call drops happens.
For the stop threshold, it should help to avoid the frequent start or stop of compressed
mode.
In dense urban, the continuous coverage of the 3G should be ensured, thus avoiding
unnecessary inter-RAT handovers and increase of system load. For edges of the 3G
network and highways, the UEs should be handed over to the 2G network before the
heavy fading. Under this condition, the trigger threshold of Event 2D should be raised
so that the UE can initiate the compressed mode as early as possible.

3.4.1.3

Maximum DL TX power of the Radio Link

If large amounts of call drops happen due to coverage causes, then the maximum DL
TX power of the services can be increased appropriately. However, this is at the risk
that the UEs at cell edges may consume too much power, and then affect the other UEs,
and reduce the DL capacity of the system. For cells with a great deal of access failures
caused by excessive load, this parameter can be set to a small value.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

23

Internal
3.4.1.4

Inter-Frequency/Inter-RAT Handover Threshold

The UE can be handed over to the inter-RAT/frequency neighbor cells when the
measured value of the signals from these cells is higher than the threshold. This
parameter can be set combining the start threshold of the compressed mode. If this
parameter is configured with a little value, then the handover can be triggered early. If
this parameter is configured with a large value, then the handover will be prolonged.

3.4.2 Timer and Counter Related with Call Drop

The following table lists the timer and counter related to the UE.
Table 3 Timer and counter related to the UE
Name

Description

Value Range

Default
Value

T312

T312 in connected mode, and indicates the

Connected

time that UE waits from the synchronization

(1..15)s

1s

indicator from L1 when it starts to establish

the DPCCH.
N312

T312 in connected mode, and indicates the

(1, 2, 4, 10, 20, 50,

Connected

number of synchronization indicator that the

100, 200, 400, 600,

UE received from L1 before the DPCCH is

800, 1000)

established.
T313

Indicates the waiting time of the UE in

(0..15)s

3s

Indicates the number of maximum number of

(1, 2, 4, 10, 20, 50,

20

out of sync indicators that the UE receives

100, 200)

CELL_DCH state after the DPCCH channel is

established.
N313

from L1.
T314

Start: When the criteria for radio link failure

(0, 2, 4, 6, 8, 12, 16,

are fulfilled. The timer is started if radio

20)s

4s

bearer(s) that are associated with T314 exist or

if only RRC connection exists only to the CS
domain.
T315

Start: When the criteria for radio link failure

(0,10, 30, 60, 180,

are fulfilled. The timer is started if radio

600, 1200, 1800)s

30s

bearer(s) that are associated with T314 exist or

if only RRC connection exists only to the CS
domain.
N315

Indicates

the

maximum

number

of

(1, 2, 4, 10, 20, 50,

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

24

Internal
synchronization
T309

indicators

that

the

UE

100, 200, 400, 600,

received from L1 after T313 is activated.

800, 1000)

Indicates the waiting time of the UE after

(1..8)s

3s

sends the inter-RAT handover requests.

This document contains proprietary information of ZTE Corporation and is not to be disclosed or used
except in accordance with applicable agreements.

25