UMTS Call Drop Impact Factors Troubleshooting Methods and Tools Deliverables V4.0

Security Level: INTERNAL
UMTS Call Drop: Impact

Factors+Troubleshooting
Methods and Tools+Deliverables
Prepared by: UMTS Maintenance Dept. and UMTS
Design Dept.
Reviewed by: Qi Haofeng (employee ID: 00118729)
2015-12-15 www.huawei.com
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential

Abstract
This topic describes the following information:
Main factors that affect the call drop rate of UMTS Circuit service and Packet service (KPI)
16 required actions of troubleshooting call drops
How to determine top cells based on call drop rate difference and analyze call drops based on
call history records (CHRs) to eliminate the main factors that affect the UMTS call drop rate
Deliverables that field engineer need to provide when reporting dropped call problems. The
deliverables include the conclusions of determining top cells based on call drop rate difference
and analyzing call drops based on CHRs.
This topic contains typical cases, showing the importance and necessity of implementing
dropped-call analysis actions and the implementation effects. The main causes of call drops
are classified into parameter problems, neighboring cell problems, interference problems, and
capacity problems. If the 16 required actions are performed (not all the 16 actions are
performed because each action has prerequisites), call drops still persist. In this case, you are
advised to submit call drops to R&D engineer.
Change History
Date Version Description Reviewer Author

Qi Haofeng (employee ID: 00118729)
Tang Yuanxian (employee ID: 00160434)
Cui Chengxiao (employee ID: 00239678) Qian Jin
Gong Jie (employee ID: 00162126) (employee ID:
Yang Bangquan (employee ID: 64231)
00110068) Xu Jing
Zhu Peng (employee ID: 58079) (employee ID:
Zhou Yang (employee ID: 00145062) 56391)
Liu Yingchun (employee ID: 61348) Zheng
2013-02-13 V2.0 Completed the draft.
Xia Da (employee ID: 00148872) Jianhua
Liu Ming (employee ID: 00141061) (employee ID:
Fan Jingchang (employee ID: 00142681) 42104)
Hu Wensu (employee ID: 00129579) Huang
Yang Cheng (employee ID: 00136533) Xiangrong
Guo Jia (employee ID: 00178263) (employee ID:
Xue Wei (employee ID: 00138314) 00137761)
Chen Jian (employee ID:00202821)
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 3

R&D Support
On the topic of call drops, Huawei provides training and 7 x 24 hours
technical support.
The following table lists information about R&D support personnel.
Name Telephone Number

Xu Jing (employee ID: 56391) See Huawei phone book.
Qian Jin (employee ID: 64231) See Huawei phone book.
Zheng Jianhua (employee ID: 42104) See Huawei phone book.
Huang Xiangrong (employee ID: 00137761) See Huawei phone book.

Overview of Call Drops
Cause Analysis of Call Drops and Data Source Processing
Standard Analysis Actions and Deliverables for Call Drops
Cases Related to Call Drops

Statistics on Call Drops (1)
A call drops means that a call ends abnormally and subscriber services are terminated because radio
network controllers (RNCs) or user equipment (UE) releases service channels.
Statistics on call drops
1. When an RNC detects an exception (a signaling radio bearer [SRB] reset, a performance radio bearer
[TRB] reset, a failure of radio link synchronization, timeout of the air-interface process, or preemption, or
Iu GTPU loss), the RNC sends an RAB RELEASE REQUEST message to the core network (CN) to
request RAB release, or sends an IU RELEASE REQUEST message to request connection release at
the Iu interface. When the RNC initiates such abnormal release, it counts the number of call drops
based on specific causes.
UE NodeB RNC MSC

Case 1: RL failure
Case 3: Iu error
Case 2: RLC reset, Uu no reply

Rab/IU Release Req
Rab/IU Release Command
Rab/IU Release Complete
Measurement point

2. The RNC does not consider call releases initiated by the CN are as call drops by default by using a switch. This case
needs to be considered when VIP subscribers complain about call drops.
The CALL_DROP_DEFINITION parameter is introduced in R10 and is invisible in later versions. It is set to 1 by default.
Cause Value of Cause Value of Turning Off the Switch: Turning On the Switch:
Releases Initiated by Releases Initiated by SET URRINNERTIMER: SET URRINNERTIMER:
the RNC the CN CALL_DROP_DEFINITION-0 CALL_DROP_DEFINITION-1
Normal Normal No No
Normal Abnormal No No
Abnormal Normal No No
Abnormal Abnormal Yes Yes
No release initiated Normal No No
No release initiated Abnormal Yes No
Normal No release initiated No No
Abnormal No release initiated Yes Yes
UE NodeB RNC CN

RAB/Iu Release
Command (Abnormal)
RAB/Iu Release Complete
The RNC does not consider
call releases initiated by the
CN as call drops by default.

CS or PS abnormal call releases initiated by the RNC are considered call drops when
CS_CALL_DROP_DEFINITION or PS_CALL_DROP_DEFINITION is set to 1.
CS_CALL_DRO Cause Value Cause Value Normal or PS_CALL_ Cause Cause Normal or
P_DEFINITION of Releases of Releases Abnormal DROP_DE Value of Value of Abnormal
Initiated by Initiated by Release FINITION Releases Releases Release
the RNC the CN Initiated by Initiated by
the RNC the CN
ON - Normal Normal ON - Normal Normal

ON - Abnormal Abnormal ON - Abnormal Abnormal
ON Normal Normal Normal ON Normal Normal Normal
ON Normal Abnormal Normal ON Normal Abnormal Normal
ON Abnormal Normal Abnormal ON Abnormal Normal Abnormal
ON Abnormal Abnormal Abnormal ON Abnormal Abnormal Abnormal

OFF - Normal Normal OFF - Normal Normal
OFF - Abnormal Abnormal OFF - Abnormal Abnormal
OFF Normal Normal Normal OFF Normal Normal Normal
OFF Normal Abnormal Normal OFF Normal Abnormal Normal
OFF Abnormal Normal Normal OFF Abnormal Normal Normal
OFF Abnormal Abnormal Abnormal OFF Abnormal Abnormal Abnormal

The formula for calculating the CS call drop rate is as follows:
[VS.RAB.AbnormRel.AMR/(VS.RAB.AbnormRel.AMR + VS.RAB.NormRel.AMR)] x 100%
The formula for calculating the PS call drop rate is as follows:

With the development of smartphones, CELL_PCH state relocation is enabled at more and
more sites to make smartphones online as much as possible. When CELL_PCH state
relocation is enabled, the UE is usually in CELL_PCH mode, reducing the possibility that
PS services are normally released. At the same time, when the UE is in CELL_PCH mode,
the user considers that PS services are normally released. Therefore, when CELL_PCH
state relocation is enabled, Huawei recommends that call releases in PCH mode be
excluded. The formula for calculating the PS call drop rate is as follows:
[(VS.RAB.AbnormRel.PS - VS.RAB.AbnormRel.PS.PCH - VS.RAB.AbnormRel.PS.D2P -
VS.RAB.AbnormRel.PS.F2P)/(VS.RAB.AbnormRel.PS + VS.RAB.NormRel.PS -
VS.RAB.AbnormRel.PS.PCH - VS.RAB.NormRel.PS.PCH + VS.DCCC.D2P.Succ + VS.DCCC.Succ.F2P)]
x 100%
If PCH is enabled on the original network after swapping, Huawei also recommends that
call releases in PCH mode be excluded from the formula mapping of the PS call drop rate.
For details, see the KPI mapping table for the swapping SOP.
Call releases in PCH mode are excluded from the formula for calculating the PS call drop rate. In this way, more methods are
available for improving the PS call drop rate and it is possible to reduce call drops by using state relocation parameters.

Classification of Call Drops Based on KPIs
RNCs collect statistics by type based on different causes of call drops, which facilitates
identification of dropped call types and problem locating.
The causes of call drops can be divided into radio frequency (RF) causes and non-RF
causes. For the experience of commercial networks, RF causes are the main causes of call
drops and the key point of optimization. call drops resulting from non-RF causes account
for a small percentage (less than 5%).
The following table lists related information about CS call drops.
Call Drop
Counter Trigger Cause
Cause
VS.RAB.AbnormRel.CS.RF.SRBReset Signaling transmission failure and SRB RLC reset
Timeout of the timers for the SHO, HHO, and RB
VS.RAB.AbnormRel.CS.RF.UuNoReply
RECFG air-interface processes
RF VS.RAB.AbnormRel.CS.RF.ULSync Failure of all radio links of the active set
problems VS.RAB.AbnormRel.CS.RF -
(VS.RAB.AbnormRel.CS.RF.SRBReset
Process overlapping and non-support of processes
+ VS.RAB.AbnormRel.CS.RF.ULSync
+ VS.RAB.AbnormRel.CS.RF.ULSync)
AAL2 setup failure due to transmission on the Iu
VS.RAB.AbnormRel.CS.IuAAL2
interface
VS.RAB.AbnormRel.CS.OLC Cell overload
Cell unavailability caused by digital signal
Non-RF
VS.RAB.AbnormRel.CS.UTRANgen processing (DSP) faults or packet loss due to high
problems
CPU load
VS.RAB.AbnormRel.CS.OM OM forced release (cell blocking)
VS.RAB.AbnormRel.CS.Preempt Release caused by preemption
VS.RAB.AbnormRel.CS - all the preceding counters Abnormal call drops resulting from other causes

According to the causes of PS call drops, call drops can be classified into RF and non-RF
call drops. Based on commercial networks experience, RF problems are the main cause for
call drops and are the focus of optimization. Call drops due to non-RF problems occupy
less than 5%. The following table lists related information about PS call drops.
Call Drop
Related Counter Usual Trigger Cause
Type
VS.RAB.AbnormRel.PS.RF.SRBReset Signaling fails to be sent and SRB RLC is reset.
Air interface process timers, such as SHO, HHO, and RB
VS.RAB.AbnormRel.PS.RF.UuNoReply
RECFG, time out.
Data on the user plane fails to be sent and TRB RLC is
VS.RAB.AbnormRel.PS.RF.TRBReset
reset.
Synchronization failures occur on all radio links in the
RF problems VS.RAB.AbnormRel.PS.RF.ULSync
active set.
VS.RAB.AbnormRel.PS.RF -
(VS.RAB.AbnormRel.PS.RF.SRBReset + Call drops occur due to process overlap and process
VS.RAB.AbnormRel.PS.RF.ULSync + unsupported, such as RL failure after RB Reconfigure,
VS.RAB.AbnormRel.PS.RF.ULSync + Physical channel reconfigure.
VS.RAB.AbnormRel.PS.RF.TRBReset)
GTPU exceptions at the Iu interface result in RAB
VS.RAB.AbnormRel.PS. GTPULoss
releases.
VS.RAB.AbnormRel.PS.OLC Cell overload
Non-RF VS.RAB.AbnormRel.PS.OM The OM is forcibly released (due to cell blocking).
problems VS.RAB.AbnormRel.PS.Preempt Releases due to preemption
Call drops occur due to other causes, such as FP
VS.RAB.AbnormRel.PS - all preceding KPIs synchronization failures, common channel congestion
during cell updates .

The RNC performs statistics based on channels carrying PS services,
which helps identify call drop types and locate call drop causes.
According to the channel types, there are two channels: DCH and
CCH. For details, see the following table.
Channel Type of
Related Formula
Call Drops
VS.RAB.AbnormRel.PS - VS.RAB.AbnormRel.PS.CCH-
DCH
VS.RAB.AbnormRel.PS.D2P
VS.RAB.AbnormRel.PS.CCH - VS.RAB.AbnormRel.PS.PCH-
CCH
VS.RAB.AbnormRel.PS.F2P
PS call drops on the DCH may be caused by incremental HSPA call

drops. Related counters are as follows: VS.HSDPA.RAB.AbnormRel
and VS.HSUPA.RAB.AbnormRel

Call Drop Formula Mapping
Formulas for calculating the call drop rate on swapped networks must be correctly mapped between peer vendors
and Huawei. For details, see swapping deliverables (KPI Mapping Table). The formula for calculating the NSN CS
call drop rate is used as an example. The following table lists the formula for calculating the NSN call drop rate
recommended by Huawei and Huawei mapping formula, and describes differences between the two vendors.
Analysis on Comparison of KPIs Huawei Mapping KPI Formula
NSN KPI KPI Formula_NSN (RU20 KPI Reference) Recommended Modified the NSN Formula
Between NSN and Huawei (R12)
100 100 x Sum([RAB_ACT_REL_CS_VOICE_P_EMP] 100 100 x Sum([RAB_ACT_REL_CS_VOICE_P_EMP] +
+ [RAB_ACT_FAIL_CS_VOICE_IU] + [RAB_ACT_FAIL_CS_VOICE_IU] +
[RAB_ACT_FAIL_CS_VOICE_RADIO] + NSN call drops are not completely [RAB_ACT_FAIL_CS_VOICE_RADIO] +
[RAB_ACT_FAIL_CS_VOICE_BTS] + counted. Huawei counts [RAB_ACT_FAIL_CS_VOICE_BTS] +
[RAB_ACT_FAIL_CS_VOICE_IUR] + RAB_ACT_REL_CS_V_UNSPE_ER_CN [RAB_ACT_FAIL_CS_VOICE_IUR] +
[RAB_ACT_FAIL_CS_VOICE_RNC] + for calculating releases over the Iu [RAB_ACT_FAIL_CS_VOICE_RNC] +
[RAB_ACT_FAIL_CS_VOICE_UE] + interface on the RAN side. It is [RAB_ACT_FAIL_CS_VOICE_UE] +
[RAB_ACT_FAIL_CS_VOICE_TRANS])/Sum([RAB_AC recommended that [RAB_ACT_FAIL_CS_VOICE_TRANS] +
T_COMP_CS_VOICE] + RAB_ACT_REL_CS_V_UNSPE_ER_CN [RAB_ACT_REL_CS_V_UNSPE_ER_CN])/Sum([RAB_ACT_
RAB Success 1
[RAB_ACT_REL_CS_VOICE_SRNC] + be added to the denominator in the NSN COMP_CS_VOICE] + [RAB_ACT_REL_CS_VOICE_SRNC]
Ratio, Voice (CSR) [VS.RAB.AbnormRel.AMR/(VS.R
[RAB_ACT_REL_CS_VOICE_P_EMP] + KPI formula. In addition, in NSNRU20 + [RAB_ACT_REL_CS_VOICE_P_EMP] +
(1-Voic call drop AB.AbnormRel.AMR +
[RAB_ACT_REL_CS_VOICE_HHO] + Performance Statistics help documents, [RAB_ACT_REL_CS_VOICE_HHO] +
rate) VS.RAB.NormRel.AMR)] x 100%
[RAB_ACT_REL_CS_VOICE_ISHO] + RAB_ACT_COMP_CS_VOICE includes [RAB_ACT_REL_CS_VOICE_ISHO] +
[RAB_ACT_REL_CS_VOICE_GANHO] + RAB_ACT_REL_CS_V_UNSPE_ER_CN. [RAB_ACT_REL_CS_VOICE_GANHO] +
[RAB_ACT_FAIL_CS_VOICE_IU] + Note: In RU10 NSN Performance [RAB_ACT_FAIL_CS_VOICE_IU] +
[RAB_ACT_FAIL_CS_VOICE_RADIO] + Statistics help documents, the [RAB_ACT_FAIL_CS_VOICE_RADIO] +
[RAB_ACT_FAIL_CS_VOICE_BTS] + relationships between [RAB_ACT_FAIL_CS_VOICE_BTS] +
[RAB_ACT_FAIL_CS_VOICE_IUR] + RAB_ACT_COMP_CS_VOICE and [RAB_ACT_FAIL_CS_VOICE_IUR] +
[RAB_ACT_FAIL_CS_VOICE_RNC] + RAB_ACT_REL_CS_V_UNSPE_ER_CN. [RAB_ACT_FAIL_CS_VOICE_RNC] +
[RAB_ACT_FAIL_CS_VOICE_UE] + [RAB_ACT_FAIL_CS_VOICE_UE] +
[RAB_ACT_FAIL_CS_VOICE_TRANS]) [RAB_ACT_FAIL_CS_VOICE_TRANS])
If the mapping formula used field is different from the recommended formula, try to use the recommended formula.
Some projects may meet difficulties from customers and acceptance formulas may fail to modified. In this case, you are
advised to turn to PSEs or R&D engineer.
Analysis on mapping differences between most call drop rate formulas is archived in swapping SOP deliverables, which helps
field engineer communicate with customers and modify formulas. If related information is not contained in swapping SOP
deliverables, turn to SOP R&D engineer over PSEs. Then the SOP R&D engineer needs to provide a solution.

Identifying Call Drop Causes Based on CHRs
You can determine an increase in the call drop rate based on the percentages of various
types of call drops, and perform troubleshooting based on different causes of call drops.
For details about the causes of call drops, see Classification of Call Drop Causes Based
on CHRs. Classification of the causes of CS
Note: This color indicates
dropped calls related to
dropped calls based on CHRs composite services.
Dropped calls related to a single service/composite services
Inter-frequency/inter-
Dropped calls resulting from

Related to abnormal
Non-configuration of
timeout of PS waiting for IU
the RB_SET UP process of

Related to NodeBs
Related to the Iub
RAT/compressed
Related to the Iur
neighboring cells
Related to RANs
Related to the Iu
SRB reset in safe mode
the RB_REL process of

Weak coverage
Radio resource
Related to CNs
Pilot pollution
Large RTWP
Delayed soft
composite services
composite services
congestion
handovers
REL COM MAND

interface
interface
interface
mode
UEs
Interface class Equipment class Basic RF class Networking

Resource
class
class
Dropped calls resulting from the

RB_RECFG process
Dropped calls resulting from the

PH_CH_RECFG process
(serving cell change)
Others

Analyzing Causes of CHR PS Call Drops
Based on the proportion of call drops with various causes, preliminarily
check whether call drops occur due to a specific cause. Troubleshoot
various causes. For details, see Classification of Call Drop Causes
Based on CHRs. Classifying PS CHR call
drop causes
Note: This color specifies
call drops of combined
services.
Single/combined service
of combined services
Inter-frequency/Inter-
mode-related causes
SRB reset in security
process of combined
system/Compressed
RB_SETUP process
RAN-related causes
Iub interface-related
Iur interface-related
Abnormal RB_REL
Iu interface-related
CN-related causes
neighboring cells
configurations of
Weak coverage
Radio resource-
related causes
Abnormal UEs
NodeB-related
Pilot pollution
Delayed soft
High RTWP
handovers
Abnormal
services
Missing
causes
causes
causes
causes
mode
Resources Interfaces Devices Basic RF Network
RB_RECFG process call

drops (DCCC)
PH_CH_RECFG process
call drops
(serving cell changes
Radio link
synchronization failure
Others

Example Percentages of the Typical Causes
of call drops (Based on Performance
Statistics)
According to Performance Statistics, the distribution of various types of CS call drops is as follows:
The percentage of call drops resulting from RF causes is about 95%, whereas the percentages of
other types of call drops are small. This is the typical case for networks. When the percentage of
call drops resulting from non-RF causes is large, check hardware and alarms.
RF causes mainly include SRB reset, uplink failures, and no reply on the Uu interface. The
relationship of the percentages of call drops resulting from the three main causes is related to the
configurations of the SRB reset timer, uplink failure timer, and process timeout timer on the
network. Configuration difference results in large percentage difference (depending on which
timer expires first).
RF Problem Non-RF Problem
Link Re- VS.CS.Call. VS.RAB.Abn VS.RAB.Ab
Office Scenario establishme Drop.Cell.R VS.RAB.Abnorm VS.RAB.Abnor ormRel.CS. VS.RAB.Lo VS.RAB.Ab VS.RAB.Ab normRel.C VS.RAB.Ab VS.RAB.Ab VS.Call.Dro
nt ate Rel.CS.RF.SRBR mRel.CS.RF.UL ss.CS.RF.O normRel.C normRel.C normRel.C normRel.C
RF.UuNoRe S.UTRANg p.CS.Other
eset Sync th S.OM S.Preempt S.IuAAL2 S.OLC
ply en
Optus refarming U900
U900 carriers Enabled 0.74% 0.3% 29.2% 49.8% 18.8% 0.0% 0.0% 0.0% 0.0% 0.0% 1.8%
in Australia
Optus refarming U900
U2100 carriers Enabled 0.35% 0.1% 20.6% 55.9% 17.2% 0.0% 0.0% 1.1% 0.1% 0.0% 4.9%
in Australia
Optus refarming U900 U2100+U900
Enabled 0.42% 0.2% 23.4% 53.9% 17.7% 0.0% 0.0% 0.8% 0.1% 0.0% 3.9%
in Australia carriers
Data collected by P4 in
the suburban areas of U2100+U900
Enabled 0.48% 0.1% 4.0% 82.4% 9.3% 0.0% 0.0% 0.0% 0.0% 0.0% 4.2%
Poland (U900 [3.8 carriers
Mbit/s], U2100)
P4 U900 in Poland U900 carriers Enabled 2.10% 0.0% 3.6% 78.7% 12.1% 0.0% 0.0% 0.3% 0.0% 0.0% 5.4%
P4 U2100 in Poland U2100 carriers Enabled 0.34% 0.2% 3.3% 82.8% 8.0% 0.1% 0.0% 0.3% 0.0% 0.0% 5.2%
Maxis in Malaysia U2100 Disabled 0.47% 67.0% 16.7% 13.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 3.4%
StartHub in Singapore
U2100 Disabled 0.33% 0.3% 5.9% 57.3% 28.5% 0.0% 0.0% 0.2% 0.1% 0.0% 7.7%
(2011-07)

Example Proportion of Typical Causes of
Call Drops (Performance Statistics)
According to PS Performance Statistics, distribution of various call drops is as follows:
Call drops caused by RF problems takes about 95% and call drops due to other causes
takes a low percentage. This proportion is normal. If call drops causes by non-RF problems
takes a high percentage, check hardware and alarms.
RF problems including SRB resets, UL synchronization failures, and Uunoreply, which are
related to configurations of the SRB resetting timer, UL synchronization failure timer, and
process timeout timer on the wireless side.
RF Problem (VS.RAB.AbnormRel.PS.RF) Non-RF Problem
Link Re- VS.PS.Cal VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A
Site Scenario establish l.Drop.Cel bnormRel bnormRel bnormRel bnormRel VS.RAB.L VS.RAB.A bnormRel bnormRel VS.RAB.A bnormRel
ment l.Rate .PS.RF.S .PS.RF.T .PS.RF.U .PS.RF.U oss.PS.R bnormRel .PS.Pree .PS.GTPU bnormRel .PS.Other
F.Other .PS.OM .PS.OLC
RBReset RBReset LSync uNoReply mpt Loss
SFR in
U2100 OPEN 2.61% 1.5% 0.5% 3.8% 53.6% 25.6% 0.0% 0.0% 2.2% 0.0% 12.8%
France
SFR in
U900 OPEN 10.60% 0.5% 1.2% 5.5% 52.9% 32.6% 0.0% 0.0% 0.3% 0.0% 6.9%
France
O2 in
U2100 OPEN 3.40% 1.2% 26.9% 6.0% 27.1% 11.3% 0.0% 0.1% 0.0% 0.0% 27.3%
Germany
Vodafone
U2100 OPEN 1.89% 2.2% 24.8% 2.3% 41.5% 19.3% 0.0% 0.0% 0.3% 0.0% 9.7%
in Spain
Vodafone
U900 OPEN 4.58% 1.0% 36.8% 3.5% 39.2% 13.6% 0.0% 0.0% 0.0% 0.0% 5.9%
in Spain

Example Percentages of the Typical
Causes of CS call drops (Based on CHRs)
According to CHRs, the distribution of various types of CS call drops is as follows:
Australia is used as an example (link re-establishment enabled and refarming U900). The
percentage of call drops caused by RTWP is 18% for the U900, whereas that for the U2100 is
3%. The percentage of circuit switched (CS) call drops caused by PS_RB_REL is about 16% for
combined services.
The impact of the RTWP on call drops for the U900 is greater than that for the U2100.
Comparison of the following data is for your reference.
0.98% Causes of dropped calls for the Causes of dropped calls for the
4.31% U2100, on November 5, 2012
4.90% U900, on November 5, 2012 0.78%
BadCoverage BadCoverage
High_RTWP High_RTWP
16.67% 15.29%
IUR_Related
PH_CH_FAIL
5.49%
3.92% PH_CH_FAIL
RBREL
55.88%
70.20% RBREL
17.65% Startcompressmode_T
imeOut 1.18%
Startcompressmode_TimeO
Pilot_Pollution 2.75% ut
Pilot_Pollution

Sample-Proportion of Typical Causes of Call
Drops (CHR)
According to CHR statistics, distribution of various PS call drops is as follows:
According to NPMaster statistics, CHR call drops are classified into PS call drops in CELL_DCH
mode and PS call drops in CELL_CCH mode. Call drops in CELL_CCH mode contain call drops
in PCH mode that should be filtered out when call drop statistics is performed.
For example, on D2 networks in Germany, 50% of call drops in PS DCH mode are caused
by weak coverage and about 7% caused by inter-frequency/inter-RAT handovers.

Cause Analysis of Call Drops and Data

Source Processing
Troubleshooting Methods and Deliverables

for Top Cells with Call Drops

Procedures of Analyzing call drops Based
on Various Data Sources
Step 1: Determine the scope of call drops. Use Performance Statistics or CHRs to locate
the main scope of call drops to top cells/areas, the entire network, both top cells/areas
and the entire network, top UE types/subscribers, or top subsystems.
Note 1: The analysis method varies with the scenario. In the scenario where the call drop rate deteriorates after
swap or upgrade, compare the difference before and after the deterioration of the call drop rate to analyze the
general scope of the deterioration. In the scenario of inventory optimization (the problem of call drops is always
serious, and the call drop rate must be optimized to reach the target value), you do not need to analyze the
difference before and after a certain period. You only need to analyze the area with a high call drop rate.
Note 2: In addition to using Performance Statistics to analyze the scope of call drops (top cells, the entire network, or
both), use CHRs to analyze the scope of call drops when some UE types or special subscribers cause the call drop
rate to deteriorate.
Note 3: When the call drop rate deteriorates on changed networks (changes occurred on networks, such as swap,
upgrade, and capacity expansion, or 2G/CN swap), compare and assess the change in the numerator and
denominator of the call drop rate, and determine whether the call drop rate increases because of non-mapping of
counters to the original network after swap or because of performance migration (for example, the number of
subscribers in weak 3G coverage increases because the 2G -> 3G handover is enabled).
Step 2: Determine the main cause of call drops based on various data sources.
Step 3: Determine the root cause of call drops and subsequent issue closure actions
based on the checklist of required actions of analyzing call drops.
Note: For details about the required actions of analyzing call drops, see the following section.
Step 4: Perform the issue closure actions and evaluate the result. If the result does not
meet the expectation, repeat the preceding steps to perform analysis again.

General Principle of Analyzing Call Drops:
Analyze Data, Reach a Conclusion, and
Determine the Step to Be Performed
A majority of the basic required actions
are supported by tools. The analysis 1. Identify the scope of call drops.
time is short. For example, the time of
analyzing Performance Statistics, CHRs, 2. Identify the causes of call drops.
neighboring cells, parameters, alarms,
and RF channels is short. 3-1. Perform the required actions of analyzing call
drops, analyze data, and reach a conclusion (or an
intermediate conclusion).
The issue closure actions performed
based on the analysis result depend on 3-2. Formulate a troubleshooting plan and issue
closure actions based on the conclusion.
the speed of field issue closure.
Therefore, determine the primary
4-1. Perform issue closure (primary contradictions
contradictions and secondary first and then secondary contradictions).
contradictions, and focus on completing
issue closure based on the primary No
contradictions. 4-2. Is troubleshooting successful?
Yes
4-3. Prepare a summary report and a case.

Determining the Scope of Call Drops
Principles of Selecting Top Cells, Top UE
Types, and Top Subscribers
The principles of selecting top cells, top UE types, and top subscribers vary with the scenario of
troubleshooting call drops when the scope of call drops is determined.
Scenario 1: trend deterioration scenario, such as the scenario where the call drop rate
deteriorates after upgrade, feature activation, or swap, or the scenario of sudden
deterioration of the call drop rate resulting from an unknown cause
Principle of selecting top cells: Calculate the difference between the call drop rates and
between the number of call drops before and after the specified period (subtract the value after
deterioration by that before deterioration). Obtain the top cells of call drop rate deterioration and
those with an increase in the number of call drops by ranking the values of call drop rate
difference and dropped-call quantity difference in descending order. The principles of selecting
top UE types and top subscribers are similar.
Scenario 2: inventory optimization, network construction, or swap (the cell level counters
of the original network cannot be obtained). Call drop rate is always poor on live networks
(not sudden deterioration), and the call drop rate must be optimized to reach the target
value.
Principle of selecting top cells: Obtain the top cells with the highest call drop rate and those
with the largest number of call drops by ranking the absolute values of the call drop rate and
dropped-call quantity in descending order. The principles of selecting top UE types and top
subscribers are similar.

Determining the Scope of Call Drops Criteria
Top cells: Eliminate the first 20% of top cells with the highest call drop rate and those with the largest number
of call drops. If the call drop rate of the entire network improves or restores to the original value (or reaches the
target value), the scope of call drops can be located to top cells.
The entire network: Eliminate the first 20% of top cells with the highest call drop rate and those with the
largest number of call drops. If the call drop rate of the entire network does not improve, the scope of call drops
can be located to the entire network.
Top cells + entire network: Eliminate the first 20% of top cells with the highest call drop rate and those with
the largest number of call drops. If the call drop rate of the entire network improves but is still higher than the
original value (or the target value), the scope of call drops can be located to both top cells and the entire
network.
Top UE types and top subscribers: Eliminate the first 20% of top UE types or top subscribers. If the call drop
rate of the entire network improves or restores to the original value (or reaches the target value), the scope of
call drops can be located to top UE types or top subscribers.
Top subsystems: A subsystem is considered abnormal when the following conditions are met:
According to Performance Statistics, the call drop rate of the subsystem is higher than 3% every day. (The
access failure rate and call drop rate rarely exceed 3%. Therefore, you can determine that an exception
occurs if the failure rate or call drop exceeds 3%.)
The access times are greater than 10,000 every day.
The call drop rate of each NodeB under the subsystem is higher than the average call drop rate of other
subsystems.
Note: UE compatibility problems often occur during swap. However, comparison and analysis cannot be
performed directly because the original network may not have data similar to CHRs during swap. You can
determine whether UE compatibility problems exist by focusing on subscriber complaints. Therefore, it is
important to analyze subscriber complaints during swap.

Identifying Call Drop Causes
After you determine the scope of call drops, use available data sources to
obtain the basic causes of call drops. The data sources include:
Performance Statistics
CHRs
Signaling (intelligent optimization system [IOS] tracing)
Drive test data

For details, see UMTS maintenance manuals, which are available at
http://support.huawei.com/support/pages/navigation/gotoKBNavi.do?actionFlag=getAllJsonData&mate
rialType=123-2&colID=ROOTWEB|CO0000000064&level=3&itemId=202-00046311&itemId0=29-
7&itemId1=3-337&itemId2=1-553&itemId3=202-
00046311&itemId4=&itemId5=&itemId6=&itemId7=&itemId8=&itemId9=&materialType=123-
2&isHedexDocType=&pageSize=20

Determining the Call Drop Scope and Analyzing
Call Drop Causes by Using the OMStar
OMStar V500R013 can determine the call drop scope and analyze call drop causes by
importing configuration data and performance counters.
Excel containing
analysis on call
drop causes
Excel containing
analysis on call
drop scope

Analyzing Call Drop Causes by Using
Performance Statistics
Performance Statistics helps locate call drop causes: air interface RF
failure and device faults (faults of transmission and O&M devices)
Link Re- VS.CS.Call. VS.RAB.Ab VS.RAB.Ab VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A
VS.RAB.L VS.RAB.A VS.RAB.A VS.Call.Dr
Site Scenario establish Drop.Cell.R normRel.CS normRel.C bnormRel bnormRel bnormRel bnormRel
oss.CS.R bnormRel bnormRel op.CS.Oth
ment ate .RF.SRBRes S.RF.ULSy .CS.RF.Uu .CS.Pree .CS.UTRA .CS.IuAAL
F.Oth .CS.OM .CS.OLC er
et nc NoReply mpt Ngen 2

Link Re- VS.PS.Call. VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A VS.RAB.A
VS.RAB.Abn VS.RAB.L VS.RAB.A VS.RAB.A VS.Call.Dr
Site Scenario establish Drop.Cell.R bnormRel bnormRel bnormRel bnormRel bnormRel
ormRel.PS.R oss.PS.R bnormRel bnormRel op.PS.Oth
ment ate .PS.RF.TR .PS.RF.UL .PS.RF.Uu .PS.Pree .PS.GTPU
F.SRBReset F.Other .PS.OM .PS.OLC er
BReset Sync NoReply mpt Loss
Original Performance Statistics files are not allowed to be uploaded and field engineer need to feed
back results of Performance Statistics analysis. Call drop causes are classified by using the Nastar.
The OMStar-based template for querying KPIs is as follows:
Analysis time: data within one week before and after KPI deterioration (If data within one week after KPI is
unavailable, data of the current day is required.)
Analysis object: cluster and cell
Analysis unit: by hour or day
Purpose: Find the time of KPI deterioration and determine the scope of KPI deterioration.

Analyzing Call Drop Causes by Using CHRs
The CHR records detailed information about each call. Call drop causes can be classified into the following
types by using the CHR: problems of air interfaces (Iub, Iur, and Iu), faults of devices (NodeB, RAN, CN,
and UE), basic RF problems (RTWP, missing neighboring cells, SHO handover delay, pilot pollution), weak
coverage, and combined services, and networking.
CHR analysis (data source processing method): Call drop causes can be automatically classified by
using the NPMaster.
Original CHR logs are not allowed to be uploaded and field engineer need to feed back
results of analysis on CHR call drops.
Analysis time: Perform analysis on CHR call drops and feed back results before and after KPI
deterioration. Related logs must be during the same period on the same day (for example Monday)
before and after KPI deterioration.
Analysis object: entire network or cluster
Operation results:
1. CALLDROPDETAILS.txt
2. CALLDROPMISSINGNEIGHBOR.txt
3. CALLDROPPILOTPOLLUTIONDETAILS.txt
4. CALLDROPSTAT_CS.txt
5. CALLDROPSTAT_PS.txt
6. CallDropStat_CCH.txt

Data Processing Tools and Methods CHRs
For CHR data, use the cell performance analysis function of the Nastar to analyze exceptions and abnormal
release causes. You can use the offline analysis function of the NPMaster to classify the causes of call drops
and identity the main causes. The analysis scope can be CS networks (AMR and VP), packet switched (PS)
networks (R99 PS, HSDPA, and HSUPA), or common transport channels (forward access channels [FACHs]
and paging channels [PCHs]). For the analysis subject, you can define clusters for RNCs.
Note: For details about operation guide, see the NPMaster User Manual.chm in the NPMaster installation
directory.
1. Select an analysis function: CS call drops, PS call drops.
2. Select an analysis subject: Define clusters.

Identifying the Causes of Call Drops Based
on Signaling
Signaling: can be used to analyze the detailed causes of call drops. You can determine the specific causes
of call drops based on signaling flows and measurement reports.
Signaling tracing includes IOS tracing, single-subscriber call detail trace (CDT), and interface tracing. call
drops are often analyzed based on IOS tracing of top cells or single-subscriber CDT.
IOS analysis: The specific cause of call drops is analyzed based on the signaling flow and
message content of each dropped call, as well as the ECN0 and received signal code power (RSCP)
in the measurement report. IOS analysis applies to locating of call drops caused by UE
incompatibility or improper product implementation, or serious call drops in areas adjacent to peer
vendors.
Single-subscriber CDT: can be used to analyze the specific causes of call drops experienced by
some subscribers. Single-subscriber CDT applies to network-side data tracing during drive tests or
to analysis of the complaints of VIP subscribers.
The causes of call drops are analyzed based on both CHRs and signaling because signaling
analysis has strong pertinence.
Analyze CHRs and output the

following information. Analyze IOS data, and
1. Distribution of the causes of determine whether the
call drops patterns of call drops are
Perform IOS tracing or drive
2. Patterns of call drops and consistent with those
tests on top cells.
top cells that require in- indicated by CHRs. If they
depth analysis (signaling are consistent, perform in-
flows and service behavior) depth analysis.

Identifying the Causes of call drops Based
on Drive Test Data
Drive test data has strong pertinence and only contains single-subscriber downlink
information. The causes of call drops are analyzed based on both drive test data and
single-subscriber signaling.
Drive test data has strong limitation. You can perform tests on top cells or areas and
analyze the causes of call drops.
Analysis of call
drops based on
drive test data
Neighboring cell Handover Interference Coverage UE problems

relationship parameters overlap
Missing Invalid handover Interference Coverage Compatibility

neighboring cell parameters, outside networks, overlap because problems
relationship, causing interference of of the geographic triggered by
causing handover delay equipment locations of certain UEs in
handover delay or improper intermodulation, NodeBs or special
Redundant handovers or heavy geographic processes
neighboring cell performance, characteristics
relationship, causing high
causing improper RTWP and poor
handovers uplink quality

Data Processing Tools and Methods Drive
Test Data
You can review and analyze drive test data based on the applied test software. The common tools include
the QXDM and Probe. Information related to drive test data review and analysis is intuitive. You can view
signals, signal-to-noise ratio (SNR), UEs' transmit power, and neighboring cell information displayed by the
software. Then, determine the causes of call drops.
Compared with analysis of signaling and Performance Statistics, analysis of drive test data shows more
downlink information, including all neighboring cells. You can analyze non-configuration of neighboring
cells, interference, and handovers more conveniently using drive test data.


Source Processing
Standard Analysis Actions and

Deliverables for Call Drops

Page 33
As analysis of call drops involves complex causes, 16
fixed checklists are summarized for each cause of call
drops (top cells, the entire network, or both). It is
strongly recommended that operations be performed
strictly based on the checklists. It is difficult or complex
to prepare if-else flowcharts. It is easy to analyze the
causes of call drops by using check items one by one.

Results of Analysis on Call Drops
Checklist of 16 Required Actions (1)
Required Action Prerequisite Purpose
Action 1: identifying call drop causes 1. Identify top cells, entire networks, or comprehensive
by analyzing Performance Statistics None problems.
and CHRs 2. Analyze main call drop causes.
Action 2: checking parameters (all Analyze appropriateness of and consistency between the
None
parameters) 288 call drop core parameters.
Action 3: checking versions 1. Check whether differences are caused by version
(differences between RNC and None changes.
NodeB versions and parameters) 2. Check whether known issues occur.
Action 4: checking for device faults,
None Check whether devices and clocks work properly.
alarms, and clock exceptions
Check whether transmission exceptions occur including
Action 5: checking transmission Top cells exist.
delay, packet losses, jitters, and congestion.
Action 6: checking RF channels for
Check for RF channel exceptions by referring to UMTS
main and diversity channels, cross
RF Channel Problem Detection and Rectification: Impact
pairs, interferences, power Top cells exist.
Factors+Troubleshooting Methods and
inconsistency, and DL channel
Tools+Deliverables.
exceptions
Neighboring cells are changed on

Check whether intra/inter-frequency and inter-RAT
Action 7: analyzing neighboring cells new and swapped networks.
neighboring cells are normal. For details, see the topics
on new networks and swapped Or the call drop rate is greater than
related to neighboring cell optimization in UMTS Network
networks 5% due to abnormal neighboring cells
Optimization: Process+Principle+Tool+Deliverables.
based on analysis results in action 1.
Action 8: checking adjacent areas of Top cells are located at the border of
Check whether Huawei RNCs and RNCs from peer
Huawei RNCs and peer vendor Huawei RNCs or RNCs from peer
vendors are properly interconnected.
RNCs vendors.

Results of Analysis on Call Drops
Checklist of 16 Required Actions (2)
Required Action Prerequisite Purpose
Check whether call drops are caused by inappropriate
Action 9: analyzing inter-RAT service
None inter-RAT service bearing policies, or by changes in inter-
bearing impact
RAT service bearing.
Combined services probably cause a high call
Action 10: checking call drops of
drop rate according to analysis results in action Check impact of combined services on call drops.
combined services (CS call drops)
1.
Exceptions on common channels probably
Action 10: checking call drops on
cause a high call drop rate according to Check impact of common channels on call drops.
common channels (PS call drops)
analysis results in action 1.
Check whether networking policies are appropriate by
Action 11: checking networking
Multi-carrier scenarios are available. referring to UMTS Network Optimization:
strategies
Process+Principle+Tool+Deliverables.
The call drop rate increases with incremental This action aims to check for capacity problems. For
Action 12: checking resource capacity performance volumes. details, see the capacity-related topics in UMTS Network
Top cells exist. Optimization: Process+Principle+Tool+Deliverables.
Swapped, new, and expanded networks exist.
Call drops in top cells that are not caused by 1. Check whether coverage changes.
Action 13: checking coverage
swapping, deployment, or capacity expansion 2. Check whether top cells are in weak coverage.
of networks
Check whether call drops are caused by external
Action 14: checking abrupt events such The call drop rate suddenly deteriorates, which
unexpected events, such as charging policy changes,
as charging policy changes, weather is not caused by upgrades, operations, or
weather changes, mass gatherings, and returning/leaving
changes, and mass gatherings. external unexpected interference.
of college students to/from campuses.
Action 15: analyzing the long-term
performance trends due to seasonal The call drop rate increases slowly with Check whether the call drop rate fluctuates periodically
changes and subscriber number changes in performance volumes or seasons. due to seasonal changes.
increase
Action 16: analyzing complaints about
Perform in-depth analysis on call drops including analysis
call drops and other abnormal call drops A single user complains.
on the time, area, and causes of call drops.
by using CHRs

Action 1: Determining the Scope of Call
Drops and Identifying Call Drop Causes
Trigger scenarios of the required action:
All scenarios
Analysis Sequence Summary of Data Sources and Analysis Characteristics
and Priority of
Different Data Performance Statistics CHR
Sources
[Data analysis templates]

(1) Template of analysis of the scope of call drops (Performance Statistics + upgrade, feature activation, and
sudden counter deterioration scenarios)
(2) Template of analysis of the scope of call drops (Performance Statistics + counter fulfillment of new
You can obtain the template by
networks, counter fulfillment of swap, and inventory optimization scenarios)
analyzing CHRs.
(3) Template of distribution of the causes of call drops (Performance Statistics)
(1) Template of distribution of
[Characteristics]
the causes of call drops
In the trend deterioration scenario, determine the scope of call drops based on "difference. " In the inventory
(CHRs)
optimization scenario, determine the scope of call drops based on "absolute value."
(1) Top cells:
[Characteristics]
Eliminate the first 20% of top cells with the highest call drop rate and those with the largest number of
(1) Top subscribers: Eliminate
call drops. If the call drop rate of the entire network improves or restores to the original value (or reaches
the first 20% of top
the target value), the scope of call drops can be located to top cells.
Performance subscribers. If the call drop
(2) Entire network:
Statistics -> CHRs: rate of the entire network
high priority improves or restores to the
call drops. If the call drop rate of the entire network does not improve, the scope of call drops can be
original value (or reaches
located to the entire network.
the target value), call drops
(3) Both top cells and the entire network:
are caused by top
subscribers.
call drops. If the call drop rate of the entire network improves but still falls short of the original value (or
(2) Top UEs: The call drop rate
the target value), the scope of call drops can be located to both top cells and the entire network.
of top UEs is two times that
(4) Top subsystems and top interface boards:
of other UEs. The call drop
According to Performance Statistics, the call drop rates of subsystems and interface boards are greater
rate reaches the target
than 3% every day, and the denominator is greater than 10,000. (The access failure rate and call drop
value when top UEs are
rate rarely exceed 3%. Therefore, you can determine that an exception occurs when the access failure
eliminated.
rate or call drop rate is greater than 3%.)
The call drop rate of each NodeB under the subsystem is greater than the average call drop rate of other
subsystems.

Action 2: Checking All Parameters (1)
1. Check all parameters of the entire network unconditionally when calls are
dropped after actions that involve the entire network structure and
performance change have been performed. Those actions include network
swap and construction, upgrade of the entire network, adjustment of
parameters (such as timers and software parameters) of the entire network,
parameter adjustment of CNs, and 2G and 3G service adjustment.
2. Check all parameters of the NodeBs in the modified areas and
corresponding boundary NodeBs unconditionally when calls are dropped after
the following actions have been performed: capacity expansion, NodeB
relocations, adjustment of partial parameters and coverage, and adjustment of
partial network structure and performance change on the boundaries adjacent
to peer vendors.
3. Check and optimize core parameters when the network structure or
performance does not change and only routine call drop rate optimization is
performed. If the expected effect cannot be obtained, consider checking all
parameters.
4. In the swap scenario, analyze the mapping results of parameters before and
after swap.

Action 2: Checking All Parameters (2)
For details about the actions of checking all parameters, see UMTS Full Parameter
Check: Check Rules+Cases+Tools+Deliverables.
There are 288 core parameters about call drops including parameters of the Iur
interconnection, timer, power control, activation time, link re-establishment,
process timer, handover, algorithm, synchronization failure, cell reselection, call
drop statistics, and state relocation, user-plane parameters, and parameters of call
drops for combined services.
Sequence and Priority of Data Source and Characteristics (Summary)
Analyzing Various Data
Sources Parameter DT Data and Signaling
[Data analysis]
[Data analysis]
(1) Check and optimize the
Perform DTs in the coverage of the following
Parameter: high priority 288 core call drop
areas to check whether call drops are caused by
DT data and signaling: parameters.
inappropriate parameter settings: top N cells,
medium priority (used (2) Check and optimize
boundaries of areas served by the devices from
when all parameters of consistency between the
other vendors, areas where 2G/3G interoperability
interconnected devices are 288 core call drop
is allowed.
not obtained) parameters.
[Tools]
[Tools]
DT software and signaling analysis software
NPMaster and CME

Action 3: Checking Versions
Check version difference unconditionally when calls are dropped
after version upgrade has been performed on RNCs and NodeBs.
Analysis Sequence and Summary of Data Sources and Analysis Characteristics
Priority of Different
Performance Statistics Parameter
Data Sources
[Data analysis templates] [Data analysis]
(1) Template of analysis of the scope of call drops (1) Output the check result of version difference
(2) Template of distribution of the causes of call before and after upgrade. The version difference
drops includes all difference points of features,
[Characteristic 1] The scope of call drop rate parameters, and default values. Analyze each
deterioration is the entire network or both the difference point, and determine whether the
entire network and top cells. The time of call difference point affects the call drop rate.
drop rate deterioration corresponds to the time (2) Output the check result of known problems, and
Performance Statistics ->
of version upgrade on RNCs and NodeBs. eliminate the impact of known problems on the
parameters: high priority
[Characteristic 2] The scope of call drop rate call drop rate.
deterioration is top cells. The time of call drop rate [Characteristics]
deterioration corresponds to the time of version (1) Modification difference that affects the call drop
upgrade on NodeBs. rate exists.
[Characteristic 3] The areas with a high call drop (2) Known problems that affect the call drop rate
rate are top N cells. The software versions of the exist.
NodeBs in those areas are different from those of [Tools]
other NodeBs. NPMaster, OMStar, and FMA
For details about version changes related to call drops, see the
following attachment:

Action 4: Checking for Equipment Faults,
Alarms, and Clock Exceptions (1)

1. Check equipment faults and alarms unconditionally in
all scenarios. The clearing of alarms that are unrelated to
or have slight impact on the call drop rate can be
postponed. Alarms that affect the call drop rate and
network performance must be cleared first.
2. Check the Iub interface clocks of top cells when the
scope of call drops is located to top cells.

Action 4: Checking for Equipment Faults,
Alarms, and Clock Exceptions (2)
Detailed description
Analysis Sequence
Summary of Data Sources and Analysis Characteristics
and Priority of
Different Data
Performance Statistics Drive Test + Signaling Tracing Alarm and Log Other Data Source
Sources
[Data]
[Data analysis templates] (1) Alarm list
(1) Drive tests or signaling tracing [Characteristics]
(1) Out-of-service counters of cells
for top cells or VIP areas (1) Fault alarms or
(2) List of cells with abnormal performance
[Characteristics] transient alarms [Data analysis]
(zero or ultra-light performance, and
(1) Calls often drop during soft are generated for Check result of the
zero or small access success rate) or
handovers between top cells and equipment (such clock statuses of the
abnormal change
neighboring cells. The Ec/Io as interface NodeBs for top cells
(3) Template of distribution of the causes
values of other cells are small boards, and [Characteristics]
Alarms -> other data of call drops (Performance Statistics)
when UEs use the signals of top internal DSPs, The clocks of some
sources (top cells) -> [Characteristics]
cells. The Ec/Io values of top MPUs, and RRUs), NodeBs for top cells
Performance (1) The percentage of call drops resulting
cells are small when UEs use the channels, clocks, are not locked, and
Statistics: high priority from OM causes is greater than 5%.
signals of other cells. CPU load, and are in the free-run
(2) The scope of call drop rate
(2) Calls often drop during inter- transmission (from state and have large
Drive tests + deterioration is located to top cells. The
frequency handovers and inter- the bottom layer to frequency deviation.
signaling tracing: low top cells or neighboring cells encounter
RAT handovers in top cells. More the PATH layer). [Tools]
priority performance and access exceptions or
than 80% of downlinks fail due to [Tools] NodeB maintenance
are out of service.
asynchronization during Alarm tool (local
(3) The call drop rate of a subsystem is
handovers to a target cell of a maintenance maintenance
greater than 3%. The call drop rate of
different NodeB. console and terminal [LMT])
each NodeB under the subsystem is
[Tools] OMStar
higher than the average call drop rate
Drive test software and signaling
of other subsystems.
analysis software

Action 5: Checking Transmission
1. For call drop rate deterioration of the entire network, check the transmission related to the Iu
and Iur interfaces.
2. For call drop rate deterioration of top cells, check Iub interface-related transmission of top cells.
Analysis
Sequence and Summary of Data Sources and Analysis Characteristics
Priority of
Different Data Performance Statistics Parameter Alarm and Log Other Data Source
Sources
(1)Analysis of the Performance [Data analysis templates]
Statistics on QAAL2 path setup or [Data analysis] (1) Check result of the path statuses of the Iu and
modification for the Iu and Iur Output the check result Iur interfaces and the Iub interfaces of top cells
interfaces and the Iub interfaces of the transmission (2) Check result of packet loss on the NCP, CCP,
of top cells configuration of the Iu SCTP, and SRB ports of the Iu and Iur
(2) Analysis of the template of and Iur interfaces and [Data] interfaces and the Iub interfaces of top cells
distribution of the causes of call the Iub interfaces of top (1) Alarm list (3) Measurement result of the delay and delay
drops cells. [Characteristics] variation of the Iub and Iur legs of top cells and
[Characteristics] [Characteristics] (1) Alarms intra-frequency neighboring cells
Alarms -> (1) According to Performance 1. The path type/PVC, indicating failed (4) Statistics on packet sending and retransmission
parameters -> Statistics, calls are dropped due or IP address and transmission, on the ATM or IP user plane and signaling
other data to faults unrelated to the air port/bandwidth, and packet loss, plane
sources -> interface. For example, the path ID (for AAL2) and intermittent [Characteristics]
Performance percentage of call drops are inconsistent on disconnection (1) Paths fail.
Statistics: high resulting from Iu AAL2 causes or both sides of the are generated. (2) The SAALink, SCTP, or path packet loss
priority GTPULoss causes is greater interfaces. [Tools] (frame error) rate is greater than 1%.
than 5%. 2. The number of Alarm (3) The delay difference of the Iub and Iur legs of
(2) More than 30% of call drops are paths at one end of maintenance top cells and neighboring cells is greater than
caused by TRB resets. an interface is console and 20 ms.
(3) QAAL2 establishment or inconsistent with OMStar (4) The real-time average path delay variation of
modification failure rate of the that at the other end the Iub interface of a top cell or neighboring cell
Iu/Iur/top cell is greater than of the interface. is greater than 10 ms.
0.5% during busy hours at the 3. AAL2RT or IPRT is [Tools]
Iub interface. not configured. Maintenance tools (LMTs) of RNCs and NodeBs
(4) The call drop rate of sectors at and man-machine language (MML)
sites is high.
Action 6: Checking RF Channels (Main and
Diversity+Cross-connected
Lines+Interference) (1)
1. For call drop rate deterioration of top cells, check the RF channels of top
cells.
2. Check the RF channels of the entire network first unconditionally when
calls are dropped after actions that involve adjustment of NodeB
equipment have been performed, such as network swap and construction,
and NodeB version upgrade.
3. Check the RF channels of NodeBs of the modified areas after routine
network optimization is performed, or when calls are dropped after actions
that involve partial equipment adjustment have been performed, such as
capacity expansion, and NodeB relocations and maintenance.
For details about the actions of checking RF channels, see UMTS

RF Channel Fault Detection and Rectification: Impact
Factors+Troubleshooting Methods and Tools+Deliverables.

Action 6: Checking RF Channels (Main and
Diversity+Cross-connected
Lines+Interference) (2)
Analysis Summary of Data Sources and Analysis Characteristics
Sequence and
Priority of
Performance Statistics CHR Parameter Alarm and Log Other Data Source
Different Data
Sources
[Data analysis] [Data analysis

(1) Analyze the RTWP logs of the entire templates]
network or top cells. (1) Spectrum
(2) (2) Analyze the configuration of the RF scanning files of
(1) Checking of the
[Data analysis channels of the cells of the entire top cells with a
Performance
templates] network. large average
Statistics on the
(1) Distribution [Characteristics] RTWP
RTWP of top cells [Data]
of the (1) In cells with cross-connected lines, the (2) Check result of
and those on the (1) Alarm list
causes of uplink receiving level has a 3 dB gain NodeB
number of [Characteristics]
call drops loss, which weakens uplink coverage. intermodulation
subscribers (1) Alarms
Alarms -> [Characteristics] The RTWP inconsistency of main and [Characteristics]
(2) Distribution of large indicating
parameters -> The percentage diversity can easily cause the noise (1) According to the
RTWP values of top exceptions of
CHRs: high priority of call drops floor of cells to be abnormal. spectrum scanning
cells uplink
caused by a (2) In cells with intermodulation of top cells with a
[Characteristics] channels or
Performance large RTWP is interference, the uplink RTWP is large average
(1) For top cells, the RRUs are
Statistics: greater than 5%, excessively large, which affects the RTWP, external
MinRTWP is greater generated.
intermediate or the increment noise floor of cells and interferes with broadband or
than 104 dBm, and [Tools]
priority is greater than uplink signals. narrowband
the MeanRTWP is Alarm maintenance
100%. (3) When the configuration parameters of interference exists.
greater than 90 console, OMStar,
[Tools] RF channels are incorrect, the RTWP (2) According to the
dBm. and dedicated
NPMaster and is out of the normal range. When check result of
(2) For top cells, RTWP maintenance tools
NodeB LMT tower mounted amplifiers are used, NodeB
fluctuation is
the corresponding RF channel intermodulation,
consistent with the
attenuation must be set. cells affected by
trend of subscriber
[Tools] intermodulation
quantity change.
(1) RTWP log analysis tool interference exist.
(2) Check script of the configuration [Tools]
parameters of RF channels NodeB LMT

Action 7: Analyzing Neighboring Cells
1. Neighbor relationships change in the network construction, swap, and capacity expansion scenarios.
2. The neighbor relationships of the entire network can be checked and optimized when network quality is
improved (KPIs are optimized).
and Priority of
CHR Drive Test + Signaling Tracing Parameter
Different Data Sources
[Data analysis]
Output the check result of the
[Data analysis] consistency and validity of neighboring
(1) Perform drive tests or signaling tracing on top cells.
cells, the entire network, and boundary areas [Characteristics]
(1) Distribution of the causes
adjacent to peer vendors. You can also 1. The NRNCIDs, LACs, RACs, cell
of call drops
optimize neighboring cell configuration. When IDs, or scrambling codes of intra-
coverage overlap occurs, perform adjustment. system neighboring cells are
[Data and characteristics]
(2) Analyze engineering parameters. inconsistent.
(1) According to CHR
2. The MCCs, MNCs, LACs, BCCs,
analysis, the percentage
[Characteristics] NCCs, BCCHs, or cell IDs of inter-
Parameters -> CHRs: of call drops caused by
(1) Calls are dropped due to non-configuration of system neighboring cells are
high priority non-configuration of
neighboring cells (the detect set contains cells inconsistent.
neighboring cells is
with strong signals), coverage overlap (the 3. Cells in different coverage areas are
Drive tests + signaling greater than 5%.
signals of remote cells are strong; UEs cannot configured as neighboring cells for
tracing: low priority (2) According to CHR
trigger handovers in the coverage areas of blind handovers. The blind handover
analysis, the percentage
other cells), and delayed handovers caused by is enabled.
of call drops caused by
sudden signal change. 4. For some intra-frequency
delayed handovers is
(2) Calls are dropped due to scrambling code neighboring cells, ReadSFNInd
greater than 5%.
conflict. (replaced by
CMP_READSFN_IND_IN_SIB_SWI
[Tools]
[Tools] TCH in versions later than R15) is
NPMaster
Drive test software and signaling analysis set to False.
software
[Tools]
NPMaster and CME
For details about the actions of neighboring cell optimization, see the UMTS Network Planning and
Optimization: Principles + Troubleshooting Methods + Cases + Deliverables.
Action 8: Checking Areas Adjacent to Peer
Vendors
1. For network swap and construction that involve the adjacent areas of RNCs and
the boundaries adjacent to peer vendors, check the adjacent areas in advance.
2. During inventory maintenance, when the call drop rate of the adjacent areas of
RNCs and that of the areas adjacent to peer vendors change abnormally, check the
adjacent areas.
Sequence and
Priority of Drive Test + Signaling
Performance Statistics Parameter
Different Data Tracing
Sources
[Data analysis]
Based on the topic of full parameter check, analyze the parameters of
[Data analysis]
[Data analysis templates] Huawei and peer vendors concerning reselections, handovers, power control,
Perform drive tests on
(1) Statistics on RL setup channel switching, service control, and flow control (including timers). Check
the adjacent areas of
and reconfiguration on whether these parameters affect the call drop rate.
RNCs and the areas
Performance the Iur interface
adjacent to peer
Statistics -> [Characteristics]
vendors.
parameters: [Characteristics] 1. The DivCtrlField (Huawei: SET CORRMALGOSWITCH:
[Characteristics]
high priority (1) The RL setup or CmpSwitch=CMP_IUR_SHO_DIVCTRL_SWITCH) switch of SRNC
(1) Calls are often
reconfiguration success consolidation indication is disabled.
dropped in the
Drive tests + rate on the Iur interface 2. The HO_MC_SIGNAL_IUR_INTRA_SWITCH switch of the SRNC is
adjacent areas of
signaling is smaller than 99.5%. disabled.
RNCs or the areas
tracing: (2) Top cells are located on 3. Ping-pong reselections are easily triggered by the parameters of intra-
adjacent to peer
intermediate the boundaries of RNCs frequency, inter-frequency, and inter-RAT reselections of RNC
vendors.
priority or peer vendors (check boundaries.
[Tools]
CN parameter settings, 4. The RNC or peripheral RNC reselection parameters and LACs/RACs
Drive test software and
and perform drive tests). change.
signaling analysis
software
[Tools]
NPMaster and OMStar

Action 9: Analyzing Impact of Service Bearers
Between Technology Types (1)
Trigger conditions of the required action:
1. When KPIs deteriorate on inventory SRAN networks, check whether
mutual impact between GSM and UMTS is caused by GSM and UMTS
service bearer policies or invalid parameter settings.
2. When KPIs deteriorate after swap of a single technology type or of both
GSM and UMTS, check whether exceptions are caused by non-mapping of
interoperation parameters or policies, or improper interoperation policies.
3. When the UMTS call drop rate deteriorates after refarming, check
whether it is caused by mutual impact of technology types.
For details about analysis on the impact of service bearing between

modes, see Mutual Impact between GSM and UMTS: Influence
Factors +Troubleshooting Methods and Tools +Deliverables.

Action 9: Analyzing Impact of Service Bearers
Between Technology Types (2)
Analysis
Sequence and
Priority of
Different Data Performance Statistics CHR Parameter
Sources
Comparison of KPIs, including access times and number of inter-RAT
handovers [Data analysis templates]
[Data analysis and
[Data and characteristics] (1) Distribution of the causes of
characteristics]
(1) The change in the number and percentage of inter-RAT call drops (call drops of the
(1) Check whether
handovers between 3G and 2G networks is large: entire network and call drops
the GSM and
The percentage of inter-RAT CS outgoing handovers is greater of both top cells and the entire
UMTS
than 10%, and the change in the number of inter-RAT CS network)
interoperation
outgoing handovers is greater than 20%. [Data and characteristics]
parameters are
Or: The percentage of inter-RAT PS outgoing handovers is The criteria for determining an
valid.
greater than 10%, and the change in the number of inter-RAT PS increase in the 3G call drop rate
(2) Check the
outgoing handovers is greater than 20%. caused by 2G -> 3G inter-RAT
consistency of 2G
Or: The percentage of reselections to 2G networks in the PCH or handovers are as follows:
and 3G
Parameters -> FACH state is greater than 10%, and the change in the number of (1) 80% of the increase in the
neighboring cells,
Performance reselections to 2G networks in the PCH or FACH state is greater number of 3G CS call drops is
power
Statistics: high than 20%. caused by inter-RAT incoming
configuration,
priority (2) The change in the number and percentage of 2G -> 3G inter-RAT handovers.
consistency of 2G
handovers is large: (2) After the impact of inter-RAT
and 3G LACs and
CHRs: The change in the number of radio resource control (RRC) 2G -> handovers is removed, the 3G
RACs, and NCC
intermediate 3G cell reselections is greater than 20% (PS 2G -> 3G is the CS call drop rate restores to
and BCC
priority cause value). the normal value. That is, the
consistency.
Or: The change in the number of CS 2G -> 3G handovers is value of the following formula
In the swap scenario,
greater than 20%, and the percentage of CS 2G -> 3G handovers meets KPI requirements.
focus on checking the
is greater than 10%. (Total number of 3G CS call drops
consistency with the
(3) The 2G and 3G idle-state behaviors change (which affects Increase in the number of CS call
original network. For
access): drops after 2G -> 3G
power matching, test
The aggregate 2G and 3G access times do not change, and the handovers)/(Total number of 3G
the power
change in the 3G CS access times is greater than 20% (that is, CS calls Number of 2G -> 3G CS
configuration of the
CS access times change between 2G and 3G networks). incoming handovers)
typical NodeBs of the
Or: The change in the ratio of 3G CS access times to the
original network.
aggregate 3G and 2G CS access times is greater than 20% (that [Tools]
is, the percentage of CS access is changing). NPMaster
[Tools]
Nastar

Action 10: Checking Call Drops Caused by
Combined Services (CS Call Drops)
1. If the scope of call drops is located to the entire network, check call
drops caused by combined services.
Analysis
Sequence and
Priority of
Performance Drive Test +
Different Data CHR Parameter
Statistics Signaling Tracing
Sources
[Data analysis]
[Data analysis [Data analysis templates] Perform drive tests
templates] (1) Distribution of the causes of call on the entire network
(1) Analysis of the drops (call drops of the entire and VIP areas.
[Data analysis]
call drop rate of a network and call drops of both top [Characteristics]
Check the
single service and cells and the entire network) (1) In some areas,
Parameters -> parameter settings
that of combined [Data and characteristics] combined
CHRs: high priority related to call drop
services (1) According to the analysis result of services cause
rate optimization for
call drops based on CHRs, the calls to be
Drive tests + combined services
[Characteristics] percentage of CS call drops dropped more
signaling tracing: based on the topic
(1) Call drop rate of caused by the PS processes of easily than a
low priority of parameter check.
combined combined services is greater than single service.
[Tools]
services > Call 40%, or the increment is greater [Tools]
NPMaster
drop rate of a than 50%. Drive test
single CS service [Tools] software and
x2 NPMaster signaling analysis
software

Action 10: Checking Call Drops on Common
Channels (PS Call Drops)
Triggering conditions:
PS call drops occur. Common channels probably cause a high call drop rate
according to analysis results in action 1.
For details, see Common Channels: Impact Factors+Troubleshooting
Methods and Tools+Deliverables.
Sequence and Data Source and Characteristics (Summary)

Priority of
Analyzing Performance
Parameter CHR DT Data and Signaling
Various Data Statistics
Sources
[Data analysis template]
[Data analysis [Data analysis]
(1) Distribution of call drop
[Data analysis] template] Perform DTs on the entire
causes (entire network
According to (1) Analysis on the network or VIP areas.
problems and
Parameter Check call drop rate on [Characteristics]
Parameters -> comprehensive problems)
Theme, check various channels (1) Call drops are more
CHRs: high priority [Data and characteristics]
configurations of [Characteristics] liable to occur on
(1) According to analysis
parameters related (1) Call drop rate of common channels than
DT data and results of CHR call drops,
to common services carried on on dedicated channels in
signaling tracing: the PS call drop rate on
channel call drop common channels some areas.
low priority common channels is
optimization. > Call drop rate of [Tools]
greater than 40% or
[Tools] services carried on DT software and
increases by 50%.
NPMaster dedicated signaling analysis
[Tools]
channels x 2 software
NPMaster

Action 11: Checking Networking Policies
1. For multi-technology type and multicarrier networks, check networking policies.
2. In the swap scenario, check networking policies first.

and Priority of
Different Data
Sources Performance Statistics CHR Parameter
[Data analysis templates] [Data analysis templates]

Counters related to RRC and radio access bearer (RAB) (1) Distribution of the causes of call
access in different frequency bands, CS and PS service drops (call drops of the entire [Data analysis]
volume and number of online subscribers, and inter- network and call drops of both top Output the result of
frequency handovers and inter-RAT handovers, and cells and the entire network) parameter validity
resources [Data and characteristics] check.
Parameters ->
(1) According to the analysis result of [Characteristics]
Performance
[Characteristics] call drops based on CHRs, the 1. Networking
Statistics -> PCHRs:
(1) The change in RRC access times due to inter-RAT percentage of call drops caused by parameters do not
high priority
reselections on the entire network is greater than 20%. activation of the compressed mode comply with
(2) The change in the number of inter-RAT and inter-frequency handover networking policies.
incoming/outgoing handover attempts on the entire failures is greater than 10%, or the [Tools]
network is greater than 20%. increment is greater than 50%. NPMaster
(3) In the multicarrier scenario, the call drop rate difference [Tools]
between different carriers is greater than 50%. NPMaster
For details about how to check networking policies, see the

topic of network planning and optimization.
Action 12: Checking Resources and
Capacity (1)
1. When the scope of call drops is located to top cells or both top
cells and the entire network, check capacity unconditionally.
2. The call drop rate deteriorates continuously within a period,
and corresponds to the increase trend of voice and data services.
3. In the swap scenario, check capacity.
For details about how to check capacity, see the topic of

network planning and optimization.

Action 12: Checking Resources and
Capacity (2)
and Priority of
Other Data
Different Data Performance Statistics Parameter Alarm and Log
Source
Sources
Revision of the capacity topic
(1) Checking of various RRC access causes and changes of
the entire network and top cells
(2) Number of and change in inter-RAT incoming handover
attempts of the entire network and top cells
(3) Volume of the voice, PS, CCH, and combined services of [Data analysis]
the entire network and top cells/erlang and number of online Output the result of [Data analysis]
subscribers/TCP, NonHSTCP, and RTWP parameter validity Check result of
[Data]
(4) Distribution of the causes of RRC and RAB access failures check result. CPU load of top
(1) Alarm list
of the entire network and top cells cells during the
[Characteristics
(5) List of RNCs' boards with abnormal CPU load during busy [Characteristics] busy time
(1) Alarms
Parameters -> alarms time 1. In cells with [Characteristics]
indicating
-> other data sources [Characteristics] heavy The average CPU
CPU overload
-> Performance (1) The performance volume is consistent with the KPI performance, the load is greater
are
Statistics: high priority deterioration trend. values of than 70% on the
generated.
Revision of the (2) The percentage of RRC access times with the cause value parameters of NodeBs for top
[Tools]
capacity topic of inter-RAT reselections of the entire network or top cells is the live network cells during busy
Alarm
greater than 10%, or the increment is greater than 50%. are different from time.
maintenance
(3) The percentage of RRC access times with the cause value recommended [Tools]
console and
of registration of the entire network or top cells and values. NodeB
OMStar
geographically neighboring cells is greater than 50%, or the maintenance tool
increment is greater than 50%. [Tools] (LMT)
(4) The ratio of inter-RAT incoming handover attempts of the NPMaster
entire network or top cells to RAB setup times is greater
than 10%.
(5) The percentage of access failures caused by congestion of
top cells is greater than 10%.
(6) The average CPU load of boards is greater than 70% during
busy time.

Action 13: Checking Coverage (1)

1. In the scenarios of network construction, swap, and capacity
expansion that involve adjustment of the network structure and
RF parameters such as equipment power and antenna feeders,
check coverage and compare coverage difference before and
after network construction, swap, and capacity expansion.
2. When call dropping problems of top cells are not resolved after
checking of RF channels and parameters, neighboring-cell
optimization, and capacity analysis, perform in-depth coverage
check and optimization.
3. Perform routine coverage optimization periodically.

Action 13: Checking Coverage (2)
Sequence and
Priority of Performance
CHR Drive Test + Signaling Tracing Parameter
Different Data Statistics
Sources
[Data analysis]
1. Perform drive tests or IOS tracing on the entire network
[Data analysis and
or top cells.
characteristics]
[Data analysis 2. Perform drive tests or fixed-point tests in special
Check the
[Data analysis templates] scenarios, such as VIP areas, indoor areas, campuses,
configuration of
templates] (1) Distribution of residential areas, and high-speed railways.
power, gain of tower
Various KPIs of top the causes of call 3. Perform coverage tests on areas of subscriber
mounted amplifiers,
cells (call drops of top drops complaints.
and antenna
cells) [Characteristics] [Characteristic 1] Based on the data of drive tests or tracing,
Parameters -> parameters. In the
[Characteristics] (1) According to check whether weak coverage, coverage holes, coverage
CHRs: high swap scenario, focus
The access success the analysis overlap, and downlink interference exist, or whether non-
priority on checking the
rate (call completion conclusion of the configuration of neighboring cells or invalid handover
consistency with the
rate smaller than 99%) causes of call parameters cause abnormal handovers and bad level exists.
Drive tests + original network. For
and call drop rate drops, the These factors can cause calls to be dropped.
signaling tracing: power matching, test
(greater than 1%) of top percentage of call [Characteristic 2] In the swap scenario, compare the drive
intermediate the power
cells are bad. Both the drops caused by test coverage distribution before and after swap. For
priority configuration of the
small access success weak coverage is NodeBs and cells with abnormal coverage shrinkage,
typical NodeBs of
rate and call failures are greater than 70%. antenna feeders, power, and combiners may be abnormal.
the original network
mainly resulted from RF (Note: It is difficult to identify coverage shrinkage introduced
(check whether
causes. [Tools] by power matching and combiners through routine check of
parameters and
NPMaster RF channels. Therefore, check power and combiners when
antenna feeders
no problems are identified during routine check of RF
change).
channels but coverage shrinkage is identified by coverage
comparison.
For details, see coverage analysis in Network Planning

Optimization Theme.
Action 14: Analyzing Incidents

When the call drop rate deteriorates suddenly and no internal network
adjustment (equipment faults, parameter adjustment, and upgrade) or
external interference exists, check whether the following factors that may
affect coverage and performance exist: tariff change, weather change,
gathering, and students leaving or returning to school.

and Priority of
Different Data Sources Performance Statistics

(1) Template of comparison of voice and data service volume and the call drop rate
change trend
Performance Statistics:
[Characteristics]
high priority
The call drop rate deteriorates suddenly. The period and area of the deterioration
correspond to those of an incident (such as tariff change, weather change, and
gathering, which may affect coverage and performance).

Action 15: Analyzing the Secular Trend of
performance and KPIs
When the call drop rate deteriorates slowly and performance or
seasonal change occurs during deterioration, check whether the
call drop rate is normal based on the secular historical trend.

and Priority of
Different Data Performance Statistics
Sources

(1) Template of comparison of voice and data service volume and the call drop rate
change trend
Performance Statistics:
intermediate priority
[Characteristics]
The call drop rate changes slowly. The change trend is similar to the secular
historical trend of seasonal change or subscriber development.

Action 16: Analyzing Complaints and Other
Abnormal Call Drops (1)
1. VIP subscriber assurance (VIP subscriber tracing and analysis)
2. Analysis on CHRs of subscribers complaining about call drops3. In-depth analysis
on call drop records
Analysis
Sequence and Summary of Data Sources and Analysis Characteristics
Priority of
Different Data Parameter CHR
Sources
[Data analysis]
[Data analysis] Collect statistics on CHRs.
(1) Check and optimize the (1) Analysis of VIP subscribers' call records (check whether calls are dropped on 3G
288 core parameters of networks or whether calls are released by called parties)
call drops. (2) Analysis of the call records of subscribers that make complaints (check whether
(2) Check and optimize calls are dropped on 3G networks or whether calls are released by called
CHRs: high priority consistency between parties)
the 288 core (3) Cause values of call drops
parameters of call (4) Return visit to the subscribers that make complaints about call drops to identify
drops. the problem areas and UEs. Check whether the call drop rate of the
[Tools] corresponding area is greater than that of the entire network. Perform tests on
NPMaster and CME the area, and perform the required actions (checking parameters, transmission,
RF channels, and other related factors).

Action 16: Analyzing Complaints About Call Drops
and Other Abnormal Call Drops (2)
Steps for analyzing VIP subscriber complaints:
Step Item Result Solution Implementation
Deploy VIP monitoring on the Nastar to monitor VIP subscribers that 1. If the call drop rate of an individual VIP is
Check whether the call drop rate of VIP
complain about call drops. high, optimize the VIP line and trace and
1. Analyzing the historical subscribers is higher than that of the entire
Analyze the historical call drop rate of VIP subscribers that complain analyze VIP signaling.
call drop rate of VIP network. If yes, check whether VIP call drops
and compare the call drop rate with that on the entire network. If field 2. If the call drop rate of the entire network
subscribers occur in fixed mobile phone models, on fixed
engineer cannot deploy the Nastar, feed back this information to is high, perform the first 15 required
lines, or in fixed areas.
RCHR R&D engineer. actions.
Check whether known issues exist by searching for cases and Check for known issues, analyze the impact,
2. Checking known issues Exclude the impact of known issues.
checking RNs and the bug list of terminal compatibility. and provide a preventive solution.
1. Analyze whether call drops occur on the
1. If call drops do not occur on the RAN,
UMTS RAN.
3. Analyzing information analyze the situation with the peer end.
Record and feed back detailed complaint information according to 2. Analyze whether call drops are caused by
about the RAN and CN 2. If call drops occur on the RAN, perform
Standard Complaint Template. abnormal answered calls.
and locating faults further analysis by referring to the following
3. Analyze whether call drops occur on fixed
required actions.
lines and in fixed areas.
The original CHR on the CN contains detailed call release causes.
Check whether the CN abnormally releases Cooperate with personnel working with the
Check whether the CN releases calls based on preceding
calls. CN.
information.
The original CHR of the CN contains call release causes and NEs
Check whether call drops occur on the RAN of Cooperate with personnel working with the
related to call releases. Then check whether call drops are caused
the peer end. network where the peer end locates.
by faults of the peer end based on preceding information.
4. Analyzing call drops that
Check whether calls in the CHR are released in GSM or UMTS.
do not occur on the RAN Check whether call drops occur after terminals Cooperate with personnel working with the
Then check whether VIP call drops occur in GSM.
are handed over to the GSM. GSM network.
According to call release causes in the original CHR of the CN,
After confirming with VIP subscribers
check whether calls are normally released. If yes, check whether Check whether misoperations occur. For
experiencing call drops, we find that the cause
misoperations such as the touchscreen contacting the body cause example, users mistakenly end the call.
is that subscribers end calls.
call releases.
Analyze VIP call drop causes and provide a
Trace CDT of VIP subscribers. Implement a call drop optimization solution.
solution.
Perform DTs in places and areas where subscribers complain about
Analyze call drop causes by performing DTs
call drops and perform dialing tests in various scenarios. For details, Implement call drop optimization measures.
and provide a solution.
see Cases of Dialing Tests for Call Drops.
5. Analyzing call drops on According to complaints of VIP subscribers, check whether call drops
Check whether the call drop rate is high during Provide a solution to reduce the call drop rate
the RAN occur during busy hours and whether call drops are related to
busy hours. during busy hours.
performance volumes.
Perform the first 15 required actions in areas Provide results after the first 15 required
For details, see the first 15 required actions.
where VIP subscribers experience call drops. actions are performed.
Analyze data by using the Nastar that helps analyze UMTS
Analyze causes in CHRs and provide a solution. Implement a call drop optimization solution.
complaints and analyze UMTS VIP subscribers.

UMTS VIP analysis - result query - user-level analysis Result worksheet
Filtered Analysis worksheet of cells with

VIP Selecting object specified VIP groups or subscribers
Filtered
Selecting service types
Filtered
Selecting KPI sets
The Nastar VIP analysis function has the following characteristics:

Results are displayed in tables, which helps engineers quickly discover abnormal VIP
subscribers based on KPIs.
VIP subscribers, service types, and KPI sets can be filtered and viewed.
In-depth analysis can be performed based on specified VIP subscribers and abnormal KPIs.

Auxiliary analysis on UMTS complaints-result viewing-summary worksheet
Abnormal cause field:

Release cause field:
Provide demarcation
Analyze recorded causes
analysis results based on
of device exceptions
various information.
based on the release
Selecting service types cause field.
Calls with various

exceptions are
clearly displayed.
Selecting users and
abnormal objects
The function of auxiliary analysis on complaints

on the Nastar provides the following subfunctions: Analyzing handover problems
Filtering and viewing service types Analyzing service quality problems in the CS
Analyzing SMS domain
Analyzing combined services Analyzing service short-paging problems in the CS
Analyzing delay problems domain
Analyzing service quality in the PS domain

Deliverables Template of the Analysis
Report on call drops
Complete and symmetrical information output is required for troubleshooting common call drops and
major problems jointly handled by frontline and support personnel.
Provide a template of the analysis report on call drops based on the required actions of
troubleshooting call drops and the analysis of call drops on actual networks. Analyze all call drops
based on the template. Provide a standardized information platform to problem troubleshooters and
problem tackling participants. Standardize the process of performing required actions. Perform issue
closure on the shortest path.

Call Drops on Live Networks
Troubleshooting guides are used to resolve call drops on live networks.
Percentage of problems that can be resolved based Distribution of problems on live networks that can be resolved
on troubleshooting guides by performing required actions in troubleshooting guides:
1.82% 1
Action 1
Percentage of
problems that can be
7.27% 7.27% 2
Action 2
resolved based on
troubleshooting guides 5
Action 5
12.73% 6
Action 6
Percentage of 7
Action 7
problems that cannot 1.82%
be resolved based on 3.64% 8
Action 8
troubleshooting guides 40.00%
9
Action 9
9.09%
Distribution of problems that cannot be resolved 10
Action 10
based on troubleshooting guides 11
Action 11
1.82%
5.56% 14
Action 14
5.56%
UE problems 3.64%
1.82% 5.45% 16
Action 16
5.56%
UE authentication 3.64%
DRD problems
DRD
33.33%
bug
Version bugs
11.11%
NodeB faults
NodeB
5.56% CN
Action
CN of a8 peer vendor
Single cell
5.56% 5.56%
unavailability
5.56% 11.11%
Voice codes
5.56%


Source Processing
Standard Analysis Actions and

Deliverables for Call Drops

Typical Cases Related to Call Drops
Case Name Case Library Link X-Board Axe Solution
The CS call drop rate increases because uplink performance increases after the NodeBs of office T in country C are upgraded from R11 http://wxsolutions/casebase/CasDetails
Action.do?casno=1326704667593&met Check versions.
to R12. hod=details
http://wxsolutions/casebase/CasDetails
Analysis report on frequent call drops after Iur interface handovers for China Unicom, Chongqing Action.do?casno=1326245468484&met Check versions and Iur interface problems (ZTE)
hod=details
The call drop rate deteriorates because RNCs' parameters are set incorrectly (inner-loop power control). N/A (see the X-board axe slides) Check parameters.
The 3G call drop rate increases after the 2G -> 3G handover switch is enabled because 2G parameters are invalid. Action.do?casno=1335584757659&met Check parameters.
hod=details
The call drop rate increases because of downlink channelized code conflict after the default configuration switch of inter-RAT CS Action.do?casno=1318927429671&met Check parameters.
incoming handovers is enabled. hod=details
[Costa Rica-ICE] The DRL setup success rate is low because scripts are not modified completely after inter-RNC cell rehoming. Action.do?casno=1312342246328&met Check parameters.
hod=details
3G KPIs deteriorate due to non-mapping of the reselection parameters of 2G -> 3G handovers after 2G network swap. N/A (see the X-board axe slides) Check parameters.
The call drop rate of problem NodeBs increases because the configuration of SAAL link transmission bandwidth is below the lower limit Action.do?casno=1312525891812&met Check parameters: transmission configuration.
after transmission rectification. hod=details
The call drop rate increases because the path configuration on the Iur interface is incorrect after swap of Optus V1 of Portugal to V9. Action.do?casno=1309156382765&met Check parameters: transmission configuration.
hod=details
The call drop rate on the Iur interface is high because of incorrect AAL2 path PVC configuration on the Iur interface. Action.do?casno=1306594949343&met Check parameters: transmission configuration.
hod=details
The CS call drop rate increases after the 2D threshold of Singapore is modified. Action.do?casno=1305633270953&met Check parameters and networking.
hod=details
The CS and PS call drop rates increase after LACs and RACs are modified by URNC07, Hong Kong. Action.do?casno=1318578016453&met Check parameters, networking, and capacity.
hod=details
The call drop rate increases because of SCTP congestion during the busy time of office B in Canada. Action.do?casno=1318316249515&met Check transmission alarms and QoS.
hod=details
The call drop rate increases due to inter-RNC handovers between Huawei and Motorola resulting from the processing delay of Motorola' Action.do?casno=1301745086640&met Check transmission: Iur interface delay.
NodeBs. hod=details
Check transmission. VCLCC detection indicates that alarms
Analysis of the increase in the CS call drop rate due to IuUP failures at an office of Kazakhstan Action.do?casno=1312184211703&met
hod=details are generated.
KPIs deteriorate after swap of Orange, Spain. Action.do?casno=1302629359828&met Check transmission: transmission QoS.
hod=details
Check transmission: transmission QoS and Performance
Analysis of the high CS and PS call drop rates on the entire network of Nigeria Action.do?casno=1316049675125&met
hod=details Statistics.
The call drop rate on the Iur interface is high in Oman. Action.do?casno=1309338766468&met Check transmission: transmission failures.
hod=details
[PCCW, Hong Kong] The number of CS and PS call drops of a single NodeB increases resulting from OM causes. Action.do?casno=1337582141830&met Check equipment faults, alarms, and clocks.
hod=details
The CS call drop rate increases suddenly due to clock exceptions in Thailand. Action.do?casno=1320635798968&met Check equipment faults, alarms, and clocks.
hod=details
Analysis of the failure of intra-frequency handovers between some NodeBs of Motorola in Vietnam Action.do?casno=1310374148812&met Check equipment faults, alarms, and clocks.
hod=details
Check equipment faults, alarms, and clocks: transmission
Calls are dropped due to weak coverage when FP synchronization of new links fails during inter-RNC handovers. Action.do?casno=1334057364906&met
hod=details alarms.
[China Unicom, Nanchang] Calls are dropped when combined services are performed. Action.do?casno=1324294013140 Check call drops caused by combined services.
In Singapore, the call drop rate of combined services is high and must be optimized. N/A (see the X-board axe slides) Check call drops caused by combined services.
[Costa Rica-ICE] Optimization of the CS call drop rate of the third carrier Action.do?casno=1310715261421&met Check networking.
hod=details
Analysis report on failure of the UMTS CS call drop rate to reach the target value after refarming of Optus in Australia Action.do?casno=1339487337393&met Check networking, RF channels, and coverage.
hod=details
Maintenance knowledge base (see the
Many Calls are dropped due to incorrect configuration of neighboring cells, and the cause of call drops is ASU timeout. X-board axe slides) Check networking: neighboring cell check.
There is a high probability of call drops in some cells of office G in country C due to intra-frequency coverage overlap with the same Maintenance knowledge base (see the
X-board axe slides) Check networking: scrambling code conflict.
scrambling code.

Case 1: The call drop rate deteriorates because
parameters on the RNC are set incorrectly. (1)
Overview
According to telecom operator V of country I, KPIs deteriorate after RNC upgrade. The
involved KPIs include RRC setup failure rate, CS and PS RAB setup failure rates, and CS
and PS call drop rates. The reason is that RNCs' parameters are set incorrectly and the
inner-loop power control is disabled.
Problem analysis process

Step 1: Determine the scope of call drops. The call drop rate of the entire network
deteriorates after RNC upgrade, which is hardly related to top cells.
Step 2: Identify the causes of call drops. The cause of call drop rate deterioration is the
increase in the number of call drops resulting from RF causes, including SRB reset, uplink
failures, and no reply on the Uu interface.

Case 1: The call drop rate deteriorates because
parameters on the RNC are set incorrectly. (2)
Step 3: Analyze call drops Step 4: Perform issue closure
based on required actions. actions and evaluate the effect.
Data Analysis and Conclusion of Data Issue Closure
Required Action Effect
Symptom Analysis Action
The number of call drops The call drop rate
The inner-loop power control is
resulting from RF causes restores to the normal
Check parameters (full disabled manually after Enable the inner-
increases because the value after the inner-
parameter check). parameters of inner-loop power loop power control.
inner-loop power control is loop power control is
control are upgraded.
disabled. enabled.
Check versions (RNC

and NodeB version
Not performed Not performed Not performed Not performed
difference + parameter
difference).
According to operation log analysis, the downlink inner-loop power control switch was deactivated at 15:25 on
March 11, 2011. As a result, downlink NodeBs do not perform inner-loop power control. The number of call
drops resulting from RF causes increases.
242414,'admin','10.188.41.101',13615,'/*HWHandle=1686*/SET UCORRMALGOSWITCH:
DraSwitch=DRA_HSDPA_STATE_TRANS_SWITCH-1&DRA_HSUPA_STATE_TRANS_SWITCH-1,
PcSwitch=PC_DL_INNER_LOOP_PC_ACTIVE_SWITCH-0, MapSwitch=MAP_HSUPA_TTI_2MS_SWITCH-
1, PsSwitch=PS_BE_IU_QOS_NEG_SWITCH-1, CmcfSwitch=CMCF_DL_HLS_SWITCH-
0&CMCF_UL_HLS_SWITCH-0, ReservedU32Para0=0;','2011-03-11 15:25:05','2011-03-11
15:25:05',1,0,'Execution succeeded.','10.188.41.101---O&M System','','',2,0,1,0,''

Case 2: The PS call drop rate does not meet desired
requirements due to NSN formula mapping and
parameter configuration after swapping. (1)
Overview
After NSN networks are swapped in area M in country D, the PS call drop rate
does not meet desired requirements. Firstly, the PS call drop rate formulas
between NSN and Huawei are different. Secondly, the SRBOE parameter in weak
coverage is not properly configured.
Problem Analysis
Check whether mapping is correct on swapped networks.
Step 1: Determine the scope of the call drop problem. After swapping, the call
drop rate in the FSA area is higher than that on the original NSN network and does
not meet desired requirements.
Step 2: Analyze the reason of the call drop problem in detail. The main cause of
CHR call drops is RF problems.
Steps 1 and 2 correspond to action 1.

Case 2: The PS call drop rate does not meet desired
requirements due to NSN formula mapping and
parameter configuration after swapping. (2)
Step 3: Analyze required actions.
Action Symptom and Analysis Conclusion
Action 1: identifying call drop causes by 1. Top causes of call drops are RF Top causes of call drops are RF problems
analyzing Performance Statistics and problems including CCH, TRB resets, including CCH, TRB resets, and
CHRs and UuNoReply. UuNoReply.
Action 2: checking parameters (all 1. The E2D switch is not turned on after The E2D switch is not turned on and the
parameters) swapping. number of HSUPA users increases.
Action 3: checking versions (differences
between RNC and NodeB versions and No exceptions occur. No exceptions occur.
parameters)
No exceptions occur. No exceptions occur.
Action 5: checking RF channels for main
and diversity channels, cross pairs, Channels keep unchanged before and
No exceptions occur.
interferences, power inconsistency, and after swapping.
DL channel exceptions
Actions 6 to 16: See the preceding
No action is required. No action is required.
description.
The two figures on the

left show the access
success rate and call
drop rate. The call drop
rate shown in the figures
is far higher than the
target value of the PS
call drop rate (0.33).

Case 3: The PS call drop rate increases by 0.1%
when the NodeB is upgraded from R012SPC440 to
R013SPC339. (1)
Overview
According to operator T in country T, the call drop rate increases by 0.1%
after the NodeB is upgraded from R012SPC44 to R013SPC339.
Problem Analysis
Step 1: Determine the scope of the call drop problem. According to
analysis on Performance Statistics, the call drop rate deteriorates
under the coverage of the entire RNC instead of in top cells. Step 2:
Analyze the reason of the call drop problem in detail. According to
analysis on Performance Statistics, most call drops are HSUPA call
drops. The main cause of call drops is incremental SRB resets.

R013SPC339. (2)
Action 1: identifying call drop causes by The main cause of call drops is The main cause of call drops is
analyzing Performance Statistics and incremental SRB resets. Most call drops incremental SRB resets. Most call
CHRs occur on HSUPA users. drops occur on HSUPA users.
1. Swapped parameter mapping is

Action 2: checking parameters (all normal.
Parameters are normal.
parameters) 1. Parameters related to call drops are
normal.
The scope of the call drop problem is in

Action 3: checking versions (differences top N cells and on the entire network and The call drop rate deteriorates
between RNC and NodeB versions and the call drop rate deteriorates immediately after the RNC or
parameters) immediately after the RNC or NodeB is NodeB is upgraded.
upgraded.

Action 5: checking transmission No action is required. No action is required.
Action 6: checking RF channels for main The RTWP in top cells deteriorate
RTWP deteriorates after a version
and diversity channels, cross pairs, and according to analysis on RNC
upgrade.
interference Performance Statistics.
Actions 7 to 12: See the preceding
description.

R013SPC339. (3)
Step 4: Resolve the problem.
If the RTWP optimization solution is incorporated in R012SPC420, RTWP will increase. If the
RTWP optimization solution is incorporated in R013SPC510, the RTWP slightly increases after
the NodeB is upgraded to version R013SPC399. However, SRBOE is configured on live
networks, which affects the call drop rate of HSUPA users. Explain this situation to customers
in reports.
For details, see the following table.
The Received Total Wideband Power (RTWP) may increase sharply if the NodeB admits UEs that have
Description
a high transmit power.
When cell load is heavy, the preambles of the UEs that have a high transmit power lead to a sharp
Cause
increase in the RTWP.
Impact The RTWP increases sharply.

Severity Warning
Solution When cell load is heavy, NodeBs reject the UEs that have a high transmit power and filter the RTWP.
PR Number DTS: DTS2011051206349
Test Case ID ATP-2011051206349

Case 4: Call drops occur because soft handovers
cannot be performed on some NodeBs due to clock
exceptions. (1)
Overview
Soft handovers cannot be performed on two NodeBs of telecom operator V of country V due
to clock exceptions. As a result, signals deteriorate, and calls are dropped.

Step 1: Identify the scope of call
drops. Calls are dropped between
two NodeBs.
Step 2: Identify the causes of call
drops. According to drive tests and
signaling analysis, when UEs move
from NodeB A to NodeB B, the
signals of the cells under NodeB B
become increasingly better.
However, UEs do not report soft
handover measurement events. As
a result, the signals of UEs in the
cells under NodeB A deteriorate,
causing calls to be dropped.

Case 4: Call drops occur because soft handovers
cannot be performed on some NodeBs due to clock
exceptions. (2)
Step 3: Analyze call drops based Step 4: Perform issue closure
on required actions. actions and evaluate the effect.
Conclusion of Data Issue Closure
Required Action Data Analysis and Symptom Effect
Analysis Action
Identify the causes of call Many subscribers complain about call drops. Coverage check is required
Perform further
drops (analysis of According to CHR analysis, the percentage of call because the percentage of
check based on None
Performance Statistics and drops caused by weak coverage is greater than call drops caused by weak
required actions.
CHRs). 90%. coverage is large.
Check parameters (full Parameters related to neighboring cells,
No exception N/A None
parameter check). handovers, and reselections are valid.
1. No alarms are generated.
2. The current DA of clocks deviates from the
original DA, but the center DA changes with
1. The current DA of 1. Replace the Faults are
the current DA. Therefore, clocks are locked.
clocks deviates from the WMPT board. rectified after
Check equipment faults, 3. After power-off reset, calls are still dropped.
original DA. 2. Check the fault the WMPT
alarms, and clocks. After the WMPT board is replaced, calls are
2. The cause of call drops cause of the board is
not dropped. When the replaced WMPT board
is the WMPT board. WMPT board. replaced.
is transferred to another NodeB, calls are
dropped. Therefore, the cause of call drops is
the WMPT board.
The signals of the areas where calls are dropped
Check coverage. are good. Weak coverage areas do not exist. Coverage is normal. N/A None
(ECN0 > -14, and RSCP > -105)
Root cause of the impact of clocks on handovers: Clock offset causes the offset of the center frequency of the air-interface
signals on NodeBs. For example, intra-frequency cells A and B have the same UARFCN 2.15 GHz. When a UE maintains
connection in cell A, phase-locked loop is enabled to trace the clock of the NodeB for cell A. When cell B is measured, the
clock is used as reference. If cell B's clock is abnormal, causing frequency deviation, the UE may not measure the real center
frequency of cell B. In this case, the UE may not be able to measure signals or measure bad signals. The clock difference
between cells A and B may cause air-interface synchronization and the timing relationship to be abnormal. It is difficult for the
UE to receive information at the correct time. The measurement varies with UEs. Therefore, the impact on UEs also varies.

Case 5: Call drops of HSPA users occur because
UE-not-involved RNC relocation is not performed
properly. (1)
Overview
The call drop rate is high at some sites of operator C in country C.
According to analysis, HSPA users experience call drops.
Problem Analysis
Step 1: Determine the scope of the call drop problem. According to
analysis on Performance Statistics, call drops mainly occur in top
cells.
Step 2: Analyze the reason of the call drop problem in detail.
According to analysis on Performance Statistics, call drops mainly
occur on HSDPA users.

properly. (2)
Action 1: identifying call drop
The main cause of call drops is SRB
causes by analyzing The main cause of call drops is
resets. Call drops occur in HSUPA and
Performance Statistics and incremental HSPA SRB resets.
HSDPA.
CHRs
1. Swapped parameter mapping is
Action 2: checking parameters normal.
Parameters are normal.
(all parameters) 2. Parameters related to call drops are
normal.
Action 3: checking versions
No version operation is required and no
(differences between RNC and No version operation is involved.
known issue is discovered.
NodeB versions and parameters)
Actions 4 to 12: See the
preceding description.
This problem may be related to the
compatibility of the Iur interface.
Action 8: checking joint areas of Top cells are located at the border of
Perform a DT at the Iur interface
Huawei RNCs and RNCs from Huawei RNCs or RNCs from peer
and trace signaling on the network
peer vendors vendors.
side. Then feed back DT data and
tracing logs to headquarters.
Actions 9 to 16: See the

properly. (3)
When UE-not-involved relocation is performed on the target RNC, SRB fallback
occurs. During reassignment, DL DPCH SlotFormat at the Iub interface is
reassigned, but DL DPCH Pilot Bit at the Uu interface is not reassigned, causing
call drops.
During handovers, SlotFormat used by the source RNC is 3. After UE-not-involved relocation is performed on the
local RNC, SlotFormat used by the target RNC is 5.
Solution: version upgrades

Preventive solution: Turn off the IUR OVER HSDPA switch on the source RNC.

Case 6: The UMTS call drop rate of Huawei deteriorates
because of peer vendor's incorrect configuration of
AAL2 path PVCs at the Iur interface. (1)
Overview
After Ericsson network swap performed by VHA in Australia, the number of call
drops in boundary cells increases. According to analysis, the cause is an FP
synchronization failure on the Iur interface because of the incorrect configuration of
AAL2 path PVCs of the peer vendor connecting to the Iur interface.

Step 1: Identify the scope of call drops. After Ericsson network swap, the Iur-
interface call drop rate is high on NodeBs.
Step 2: Identify the causes of call drops. According to analysis on
Performance Statistics by using the NPMaster, many call drop causes are
unknown.

Case 6: The UMTS call drop rate of Huawei deteriorates
because of peer vendor's incorrect configuration of
AAL2 path PVCs at the Iur interface. (2)
Step 3: Analyze call drops based on Step 4: Perform issue closure actions and
required actions. evaluate the effect.
Issue Closure
Required Action Data Analysis and Symptom Conclusion of Data Analysis Effect
Action
1. Parameter mapping is normal in the swap scenario.
Peer vendors transmission parameters
Check parameters (full 2. Parameters related to the call drop rate are normal. None
on the Iu interface are not checked. Other N/A
parameter check). 3. Transmission parameters on the Iur interface are not
parameters are normal.
checked.
Check transmission. The peer vendor The call drop rate
1. Certain AAL2 paths on the Iur interface connected to
Transmission fails because the peer corrects the restores to the
the peer vendor's network do not receive performance.
Check the adjacent areas of vendor's configuration of AAL2 path PVCs configuration of normal value
2. The peer vendor's configuration of AAL2 path PVCs
RNCs and the areas on the Iur interface is incorrect, which AAL2 path PVCs after the
on the Iur interface is inconsistent with that of Huawei
adjacent to peer vendors. causes an FP synchronization failure. on the Iur configuration is
(the peer vendor's configuration is incorrect).
interface. corrected.
According to analysis of the logs about call drops on the Link deletion resulting from an FP
Analyze complaints and None
Iur interface, an FP synchronization failure causes synchronization failure is the main cause of None
other abnormal call drops.
deletion of the best link. As a result, calls are dropped. call drops on the Iur interface.
UE RNC DRNC (peer vendor) NodeB (DRNC)
Measure Report (1A + Iur cells)
RL Setup Request RL Setup Request
RL Setup Rsp
RL Setup Rsp
ASU (addition of Iur
neighboring cells)
ASU Complete (addition of Iur

neighboring cells) Trch Sync Fail
ASU (deletion of Iur

neighboring cells)
The lur cell with the best signal
is deleted. When subscribers
move, calls are dropped
because the signal of the
original cell deteriorates.

Case 7: The UMTS call drop rate deteriorates after
the U900 is activated. (1)
Overview
According to telecom operator O of country A, the UMTS CS call drop rate deteriorates after
the U900 is activated for GSM and UMTS refarming. The result of problem tackling shows
that the deterioration is caused by U900 interference and increase in inter-frequency
handover failures.

Step 1: Identify the scope of call drops.
1. According to analysis of Performance Statistics, the call drop rates of the U900 and
U2100 deteriorate after the U900 is activated.
2. The scope of call drop rate deterioration of the U900 is top cells, and that of the U2100 is
the entire cluster.

Step 2: Identify the causes of call drops.
Analyze the causes of call drops based on PCHRs.
The main causes of call drops are weak coverage, inter-frequency handover failures, and
abnormal RTWP.
Weak coverage and abnormal RTWP mainly occur in the U900's top cells. In this case, the
scope of call drops is located to both top cells and the entire network.
More than 90% of the increase in inter-frequency handover failures is caused by an
increase in the number of failed handovers from the U2100 to U900. In this case, the scope
of call drops is located to the entire network.

Step 3: Analyze call drops based on required actions (some required actions are followed by detailed data).
Category Data Analysis and Symptom Conclusion of Data Analysis
1. The main causes of call drops are weak coverage, inter-
frequency handover failures, and abnormal RTWP.
Identify the causes of call drops 2. Weak coverage and abnormal RTWP mainly occur in the
The main causes of call drops are weak coverage, inter-
(analysis of Performance Statistics U900's top cells.
frequency handover failures, and abnormal RTWP.
and CHRs). 3. More than 90% of the increase in inter-frequency
handover failures is caused by an increase in the number
of failed handovers from the U2100 to U900.
2G power mapping and neighboring-cell mapping are
Check parameters (full parameter
configured. LACs and RACs are normal. 2G and 3G All parameters are valid.
check).
parameters are consistent. Other parameters are normal.
Check versions (RNC and NodeB
version difference + parameter No exception No exception
difference).
Check equipment faults, alarms, and
No exception No exception
clocks.
Check RF channels (main and
diversity + cross-connected lines + External interference exists on some top NodeBs. External interference causes a large RTWP on some NodeBs.
interference).
Analyze neighboring cells (new
neighboring cells and neighboring
No exception No exception
cells on the boundaries adjacent to
peer vendors).
CIDs are insufficient on the Iur interface, causing QAAL2 setup
Check the areas adjacent to peer CIDs are insufficient on the Iur interface, causing QAAL2 setup
failures. As a result, handovers fail, and the call drop rate is
vendors. failures.
affected.
1. Inter-RAT handovers are converted into inter-frequency
handovers, which causes an increase in the number of
The number of inter-RAT handovers decreases, whereas the
Check networking policies. failed inter-frequency handovers.
number of inter-frequency handovers increases accordingly.
2. Inter-frequency handover failures cannot be rolled back,
which causes the increase in the number of call drops.
Check capacity. Not started Not started
Check coverage. Drive tests on the U900's top cells show pilot pollution. Drive tests on the U900's top cells show pilot pollution.
Check the impact of incidents (tariff,
N/A N/A
weather, and gathering).
Analyze the secular performance trend After the U900 is activated, 3G performance increases,
The U900 has better coverage than the G900, and absorbs
(seasonality + subscriber quantity whereas 2G performance decreases. The aggregate 3G and
more performance of weak coverage.
increase). 2G performance increases.
Analyze complaints and other
N/A N/A
abnormal call drops (based on CHRs).

3. The call drop rate of the U2100 increases mainly because
Step 3: Analyze call drops based on required actions.
UEs return inter-frequency handover failures.
Analyze networking policies (inter-frequency handovers and
4. The call drop rate of the U900 increases not merely
inter-RAT handovers).
because UEs return inter-frequency handover failures.
1. The number of inter-RAT handovers decreases, while the
number of inter-frequency handovers increases. The aggregate
number of inter-frequency handovers and inter-RAT handovers
does not change.
2. Inter-frequency handovers are mainly triggered by the received
signal code power (RSCP).
CS inter-frequency and inter-

system handover times
Issue closure actions:

1. Optimize the 2D2F threshold of inter-frequency handovers.
2. Enable the function of inter-frequency handover failure
rollback.

Analyze RF channels.
A large RTWP causes an increase in the call drop rate of the U900 cells. The check result shows
external interference, as shown in the following figure.

Analyze coverage.
The statistics of CHRs show a high call drop rate of the U900's top cells due to bad
RF. Drive tests show pilot pollution.

Analyze the performance trend.
1. The aggregate performance of the G900 and G1800 decreases by 10%. The performance of
the U2100 decreases by 4%. The aggregate performance of the U2100, U900, and GSM
increases by 10%.
2. The U900 absorbs many subscribers that are originally out of coverage areas. The coverage
14000 of the U900 is wide. 08/03/2012 CS 22/03/2012 CS
12000 performance 3% performance
10000
16%
8000
45%
50% 46% 21%
6000
4000
18%
2000
0
08/03/2012 22/03/2012 1%
CS Traffic(U2100 ) CS Traffic(U900 ) CS Traffic(GSM1800) CS Traffic(GSM900) CS Traffic(GSM1800) CS Traffic(GSM900)

CS Traffic(GSM900) CS Traffic(GSM1800) CS Traffic(U900 ) CS Traffic(U2100 ) CS Traffic(U900 ) CS Traffic(U2100 )
Issue closure action: The U900 has wider coverage and absorbs more subscribers in weak-coverage
areas. Clarify to customers that this is the cause of the U900's KPIs worse than those of the U2100.

Step 4: Perform issue closure actions and 1. Optimize the 2D2F threshold of inter-frequency handovers,
evaluate the effect. and perform rollback upon inter-frequency handover failures.

2. Eliminate the external interference that affects the RTWP of the

U900's top cells.
Removing the Corio interferer
Removing the Corio interferer

3. Optimize the RF of the U900's top cells.
Current Optimized
Sector
E-downtilt E-downtilt
Belmont_E2 0 3
The red circle shows the Hamlyn Heights_E1 4 6

location where pilot Hamlyn Heights_E2 4 8
pollution is improved. St.Albans Park
7 9
Sector 1
Geelong West_E2 6 8
Whittington_E1 4 6
Whittington_E2 3 5
Whitington_E3 3 4
Brekwater North_E2 3 5

4. Optimize the call drop rate at the Iur interface.
According to the distribution of call drops, the percentage of call drops on the Iur interface is
large. The analysis result shows an increase in the number of RLC setup failures due to CID
deficiency. AAL2 paths were added during the period from April 28 to April 30. The CID
congestion times decrease greatly.
field engineer incorrectly adjusted the U2100's downtilt on April. Therefore, the effect of
optimization on the Iur interface is unknown for call drop rate improvement.

The number of call drops decreases after the following actions are performed: optimization of the 2D2F
threshold of inter-frequency handovers, rollback of inter-frequency handover failures, elimination of interference
affecting the RTWP of certain NodeBs, and RF optimization for certain cells. The following figures show the
details about the decrease in the number of call drops.
120
100
U900 4.90% 0.98%
U900 Call Drop Reason-
80
11/05/2012
3.92% BadCoverage
60
40 High_RTWP
20 16.67%
PH_CH_FAIL
0
RBREL
55.88%
17.65% Startcompressmo
de_TimeOut
Pilot_Pollution
17/04/2012 11/05/2012
300 0.78% U2100 Call Drop Reason-

U2100
U2100 4.31% 11/05/2012
250
BadCoverage
200 5.49%
High_RTWP
150 15.29%
IUR_Related
100 PH_CH_FAIL
50 70.20% RBREL
0 Startcompressmode_
BadCoverage High_RTWP PH_CH_FAIL Pilot_Pollution 2.75% TimeOut
1.18% Pilot_Pollution
17/04/2012 11/05/2012

The U2100&U900 CS
drop rate increases.
The U2100 CS drop rate

The U900 CS drop rate increases.
increases.
The number of inter- Bad coverage, pilot pollution, RTWP, and

frequency handover failures inter-frequency handover failures exist.
increase.
Root Cause Root Cause Solution

1. CS inter-frequency 1. U900 coverage is not continuous. 1. Provide an inter-frequency
handovers replace inter- 2. External interference exists. handover fallback solution.
RAT handovers and inter- 3. Pilot pollution exists. 2. Optimize antenna downtilts.
frequency handovers 4. The U900 provides better coverage 3. Eliminate external
cannot fall back. than G900 and U900 absorbs more interference.
users with weak coverage.
5. Inter-frequency handovers fail and
cannot fall back.

Case 8: Combined services cause a high CS call
drop rate. (1)
Overview
According to telecom operator S of country S, the percentage of call drops caused by
combined services is about 80%. The CS call drop rate of combined services must be
optimized.
Step 1: Identify the scope of call drops. The call drop rate of the combined services on the
entire network is high, indicating that the scope of call drops is not top cells.
Step 2: Identify the causes of call drops. According to the analysis of distribution of call
drops through the NPMaster, 80% of call drops are caused by combined services.

Case 8: Combined services cause a high CS call
drop rate. (2)
Step 3: Analyze the cause of the high call drop rate of Normally, the call drop rate of combined services is greater
combined services, and optimize the call drop rate. than that of a single CS service. However, you can optimize
Combined services' requirements of signal quality: the call drop rate of combined services as follows:
Lab simulation: 1. Perform H2D or E2D rollback on combined services.
2. Limit the PS rate threshold of combined services (which can
reduce the number of call drops caused by PSDCCC signaling
interworking).
3. Set up CS services in the CELL_PCH state, reduce the P2D
process interaction to a single process, and set up CS+PS 0/0
kbit/s.
Step 4: Perform issue closure actions and evaluate the effect.
Lab tests:
UE Tx PowerTest in Lab
-30
-35 CS CS+PS
CS+PS E/HS
-40
CS+PS D8/HS
-45
CS+PS D8/D8
-50
-55

Case 9: FACH congestion results in CCH call drops.
(1)
Overview
The call drop rate in some cells of operator B in country C is high.
According to analysis results, data fails to be transmitted in the DL due to
FACH congestion, resulting in TRB resets.
Problem Analysis
Step 1: Determine the scope of the call drop problem. Call drops occur
on CCHs in some top cells.
Step 2: Analyze the reason of the call drop problem in detail.
According to analysis on Performance Statistics, many call drop causes
are caused by TRB resets.

Case 9: FACH congestion results in CCH call drops.
(2)
Step 3: Analyze required actions. Call drops occur on CCHs in some top cells.
Subsequent Closed-
Required Action Symptom and Analysis Conclusion Effect
Loop Action
1. Swapped parameter mapping
Checking parameters (all is normal. Parameters are
None
parameters) 2. Parameters related to call normal.
drops are normal.
VS.PCH.Bandwidth.UsageRate
Checking versions (differences

120.00% Version operations are not
between RNC and NodeB None
100.00% involved.
versions and parameters)
80.00%
Checking for device faults, No device alarms are generated The device and clock
60.00% None
alarms, and clock exceptions and clock status is normal. are normal.
40.00%
20.00%
No transmission alarms are
generated, transmission No transmission
Checking transmission
0.00% None
0 :0 configurations
0 :0 0 :0 :0 are normal,
0 :0 and
0 :0 :0
exceptions
0 :0
occur.
0 :0 :0 0 0 0 0 0 0
0: 0 0: 0 :
0 :0 :packets
0 0: 0 0: 0 0 0: 0 0: 0 0 0: 0: 0: 0: 0: 0:
1: 2: 3: 4:QoS 5: of 6ping 7 8: 9:is 1normal.
0: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23:
-1 1the
Actions 7 to 12:-11See -1 1-1 1-1 1-1 1-1 1-1 1-1 1-1 -1 -1 -1 1 1 1 1 1 1 1 1 1 1 1
-1 0-1 0-1 0-1No0-exceptions
1 -1 1 -1 1 1 1 1- 11- 11- 11- 11- 11- 11- 11- 11- 11- 11-
10 10 1 1 1 1 1 0 10- 10occur.
0-1 0-1 0-1 0-1 0No - exceptions
0 - 0- 0- occur.
0- 0- None
0 - 0- 0- 0 -
20 20 20 20 20 20 20 20 20 201 201 201 201 201 201 201 201 201 201 201 201 201 201
FACH data fails to be Optimize the
VS.PCH.Bandwidth.UsageRate
transmitted due to LAC.
Expand the capacity of
Checking resource capacity FACH congestion PCH paging channel An SCCPCH
top cells.
congestion in top channel is
cells. added.
Actions 13 to 16 No exceptions occur. No exceptions occur. None

Expand the capacity of CCHs.

Case 10: Seasonality and performance increase
cause a high CS call drop rate. (1)
Overview
Telecom operator O of country G has sent feedback about the call drop rate
deterioration (an average increase of about 0.2%) on multiple RNCs since the
beginning of May 2011 (time of completion of GSM upgrade). The customer
performed massive analysis and optimization, but the call drop rate was not improved.
The customer suspected that the call drop rate deterioration was closely related to
GBSS9.0 upgrade, and required help from Huawei for analysis. About China's spring
festival in 2012, the customer said that the call drop rate of Huawei's network was
worse than that of the NSN, and required Huawei to perform optimization.

Step 1: Identify the scope of call drops. According to analysis of Performance
Statistics, the scope of the call drop rate deterioration is both the entire network and
top cells.
Step 2: Identify the causes of call drops. According to analysis of Performance
Statistics, the main cause of call drops is related to the air interface.

According to analysis of the change trend of the call drop rate on multiple RNCs, the 3G call drop rate did not change much before and
after the GSM upgrade from April to May. Therefore, the 3G call drop rate deterioration is not caused by GSM upgrade.
Comparison with secular performance change of previous years shows a significant seasonal variation of performance. When summer
arrives, the CS call drop rate decreases. Comparison with the same period of previous years shows that the call drop rate of some
clusters is not smaller than that of the original network. However, the call drop rate does not decrease on August and September,
which is mainly caused by an increase in PS performance. With performance increase, CS link setup is enabled to optimize the call
drop rate at 0.3% to 0.4%.

Step 4: Perform issue closure actions and evaluate the effect.
1. Seasonal factors have significant impact in many areas. Seasonal change causes change
in radio environments and performance. For example, thunderstorm increase in summer
and dense tree leaves change radio environments.
2. According to analysis of the distribution of call drops on the live network, the main cause of
call drops is RF, which results from PS performance increase and coverage shrinkage. The
change trend of the CS call drop rate in 2011 is not completely consistent with that in 2012.
3. According to analysis of the change trend of the call drop rate, the 3G call drop rate of the
areas in the same coverage does not deteriorate (the time points are different; the time of
3G call drop rate deterioration is close to that in 2010). Therefore, the 3G call drop rate is
not affected by GSM upgrade.
The customer recognized Huawei's analysis after the preceding factors were clarified. Huawei
provided the measure (call link re-establishment) of optimizing the CS call drop rate. The CS
call drop rate was optimized at 0.3% to 0.4%.

Case 11: Call drops are caused because combined
services of BlackBerry terminals are refused in security
2. Analysis on abnormal signaling procedures
mode.(1) Combined services exist. 505 is the CN in the CS domain (1) and 506 is the CN in the PS
domain (2).
Overview
(2) The services in the PS domain are released after PS RAUs are complete (3).
Subscribers complain
(3) The that aBlackBerry
UE initiates terminals
PDP activation request often experience
in the PS domain. Atcall
thisdrops in operator
moment, I of
the CN in the
country M. This problem
PS domain is caused
delivers by BlackBerry
the security terminal
mode command. Thecompatibility
UE receives the problems.
command Inbutcase
does of
combined services, PS Then
not respond. services are are
services released when
released duo toCS services
timeout. [Theare
CN retained. After PS
in the PS domain services
does
are established again,authentication.]
not deliver BlackBerry terminals do not respond in security mode if the CN directly
places the PS services in security mode instead of firstly authenticating the PS services,
leading to CS call drops.
Problem Analysis
Step 1: Determine the scope of the call drop problem. According to PCHR logs, the call
drop rate of combined services is high on BlackBerry (BB9700) terminals.
Step 2: Analyze the reason of the call drop problem in detail. Call drops occur in combined
services of top terminals, and therefore you are advised to analyze call drop causes by tracing
signaling. Steps 1 and 2 correspond to action 1. Other actions are not required.
Step 3: Resolve the problem. The authentication switch for paging response and MS
Service request is turned on the SGSN side.

Case 12: Call drops occur during a conference call
because Ericsson CN is required.
Overview
VIP customers complain that CS call drops frequently occur for operator T in country M.
Problem Analysis
Step 1: Determine the scope of the call drop problem. VIP customers complain about call drops. Analyze
CHRs of VIP customers including CN CHRs and RNC PCHRs. According to analysis results, VIP customers
experience call drops during a conference call. Cases are as follows:
Case1: C calls B while A is calling B, B holds A and answer C, then silence problem happens and call drops about 10 seconds later.
Case2: C calls A while A is calling B, A holds B and answer C, then silence problem happens and call drops about 10 seconds later.
Step 2: Analyze the reason of the call drop problem in detail. Trace signaling of VIP call drops and find that
Huawei and Ericsson have different understanding on related protocols. The RNC cannot properly handle the
second assignment delivered by the CN and therefore customers experience mute voices or call drops. To
prevent this situation, the same registration priority is configured on the CN (that is, the second assignment is
not triggered). The logs of abnormal call drops for the second assignment are as follows:
Steps 1 and 2 correspond to action 1. Other
actions are not required.
Note: The RNC does not support the second

assignment delivered by the CN. The
handling procedure will be modified in
RAN14.0, that is IUUP initialization is not
performed in RAN14.0.

Support Tools Related to Required Actions of
Troubleshooting Call Drops
Efficiency Evaluation on Required Actions for

Call Drops

How to Obtain Tools
Tool Name Function How to Obtain Contact Person of R&D

http://support.huawei.com/support/page
Identify the causes s/editionctrl/catalog/ShowVersionDetail.
NPMaster of call drops. do?actionFlag=clickNode&p_line=&node Huang Xiangrong
Analyze CHRs. =000001410343&colID=ROOTWEB|CO
0000000065&
s/kbcenter/view/product.do?actionFlag= Ma Sufen: owner of the
Analyze neighboring
NASTAR detailProductSimple&web_doc_id=SC00 network planning
cells.
00696179&doc_type=ProductManual&d topic/OSS
oc_type=ProductManual
s/kbcenter/view/product.do?actionFlag=
Checks parameter Lin Ankun: owner of the
CME detailProductSimple&web_doc_id=SC00
consistency. parameter topic
00704315&doc_type=ProductManual&d
oc_type=ProductManual
Parameter Check all Topic of full parameter

check tool parameters. check
Analyze
PRS/OMStar Performance
Statistics.

Support Tools Related to Required Actions of
Troubleshooting Call Drops
Efficiency Evaluation on Required

Actions for Call Drops

Efficiency Evaluation on required actions for
Dropped Call Problems (1)
Processing Duration Processing Duration
Required Action Tool
Required by Tools Required by Manual Analysis
Performance
Action 1: identifying call drop causes by Statistics: 30 Performance Statistics: 30
Performance Statistics: OMStar
analyzing Performance Statistics and minutes/RNC minutes/RNC
CHR: NPMaster
CHRs CHR: 3090 CHR: 3090 minutes/RNC
minutes/RNC
Action 2: checking parameters (all Parameter check tools
1-5 minutes/RNC 30-90 minutes/RNC
parameters) (NPMaster and OMStar)
Action 3: checking versions
(differences between RNC and NodeB None None Unknown
versions and parameters)
OMStar and alarm console 5 minutes/RNC 30-60 minutes/RNC
Action 5: checking transmission None None Unknown
For details, see UMTS RF
Channel Problem Detection and
Action 6: checking RF channels for Rectification Factors of RTWP tool for main and
main and diversity channels, cross Impact+Troubleshooting+Method 5s/site diversity channels: 5s/site
pairs, and interference s and Tools+Deliverables. Manual analysis: 30s/site
Tools for analyzing RTWP logs
of main and diversity channels
For cells with missing
Action 7: analyzing neighboring cells
neighboring cells or top N cells,
on new networks and swapped Nastar 30 minutes
the processing takes 1 to 3
networks
minute per cell.
Signaling: unknown
Action 8: checking joint areas of Signaling: unknown
Signaling: FMA/UMAT Performance
Huawei RNCs and RNCs from peer Performance Statistics: 1020
Performance Statistics: OMStar Statistics: 1020
vendors minutes/cell
minutes/cell

Efficiency Evaluation on required actions for
Dropped Call Problems (2)
Processing Duration
Processing Duration
Required Action Tool Required by Manual
Required by Tools
Analysis
CHR: NPMaster CHR: 3090 minutes/RNC
Action 9: analyzing impacts of service
Performance Performance Statistics: 20 30-90 minutes/RNC
bearing between modes
Statistics: OMStar minutes/RNC
Action 10: checking call drops of
combined services (CS call drops)
NPMaster CHR: 3090 minutes/RNC CHR: 3090 minutes/RNC
Action 10: checking call drops on common
channels (PS call drops)
Action 11: checking networking policies None None Unknown
For details, see the capacity-related topics in UMTS Network Optimization:
Action 12: checking resource capacity
Process+Principle+Tool+Deliverables.
Action 13: checking coverage None None 60 minutes/RNC
Action 14: checking abrupt events such as
A long time for obtaining data
charging policy changes, weather N/A N/A
and 10 minutes for analyzing
changes, and mass gatherings.
Action 15: analyzing the long-term
A long time for obtaining data
performance trends due to seasonal N/A N/A
and 10 minutes for analyzing
changes and subscriber number increase
Analysis on statistics: 3060
Action 16: analyzing complaints about call
minutes/RNC
drops and other abnormal call drops NPMaster 10-30 minutes/RNC
Analysis on a single call: 3-10
(CHR)
minutes/call

List of Deliverables
Deliverable Description
Call Drops of UMTS Voices+CS
Services: Impact Describes how to analyze call drop causes
Factors+Troubleshooting Methods and provides methods.
and Tools+Deliverables
UPSS V100R003C00 Guide to
Describes how to analyze call drop causes in
Troubleshooting Call Drops of CS
detail.
and PS Services
[xxx Project] Template of the field engineer troubleshoot problems and
Analysis Report for Call Drops provide the template.
Describes how to perform statistics on
Guide to Designing Call Drop Tools
various call drop causes.
Describes how to use the NPMaster and how
NPMaster User Manual.chm
to use the function of analyzing call drops.

Thank you
www.huawei.com

UMTS Call Drop Impact Factors Troubleshooting Methods and Tools Deliverables V4.0

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UMTS Call Drop Impact Factors Troubleshooting Methods and Tools Deliverables V4.0

Enviado por

Direitos autorais:

Formatos disponíveis

Security Level: INTERNAL

UMTS Call Drop: Impact

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential

Date Version Description Reviewer Author

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 3

The following table lists information about R&D support personnel.

Name Telephone Number

Qian Jin (employee ID: 64231) See Huawei phone book.

Zheng Jianhua (employee ID: 42104) See Huawei phone book.

Huang Xiangrong (employee ID: 00137761) See Huawei phone book.

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 4

Cause Analysis of Call Drops and Data Source Processing

Standard Analysis Actions and Deliverables for Call Drops

Cases Related to Call Drops

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 5

UE NodeB RNC MSC

Rab/IU Release Command

Rab/IU Release Complete

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 6

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 7

ON - Normal Normal ON - Normal Normal

ON Abnormal Abnormal Abnormal ON Abnormal Abnormal Abnormal

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential

The formula for calculating the PS call drop rate is as follows:

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 9

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 10

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 11

PS call drops on the DCH may be caused by incremental HSPA call

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 12

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 13

Dropped calls related to a single service/composite services

Dropped calls resulting from

Dropped calls resulting from

Dropped calls resulting from

Dropped calls resulting from

timeout of PS waiting for IU

the RB_SET UP process of

SRB reset in safe mode

the RB_REL process of

REL COM MAND

Interface class Equipment class Basic RF class Networking

Dropped calls resulting from the

Dropped calls resulting from the

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 14

SRB reset in security

RB_RECFG process call

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 15

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 16

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 17

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 18

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 19

Cause Analysis of Call Drops and Data

Troubleshooting Methods and Deliverables

Cases Related to Call Drops

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 20

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 21

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 22

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 23

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 24

Signaling (intelligent optimization system [IOS] tracing)

Drive test data

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 25

HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 26