Key Performance Indicators Reference

Prepared by:
Jefferson Aboo

NPO-Mumbai

08/01/2012
Introduction
This document is designed for personnel involved in the performance evaluation and the optimization of
UMTS Terrestrial Radio Access Networks (UTRAN) to get the basic idea of UMTS KPIS that need to be
monitored
Accessibility
KPIs are:
CSV Accessibility rate (RCOM KPI -Voice Access Success Rate (%))
Threshold Should be greater than 98%

CSD Accessibility rate Video BH (RCOM KPI Video Access Success Rate (%)
Threshold Should be greater than 98%

PSD Accessibility rate (RCOM KPI - HSDPA + HSUPA + PS(R99) Access Success Rate(%) )
Threshold Should be greater than 98%

Call setup process

The call setup process consists of different procedures depending on what kind of
session/service type is required (for example CS or PS). RRC Connection
Establishment and RAB Establishment procedure are the main procedures on the
UTRAN side.
With the RRC Connection Establishment procedure, the UE requests resources from
the UTRAN and executes the transition from Idle to CELLDCH state, entering the
UTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radio
Links.
With the RAB Establishment procedure, all the requested resources are allocated by the
Core Network and by the UTRAN in terms of Radio Access Bearers (RABs) while the
UE stays in CellNDCH state and acknowledges the resources setup.
The call is successfully set-up only if both procedures are successfully completed.

Network level access phase

During the network level access phase, the UE has to successfully perform the cell
(re)selection process as well as to gain network access using the Random Access
procedure.
RRC Connection Establishment phase
During the RRC Connection Establishment phase, the UE requests resources from the
UTRAN and executes the transition from Idle to CellNDCH state and enters the
UTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radio
links.

RAB establishment phase

During the RAB Establishment phase, the requested resources are allocated by the
Core Network and by the UTRAN in terms of Radio Access Bearers (RABs) while the
UE stays in CellNDCH state and acknowledges the resources setup.
Determination of accessibility problem
In order to quickly determine whether there are severe problems in the UMTS network,
it is possible to analyze the general satisfaction level, from a network point of view, of
the UMTS mobile subscriber about the network accessibility
Abnormal accessibility rate values
When one of the Accessibility rate values is very low, this can be caused by many
different issues. Therefore, it is advised to localize the issue by analyzing the
performance measurements and KPIs separated over the accessibility call phases:
Network level access phase
RRC connection establishment phase
RAB establishment phase

RRC Connection establishment procedure

In general the RRC connection establishment procedure may occur in different
scenarios such as:
Network attach (the UE is switched on and moves to Idle state)
Location update
MO/MT call setup (the UE moves from Idle state to CellDCH state).
RRC Connection Establishment starts with the successful receipt at the RNC of the
RRC Connection Request message. This means that cell selection/re-selection as well
as Random Access Detection procedures have been successfully completed.
Call setup stages
In case of a mobile originated call setup, the RRC Connection Establishment procedure
may be categorized into the following basic stages:
1. Call Admission Control (CAC) at the RNC
2. Node B Application Part (NBAP) Radio Link Setup (including transport bearer and
synchronization)
3. RRC Connection Setup.

RAB establishment procedure

As soon as the RRC connection establishment procedure has been completed, the call
setup procedure is finalized via the RAB Establishment procedure.
The RAB Establishment procedure is executed in case of call setup with:
Packet-switched (PS) calls
Circuit-switched (CS) calls.
RAB establishment initiators
The RAB Establishment procedure is initiated by the core network, this means SGSN
for PS calls or 3G-MSC for CS calls, upon receipt of an RRC/RANAP Uplink Direct
Transfer message from the UE requesting either a Packet Data Protocol (PDP) Context
Activation (PS call) or a Call Setup (CS call). This procedure is successfully completed
upon receipt of RANAP RAB Assignment Response message at the core network.
The RAB Establishment Success Rate is the percentage of calls for all supported service types
that successful established a RAB, against the number of valid calls requested/attempted.

Depanding on Qos requirement all applications are divided into 4 classes:

Conversational

Interactive

Streaming

Backgroud

Beside delay in communication, BER is also an important Qos criterion(application sensitivity to

transmission error )
RCOM KPIS

1.CSV Access Failure Rate .

In the above KPI we are calculating Access Failure Rate for voice .
Which contains 2 part
1.RRC 2)RAB

1.RRC 2 Types of RRC request taken into consideration Conversational(Originating &

terminating ) and Emergency these are the only 2 type of RRC request used for making Voice
calls in 3G
2.RAB
CS, conversationalAMR 12.2 is the type of RAB used5 for making 3G voice Call .
CS, conversational64K is the type of RAB used5 for making Vide call.
PS, streaming RABS 32, 64 , 128 ,384 etc
Similarly for PS interactive & Background.

2.CSD Access Failure Rate .

In the above KPI we are calculating CS Data Call (Video) Access Failure Rate .
Which contains 2 part

1)RRC 2)RAB

1.RRC 1 Types of RRC request taken into consideration Conversational(Originating &

terminating )
2.RAB CS RAB(64Kbps) is the type of RAB used for making 3G video Call .

3. PSD (HSDPA+HSUPA+PS (R99)) Access Failure Rate .

In the above KPI we are calculating Access Failure Rate for all the PS Services
(HSDPA+HSUPA+PS)

KPI contains 2 part

1)RRC 2)RAB

1)RRC 3 types of RRC request taken into consideration Background ,Interactive.

Note:Streaming type also has to be taken into consideration current formula this is not taken
into consideration .

2)RAB 4 Types of PS RAB Taken into consideration PS Conversation ,PS Streaming ,PS
Interactive and PS Background
Retainabilty
As soon as the call is successfully set up, the second factor influencing UMTS user
Perception is the probability of maintaining the call, as opposed to the probability of
dropping the call.
A call drop is defined as an abnormal termination of a voice/data session due to any
reason causing the user to re-initiate the session. Where a drop on a PS session will
still result in PDP context preservation, and the end user will be able to re-establish
seamlessly (with some delay). PS drops are generally not as severe for end users as CS
drops.
On the UTRAN side, KPI CS&PS Drop Rate, defined as the percentage of dropped
RAB due to any reason against the total number of established RABs for all services,
can be calculated.
Measurement classification
Call drop defined by the measurement - CS call drop & PS call drop

KPIs are:

CSV Drop rate(RCOM Name -Voice Drop Rate (%))

Threshold Should be less than 2%

CSD Drop Rate(RCOM Name- Video Call Drop rate(%)

Threshold Should be less than 2%

PS Drop Rate(RCOM Name- HSDPA + HSUPA + PS Drop Rate (%)

Threshold Should be less than 2%

Dropped RABs are identified by either a RANAP Iu Release Request message or RANAP Reset
Resource message sent by the RNC to the core network. When a Release Request message is
sent, the resources on the UTRAN and core network are released.
Note: For PS calls the PDP context will not be released.
CSV Drop rate(RCOM Name -Voice Drop Rate (%))
Threshold Should be less than 2%

KPI Formula Counter

[Number of CS AMR RABs Abnormally Released for
(AMR RAB Abnormal Release/AMR RAB Cell]/([Number of CS AMR RABs Abnormally Released for
CSV Drop Rate
Release)*100% Cell]+[Number of CS AMR RABs Normally Released for
Cell(not including WB-AMR)])*{100}

This measurement helps evaluate the call drop rate of CS services. This counter is measured
when the RNC initiates the abnormal release procedure through the RAB RELEASE REQUEST
and IU RELEASE REQUEST messages.

KPI contains only RAB Part (AMR RABs ).

CSD Drop Rate(RCOM Name- Video Call Drop rate(%)

Threshold Should be less than 2%

KPI contains only RAB Part (64kbit/s RABs).

This measurement helps evaluate the call drop rate of Video call services in a RNC or cluster.
This counter is measured when the RNC initiates the abnormal release procedure through the
RAB RELEASE REQUEST and IU RELEASE REQUEST messages.

PS Drop Rate(RCOM Name- HSDPA + HSUPA + PS Drop Rate (%)

Threshold Should be less than 2%

This measurement helps evaluate the call drop rate of PS services in a RNC or cluster. This
counter is measured when the RNC initiates the abnormal release procedure through the RAB
RELEASE REQUEST and IU RELEASE REQUEST messages.
Note: The cell level counter calculates only the RAB releases on the SRNC, whereas the result of
the above formula includes the R99 call drop and HSPA call drop.
Possible failing reasons for abnormal rab release
The major components that constitute RAB Drops may be classified as follows:
Radio Link Failure, caused by:
poor RF coverage
poorly defined neighbor list
poor Primary Scrambling Code (PSC) plan-pilot pollution
DL power overload.
UL Interference
Operator intervention (for example reset, lock action)
Inter-RAT handover due to supervision timer expiry (UMTS to GSM)
URANPCH time-out (due to the UE not performing a periodical URA update)
Iu, Iub and Iur link failure
RRC signal connection release Indication sent by the UE.
Failures during SRNS Relocation procedure
Unsuccessful termination of the Iu Rate control procedure
UE Inactivity.

Mobility
WCDMA mobility can be divided into different categories.

Soft handover
Soft/Softer handover
Hard handover
Intra-frequency hard handover
Inter RAT handover
Inter-RAT CS handover
Inter-RAT PS handover
HSDPA handover
Handover between HSDPA cells
Handover between HSDPA and DCH

RCOM KPIs Monitored in Mobilty are :

SHO Failure Rate (RCOM Name - SHO Failure Rate (%))

Threshold Should be less than 1%

CSV IRAT Failure Rate (RCOM Name- IRAT Failure Rate (%)
Threshold Should be less than 2%

Soft/Softer Handover Overhead (RCOM Name- Soft/Softer Handover Overhead (%)

Threshold Should be between 30% & 40%
Soft handover Success Rate

In UMTS networks soft/softer handover is the basic feature that ensures seamless
mobility as well as call performance and quality improvements.

Soft/softer handover procedure steps

The soft/softer handover procedure steps for UE in CellNDCH state are:

1. Reporting of soft/softer handover triggering event to the UTRAN via an RRC
Measurement report message
2. Set up resources in the UTRAN via NBAP procedure (in case of addition or
Replacement)
3. Soft/softer handover execution via RRC active set update procedure. Soft/softer
handover procedure is successfully executed on receipt of an RRC active set update
complete message at the RNC
4. Clear resources in the UTRAN via NBAP procedure (case of removal or replacement)
5. Monitored Set update upon neighbor List Selection Algorithm evaluation via
an RRC measurement control message.
Handover scenarios
Soft/softer handovers can be executed as Intra-RNC as well as Inter-RNC. In case of
Inter-RNC soft/softer handover, the RNCs involved are defined as Serving RNC (SRNC)
and one or several Drift RNCs (DRNC).

Soft handover event 1A

In case of soft handover with event 1A triggered, other procedures via ALCAP and DCH
Framing Protocols are executed on the Iub interface in between Radio Link Set-up (step
2) and Active Set Update (step 3) procedures.

Softer handover
In case of softer handover, the NBAP Radio Link Addition is executed within the same
Node B instead of NBAP Radio Link Setup.
Inter-RNC soft handover
In Case of Inter RNC soft handover event 1A is triggered in one Node B belonging to
the DRNC then the SRNC initiates the setup of the resources at the DRNC via the
RNSAP Radio Link Setup procedure. Afterwards the DRNC allocates the required
resources at the relevant Node B via the NBAP Radio Link Setup procedure. This
example is valid when no soft handover context exists at the Node B, otherwise RNSAP
and NBAP Radio Link Addition procedures are executed instead.

Possible failing reasons for SoftHandover Failure

Poor RF Conditions
Incorrect translations settings
No NodeB resources available
No transport resources available
No UE answer
UE Reject
NodeB/RNC Outages
Iub, Iur link Outages
CS Inter-RAT handover
IRAT handover are used to maintain the UMTS voice call in case the 3G RF coverage and/or
quality is not sufficient. Furthermore they can be used for traffic distribution. IRAT handovers
are always hard handovers and can be either mobile assistant or database assistant.

A handover to another network system or inter Radio Access Technology (inter RAT)
handover is always a hard handover with MSC involvement.
The UTRAN initiates the Relocation Preparation Procedure at the Iu interface towards
the MSC of the GSM network. The UE must have established at least a Circuit
Switched (CS) connection to the UMTS network.

KPI Formula Counter

1-[Number of successful outgoing inter-RAT
CSV IRAT Failure
handovers (CS)/Number of attempted outgoing
Rate
inter-RAT handovers (CS) x 100%
[Number of Successful CS Outgoing Inter-RAT Handovers
for Cell]/[Number of CS Outgoing Inter-RAT Handover
Attempts]*{100}

CS Voice UMTS to GSM handover procedure

In general the UMTS-to-GSM handover procedure can be separated in the following

steps:
1. Handover relocation preparation within UMTS RAN/CN and GSM RAN/CN
2. Handover execution involving also the UE
3. Release of UMTS resources
UMTS to GSM handover failures
Components that constitute failures of UMTS to GSM handover may be classified as
follows:
1. Relocation preparation procedure failures
Relocation preparation failures occur during the RANAP relocation preparation
procedure, for example GSM handover resource allocation fails or the core network
rejects the UMTS to GSM handover request.
2. Handover procedure failures.
Upon successful completion of relocation preparation procedure, the SRNC sends the
handover from UTRAN command including the GSM handover command to the UE. If
the UE fails to complete the requested handover then the SRNC receives a handover from
UTRAN command failure message from the UE.

System Availability
System Availability is defined as the percentage of time the Network can handle one hundred per-cent (100%)
of the traffic demand within the limits it is designed for as measured at Cell Level.
The purpose of this metric is to calculate the total amount of time (in percentage) out of the total operating time
the RNC and Node-B are available to carry commercial traffic. Minimum granularity for KPI purposes is total
loss of traffic at Cell level.
The loss of traffic at Cell Level can be due to one or more reasons:
1. Equipment failures
2. Software failures
3. Other Failures (accidental, misuse, reset etc.)
4. Planned events authorized by Seller (Software upgrade, Equipment upgrade, Parameter change etc)

HSDPA Unavailability duration - VS.Hsdpa.UnavailTime

HSUPA Unavailability duration - VS.Cell.HSUPA.UnavailTime
Coverage
Soft/Softer Handover Overhead

It tells the consumption of extra network resources due to soft handover in one RNC
It is nothing but a simple ratio of No. of Radio Links used over the No. of UEs in anRNC

Soft/Softer Handover Overhead KPI provides an indication of how many Cells or Sectors were in the active set
during the call on an average basis.

Uplink Interference Ratio

RTWP reflects the total noise level within the UMTS frequency band of one single cell.
RTWP (Received Total Wideband Power) analysis is used to evaluate the uplink interference and
loading status.
If actual loading of the network is empty, then the RTWP is the thermal noise plus the noise figure
of the NodeB. With the access of more users in the network, RTWP increases accordingly.

Cell is considered as interefered if the VS.MeanRTWP value is greater than -96

Integrity
Indicates the service capabilities for PS/HSDPA throughput on busy hour in each cell and for evaluating
the UL BLER values for each cell.

Main KPIs:
Average UL Throughput for R99 services.
Average DL Throughput for R99 services.
HSDPA throughput.
HSUPA throughput

Traffic

Used to evaluate the circulated traffic such as CS Erlangs, PS Traffic, Mean UE number for various kind of
services.

Key KPIs: No. of CS users, No. of PS R99 users, No. of HSDPA users, No. of HSUPA users, HSDPA traffic
volume, HSUPA traffic volume.

This KPI provides the equivalent Erlang values/ & Data Traffic for all the services

KPI Formula Counter

HSDPA Payload Volume (GB)
HSUPA Payload Volume (GB)
R99 DL Payload Volume (GB)
R99 UL Payload Volume (GB)
Voice Traffic Volume (Erlang)
Video Traffic Volume (Erlang)
Town wise KPI =Sum(([VS.HSDPA.MeanChThroughput.TotalMBytes])/(1024*1024*1024))
[VS.HSDPA.MeanChThroughput.TotalMBytes]/(1024*
Formula=sum(([Number of Total Bytes Received([Number
in Uplink of HSUPA
Total Bytes
MAC-d
Received
Flow for
in Uplink
Cell])/(1024*1024
of HSUPA
S um of allcounter /(1024*1024*1024*8) ([UL Traffic Volume of 8 Kbit/s PS R99 Background Se
sum of counter /(1024*1024*1024*8) ([DL Traffic Volume of 8 Kbit/s PS Background Service
(SUM(VS.RB.AMR.UL.10.2 + VS.RB.AMR.UL.12.2 VS.RB.AMR.UL.10.2
+ VS.RB.AMR.UL.7.95+ VS.RB.AMR.UL.12.2
+ VS.RB.AMR.UL.7.4 + VS.RB
+ VS
(SUM(VS.RB.CS.Conv.DL.64))/number of days VS.RB.CS.Conv.DL.64
THANK YOU