#NSN-004 Title [Alt+T] (34 Pt/auto Pt)

BSS Performance Troubleshooting InstructionsTCH Drop (Abis Reason) Version 0.2document description

Title and versionPerformance troubleshooting instructions - BSS

Reference

Target GroupNPO engineers (working in NOA projects)

Technology and SW release2G, 2.5G

Related Service ItemsRadio network optimization / Capacity Extension Management

Service Item number

AuthorKarri Sunila

Date-

ApproverEric Kroon

Change RECORD

This section provides a history of changes made to this document

VersionDateEdited bySection/SComments

0.125.02.2010Karri SunilaALLFirst draft:

0.208.03.2010Karri SunilaALLModifications based on comments

Copyright Nokia Siemens Networks. This material, including documentation and any related computer programs, is protected by copyright controlled by Nokia Siemens Networks. All rights are reserved. Copying, including reproducing, storing, adapting or translating, any or all of this material requires the prior written consent of Nokia Siemens Networks. This material also contains confidential information which may not be disclosed to others without the prior written consent of Nokia Siemens Networks.

Table of Contents3Table of Contents

41.Purpose and Scope

52.TCH Drop (Abis Reason)

52.1DCR KPIs

62.2Referencing KPIs to be checked

62.3Call related DX causes (Clear code observation)

92.4Referencing Features

93.Troubleshooting

93.1Alarms

93.2Drops in different call phase

93.3Quality / Interference

113.4Coverage

123.5Observation

1. Purpose and ScopePurpose:

This document is an optimization guideline with the purpose to instruct NPO engineers working in NOA projects to deliver performance troubleshooting.This document is meant for INTERNAL USE ONLY

Scope:

The scope of the document is the following:

To show how to troubleshoot cells to improve certain KPIs.Note! All the networks are different and thus is heavily recommended to analyze network properly before optimization. Also properly optimization strategy should be created, will it be better to use special cell level optimized parameter values and loose control of the network or use some general (not cell level optimized) values.

2. TCH Drop (Abis Reason)Dropped call ratio is one of the most important indicators to monitor the network quality. Dropped TCH means that TCH transaction ended because of a radio failure on the source channel. Reason for drops can be different. In following chapters drop call rate related KPIs are described and some troubleshooting instructions, how to find the reason for dropped calls.2.1 DCR KPIs

The formula of the Drop Call Rate is defined as the ratio between the failures occurred during the call and the number of calls occurring during the observed time

Different formulas can be developed according to the period of observation and the area of observation, according to customer needs. The different approaches / different drop call KPI triggering points can be seen here (attached file)

A benchmarking KPI for TCH drop call rate is dcr_5a

Different drop reasons can be seen dcr_3j is used:

Abis related counters are, if formula

1084 TCH_abis_fail_call

1085 TCH_abis_fail_old

Typical reason for abis drop is typically Abis/PCU related problems. RF reason can effect on drop, so it is recommended to check all possible reason. More information, please see troubleshooting 32.2 Referencing KPIs to be checkedDropped call is not a reason, it is always a consequence. In this chapter DCR related KPI are mentioned. These KPIs should be always checked in parallel with DCR KPI2.3 Call related DX causes (Clear code observation)

Clear Code Observation contains information on the clear codes that indicate a failure in a call. The failure may lead to call dropping or inform about handover problems.

TCH drop in Abis reason can be analyzed with following counters:

1084 TCH_abis_fail_call

This counter is updated in call phases 1-8 and phase 15 only. 1085 TCH_abis_fail_old

This counter is updated in call phases 9-11 only.Call Phases:

1. Paging/initial MS on CCCH

2. MM signalling

3. Basic assignment

4. Release

5. FACCH assignment

6. SMS establishment on TCH

7. SMS establishment on SDCCH

8. Ciphering

9. External handover for source side

10. Internal handover intra for source side

11. Internal handover inter for source side

12. External handover for target side

13. Internal handover intra for target side

14. Internal handover inter for target side

15. Conversation

It is good to know which DX causes are triggered in call phase 1-8/15 or 9-11, so which is more detailed reason (DX cause) for TCH drop (Abis)

More detailed information related capacity optimization access transmission can be found from IMS

https://sharenet-ims.inside.nokiasiemensnetworks.com/livelink/livelink?func=ll&objId=413652220&objAction=Open&vernum=1&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dsrch%2ESearchCache%26cacheId%3D170421082.3.1 Quality (ulq_2a,dlq_2a, Rx_Level_Statistics table)

Bad quality is typically measured as BER (bit error rate) or as FER (frame erasure rate). The FER Measurement provides the uplink frame erasure rate (UL FER) from each codec of each TRX in the BTS.. In this document quality (DL and UL) is measured using BER measurements.Bad quality is effecting heavily on Drop call rate. In this chapter it is shown how quality can be measured and how to analyze if quality is on reason which is causing TCH drops in the network. In Troubleshooting chapter more detailed information, how to analyze bad quality is described

Most of the triggering (counter 1084) are a related to missing Establish_indication -message (timer T3101 expires). Reason for this typically is not always related to Abis-interface itself but for instance improvements of the radio interface can reduce the triggering of this counter. This is the reason why quality / coverage should be also checked when abis related problems are solved.

2.3.2 Coverage (Rx_Level_Statistics table)

Bad coverage means that received signal level is near the (MS/BS) sensitivity level. Here the quality will be decreased due to bad signal level and like bad quality, this bad quality will cause user perceived problems

Like quality, coverage should be also checked even drops are more abis related drops.

Note! It should be checked that there is no imbalance problems between UL and DL. Many times UL is the weaker one ,so UL coverage should be also checked.

2.3.3 Abis blocking (dap_7,dap_9) dap_7 Inadequate EDAP resources in DL,min/KB Time per kilobytes when adequacy of requested EDAP resources cannot be granted for a scheduled DL TBF in BTSs where EGPRS is enabled. dap_9 Downlink MCS selection limited by PCU Time per gigabytes when adequacy of requested EDAP resources cannot be granted for a scheduled DL TBF in BTSs where EGPRS is enabled. Only PCU limitations are considered. 2.4 Referencing Features

Dynamic Abis TroubleshootingDropped call is always a consequence, not a reason. In this chapter some troubleshooting items, which should be checked when analyzing DCR KPI, are mentioned.There are many times several reasons for KPI degradation, so all step should be checked to be sure that reasons for dropped calls will be found.

2.5 Alarms

Check that there are no any ** or *** active alarms. Connection to NetAct is needed.2.6 Drops in different call phase

Tch_abis_fail call gets triggered when there are problmes in Abis interface and messages are lost or corrupted.

Most of the triggering(counter 1084) are anyhow related to missing Establish_indication -message (timer T3101 expires). Reason for this typically is not always related to Abis-interface itself but for instance improvements of the radio interface can reduce the triggering of this counter.

Also some BTS faults did cause increase. => Better always to check the BTS alarms if it is bothering individual BTS.More information, see document Call Related DX Causes in BSCMore detailed information related capacity optimization access transmission can be found from IMS

https://sharenet-ims.inside.nokiasiemensnetworks.com/livelink/livelink?func=ll&objId=413652220&objAction=Open&vernum=1&nexturl=%2Flivelink%2Flivelink%3Ffunc%3Dsrch%2ESearchCache%26cacheId%3D170421082.7 Quality / Interference

Bad quality is the most common reason for dropped calls. Some troubleshooting steps to reduce interference are mentioned below

Rx_Level_satistics table can be used for quality/interference analysis

If bad quality in good signal level,(>-75dB) Frequency changes (new frequency plan) should be done. This is the worst situation, because no better cell available to make interference HO. Interference HO threshold can be adjusted to for example -75dB to make the difference between quality HO and interference HO more clear

If bad quality in signal level,(-75dB..-100dB) Frequency changes can be done to reduce interference

Handover Threshold Parameters, level, quality, interference. Threshold values and Px,Nx values can be adjusted

Normally some overlapping exists, so HOs to adjacency, reasons quality/Interference will happen.

Checked that no missing adjacency cells. Missing neighbors can be one reason for bad quality, serving areas are not working properly.

If AMR feature can be used, Handover Threshold Parameters, level, quality, interference. Threshold values and Px,Nx values can be adjusted little more loose.

If bad quality in bad signal level,(