analyze drop call t030 g

Analyze Drop Call T030-G

Nokia S/W Revision : BSC S7 : OMC/NMS2000 T10H/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 /8



The indicators of Commutative UL quality distribution, 24 h short term criteria is 0…4 , 95%Long term criteria is 0…4 , 98%

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

Long term criteria is 0…4 , 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 auditReport 153 : Adjacencies having high HO failure ratioReport 163 : Cell having high TCH drop call ratioReport 164 : Transcoder failuresReport 166 : SDCCH drop ratio per cellReport 190 : Cell having UL interference, 24-hour/10-day breakdownsReport 195 : Cell by DL and UL level balanceReport 196 : UL and DL quality and UL interference per TRX, 24-hour/10 day breakdownsReport 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




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 criteriaTCH Drop ratio (%) , 24 h 5 3SDCCH 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 tablec = 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)




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 rateIs 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.24.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.44.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 holeIn 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.




Investigate by drivetest that area.

5. If there doesn’t 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 haven’t 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.




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




RES_AV_DENOM4 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 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_QUAL6 Frequency of samples (calls) where uplink Rx Quality was 6


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






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


Index

-


analyze drop call t030 g

Documents