Performance Troubleshooting -CS - TCH Blocking v0.2

BSS Performance Troubleshooting Instructions

TCH Blocking

Version 0.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 26.02.2010 Karri Sunila ALL First draft:0.2 10.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.


Table of Contents

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

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

2. TCH Blocking..............................................................................52.1 TCH Blocking KPIs.................................................................................................52.2 Referencing KPIs to be checked.............................................................................52.3 Referencing parameters..........................................................................................72.4 Referencing Features..............................................................................................7

3. Troubleshooting..........................................................................73.1 Alarms.....................................................................................................................83.2 TCH Availability (ava_1g, uav_15a)........................................................................83.3 Temporary blocking.................................................................................................83.4 Quality / Interference (Rx_Level_Statistics table)...................................................83.5 Coverage.................................................................................................................93.6 Traffic handling......................................................................................................103.7 Usage of capacity features....................................................................................113.8 HO Failure.............................................................................................................123.9 Neighbor plan........................................................................................................133.10 Parameters............................................................................................................13


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 BlockingTCH blocking is important KPI to monitor. If there are blocking problems in the network, it means that calls can not be handed over neighbor cell. Due to this calls are not served by dominance cells. This will cause following problems

o Interference level will increase => possible more dropped calls

o Increased interference will cause performance decreasing in CS and PS KPIs

2.1 TCH Blocking KPIsIn following KPIs can be used to analyze TCH blocking in the network

o Blck_8i (benchmarking KPI)

2.2 Referencing KPIs to be checkedIn parallel with blocked calls, following KPIs should be checked

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) from each codec of each TRX in the BTS.. In this document quality (DL and UL) is measured using BER measurements.

Bad quality can effect on blocking. If there are interference problems in the cell, traffic is moved to neighbor cells maybe causing some blocking problems. 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, dominance areas are not working properly.


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




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 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 also effecting, like bad quality, on blocking. If there are bad coverage dips in the cell, traffic will move (if better cell available). See picture below, bad quality 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.3 TCH availability


If there are some RTSLs or even TRXs, which are not in the air, capacity will be decreased and due to that decreased capacity there might be some blocking. TCH availability should be checked first.

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)

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

2.4 Referencing Featureso AMR HRo Dual band networko Umbrella featureo CBCCHo Traffic reason HOo AMHo DRo Traffic handling features, see 3.6

3. TroubleshootingBlocking (>2%) is causing problems in the network. Service areas are not working and due to that

o Traffic is moved to other cells

o Interference level will be higher => more drops

o HO failures will be higher.

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.

More information related to capacity optimization, see capacity optimization guide


In IMS https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/404404356

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

3.2 TCH Availability (ava_1g, uav_15a)THC availability is first thing which should be checked if there are some blocking problems.

o If some availability problems, these should be repaired as soon as possible

All sites should be in the air; otherwise blocking results are not reliable enough.

3.3 Temporary blockingIf there are some blocking problems, it should be checked whether it is temporary problem or not. First amount of traffic should be checked

o Number of timeslots for CSW traffic = (Nbr of TRX)*8 – signaling RTSL – dedicated RTSL

ErlangB table, amount of traffic for existing blocking

o If much less traffic => blocking is temporary (for example train is passing by etc)

o Check from hourly data, is blocking critical. If critical, keep on optimizing with next chapters

If blocking is not critical, needs for capacity expansion must be discussed.

3.4 Quality / Interference (Rx_Level_Statistics table)Bad quality can cause some blocking, because traffic is moved to other cells. Blocking due to interference is also called soft blocking.

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.

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

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


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

3.5 Coverage Bad coverage is also effecting, like bad quality, on blocking. If there are bad coverage dips in the cell, traffic will move (if better cell available).to other cells causing (possibly) blocking

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 coverageo Add more gain antennas


o 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.6 Traffic handlingThe purpose of the traffic handling is not to move capacity but balance traffic between cells / sites.

3.6.1.1 GSM –GSM traffic handlingTraffic handling between different sites/cell can be as follows:

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

o AUCL parameter CBCCH

o Load parameterso Signal level parameterso Segment level parameters

Traffic reason HO


AMH DR

o Cell splitting is one solution to reduce blocking Same traffic is spread to new cells => traffic per cell will reduce

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 Selecting site places properly Hot spots are not located in the edge of the cell

3.6.1.2 GSM – UMTS traffic handlingGSM –UMTS traffic handling should be based on capacity optimization strategy. Which layer is prioritized for CS traffic and which for PS traffic? Coverage should be good enough to support this strategy.

Traffic between 2G and 3G can be handled by parameters. More detailed information related Inter-system handovers (ISHO) can be seen from ISHO Planning & Optimization Guide (https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/363674954)

3.6.1.3 Cell splitting

Cell splitting can be used to balance traffic between cells in case of blocking. In case of cell splitting new cells are created to balance traffic between cells. Cell splitting can be used if TCH traffic or SDCCH traffic is increased and other capacity optimization tasks are not working.

If cell splitting is done based on blocking (can be also done based on coverage) traffic analysis should be done carefully. It must be analyzed, where and why traffic is come to the cell, otherwise new cell was created but old cells are still collecting traffic

o Hot spots (TCH, SDCCH)o PS features are causing additional SDCCH traffico Location updates, SMSs etco CCCH traffic too high. Reason for traffic must be analyzed (not bad LAC

planning etc)o If interference levels are too high to add TRX, cell splitting can be used

3.7 Usage of capacity featuresThe purpose of the capacity feature is to handle additional capacity needs without HW implementations, for example without adding new TRXs. More detailed information of S12/S13 capacity features can be seen from references Error: Reference source not found.

Following traffic features can be used for traffic management



o AMH o DR and intelligent DR o Traffic reason HO o Increased SDCCH capacity feature o CommonBCCH o AMR FR/HR

2 HR calls can be done in one RTSL TRX level feature – license is needed Check also that HR is working (RS_211)

o BSC level features BSC3i 3000

Note! More detailed information related to capacity feature can be found from capacity optimization guide


Note! Licenced features can be run with MML commands. Run MML Commands as follows ( states, on, off and conf)o ZW7I:FEA,FULL:FSTATE=ON;o ZW7I:FEA,FULL:FSTATE=OFF;o ZW7I:FEA,FULL:FSTATE=CONF;

3.8 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, reduce blocking in adjacent cells based on this

document o Check that neighbor plan is properly done, no missing neighbors. See 3.9o 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 borderso Check that HOC parameters are correct (default values if no other customer

set default values), see 3.10

3.9 Neighbor planGood neighbor plan in playing important role. If some overshooting and due to that some neighbor cells are missing, traffic is not properly handled. Due to missing neighbors calls will be longer time in certain cell increasing traffic (and possible causing some blocking)

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.

3.10 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


Some parameters, which can improve TCH blocking, 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 TCH blocking can be even higher.

o POC parameters BS Tx max power (PMAX)



o HOC parameters Handover Threshold Parameters, level, quality, interference. Threshold

values and Px,Nx values PBGT

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

o Rx Lev Min Cell (SL)o Rx Lev Access Min (RXP)o Frl / fru (HR parameters)

Performance Troubleshooting -CS - TCH Blocking v0.2

Documents

tch blocking kpis

following kpis

document quality

ps kpis

certain kpis

tch blockingtch blocking

temporary blocking

quality interference