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

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

3G KPIs 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

 CS Call Drop
Possible Reason

Resolution

1: Poor coverage issue

1: Change physical antenna parameters (tilt, Azimuth and

height), If required Increase TCP and CPICH power to
increase coverage and capacity.

2: Neighbour planning issue

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

(Missing neighbours)

3: RTWP issue (Receive Total wideband power)

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

external interference through YBT or spectrum Analyzer or
get the hardware checked

4: Alarms

4: Forward alarms to BSS team for Rectification.

5: Overshooting issue

5: Check RF conditions in and check Source and Target

Cells to have a feel of overshoot. Make physical changes
on the basis of results.

6. PSC Clash- Same PSC in cells having

overlapping coverage

6. Replan the PSC of the cells

12/20/12

 PS Call Drop
Possible Reason

Resolution

1. Poor RF conditions

1. change physical antenna changes or If required

Increase TCP and CPICH power to increase coverage and
capacity.

2: Missing Neighbour Issue

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

(Missing neighbours)

3: RTWP issue

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

external interference through YBT or spectrum Analyzer or
get the hardware checked

4: Alarms

4: Forward alarms to BSS team for Rectification.

5: Tracing the particular UE.

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: Code Congestion

4: Load Balancing/physical optimization or add carrier or

play with HSDPA codes.

5: No Reply

5: This includes reasons like RF conditions and UE issue

6. Dongle/UE issue

6. Cell Scenario analysis report and check if the failures

are interactive call failures
12/20/12

 HO Failure (3G-3G)
Possible Reason
1: Overshooting issue
2: Missing Neighbour Issue
3. Handover event threshold and parameter
settings
4. PSC Clash- Same PSC in cells having
overlapping coverage
5: Poor coverage issue

Resolution
1: Check RF conditions in Omstar and check Source and
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.
(Missing neighbours)
3. Retune the handover event threshold and parameter
settings
4. Replan the PSC of the cells
5: Change physical antenna parameters (tilt, Azimuth and
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: Particular cell issue

5: Filter the cells having continuous high IRAT failures.

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

 Power congestion Issue

Possible Reason

Resolution

1. RTWP issue

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

external interference through YBT or spectrum Analyzer
or get the hardware checked

2: Power issue

2: Increase TCP and CPICH power to increase coverage

and capacity.

3: Carrier addition

3: Add new carrier

4: Overshooting cell

4: Check RF conditions in Omstar and check Source and

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

12/20/12

3G KPIs and acceptance Limit (different for different operators)

Information Element

Accept Limit (%)

CSV Access Failure Rate

CSV Drop Rate

< 1.0 %
<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

HSDPA Drop Call Rate
HSUPA Drop Call Rate
CSD Drop Call Rate
PSD average DL Throughput
PSD average UL Throughput
PSD Call Setup time
Stationary Maximum DL HSDPA Bit Rate(kbps)
Stationary Maximum UL HSUPA Bit Rate(kbps)

<1.0 %
<1.0 %
<1.0 %
1.0 %
210
180
95th percentile sessions 3 seconds
> 6 Mbps
> 1.2 Mbps

HSDPA Latency

95th percentile sessions 100 ms

PSD Latency

95th percentile sessions 100 ms

12/20/12

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 cells 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
12/20/12
12
quality/video quality/packet throughput analysis)

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
12/20/12
13
other RABs may continue to have an acceptable

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
12/20/12
16
type to one using RRUs (RBS 3402 or RBS 3412)
if this

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 MTNs 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
12/20/12
17
solution is to reduce the traffic carried by the site (See the

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 RLs 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
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:
12/20/12
19
pmNoFailedRabEstAttemptLackDlHw,

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