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 (AMR RAB Abnormal Release/AMR RAB Release)*100% Counter [Number of CS AMR RABs Abnormally Released for Cell]/([Number of CS AMR RABs Abnormally Released for Cell]+[Number of CS AMR RABs Normally Released for Cell(not including WB-AMR)])*{100}

CSV Drop Rate

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 CSV IRAT Failure Rate Formula 1-[Number of successful outgoing inter-RAT handovers (CS)/Number of attempted outgoing inter-RAT handovers (CS) x 100% Counter [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 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)

Formula Counter Town wise KPI =Sum(([VS.HSDPA.MeanChThroughput.TotalMBytes])/(1024*1024*1024)) [VS.HSDPA.MeanChThroughput.TotalMBytes]/(1024* Formula=sum(([Number of Total Bytes Received([Number of HSUPA MAC-d Flow for Uplink of HSUPA in Uplink Total Bytes Received in Cell])/(1024*1024 S um of al counter /(1024*1024*1024*8) l ([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.7.95 + VS.RB.AMR.UL.7.4 + VS VS.RB.AMR.UL.10.2 + VS.RB.AMR.UL.12.2 + VS.RB (SUM(VS.RB.CS.Conv.DL.64))/number of days VS.RB.CS.Conv.DL.64

THANK YOU