Performance Troubleshooting -CS - TCH Drop(RF) v0.2

17
BSS Performance Troubleshooting Instructions TCH Drop (RF Reason) Version 0.2

Transcript of Performance Troubleshooting -CS - TCH Drop(RF) v0.2

Page 1: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

BSS Performance Troubleshooting Instructions

TCH Drop (RF Reason)

Version 0.2

Page 2: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

2 Copyright 2007 Nokia Siemens Networks.All rights reserved.

document description

Title and version Performance troubleshooting instructions - BSSReferenceTarget Group NPO engineers (working in NOA projects)Technology and SW release

2G, 2.5G

Related Service Items

Radio network optimization / Capacity Extension Management

Service Item numberAuthor Karri SunilaDate -Approver Eric Kroon

CHANGE RECORD

This section provides a history of changes made to this document

VERSION DATE EDITED BY SECTION/S COMMENTS

0.1 24.02.2010 Karri Sunila ALL First draft:0.2 08.03.2010 Karri Sunila ALL Modifications 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.

Page 3: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

3 Copyright 2007 Nokia Siemens Networks.All rights reserved.

Table of Contents

Table of Contents......................................................................................3

1. Purpose and Scope....................................................................4

2. TCH Drop (RF Reason)..............................................................52.1 TCH Drop KPIs........................................................................................................52.2 Referencing KPIs to be checked.............................................................................62.3 Referencing parameters..........................................................................................82.4 Referencing Features..............................................................................................9

3. Troubleshooting..........................................................................93.1 Alarms.....................................................................................................................93.2 Quality / Interference...............................................................................................93.3 Coverage...............................................................................................................103.4 Blocking.................................................................................................................113.5 HO Failure.............................................................................................................123.6 Neighbor plan........................................................................................................133.7 Parameters............................................................................................................13

Page 4: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

4 Copyright 2007 Nokia Siemens Networks.All rights reserved.

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.

Page 5: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

5 Copyright 2007 Nokia Siemens Networks.All rights reserved.

2. TCH Drop (RF 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 TCH Drop KPIsThe 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)

NSN recommendation for DCR formula is a benchmarking KPI, dcr_5a

Different drop reasons can be seen dcr_3j is used:

Page 6: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

6 Copyright 2007 Nokia Siemens Networks.All rights reserved.

RF reason related counters are,

o 1013 TCH_radio fail

o 1014 TCH_rf_old_ho

Typical reasons for TCH drops (RF reasons) are

o Interference

o Coverage problems

o Dominance area problems

Blocking

Wrong adjacent cell parameters

o Missing neighbors

There are many times several reasons for dropped calls in certain cell, so all reasons should be analyzed. More detailed information, see troubleshooting chapter 3

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

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

Page 7: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

7 Copyright 2007 Nokia Siemens Networks.All rights reserved.

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

RX level – quality distribution can be seen below. The distribution (lowest picture) shows that there are quite a lot bad quality samples which will cause problems in the network.

o Voice quality will be decreasedo PS quality (throughput ) will be decreasedo Dominance areas are not working properlyo Drops + HO failures will be increased

q0 q1 q2 q3 q4 q5 q6 q7-100dBm 10645 8516 6813 5450 4360 3488 2791 2232-95dBm 47043 37634 30108 24086 9865 7543 5643 2345-90dBm 56204 44963 35971 28776 16574 5676 845 65-80dBm 200863 160690 128552 102842 17654 3653 145 28-70dBm 12785 10228 8182 6546 456 112 24 23-47dBm 4583 1123 583 452 261 76 26 2

Bad interference problem → signal level good (<-80dBm) and sometimes no better cell available. If better cell available and quality samples are 4 or worse → HO (reason quality or interference, depends on the parameter) Interference is causing drops.

Really bad interference problem → signal level is really good (<-70dBm) and usually no better cell available → no HO → samples can be seen in the table. Interference is causing drops.

Situation is “network is working properly” If there are quality 4 or worse samples → quality HO. Most of the samples are q4 samples. If lots of q5..q7 samples → interference problem and interference must be analyzed / removed. If quality HOs but no q5..q7 samples → better cell is available → no interference problems. In these signal levels overlapping exists and if handover reason is no PBGT, it will be quality HO. By parameter amount of quality HOs can be adjusted

q0 q1 q2 q3 q4 q5 q6 q7-100dBm 10645 8516 6813 5450 4360 3488 2791 2232-95dBm 47043 37634 30108 24086 9865 7543 5643 2345-90dBm 56204 44963 35971 28776 16574 5676 845 65-80dBm 200863 160690 128552 102842 17654 3653 145 28-70dBm 12785 10228 8182 6546 456 112 24 23-47dBm 4583 1123 583 452 261 76 26 2

q0 q1 q2 q3 q4 q5 q6 q7-100dBm 10645 8516 6813 5450 4360 3488 2791 2232-95dBm 47043 37634 30108 24086 9865 7543 5643 2345-90dBm 56204 44963 35971 28776 16574 5676 845 65-80dBm 200863 160690 128552 102842 17654 3653 145 28-70dBm 12785 10228 8182 6546 456 112 24 23-47dBm 4583 1123 583 452 261 76 26 2

q0 q1 q2 q3 q4 q5 q6 q7-100dBm 10645 8516 6813 5450 4360 3488 2791 2232-95dBm 47043 37634 30108 24086 9865 7543 5643 2345-90dBm 56204 44963 35971 28776 16574 5676 845 65-80dBm 200863 160690 128552 102842 17654 3653 145 28-70dBm 12785 10228 8182 6546 456 112 24 23-47dBm 4583 1123 583 452 261 76 26 2

Bad quality samples due to signal level problems. If PBGT overlapping is not existing → lots of quality HOs + level HOs (margin are lower than in PBGT).

Not interference problem, more coverage problem.

DL_q0 DL_q1 DL_q2 DL_q3 DL_q4 DL_q5 DL_q6 DL_q7-100dBm 12057 2827 3108 3952 4783 6200 7013 8156-95dBm 44818 4811 5041 5866 6587 7223 7259 6781-90dBm 98587 7107 7400 8334 8470 8781 7825 6162-80dBm 225919 7450 7731 8445 7726 7441 5695 3369-70dBm 88708 1014 971 998 751 688 689 367-47dBm 15881 84 109 122 104 167 199 184

There are almost as much samples Q5 and Q7 samples as Q 4 samples → even interference is really bad or there is no better cell available ( no ho’s after bad quality samples). These kind of interference cells should be optimized, otherwise there are lots of drops etc

2.2.2 Blocking (blck_8i)

Blocking is also effecting heavily on drop call rate. If there will be lots of blocking in the network

o Dominance areas are not working properly. This will cause more drops

Page 8: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

8 Copyright 2007 Nokia Siemens Networks.All rights reserved.

Note! Blocking should be checked also in target cells

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

Bad coverage is effecting heavily on drop call rate. If there are bad coverage dips in the cell, quality will be decreased and call will be dropped. In troubleshooting chapter more detailed information how to analyze bad coverage is described.

See picture below, bad coverage samples are due to bad coverage.

DL_q0 DL_q1 DL_q2 DL_q3 DL_q4 DL_q5 DL_q6 DL_q7-100dBm 7055 1398 1374 1906 2163 2003 1468 832-95dBm 20109 1307 1274 1161 694 332 211 84-90dBm 34531 1053 745 587 273 131 94 41-80dBm 107539 875 518 630 161 98 113 47-70dBm 177614 283 316 663 61 32 29 9-47dBm 58718 78 91 198 54 40 54 32

There are bad quality samples only due to signal level problems.

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.2.4 HO failure

HO failure is good indicator when drop call rate analysis will be done. HO failure is a consequence (like a drop), there are some problems in the network. HO failure might indicate that there are

o Incorrect adjacency parameterso Missing neighborso Blocking in the target cells

Ho failures should be always checked with dropped calls. In troubleshooting part more information how to analyze HO failures are described.

2.3 Referencing parametersParameter assessment should be done to make sure that there are no any parameter discrepancies which could cause drops. Some parameters are effecting on drop call rate.

o Handover Threshold Parameters, level, quality, interference. Threshold values and Px,Nx values

o General control parameters – HOs must be enabled (except EMS, Enable MS Distance Process)

Page 9: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

9 Copyright 2007 Nokia Siemens Networks.All rights reserved.

o HO margin parameters, PBGT,quality,levelo Rx Lev Min Cell (SL)o Rx Lev Access Min (RXP)

2.4 Referencing Featureso AMR HRo AMR unpacking optimizationo Frequency hoppingo SAIC/DARPo DFCAo Directed retryo Traffic handling features, see 3.4

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

3.1 AlarmsCheck that there are no any ** or *** active alarms. Connection to NetAct is needed.

3.2 Quality / InterferenceBad quality is the most common reason for dropped calls. Some troubleshooting steps to reduce interference are mentioned below.

If there are bad quality (q4…q7) samples more than 5%, there are bad quality problems. Also fewer samples can cause bad drop problems in the network. Accurate threshold level is difficult to set, because networks are so different.

o Rx_Level_satistics table can be used for quality/interference analysis

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

Page 10: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

10 Copyright 2007 Nokia Siemens Networks.All rights reserved.

Interference HO threshold can be adjusted to for example -75dB to make the difference between quality HO and interference HO more clear

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

o If bad quality in bad signal level,(<-100dB) Bad quality due to bad coverage. Improve coverage, see 3.3 Check also imbalance between UL and DL. Which coverage UL or DL

is more important to improve Parameters (Rx Lev Min Cell (SL), Rx Lev Access Min (RXP)) can be

adjusted to avoid call setups / HOs in very bad coverage.

o Broken components, quality results are strange, see picture below

Q4 samples are strange, no typical interference. More quality4 samples than quality3 samples. HW problem, after TRX reset TRX started to work properly.

If AMR feature available and if lots of quality samples in quality5, but not in quality6 or quality7,

3.3 CoverageBad coverage problems are usually indoor problems due to increased losses (walls etc). These can be outdoor problems also. When cell level coverage problems are analyzed, it is good to check from planning tool or map, what kind of area it is (urban, suburban etc)

Bad coverage like bad interference is causing lots of dropped calls. Some troubleshooting step, how to monitor / improve bad coverage are mentioned below.

Page 11: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

11 Copyright 2007 Nokia Siemens Networks.All rights reserved.

If there are more than 5% bad coverage samples, these can cause lots of drops in the network. Accurate threshold for bad coverage is difficult to set, networks are so different.

o Rx_Level_satistics table can be used for coverage analysis

o If bad UL signal level,(<-100dB) samples . Check imbalance between UL and DL. If lots of UL imbalance, UL

coverage improvement can improve network performance.o Add MHA to improve UL coverageo Check that receiver is working properly, no broken components

o If bad DL signal level,(<-100dB) samples . Check imbalance between UL and DL. If lots of DL imbalance, DL

coverage improvement can improve network performance.o Check that transmitter is working properly, no broken

componentso Check that power parameter (PMAX) is correct

o If no imbalance and bad coverage Improve coverage by adding RF components

o Add more gain antennaso Use Flexi BTS o Add new sectoro Add new site

Parameters (Rx Lev Min Cell (SL), Rx Lev Access Min (RXP)) can be adjusted to avoid call setups / HOs in very bad coverage.

o Broken components (lots of sample <-100dB), see picture below

Almost all UL samples in bad coverage. DL is working fine => HW problems, broken combiner, TRX etc. No alarms.

3.4 Blocking It is important that dominance areas are working properly. If there are blocking in the network, it means that blocked call is not in the right dominance area. This means that interference level will increase and drop call rate will be higher

o Check blocking, check blocking also in neighbor cells (blck_8i)

o Check TCH unavailability, check also in neighbor cells (uav_15a)

o If some blocking, traffic handling can be done

Add HR if HR is not used.

Page 12: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

12 Copyright 2007 Nokia Siemens Networks.All rights reserved.

o Check HR peak values (RS_211). Maximum values should be reached to get maximum gain.

o Check frl, fru parameters.

Check that no missing neighbors

Check that no bad interference problems in neighbor cells (soft blocking)

Traffic handling to other cells

o Adjusting HO parameters

PBGT RxlLevMinCell Level and quality HO margins BTS power parameters can be also adjusted, but before

POC changes, HOC changes should be done (POC is affecting to all neighbors and can cause problems)

Before adjusting HOC parameters, HO strategy should be created, to keep call on dominance area or use overlapping area as a backup coverage.

Note! HOC optimization should be based on strategy. If lots of cell level optimized values, control of the network can be difficult to handle.

o Adjusting antenna configurations

More gain antennas UL /DL boosters (check link balance) Reducing losses (cable, combiner etc)

o Using traffic handling features

Dual band network Umbrella feature

AUCL parameter CBCCH

Load parameters Signal level parameters Segment level parameters

Traffic reason HO AMH DR

o Cell splitting o Using features, which are improving interference.

HO margins (for example when frequency hopping is used)

AMR (improving voice quality) Frequency hopping SAIC/DARP DFCA, improves spectral efficiency

o Add TRX / new sector to get more capacity

More information related to capacity issues (including features) can be found from IMS https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/404404356

Page 13: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

13 Copyright 2007 Nokia Siemens Networks.All rights reserved.

3.5 HO FailureHO Failure is good indicator how mobility is working in the network. If there are lots of HO failures in the cell, there are also lots of dropped calls in the cell.

o Check that HO failure is not due to blocking (hfr_55c) If due to blocking, see blocking chapter 3.4

o Check that neighbor plan is properly done, no missing neighbors. See 3.6o Check that there are no broken components in adjacent cells (source cell,

where HO fail% is high) Check RXlevel-Quality distribution in adjacent cells (RxLevelStatistics)

o Check that there are no bad interference problems is neighbor cellso Check that there are no bad coverage problems is neighbor cells

If lots of Level HO => there might be some coverage problems Check also level HO parameters, how much signal level in adjacent

cell should be bettero Check if HO failures are in BSC or in MSC controlled HOs

Counters 4000-4070 (Handover control table) Check also if these are incoming HO fails or outgoing HO fails If lots of MSC controlled fails, optimize BSC / MSC borders

o Check that HOC parameters are correct (default values if no other customer set default values), see 3.7

3.6 Neighbor planGood neighbor plan in playing important role. If some overshooting and due to that some neighbor cells are missing, there will be definitely be some dropped calls.

o Check all neighbor cells in planning tool (visual check is recommended)

Check Timing advance distribution. If high distance samples and only nearest cells as a neighbor cells, these will be some missing neighbors

GREEN = source

RED =neighbor cell

BLUE = no neighbor

Note! If cell is located near the sea, neighbor planning is more challenging. Signal in the sea might come far away, so neighbor planning should be based on that information.

Page 14: Performance Troubleshooting -CS - TCH Drop(RF) v0.2

14 Copyright 2007 Nokia Siemens Networks.All rights reserved.

3.7 ParametersIt is important that parameter values are the same as these are planned. If there are some parameter discrepancies, these should be correct before more detailed optimization.

Parameter assessment should be done to get clear picture what kind of parameters values are in the network. More detailed information how to do parameter assessment can be found from here

https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/380106805

Some parameters, which can improve drop call rate, are mentioned below. It is important that engineer, who really understands how these parameters are effecting on network, can adjust these parameters. With incorrect values DCR can be even higher.

o Access parameters Parameters (Rx Lev Min Cell (SL) Rx Lev Access Min (RXP))

o POC parameters If reduced power => coverage problems

o HOC parameters HOs are enabled

o PLMN permitted parameters are correct All combinations are defined.