Вы находитесь на странице: 1из 8

AnalyzeDropCall

T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200

Objective
To find the source of drop call problem detected from the statistics. This document contains the way of
distinguishing this problem from others by using statistics, comparing all involved parameter/configuration
with the previous ones, checking functions of all involved hardware, and end up with initiating an observation
to get results giving to system planner. If there is any obvious result from observations, the solutions can be
proposed. This document does not cover how to define parameter/configuration to solve the problems.

Abstract
This document describes the procedure how to analyze drop call problem which can be done in many ways.
The first step in trouble shooting dropout is identifying those cells which will contribute the most to the overall
dropout rate for the network. This will have already been done in the AIS network in the daily dropout report
generated. Then the component causing most dropouts needs to be identified.
Radio failure is a common cause for dropped calls. The reasons for radio failure can be due to any number
of causes, which will generally result in the signal level or quality not being good enough to hold a call. The
causes for poor signal strength can be varied, from interference, or poor coverage levels to equipment
problems (such as water in the feeders, loose connections, antenna misalignment etc.) to configuration
problems (adjacencies misdefined, poor parameter settings etc.) or even be a factor of the environment such
as a steep hilly terrain with water and deep valleys or a dense skyscraper terrain with lots of reflections and
handling calls from within buildings with the associated problems. Even if there seems to be no obvious
problem with the radio path other problems in the system however unlikely can manifest themselves as radio
problems such as a case where sudden and very large drops in signal strength causing consistent dropouts
resulted in the entire changeout of BTS equipment before a problem with the 2Mb link was finally identified
as the cause. Any extra features or hardware configurations need to be kept in mind and also the alarm
manual which describe a simple method of locating the hardware problem and the solution.

Prerequisite
Indentifying the Performance Problems

All reports need to be analysed regularly and also in the case of rapid changes in the NW. At the cell level,
problematic cells are investigated daily and in greater detail. In the case of rapid changes it is important to
know what has happened; was it because of planned work, external interference or HW fault ?

Quality of service Indicators

Quality of Service is defined with several different indicators, e.g. dropped call rate, congestion, etc. If even
one of the indicators does not fulfil the criteria, the overall QoS cannot be reached. For each of the
indicators, the criteria have to be defined and the overall target is to reach these criteria and preferably
exceed them. All these factors define the quality that the subscriber will experience.

These indicators have to be taken from the network and analysed continuously. The defined levels can be
achieved by understanding the major Quality of Service problems and addressing them first. Once the
network has reached the quality level indicated in these figures, the QoS requirements can be brought to the
next level.

The indicator below is for NWs where Intelligent Underlay-Overlay and Frequency Hopping features are not
in use. These features will affect HO Success Rate and Quality values. In addition, Frequency Hopping can
increase drop call rates because some of the mobiles on the market do not hop correctly.

The indicators of TCH Drop Ratio [%], 24h for short term criteria is 5 % and for long term criteria is 3 %

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 1/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200

The indicators of Commutative UL quality distribution, 24 h short term criteria is 04 , 95%


Long term criteria is 04 , 98%

The indicators of Commutative DL quality distribution, 24 h short term criteria is 04 , 95%


Long term criteria is 04 , 98%

Rx Quality coding is:


GSM 05.08 (8.2).
Qua 0 = less than 0.2% (BER)
Qua 1 = 0.2% to 0.4% (BER)
Qua 2 = 0.4% to 0.8% (BER)
Qua 3 = 0.8% to 1.6% (BER)
Qua 4 = 1.6% to 3.2% (BER)
Qua 5 = 3.2% to 6.4% (BER)
Qua 6 = 6.4% to 12.8% (BER)
Qua 7 = greater than 12.8% (BER)

Network doctor report

BSS Network Doctor is a reporting package which provides effective tools to cover all functional areas of the
NMS/2000: Configuration Management, Fault Management, and Performance Management (PM), with
special focus on the needs of network planning, operation and maintenance.

Self-documented reports with front-page description and column headers guarantee that the basic
information is always where it is needed.

There are the examples of network doctor which concerning with analyzing drop call .

Report 063 : BTS audit


Report 153 : Adjacencies having high HO failure ratio
Report 163 : Cell having high TCH drop call ratio
Report 164 : Transcoder failures
Report 166 : SDCCH drop ratio per cell
Report 190 : Cell having UL interference, 24-hour/10-day breakdowns
Report 195 : Cell by DL and UL level balance
Report 196 : UL and DL quality and UL interference per TRX, 24-hour/10 day breakdowns
Report 213 : Cell doctor to see the details of a BTS on periodical basis for all counters and also the alarms
and parameters across the selected period.
Report 216 : Cell analyser to see the average and busy hour values and 10-day/24-hour profiles of the most
Important indicators ending on the selected day.Cell analyzer offers versatile information about
The parameters , key performance indicators, consistencies and alarms for analysing a single
BTS.

The explanation of each network doctor reports will display in front of report which you generate. And also
you can read in Network Doctor User Guide[4].

Procedure

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 2/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200

Trouble shooting of drop call is one of the routine things need to do . You must start by looking at basic drop
call results from the daily running measurements.

1. Follow up of the TCH drop call rate across a maintenace region or BTS group on cell basis.

2. Spot the problematic cell from TCH drop out ratio.

The key performance indicators (KPIs) Short term criteria Long term criteria
TCH Drop ratio (%) , 24 h 5 3
SDCCH Success Ratio(%) ,24 h 95 97

3. Determine whether the the high drop call rate is related to RF, Abis or TC by drop out failure type
(Report 163) The detail of the network doctor report see in prerequisite.

sum(a.tch_radio_fail+a.tch_rf_old_ho+a.tch_abis_fail_call+a.tch_abis_fail_old+
a.tch_a_if_fail_call+ a.tch_a_if_fail_old+ a.tch_tr_fail+ a.tch_tr_fail_old+
a.tch_lapd_fail+ a.tch_bts_fail+ a.tch_user_act+ a.tch_bcsu_reset+
a.tch_netw_act+a.tch_act_fail_call)
Drop call ratio = 100 -100* -------------------------------------------------------------------------------------------------------
%
sum(a.tch_norm_seiz) ;(normal calls)
+ sum(c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch) ;(calls started via DR)
+ sum(a.tch_seiz_due_sdcch_con) ; (calls started as FACCH call setup)
+ sum(c.msc_i_tch_tch+c.bsc_i_tch_tch) ;(TCH-TCH Ho from other cells)

a = p_nbsc_traffic table
c = p_nbsc_ho table

Also check the outgoing Handover failure ratio to the neighbour cell (Report 153) . If outgoing HO fail
ratio is high ,the drop call may cause by problem in that neighbour cell. So continue with investigating
the problem for the target BTS cell [1] first

Ho failure ratio to adj. Cell = 100*( sum(ho_att_to_adj - ho_succ_to_adj)/ sum(ho_att_to_adj)

HO failure ratio from adj.Cell = 100*( sum(ho_att_from_adj - ho_succ_from_adj)/ sum(ho_att_from_adj))

All counters are from the p _nbsc_ho_adj table.

4. From drop out failure type in network doctor report 163 , if hi drop call rate is related to RF reason.
Check following item.

4.1 Any change on neighbor list or frequency plan?


If there is some recent change which affect the problem , so send job to system planning.

4.2 Link balanced


Is the link unbalanced ? (Report 195)

Average UL signal strength = sum(ave_ul_sig_str)/sum(power_denom4)

Average DL signal strength = sum(ave_dl_sig_str)/sum(power_denom3)

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 3/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200

All counters are from the p_nbsc_power table

At the beginning of plan , link is balance . But later when some hardwares go faulty or cable is
broken , these will cause unbalance link .
If the DL is worse then check the transmitter path including transmitter .
If the UL is worse then check receiver path including receiver ,cables, LNAs , connectors.

4.3 Bit error rate


Is UL/DL having high B.E.R.? (Report 196)

Sum(a.freq_ul_qual0 + ... + a.freq_ul_qualX)


Cumulative % of uplink call samples = 100 *
---------------------------------------------------------------- %
Sum(a. freq_ul_qual0 + ... + a.freq_ul_qual7)

sum(a.freq_dl_qual0 + ... + a.freq_dl_qualX)


Cumulative % of downlink call samples= 100 * -------------------------------------------------------------- %
sum(a. freq_dl_qual0 + ... + a.freq_dl_qual7)

All counters are from the p_nbsc_rx_qual table.

If DL have high bit error rate because of interference (Report 213 ),check frequency plan or TRX.
If UL have high bit error rate because of interference (Report 190),

sum(ave_idle_f_TCH_1/res_av_denom4)
UL interference, BTS level, S1 = 100x (1- -------------------------------------------------------------------- ) %
sum(ave_idle_f_TCH_1/res_av_denom4+
ave_idle_f_TCH_2/res_av_denom5+
ave_idle_f_TCH_3/res_av_denom6+
ave_idle_f_TCH_4/res_av_denom7+
ave_idle_f_TCH_5/res_av_denom8)

All counters are from the p_nbsc_res_avail table.

Check following possible reason:

4.3.1 In-band interference ? Check from frequency plan. If not go to 4.3.2


4.3.2 External interference ? Check by drivetest or spectrum Analyser. If not go to 4.3.3
4.3.3.Receiver faulty ? Check the alarm. If not go to 4.3.4
4.3.4TRX faulty? Check the alarm .

If the reason is not from interference ,so check for all neighbour relations and
discrepancies .

4.4 Wrong cell serving


Check TA statistic by report 213 , 216 (cell analyzer) and drivetest analysis.
If the cell serving an area that it should not serve ,Send the job to system planner to redefine
antenna configuration.

4.5 The other reasons ex. The coverage hole


In this scennario the serving cell is the right one ,however there is lack of coverage and the area
could not be well covered because of lack or poor performance of sites.

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 4/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200
Investigate by drivetest that area.

5. If there doesnt seem to be any obvious reason for the high RF failures then check the alarms for
hardware faults that will usually result in poor signal levels and perhaps poor quality. If there are alarms
in problem period, check the severity of the alarm and correct the fault situation [2] .

Besides RF problem ,there are many reason can be example : Cell going down on that time , a fatal
error in the BSC or MSC , fatal error at the BTS and/or the transmission from BTS to BSC ,BCSU
reseting, blocked TRX ,problem in the PSTN .Check all these relative event by Trouble Ticket System
program.

6. Compare the parameter of the cell with the default parameter .


Report 63 in network doctor can help you to check the cell parameter in maintenance region against
default parameter which store in NMS database. The result will tell you which cell has difference
parameter than default.
If everything is already checked , send the job to system planner for consider parameter modification.
7. If there are still some dropouts that havent been identified by following the above procedures then there
are still some further steps that can be taken. First get more information by analyse drive test data on
that area .You can use NMS/X 5.2 User Manual and Measurement SW User Manual [5][6] as a reference.
After that if you still cannot identify the reason of dropouts , One is to set up the relevant observation
example activate trace call in MSC .To do this ,see Technical Manual T016 [7] . The other alternative is to
do an abis trace but it is very labour intensive alternative. You have to connect the Abis analyser to the
cross connection between BSC and BTS for tracing signalling on TRXs .

The dropouts that occur on the SDCCH are mainly due to the same reason as that for TCH dropouts.
The only difference to consider here is the differing functionality of the SDCCH compared to the TCH.
Usually the SDCCH is defined in only one or two timeslots for a cell and so if there is a fault with one of
these timeslots then the dropout rate will be more severe than that corresponding for TCH. The SDCCH
is used in call set up on the cell, SMS and location update. The call origination can be from the SDCCH
- TCH of the same cell or SDCCH TCH of a neighbouring cell in the case of directed retry, so although
the SDCCH is not actively involved in the handover process a failure on the SDCCH during a directed
retry is in effect a handover failure for whatever reason the failure occurred (e.g. Hardware or RF).
Interference can cause the cell suffering from quality .Too many Location Updates due to LA not suitable
can cause also. Additional the bad coverage will effect to SDCCH drop .See detail in T029. [3]

Reference
[1] O&M-PAS6W1-T026-G-Nokia (Analyze Handover Performance)
[2] BSC NED Documentation, S7 Level / Alarm Reference Manual
[3] O&M-PAS6W1-T029-G-Nokia (Analyze Unsuccessful Call Setup)
[4] Network Doctor User Guide.
[5] NMS/X 5.2 User Manual.
[6] NMS/X 5.2 Measurement SW User Manual.
[7] O&M-PAS3W4-T016-G-Nokia (Initiate Mobile Observation)

Counters of P_NBSC_HO_ADJ table.

HO_ATT_TO_ADJ The number of handover attempts to the adjacent cell.

HO_SUCC_TO_ADJ The number of successful handovers to the adjacent cell.

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 5/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200
HO_ATT_FROM_ADJ The number of handover attempts from the adjacent cell.

HO_SUCC_FROM_ADJ The number of successful handovers from the adjacent cell.

Counters of P_NBSC_HO table


MSC_I_SDCCH_TCH The number of successful SDCCH>TCH handovers
(an MSC-controlled incoming handover)

MSC_I_TCH_TCH The number of successful TCH>TCH handovers


(an MSC-controlled incoming handover)

BSC_I_SDCCH_TCH The number of successful SDCCH>TCH handovers


(BSC-controlled incoming handovers)

BSC_I_TCH_TCH The number of successful TCH>TCH handovers


(BSC-controlled incoming handovers)

Counters of P_NBSC_RES_AVAIL table.

TCH_CONG_TIME Total TCH channel busy time in a measurement period.

AVE_IDLE_F_TCH_1 The average number of idle full rate TCHs per interference band1.

AVE_IDLE_F_TCH_2 The average number of idle full rate TCH per interference band 2.

AVE_IDLE_F_TCH_3 The average number of idle full rate TCHs per interference band3.

AVE_IDLE_F_TCH_4 The average number of idle full rate TCHs per interference band4.

AVE_IDLE_F_TCH_5 The average number of idle full rate TCHs per interference band5.

RES_AV_DENOM4 The denominator of the average number of idle full rate TCHs per
interference band (always>0).

RES_AV_DENOM5 The denominator of the average number of idle full rate TCHs per
interference band (always>0).

RES_AV_DENOM6 The denominator of the average number of idle full rate TCHs per
interference band (always>0).

RES_AV_DENOM7 The denominator of the average number of idle full rate TCHs per
interference band (always>0).

RES_AV_DENOM8 The denominator of the average number of idle half rate TCHs per
interference band (always>0).

Counters of P_NBSC_TRAFFIC table


TCH_RADIO_FAIL Number of TCH transaction failures due to radio failure

TCH_RF_OLD_HO Number of TCH transaction failures due to a radio failure of the old channel

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 6/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200
during a TCH handover

TCH_TR_FAIL Number of TCH transaction failures due to transcoder failure

TCH_TR_FAIL_OLD Number of TCH transactions ended due to transcoder failure of an old


channel during a handover on a TCH.

TCH_ABIS_FAIL Number of TCH transaction failures due to Abis interface failure

TCH_LAPD_FAIL Number of TCH transaction failures due to LAPD failure

TCH_BTS_FAIL Number of TCH transaction failures due to BTS failure

TCH_USER_ACT Number of TCH transaction failures due to user actions

TCH_BCSU_RESET Number of TCH transaction failures due to BCSU reset

TCH_NETW_ACT The number of TCH transaction failures due to radio network reconfiguration
actions

TCH_A_IF_FAIL The number of TCH transaction failures due to an A-interface failure

TCH_ACT_FAIL_CALL Number of TCH transaction failures due to activation failure during a call
attempt

TCH_ABIS_FAIL_OLD Number of TCH transaction failures due to Abis interface failure on the old
channel during a TCH handover

TCH_A_IF_FAIL_OLD Number of TCH transaction failures due to A-interface failure on the old
channel during a handover attempt

TCH_SEIZ_DUE_SDCCH_CON Successful seizures of TCH due to SDCCH Congestion

TCH_NORM_SEIZ Number of successful TCH requests for a normal assignment

Counters of P_NBSC_POWER table


AVE_DL_SIG_STR Average downlink signal strength measured in the cell.

AVE_UL_SIG_STR Average uplink signal strength measured in the cell.

POWER_DENOM3 The denominator of the average downlink signal strength measured in the
cell. (always>0)

POWER_DENOM4 The denominator of the average uplink signal strength measured in the cell.
(always>0)

Counters of P_NBSC_RX_QUAL table


FREQ_UL_QUAL0 Frequency of samples (calls) where uplink Rx Quality was 0.

FREQ_UL_QUAL1 Frequency of samples (calls) where uplink Rx Quality was 1.

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 7/8
AnalyzeDropCall
T030-G
S/W Revision : BSC S7
Nokia : OMC/NMS2000 T10
H/W Revision : DX 200

FREQ_UL_QUAL2 Frequency of samples (calls) where uplink Rx Quality was 2.

FREQ_UL_QUAL3 Frequency of samples (calls) where uplink Rx Quality was 3.

FREQ_UL_QUAL4 Frequency of samples (calls) where uplink Rx Quality was 4.

FREQ_UL_QUAL5 Frequency of samples (calls) where uplink Rx Quality was 5.

FREQ_UL_QUAL6 Frequency of samples (calls) where uplink Rx Quality was 6

FREQ_UL_QUAL7 Frequency of samples (calls) where uplink Rx Quality was 7.

FREQ_DL_QUAL0 Frequency of samples (calls) where downlink Rx Quality was 0.

FREQ_DL_QUAL1 Frequency of samples (calls) where downlink Rx Quality was 1.

FREQ_DL_QUAL2 Frequency of samples (calls) where downlink Rx Quality was 2.

FREQ_DL_QUAL3 Frequency of samples (calls) where downlink Rx Quality was 3.

FREQ_DL_QUAL4 Frequency of samples (calls) where downlink Rx Quality was 4.

FREQ_DL_QUAL5 Frequency of samples (calls) where downlink Rx Quality was 5.

FREQ_DL_QUAL6 Frequency of samples (calls) where downlink Rx Quality was 6

FREQ_DL_QUAL7 Frequency of samples (calls) where downlink Rx Quality was 7.

Index

Document No: O&M-PAS6W1-T030-G-Nokia AIS & Nokia Confidential Rev.:A2 Date:29/3/1999 Page 8/8