3G Key Performance Indicators (KPI)

Key Performance Indicators (KPI)

• For radio network optimization, it is necessary to have decided on key performance

indicators.
• These KPIs are parameters that are to be observed closely when the network
monitoring is going on.
• Mainly, the term KPI is used for parameters related to voice and data channels, but
network performance can be broadly characterized into coverage, capacity and
quality criteria also that cover speech and data aspects.
• KPIs are collected from network management system along with field
measurements such as drive tests.

12/20/12 2
Key Performance Indicators…..continued

• For the field measurements, the tools used are ones that can analyze the
traffic, capacity and quality of the calls, and the network as a whole.
• For drive testing, a test mobile is used.
• This test mobile keeps on making calls in moving vehicle that goes around
various parts of the network to measure Drop Call Rate (DCR), CSR (Call
Success Rate), HO (Handover) etc. parameters.
• Apart from drive testing, the measurements can also be generated by the
network management system.
• Network Management system (NMS) can generate various reports which
can be analysed, processed and used to found problematic parameters in
network.

12/20/12 3
3G KPI’s Detail

Following main KPIs are monitored for UMTS:

• Accessibility ( Setup Failures-RAB and RRC, CSSR)

• Retainability ( Drops-RAB and RRC)

• Mobility ( SHO,ISHO)

• Throughput

• Usage (Resources)

12/20/12 4
 CS Call Drop

Possible Reason Resolution

1: Change physical antenna parameters (tilt, Azimuth and
1: Poor coverage issue height), If required Increase TCP and CPICH power to
increase coverage and capacity.

2: check for Neighbour planning of the cells in that area.

2: Neighbour planning issue
(Missing neighbours)

3: Check and resolve the issue by tracing the source of

3: RTWP issue (Receive Total wideband power) external interference through YBT or spectrum Analyzer or
get the hardware checked
4: Alarms 4: Forward alarms to BSS team for Rectification.
5: Check RF conditions in and check Source and Target
5: Overshooting issue Cells to have a feel of overshoot. Make physical changes on
the basis of results.
6. PSC Clash- Same PSC in cells having
6. Replan the PSC of the cells
overlapping coverage

12/20/12 5
 PS Call Drop

Possible Reason Resolution

1. Poor RF conditions
2: Missing Neighbour Issue
3: RTWP issue
4: Alarms
5: Tracing the particular UE.
1. change physical antenna changes or If required
Increase TCP and CPICH power to increase coverage and
capacity.
2: check for Neighbour planning of the cells in that area.
(Missing neighbours)
3: Check and resolve the issue by tracing the source of
external interference through YBT or spectrum Analyzer or
get the hardware checked
4: Forward alarms to BSS team for Rectification.
5: Check CHR data and see if the drops are taking place on
one particular UE or different UE

 RRC Connection Setup Failure

Possible Reason Resolution
1. RRC Failure 1. Do Cell RRC Reject Analysis
2: Power congestion 2: Check for RTWP issue or Increase the power
3: CE Congestion 3: Load Balancing/physical optimization or add carrier.
4: Load Balancing/physical optimization or add carrier or
4: Code Congestion
play with HSDPA codes.
5: No Reply 5: This includes reasons like RF conditions and UE issue
6. Cell Scenario analysis report and check if the failures are
6. Dongle/UE issue
interactive call failures
12/20/12 6
 HO Failure (3G-3G)

Possible Reason Resolution

1: Check RF conditions in Omstar and check Source and
1: Overshooting issue Target Cells to have a feel of overshoot. Make physical
changes on the basis of results.
2: check for Neighbour planning of the cells in that area.
2: Missing Neighbour Issue
(Missing neighbours)
3. Retune the handover event threshold and parameter
3. Handover event threshold and parameter settings
settings
4. PSC Clash- Same PSC in cells having
4. Replan the PSC of the cells
overlapping coverage
5: Change physical antenna parameters (tilt, Azimuth and
5: Poor coverage issue height), If required Increase TCP and CPICH power to
increase coverage and capacity.

 IRAT HO Failure (3G Network to 2G Network)

Possible Reason Resolution
1. GSM Cell Discrepancies 1. Remove all GSM cell Discrepancies
2: Interference on GSM Cell 2: Remove interference issue on 2G cell
3: Alarms on 2G or 3G cell 3: Remove all alarms either on 2G or 3G side.
4: IRAT parameters 4: Retune IRAT parameters.

5: Filter the cells having continuous high IRAT failures.

5: Particular cell issue Enable the IRAT attempt and IRAT success counter from
M2000 to find out failures are with which cells

6. Blocking on 2G cell 6. Resolve the issue of blocking in 2G cell

12/20/12 7
 Power congestion Issue

Possible Reason Resolution

1. Check and resolve the issue by tracing the source of

1. RTWP issue external interference through YBT or spectrum Analyzer or
get the hardware checked

2: Increase TCP and CPICH power to increase coverage

2: Power issue
and capacity.

3: Carrier addition 3: Add new carrier

4: Check RF conditions in Omstar and check Source and

4: Overshooting cell Target Cells to have a feel of overshoot. Make physical
changes on the basis of results.

12/20/12 8
3G KPI’s and acceptance Limit (different for different operators)
Information Element Accept Limit (%)
CSV Access Failure Rate < 1.0 %
CSV Drop Rate <1%
CSV Quality (DL) 95th percentile of samples ≤ 2.0 % BLER

CSV Quality (UL) 95th percentile of samples ≤ 2.0 % BLER

Soft/Softer Handover Overhead < 1.6

*Voice Call Setup time (Mobile to PSTN) 95th percentile ≤ 5 seconds
*Voice Call Setup time (Mobile to Mobile) 95th percentile ≤ 9 seconds
HSDPA Access Failure Rate ≤ 1.0 %
HSUPA Access Failure Rate ≤ 1.0 %
CSD Call Setup Time 95th percentile ≤ 7 seconds
CSD Access Failure Rate <1.0 %
HSDPA Drop Call Rate <1.0 %
HSUPA Drop Call Rate <1.0 %
CSD Drop Call Rate ≤ 1.0 %
PSD average DL Throughput ≥ 210
PSD average UL Throughput ≥ 180
PSD Call Setup time 95th percentile sessions ≤ 3 seconds
Stationary Maximum DL HSDPA Bit Rate(kbps) > 6 Mbps
Stationary Maximum UL HSUPA Bit Rate(kbps) > 1.2 Mbps
HSDPA Latency 95th percentile sessions ≤ 100 ms

PSD Latency 95th percentile sessions ≤ 100 ms

12/20/12 9
Parameters
Adjustment Recommendation and Implementation

• Adjustment Recommendation and Implementation

– Common Control Channel Power Allocation parameters
– RL Maximum Power parameters
– Intra-frequency Handover parameters
– Inter-frequency Handover parameters
– Inter-RAT Handover parameters
– Power Control parameters
– Access parameters

12/20/12 10
PROCEDURE- ANALYSING COUNTERS

• Available on an RNC, RXI and RBS basis, the FACTS tool is available
to interface to and represent the relevant counters. Counters are
collected on a quarterly (15 minute) basis (known as a reporting
period) and are stored from the operational date of the cell thereby
allowing for past analysis.

• There are numerous counters available from an RNC/RXI/RBS.

However, this procedure concentrates on counters reflecting the
critical performance of the cells. These counters (and formulae
derived there from) are best analysed graphically through the use
of FACTS. The formulae used for statistics such as DCR and CSSR
may be obtained within the FACTS.

12/20/12 11
PROCEDURE- ANALYSING COUNTERS

• Both the NMC and the Planning & Optimization Engineer are
responsible for monitoring counters. The NMC has the
responsibility of maintaining the active status of all cells and
therefore must act in accordance to all such related counters. The
Planning and Optimization Engineer monitors and acts on counters
reflecting the cell’s active performance.
• It is possible to configure alarms to be generated for counters
exceeding specific values. These alarms would then be monitored
by the NMC.
• For the Radio Planning & Optimisation Engineer the focus is on
maintaining adequate cell performance in terms of Accessibility
(call setup analysis), Retainability (drop call analysis) and Integrity
(speech quality/video quality/packet throughput analysis)
12/20/12 12
ACCESSIBILITY

• If a cell has poor accessibility it is typically due to either some form

of congestion or a hardware/software fault or a misconfiguration. It
is also possible that there is some external source of interference
(such as a microwave link on the same frequency) affecting the
accessibility.
•
• Accessibility should be monitored independently for the different
RAB types (e.g. Speech, CS Video, PS Interactive R99, PS Interactive
HSDPA, etc.) as in certain situations only one of the RAB types will
be affected. For example, a disabled HS-TXB will affect the
accessibility of the PS Interactive HSDPA RAB, but if the RBS also has
a TXB (non-HS) installed then the other RABs may continue to have
an acceptable accessibility.
12/20/12 13
ACCESSIBILITY..continued

• When a low CSSR is detected on a cell the first thing to check is if

Admission Control is rejecting the RRC/RAB setup attempt
(pmNoReqDeniedAdm) or if it is failing after admission
(pmNoFailedAfterAdm). For high pmNoReqDeniedAdm refer to the
“Admission Control” sections below. For high pmNoFailedAfterAdm
refer to the “Failure After Admission” sections below.

12/20/12 14
Example: FACTS Report showing a low CSSR Speech caused by a high
pmNoReqDeniedAdm. Note that pmNoReqDeniedAdm is not RAB
specific so other RABs will most likely be affected in this case too.

12/20/12 15
Admission Control: DL Power

• If Admission Control rejects a RAB establishment due to a lack of DL power

then the counter pmNoFailedRabEstAttemptLackDlPwr is incremented.
Check that the feeder losses are configured correctly in the RBS and that
the parameter maximumTransmissionPower is set correctly (typically to
maxDlPowerCapability minus 0.2dBm). The value of parameter pwrAdm
should also be verified (typically set to 75%). Also, check for MCPA alarms
i.e. sometimes RBS 3202 sites with high feeder losses are configured with
two MCPAs per sector and one of the MCPAs fails resulting in a large
reduction in the maxDlPowerCapability of the sector and, hence, causing a
lack of DL power. Long term solutions are to increase the power capability
of the sector by adding or upgrading an MCPA (RBS 3203) or RU (RBS
3206), re-engineering the site to reduce feeder lengths, or perhaps to
change the RBS type to one using RRUs (RBS 3402 or RBS 3412) if this
provides higher power at the reference point. The short term solution is to
reduce the traffic carried by the site (See the “Traffic Offload” sections).

12/20/12 16
 Admission Control: DL Channelisation Codes

• If Admission Control rejects a RAB establishment due to a lack of DL

channelisation codes then the counter
pmNoFailedRabEstAttemptLackDlChnlCode is incremented. This will
typically affect the PS Interactive R99 (DCH/FACH) CSSR worse than the
Speech CSSR as the PS Interactive R99 RAB requires channelisation codes
at a lower spreading factor (using more of the code tree). In the P4
software release a cell that supports R99 and HSDPA typically has 5
spreading factor 16 DL channelisation codes reserved for HSDPA. This
means that approximately 32% of available codes are reserved for HSDPA.
When this is the case it is common for DL channelisation code congestion
too occur. Check the setting of parameter dlCodeAdm (typically set to 85%
on MTN’s network). The long term solution is to add another cell in the
coverage area to take some of the traffic; this may be achieved by
introducing a second carrier, another sector, or another site. The short
term solution is to reduce the traffic carried by the site (See the “Traffic
Offload” sections).
12/20/12 17
Admission Control: Connection Limits

• If Admission Control rejects a RAB establishment due to exceeding

the configured connection limit for SF 8, SF 16, or SF 32 then the
counter pmNoFailedRabEstAttemptExceedConnLimit is
incremented. These spreading factors are used by the PS64/384,
PS64/128, and PS64/384 RBs so the connection limit blocking
typically applies to channel switching between these RBs for an
R99 packet interactive RAB. The connection limits are configured
by parameters sf8Adm, sf16Adm and sf32Adm. The default settings
allow the maximum possible number of RL’s for each spreading
factor in which case Admission Control will not block for this
reason. Lower settings have been tested (in combination with
adjusted Class B QoS settings on the Iub interface) in which case
some connection limit rejections were obtained. But this is a
special situation and for the purpose of this document such
connection limit rejections are not worth further consideration.
12/20/12 18
Admission Control: Hardware Usage (Channel
Elements)

• It is possible for Admission Control to reject a RAB establishment attempt due to

insufficient UL or DL RBS hardware capacity i.e. too few channel elements
available. The channel element capacity of an RBS may be software limited
(according the software license configured for the RBS) or hardware limited
(according to the TXBs and RAXBs installed in the RBS). The two parameters that
control the RBS hardware admission policy are ulHwAdm and dlHwAdm. By default
these parameters should be set to 100% in which case no hardware is reserved for
handovers and Admission Control will not block RAB establishment attempts for
this reason (see “Failure After Admission: Hardware Usage”). In software revision
P4 there is no specific counter to indicate this type of Admission Control rejection,
so if pmNoReqDeniedAdm is triggered without any of the other relevant counters
indicating a reason then it is likely that this is the cause and that ulHwAdm or
dlHwAdm is incorrectly configured to a value below 100%. In the P5 software
release there are new counters that indicate when lack of hardware capacity
causes RAB establishment failures in a cell: pmNoFailedRabEstAttemptLackDlHw,
pmNoFailedRabEstAttemptLackDlHwBest, pmNoFailedRabEstAttemptLackUlHw,
pmNoFailedRabEstAttemptLackUlHwBest.
12/20/12 19
Soft Handover Drops

• Typically a cell that has a high number of dropped calls due to

SOHO failures (pmNoSysRelSpeechSoHo) will also have a high
number of drops due to missing neighbours
(pmNoSysRelSpeechNeighbr) indicting that the SOHO failures are
due to missing neighbour relations; however, there are situations
where SOHO failures happen for other reasons. Two common
reasons are a neighbouring cell that is misbehaving (often due to
faulty hardware/software) or a misconfiguration resulting in a
failure to perform an inter-RNC SOHO across the Iur interface.

12/20/12 20
Drive Test Based Service Quality Measurements

• From TEMS Investigation,the ability to measure the speech and

video streaming service quality is introduced through two new KPIs:
the WCDMA Speech Quality Index (SQI) and the Video Streaming
Quality Index (VSQI). These two KPIs may be used to benchmark the
service quality for speech and video streaming from drive test data.
In addition to the above the DL BLER may also be obtained for

12/20/12 21
R99 & HSDPA PS Interactive Throughput (RNC
Level)
• The throughput obtained on the packet interactive RABs (HSDPA
and R99) are a good indication of the Integrity offered by these
services. Counters are available at an RNC level to obtain the PS
Interactive Average Throughput for R99 (DCH/FACH) and HSDPA, as
well as the retransmission rate for these two services.

12/20/12 22
Test for Special Areas/ Hot-spots

• Special area refers to a small district or indoors environment

– Operator offices, residence of VIP.
– Key hotels or entertainment location.
– Government location.
– Locations of large company or group subscribers .
– Locations tend to be cared , such as railway station or airport.

12/20/12 23
Optimization Report

• The 《optimization report》 should be presented after the project

passes the customer acceptance. The optimization report should
include:
– Project background introduction.
– Existing network status.
– Acceptance criteria.
– Optimization process.
– Problem analysis, adjustment recommendation and the effect
for the implemented part.
– Acceptance test and result.
– Leftover problems and suggestions from the optimization point
of view.
12/20/12 24
THANKS

12/20/12 25
25