Umts Cs Call Drop Analysis: PDF Created With Pdffactory Pro Trial Version

UMTS CS Call Drop Analysis
ZTE CORPORATION
ZTE Plaza, Keji Road South,
Hi-Tech Industrial Park,
Nanshan District, Shenzhen,
P. R. China
518057
Tel: (86) 755 26771900 800-9830-9830
Fax: (86) 755 26772236
URL: http://support.zte.com.cn
E-mail: doc@zte.com.cn
PDF created with pdfFactory Pro trial version www.pdffactory.com

Contents
Chapter 1.........................................................................1
Introduction ....................................................................1
Chapter 2.........................................................................3
Definition.........................................................................3
Definition of Call Drop from Drive Test Aspect ..................... 3
Definition of Call Drop at OMC Side .................................... 3
Chapter 3.........................................................................5
Call Drop Analysis............................................................5

Call Drop Reasons............................................................ 5
Call Drops Caused by Poor Coverage .......................................5
Call Drop Caused by Neighbor Cells.........................................6
Call Drop Caused by Interference ...........................................7
Call Failure Caused by Two Cells Using the Same PSC ................8
Call Drops Caused by Engineering Causes .............................. 10
Call Drops Caused by 2G/3G Interoperability .......................... 12
Call Drops Caused by the System ......................................... 13
Analyzing Call Drops by DT ............................................. 13
Analyzing Call Drops by Traffic Statistics........................... 15
Procedure of KPI Analysis.................................................... 16
Basic Methods to Analyze KPIs ............................................. 17
KPI Analysis Tools.............................................................. 18
Radio Parameters Involved During Optimization ................ 20
Radio Parameters Related with CS Call Drops ......................... 20
Timer and Counter Related with Call Drop .............................. 22

Chapter 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.
Confidential and Proprietary Information of ZTE CORPORATION 1

Chapter 2
Definition
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:
n The UE receives any BCH information (system information).
n The call is released for Not Normal and the UE receives the
RRC Release information.
n 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.
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:
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.

Chapter 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.
Call Drop Reasons

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.
T ABLE 1 R S C P AN D E C /IO T H R E S H O L D F O R D I F F E R ENT S E R V I C E S
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.
For the coverage optimization method, see the WCDMA Radio
Network Optimization Guide.
Call Drop Caused by Neighbor Cells

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.
n 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.
n 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.
n 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.
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.
Untimely update of the external cell information
Check the external cells of the RNC periodically, and ensure the
cells in the list are correct.

Chapter 3 Call Drop Analysis
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.
n Overshooting of sites at a high location
n NodeBs in ring-shaped distribution
n 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 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.
Call Failure Caused by Two Cells

Using the Same PSC
Scenario One
FIGURE 1 S C E N A R I O O N E T H AT MA Y C A U S E T H E S A M E P S C P R O B L E M
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 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.

Scenario Two
FIGURE 2 S C E N A R I O T W O T H A T M A Y C A U S E T H E S A ME P S C P R O B L E M
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.
Scenario Three
FIGURE 3 S C E N A R I O T H R E E T H A T M A Y C A U S E T H E S A ME P S C P R O B L E M
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.

Call Drops Caused by Engineering

Causes
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.
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.
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.
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.
Leakage of signals from indoor distribution system
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.
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.

T ABLE 2 C O MMO N E 1 F AU L T S AN D H AN D L I N G SU G G E S T I O N S
Fault Causes Solutions

Lost of E1 The RX end detects 1. Check whether the SA
electrical no line circuit pulse board is secure, and
signals or cannot detect whether the E1 adapter is
logic 1 within slack.
continuous periods, 2. Check whether the pins
then the LOS alarm of the adapter are
is reported. This damaged.
alarm is generally
3. Check whether the joint
caused by the RX
connector of the E1 cable is
fault of the E1/T1 or
damaged, and whether the
broken lines, then
joint connector is securely
the E1/T1 cannot
connected with the E1
detect the signals
cable.
from the remote end.
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 It indicates the 1. The TX line is faulty or
reception E1/T1 remote alarm. broken. Check whether the
failure of the This alarm indicates TX line is correctly
E1 the abnormal connected. For details, see
receptions at the the Handling suggestions
remote end. The for the LOS Alarm.
remote end inserts 2. Check whether the frame
the RAI indicator bit structures of the E1 frame
to the signals and at the local end and remote
then sends it to the match. The E1 frame at
local end, and the both ends must both work
local end reports the at dual-frame or
alarm after detecting multi-frame mode.
the alarm. The
3. Check for error codes at
remote reception
the TX line.
error is reported.
E1 frame out The first bit of slot 0 1. Whether E1 and T1 work
of sync of both E1 and T1 at the same state.
carries the 2. Check whether E1 frames
synchronous clock are of the same modes
signals, which inform (dual-frame/multi-frame).
the RX end of the
3. Check whether the
start of one frame. If
impedance modes of E1/T1
the RX ends of the
matches.
E1 and T1 are out of
sync, then data 4. Check for interferences
frames would be lost from digital devices around
and the LOF alarm is E1/T1.
reported. 5. Check whether the clock
signals are normal.

Fault Causes Solutions

SSCOP link This alarm is caused See the handling
error by that the SSCOP suggestions for E1 faults.
signaling link is
unsuccessfully
established or 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 See the handling
non-operating is successfully suggestions for E1 faults.
mode configured, if IMA
remains in
non-operating mode
for over 1s, then this
alarm is reported.
Currently, some sites are configured with IP transmission.

Therefore, the alarm of "Lack Ethernet electrical signals" also
should be handled on site.
Call Drops Caused by 2G/3G

Interoperability
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.
Parameters must be refined based on different scenarios.
To improve 3G->2G handover success rate, the parameters
must be detailed planned based on different scenarios.
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.
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.

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.
Analyzing Call Drops by DT

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

FIGURE 4 F L O W C H A R T T O T E S T C A L L D R O P S B Y DT
Call drop data

The call drop data refers to the CNT test data and RNC signaling
tracing data.
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.
Stability of the primary serving cell
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.
RSCP and Ec/Io of the primary serving cell
Check the RSCP and Ec/Io of the optimal cell, and then
n When the RSCP is bad, the coverage is poor.

n When the RSCP is normal, while the Ec/Io is bad, pilot

pollution or DL interference exists.
n 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.
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.
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 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.

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.
FIGURE 5 FLOW CHART FOR T OP CELL SELECTION

Basic Methods to Analyze KPIs

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.
Collecting UE log, RNC signaling, KPI data, alarms, abnormal
probes, and packet captured at the Iub interface
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 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.
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:
n Alarms
n Frequently added or removed common transport channels
n UL & DL power
n Radio link restore
n Balance level between two antennas
n 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:
n UL interferences
n Insufficient cell radius or overshooting
n Reuse of the same PSC
n Abnormal UL RF channel

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

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

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

Radio Parameters Involved

During Optimization
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.
For the adjustment of the related parameters, a whole new set
of parameters must be assigned to the target cell.
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⋅ LogMOld + CIOOld ≤ W ⋅10 ⋅ Log  ∑Mi  + (1−W) ⋅10 ⋅ LogMBest − (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.
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.
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.
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.
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.
Timer and Counter Related with Call

Drop
The following table lists the timer and counter related to the UE.

T ABLE 3 T I ME R A N D C O U N T E R R E L AT E D T O T H E UE
Value Default
Name Description
Range Value
T312 T312 in connected mode, (1..15)s 1s
Connected and indicates the time that
UE waits from the
synchronization indicator
from L1 when it starts to
establish the DPCCH.
N312 T312 in connected mode, (1, 2, 4, 10, 1
Connected and indicates the number of 20, 50, 100,
synchronization indicator 200, 400,
that the UE received from L1 600, 800,
before the DPCCH is 1000)
established.
T313 Indicates the waiting time of (0..15)s 3s
the UE in CELL_DCH state
after the DPCCH channel is
established.
N313 Indicates the number of (1, 2, 4, 10, 20
maximum number of out of 20, 50, 100,
sync indicators that the UE 200)
receives from L1.
T314 Start: When the criteria for (0, 2, 4, 6, 8, 4s
radio link failure are fulfilled. 12, 16, 20)s
The timer is started if radio
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 (0,10, 30, 30s
radio link failure are fulfilled. 60, 180, 600,
The timer is started if radio 1200, 1800)s
bearer(s) that are
associated with T314 exist
or if only RRC connection
exists only to the CS
domain.
N315 Indicates the maximum (1, 2, 4, 10, 1
number of synchronization 20, 50, 100,
indicators that the UE 200, 400,
received from L1 after T313 600, 800,
is activated. 1000)
T309 Indicates the waiting time of (1..8)s 3s
the UE after sends the
inter-RAT handover
requests.

Umts Cs Call Drop Analysis: PDF Created With Pdffactory Pro Trial Version

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Umts Cs Call Drop Analysis: PDF Created With Pdffactory Pro Trial Version

Uploaded by

Copyright:

Available Formats

UMTS CS Call Drop Analysis

PDF created with pdfFactory Pro trial version www.pdffactory.com

Call Drop Analysis............................................................5

PDF created with pdfFactory Pro trial version www.pdffactory.com

This document is compiled to guide the network optimization

Confidential and Proprietary Information of ZTE CORPORATION 1

PDF created with pdfFactory Pro trial version www.pdffactory.com

Definition of Call Drop from

Definition of Call Drop at

Confidential and Proprietary Information of ZTE CORPORATION 3

PDF created with pdfFactory Pro trial version www.pdffactory.com

Confidential and Proprietary Information of ZTE CORPORATION 4

PDF created with pdfFactory Pro trial version www.pdffactory.com

Call Drop Analysis

Call Drop Reasons

T ABLE 1 R S C P AN D E C /IO T H R E S H O L D F O R D I F F E R ENT S E R V I C E S

Service Type RSCP [dBm] Ec/Io [dB]

The coverage condition at the UL and DL of the network can be

Confidential and Proprietary Information of ZTE CORPORATION 5

PDF created with pdfFactory Pro trial version www.pdffactory.com

If the UL TX power before the call drop has reached the

Call Drop Caused by Neighbor Cells

Confidential and Proprietary Information of ZTE CORPORATION 6

PDF created with pdfFactory Pro trial version www.pdffactory.com

Call Drop Caused by Interference

Confidential and Proprietary Information of ZTE CORPORATION 7

PDF created with pdfFactory Pro trial version www.pdffactory.com

insist. Thus, in actual analysis, this method can be used to

Call Failure Caused by Two Cells

Confidential and Proprietary Information of ZTE CORPORATION 8

PDF created with pdfFactory Pro trial version www.pdffactory.com

Confidential and Proprietary Information of ZTE CORPORATION 9

PDF created with pdfFactory Pro trial version www.pdffactory.com

Call Drops Caused by Engineering

Confidential and Proprietary Information of ZTE CORPORATION 10

PDF created with pdfFactory Pro trial version www.pdffactory.com

Fault Causes Solutions

Confidential and Proprietary Information of ZTE CORPORATION 11

PDF created with pdfFactory Pro trial version www.pdffactory.com

Fault Causes Solutions

Currently, some sites are configured with IP transmission.

Call Drops Caused by 2G/3G

Confidential and Proprietary Information of ZTE CORPORATION 12

PDF created with pdfFactory Pro trial version www.pdffactory.com

Call Drops Caused by the System

Analyzing Call Drops by DT

Confidential and Proprietary Information of ZTE CORPORATION 13

PDF created with pdfFactory Pro trial version www.pdffactory.com

Call drop data

Confidential and Proprietary Information of ZTE CORPORATION 14

PDF created with pdfFactory Pro trial version www.pdffactory.com

n When the RSCP is normal, while the Ec/Io is bad, pilot

Analyzing Call Drops by

Confidential and Proprietary Information of ZTE CORPORATION 15

PDF created with pdfFactory Pro trial version www.pdffactory.com

Procedure of KPI Analysis

FIGURE 5 FLOW CHART FOR T OP CELL SELECTION

Confidential and Proprietary Information of ZTE CORPORATION 16

PDF created with pdfFactory Pro trial version www.pdffactory.com

Basic Methods to Analyze KPIs

To locate the problem, you have collect data from many

Health Check of Sites

Confidential and Proprietary Information of ZTE CORPORATION 17