UMTS RF Troubleshooting Guideline Draft V21

Document name:
Date:
UMTS RF Troubleshooting Guideline U04.03
2007-06-08
Rev: 2.1
UMTS RF
Troubleshooting Guideline
U04.03
Author:
Matthias Braun
Editor:
Irfan Mahmood
Date:
6th August 2007
Version:
2.1
UMTS Network Performance Engineering
Page 1 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table of Contents
1.
GLOSSARY OF TERMS AND ABBREVIATIONS................................................................. 5
2.
REFERENCES ........................................................................................................................... 10
3.
ABOUT THIS DOCUMENT..................................................................................................... 12

3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
INTRODUCTION ...................................................................................................................... 12
CONTENT ............................................................................................................................... 12
HOW TO READ ....................................................................................................................... 13
UTRAN/CN RELEASE AND VENDOR DEPENDENCY ............................................................... 13
INTENDED AUDIENCE ............................................................................................................. 13
DISCLAIMER - WHAT IS NOT COVERED ................................................................................... 13
4.
DESCRIPTION OF THE OPTIMISATION PROCESS ........................................................ 14
5.
CALL SETUP ............................................................................................................................. 16

5.1.
CALL SETUP RRC CONNECTION ESTABLISHMENT............................................................... 16
5.1.1.
PLMN/cell selection and reselection ............................................................................ 16
5.1.2.
Failures on the AICH, PICH and PCH......................................................................... 20
5.1.3.
Random Access Procedure ........................................................................................... 23
5.1.4.
Call Admission Control (CAC) ..................................................................................... 26
5.1.5.
Radio Link Setup........................................................................................................... 28
5.1.6.
Call setup failures on the FACH................................................................................... 29
5.1.7.
RRC Connection Reject message with specified cause unspecified.......................... 31
5.2.
CALL SETUP FAILURES DURING THE CALL SETUP PHASE ..................................................... 32
5.2.1.
Concept ......................................................................................................................... 32
5.2.2.
Failure symptoms, identification and fixes for improvement ........................................ 32
5.3.
CALL SETUP CORE NETWORK FAILURES ............................................................................. 33
5.3.1.
Mobility Management failures...................................................................................... 34
5.3.2.
Call Control failures..................................................................................................... 35
5.3.3.
Session Management failures ....................................................................................... 36
5.4.
CALL SETUP RAB ESTABLISHMENT .................................................................................... 37
5.4.1.
Dynamic bearer control (DBC) .................................................................................... 38
5.4.2.
Radio Link Reconfiguration.......................................................................................... 40
5.4.3.
Radio Bearer Establishment ......................................................................................... 41
6.
CALL RELIABILITY (RETAINABILITY)............................................................................ 43

6.1.
CALL RELIABILITY RADIO LINK FAILURE (RLF) ................................................................ 43
6.1.1.
Concept ......................................................................................................................... 43
6.1.2.
6.2.
CALL RELIABILITY DROP OF THE RAB................................................................................ 47
6.2.1.
Concept ......................................................................................................................... 47
6.2.2.
6.3.
CALL RELIABILITY DROP OF RRC CONNECTION AFTER CALL SETUP ................................... 49
6.3.1.
Concept ......................................................................................................................... 49
6.3.2.
6.4.
CALL RELIABILITY RF PLANNING RELATED ISSUES ............................................................ 52
6.4.1.
Introduction .................................................................................................................. 52
6.4.2.
Pilot pollution ............................................................................................................... 52
6.4.3.
Around-the-corner-effect .............................................................................................. 53
Page 2 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6.4.4.
Non-optimal neighbour definitions ............................................................................... 54
6.4.5.
Poor RF coverage......................................................................................................... 57
6.4.6.
Poor PSC plan .............................................................................................................. 58
6.5.
CALL RELIABILITY CONGESTION CONTROL (CONGC) ........................................................ 58
6.5.1.
Concept ......................................................................................................................... 58
6.5.2.
6.6.
CALL RELIABILITY FAILURES IN URA_PCH/CELL_PCH MODE ........................................ 59
6.6.1.
Concept ......................................................................................................................... 59
6.6.2.
6.7.
CALL RELIABILITY FAILURES IN CELL_FACH MODE ........................................................ 60
6.7.1.
Concept ......................................................................................................................... 60
6.7.2.
6.8.
CALL RELIABILITY HARDWARE AND NETWORK INTERFACE OUTAGES ................................ 63
6.8.1.
Concept ......................................................................................................................... 63
6.8.2.
6.9.
CALL RELIABILITY INTRA FREQUENCY HANDOVER ............................................................. 63
6.9.1.
Concept ......................................................................................................................... 63
6.9.2.
6.10.
CALL RELIABILITY IRAT HANDOVER ............................................................................. 67
6.10.1. Concept (UMTS->GSM)............................................................................................... 67
6.10.2. Failure symptoms, identification and fixes for improvement (UMTS->GSM).............. 69
6.10.3. Concept (CS GSM ->UMTS) ........................................................................................ 69
6.10.4. Failure symptoms, identification and fixes for improvement (CS GSM ->UMTS) ....... 70
6.11.
CALL RELIABILITY CELL CHANGE ORDER FROM UTRAN............................................... 71
6.11.1. Concept ......................................................................................................................... 71
6.11.2. Failure symptoms, identification and fixes for improvement ........................................ 71
6.12.
CALL RELIABILITY INTER FREQUENCY HANDOVER ......................................................... 72
6.12.1. Concept ......................................................................................................................... 72
6.13.
CALL RELIABILITY FAILURES ON THE TRANSPORT NETWORK ........................................ 75
6.14.
CALL RELIABILITY FAILURES ON RLC ............................................................................ 75
6.14.1. Concept ......................................................................................................................... 75
6.15.
CALL RELIABILITY HSDPA ............................................................................................ 79
6.15.1. Introduction .................................................................................................................. 79
6.15.2. Mobility aspects of HSDPA .......................................................................................... 80
6.15.3. RF related issues........................................................................................................... 82
6.15.4. UE limitations............................................................................................................... 84
6.15.5. Capacity issues ............................................................................................................. 84
6.16.
CALL RELIABILITY HSUPA/EDCH ................................................................................ 85
Introduction ................................................................................................................................. 85
6.16.2. Mobility aspects of HSUPA .......................................................................................... 85
6.16.3. MAC/ RF related Issues................................................................................................ 86
6.16.4. UE Limitations.............................................................................................................. 87
6.16.5. Capacity issues ............................................................................................................. 87
6.17.
CALL RELIABILITY MISCELLANEOUS FAILURES............................................................... 88
6.17.1. RB Reconfiguration / Transport Channel Reconfiguration failure............................... 88
6.17.2. Physical Channel Reconfiguration failures .................................................................. 89
6.17.3. Relocation failures........................................................................................................ 89
6.17.4. Failures during the RAB and RL release procedure..................................................... 91
7.
CALL QUALITY ....................................................................................................................... 92

7.1.
CALL QUALITY - BLOCK ERROR RATE (BLER) ..................................................................... 92
7.1.1.
DL Block Error Rate (BLER) analysis.......................................................................... 92
7.1.2.
UL Block Error Rate (BLER) analysis.......................................................................... 94
7.2.
CALL QUALITY QUALITY OF SERVICE (QOS) ...................................................................... 96
Page 3 of 106
Document name:
Date:
2007-06-08
7.2.1.
7.2.2.
7.2.3.
7.2.4.
Rev: 2.1
QoS general ............................................................................................................... 96

QoS voice service....................................................................................................... 96
QoS data services....................................................................................................... 97
QoS VT service ........................................................................................................ 101
APPENDIX ....................................................................................................................................... 102

A. MEASUREMENT DEFINITION ....................................................................................................... 102
A.1. Measurement definition voice .......................................................................................... 102
A.2. Measurement definition data............................................................................................ 102
A.3. Measurement definition VT .............................................................................................. 105
B. TIME SYNCHRONISATION OF MEASUREMENT TRACES ................................................................. 105
Change Record
This table details the changes done to the document since the last baseline version
Date
th
6 August 2007
Changes
Issue#
Updated draft after review with following

changes
2.1
Editorial throughout the document
Added sections like HSUPA, InterFreq HO, RRC connection reestablishment, 2G->3G IRAT HO
Page 4 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
1. Glossary of terms and abbreviations

3GPP
3G Partnership Project
ACB
Access Class Barring
ACK
Acknowledgement
AICH
Acquisition Indication Channel
ALCAP
Access Link Control Application Protocol
APN
Access Point Number
AM
Acknowledged Mode
ARQ
Automatic Repeat Request
AS
Access Stratum
ATM
Asynchronous Transfer Mode
BCCH
Broadcast Control Channel
BER
Bit Error Rate
BLER
Block Error Rate
BSIC
Base Station Identity Code (GSM)
BSS
Base Station Subsystem (GSM)
CAC
Call Admission Control
CCPCH
Common Control Physical Channel
CM
Configuration Management / Connection Management
CN
Core Network
CongC
Congestion Control
CPICH
Common Pilot Channel
CQI
Channel Quality Indicator
CRC
Cyclic Redundancy Checksum
CRCI
CRC Indicator
CS
Circuit Switched
DAHO
Database Assisted HO
DBC
Dynamic Bearer Control
DCCH
Dedicated Control Channel
DCH
Dedicated Channel
DL
Downlink
DRNC
Drift RNC
DRX
Discontinuous Reception
EDCH
Enhanced DCH
Page 5 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
ETSI
European Telecommunication Standard Institute
FACH
Forward Access Channel
FDD
Frequency Division Duplex
FM
Fault Management
FP
Framing Protocol
FSN
First SN
FTP
File Transfer Protocol
GGSN
Gateway GPRS Support Node
GMM
GPRS MM
GPRS
General Packet Radio Services
GPS
Global Positioning System
GSM
Global System for Mobile Communication
HCS
Hierarchical Cell Structure
HLR
Home Location Register
HHO
Hard Handover
HO
Handover
H-PLMN
Home PLMN
HSDPA
High Speed Downlink Packet Access
HS-DSCH
High Speed Downlink Shared Channel
HSUPA
High Speed Uplink Packet Access
HTTP
Hyper Text Transfer Protocol
H-USDPA
High Speed Downlink Packet Access
HW
Hardware
IE
Information Element
ICMP
Internet Control Message Protocol
IP
Internet Protocol
IRAT
Inter Radio Access Technology
KPI
Key Performance Indicator
LA
Location Area
LWS
Lucent Worldwide Services
MAC
Medium Access Control
MAC-hs
Medium Access Control high speed
MAHO
Mobile Assisted HO
MIB
Master Information Block
MM
Mobility Management
MMS
Multi Media SMS
MO
Mobile Originating
Page 6 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
MOS
Mean Opinion Score
MSC
Mobile Switching Centre
MSS
Maximum Segment Size
MNC
Mobile Network Code
MT
Mobile Terminating
NACK
Negative ACK
NAS
Non access stratum
NBAP
NodeB Application Part
NTP
Network Time Protocol
O&M
Operation and Maintenance
OMC-U
Operations and Maintenance Centre UMTS
PCPICH
Primary CPICH
PC
Power Control
PCH
Paging Channel
PDCP
Packet Data Convergence Protocol
PDP
Packet Data Protocol
PDU
Protocol Data Unit
PHY
Physical Layer
PICH
Paging Indication Channel
PLMN
Public Land Mobile Network
PM
Performance Measurement
PPP
Point to Point Protocol
PS
Packet Switched
PSC
Primary Scrambling Code
QE
Quality Estimate
QoS
Quality of Service
RA
Routing Area
RAB
Radio Access Bearer
RACH
Random Access Channel
RAN
Radio Access Network
RANAP
Radio Access Network Application Part
RB
Radio Bearer
RL
Radio Link
RLC
Radio Link Control
RLF
Radio Link Failure
RF
Radio Frequency
RFCT
RF Call Trace (also called IMSI tracing)
Page 7 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
RNC
Radio Network Controller
RNSAP
Radio Network Subsystem Application Part
RRC
Radio Resource Control
RRM
Radio Resource Management
RSSI
Received Signal Strength Indicator
RSCP
Received Signal Code Power
RTP
Real Time Protocol
RTT
Round Trip Time
RXLEV
Receive Level (GSM)
SACK
Selective ACKs
SC
Scrambling Code
SCCPCH
Secondary CCPCH
SCH
Synchronization Channel
SDU
Service Data Unit
SGSN
Serving GPRS Support Node
SHO
Soft/softer Handover
SIB
System Information Broadcast
SIM
Subscriber Identity Module
SIR
Signal to Interference Ratio
SM
Session Management
SMS
Short Message Service
SN
Sequence Number
SRB
Signalling Radio Bearer
SRNC
Serving RNC
TB
Transport Block
TBS
Transport Block Size
TCP
Transmission Control Protocol
TGPS
Transmission Gap Pattern Sequence
TM
Transparent Mode
TPC
Transmit Power Control
TSSI
Transmitted Signal Strength Indicator
TX
Transmitted
UDP
User Datagram Protocol
UE
User Equipment (mobile station)
UL
Uplink
UM
Unacknowledged Mode
UMTS
Universal Mobile Telecommunication Standard
Page 8 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
URA
UTRAN Registration Area
U-SIM
UMTS Subscriber Identity Module
UTRAN
UMTS Terrestrial Radio Access Network
VT
Video Telephony
A reference for abbreviations can be found in [37].
Page 9 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
2. References
[1] TS 23122 NAS Functions related to Mobile Station (MS) in idle mode
[2] TS 11.11 Specification of the SIM ME interface
[3] TS 25304 UE Procedures in Idle Mode and Procedures for Cell Reselection
in Connected Mode
[4] GSM 03.22 Functions related to Mobile Station in idle mode and group
receive mode
[5] TS 24008 Mobile radio interface layer 3 specification; Core Network
Protocols Stage3
[6] TS 25331 RRC Protocol Specification
[7] TS 25433 UTRAN Iub Interface NBAP Signalling
[8] TS 24007 Mobile radio interface signalling layer 3 specification; general
aspects
[9] TS 25413 UTRAN Iu Interface RANAP Signalling
[10] TS 25423 UTRAN Iur Interface RNSAP Signalling
[11] TS 25214 Physical layer procedures (FDD)
[12] TS 25922 Radio resource management strategies
[13] TS 25201 User Equipment (UE) Radio transmission and reception (FDD)
[14] TS 25306 UE Radio Access Capabilities
[15] TS 34121 Terminal conformance specification; Radio transmission and
reception (FDD)
[16] UMTS RF Translation Application Note (TAN) for HSDPA
[17] UMTS RF Translation Application Note (TAN) for EDCH
[18] UMTS RF Translation Application Note (TAN) for Cell Selection and
Reselection
[19] UMTS RF Translation Application Note (TAN) for Access Procedures
[20] UMTS RF Translation Application Note (TAN) for Load Control
[21] UMTS RF Translation Application Note (TAN) RLC
[22] UMTS RF Translation Application Note (TAN) RF Call Trace
[23] UMTS RF Translation Application Note (TAN) Handover
[24] UMTS RF Translation Application Note (TAN) Inter-Frequency Handover
[25] UMTS RF Translation Application Note (TAN) Inter-RAT Handover
[26] UMTS RF Translation Application Note (TAN) Inter Frequency Handover
[27] UMTS RF Translation Application Note (TAN) Radio Link Control
[28] UMTS RF Translation Application Note (TAN) Power Control
[29] Actix, http://www.actix.com
Page 10 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
[30] Ethereal, documentation and download at www.ethereal.com

[31] tcptrace, documentation and download at www.tcptrace.org
[32] Tardis2000, www.kaska.demon.co.uk/tardis.htm
[33] UMTS RF Optimization Guidelines available at
http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/guidelines.htm
[34] UMTS RF Engineering Guidelines available at
[35] UMTS Cluster Optimisation Guideline
[36] TS 25322 RLC protocol specification
[37] TS 21905 Vocabulary for 3GPP Specifications
[38] Cygwin available at http://public.planetmirror.com/pub/cygwin
[39] DR TCP available at http://www2.kansas.net/drtcp.asp
[40] TS 25323 Packet Data Convergence Protocol (PDCP) Specification
[41] Network Performance Engineering LWS Europe
http://npe.de.lucent.com/AL/arca/index.cfm
[42] Performance Measurements Definitions Manual (PMDM) for U04.03
available at
http://ns.uk.lucent.com/ctip/gsmnav/gsmsysdoc/mnode/webdocs/libfiles/pmd
mindex.htm
[43] NDP homepage
http://ge1884ndp01.de.lucent.com:7779/portal/page?_pageid=35,31210&_d
ad=portal&_schema=PORTAL
[44] Parameter consistency checks http://mobility.ih.lucent.com/~caateam/
[45] Multi-vendor PM database system http://135.246.63.129/pm_db/login.php
[46] UMTS IRAT Optimization Guidelines
[47] TR 26975 Performance characterisation of the AMR speech codec Report
[48] ITU-T J.144 Objective perceptual video quality measurement techniques
for digital cable television in the presence of a full reference
[49] RF Optimisation and Analysis Tool Suit
http://navigator.web.lucent.com/
Page 11 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
3. About this document

3.1.
Introduction
The UMTS RF Troubleshooting Guideline is the base document for the UMTS
optimisation process and is used for the identification, classification and
resolution of problems, failures or performance degradations that might be
observed during the optimisation activity.
This document covers the following items:
Drive test data analysis (Uu traces and 2G/3G scanner measurements)
Network interface tracing analysis (e.g. Iu, Iur and Iub interface tracing)
PM KPI analysis
End-to-end performance analysis
Furthermore this guideline is cross correlating the observed occurrences to the

corresponding UTRAN parameter, PM counters and KPIs of the UTRAN and/or
CN and gives references.
Last but not least this document is used as a specification for writing queries
that automatically identify and classify failures and problems from network
interface traces and drive test data. For more information see [41].
3.2.
Content
There are five main chapters in this document:
Chapter About this document is providing an introduction and an

overview of the UMTS RF Troubleshooting Guideline.
Chapter Description of the optimisation process is providing a short

overview of the UMTS optimisation process as covered by the UMTS
RF Troubleshooting Guideline.
Chapter Call setup is listing all problems that might occur at the call
establishment phase.
Chapter Call reliability is describing failures and problems that might

occur after call establishment; examples are dropped calls, radio link
failures or handover problems.
Chapter Call quality is dealing with quality problems as perceived by

the UMTS subscriber.
Page 12 of 106
Document name:
Date:
2007-06-08
3.3.
Rev: 2.1
How to read
The main analysis chapters are subdivided into subsections that are describing
the particular problems and failures step by step. Basis for the structure is the
UMTS call handling. The subsections are structured as follows:
In the first part, the problem and when applicable corresponding

UTRAN parameter are described and listed; this part has the subtitle
concept.
In the second part called failure symptoms, identification and fixes for
improvement there are if applicable three tables:
o
The first table is specifying the trigger points for the identification in
the network interface trace or in the drive test data including the type
of traces necessary for problem identification (e.g. Uu trace, 3G
scanner measurements or TCP/IP protocol interface trace)
The second table is listing the PM KPIs as retrieved by the UTRAN

or CN PM system
The third table is listing the corresponding parameter(s)
3.4. UTRAN/CN release and vendor dependency

This document is a living document and is updated on a regular basis based
on the experience coming from the different projects.
This version of the UMTS RF Troubleshooting Guideline is supporting exLucent equipment only. However it is geared towards supporting multi-vendor
equipment so long as they follow 3GPP mandated procedures. Whenever a
new UTRAN or CN network release is available certain tables and descriptions
have to be updated while others parameters are project dependent and hence
no particular value is assigned to them.
3.5.
Intended audience
This document is directed to system engineers, network planners, RF
optimisation engineers and all engineers that are going to analyse network with
the aim of optimising a UMTS network.
3.6.
Disclaimer - what is not covered

This document is not covering Element Management Layer activities. As a
consequence this Guideline cannot be used for troubleshooting maintenance
task issues. This document does not support how to trace and to operate
measurements instruments and tools. For more details check the corresponding
reference documentation.
Currently the Fault Management (FM) analysis is also not covered in this
guideline, but might be added in later releases.
This guideline is only shortly covering RF network planning and dimensioning
issues; these topics are covered in more details in [33] and [34].
Core Network specific problems are only covered in this guideline in the way to
explain how to identify these kind of problems during the analysis. The question
of the root cause and how to overcome this problem is not part of the UMTS RF
Troubleshooting Guideline.
Page 13 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
4. Description of the optimisation process

The different fields of UMTS RF optimisation can be summarised by the
following items:
FM audit and analysis
RF
design
audit
and
and [34] for a detailed description)
CM audit and optimisation
PM audit and optimisation
Drive testing and investigation
Network interface tracing and analysis
Lab investigation and optimisation
optimisation
(see
These fields of UMTS optimisation are displayed in Figure 1 in yellow below.
Figure 1: Ex-Lucent UMTS optimisation process process flow
Page 14 of 106
[33]
Document name:
Date:
2007-06-08
Rev: 2.1
Pre-requisite before starting with a performance verification and optimisation is

that
The FM analysis shows no severe alarms that might influence the

performance measurements as retrieved by the PM statistic or drive
test data
The RF design audit and optimisation has been finished for the region
to be optimised
In case, one or both pre-requisites are not fulfilled starting with the performance
investigation and troubleshooting does not make much sense.
For
troubleshooting and optimizing new clusters, the Drive test and interfaces
traces would be more relevant than PMs that may get skewed because of small
number of users.
Page 15 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
5. Call setup
One main user perception of a UMTS network is the success of setting-up a
UMTS call. This section is describing all kind of failures and problems that might
occur during the call establishment phase. The different phases during the call
setup are covered step-by-step in the following subsections of this chapter.
5.1.
Call setup RRC connection establishment
5.1.1. PLMN/cell selection and reselection

5.1.1.1.
Concept
The UE in idle mode has to perform the following tasks:
PLMN selection and reselection
Cell selection and reselection
Location registration
The whole procedure is visualised in Figure 2 below and will be explained in

detail in the following subsections:
Figure 2: PLMN (re-)selection and cell (re-) selection process

If the UE is in CELL_FACH, CELL_PCH or URA_PCH the UE also performs cell
reselections; however possible failures that may occur are covered in the
subsection regarding failures on RACH (subsection 5.1.3) and FACH
(subsection 5.1.6). In the following it is assumed that the UE is in idle mode.
Page 16 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Description of the NAS part during PLMN/cell selection and reselection

The NAS part is described in [1] and depends mainly on the information stored
on the U-SIM [2].
After power-on the UE starts with the initial cell search procedure and tries to
decode the network information as broadcasted by the 2G or 3G cells on the
BCCH. The UE is either selecting the best suitable cell (in terms of the cell
selection criteria, see below) of its H-PLMN and starts with the location
registration procedure or otherwise when the H-PLMN is not available the UE is
selecting a non-forbidden PLMN, camping on the best suitable cell and starts
with the location registration procedure.
In case there is no suitable cell of a non-forbidden network (no roaming
agreement, lack of coverage, SIM locked in the HLR etc.) the mobile enters the
Limited Service state. In this state the UE is only allowed to initiate emergency
calls in case it detects any PLMN coverage.
Description of the AS part during PLMN/cell selection and reselection
The AS part is defined in [3] (for UMTS) and [4] (for GSM). Optimisation
approach is to ensure that the UE camps on the best suitable cell (in terms of
RF conditions, traffic distribution assumptions etc.) to setup a call. The process
can be configured by O&M parameters as explained below:
In case ACB is used the UE is selecting a non-barred cell based on either cell
information stored on the U-SIM or after doing the initial cell search.
Prerequisite for the cell selection (and also cell reselection) are that the
following criteria are fulfilled:
For UMTS:
Squal = Qqualmeas - Qqualmin > 0 AND

Srxlev = Qrxlevmeas Qrxlevmin - Pcompensation > 0
For GSM:
Srxlev = Qrxlevmeas Qrxlevmin - Pcompensation > 0
The different terms in the formula are defined as follows:

Qqualmeas is the measured cell quality value. The quality of the received signal expressed in CPICH
Ec/N0 (dB) for FDD cells. Not applicable for TDD cells or GSM cells.
Qrxlevmeas is cell RX level value. This is received signal, CPICH RSCP for FDD cells (dBm),
P-CCPCH RSCP for TDD cells (dBm) and RXLEV for GSM cells (dBm)
Pcompensation
is the defined as Max(UE_TXPWR_MAX_RACH

Max(MS_TXPWR_MAX_CCH P, 0) (GSM)
P_MAX,
0)
(UMTS),
UE_TXPWR_MAX_RACH is the maximum allowed power for the RACH and P_MAX is the
maximum power for the given mobile power class.
The different O&M parameters of the formula above are listed in Table 1 below:
Parameter
Description
Qqualmin
Minimum required quality level in the cell (dB). Not applicable for TDD cells or
GSM cells, broadcasted via SIB3 and SIB4
Qrxlevmin
Minimum required RX level in the cell (dBm), broadcasted via SIB3 and SIB4
Table 1: Parameters used for cell selection
Page 17 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Remark
The current formulas can only be used in case HCS is not deployed.
Furthermore while camping the UE shall start to perform inter-RAT
measurements if Squal <= SSearchRAT, otherwise not. SSearchRAT is a configurable
UMTS parameter broadcasted on SIB3/SIB4. However note that to avoid ping
ponging between UMTS and GSM the following condition should be fulfilled:
FDD_Qmin > Qqualmin + SsearchRAT
If the above condition is not satisfied, a UE will move from GSM to UMTS and
immediately start monitoring neighboring GSM cells again, an undesirable
condition. Furthermore frequent re-selections between UMTS and GSM can
cause mobile terminating call failure in case the PLMN pages the current
network while the UE is in the process of registering with the other network.
In a similar way the criterion for UMTS Interfrequency measurements is defined;
for this parameter Sintersearch is used and is broadcasted on SIB3/SIB4.
The UE can only reselect one of the 2G or 3G cells that are defined in the
reselection list that are broadcasted via SIB11/SIB12 on the BCCH.
For cell reselection the target cell has to fulfill the same criteria as specified for
the cell selection case. The UE ranks the cells according to the cell ranking
criteria Rs (serving cell) and Rn (neighbour cell). The UE will reselect the best
GSM or UMTS cell of the ranking list if at least Treselection (UMTS parameter)
has elapsed when camping on the cell. For UMTS network without HCS the
following formulas are used (both for GSM and UMTS cells):
Rs = Qmeas,s + Qhysts
Rn = Qmeas,n - Qoffsets,n
For UMTS Qmeas is based either on RSCP or Ec/No measurements of the
server/neighbour cell depending on the setting of the UTRAN parameter
configuring the selection and reselection quality measure. Qhysts is an hysteresis
to avoid ping-pong effects, Qoffsets,n is an offset defined on a per-neighbour
definition (for both GSM and UMTS neighbours).
The reselection process using the mentioned parameters (Qoffsets,n = 0) is
visualised in Figure 3 below:
Figure 3: Cell reselection process
Page 18 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table 2 below is listing the main parameters configuring the cell reselection
process in case no HCS is used:
Parameter
Description
cellSelAndResQualMeas
Parameter defining whether CPICH or RSCP measurement shall be used for

UMTS measurements
sIB3Treselection
Time hysteresis for the cell reselection
sIB3RAT.sSearchRAT
UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start
with inter-RAT measurements (setting of SSearchRAT)
sIB3SInterSearch
UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start
with UMTS interfrequency measurements (setting of Sintersearch)
sIB3Qhyst1, sIB3Qhyst2
Hysteresis to avoid ping-pong effects (RSCP, Ec/No hysteresis)
outFDDAdjCells.cellOffset
UMTS parameter broadcasted via the SIB11/SIB12 defining an offset on a per

neighbour basis
Table 2: Most important parameter used for cell reselection, non HCS
Description of the Location Registration part during PLMN/cell selection and
reselection
The Location Registration procedure is initiated by the UE by sending MM/GMM
Direct Transfer messages. For these kinds of failures see subsection 5.3.1.
The cell selection and reselection process and its translations are covered in
more details in [18].
5.1.1.2.
Failure symptoms, identification and fixes for improvement
A failure of the PLMN selection/reselection during a drive test can be easily

identified when the screen of the drive test mobile is showing Limited Service
and the MNC of the selected cell is different from the H-PLMN. The root cause
might be a network outage due to NodeB, RNC or any particular network
interface like Iub or Iu (see also subsection 6.4.5 and 6.8) or when the test van
is driven out of the coverage footprint of the (GSM and UMTS) network. In that
case the drive test route should be checked.
When the PM counters of the CN are showing a high rejection rate due to
missing national roaming it may be caused by an interface problem to or an
outage in the roaming networks be it UMTS or GSM.
Another problem might be ACB on one or several of the surrounding GSM
and/or UMTS cells. Information regarding Access Class Barring is broadcasted
via SIB3 or SIB4 [6]. ACB is used during the integration of cells see [35] for
details.
Common problems of the cell selection/reselection procedure are non-optimised
configuration of the corresponding UTRAN parameter. As a consequence the
call will be setup on a non-optimal cell or a non-optimal RAN so the call-setup
might fail during the RACH procedure (subsection 5.1.3), the paging procedure
(subsection 5.1.2) or during the call setup procedure (subsection 5.2). A
consistency check of the parameters listed in Table 1 and Table 2 might help to
find parameter misconfiguration. Parameter Qoffsets,n used for optimisation of a
per-cell basis should be reviewed.
In case of poor 3G coverage and low call setup success rate the parameter
SSearchRAT might be set to a lower value so the UE will start earlier with inter-RAT
Page 19 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
measurements. Also the cell offsets for the GSM cells can be adapted to prefer
call setup on the 2G layer.
Another problem arises when different LA codes are defined for the GSM and
UMTS networks and the Inter-RAT reselection criterion is met. This is in
particular the case for subscribers inside a building where the UMTS coverage
is not as strong compared to the GSM coverage, but the preference is on the
UMTS network. As a consequence it is recommended to assign the same LA
codes to GSM and UMTS cells that are providing coverage to the same area to
avoid LAU ping-pong.
Table 3 below is listing the identification techniques of PLMN/cell (re-)selection
failures in drive test traces and scanner measurements:
Problem
Trace
Trigger
Wrong PLMN
selected
Uu
Any occurrence of the MNC of the cell the UE is camping on is different from
the MNC of the H-PLMN
ACB
Uu
Any occurrence of IE Access Class Barred = TRUE in SIB3/SIB4
Call setup on nonoptimal cell
Uu, 3G
scanner
The call is setup via RRCConnectionSetup message on a cell that is not on the
x best cell listed by the 3G scanner within y dB window.
Call setup on nonoptimal RAN

technology
Uu, 2G/3G
scanner
The RXLEV of the best measured 2G cell is within a x dB window (or even
better) for y seconds compared to the RSCP of the cell the UE is camping on
when sending the RRC Connection Request or Cell Update message on
RACH
Ping-pong LU
between 2G / 3G
Uu
There are two consecutive LUs between 2G and 3G within x seconds and the
LA codes for the cells are different.
Table 3: Identification of PLMN/cell (re-)selection failures in traces

Cell selection and reselection failures cannot be detected via PMs because the
process is within the UE. Failures during the Location Registration procedure
are identified via CN PMs and covered in subsection 5.3.1.
5.1.2. Failures on the AICH, PICH and PCH
5.1.2.1.
Concept
The UTRAN might initiate the paging procedure because of the following
events:
The UTRAN is receiving a paging request from the CN via RANAP
The UE has an established PDP context, but the UE is in URA_PCH or

Cell_PCH mode and downlink PS data are scheduled to be delivered in
the downlink
If the UE is in idle, URA_PCH or CELL_PCH modes and the UE is receiving a

Paging Indication on the PICH from the NodeB; then the UE is starting to
monitor the PCH to receive the paging (Paging Type 1). In case the UE is in
connected mode and is paged, then the UTRAN is sending the paging via
DCCH (Paging Type 2).
The CN might perform a repetition of paging process in case the UE has not
answered within a certain period in time. In addition the RNC might trigger the
repetition of the UE paging in the UTRAN. The repetition timers of the RNC and
CN have to be set accordantly.
In the following it is assumed that the UE is not in connected mode so it has
received a Paging Type 1.
Page 20 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
After the UE has successfully decoded the paging on the PCH it sends a RACH
Preamble using the open loop power control algorithm. When the NodeB
receives the RACH Preamble it answers by sending an indication on the AICH,
the reception of the AICH is answered by the UE by sending a RRC Connection
Request/Cell Update/URA Update message using the RACH (so called RACH
Message Part). Upon successful decoding the NodeB forwards the RACH
Message Part to the RNC. RACH failures are covered in subsection 5.1.3.
The RNC sends back (on the FACH) the RRC Connection Setup/Cell Update
Confirm/URA Update Confirm message (successful case). FACH failures are
covered in subsection 5.1.6.
5.1.2.2.
Failures on the PCH, PICH and AICH are most likely due to
Non-optimal power settings of the PICH, AICH or PCH
Poor radio conditions in terms of low RSCP or Ec/No because of e.g.

pilot pollution (subsection 6.4.1), poor RF coverage (subsection 6.4.5),
camping on a non-optimal cell (see subsection 5.1.1) etc.
Congestion on the PCH
Table 4 below is listing the main UTRAN parameters configuring the PICH, PCH
and AICH:
Parameter
Description
pICHPower
UTRAN parameter defining the power settings of the PICH
pCHPower
UTRAN parameter defining the power settings of the PCH
aICHPower
CN_PCH_Timer
UTRAN parameter defining the power settings of the AICH

1
Timeout when the CN will reinitiate the paging
tPageRep
Timeout when the RNC will reinitiate the paging
CN_PCH_Max
Maximum number of paging repetitions by the CN
nUtranPageRep
Maximum number of paging repetitions by the RNC
Table 4: Parameter used for configuring the PICH, AICH and PCH
The paging itself is sent on the PCH that is a PHY channel on Uu. The drive test
equipment can record paging requests. However analysing drive test logs is not
a good way to investigate paging problems because paging that is not received
by the UE can only be detected via parallel Iub tracing.
A better approach for analysing call setup problems due to paging failures is to
use PM counters of the UTRAN and the CN.
If the UE is in URA_PCH or CELL_PCH mode, the RRC connection is
maintained via the common physical channels (subsection 6.6). When the UE
cannot be reached via paging the UTRAN may decide to drop the RRC
connection.
CN_PCH_Timer
& CN_PCH_Max are dummy names for the parameters
Page 21 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 4: Dropped RRC connection due to unsuccessful paging

Congestion on the PCH is also indicated by the UTRAN PM system. A solution
of lowering the paging load might be to separate the FACH and PCH on the
SCCPCH by introducing an additional SCCPCH. In addition creating smaller
Location Areas / Routing Areas will also lower the paging load.
Failures on the AICH or PICH (PHY channels, no corresponding Transport
channels) can be detected only indirectly because standard drive test tools do
not record these messages that are sent only on the Uu interface. Increasing
the power settings of the particular Physical Channels will reduce the failure
rate. In addition normal RF optimisation for areas with low Ec/No will improve
the situation.
Table 5 below is listing of how failures on the PICH/AICH/PCH can be identified
in interface traces:
Problem
RRC drop due to
unsuccessful paging
Unsuccessful paging
Trace
Trigger
Iub and Iu
Cross correlation Iu and Iub trace: any occurrence where a UE page is

recorded on Iub, there is no Cell Update recorded on Iub within x seconds and
the RNC is sending back within y seconds an Iu Release Request message
with cause Release due to UTRAN generated reason (UE is either in
URA_PCH or CELL_PCH mode)
Iub
Any occurrence where a UE is paged and recorded on the Iub and there is no
answer by the UE on UL CCCH also recorded on the Iub within x seconds
Page 22 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table 5: Identification of PICH/PCH/AICH failures in traces

Table 6 below is listing the identification possibilities using KPIs/Counters
retrieved by the CN and/or UTRAN PM system.
PM
system
Counter / KPI
KPI Name / Description
RNC
VS.MM.RRCConnDrop.UTRANPagingFailure
Counting the number of RRC drops due to

UTRAN Paging failures
UtranCell
VS.MM.PagAttDiscard.ProcessorLoad
This measurement provides the number of

paging attempts discarded by the RNC TPU
due to processor load
RNC
VS.MM.PagAttRec
This measurement provides the number of

paging attempts received by the RNC
3G-SGSN
(MM.SuccPsPagingProcIu + SuccPsPagingRepititionsIu) /
(MM.AttPsPagingProcIu + AttPsPagingRepititionsIu)*100
KPI Paging success rate. Paging success rate

defines the rate of successful paging in the
packet network.
3G-MSC
VS.succFirstPageReqs
The measurement provides the number of

successful page responses from MS. The
attempt and success counts are used to
monitor the paging performance.
RNC
VS.ChannelOccupRatePCH
Provides the channel occupancy rate for the

PCH channel
Table 6: PM KPIs/Counters for PICH/PCH/AICH failures
5.1.3. Random Access Procedure

5.1.3.1.
Concept
The RACH Access Procedure is used when attaching to the network, setting up
a call, answering to a page or performing a LA Update/RA Update. The RACH
procedure has been successfully performed when the RACH Message Part is
received by the RNC upon successful decoding at the NodeB.
The RACH is transmitted on the PHY in two separated parts: first a certain
number of RACH Preambles are sent. The power of the first RACH Preamble is
relatively low and calculated using Open Loop Power Control. Each of the
following RACH Preambles are transmitted with an increased power level till an
ACK is received on the AICH. This is the case when received preamble power
exceeds the parameter physicalRACHPreambleThreshold.
Then the UE transmits the RRC Connection Request (Cell Update, URA
Update) message in the RACH Message Part. Figure 5 below illustrates the
transmission of several RACH Preambles in different Ramping Cycles and only
after the reception of an ACK on AICH, the transmission of the RACH message
part:
Page 23 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 5: RACH procedure with RACH Preambles and Message Part

When the UE is sending the RRC Connection Request message for the first
time, it resets its internal counter V300 to 1 and starting its internal guard timer
T300 (to UTRAN parameter t300); if the UE has already sent one or several
RRC Connection Request messages before, counter V300 is incremented by
one and guard timer T300 is restarted. Upon reception of the RRC Connection
Request message at the RNC, PM counter RRC.AttConnEstab.<per
2
establishment cause> is incremented by one . Upon expiry of timer T300 the
UE may start again by sending RACH Preambles depending on the status of
counter V300. If V300 <= N300 (configured by UTRAN parameter n300), the UE
increments V300 by one, resets T300 and sends the RACH Preamble again. If
V300 > N300, the UE stops sending on the RACH and stays in idle mode [6].
For the Cell Update and URA Update procedure V302 and T302 are used, the
corresponding PM counters are named VS.MM.CellUpdateReq.<per
establishment cause>. Figure 6 below is showing as an example the Cell
Update procedure:
Figure 6: Cell Update procedure supervised by T302 and V302

2
<per establishment cause> is a placeholder for e.g. OrigConvCall, OrigStrmCall etc. A full list is
available in [42].
Page 24 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Failures in the RACH procedure occur if either the RACH Preamble or the
RACH Message Part cannot be decoded.
Possible reasons for these decoding problems are:
Non optimal RACH power settings
Non optimal RACH counter/timer settings
RACH congestion
Non optimal setting of physicalRACHPreambleThreshold & RACH

search Window

camping on a non-optimal cell (see subsection 5.1.1) etc.
In the following only the RACH specific issues are covered, for the other
(common) RF issues see the corresponding subsections.
Table 7 below is listing the main UTRAN parameters configuring the RACH:
Parameter
Description
constantVal
Used by UE to calculate Initial Preamble Power
PowerRampStep
Determines the power increment between two successive RACH

Preambles
maxRetranPreamble
Determines the maximum number of preambles allowed within one

Power Ramping Cycle
physicalRACHPreambleThres
hold
The threshold for preamble detection. The ratio between received

preamble power during the preamble period and interference level
shall be above this threshold in order to be acknowledged.
SIB3MAXAllowedULTXPower,
SIB4MAXAllowedULTXPower
These parameters define the maximum allowed power the UE may

use when accessing the cell on PRACH in idle mode
mMax
Determine the maximum number of power ramping cycles allowed
t300
UE guard timer that is supervising the RRC Connection Setup

procedure when the UE is waiting for the RRC Connection Setup
message
n300
Defines the number of times the UE is allowed to send the same

RRC Connection Request message
t302
UE guard timer that is supervising the Cell/URA Update procedure

when the UE is waiting for the Cell Update Confirm/ URA Update
Confirm message
n302
Defines the number of times the UE is allowed to send the same

Cell Update/ URA Update message
Table 7: Parameter used for configuring the RACH

For a complete list of RACH parameters see also [19].
5.1.3.2.
The RACH Preambles may only be recorded in internal UE or NodeB traces,

but not by normal drive test tools. In most cases only a statistic about the PHY
Page 25 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
and MAC procedure of the RACH is listed in the drive test logs e.g. number of
3
RACH Preambles sent, last transmitted power etc .
Possible congestion on the RACH could be detected by supervision of PM
UTRAN counters (Table 9 below).
The RACH performance can be improved by changing of the power settings
and/or changing of the timer/counter as listed in Table 7.
Table 8 below is listing the identification possibilities for network interface
traces, Table 9 below is listing the identification possibilities using KPIs
retrieved by the UTRAN PM system.
Problem
Trace
RACH message
lost
Uu, Iub
Trigger
Cross-correlation Uu/Iub trace: RACH Message Part (RRC Connection
Request, Cell Update or URA Update) is recorded on the Uu, but not
recorded on the Iub interface.
Table 8: Identification of RACH failures in traces
PM
system
Counter / KPI
UtranCell
VS.RACHcongestion
This measurement provides the percentage of

time that the RACH is in congested state.
UtranCell
VS.RACHTransBlock.Good / (VS.RACHTransBlock.Bad
+ VS.RACHTransBlock.Good) * 100
KPI RACH transport block good CRC rate is

the percentage of RACH Transport Blocks with
good CRC.
UtranCell
VS.ChannelOccupRateRACH
This measurement provides the channel

occupancy rates for Radio Access Channel.
Table 9: PM KPIs for RACH failures

More RACH related PM KPIs are available in [19].
5.1.4. Call Admission Control (CAC)

5.1.4.1.
Concept
The Call Admission Control (CAC) procedure is used in order to admit or deny
the establishment of the RRC connection to avoid an overload of the UMTS
system. The CAC thresholds can be defined for uplink and downlink load
separately. The CAC algorithms and the corresponding parameter are
described in detail in [20].
The CAC is started after the RNC receives the RRC Connection Request
message on RACH and executes CAC before setting up the RL on NBAP (see
Figure 7 below):
Note: It might be that in the drive test logs a RRCConnectionRequest message is listed, but the
RACH message part is never transmitted via the air interface in case the RACH preamble has already
failed.
The higher layer (RRC) initiates the transmission of the RACH message. In case of a lower layer
failure ro deliver preamble it is up to the higher layer re-initiate the whole RACH procedure again
(means in the RRC decoding another RACH Message would be listed).
Page 26 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 7: CAC executed after reception of RACH Message Part

If the defined load thresholds for CAC are exceeded the RRC connection
establishment request is denied and a RRC Connection Reject message with
cause Congestion is sent back to the UE.
The only optimisation approach in case of CAC rejections is to optimise the RF
environment in terms of pilot pollution, neighbour list optimisation etc. In
addition it should be verified that the CAC thresholds are set correctly.
Table 10 below is listing the main parameters configuring CAC:
Parameter
Description
thrCAC2UL
Specifies the load threshold for UL call admission of a non-emergency RRC connection
request.
thrCAC2DL
Specifies the load threshold for DL call admission of a non-emergency RRC connection
request when HSDPA is disabled.
thrCAC2DLHS
DPA
Specifies the load threshold for DL call admission of a non-emergency RRC connection
request when HSDPA is enabled.
Table 10: Parameter configuring CAC

5.1.4.2.
CAC failures can only be identified in a reliable manner via PM counters or

internal traces. Reason is that the RRC Connection Reject message with cause
Congestion might also be sent in case of missing resources during the RL
setup procedure (subsection 5.1.5) or also for other failures.
Problem
RRC Connection
Reject
Trace
Uu or Iub
Trigger
After the UE sends a RRC Connection Request message the RNC replies with
RRC Connection Reject message with cause Congestion .
Table 11: Identification of RRC Connection Reject due to Congestion or

missing resources
For CAC related PM KPIs see [20] however the main PM counter is given
below:
Page 27 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM
system
Counter / KPI
Name / Description
UtranCell
RRC.FailConnEstab.CAC
This measurement provides the number of failed RRC connection

establishment with cause Call Admission Control (CAC).
Table 12: PM Counter for CAC failures

5.1.5. Radio Link Setup
5.1.5.1.
Concept
The Radio Link Setup procedure is initiated in two cases:
During the call establishment phase after the CAC is granted the RNC
requests the NodeB to allocate resources through the NBAP Radio Link
Setup message.
In case of soft handover when allocating resources on a new NodeB
Note that after the Radio Link Setup on NBAP the RNC should initiate the
establishment of the AAL2 bearer over the Iub interface using ALCAP (ALCAP
Establishment Request and ALCAP Establishment Confirm). Problems on
ALCAP could be due to ATM configuration and are outside the scope of this
document. ATM synchronisation problems are not expected at this stage of the
call because of the already successful NBAP procedure.
The same is valid for the synchronisation between NodeB and RNC via the
DCH-FP over AAL2 bearer.
Figure 8: Initial RRC Setup Steps after successful CAC
5.1.5.2.
The NBAP Radio Link Setup procedure may fail and the NodeB sends back the
Radio Link Setup Failure message.
Page 28 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
According to [7] the failure causes can be classified as follows:
Radio Network Layer Cause
Transport Layer Cause
Protocol Cause
Miscellaneous Cause
Each category has many subcauses like Transport Resources unavailable,

NodeB Resources unavailable or Semantic error etc. 3GPP has defined a
variety of failure causes. Here one major reason for NodeB resources problem
can be UCU capacity shortage, while transport resources issue can point to the
backhaul bandwidth limitation.
traces, Table 14 is listing the identification possibilities using KPIs retrieved by
the UTRAN PM system.
For identification of failures during the Radio Link Setup procedure Iub traces
are mandatory. Reason is that on Uu only the RRC Connection Reject message
is available with only two possible failure causes (congestion and
unspecified), see also subsection 5.1.4.
Problem
Trace
Trigger
Radio Link Setup I
Uu, Iub
Cross-correlation Uu/Iub trace: Any occurrence of the NBAP Radio

Link Setup Failure message on Iub and RRC Connection Reject with
cause unspecified or congestion on Iub/Uu
Radio Link Setup II
Iub
Any occurrence of the NBAP Radio Link Setup Failure message on Iub
Table 13: Identification of failures in the Radio Link Setup

PM
system
Counter / KPI
UtranCell
RRC.FailConnEstab.RLSetupFailure/RRC.AttConnEstab.sum*100
Failed RRC Connection

Establishment Rate due to RL
Setup failures
UtranCell
RLM.SuccRLSetupIub / RLM.AttRLSetupIub*100
Radio link setup success rate on

Iub
UtranCell
(RLM.FailRLSetupIub.NodeBRes.CSV + RLM.FailRLSetupIub.NodeBRes.CSD
+ RLM.FailRLSetupIub.NodeBRes.PSD) / RLM.AttRLSetupIub*100
Radio link setup failure rate on

Iub NodeB resource
UtranCell
(RLM.FailRLSetupIub.TransRes.CSV + RLM.FailRLSetupIub.TransRes.CSD +
RLM.FailRLSetupIub.TransRes.PSD) / RLM.AttRLSetupIub*100
Radio link setup failure rate on

Iub transport resource
RNC
(RLM.AttRLSetupIur RLM.FailRLSetupIur.sum) / RLM.AttRLSetupIur * 100
Radio link setup success rate on

Iur
Table 14: PM KPIs for Radio Link Setup failures
5.1.6.Call setup failures on the FACH

5.1.6.1.
Concept
This subsection is covering only call setup related failures on FACH; for failures
in CELL_FACH mode see subsection 6.7.
Page 29 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
It is assumed that the RACH Message Part has been successfully received, the
CAC has been granted and the RL are established. In this case the RNC sends
back either the RRC Connection Setup, Cell Update Confirm or URA Update
Confirm message on FACH (successful case).
The RNC sends the FACH message, resets counter V30001 and starts its
guard timer T30001. When the RNC receives the answer by the UE (RRC
Connection Setup Complete, UTRAN Mobility Information Confirm, Radio
Bearer Reconfiguration Complete, ) before T30001 expires, the RNC stops
T30001. If the RNC does not receive the message before T30001 expires, the
RNC may resend the FACH message depending on the status of counter
V30001. If V30001<= N30001 (maximum number of retries), the RNC
increments V30001 by one, resets timer T30001 and sends the FACH message
again. If V30001 > N30001, the RNC will stop sending FACHs to the UE and
will release the reserved resources on NBAP and ALCAP. Note that the RNC
will not send any failure message on the Uu.
The whole procedure is visualised in Figure 9 below:
Figure 9: Failures on FACH
Page 30 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table 15 below is listing the parameters configuring the FACH:
Parameter
Description
fACHTrafPower
UTRAN parameter defining the power settings of the FACH data part
fACHSigPower
UTRAN parameter defining the power settings of the FACH control part
uERRCConnectionSetupRes
ponseTimer
UTRAN parameter defining setting of T30001
maxRRCConnSetupRetries
UTRAN parameter defining setting of N30001
Table 15: Parameter used for configuring the FACH

5.1.6.2.
There are the following possible reasons for failures on FACH:
Non optimal UTRAN parameter settings (e.g. FACH signalling and

traffic power)
Call setup not done on an optimal cell (subsection 5.1.1)
The FACH message is not successfully decoded due to poor FACH

coverage
The message on the FACH is successfully decoded by the UE, but

afterwards the RNC cannot successfully decode the answer sent by the
UE (UE is already in CELL_DCH mode, see also subsection 5.2)
Failures on the FACH can be indicated by UTRAN PM statistics, Iub and Uu

traces. On Uu FACH failures cannot be directly observed because there is no
corresponding failure message sent.
Table 16 below is listing the identification of FACH failures on Iub, Table 17 the
corresponding PM KPIs:
Problem
Trace
Trigger
Lost FACH
message
Iub and
Uu
Cross-correlation Uu/Iub trace: one or more FACH messages are recorded on

the Iub, but not on the Uu interface
Uu or Iub
Any occurrence of a Cell Update/URA Update message and within x seconds

there is a RRC Connection Release message with specified cause other than
normal event sent back by the RNC
FACH Failure
Table 16: Identification of failures on the FACH
PM
system
Counter / KPI
UtranCell
RRC.FailConnEstab.SetupIncomplete /
RRC.AttConnEstab.sum*100
UtranCell
VS.PercentageFACHOccupancy

Failed RRC connection
Establishment Rate timeout
Occupancy rate on FACH
Table 17: PM KPIs for failures on the FACH

5.1.7. RRC Connection Reject message with specified cause unspecified
The UE might receive a rejection when trying to establish a RRC Connection
with specified cause unspecified.
Page 31 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Possible reasons for that failure message are problems in the Radio Link Setup
procedure, protocol errors or problems when sending the FACH etc. Table 18
below is listing how to identify this kind of error in Uu logs:
Problem
Trace
RRC Connection
Reject with cause
unspecified
Uu
Trigger
Any occurrence of an RRC Connection Reject message with specified cause
unspecified.
Table 18: RRC Connection Reject unspecified

There are no specific PM counters for that case; instead other PM counters with
the name RRC.FailConnEstab.<different rejection causes> are used.
5.2.
Call setup failures during the call setup phase
5.2.1. Concept
At this point in time the UE is in the transition phase to either CELL_FACH or
CELL_DCH mode. The next message will already be sent in the new mode (as
an example next message to be sent by the UE is RRC Connection Setup
Complete or UTRAN Mobility Information Confirm).
When transiting to the CELL_DCH mode there is the possibility that the UE is
already in soft/softer handover mode when sending this message. This is the
case if
The UE is allowed to report the measurements of more than one NodeB

in the RRC Connection Request / Cell Update message
The UE is supporting this feature
The measurement of more than one cell is reported in RRC Connection

Request / Cell Update message
The RNC is then directing the UE to soft/softer HO via RRC Connection

Setup, Cell Update Confirm or URA Update Confirm message
Table 19 below is listing the parameters that are important for the call setup
phase:
Parameter
Description
measQty.maxNoReport
edCellsOnRACH
Defines the maximum number of cells the UE may report on RACH
addThresholdSHO
Defines the hysteresis used at call setup to add neighbour cells to the Active Set
Table 19: Parameter important for the call setup phase

For more details about the translations see [23].
If the call is setup in an area where several NodeBs are providing marginal
coverage and it is not possible to add the radio legs quickly, there is a big
likelihood that the call setup will fail. When the call is not setup in soft/softer HO
mode the UE has to wait for the reception of the Measurement Control
messageand time-to-trigger before sending Measurement Report 1a etc.
5.2.2.Failure symptoms, identification and fixes for improvement
The RRC connection might drop in this early stage due to the following reasons:
Page 32 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Non optimal handover parameter configuring the call setup in soft/softer

handover mode
Non optimal power settings

camping on a non-optimal cell resulting in non-optimal reselection list
(see subsection 5.1.1) etc.
There are no specific PM counters available that can be used to identify issues
during the call setup phase because at this point the UE is already in
CELL_DCH/CELL_FACH mode so a drop of the RRC connection cannot be
differentiated from an RRC drop occurred in a later stage of the call. Also the
drop might occur only a very short time later, but the root cause for the failure is
one of the issues mentioned above.
Nevertheless it is possible to identify issues in network interface traces as listed
in Table 20 below:
Problem
Trace
Trigger
Call setup on a nonoptimal cell
Uu, 3G
scanner
The call is setup via RRCConnectionSetup message on a cell and at the

same time the 3G scanner is reporting at least x cells that are within a y dB
window compared to the best measured cell.
Not best cells in AS at

call setup
Uu, 3G
scanner
The number of cells in the Active Set is smaller than max AS size, but one
neighbouring cell is within xdB window compared to the Ec/No of the best
cell in the Active Set
Drop of RRC connection

at call setup
Uu
Call Setup not

soft/softer HO mode
in
Uu, 3G
scanner
The call is dropped within x seconds after sending the RRC Connection
Request or Cell/URA Update
The call is setup in non soft/softer HO mode (# of SCs in RRC Connection
Setup message is 1), the assigned SC is under the best x SCs measured
by the 3G scanner, and these SCs are within y dB window as measured by
the 3G scanner
Table 20: Identification of call setup in traces
5.3.
Call setup Core Network failures

After establishment of the RRC connection the UE and the CN exchange Direct
Transfer messages so the UE can GPRS attach to the PS network, perform a
Location or Routing Area Update or initiate a data, voice or VT call. LAU/RAU
involve just the mobility management procedures while the Call setup also
includes call control and session management protocols for CS and PS calls
respectively.
The following subsections are summarising possible failures that might occur
during these procedures. The subsections are grouped by the following three
different protocols:
Mobility Management (MM) and GPRS Mobility Management (GMM)
Call Control (CC)
Session Management (SM)
The three protocols are sublayer protocols of the Connection Management

(CM); these protocols are specified in [5] and [8]. CM failures causes like CM
Page 33 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Service Reject Cause is mapped on the Reject Cause of the Mobility

Management IE [5].
Note that (almost) any failure in this subsection is not UTRAN related because
4
Direct Transfer messages are transparent to the UTRAN . Any of the failures
can be easily detected by the corresponding failure messages.
Because the protocols are transparent to the UTRAN all PM KPIs are defined
within the CN entities e.g. SGSN / GGSN, 3G-MSC, basis.
5.3.1. Mobility Management failures
5.3.1.1.
Concept
The main function of the mobility management is to support the mobility of user
terminals, such as informing the network of its present location and providing
user identity confidentiality. A mobility management context in the SGSN or 3GMSC is a prerequisite for the initialisation of voice, data or VT services.
5.3.1.2.
For the root cause analysis please review the timer settings supervising the
mobility management protocols as specified in [5] chapter 11.2. The settings of
these timers are specified and not configurable. In addition Mobility
Management failures might be due to missing roaming agreement, locked SIM
card, CN problems like authentication not possible due to inaccessible HLR
database etc.
The failure messages are retrieved from [5] chapter 9.2 (MM/CM) and 9.4
(GMM). Table 21 below is listing the Mobility Management failures as they can
be retrieved by interface traces:
Problem
Trace
Trigger
MM
Authentication
Reject
Uu or Iub or Iu
Any occurrence of a MM Authentication reject message sent by the CN

e.g. because of not-allowed national/international roaming
CM Service Reject
Uu or Iub or Iu
Any occurrence of a CM Service reject message sent by the CN; the

reject cause will give an indication of the occurred failure.
CM Service Abort
Uu or Iub or Iu
Any occurrence of a CM Service abort message sent by the UE. This

message is sent by the mobile station to the network to request the
abortion of the first MM connection establishment in progress and the
release of the RR connection.
MM Abort
Uu or Iub or Iu
Any occurrence of a MM Abort message sent by the CN. This

message is sent by the network to the mobile station to initiate the
abortion of all MM connections and to indicate the reason for the
abortion. The rejection cause will give an indication about the occurred
failure.
MM
Location
Updating Reject
Uu or Iub or Iu
Any occurrence of a MM Location updating reject message sent by the

CN. The specified rejection cause will indicate the reason for the
failure e.g. IMSI unknown in the HLR, illegal MS/ME, roaming not
allowed etc.
GMM Attach Reject
Uu or Iub or Iu
Any occurrence of a GMM Attach Reject message sent by the CN The

specified rejection cause will indicate the reason for the failure e.g.
protocol error, wrong or incorrect IE format etc.
Exception: there might be the case that due to a bad RF environment the direct transfer messages
cannot be delivered to the other entity because the RLC layer is not able to deliver the corresponding
message also after RLC retransmissions, RLC resets etc. It is up to the corresponding higher layer
(e.g. CC, GMM, MM or SM) to react accordantly of the discarded message.
Page 34 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
GMM Authentication
and Ciphering Failure
Uu or Iub or Iu
Any occurrence of a GMM Authentication and Ciphering Failure

message sent by the UE. The specified rejection cause will indicate
the reason for the failure e.g. a sync failure.
GMM Authentication
and Ciphering Reject
Uu or Iub or Iu
Any occurrence of a GMM Authentication and Ciphering Reject

message sent by the CN.
GMM Routing Area

Update Reject
Uu or Iub or Iu
Any occurrence of a GMM Routing area update reject message sent

by the CN. The specified rejection cause will indicate the reason for
the failure e.g. protocol error, wrong or incorrect IE format etc.
GMM Service Reject
Uu or Iub or Iu
Any occurrence of a GMM Service reject message sent by the CN
Table 21: Identification of Mobility Management failures in interface traces

Table 22 below is listing the PM KPIs of the Mobility Management as they can
be retrieved by the PM system of the 3G-MSC and SGSN:
PM
system
Counter / KPI
SGSN
(MM.AttGprsAttach.U MM.SuccGprsAttach.U) /
MM.AttGprsAttach.U * 100
SGSN
(attAuthInSgsn succAuthInSgsn) / attAuthInSgsn * 100
SGSN
(MM.AttGprsDetachSgsn.U
MM.SuccGprsDetachSgsn.U) /
MM.AttGprsDetachSgsn.U * 100
3G-MSC
(attInterVLRLocationUpdates +
attIntraVLRLocationUpdates) /
(succInterVLRLocationUpdates +
succIntraVLRLocationUpdates) * 100

GPRS attach failure rate
Authentication failure rate
SGSN initiated GPRS detach failure rate
Location Update Success Rate
SGSN
MM.SuccInterSgsnRaUpdate.U /
MM.AttInterSgsnRaUpdate.U * 100
Inter SGSN routing area update success

rate
SGSN
MM.SuccIntraSgsnRaUpdate.U /
MM.AttIntraSgsnRaUpdate.U * 100
Intra SGSN routing area update success

rate
3G-MSC
VS.mobileOrigAttRejected
The counter is incremented for a mobile

origination attempt that MSC for reasons
other than system resource overload
related.
3G-MSC
VS.mobileTermAttRejected
The counter is incremented for a mobile

termination attempt that is rejected by
the MSC for reasons other than system
resource overload related.
Table 22: PM KPIs/Counters for (GPRS) Mobility Management failures

5.3.2. Call Control failures
5.3.2.1.
Concept
This subsection describes failures on the Call Control (CC) protocol. The CC
protocol is responsible for CS call establishment and clearing procedures, call
information phase procedures etc. CC procedures can only be performed if a
MM context has been established between the UE and the CN (subsection
5.3.1).
Page 35 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
5.3.2.2.
Table 23 below is listing the CC failures as they can be retrieved by interface

traces [5]; note that the specified cause might depend on the 3G-MSC/UE
vendors:
Problem
Trace
Trigger
Ubnormal
Disconnect
CC
Uu or Iub
or Iu
Any occurrence of a CC Disconnect message (either UE or CN initiated) with

specified cause other than normal event
Ubnormal
Release
CC
Uu or Iub
or Iu
Any occurrence of a CC Release / Release Complete message (either UE or

CN initiated) with specified cause other than normal event
Table 23: Identification of CC failures in interface traces

Table 24 below is listing the PM KPIs of the CC failures as they can be retrieved
by the PM system of the 3G-MSC:
PM
system
Counter / KPI5
3G-MSC
NoCCDisconnectUbnormalEvent / NoCCDisconnects * 100
Ubnormal CC Disconnect Rate
3G-MSC
NoCCReleaseUbnormalEvent / NoCCReleases * 100
Ubnormal CC Release Rate
Table 24: PM KPIs for CC failures

Depending on the specified failure cause the failure might be due to missing
resources (e.g. requested circuit/channel not available), drive test
configuration issue (e.g. User busy) or protocol failure.
For the root cause analysis please check the timer settings supervising the CC
protocol in [5] chapter 11.3. The settings of these timers are not configurable.
5.3.3.Session Management failures
5.3.3.1.
Concept
The main function of SM is to support the PDP context handling of the PS

services. The SM comprises procedures for identified PDP context activation,
deactivation and modification. SM procedures for identified access can only be
performed if a GMM context has been established between the UE and the CN
(subsection 5.3.1).
5.3.3.2.
The failure messages are retrieved from [5]. Table 25 below is listing the SM
failures as they can be retrieved by interface traces:
Problem
Trace
Trigger
SM Activate PDP Context

Reject
Uu or Iub or Iu
Any occurrence of a SM Activate PDP Context Reject

message sent by the CN. The specified rejection cause is
giving an indication of the type of failure e.g. protocol error,
missing or faulty APN, lack of resources etc.
SM Activate Secondary
PDP Context Reject
Uu or Iub or Iu
Any occurrence of a SM Activate Secondary PDP Context

Reject message sent by the CN. The specified rejection
cause is giving an indication of the type of failure e.g.
Dummy names
Page 36 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
protocol error, missing or faulty APN, lack of resources etc.

SM Request PDP Context
Activation Reject
Uu or Iub or Iu
Any occurrence of a SM Request PDP Context Activation

Reject message sent by the UE. The specified rejection
cause is giving an indication of the type of failure e.g.
protocol error, feature not supported, lack of resources etc.
SM Modify PDP Context

Reject
Uu or Iub or Iu
Any occurrence of a SM Modify PDP Context Reject

message sent by the CN. The specified rejection cause is
giving an indication of the type of failure e.g. protocol error,
service option not supported, lack of resources etc.
Table 25: Identification of SM failures in interface traces

Table 26 below is listing the PM KPIs of the SM failures as they can be
retrieved by the PM system of the GGSN:
PM
system
Counter / KPI
SGSN
(1-((SM.FailActPdpCtxMs.Cause) /
(SM.FailActPdpCtxMs.Cause+SM.SuccActPdpCtxMs))
)*100
SGSN
SM.SuccModPdpContextSgsn.U /
SM.AttModPdpContextSgsn.U * 100

Session establishment success rate
Network originated session

modification success rate
Table 26: PM KPIs for SM failures

The most common SM failures are PDP Context activation failures due to wrong
or missing APN or if the user is not allowed to subscribe to PS services. This is
also a typical configuration issue of the drive test equipment.
For the root cause analysis please review also the timer settings supervising the
SM protocol in [5] chapter 11.2.3. The settings of these timers are specified and
not configurable.
5.4.
Call setup RAB establishment

The RAB establishment is started at higher layer signalling after the RRC
Connection establishment and CM procedures are successful. Figure 10 below
is showing the flow chart for a PS data call:
Page 37 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 10: RAB establishment procedure

The RAB establishment procedure is always initiated by the RANAP RAB
Assignment Request and always terminated by the RAB Assignment Response.
The failure and failure causes of the RAB Establishment are specified in [9];
there are a variety of causes and it is up to the infrastructure vendor as to what
failure is mapped to which particular failure cause.
Table 27 below is listing how to identify failures of the RAB establishment
procedure in network interface traces:
Problem
Trace
RAB establishment failure
Iu
Trigger
Any occurrence of an RAB Assignment Response with
specified failure cause according to 3GPP6
Table 27: Identification of RAB establishment failures in traces

In the following subsections possible root causes for an unsuccessful RAB
establishment are discussed in detail.
5.4.1. Dynamic bearer control (DBC)
5.4.1.1.
Concept
Dynamic bearer control (DBC) is used to prevent overload of the R99 system in
case new radio resources or radio resources requiring more power are
requested. DBC takes place
During the RAB establishment after the RNC is receiving the RAB
Assignment Request on RANAP
There are a huge amount of failure causes, but not all related to RAB assignment failure.
Page 38 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
During the transition of CELL_PCH/URA_PCH to CELL_DCH mode

(see also subsection 6.6) after the RNC is receiving the corresponding
RACH messages
In case service based data rate increase is triggered (see also

subsection 7.2.3) after the RNC receives a corresponding RRC
Measurement Report from the UE
DBC thresholds can be defined for UL and DL load separately and DBC failure
can also occur at stages other than RAB establishment.
In case DBC grants the requested service the call handling proceeds as
specified (depending on the phase of the call), otherwise the call handling is as
follows:
During the RAB establishment the RNC sends a RAB Assignment

Response message on RANAP with specified cause No resource
available under miscellaneous class. On Uu the following
messages/outcomes will be indicating that DBC has not granted the
requested service:
o
The assigned PS RB is smaller than the default one or the one

7
requested in the PDP Context Activation message ; the default PS
RB is configurable
OR the PDP Context Activation is rejected with an appropriate
specified cause like QoS not accepted or Insufficient resources
The VT call is not granted or instead a voice call is setup
The Voice call receives a CC Disconnect message with specified

cause resource unavailable
During the transition of CELL_PCH/URA_PCH to CELL_DCH mode:
The RNC sends back the UE to idle mode with the RRC
Connection Release message and specified cause congestion
OR
The RNC sends back to the UE either a Cell Update Confirm /

URA Update Confirm message, but the RRC State Indicator is set
to CELL_PCH/URA_PCH.
In case of service based data rate increase: the RRC Measurement

Report message is just ignored so the UTRAN is keeping the current
RB and Transport Channels
Not granting the requested service by DBC indicates either high cell loading or
an area of high interference. The optimisation approach in the later case is to
optimise the RF environment in terms of reducing pilot pollution, improving RF
coverage, neighbour list optimisation etc.
DBC uses a QoS parameter in order to prioritise different user when
downgrading, see also [20] for details.
5.4.1.2.
Table 28 is listing the identification techniques in traces in case DBC is not

granting the requested service:
The requested QoS profile in the PDP Context Activation message might be ignored and only a
default one is assigned
Page 39 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Problem
Trace
Trigger
DBC RAB not

granted on Iu
Iu
Any occurrence of a RAB Assignment Response message on RANAP with

specified cause No resource available
DBC RAB not

granted on Iu
and Uu
Iu, Uu
DBC RAB PS
not granted
Iu or Iub,
or Uu
Any occurrence of a SM Activate PDP Context Reject message sent by the CN to

the UE and the specified cause is Insufficient resources
DBC RB Setup
PS
Uu
On Uu, in the RRC RB Setup Message the IE Spreading Factor is larger than the
default one and a PDP Context Activation message was sent within the last x
seconds with the requested bit rate in the DL higher than the granted one
DBC RB Setup
VT
Uu
The VT call has been requested, the called entity is also a UE with VT capabilities
but a voice RB is setup
DBC
Release
RRC
Uu
Any occurrence of an RRC Cell Update/URA Update message following within x

seconds a RRC Connection Release message with specified cause congestion
and the UE is in either CELL_PCH or URA_PCH mode
DBC RB Setup
voice
Uu
The UE is sending a CC Setup message and within x seconds gets a CC

Disconnect with cause resource unavailable
DBC Cell/URA
update failed
Uu
The UE is sending a Cell Update/URA Update message and the RNC is sending
back within x seconds a Cell Update Confirm/URA Update Confirm message with
RRC State Indicator set to CELL_PCH/URA_PCH.
Cross-correlation Uu/Iu trace: Any occurrence of a RAB Assignment Response

message on RANAP with specified cause No resource available
Table 28: Identification of DBC rejections in interface traces

For DBC related PM counters see [20] with a summarized version shown below.
Note that <Cause> can be UL interference or DL power.
PM
system
Counter / KPI
Name / Description
UtranCell
RAB.FailEstabCSNoQueuing
.<Cause>
Number of RAB Establishment Failures due to a given cause for CS

domain.
UtranCell
RAB.FailEstabPSNoQueuing
.<Cause>
Number of RAB Establishment Failures due to a given cause for PS

domain.
Table 29: PM Counters indicating potential R99 DBC failures

5.4.2.Radio Link Reconfiguration
5.4.2.1.
Concept
After DBC has taken place the RLs on the Iub have to be reconfigured using the
Radio Link Reconfiguration procedure on NBAP. The flowchart can be seen in
Figure 10.
The RNC tries to allocate resources on the Iub by sending a RL Reconfiguration
Prepare message on NBAP. The NodeB is answering by either sending a Radio
Link Reconfiguration Ready (successful case) or Radio Link Reconfiguration
Failure (unsuccessful case). The successful case ends in the RNC sending a
Radio Link Reconfiguration Commit to the NodeB. This procedure is used to
order the Node B to switch to the new configuration for the Radio Link(s) within
the Node B. The whole procedure is described in [7].
5.4.2.2.
For the failure analyses please refer to subsection 5.1.5.2.
Page 40 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table 30 below is listing the identification triggers for network interface traces,
Table 31 the corresponding UTRAN KPIs.
Problem
Trace
Trigger
Iub
Any occurrence of the NBAP Radio Link Reconfiguration Failure message on

Iub x seconds after there was a Radio Link Reconfiguration Prepare on NBAP
Radio
Link
Reconfiguration Iub
Table 30: Identification of RL reconfiguration failures in traces

PM
system
Counter / KPI
UtranCell
(VS.RLM.AttRLReconfig VS.RLM.FailRLReconfig.sum) /
VS.RLM.AttRLReconfig * 100
Total radio link reconfiguration success

rate
Table 31: PM KPIs for RL reconfiguration failures

5.4.3. Radio Bearer Establishment
5.4.3.1.
Concept
Once the required resources have been successfully reconfigured in the

NodeBthe RNC sends the Radio Bearer Setup message to the UE that sends
back the Radio Bearer Setup Complete message upon successfully allocating
resources for the new RB. The Radio Bearer Establishment procedure may fail
for different reasons (see below); in that case the UE sends back a Radio
Bearer Setup Failure message to the RNC.
When a physical dedicated channel establishment is initiated by the UE, the UE
shall start a timer T312 and wait for N312 successive in sync indications. On
receiving N312 successive in sync indications, the physical channel is
considered established and the timer T312 is stopped and reset. If the timer
T312 expires before the physical channel is established, the UE shall consider
this as a physical channel establishment failure. The whole procedure is
explained in [6].
Table 32 below is listing the parameters for the RB Establishment:
Parameter
Description
t312
The UTRAN parameter is configuring timer T312
n312
The UTRAN parameter is configuring N312
Table 32: Parameter important for the RB Establishment

5.4.3.2.
In case the UE sends back the Radio Bearer Setup Failure message to the
RNC and the Radio Bearer Establishment procedure fails.
Main reason for the failure can be subdivided as follows:
Physical Channel Failure (i.e. T312 expiry)
Unsupported or invalid configuration in the UE
Code starvation (the required channelisation code is not available

anymore from the code tree)
Protocol Error
Page 41 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
In general, the physical channel failure occurs when there is loss of

synchronisation between UE and NodeB. This is mainly caused by poor RF
conditions; see also subsection 6.1 and 6.4 for details. The other two causes
are expected to occur infrequently and in general are not related to RF issues.
The causes of the Radio Bearer Setup Failure message are listed in chapter
10.3.3.13 in [6]. Again it is up to the UTRAN vendor, which cause out of this list
is chosen for the particular failure that has occurred.
Table 33 is listing the identification techniques in traces, Table 34 the
corresponding PM KPIs for failures in the Radio Bearer Setup procedure:
Problem
Trace
RB setup failure
Uu
Trigger
Any occurrence of the RRC Radio Bearer Setup Failure message
Table 33: Identification of Radio Bearer Setup failures in traces
PM
system
Counter / KPI8
KPI Name /
Description
RNC /
Utrancell
RAB.FailEstabCSNoQueuing.RBSetupFail /
CS RAB Attempts * 100
CS RAB establishment failure

rate due to RB setup failure
RNC /
Utrancell
RAB.FailEstabPSNoQueuing.RBSetupFail /
PS RAB Attempts * 100
PS RAB establishment failure

rate due to RB setup failure
Table 34: PM KPIs for Radio Bearer Setup failures
For corresponding definitions of CS RAB Attempts and PS RAB Attempts see [42].
Page 42 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6. Call Reliability (Retainability)

This section is describing failures and occurrences that might happen after the
call has been successfully setup. This might endanger the single particular call
to drop, but also the overall quality of the UMTS network as well as user
perceived quality (section 7) might be degraded.
6.1.
Call reliability Radio Link Failure (RLF)
6.1.1. Concept
According to [11] the PHY in the NodeB and UE checks every radio frame the
synchronisation status. The status is indicated to higher layers using the CPHYSync-IND and CPHY-Out-of-Sync-IND primitives indicating in-sync state and
out-of-sync state respectively.
In the following the UL and DL are treated separately.
RLF and RL Restore in the UL
The RLF and restore procedures in the UL are supervised in the NodeB on
NBAP; the UL radio link sets are monitored to trigger if necessary RLF and RL
Restore procedures. When the radio link set is in the in-sync state and the
NodeB is receiving consecutive N_OUTSYNC_IND out-of-sync indications,
NodeB starts timer T_RLFAILURE. The NodeB stops and resets timer
T_RLFAILURE upon receiving successive N_INSYNC_IND in-sync indications.
If timer T_RLFAILURE expires, the NodeB triggers the RLF procedure and
indicates which radio link set is out-of-sync. In that case, the state of the radio
link set changes to the out-of-sync state and the NodeB indicates the RLF to the
RNC by sending a Radio Link Failure Indication on NBAP with the cause
Synchronisation Failure (see [7]).
Upon reception of this message the RNC starts timer T_RL_RESYNC (internal
RNC timer defined by the UTRAN vendor). This timer is stopped and no further
action is taken if the RNC receives from the NodeB the NBAP Radio Link
Restore Indication message. The NodeB sends this message if the radio link
set is in the out-of-sync state and the NodeB is receiving successive
N_INSYNC_IND in-sync indications. The NodeB indicates which radio link set
has re-established synchronisation. When the RL Restore procedure is
triggered, the state of the radio link set changes to the in-sync state again.
Upon expiration of timer T_RL_RESYNC, the RNC removes the particular RL in
the NodeB via the NBAP Radio Link Deletion procedure. After the deletion of
the RL the RNC starts either
With the Active Set Update procedure on RRC in case the UE is in

soft/softer HO mode; note that this is not a dropped call (in terms RAB
or RRC drop)
Timer T314/T315 (configured by parameter T314rnc for CS / T315rnc

for PS, see also Figure 17) giving the UE the possibility to re-establish
the RRC connection. In case timer T314/T315 is expired the RNC
releases the call by sending RANAP Iu Release Request message with
specified cause Release due to UTRAN generated reason to the CN.
Afterwards the RNC also releases the RRC connection by sending the
RRC Connection Release message with cause other than normal
event. The identification of this event only with Uu traces is difficult
because it is up to the UTRAN vendor of what kind of specified cause is
Page 43 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
sent in case of an UL RLF. Finally the UE sends back a RRC

Connection Release Complete and the procedure ends.
Figure 11 below is showing the call handling of the RAB release in case of a
dropped call:
CN
Figure 11: RLF is resulting in RAB drops

RLF and RL Restore in the DL:
The RLF procedure in the DL is supervised on RRC on the UE side.
In CELL_DCH state, the UE starts timer T313 after receiving N313 consecutive
out-of-sync indications for the established DPCCH physical channel. The UE
stops and resets timer T313 upon receiving successive N315 in-sync
indications.
If T313 expires, the RRC connection is dropped and the UE goes to idle mode.
In idle mode the UE will select a suitable cell according to the cell reselection
criteria and will initiate a Cell Update procedure with specified cause radio link
failure (chapter 8.5.6 in [6]).
Subsequently the RLF in the UL will be triggered when the UE is in idle mode
by the UTRAN on its own accord.
Figure 12 below is showing the transitions between the different states; the
initial state of a RL is defined as the state when a new RL is to setup:
Page 44 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 12: Transitions between different states

Table 35 below is listing the parameters that are configuring the RLF and RL
Restore procedure:
Parameter
Description
tRLFailure
This parameter is defining the setting of T_RLFAILURE
noOutSyncInd
This parameter is defining the setting of N_OUTSYNC_IND
noInSyncInd
This parameter is defining the setting of N_INSYNC_IND
radioLinkFailureResynchronisationR
esponseTimer
Configure guard timer T_RL_RESYNC to allow time for resynchronization to occur when a loss of synchronization is
detected on the last or only radio link associated with a
UE connection.
RadioLinkFailureDeletionResponse
Timer
Configure guard timer T_RL_RESYNC to allow time for the

normal operation of the handover and power control
algorithm to delete a radio link affected by a loss of
synchronization or for re-synchronization to occur when the
radio link is one of several associated with a UE
connection.
t313
This parameter is defining the setting of T313
n313
This parameter is defining the setting of N313
t314
t315
n315
This parameter is defining the setting of N315
Table 35: Parameter configuring the RLF and RL Restore procedure

6.1.2. Failure symptoms, identification and fixes for improvement
There are a variety of causes responsible for RLFs possibly resulting in dropped
calls:
Pilot pollution and around-the-corner effect (subsection 6.4.1)
Weaknesses in the neighbour planning (subsection 6.4.4)
Problems during (or before) the call establishment phase (section 5)
Problems with the RF coverage (subsection 6.4.5)
Problems with the SC plan (subsection 0)
Page 45 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
For more information please take a look in these subsections.

A RLF in the UL that is causing a removal of a radio leg can be indirectly
identified if there is no Measurement Report with type 1b/1c sent previously.
Problem is that it can be that the Measurement Report message may not have
been recorded resulting in false identification.
Identification of a dropped call due to RLF in the UL only with Uu traces is
difficult because the RRC Connection Release message sent by the RNC has
not a unique cause id. For a reliable identification additional Iub tracing is
required.
Dropped calls due to RLF in the DL can be easily identified in Uu traces with the
Cell Update message sent by the UE. There might be an optional failure cause
specified. Please review the status of the IE AM_RLC error indication, which
can be set to True. Other cell update failures are covered in subsection 6.3 and
6.14.2.
traces.
Problem
Dropped call due
to RLF in the DL
on Uu
Trace
Trigger
Uu
Any occurrence of a RRC Cell Update message with specified cell update cause
(not failure cause) radio link failure. Note that the dropped call is the previous call
and not the current one! There might be an optional failure cause specified.
RLF and RL
Restore on Iub
and Uu
Iub and
Uu
Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure

Indication on NBAP with the cause Synchronisation Failure and after x seconds
a Radio Link Restore Indication on NBAP
RLF and RL
Deletion on Iub
and Uu
Iub and
Uu

a Radio Link Deletion on NBAP and the number of radio legs is more than one
RLF and dropped

call on Iub and Uu
Iub and
Uu

a Radio Link Deletion on NBAP and the number of radio legs is equal to one
UL RLF and leg

removal on Uu
Uu
Any occurrence of an Active Set Update containing any entries in the group
RemovalInformationList and there was no Measurement Report within x seconds
before either with specified event id 1b/1c or without any specified event id9
High UE Tx power
Uu
Any occurrence if the UE is transmitting with maximum allowed power for x

seconds
High DL BLER
Uu
Any occurrence if the UE is reporting a BLER higher than x% for y seconds
Table 36: Identification of RLF in traces

Table 37 below is listing the identification possibilities using KPIs retrieved by
the UTRAN PM system. Refer to Figure 13 that shows at what point during the
call flow the PM counters are updated.
9
To be noted: the group eventResults containing the IE eventID is optional, for example when
periodic reporting is enabled.
Page 46 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM
system
Counter / KPI
UtranCell
VS.RAB.Drop.CS.DL_RLF/(RAB.SuccEstabCSNoQueuing.CSV
+(RAB.AttEstabCS.CSV.RelocIratHORAB.FailEstabCSNoQueuing.CSV.RelocIratHO) +
RAB.SuccEstabCSNoQueuing.CSD)*100
CS RAB Drop Rate due to DL RLF
UtranCell
(VS.RAB.Drop.CSV.CauseULRLF+
VS.RAB.Drop.CSD.CauseULRLF)/(
RAB.SuccEstabCSNoQueuing.CSV+
(RAB.AttEstabCS.CSV.RelocIratHORAB.FailEstabCSNoQueuing.CSV.RelocIratHO) +
RAB.SuccEstabCSNoQueuing.CSD)*100
CS RAB Drop Rate due to UL RLF
UtranCell
VS.RAB.Drop.PS.DL_RLF/RAB.SuccEstabPSNoQueuing.PS*100
PS RAB Drop Rate due to DL RLF
UtranCell
VS.RAB.Drop.PS.DCH.CauseULRLF+
VS.RAB.Drop.PS.HSDSCH.CauseULRLF+
VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail/
RAB.SuccEstabPSNoQueuing.PS*100
PS RAB Drop Rate due to UL RLF
UtranCell
VS.RAB.Drop.PS.DCH.CauseULRLF+
VS.RAB.Drop.PS.HSDSCH.CauseULRLF+
VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail
Total PS Dropped RABs cause UL RLF
UtranCell
VS.RRC.AttConnRel.Drop.ULRLF/RRC.SuccConnEstab.sum*100
RRC connection drop rate caused by

RLF
Table 37: PM KPIs indicating RLF
6.2.
Call reliability drop of the RAB
6.2.1. Concept
RAB drop due to UTRAN reasons
The drop of the RAB that is caused by a failure within the UTRAN is always
initiated by an Iu Release Request message on RANAP with cause Release
due to UTRAN generated reason; the call handling is shown in Figure 11. The
CN will send back an Iu Release Command message on RANAP with the same
specified cause (chapter 9.2.1.4 in [9]). After sending this message the UTRAN
will release the RRC connection (subsection 6.3).
To be noted that this does not mean the PDP context is removed, but e.g. a
FTP session that is up and running might time out. The UE can re-establish the
RRC connection after doing a cell reselection by sending RRC Connection
Request message with establishment cause Call re-establishment (subsection
7.2.3).
There are a variety of reasons why the RAB drops due to UTRAN reasons:
RLF (subsection 6.1) because of e.g. RF issues (subsection 6.4)
Hardware failures and outages on UTRAN (subsection 6.8)
Failures that occurred on NBAP (e.g. subsection 5.4.2)
General drops of the RRC connection (subsection 6.3)
()
For the reasons of these failures please refer to the corresponding sections.
RAB drop due to CN reasons
Page 47 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
RAB drops that are not caused within the UTRAN can be identified by the Iu
Release Command message on RANAP; the specified cause is other than
Release due to UTRAN generated reason and normal-release.
The specified cause is vendor dependent. For the root cause analysis please
check with the corresponding UTRAN vendor documentation and the
documentation of the CN vendor.
Figure 13: Drop of the RABs after RLF

Table 38 is showing the identification techniques in interface traces:
Page 48 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Problem
Trace
RAB drop due to

UTRAN reasons
on Iu
Iu
RAB drop due to

UTRAN reasons
on Iu and Uu
Iu and Uu
RAB drop due to

CN reasons on Iu
Iu
RAB drop due to

CN reasons on Iu
and Uu
Iu and Uu
Trigger
Any occurrence of an Iu Release Request message with cause Release due
to UTRAN generated reason on Iu
Cross-correlation Iu and Uu: Any occurrence of an Iu Release Request
message with cause Release due to UTRAN generated reason on Iu
Any occurrence of an Iu Release Command message with cause other than
Release due to UTRAN generated reason or normal-release on Iu
Cross-correlation Iu and Uu: Any occurrence of an Iu Release Command
message with cause other than Release due to UTRAN generated reason or
normal-release on Iu
Table 38: Identification of RAB drops in network interface traces

There are different PM KPIs describing RAB drops defined in
chapter 5, and following in [42]. The different PM KPIs describing RAB drops
are differentiated as follows:
6.3.
CS/PS RAB drops
Reason (due to UE inactivity, due to DL power, due to Inter-frequency

HHO, UE Poor Quality Minimum Rate, SRNS Relocation, )
RNC level and Utrancell level
Call reliability drop of RRC connection after call setup
6.3.1. Concept
The RRC is the context between UE and RNC on layer 3. A drop of the RRC
connection can be identified as follows:
The RNC sends a RRC Connection Release message with specified

10
cause unspecified or pre-emptive release
The UE sends a Cell Update message with cell update cause radio link
failure or RLC unrecoverable error and/or AM_RLC error indication is
set to TRUE (see below)
The UE sends a RRC Connection Request message with cause Call

re-establishment (see comments in subsection 6.2.1 and 7.2.3)
RRC Cell Update message with specified failure cause and with a cell
update cause other than radio link failure or RLC unrecoverable
error (these failures are covered in subsections 6.1 and 6.14.2; for
these two failures it might be that in addition a failure cause is specified;
11
this is up to the UTRAN vendor ).
For the variety of reasons of dropped calls (paging, RLF, Random Access
procedure etc.) please refer to the corresponding subsections in this document.
Note that the IE AM_RLC error indication in the Cell Update/URA Update is
specifying whether an error occurred on the RLC or not. If this IE is set to TRUE
10
The case RRCConnectionRelease with cause congestion is covered in subsection 5.4.1.

The likelihood of this is not very high because the specified failure causes do not match to the cell
update causes
11
Page 49 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
it is indicating that the RLC in the UE has detected a failure on one of its AM
RLC entities that has not been resolved by e.g. resetting of the RLC [36]. For
more details regarding failures on the RLC see subsection 6.14.
If there is a RRC Connection Release message with cause congestion the
reason might be either Dynamic Bearer Control (subsection 5.4.1) or
Congestion Control (subsection 6.5).
Ex-Lucent supports the RRC connection re-establishment for PS, CS and
simbearer services, where by on detection of the RLF, the UE sends a cell
update with cause RLF and consequently old radio links are deleted and the
new radio links are established by the RNC.
This procedure fails if the UE does not send the cell update, a RANAP
procedure has started or a NAS message is received to be forwarded to the UE.
The procedure will also not occur if all the radio legs are on the Drift RNC, a
RANAP procedure is in progress or UE indicates that the T314 or T315 timer
has expired.
"RRC Connection
Re-Establishment Feature.ppt"
UE
RN C su spen ds
RLC, MAC
Node B
RNC
CN
1) Cell Update (Cause Radio Link Failure)

2) Radio Link Deletion Request
3) Radio Link Deletion Response
4) ALCAP Release
N ew r a d io lin k s
ba sed u p on
m ea su r ed E c/Io
5) Radio Link Setup

6) Radio Link Setup Response
7) ALCAP & FP Synch
U E Moved ba ck
t o Cell DCH
8) Cell Update Confirm

9) Radio Bearer Reconfiguration Complete
10) UE Measurements
Figure 14: DL RLF and RRC re-establishment
Page 50 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
UE
Node B
T_RL_RESYNCH
expires, UE is PS
only
RNC
CN
1) Radio Link Failure Indication

2) Radio Link Deletion Request
RNC su spen ds
RLC & MAC,
Sta r t s Timer
T_RL_RESYNCH
3) Radio Link Deletion Response

4) ALCAP Release
RNC st ops
Tim er
5) Cell Update (Cause Radio Link Failure)
N ew ra dio lin ks
ba sed u pon
m ea su r ed E c/Io
6) Radio Link Setup

7) Radio Link Setup Response
8) ALCAP & FP Synch
UE Moved ba ck
t o Cell DCH
9) Cell Update Confirm

10) Radio Bearer Reconfiguration Complete
11) UE Measurements
Figure 15: UL RLF and RRC re-establishment
6.3.2.Failure symptoms, identification and fixes for improvement

Table 39 and Table 40 below listing the identification of dropped RRC
connection and the PM KPIs:
Problem
Trace
Trigger
Drop
of
RRC
connection I
Uu
Any occurrence of a RRC Connection Release message on Uu with specified

cause unspecified or pre-emptive release
Drop
of
RRC
connection II
Uu
Any occurrence of a RRC Connection Request message on Uu with

establishment cause Call re-establishment
Drop
of
RRC
connection III
Uu
The UE is simply going to idle mode without dropping the call in a regular way.
There are no RRC/Direct Transfer messages indicating a regular/irregular call
termination within x ms. The UE start monitoring the BCCH and might perform
a cell re-selection following a Cell Update with cause RLF or RLC
unrecoverable error (see also Table 36 on page 46).
Drop
of
RRC
connection IV
Uu
RNC sent a Cell update confirm but the UE didnt respond back with a RB
reconfiguration complete within x seconds showing failure of the reestablishment
Table 39: Identification of dropped RRC connections in interface traces

PM
system
Counter / KPI
Utrancell
VS.RRC.AttConnRel.Drop.ULRLF /
RRC.SuccConnEstab.sum*100

RRC Connection drop rate caused
by RLF
Table 40: PM KPIs of dropped RRC connections
Page 51 of 106
Document name:
Date:
2007-06-08
6.4.
Rev: 2.1
Call reliability RF planning related issues
6.4.1. Introduction
A detailed explanation of how to improve the RF environment is given in [33].
This guideline only briefly provides the techniques to identify these issues using
Uu traces and 2G/3G scanner measurements.
There are no specific PM counters available that could differentiate RRC and
RAB drops in terms of e.g. pilot pollution, round-the-corner effect etc. For that
reason no PM KPIs describing dropped calls are listed in this subsection,
reference the corresponding subsections 6.1, 6.2 and 6.3.
6.4.2. Pilot pollution
6.4.2.1.
Concept
Pilot pollution means an excessive overlapping of coverage footprints of

different cells with no dominant pilot. This leads to poor Ec/Io ratios. As a
consequence, the RLF could fail due to out-of-synchronisation (subsection 6.1).
Pilot pollution is in particular an issue when the number of best cells within a
certain range is exceeding the maximum size of the cells in the active set. In
this case the cells that cannot be included into the active set are decreasing the
quality of the signal.
Remark:
Because in HSDPA there is no soft/softer HO gain in the downlink HSDPA is
much more sensitive to pilot pollution compared to R99 services, see also
chapter 6.15 for details.
6.4.2.2.
This is a typical issue for RF optimisation and can be detected via Uu interface
traces and 2G/3G scanner measurements of the PHY. In addition the number of
cells in the active set is a good metric of how well defined are the handover
zone within the UMTS network.
Table 41 is listing identification techniques in drive test and scanner
measurement data:
Problem
Trace
Trigger
Pilot pollution I
UE or 3G
scanner
There are more than x cells with a measured Ec/No within x dB compared to
the best measured Ec/No
Pilot pollution II
UE or 3G
scanner
The aggregate Ec/No of the cells in the active set is below x dB while the
measured RSCP is above y dBm for z ms
High number of
cells in active set
Overshooting
cells
Uu
UE or 3G
scanner
The active set size is > 1 in more than x % of all measured samples12.
The Ec/No of a site y km away is within x dB of the best measured Ec/No
Table 41: Identification of pilot pollution
12
This is not really a problem to be identified in a trace; it is more an indication for in general nonoptimal RF conditions.
Page 52 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6.4.3. Around-the-corner-effect
6.4.3.1.
Concept
Around-the-corner-effect is quite often encountered in a dense urban

environment. The effect describes a moving UE where the receive level of the
cells in the active set decreases dramatically (in terms of Ec/No and RSCP)
whereas the receive level of cells in the monitored or detected set suddenly
increases. The root cause for this problem is shadowing of buildings or other
obstructions. As a consequence the quality of the call will always drop if the UE
is not fast enough to adapt (via Active Set Update) to the new RF conditions.
Figure 16 is showing the effect in a dense urban environment:
Active Set Pilot
Interfering Pilot
Figure 16: Around-the-corner problem

To overcome around-the-corner problem local optimisation of the RF
environment is required. In addition the RF planer has to ensure that the
parameters configuring the handover procedure is fast enough (subsection 6.9).
A detailed explanation of how to improve the RF environment is explained
in [33].
6.4.3.2.
Around-the-corner effect can be detected via UE traces when analyzing the

PHY; Table 42 is summarising the triggers in UE traces:
Problem
Trace
Trigger
Around-the-corner
effect I
Uu
Sudden drop/increase of the Ec/No of cells in the active set by x dB for the
next at least y ms; the average aggregate Ec/No is below z dB
Around-the-corner
effect II
Uu
Sudden drop/increase of the RSCP of cells in the active set by x dB for the
next at least y ms; the average aggregate RSCP is below z dBm
Table 42: Identification of around-the-corner effect
Page 53 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6.4.4. Non-optimal neighbour definitions

6.4.4.1.
Concept
One of the essential tasks of RF planning is neighbour list assignment. When

the neighbour lists are not well defined the UE might not be on an optimal cell
(or set of cells) and the call is endangered to drop.
The following neighbour lists exist in the OMC:
3G-3G soft/softer MAHO list
3G-3G soft/softer DAHO list
3G-2G neighbour MAHO list
3G-2G neighbour DAHO list
2G-3G neighbour list
The parameters configuring the intra-frequency soft/softer HO are listed in

subsection 6.9, IRAT parameter settings are covered in subsection 6.10. This
subsection is focused on the integrity of the different neighbour lists definitions
itself.
To maintain the integrity of the different HO list it is required to use a database
system with the following tables:
Table keeping site specific information of the UMTS cells

o
Site id (for identification for co-located 2G/3G cells)
Sector id (to check if a 2G cell is identical resulting in identical

coverage footprint for a possible DAHO definition)
Userlabel
Flag borderCellToGSM
Table keeping site specific information of the GSM cells

o
Site id (for identification for co-located 2G/3G cells)
Sector id (to check if a 3G cell is identical resulting in identical

coverage footprint for a possible DAHO definition)
BCCH frequency
Different neighbour lists including

o
nLSAPriority flag for 3G-3G HO definition (see also subsection

6.9 for details)
Distance between the two cells
With this kind of information the following database queries might be defined
Check for symmetry or reciprocity
Check for missing co-located neighbour definition (3G-3G, 3G-2G, 2G3G)
Check for right nLSAPriority flag
Check for missing DAHO definitions
Figure 17 below is showing a sample database in MS Access format:
Page 54 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 17: neighbour list checking using MS Access

The RF template files that are converting OMC XML data into MS Excel format
can be reused for these kinds of consistency checks see also [43] for details.
Some consistency checks are also available in the Ex-Lucent Intranet [44].
Some ex-Lucent tools like LDAT [49] have the missing neighbour list analysis
feature that can be used to debug.
6.4.4.2.
Following methods can be used to fix/detect a non-optimal neighbour list

assignment:
Cross-correlation
measurements
of
Uu
drive
test
logs
with
2G/3G
scanner
Missing 3G-3G neighbour definition: measured RSSI is relatively

high, but the RSCP of the cells in the active set is relatively low
Missing 3G-2G neighbour definition: the measured RSSI is

relatively low and the GSM coverage footprint is relatively strong
as measured by the 2G scanner, but the IRAT handover is not
triggered
Page 55 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Missing 2G-3G neighbour definition: UE is staying in 2G although

there is sufficient 3G coverage as indicated by the RSSI
measurements of the 3G scanner
Analysis of the UE Measurement Reports: the UE might report

cells of the detected set but these cells are not defined in the
NLSA (see also subsection 6.9 and [23] for details)
Analysis of the handover matrix as available in the PM system (see

below)
RF prediction tool analysis, see also [33] and [34]
Example for an analysis of the PM Handover matrix

The following is giving an example of the analysis of the IRAT HO matrix.
In the PM system the IRAT HO Matrix is given as follows:
NumUMTS.GSM.HOPerNCell.Att
NumUMTS.GSM.HOPerNCell.Fail
NumUMTS.GSM.HOPerNCell.Ncell.CI
NumUMTS.GSM.HOPerNCell.Ncell.LAC
NumUMTS.GSM.HOPerNCell.Ncell.MCC
NumUMTS.GSM.HOPerNCell.Ncell.MNC
The counters have to be imported into a database as described in [45].

Afterwards the analysis can be done using SQL queries with the focus on
Deletion of unnecessary handover definitions
Investigation of high amount of HO failures
In a similar way the intra-frequency HO matrix can be analysed.

traces, Table 44 is listing the identification possibilities using KPIs retrieved by
the UTRAN PM system:
Problem
Trace
Trigger
Missing
3G/3G
neighbour definition
Uu, 3G
scanner
Any occurrence where the measured RSSI (retrieved by 3G scanner) is

within a xdB window compared with the measured aggregate RSCP of the
cells in the active set (measured by the UE) for y seconds; at the time of
the measurement the UE is in 3G
Missing
3G/2G
Uu, 2G
scanner
The measured RXLEV of the best 2G cell (measured by the 2G scanner) is

within a xdB window compared to the measured aggregate RSCP of the
cells in the active set (measured by the UE) for y seconds; at the time of
the measurement the UE is in 3G
Missing
2G/3G
Uu, 3G
scanner
Any occurrence where the measured RSSI (retrieved by 3G scanner) is

within a xdB window compared with the measured RXLEV of the 2G
serving cell (measured by the UE) for y seconds; at the time of the
measurement the UE is in 2G
Table 43: Identification of non-optimal neighbour definitions in traces
Page 56 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM
system
Counter / KPI
UtranCell
(VS.MX.HHO.IntraFreq.Succ /
VS.MX.HHO.IntraFreq.Att) * 100
Intra-frequency HHO success rate

per neighbour cell
UtranCell
((HHO.SuccOutInterFreq.Qual + HHO.SuccOutInterFreq.Load)
/ (HHO.AttOutInterFreq.Qual +HHO.AttOutInterFreq.Load)) *
100
Inter-frequency hard handover

success rate
UtranCell
(RRC.SuccConnEstab.IratCCO /
RRC.AttConnEstab.IratCCO) * 100
Incoming IRAT PS success rate

(GSM -> UMTS)
UtranCell
((IRATHO.AttIncCS - IRATHO.FailIncCS.sum) /
IRATHO.AttIncCS) * 100
Incoming CS Inter RAT handover

success rate (GSM->UMTS)
UtranCell
(IRATHO.SuccOutPSUTRAN /
IRATHO.AttOutPSUTRAN)*100
Outgoing PS Inter RAT handover

success rate (UMTS->GSM)
UtranCell
(IRATHO.SuccOutCS / IRATHO.AttRelocPrepOutCS)*100
Outgoing CS Inter RAT handover

success rate (UMTS->GSM)
Table 44: PM KPIs identifying non-optimal neighbour definitions

6.4.5. Poor RF coverage
6.4.5.1.
Concept
Especially in the early days of 3G there will be many areas with a poor RF
coverage. But also after the integration of the sites it might happen that due to
cell breathing especially in the busy hour the Ec/No is not sufficient to
guarantee for some services like 384 kbit/s sufficient RF coverage. When this
happens either the radio bearer has to be reconfigured due to an increasing
BLER in the DL when using a PS data service (subsection 6.17.1 and 7.1.1) or
a 3G/2G IRAT handover has to be triggered to rescue the call (subsection
6.10).
In subsection 6.7.1 a drop of the RRC is described for a mobile in CELL_FACH
mode. In subsection Error! Reference source not found. a similar scenario is
described for a UE in CELL_PCH/URA_PCH mode.
6.4.5.2.
Low RF coverage can be identified as follows:
Low receive level in terms of RSSI (means low measured RSCP

values)
High NodeB TX power (probably also high UE TX power)
One root cause for low RF coverage might be a NodeB outage; this has to be
crosschecked with the FM data (see also subsection 6.8).
Table 45 below is listing identification triggers for low RF coverage in network
interface traces:
Problem
Low
coverage I
Trace
Trigger
RF
3G scanner
or Uu
Measured RSSI of the 3G cells is below x dBm for y seconds
Low
RF
coverage II
3G scanner,
Uu
Measured aggregate RSCP of the cells in the active set is below x dBm for y
seconds and there is no RSCP of a 3G cell measured by the 3G scanner
better than z dB compared to the aggregate RSCP
Low
RF
Uu, RFCT
The reported NodeB TX power is for x second above y dBm and the measured
Page 57 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
coverage III
Low Ec/No
RSCP of that NodeB is below z dBm

Uu
Measured aggregate Ec/No of the cells in the active set is below x dB for y
seconds
Table 45: Identification of low RF coverage in network interface traces
6.4.6.Poor PSC plan

The PSC is used for cell identification during the initial cell search and when
measuring the neighbour cells in idle and connected mode. Different strategies
and a guideline for PSC planning and how to unveil weaknesses in the PSC
assignment are described in [33].
In case the rules in that guideline are not followed the UE may make failures in
the neighbour list measurements or in case of overlapping coverage areas of
two NodeBs sharing the same PSC, interference and synchronisation issues
will occur. This will be the case if an overshooting site has the same PSC as
one of the cells in the active set causing co-pilot interference or if the
neighbours of the two existing active set cells share the same PSC creating NL
ambiguity.
It is hardly possible to identify PSC issues in drive test data because the
measured low Ec/No values or even RLF can also be the result of pilot pollution
or around-the-corner effect (subsection 6.1 and 6.4.1). Also there are no
specific PM counters that may track these issues.
6.5.
Call reliability Congestion Control (CongC)
6.5.1. Concept
The Congestion Control (CongC) function is used to monitor, detect and handle
situations when the system is going into overload or getting close to an overload
situation. CongC is based on UL and DL load estimations. CongC handles
users already in connected mode.
Congestion control is configurable using UTRAN parameters; the algorithm is
proprietary, see reference UTRAN vendor documentation. The RNC can initiate
the following actions for already connected users to resolve the overload
situation:
Transit (several or all) users connected to PS data services to a lower

bit rate (e.g. from 384 kbit/s to 128 kbit/s)
Transfer of (several or all) PS data users to another state e.g. from

CELL_DCH to CELL_FACH, idle or URA_PCH/CELL_PCH or from
CELL_FACH mode to URA_PCH/CELL_PCH or idle mode (subsection
6.7 and 6.6).
Start dropping (several or all) RRC connections of non PS users
The lowering of the PS data rate is done by using either the RB Reconfiguration
procedure or the Transport Channel Reconfiguration procedure (subsection
6.17.1).
The state transfer is done by the RRC Connection Release procedure (transfer
to idle mode, RAB is released) or by the RB Reconfiguration procedure (transfer
to CELL_FACH or URA_PCH/CELL_PCH mode, RAB is set to inactive); in both
cases the PDP context is retained.
Page 58 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Dropping of the RRC connection is done using the RRC Connection Release
message with specified cause congestion.
The initiating of CongC is indicating a high noise raise of the RF environment.
The only optimisation approach in that case is to optimise the RF environment
in terms of pilot pollution, neighbour list optimisation etc.
More detailed information can be found in [20].
Table 46 is listing the identification techniques in traces in case of CongC,
relevant PM KPIs are also listed in [20].
Problem
CongC
Release
Trace
RRC
CongC RRC PS
data reduction DL
Trigger
Uu
Any occurrence of an RRC Connection Release message with

specified cause congestion and the UE is either in CELL_FACH or
CELL_DCH PS mode13
Uu, TCP/IP trace

in or after CN
Cross-correlation of interface traces on Uu and TCP/ in or after CN

side: Any occurrence when either the PS data rate is reduced or the
UE is transferred from CELL_DCH to CELL_FACH / CELL_PCH /
URA_PCH mode and at the same time there is still data in the RLC
buffer of the RNC as measured in Ethereal
Table 46: Identification of CongC in interface traces
6.6.
Call reliability failures in URA_PCH/CELL_PCH mode
6.6.1. Concept
When the UE is in CELL_PCH or URA_PCH, the RRC Connection is
maintained using common physical channels (RACH in the UL and the PCCH in
the DL). On the UTRAN side no dedicated radio resources are allocated
(means no RB on RRC and RL on NBAP). On the CN side there is always a
RAB associated with the RRC connection but the RAB is marked (inside the
RNC) as inactive. When there are any data coming from the CN side, the RLC
buffer in the RNC belonging to the RAB is buffering the data and the RNC will
initiate a state transition of the UE to deliver the DL data. For TCP applications
this is appropriate because TCP traffic always starts using the Slow Start
procedure, but for UDP or RTP this might result in lost data frames.
The UE can send data via the RACH in UL. The UE might indicate to the RNC if
the UE RLC buffer is filled up rapidly by sending RRC Measurement Report 4a
on RACH. The UTRAN may or may not initiate a state transition. The behaviour
is UTRAN vendor dependent and configurable via O&M parameter.
According to [6] the UE has to monitor the PICH and PCH, do periodical
URA/PCH updates and perform cell reselections.
In might be that URA_PCH/CELL_PCH mode is not used. Instead for a PS call
when the inactivity timer elapsed the RRC resources are released while
maintaining the PDP context; the UE is sent to idle mode. The associated RAB
is removed.
The advantage of the URA_PCH/CELL_PCH mode compared of the idle mode
is that the re-establishment can be done faster because the RAB and RRC
13
Note that when the UE is in URA_PCH mode or CELL_PCH mode the release message with cause
congestion is used when DBC is triggered.
Page 59 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
connection does not need to be re-established again. Disadvantage is that there

are still some (very low) UTRAN resources the RNC has to maintain.
Figure 18 below is showing the transition phases between different UE states:
URA_PCH /
CELL_PCH
Cell DCH
HSDPA
Cell FACH
Cell DCH
DCH
IDLE
Figure 18: Transition phases between the different UE states
Failures and dropped RRC connections when the UE is in URA_PCH or
CELL_PCH mode might occur in the cell selection/reselection process
(subsection 5.1.1), failures due to periodical URA/PCH updates (subsection
5.3.1). For dynamic bearer control (DBC) failures see subsection 5.4.1. Failures
due to PCH/AICH/PICH or the RACH procedure might lead to a drop of the
RRC connection and drop of the PDP context as described in subsection 5.1.2.
In this case the RAB will be removed.
Failures due to the RB Reconfiguration procedure are described in subsection
6.17.1.
6.7.
Call reliability failures in CELL_FACH mode
6.7.1. Concept
When only a small amount of data has to be exchanged the UE can be in
CELL_FACH mode camping on one cell in order to save battery and RF
network resources. The UE has no dedicated UTRAN radio resources; the RRC
connection is established using the common channels (FACH in the DL and the
RACH in the UL), on Iub there are no reserved resources available. There is
always a RAB associated with the RRC connection because any DL data
received by the GGSN has to be forwarded to the UE. The concept is similar to
that described in subsection 6.6.1; difference is that a state transition is not
mandatory (but might be useful).
Page 60 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
According to [6] the UE has to monitor the FACH transport channels in the
downlink. The UE in CELL_FACH mode informs the UTRAN when reselecting a
new cell by sending a RRC Cell Update message on RACH; the RNC answers
by sending a Cell Update Confirm message on the FACH and the procedure
ends with the UE sending an UTRAN Mobility Information Confirm message
again on RACH.
The SRNC decides whether or not to transit the UE to another state. Figure 18
is showing the different UE states and possible transition between them. In all
cases the RNC will initiate the transition by using either the RB Reconfiguration
or the Transport Channel Reconfiguration procedure on RRC (subsection
6.17.1). It might be necessary to either delete or setup resources on the Iub via
the corresponding NBAP procedures (exception is the transition from
CELL_FACH to URA_PCH/CELL_PCH but this should occur rarely).
The algorithms are vendor dependent taking into account traffic measurements
and the RF environment. Please check in the particular UTRAN vendor
parameter description.
Figure 19 and Figure 20 below are visualising the call handling for the transition
from CELL_DCH to CELL_FACH and vice versa:
Figure 19: Call handling for transition from CELL_DCH to CELL_FACH
Page 61 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 20: Call handling for transition from CELL_FACH to CELL_DCH

The RNC may decide to release the RRC connection due to e.g. CongC. In this
case the RNC sends a RRC Connection Release message on FACH and the
UE sends back a RRC Connection Release Complete message on RACH
before transiting to idle mode. In parallel the RAB will be released.
A drop of the RRC connection might occur if the UE is leaving the RF coverage
area and then when coming back the UE has to inform the UTRAN by sending
a Cell Update message with cause Re-enter service area. In the meantime the
UTRAN might already have dropped the RRC if it had tried and failed to send
PS data in the DL.
The following failures might occur for UEs in CELL_FACH mode or during the
transition from/to CELL_FACH mode:
Failures related to the cell selection / reselection (subsection 5.1.1)
Failures related to the Random Access Procedure (subsection 5.1.3)
Failures related to the FACH (subsection 5.1.6)
Failures related to the setup of the RL on NBAP (subsection 5.1.5)
Failures related to the Radio Bearer Reconfiguration/ Transport

Channel Reconfiguration procedure on RRC (subsection 6.17.1)
Table 47 is listing failures for UEs in CELL_FACH mode and how to identify it in
traces:
Problem
Dropped call in
CELL_FACH
Trace
Uu
Trigger
Any occurrence when the RRC connection dropped while the UE was in
CELL_FACH state
Table 47: Failure identification in traces if the UE is in CELL_FACH mode
Page 62 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
There are a lot of PM counters available counting the number of attempts and
failures for the state transitions, see [42] for details.
6.8.
Call reliability hardware and network interface outages
6.8.1. Concept
Hardware failures can occur on the different nodes of the UTRAN and the CN,
but also on the particular interfaces as defined in the 3GPP specification. There
are many reasons for outages; analysing the retrieved FM data can give a good
indication for the failure cause.
Outages may lead to drops of the RAB and the RRC connection because of
missing synchronisation. Furthermore coverage issues (subsection 6.4.5),
problems in the neighbour definition (subsection 6.4.4) and problems in the
cell/PLMN selection/reselection procedure (subsection 5.1.1) may also occur
leading to dropped calls and network degradation even on NodeBs not affected
by the outages.
Outages can be easily identified when tracing the interfaces that have been outof-sync. Table 48 is listing possibilities of detecting the outages:
Problem
Trace
Trigger
Iub out-of-sync I
Iub
Missing STAT PDUs on AAL5 for more than 5 seconds
Iub out-of-sync II
Iub
Any occurrence of an AuditRequiredInformation on NBAP
Iu out-of-sync I
Iu
Missing STAT PDUs on AAL5 for more than 5 seconds
Iu out-of-sync II
Iu
Any occurrence of an Reset on RANAP
Table 48: Identification of outages in network interface traces
6.9.
Call reliability intra frequency handover
6.9.1. Concept
In UMTS networks intra-frequency soft/softer handover is one basic feature that
ensure seamless mobility as well as call performance and quality improvement.
The soft/softer handovers can be either requested by the UE (mobile evaluated
HO) or can be triggered by the UTRAN (network evaluated HO). In addition it is
assumed that the reporting criteria are set to event triggered rather than
periodically. All intra-frequency measurement reporting events (1a to 1i) are
defined in [6].
According to [12] the soft/softer HO procedure consists of the following steps:
Cell search and measurements of cells in the active set and the
monitored set
Reporting of measurement results by the UE (RRC Measurement

Report message including specified event id)
The HO algorithm
Allocation/release/change of network resources on NBAP
Execution of the HO (RRC Active Set Update message) by the RNC
If necessary execution of RNS relocation procedure (subsection 6.17.3)
Page 63 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Active Set Update Complete message on RRC from UE (successful

case)
RNC updates the measurement parameters including cells belonging to

the new monitored set and other measurement parameters via the RRC
Measurement Control Message
The different steps are configurable using UTRAN O&M parameters. As an

example Figure 21 below is visualising the HO parameter like time to trigger
(T) and the HO hysteresis for the Measurement Report events 1a, 1b and 1c:
Figure 21: HO parameter for event 1a, 1b and 1c

The call handling depends on the type of event; as an example Figure 22 below
is showing a flowchart for an intra-RNC Active Set Update procedure of type
event 1a (the grey box contains the RL deletion in case of event 1c):
Page 64 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 22: Call handling flowchart of Active Set Update event 1a (event 1c)
HO related parameters and more detailed information about the Ex-Lucent
implementation is available in [23].
There are many different reasons why the HO procedure might fail or not
executed in an optimal manner:
Measurement problems of the cells in the active and monitored set.

These failures are most likely due to RF planning issues like nonoptimal neighbour definitions, pilot pollution, weak PSC plan etc. (see
subsection 6.4 for details)
Misconfiguration of UTRAN parameter setting up the filtering, timing

and HO algorithm
Problems with the allocation of network resources on NBAP: Radio Link

Setup procedure in case no RL exists to the particular (new) NodeB
(subsection 5.1.5) and Radio Link Addition procedure in case there is
already a RL to the NodeB
Problems during RNS relocation procedure are covered in subsection

6.17.3
Failures during the release of network resources on NBAP (e.g. event

1c); these failures should occur very rarely (subsection 6.17.4)
Page 65 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Measurement Control Failure message (e.g. because the UTRAN

instructs the UE to perform a measurement that is not supported by the
UE)
RRC Active Set Update failure message from UE in case of

o
Unsupported or invalid configuration
Incompatible simultaneous reconfiguration
Invalid Active Set Update message
The UE is in a wrong state to receive that message (means

another state than CELL_DCH)
Protocol error
Physical channel error
()
The filtering, timing and HO algorithm are configurable by UTRAN parameter.

For each UTRAN vendor default parameter settings should be in place.
Especially in dense urban environment these parameter had to be optimised
e.g. to react faster to the around-the-corner effect or in areas with weak
coverage to trigger the 3G-2G HO faster.
Table 49 below is summarising how to identify these issues in network interface
traces. Note that the handover delay can be confused with missing RRC
messages (check event id of Measurement Report with removal/addition list of
ASU message). Long handover delays can result in dropped calls and in a
decrease of the overall UMTS RF conditions.
Problem
Intra
Delay
Frequency
Trace
Handover
Trigger
Uu
Any occurrence where the UE sends a Measurement Report 1x

and the RNC does not reply with an Active Set Update message
within y seconds
Active Set Update Failure
Uu
Any occurrence where the UE is sending an Active Set Update

Failure message
Long delay of Measurement

Control message after Active
Set Update Complete for event
1x
Uu
Any occurrence where the RNC is not sending the Measurement

Control message within y seconds after the UE has sent the Active
Set Update Complete message and the event ID of the last
Measurement Report has been event 1x14
Dropped call during event 1x
Uu
Any occurrence of a dropped call within y seconds after the RNC

has sent an the Active Set Update message and the event ID of
the last Measurement Report has been event 1x
HO event 1a/1c is too slow
Uu, 3G
scanner
There is one (or more) intra-frequency cell measured by the 3G

scanner that is not in the active set and its Ec/No is for x seconds
better than y dB compared to the best cell in the active set and the
UE is not sending within that time period a Measurement Report
with id 1a or 1c
Ping-pong HO
Uu
Whenever a cell is added to the active set (event 1a) , it is

removed within x seconds again (event 1b or 1c) or vice versa
Measurement Control Failure
Uu
Any occurrence where the UE is sending an Measurement Control

Failure message
Table 49: Identification handover issues in traces
14
In case of e.g. periodic reporting an update via Measurement Control message is not required
Page 66 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM KPIs related to the intra-frequency handover process are available in [23].
6.10. Call reliability IRAT handover

6.10.1.
Concept (UMTS->GSM)
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.
Two different procedures might be used:

Procedure 1:
The measurement reporting and filtering methods are similar to the one of the
intra-frequency handover as explained in subsection 6.9. When the measured
Ec/No or RSCP of the cells in the active sets drops below a certain threshold,
the UE sends a Measurement Report 2d to the RNC and after receiving the
RB Reconfiguration message from the UTRAN goes in compressed mode to
start the IRAT measurements as specified in the Measurement Control
message. When the measured Ec/No or RSCP of the cells in the active sets
exceeds a specific threshold the UE sends a Measurement Report 2f. The UE
may then leave compressed mode after it receives the Measurement Control
message with IE tgps-Status deactivate.
While in compressed mode, if the measured level on the GSM/GPRS system
exceeds a predefined threshold and the measured Ec/No or RSCP of the cells
in the active set is below a predefined threshold, the UE sends the
Measurement Report 3a. The UTRAN/BSS might decide to trigger the IRAT
handover by sending the Handover From Utran command on RRC.
Procedure 2:
This procedure is using Measurement Report 1f and Measurement Report
6a based on which UTRAN may send the UE (via RB Reconfiguration
message) into compressed mode. The RNC sends two Measurement Control
messages (a short one defining when the UE will automatically leave
compressed mode as specified by IE TGPS and a following Measurement
Control message with the IRAT handover list including BSIC and BCCH; the IE
BSIC verification required is set to not required). The UE is now starting to
periodically report the BCCH and RXLEV, but not of the BSIC. The UE may
send in between a Measurement Report 1e including SC and measured Ec/No
and/or RSCP of a 3G cell exceeding the 1e threshold; the RNC may or may
not react on this Measurement Report by sending an Active Set Update
message.
Meanwhile the UTRAN may send another Measurement Control message
including a modified (shorter) GSM neighbouring list to measure, but now the IE
BSIC verification required is set to required. The UE is continuing reporting
the IRAT neighbouring cells, but now not only the BCCH and RXLEV, but also
including the decoded BSICs.
After some time the UE either automatically leaves compressed mode or the
UTRAN selects one of the reported GSM cells as handover candidate by
sending the Handover From Utran command on RRC.
Page 67 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 23 below shows the call flow chart across the UMTS and GSM network
for performing UMTS to GSM voice handover including the UMTS and GSM
CN:
Figure 23: Flow chart of successful UMTS to GSM voice handover

The major components that constitute failures of UMTS to GSM Handover may
be classified as following:
RB reconfiguration failures when entering/leaving compressed mode

(subsection 6.17.2/not in this figure)
Relocation procedure failures (subsection 6.17.3/phase 1 in figure)
Handover procedure failures in GSM network (phase 2 in figure)
Release procedure failures (subsection 6.17.4/phase 3 in figure)
Upon successful completion of the relocation procedure, the SRNC sends the
Handover From UTRAN Command including the GSM Handover Command to
Page 68 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
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.
According to [9] the failure causes specified within this message can be
subdivided as follows:
Physical channel failure
Unacceptable configuration
Protocol error
The first failure refers to the case when there is loss of synchronisation between
UE and NodeB. This is mainly caused by poor RF conditions. The other two
causes are expected to occur seldom and in general are not related to RF
issues.
The IRAT HO can be configured with the parameters as described in [25].
More information about IRAT Handover optimisation is available in [46].
6.10.2.
Failure symptoms, identification and fixes for improvement (UMTS>GSM)
In case of a high failure rate during the IRAT handover procedure it should be
checked if the HO has to be triggered earlier under better 2G and 3G radio
conditions.
Table 50 below is listing the identification triggers for IRAT HO problems in
traces:
Problem
Trace
Trigger
Delayed IRAT HO
after event 3a
Uu
Any occurrence of a Measurement Report 3a sent by the UE, but there is no

Handover From UTRAN Command within x seconds
Handover From
UTRAN
Command Failure
Uu
Any occurrence of a Handover From UTRAN Command Failure message sent

by the UE
RRC
drop
compressed
mode
Uu
Any occurrence of a drop of the RRC connection when the UE was in

compressed mode
in
Table 50: Identification of IRAT HO problems in traces

6.10.3.
Concept (CS GSM ->UMTS)

The IRAT for GSM to UMTS would allow the operator to make use of the 3G
coverage in case of GSM network overload or simply to maximise the usage of
UMTS network. However the HO is actually initiated by the GSM network and
hence not discussed any further. This HO is limited to CS calls and in case of
combined CS/PS call the UE is required to setup the PS part of the call upon
successful completion of CS handover.
The following figure shows HO execution signaling flow that starts with the RNC
receiving Relocation Request from 3G MSC and ends when the RNC sends
back Relocation Complete after receiving Handover to UTRAN Complete
RRC message from the UE. From UTRAN perspective hoToUtranCompleteTimer
is used to ensure that RNC will release the resources if it does not receive any
abort or failure messages, in case of unsuccessful attempt.
Page 69 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 24: Flow chart of successful GSM to UMTS CS handover

6.10.4.
Failure symptoms, identification and fixes for improvement (CS GSM >UMTS)
Some main reasons as to why the GSM to UMTS handover procedure may fail
can be as follows. For a full list please refer to [25].
The GSM to UMTS handover feature is not enabled in UTRAN target cell
The UE does not support the target cell frequency band
The requested radio resources cannot be established, e.g. radio link setup
fails on Iub or the ALCAP Iu transport bearer cannot be established
The RNC does not receive a HANDOVER TO UTRAN COMPLETE message
from the UE, because the UE has received an invalid HANDOVER TO UTRAN
COMMAND message or it does not support the configuration included in the
message. In this case the timer expires
The MSC cancels the relocation by releasing the Iu connection
Page 70 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM KPIs related to the IRAT Handover process are detailed in [25].
6.11. Call reliability Cell change order from UTRAN

6.11.1.
Concept
The cell change order from UTRAN procedure may be initiated by the UTRAN
when the UE is in CELL_DCH or CELL_FACH mode.
The approach for PS inter-system/RAT handover is similar to the one described
for the CS inter-system handover in subsection 6.10. It might be that the twostep approach to first only measure BCCH/RXLEV of the neighbouring GSM
cells, and then the BSIC, may not be adopted. In the Measurement Control
message it is only specified that the UE has to report the BCCH/RXLEV.
Nevertheless when the UTRAN decides to direct the UE to the GPRS domain, a
BSIC and BCCH are specified. The UE is doing an inter-RAT cell reselection as
specified within IE "Target cell description" of the CCO from UTRAN message.
In the UE, timer T309 supervises this procedure.
6.11.2.

In case the UE cannot successfully complete the procedure and T309 expires,
the UE will
in CELL_DCH mode
o
Re-establish the UTRA physical channel(s) used at the time for

reception of cell change order from UTRAN and transmit the cell
change order from UTRAN failure message and set the IE "InterRAT change failure" to "physical channel failure"
OR when not successful, perform a cell update procedure with

cause "Radio link failure"
in CELL_FACH mode
o
Revert to the cell it was camped on at the reception of the

reception of cell change order from UTRAN and transmit the cell
change order from UTRAN failure message and set the IE "InterRAT change failure" to "physical channel failure" Select a UTRAN
suitable cell and initiate the cell update procedure using the cause
"cell re-selection"
Table 51 below is listing the parameter for the cell change order from UTRAN
procedure:
Parameter
Description
t309
Defining timer T309
Table 51: Parameter used for configuring the cell change order from
UTRAN
Table 52 below is listing the identification in interface traces possibilities for the
cell change order from UTRAN procedure:
Problem
Cell Change Order from UTRAN I
Trace
Uu
Trigger
Any occurrence of the RRC message
CellChangeOrderFromUTRANFailure
Page 71 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Cell Change Order from UTRAN II
Uu

CellChangeOrderFromUTRAN and within x seconds there is a
cell update message with cause "Radio link failure"
Cell Change Order from UTRAN III
Uu

CellChangeOrderFromUTRAN and within x seconds there is a
cell update message with cell update cause "cellReselection"
Table 52: Identification of cell change order from UTRAN failures in traces
PM KPIs related to the process is available in [25].
6.12. Call reliability inter frequency handover

6.12.1.
Concept
In UMTS networks inter-frequency hard handover is a feature that ensure
seamless mobility between frequency carriers in same or different spectrum
bands.
The hard handovers can either be triggered by the degrading quality of the
current frequency or by a high load condition. In addition it is assumed that the
reporting reports are set to event triggered rather than periodically. All interfrequency measurement-reporting events (2a to 2f) are defined in [6].
According to [24] this procedure consists of the following steps:
Detection of the need for inter-Frequency HO
HO algorithm selection and measurement report setup
Measurement event report reception and HO execution
If necessary execution of RNS relocation procedure (subsection 6.17.3)
The different steps are configurable using UTRAN O&M parameters. Two
algorithms are available namely DAHO and MAHO with the later requiring
compressed mode unless UE capability indicates otherwise. DAHO algorithm is
only used when handing over from a Micro to a Macro site. Otherwise MAHO is
recommended for most scenarios.
Irrespective of the reason for initiation, the call flow follows slightly different
sequence if the HO is inter/intra-NodeB and inter/intra-RNC. Furthermore
transport channel reconfiguration is only used if doing HS-DSCH-to-HS-DSCH
HO (as shown in Figure 25) else physical channel is reconfigured for DCH-toDCH HO. The whole procedure (from receipt of measurement report till HO
success or failure) is supervised by a timer interFreqHoProcedureTimer.
6.12.2.

The reasons for inter-frequency HO failures are similar to the ones that may be
encountered during intra-frequency or IRAT HO, as constituent procedures are
the same, however some salient failure mechanisms are
The Node B is unable to allocate the resources requested. Then it returns a

NBAP Radio Link Addition Failure or Radio Link Setup Failure message to
the SRNC (section 5.1.5) either directly or via DRNC. The call continues on
the current configuration (old frequency).
The UE may not able to perform the new configuration and returns a
Physical Channel -, Transport Channel - or Radio Bearer Reconfiguration
Page 72 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Failure. The newly allocated resources on the NodeB are released by

means of the NBAP Radio Link Deletion procedure by the RNC. In case of
HS-DSCH configuration the transport channel is re-configured to DCH.
Otherwise the call continues on the current configuration.
If the Inter-Frequency Handover Procedure Timer expires before the

Physical Channel or Transport Channel or Radio Bearer Reconfiguration
message has been sent to the UE then the SRNC undoes all actions
already performed and releases all radio resources newly allocated for this
handover using the NBAP Radio Link Deletion Procedure. The call
continues on the current configuration.
If the timer expires after any of the above Reconfiguration message has
been sent to the UE then the SRNC releases all radio resources newly
allocated using the NBAP Radio Link Deletion Procedure. The old radio
resources are no more available and the call will drop. The RNC initiates the
RANAP Iu Release Request procedure with cause 'Failure in the Radio
Interface Procedure' towards the CN.
Page 73 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 25: Inter-frequency Handover Message Flow (HS-DSCH to HSDSCH) - Intra-Node B, Intra-SRNC
Note that the phase UE detected refers to the achievement of RL
synchronisation with the new target cell. The user plane interruption is likely to
be longer for the UL as DL data is sent on both the old and new RL while UL is
only sent on old RL until either it fails or the new RL is restored.
Problem
Inter Frequency HO Delay
Dropped call during IF HHO
Trace
Trigger
Uu
Any occurrence where the UE sends a Measurement Report 2x

and the RNC does not reply with Physical or Transport Channel
Reconfiguration message within y seconds
Uu, Iu
RNC sends a Physical or Transport Channel Reconfiguration

message but the UE does not respond back with either
Page 74 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
complete or failure message within y seconds. This will be

followed by RNC initiaiting Iu release procedure.
Table 53: Identification of inter Freq HO failures from traces UTRAN

Some important KPIs/Counters pegged during this process are given below:
PM
system
Counter / KPI15
UtranCell
(HHO.SuccOutInterFreq.<trigger> /
HHO.AttOutInterFreq.<trigger>) * 100
Inter-frequency hard handover

success rate
UtranCell
HHO.FailOuterInterFreq.<trigger>.<failure cause>
Hard handover failure count
UtranCell
VS.HHO.AttPrepOutInterFreq.<trigger>
Hard handover preparation attempt

count
Table 54: PM KPIs identifying Inter-Freq HO problems
6.13. Call reliability failures on the Transport Network

The underlying transport network on the Iub and Iu interface is ATM. On the Iub
interface AAL2 and AAL5 are used, with help of the ALCAP protocol resources
are allocated. On the Iu interface the underlying ATM protocol is AAL5.
ATM failures and performance statistics of the Transport Network are not
reported at the FM/PM system of the UTRAN, but on the ATM system. Please
check the corresponding documentation.
Main problems that might occur on the Transport Network are as follows:
Link synchronisation problems e.g. when using microwave links
Configuration issues
6.14. Call reliability failures on RLC

6.14.1.
Concept
The specification of the RLC protocol is provided in [36]. A detailed description
of the ex-Lucent implementation is available in [21].
The RLC is a layer 2 sublayer. RLC provides three basic tasks:
1. Buffering
Buffering is required in RLC to compensate for the data rate variations of higher
and lower layers: TCP/IP based applications typically generate IP packets at
variable data rate, while the air interface provides varying throughput due to
varying channel conditions.
2. Segmentation and reassembly
Variable-sized IP packets provided by the PDCP as RLC SDUs are segmented
into fixed sized RLC PDUs. Concatenation and padding are used for efficient
packing. Each RLC PDU is transferred as one fixed-sized PHY TB.
3. Error control
15
<trigger> refers to quality or load based HO initiation and <failure cause> can be physical channel
reconfig failure or protocol error or configuration not supported.
Page 75 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
AM RLC provides the link-layer ARQ scheme that is required to hide PHY block
errors from higher layers.
The RLC provides three different types of data transfer modes:
TM data transfer
o
No protocol overhead added; transparent to the RLC
Used for signalling SRB (e.g. broadcast SRB on BCCH, paging

SRBs on PCH), voice services and CS data
UM data transfer
o
Buffer control of RLC SDUs for smoothing data rate variations

introduced by burst-traffic sources (e.g. TCP flow control) and
lower layer variations
Segmentation, concatenation and padding into RLC PDUs. Each

PDU is transferred as one physical layer TB.
Reassembly of PHY data from TB into RLC PDUs and RLC SDUs
Used for fast signalling (e.g. SRB1 on DCCH)
AM data transfer
o
o
UM data transfer features plus
Error control feedback, retransmission of erroneous or lost PDUs

and in sequence delivery of RLC PDUs by ARQ
Used for signalling (SRB 2-4) and PS data services
There is one pair of AM RLC entities per RB. In the following TM is not
considered any further because there is no performance impact due to RLC.
Figure 26 below is showing the UMTS protocol stack of the user plane for a
TCP/IP data application:
Figure 26: UMTS protocol stack of the userplane for a TCP/IP application
Page 76 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
TCP has its own flow control and ARQ algorithms so the O&M parameter of
RLC has to be adapted to interwork with TCP in an optimal way. Because the
TCP settings could be different on each client PC (and the corresponding server
in the Internet or corporate business network) a reference client-server system
should be defined and used to optimise the RLC settings.
16
A RLC PDU for PS RB has a size of 42 bytes (40 byte payload and 2 byte
header), which is relatively small compared to a TCP/IP packet size of around
17
1000 byte . As a consequence retransmission on RLC results in a
retransmission of relatively small amount of data compared to that on TCP/IP
layer. Furthermore if a data PDU is not completely filled with data of one SDU,
concatenation and/or padding are applied.
For each TB set the PHY is performing a CRC check; in the UL the NodeB is
adding the CRCI to each TB set (see also subsection 7.1.2.1). Furthermore the
physical frames on Iub are protected by additional CRCs. If one of both CRC
fails lower layer discards the whole frame on Iub / the whole TB set. It is up to
the RLC of how to react on lost data and possibly initiate retransmission.
RLC ARQ mechanism

For identification each PDU has (for DL and UL and per RLC entity separately)
an increasing SN (0, , 4095 for AM, 0,,127 for UM). At the TX the data
PDUs are stored in a retransmission buffer when they are submitted to the MAC
and PHY layer. If a data PDU is NACK it can be quickly retransmitted. ARQ is
using the following mechanism:
Status reporting on the RX: the RX sends a status report in so-called

STATUS PDUs containing a detailed list of received and missing PDUs.
STATUS PDUs have priority over retransmitted data. They can be sent
periodically or unsolicited e.g. after loss detection
Polling from TX: the TX can request a status report
Window mechanism: a sliding window allows the TX to transmit new

PDUs while waiting for the ACKs till end of the window size.
SDU discard function: when the delivery of a SDU cannot be managed

because of e.g. repeated errors, the transmission of SDUs is stopped
and discarded on both TX and RX side.
Protocol error recovery
Data PDUs carrying poll requests and status or other control PDUs
require a special ACK and are protected by timers
When timer protected PDUs are not acknowledged before the timer
elapses these PDUs are retransmitted
If timer protected PDUs are retransmitted and still no ACK received

then
o If data PDU retransmission did not succeed, go either to SDU
discard or RLC reset of the RLC connection between the two entities
16
The size of signaling SRBs is 16 bytes plus 2 bytes header

The size of the TCP/IP packet is depending on the MSS negotiated for each TCP session during the
connection setup. In addition it might be that the IP packet is further segmented by one Internet server
routing the packets
17
Page 77 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
o If SDU discard does not succeed, go to RLC reset of the RLC

connection between the two entities
o If RLC reset does not succeed, signal unrecoverable error to higher
layers. In this case the RRC might be dropped and the UE performs
a Cell Update and the IE AM_RLC error indication is set to TRUE
(subsection 6.3.1)
Parameters configuring the RLC are available in [27].
Reason for problems on the RLC might be due to
6.14.2.
RF related issues like pilot pollution, incorrect neighbouring definitions

etc.
Lower layer problems on the Iub
Decrease of the data rate because of .e.g. CongC resulting in SDU

discards

The retransmission on RLC layer can be easily identified by a not-in-sequence
delivery of RLC PDUs on Iub; this information is normally not available in Uu
traces. The RX acknowledges in its status reports all PDUs with a SN < LSN.
For better identification on Iub the particular call has to be extracted so as not to
mix up with RLC PDUs of other calls. In addition special ASCII files downloaded
via FTP can be used to easily identify retransmission (only possible when PPP
and PDCP compression techniques as well as ciphering is disabled, see also
subsection 7.2.3).
Another (but quite complicated) possibility is the analysis of the BITMAP in the
status reports of the RX. The BITMAP is giving the TX an indication about which
PDUs have been successfully received and which not starting from the FSN
(number of octets determined by LENGTH) [36].
A dropped call due to a RLC error can be easily identified by a Cell Update
message with cell update cause RLC unrecoverable error. See Table 55.
The SDU discard function allows discharging RLC PDU from the buffer on the
transmitter side, when the transmission of the RLC PDU does not succeed for a
long time. The SDU discard function allows avoiding buffer overflow. There will
be several alternative operation modes of the RLC SDU discard function, and
which discard function to use will be given by the QoS requirements of the
Radio Access Bearer.
Table 55 is listing problems that can be detected in interface traces and Table
56 the corresponding KPIs in the PM system:
Problem
Trace
RLC Resets
Iub
Any occurrence of RLC Resets in Iub traces
Trigger
RLC retransmission
Iub
Any occurrence of retransmission of RLC PDUs per RLC session
SDU discard with

explicit signalling
Iub
Any occurrence of a Move Receiving Window (MRW) command indicating a

SDU discard and/or a MRW-ACK
Dropped call due to

RLC error
Uu
Any occurrence of a RRC Cell Update message with specified cell update
cause (not failure cause) RLC unrecoverable error. There might be optional a
failure cause specified. The IE AM_RLC error might be set to TRUE.
Table 55: Identification of RLC problems in traces
Page 78 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM
system
Counter / KPI
UtranCell
VS.MM.CellUpdateReq.RLCError
The measurement provides the number of

requested cell updates with cause Radio Link
Control (RLC) Unrecoverable Error received
by the RNC from the UE.
Table 56: PM KPIs on RLC layer
6.15. Call reliability HSDPA

6.15.1.
Introduction
From UMTS Release 5 onwards HSDPA is supported in order to provide UMTS
subscribers higher throughput rates in the downlink as well as better resource
allocation in the UTRAN.
Compared to Release 99 the following changes have been done for HSDPA:
On UTRAN, new modulation schemes, fast scheduling and resource

sharing techniques,
New UMTS physical channels
New handsets with high speed capability
Core Network accommodation for more traffic
Figure 27 below is visualising the changes in the UMTS protocol stack in order
to support HSDPA:
UE
Node B
Uu
SM
SM
PMM
MM
PDCP RRC
PHYRRC
RLC
codec RLC
MAC
MAC
Phy-up
Phy-up
RNC
Iub
RRC PDCP GTP-U

RRC
RLC
RLC
IP
Q2150.1
UDP
RANAP
FP
RANAP
GTP-U GTP-C
Q2150.1
ALCAP
ALCAP
PHY PHY
HSDPA DCH
HSDSCH
FP
PHY
AAL2
SSCF-UNI
SSCOP
AAL5
Iu UP
AAL5
AAL5 AAL5
IP
SCCP
SCCP
MTP3-b
HSFP
SSCF-UNI
SSCF SSCF DSCH
FP
SSCOP
SSCOP SSCOP
ATM
DCH
FP
AAL2
AAL2 AAL2
SSCF-N
SSCF
SSCOP
AAL5
AAL5 AAL5
ATM
ATM
E1/ STM-1
User Plane
Phy-up
Phy-up
NBAP STC.2
NBAP ALCAP
STM-1
E1
Transport Plane
IP
SCCP
SCCP Q2150.1
MTP3-b
MTP3B MTP3B
SSCF-N
SSCF SSCF
SSCOP SSCOP
SSCOP
AAL5
L2
AAL5 AAL5
AAL2
L1
ATM
ATM
STM-1
E1
Common
Figure 27: HSDPA protocol stack enhancements

The following subsections are describing different aspects of HSDPA data calls.
GTP-C GTP-U
UDP
Q2150.1
UDP
MAC
MAC
DCH
FP
Control Plane
GGSN
PMM
SM
MAC-hs STC.2 NBAP
PHY
HSDPA
Gn
SM
MM
IP
PHY
DCH
SGSN
Iups
Page 79 of 106
IP
Q2150.
1
MTP3B
SSCF
SSCOP
L2
AAL5
L1
Document name:
Date:
2007-06-08
Rev: 2.1
6.15.2.
Mobility aspects of HSDPA
6.15.2.1.
Concept
The mobility aspect of a HSDPA user is as follows:
For the UL the mobility procedures are largely mostly the same as for
PS calls over DCH (e.g. soft/softer HO triggered via event 1a, 1b and
1c)
For the DL the HS-DSCH for a given UE belongs to only one of the
radio links of one sector of the NodeB where the UL is connected. As a
consequence only Hard Handovers (Cell Changes) are triggered
The RNC is forwarding the DL application data to the NodeB from the MAC
layer to the new MAC-hs layer that is scheduling the data for delivery. In case of
a Hard Handover the NodeB discards data that has been not been transmitted
yet. In this case it is up to the higher layer protocols (RLC or TCP) to retransmit
lost data. As a consequence too many serving HS-DSCH Cell Changes within a
short period of time (Ping-Pong handovers) may cause a reduced throughput
due to loss of data.
The number of HS-DSCH Hard Handovers is tracked by the UTRAN. If this
number exceeds an unusual amount of serving cell changes, the call is
changed from HS-DSCH to DCH. The algorithms are proprietary and depend on
the infrastructure vendor.
A typically scenario might look as follows:
UE connected to NodeB A, NodeB B is becoming stronger and stronger
UE sends Measurement Report with event id 1a
RNC adds NodeB B to the Active Set via Active Set Update procedure
UE sending Measurement Report with event id 1d
RNC triggers Hard Handover via Transport Channel Reconfiguration or

Radio Bearer Reconfiguration procedure
UE sends Measurement Report with event id 1b to remove NodeB A

from the active set
The optimisation approach when triggering event id 1d is as follows:
HSDPA cell change should not be performed too late, when the UE has
already moved 'far' into the area of another cell where it could have
better throughput.
HSDPA Hard Handovers should not be executed too early, so that it

immediately changes back to the previous cell if the radio conditions
vary (Ping-Pong effect).
In ex-Lucent UTRAN for each UE a timer hSDPAMobilityTimer is defined

tracking the number of cell changes in a certain time frame. Depending on the
status of this timer the UE
Might setup the call either on DCH or HS-DSCH, if call is in

CELL_FACH state
Might be asked to change state from HS-DSCH to DCH or vice versa
For parameters configuring HSDPA see [16] section 9.2.
Page 80 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6.15.2.2.
HSDPA performance degradations due to mobility issues can be best observed

by analysing drive test data. It is very important to avoid unnecessary Hard
Handovers, in particular Ping-Ponging effects. On the other hand the Hard
Handover should not be triggered too late so that the UE is not served by a
NodeB that is much worse compared to the best cell; in this case the throughput
will decrease or even the call may drop.
Furthermore non-optimal handover settings might cause unnecessary
transitions from HS-DSCH to DCH; as a result the benefits from HSDPA will not
be available to that particular UE.
Finally during the Hard Handover there might be major transmission gaps
including TCP retransmission. The reason might be synchronisation problems
or not optimal timing during the handover procedure e.g. the timing when the
RNC stops forwarding data towards the old NodeB. This problem can be easily
detected when correlating RRC with TCP/IP data. Figure 28 below shows an
example cross-correlated by Actix [29]; in the upper left part of the picture the
RRC protocol is shown, the lower left picture shows the TCP SQN recorded at
the client site by Ethereal:
Figure 28: Hard handover problems identified by cross-correlated

RRC and TCP data
Table 57 below is listing the identification techniques for HSDPA mobility
problems:
Problem
HSDPA ping-pong
Trace
Uu
Trigger
There are two consecutive Transport Channel Reconfiguration / Radio Bearer
Reconfiguration procedures within x seconds
Page 81 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Transmission gap
during
HO
in
HSDPA call
Uu, TCP
Cross-correlation Uu and TCP trace: during a Transport Channel

Reconfiguration / Radio Bearer Reconfiguration procedure there is a
transmission gap on TCP layer in the DL for x seconds
Table 57: HSDPA related problems indicated by network interface traces
6.15.3.
RF related issues
RF related issues on the air interface are one of the main reasons for
performance throughput degradations of HSDPA calls. The optimisation has to
be done on a per-cell basis using UE drive test data. In the following
subsections the most important measures are summarised.
Due to the fact that in the downlink there is no gain from soft/softer HO a UE in
HSDPA mode is more sensitive regarding pilot pollution, see also subsection
6.4.2 for details.
6.15.3.1.
RF related issues - CQI
The most important measure of the DL quality of the HSDPA shared channel is
the channel quality indicator (CQI) the UE is reporting back to the Node B on
the HS-DPCCH. The CQI ranges from 0 to 30, with greater values indicating
better quality. It is based on the instantaneous measurements of the RF
conditions. The NodeB is deciding upon the reported CQI values which
Transport Format Resource Combination (TFRC) can be transmitted given a
certain transmit power and an expected CRC error rate that is directly impacting
the expected throughput.
3GPP [11] defines the meaning of the reported CQI values for each UE
category. In [15] requirements for the accuracy of the channel quality
measurements are given. The UE shall assume for the purpose of CQI
reporting a total received HS-PDSCH power
PHSDPSCH = PCPICH + + in dB
where the total received power is evenly distributed among the HS-PDSCH
codes of the reported CQI value. The measurement power offset is signaled
by the RNC and the reference power adjustment is given for each UE
category in [11]. PCPICH is the transmit power of the Primary or Secondary
CPICH. It should be noted that the 3GPP specification does not demand that
the power PCPICH + is equal to the total available HSDPA power.
Figure 29 below show as a graphical distribution of the throughput versus CQI;
the test has been done stationary, the cell was unloaded, application was FTP
download via TCP/IP:
Page 82 of 106
Document name:
2007-06-08
Rev: 2.1
1800
App Fwd Throughput [kbps]
1600
1400
1200
1000
800
600
400
200
0
0
10
15
20
25
CQI
Figure 29: HSDPA - throughput versus CQI for TCP download

Note: when the CQI is exceeding 15 there is no obvious throughput
improvement observed anymore because the UE capability of 12 is in this case
the limiting factor (see also subsection 6.15.4 for details).
6.15.3.2.
RF related issues Ec/No
For the same test case as described in previous subsection the HSDPA
throughput versus Ec/No were analysed. Again a strong correlation between
both measures has been recorded as visualised in Figure 30:
1800
1600
1400
App Fwd Throughput [kbps]
Date:
1200
1000
800
600
400
200
0
-20
-18
-16
-14
-12
-10
-8
-6
-4
Ec/No [dB]
Figure 30: HSDPA - throughput versus Ec/No for TCP download

To be noted: the Ec/No is never exceeding (excluding single measurement
samples) around 6 dB because the No term includes the HSDPA traffic of the
user. Furthermore for Ec/No values exceeding around 8 dB no throughput
performance could be observed indicating again that the limiting factor is the UE
capability (see also subsection 6.15.4).
Page 83 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6.15.3.3.
RF related issues other optimisation problems
For any other optimisation problems as neighbour list planning, access

parameters or power control settings please take a look in the corresponding
subsections of this guideline.
6.15.4.
UE limitations
HSDPA capable terminals with resulting peak data rates ranging from 1.2 Mbit/s
to 14 Mbit/s at physical layer, see also [14] and [16]. Depending on the terminal
type different maximum number of HS-DSCH codes, different maximum TBS or
modulation schemes are supported. As a consequence the maximum
achievable throughput is terminal dependent and should be taken into
consideration when analysing HSDPA UE traces.
As described in subsection 6.15.3 currently the UE is the limiting factor in case
of optimal RF conditions.
6.15.5.
Capacity issues
Because the HS-DSCH is a shared channel the throughput of one UE highly
depends on the overall HSDPA traffic in the particular NodeB. Two cases can
be differentiated:
6.15.5.1.
Capacity issues sharing of the bandwidth
When sharing the HSDPA bandwidth with other users the application
throughput will not be optimal due to the fact that
The bandwidth provided by the HS-DSCH is limited
The bandwidth on the backhaul transport network is limited
These kinds of capacity issues can be detected as follows:
Indirectly by execution of UE performance tests during the busy hour

and a comparison to the non-busy hour (e.g. on Sunday or at the early
morning); a good test method might be static automatic tests for a full
day.
By evaluation of PM counter statistic
Evaluation of Iub traces
6.15.5.2.
Capacity issues HSDPA call cannot be established on a particular
NodeB
Failed establishment of HSDPA call on a NodeB can be due to
Hard limits
During call set up, HS-DSCH serving cell change and transition from
URA_PCH/CELL_FACH to CELL_DCH with HSDPA the number of active
HSDPA users is checked on a cell level against the parameter
maxHsdpaUsersPerCell. HSDPA hardware and processing resources are
limited in the NodeB, for more details see [16]. For ex-Lucent U04.0x the UCU-II
hardware limitation (and default parameter setting) is 24.
For this event there is no corresponding PM counter available in ex-Lucent
UTRAN.
Soft limits
Each time when a UE tries to establish a HSDPA call on a new NodeB via a
RadioBearerReconfiguration procedure DBC is checking the soft limitations. For
Page 84 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
ex-Lucent UTRAN the corresponding parameter and algorithm configuring DBC

are explained in [18].
HSDPA related PM counters are available in [16] section 11.
6.16. Call reliability HSUPA/EDCH

6.16.1.
Introduction
From UMTS Release 6 onwards HSUPA is supported in order to provide UMTS
subscribers higher throughput rates in the uplink as well as better resource
sharing in the UTRAN. But in this release HSUPA is only supported in UL, if
HSDPA is configured in the DL. Furthermore new UL MAC functionality has
been split into RNC entity (MAC-es) and NodeB entity (MAC-e) respectively.
Figure 27 below is visualising the changes in the UMTS protocol stack in order
to support HSUPA:
Figure 31: HSUPA changes done to the Protocol Stack

The following subsections are describing different aspects of HSUPA data call.
6.16.2.
Mobility aspects of HSUPA
6.16.2.1.
Concept
The mobility aspect of a HSUPA user is as follows:
In general the mobility procedures are the same as for PS calls over
DCH (e.g. soft/softer HO triggered via event 1a, 1b and 1c).
However one of the radio links acts as the serving cell which is
selected to be the same as for HSDPA in the DL
In HSUPA serving cell is responsible for issuing absolute serving grants (AG)
for the UE to send data. And as such this cell change only involves changing
the physical channels E-AGCH/E-RGCH to accommodate the new role of the
cell. The support of soft/softer HO means that the possibility of performance
degradation is much less as compared to HSDPA.
However 04.03 does not support HSUPA over Iur boundary. Consequently if all
the radio legs are from drift RNC, the HSDPA/E-DCH call will be reconfigured to
HSDPA/DCH state with a minimum data rate. A timer is used to supervise the
Page 85 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
reconfiguration back to HSDPA/E-DCH state (only possible in SRNS relocation

or when all radio legs handover back to SRNC) and an optimum value should
avoid ping ponging between DCH and E-DCH states in case call stays around
Iur boundary. However reconfiguration to DCH can also occur if there are cells
involved which dont support E-DCH or cells are fully loaded with maximum
allowed number of E-DCH users or if UTRAN wants to activate compressed
mode on the UE.
6.16.2.2.
Depending upon the initial E-DCH throughput, the new DCH bearer throughput
will be lower at application level. If some of the radio legs go back to SRNC then
there is possibility that bearer will never configure back up to E-DCH. However
such situation will only occur if the user only moves along the Iur boundary.
Problem
Trace
Trigger
HSUPA ping-pong
along Iur
Uu
There are consecutive Transport Channel Reconfiguration / Radio Bearer

Reconfiguration procedures within x seconds doing E-DCH DCH state
changes frequently
Reduction
in
throughput during
HO along Iur
Uu
There is no subsequent Transport Channel Reconfiguration / Radio Bearer

Reconfiguration procedure observed after the initial procedure that configured
UL to DCH
Table 58: HSUPA HO related issues involving Iur

Some relavent KPIs/Counters are given that deal with the handover aspect of
HSUPA
PM
system
Counter/KPI
UtranCell
(VS.SuccServCellChangeEDCH /
VS.AttServCellChangeEDCH)*100
EDCH Serving Cell change Success

rate
UtranCell
VS.ReconfSucc.EDCH-HSDSCH_ULDCH-HSDSCH
Total number of successful

reconfiguration E-DCH to DCH in UL
with HSDPA in DL
UtranCell
VS.ReconfSucc.ULDCH-HSDSCH_EDCH-HSDSCH
Total number of successful

reconfiguration DCH to E-DCH in UL
with HSDPA in DL
Table 59: PM Counter/KPI for E-DCH Mobility

6.16.3.
MAC/ RF related Issues

The scheduling mechanism for EDCH involves UEs sending scheduling
requests that are assigned resources by the MAC-e entity upon evaluation of a
set of criteria. This scheduling grant takes the form of absolute (giving max
uplink power that can be transmitted) or relative (stipulating change/no-change
in power with respect to previous TTI).
However in case of overload (on Uu or Iub) the scheduler will not honour the
request and would most likely start downgrading the served and non-served
UEs through absolute and relative grants respectively. Hence it is important to
ensure that UL target load and Iub links are setup correctly to give desired cell
throughput.
The scheduler is also responsible for the hybrid ARQ to ensure error-free
delivery avoiding re-transmissions at higher layers, reducing delay. Furthermore
the UL EDPCCH contains a happy bit that shows if the UE is satisfied with the
Page 86 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
current grant. This can act as an indicator of how fairly each UE is being
scheduled.
Under bad RF conditions the UE is likely to be transmitting at high power to
reach the NodeB and hence will not have sufficient power available to send the
data resulting in loss of throughput.
6.16.4.
UE Limitations
HSUPA capable terminals have peak data rates ranging from 0.7 Mbit/s to 5.7
Mbit/s at physical layer, see also [14] and [17]. Depending on the terminal type,
various options for maximum number of UL codes, minimum SF and TTI
durations are supported. As a consequence the maximum achievable
throughput is terminal dependent and should be taken into consideration when
analysing HSUPA UE traces.
6.16.5.
Capacity issues
Because the E-DPDCH is a shared channel the throughput of one UE highly
depends on the overall HSUPA traffic in the particular NodeB. Two cases can
be differentiated:
6.16.5.1.
Capacity issues sharing of the bandwidth
When sharing the HSUPA bandwidth with other users the application
throughput will not be optimal due to the fact that
The bandwidth provided by the E-DPDCH is limited, see Figure 32
The bandwidth on the backhaul transport network is limited
These kinds of capacity issues can be detected as follows:
Indirectly by execution of UE performance tests during the busy hour

and a comparison to the non-busy hour
By evaluation of PM counter statistics
Evaluation of Iub traces
Figure 32: User versus Cell throughput variation with increase in users
Page 87 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
6.16.5.2.
Capacity issues HSUPA call cannot be established on a particular
NodeB
During call set up, E-DCH serving cell change and transition from
URA_PCH/CELL_FACH/CELL_DCH to CELL_DCH with E-DCH the number of
active HSUPA users is checked on a cell level against the parameter
maxEdchUsersPerCell. For ex-Lucent U04.0x, default setting for this parameter
is 30. Currently PM system only records this failure if it happens during DCH to
E-DCH reconfiguration.
HSUPA hardware and processing resources are limited in the NodeB, for more
details see [17] section 5. NodeB equipped with UCU-II does not support EDCH. And as a result the E-DCH call can be reconfigured to DCH if the
corresponding HS-DSCH serving cell changes to the NodeB with UCU-II.
Full set of HSUPA related PM counters are available in [17] section 11.
6.17. Call reliability miscellaneous failures

6.17.1.
RB Reconfiguration / Transport Channel Reconfiguration failure
6.17.1.1.
Concept
The RB Reconfiguration or alternatively the Transport Channel Reconfiguration

procedure might be initiated for several reasons:
In case of UE state transitions e.g. when going from CELL_DCH mode

to CELL_FACH mode in case the inactivity timer expires (subsection
6.7) or because of CongC (subsection 6.5)
Hard handover for HSDPA calls (subsection 6.15.2)
In case RNC requests the UE to change the RB due to e.g. PS traffic

measurements triggered either by UE sending a Measurement Report
4a/4b or by the UTRAN monitoring the DL RLC buffer occupancy
(subsection 7.2.3)
Due to a high BLER in the DL indicated by Measurement Report 5a

sent by the UE (subsection 7.1.1)
To direct to direct the UE into compressed mode
In case of a change of the data rate first a Radio Link Reconfiguration on NBAP
is executed following changes of the ATM resources on the Iub via ALCAP
procedures.
The RNC is sending a RB Reconfiguration message/Transport Channel
Reconfiguration on RRC and in case of a failure the UE is sending back the
corresponding failure message.
6.17.1.2.
Main reason for a failure in this procedure is that the UE is not supporting the
requested new configuration.
Table 60 and Table 61 are listing the identification of RB Reconfiguration
Failures in traces and in the PM system:
Page 88 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Problem
Trace
Trigger
RB Reconfiguration failure
Uu
Any occurrence of the RRC message RB Reconfiguration

Failure
Transport
Channel
Reconfiguration failures
Uu
Any occurrence of the RRC message Transport Channel

Reconfiguration Failure
Table 60: Identification of RB Reconfiguration Failures in traces
PM
system
Counter / KPI
UtranCell
and RNC
(VS.RRC.RBReconfigSucc/VS.RRC.RBReconfigAtt)*100
RadioBearerReconfiguration
Success rate
UtranCell
and RNC
(VS.RRC.TransChanReconfigSucc/
VS.RRC.TransChanReconfigAtt)*100
TransportChannelReconfiguration
Success rate
Table 61: PM KPIs identifying RB / Transportchannel

Reconfiguration Failures
6.17.2.
Physical Channel Reconfiguration failures
6.17.2.1.
Concept
The Physical Channel Reconfiguration procedure can be initiated by the

UTRAN e.g. during inter-Frequency hard handover for DCH. Upon receiving the
Physical Channel Reconfiguration message the UE has to change its physical
configuration as requested and is sending back a Physical Channel
Reconfiguration Complete message (successful case) or Physical Channel
Reconfiguration Failure (unsuccessful case).
6.17.2.2.
Table 62 is listing the identification of Physical Channel Reconfiguration

Failures in traces:
Problem
Trace
Physical Channel
Reconfiguration Failure
Uu
Trigger
Any occurrence of a Physical Channel Reconfiguration
Failure message
Table 62: Identification of Physical Channel Reconfiguration Failures

PM counters pegging failures in the Physical Channel Reconfiguration
procedures are listed in the corresponding subsections e.g. in the subsection
6.12.2.
6.17.3.
Relocation failures
6.17.3.1.
Concept
The relocation procedure is used in case of
IRAT-HO (subsection 6.10)
Inter-RNC HO
In case of a Cell Update on a new RNC
The procedure is described in [9]. The SRNC sends a Relocation Required

message on RANAP. The CN sends back the Relocation Command message
(successful case) or Relocation Preparation Failure (unsuccessful case).
Page 89 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table 63 below is listing parameters used for the relocation procedure:
Parameter
Description
IRATHORelocGuardTimer
This parameter configuring the IRAT-HO relocation guard timer.
RelocationGuardTimer
This parameter configuring the relocation guard timer.
Table 63: Parameter used for the relocation
6.17.3.2.
Failures of the relocation process occur most likely during the IRAT-HO
process. A failure is detected during the RANAP Relocation Preparation
procedure (e.g. GSM handover resource allocation fails or the CN rejects the
UMTS to GSM handover request) due to the following causes:
Timer TRELOCprep expiry at the SRNC
Relocation Preparation Failure
In the first case the SRNC initiates the Relocation Cancel procedure at the Iu
interface. This procedure enables the CN to initiate the release of the resources
allocated during the Relocation Preparation procedure in the GSM network. The
SRNC considers the UMTS to GSM handover as not possible at this point in
time and keeps the existing radio connections established. This means that the
existing Iu-signalling connection can still be used for the call as the timer
IRATHORelocGuardTimer is still running when RelocationGuardTimer expires.
In the second case upon receiving a Relocation Preparation Failure message
from the 3G MSC, the SRNC still maintains the call. If the failure cause
specified within the message is Relocation Failure in Target CN/RNC or Target
System or Relocation not supported in Target RNC or Target System then
SRNC repeats the Relocation Preparation procedure with the next suitable cell
from the list of potential GSM target cells otherwise the SRNC considers the
UMTS to GSM handover as not possible at this point in time.
Table 64 is listing methods of how to identify relocation problems in interface
traces:
Problem
Trace
Trigger
Relocation Preparation
Failure
Iu
Any occurrence of the RANAP message Relocation Preparation Failure
Relocation Cancel
Iu
Any occurrence of the RANAP message Relocation Cancel
Table 64: Identification of relocation failures in interface traces

Table 65 below is listing the PM KPIs describing relocation failures:
Page 90 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
PM
system
Counter / KPI
UtranCell
VS.RAB.Drop.CS.RelocUEInvol/CS RAB Success*100
CS RAB Drop Rate due to SRNS

Relocation
UtranCell
VS.RAB.Drop.PS.RelocUEInvol/
PS RAB Drop Rate due to SRNS

Relocation
UtranCell
(IRATHO.AttRelocPrepOutCS IRATHO.FailRelocPrepOutCS.sum)/
IRATHO.AttRelocPrepOutCS*100
UtranCell
IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp/
IRATHO.AttRelocPrepOutCS*100
Relocation preparation UMTS to

GSM fail rate T Relocprep expiry
VS.RAB.Drop.PS.RelocUEInvol /
PS RAB Drop Rate due to SRNS

Relocation RNC
RNC
Relocation preparation for CS UMTS

to GSM HHO success rate
Table 65: PM KPIs identifying relocation failures

6.17.4.
Failures during the RAB and RL release procedure

The release of the RAB and the RL is not only used when terminating the voice
or data call, but also when doing an IRAT HO from 3G to 2G.
In general failures are not expected to occur on this stage. The call handling is
shown in Figure 11; the normal release procedure is identical with this call
handling, the only exception is that it is not initiated by an Iu Release Request.
In the 3GPP there are no failure messages defined for the NBAP Radio Link
Deletion Request or the RANAP Iu Release Request.
Page 91 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
7. Call quality
In this section those aspects are investigated that have a direct influence of the
user perceived call quality. In the first part the BLER in the DL and UL is
discussed. The second part gives a definition of the Quality of Service (QoS)
parameters for the different types of services like voice, data and VT and a
description of performance weaknesses and of how to overcome these issues.
7.1.
Call quality - Block Error Rate (BLER)

For the different types of services like voice, data and VT a specific BLER has
to be maintained to guarantee a good call quality.
In case of voice or VT call the quality degradation can be directly experienced
during the conversation. In case of data call the poor quality may cause
throughput degradation or high ping delay times. In addition VT calls will result
in a fragmented and interrupted video signal.
The DL and UL Block Error Rate (BLER) are the KPIs providing an indication of
the quality of the UMTS call from the user perspective.
The DL BLER is the percentage of corrupted blocks over the total number of
blocks received by the UE; this KPI can be only retrieved via UE logging:
DL BLER = 100 * (NumRecBlocksErrDL / NumRecBlocksTotDL)
The UL BLER is the percentage of corrupted blocks received by the Serving
RNC (before frame selection) over the total number of blocks received (before
frame selection). The UL BLER is provided via the following formula on a per
RNC basis; statistics can be retrieved via the PM system (subsection 7.1.2):
UL BLER = 100 * (NumTransBlockErrUL / NumTransBlockTotUL)
High values of one or both of these KPIs indicate that the perceived quality of
the call is poor.
The DL and UL PC algorithms are there to control the BLER to a maximum.
BLER degradation occurs in case of pilot pollution, non-optimal neighbouring
definitions etc. as explained in subsection 6.4. High BLER can be observed in
the UL or in the DL separately. The reasons observing high BLER might be as
follows:
Non-optimal PC settings
The maximum NodeB or UE transmit power for the dedicated channels

has been reached
Power restrictions to avoid system overload
In the following subsections the DL and UL BLER analysis is reflected in more

detail.
7.1.1.DL Block Error Rate (BLER) analysis
7.1.1.1.
Concept
The DL closed loop power control is in charge to keep the DL BLER in a predefined range. The DL closed loop power control can be split into two loops: DL
outer and inner loop PC. Figure 33 below is showing the principle of the DL PC:
Page 92 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 33: Downlink outer loop power control principle

DL outer loop PC:
The RNC sends a target value for the BLER to the UE on the DCCH. This value
should guarantee an optimal performance for the (voice or data) service based
on the requested QoS parameters. During the call the BLER target can be readjusted by the RNC. The decision is based on the BLER and SIR
measurements UE sends back in the UL via the DCCH.
The DL outer loop PC in the UE defines a SIR target based on the BLER. The
control loop runs autonomously in the UE with a maximum speed of 100Hz. The
method on how to set SIR target in order to provide the requested BLER is not
specified in the 3GPP standard. However minimal UE performances in given RF
conditions are specified in [13]. When the UE is in compressed mode higher
SIR target values will be defined, as there is no power control during
transmission gap.
DL inner loop PC:
The inner loop PC purpose is fast adaptation of the NodeB transmit power in
order to achieve the targeted SIR ratio for the considered downlink radio
channel. Because of the speed of the control loop (up to 1500 Hz), the only
elements involved in the inner loop power control are the UE and the NodeB.
The TPCs the UE is sending to the NodeB is based on the comparison of the
SIR estimation versus the SIR target. The NodeB transmit power is limited to
parameters given by the RNC on NBAP.
7.1.1.2.
The DL BLER is reported by any drive test system in Uu traces. Furthermore

the UE may send a Measurement Report 5a in case the number of bad CRCs
on a certain transport channel is exceeding a certain threshold specified by a
previous Measurement Control message [6]. The UTRAN may or may not react
on this Measurement Report.
Table 67 is listing the triggers in interface traces:
Page 93 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Problem
Trace
High DL BLER in
Uu
Uu
NodeB Tx Pwr via

RFCT
RFCT
Measurement
Report 5a
Uu
Trigger
DL BLER higher than x % for more than y seconds
The NodeB transmit power is exceeding for service x more than y seconds z
dBm.
Any occurrence of a Measurement Report 5a sent by the UE
Table 66: Identification of high DL BLER in interface traces

7.1.2. UL Block Error Rate (BLER) analysis
7.1.2.1.
Concept
The UL closed loop power control is in charge to keep the UL BLER in a predefined range. The UL closed loop power control can be split into two loops: UL
outer and inner loop PC:
UL outer loop PC:
The UL outer loop PC is located at the RNC and is responsible for updating the
UL SIR target so that the UL BLER ensures the QoS of the requested (voice or
data) service. The RNC provides the NodeB the updated SIR target via the
DCH FP on the Iub. The control loop runs in the RNC with a speed of 100 Hz.
For updating the SIR target the RNC takes into account not only the measured
BLER, but also the reported RSSI measured by the NodeB and other
parameters.Figure 34 below is visualising the principle:
Figure 34: UL outer loop power control

If the UE is in soft/softer HO mode and a particular NodeB has more than one
leg, the NodeB does frame selection in the NodeB(called micro-diversity). For
frames coming from different NodeBs belonging to the same RNC the RNC is
doing the frame selection (termed macro-diversity). In case the NodeBs
Page 94 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
belong to different RNCs the SRNC is doing the frame selection; the data is
provided via the Iur interface.
For each UL TB set the NodeB is performing a CRC check on PHY and adding
a CRCI to the frame. In addition the quality of the link is estimated; the QE in
each TB provides the results. The QE is vendor proprietary, different metrics
might be used to derive it. The QE ranges from 0 to 255 (small QEs are
indicating good quality).
UL inner loop PC:
The UL inner loop PC is adjusting the transmit power of the UE in order to
achieve the provided SIR target. All NodeBs involved in the particular call are
sending TPC commands with a rate of up to 1500 Hz. The TPC commands of
the particular NodeBs can differ. In this case if only one of the NodeBs is
sending a power down command, the UE will lower its transmit power by the
defined power-down-step. In case there is no TPC at all the transmit power of
the UE remains unchanged.
More information including parameter can be found in [28].
7.1.2.2.
Cells suffering with high UL BLER can be easily identified using data from the
PM system. When doing drive testing high UL BLER can be identified by using
the RFCT feature in parallel to tracking the KPIs as retrieved by the RNC. High
UL BLER might cause a RLF in the UL and/or the drop of the call (see also
subsection 6.1).
Table 67 and Table 68 are listing the triggers in interface traces and the
corresponding PM KPIs:
Problem
Trace
High UL BLER in
RFCT
High UE
reached
UL BLER higher than x % for more than y seconds
Uu
Any occurrence where the UE is sending with at least y dB UE power for more
than x seconds18
Bad CRCI
Iub
More than x % of the CRCIs within y seconds have a CRCI equal to 1.
Bad QE
Iub
More than x % of the QEs within y seconds have a QE more than y.
target
Iub
The SIR target for service x is exceeding value y.
UL SIR target not

updated
Iub
Any occurrence where the UL SIR target is not updated for more than x
seconds. This is an indication of failure in the UL that might lead to an UL RLF.
SIR
exceeded
power
RFCT
Trigger
Table 67: Identification of high UL BLER in interface traces
PM
system
Counter / KPI
RNC
(VS.ULTransBlockErr.CSV.All / VS.ULTransBlock.CSV.All)*100
UL BLER rate for All CSV AMR

codec rates
RNC
(VS.ULTransBlockErr.CSD / VS.ULTransBlock.CSD)*100
UL BLER rate for CSD
18
Note that according to the 3GPP specification there are four power classes defined (power class 1 to 4) with maximum
output power +33 dBm, +27 dBm, +24 dBm and +21 dBm. The most common mobiles on the market are class 3 (+24 dBm).
Page 95 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
RNC
(VS.ULTransBlockErr.PS / VS.ULTransBlock.PS)*100
UL BLER rate for PS
Table 68: PM KPIs identifying BLER issues

UL BLER measurements can also be retrieved via the ex-Lucent RF Call trace
feature [22].
7.2.
Call quality Quality of service (QoS)

QoS is reflecting the quality of a wireless network from the user perspective in
terms of voice quality, data throughput or the quality of the video signal using
VT. The QoS can be measured with special drive test equipment. For
evaluation purposes the drive test equipment should use a predefined
measurement sequence for each of the service types as given in the appendix
of this document.
In this chapter the QoS for the different service types are discussed as well as
how to identify possible failures and quality degradations.
It is assumed that the number of measurement samples is sufficient to get a
reliable result;
7.2.1. QoS general

In this subsection general QoS KPIs are listed that are not linked to a particular
service like voice, data or VT. These can act as trigger points for identifying
non-optimal performance.
KPI
Counter / KPI
No network [%]
Attach failure [%]
Attach setup time [s]
Location update success rate [%]
(1- NoCallAttwithNoNetworkDetected / NoAllCallAtt) * 100

NoUnsuccessfulAttachAtt / NoAllAttachAtt * 100
t_attach_complete t_attach_request
NoSuccessfullLU / NoAllLUAtt * 100
SMS failure rate [%]
NoFailedSMSTasks / NoStartedSMSTasks * 100
MMS failure rate [%]
NoFailedMMSTasks / NoStartedMMSTasks * 100
SMS delivery time [s]
t_sms_delivered t_sms_start
MMS delivery time [s]
t_mms_delivered t_mms_start
Table 69: General QoS parameters measured on application level

In ex-Lucent U04.03 QoS parameters as given in the PDP Context Activation
Request message are used for the DBC feature, see also subsection 5.4.1 and
[20] for details.
7.2.2. QoS voice service

Because of the uncorrelation of UMTS links it is necessary to measure the UL
and DL voice quality separately. Using special drive test equipment provided by
e.g. QVoice or SwissQual one can do this. This equipment is comparing the
received voice samples with the transmitted voice samples. In that way the
evaluation software can do a voice quality classification for both directions
independently.
Page 96 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Table 70 below is giving the QoS parameter for voice services. For the voice
quality evaluation the Mean Opinion Score (MOS) is used. The MOS is defined
by the ITU and is ranging from 1 to 5, for details see also ITU P.800 and ITU
P.862. For further discussion on the MOS performance of various AMR codec
rates see [47]. A good voice quality can be considered when the MOS is
exceeding 3.0. Voice quality degradations like e.g. echo or voice delay are
reflected by this measure.
Mean Opinion Score (MOS)
QoS value
Below 2.0
Poor
2.0 to 3.0
Fair
3.0 to 4.0
Good
Above 4.0
Excellent
Table 70: QoS of voice services - MOS

Table 71 below is listing the formulas to retrieve the QoS KPIs for voice:
KPI
Counter / KPI
Call completion success rate

voice [%]
NoSuccCompletedCallsVoice / NoSuccSetupCallsVoice * 100
Block call rate voice [%]
(NoSetupFailedCallsVoice - SetupFailedCallNoNetworkVoice) /
NoCallAttVoice *100
Dropped calls voice [%]
NoDroppedCallsVoice / NoSuccSetupCallsVoice * 100
HandoverSuccess3G2G [%]
No3G2GHandoverSuccSeiz / No3G2GHandoverAtt * 100
HandoverSuccess2G3G [%]
No2G3G HandoverSuccSeiz / No2G3GHandoverAtt * 100
Call setup success rate voice [%]

Good voice quality [%]
NoSuccCallSetupVoice / NoCallAttVoice * 100

NoVoiceSampleGoodExcellent / NoAllVoiceSamples * 100
Table 71: QoS of voice services KPIs
7.2.3. QoS data services

7.2.3.1.
Concept
There are different metrics available defining the QoS of data services like
throughput, delay, jitter etc. In the PDP Context Activation Request message
the UE can optionaly request pre-defined QoS profiles as specified in [5]. The
CN can check the requested QoS profile with entries from the HLR. The CN
makes these negotiated QoS parameters available to the UTRAN via the RAB
Assignment Request [9].
Dedicated and common UTRAN resources can be dynamically assigned
depending on traffic measurements or load. The initially assigned PS RB at the
beginning of a PDP session depends on the UTRAN configuration. The RB can
be dynamically changed (or even the mobile is sent to idle
mode/URA_PCH/CELL_PCH mode) depending on the data to be sent in the UL
and/or DL. Depending on the status of the RLC queue in the UE the mobile
might send a Measurement Report 4a (in case the transport channel traffic
volume exceeds an absolute threshold) or Measurement Report 4b (in case
the transport channel traffic volume becomes smaller than an absolute
Page 97 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
threshold). The RNC may or may not react on this Measurement Report by
doing a RB reconfiguration (see subsection 5.4.1 and 6.17.1). Furthermore a
smaller RB can be assigned in case of overload estimations done by the RNC
(subsection 6.5).
Another difference when describing the PS data user perceived QoS is that a
drop of the RAB and RRC connection does not (necessarily) mean that the PDP
Context is removed from the GGSN or the FTP session drops. After the new
establishment of the RRC connection and the new establishment of the RAB
the FTP session can be resumed in case the session has not timed out in
between. For the user the drop of the RRC and RAB is visible by stalling of the
FTP transfer for the particular timeframe and because of low throughput rates.
In case of real time applications like video streaming or web radio the drop will
be noticed by the user if the buffer of the application is emptied and no new
data is received. It might be that the application will re-start with codecs
requiring lower bandwidth to fill the internal buffer again.
On the PPP link of the PS data session the TCP/IP header and data can be
compressed resulting in a throughput increase. For most Microsoft platforms,
the PPP compression is an available option in the PPP settings of the dial-up
networking. .
In addition also the PDCP layer is providing header compression for e.g. TCP,
UDP, RTP and IP header [40].
Simple FTP-download tests of files with the size of 1MB in the UMTS networks
has shown that the throughput for zipped binary files is around 25% less
compared with the ASCII files.
7.2.3.2.
For analysing low PS data performance the following has to be considered:
UE state
Chosen RB
Reported failures of the transport network (subsection 6.13)
Problems detected on the RLC layer e.g. RLC retransmission or RLC

resets (subsection 6.14)
Reported BLER in UL and/or DL (subsection 7.1)
TCP configuration like TCP window size or MSS (see subsection 6.14.1
and the remarks in the appendix of this document)
Retransmission on TCP layer
PPP/PDCP compression used/not-used. Usage of zipped files/unzipped

ASCII files
The analysis should follow a top-down-approach:
First the end-to-end data performance should be investigated
Then delay measurements should be done indicating the source of the

performance degradation (e.g. delay due to non-optimal RLC queue,
retransmission on RLC etc.)
One example of an (graphical) analysis is shown in Figure 35 below. The

throughput of a FTP transfer is measured by Ethereal [30] and visualised by
tcptrace [31] is low. The root cause for the non-optimal performance is ConC:
Page 98 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 35: FTP performance degradation caused by ConC

The FTP throughput is the gradient of the curve; in addition TCP retransmission
caused by SDU discards on RLC are shown in the right part of the picture (see
also subsection 6.14.1).
It is possible to cross-correlate the UE Ethereal traces with Ethereal traces
recorded at the FTP server and also with RF data like Ec/No or Active Set
Update messages recorded by the UE by e.g. using Actix [29]. In that way FTP
performance degradations can be linked to handover problems, bad radio
conditions in terms of Ec/No or neighbour definition problems. When the traces
are recorded by different mechanisms, it might be necessary to correlate the PC
clocks by using time synchronisation see also subsection B in the appendix.
Otherwise tools like Actix can do event-based cross correlation.
Another example for an end-to-end analysis is shown in Figure 36 below; the
picture is visualising the delay of an ICMP ping between Internet server and PC
client for UL and DL separately. The trace was recorded with Ethereal [30].
Furthermore by tracing on the Iub, Iu and Gn interface it is possible to make
similar delay plots for the particular interfaces. This will unveil where the high
delay peaks are coming from and will give indications of how to improve the
end-to-end performance.
Page 99 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 36: end-to-end delay of an ICMP ping

For the same measurement the delay on the Gn interface were also measured
as shown in Figure 37 below. As expected the delay is very small and dont
have a big impact on the overall delay. This trace was recorded using a
Tektronix K12 protocol tracer.
Figure 37: delay measured on the Gn interface

Table 72 below is listing the identification triggers in network interface traces:
Page 100 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Problem
Trace
TCP reset
TCP
Number of occurrences if the REST flag of the TCP options is set to TRUE.
Statistic counted per TCP session
Trigger
TCP
retransmission
TCP
Number of occurrences of TCP retransmissions. Statistic counted per TCP

session
TCP SACKs
TCP
Number of SACK. Statistic counted per TCP session
Table 72: Identification of QoS issues for data service

Table 73 below is listing the data QoS parameter including the trigger points for
identifying non-optimal performance:
KPI
Counter / KPI
PDP context activation failure [%]

PDP context activation time [s]
PDP context cut off rate [%]
FTP cut off rate [%]
NoUnsuccessfulPDPActivation / NoPDPActivationAtt * 100

t_pdp_activation_complete t_pdp_request
NoPDPLosses / NoSuccessInitiatedPDP * 100
NoFTPLosses / NoSuccessStartedFTP * 100
FTP throughput [kbit/s]
UserDataTransferred [kbit] / (t_ftpend t_ftpstart)
Ping delay [s]
RTT of a ICMP with a payload of 32 bytes
HTTP failures [%]
NoSuccHTTPTasks / NoHTTPTasksStarted *100
RB Assignment Success Rate [%]
NoSuccAssignedRB / NoRequestedRB * 100
Table 73: QoS of data services KPIs
7.2.4. QoS VT service

For VT calls the QoS consists of voice and video quality. One Tool that can
provide the quality assessment of the video samples, as a MOS value, is exLucents LVAT. Although there is an ITU standard that defines the framework of
video quality measurement [48], it does not layout the algorithm and calibration
of the MOS and hence that remains vendor propriatry. For voice QoS parameter
the metric of subsection 7.2.2 is used.
Table 74 below is listing the formulas to retrieve the other QoS parameters for
VT:
KPI
Counter / KPI
Call completion success rate VT

[%]
NoSuccCompletedCallsVT / NoSuccSetupCallsVT * 100
Block call rate VT [%]
(NoSetupFailedCallsVT - SetupFailedCallNoNetworkVT) /
NoCallAttVT *100
Dropped calls VT [%]
NoDroppedCallsVT / NoSuccSetupCallsVT * 100
Call setup success rate VT [%]
NoSuccCallSetupVT / NoCallAttVT * 100
Table 74: QoS of VT services KPIs
Page 101 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Appendix
A. Measurement definition
A.1. Measurement definition voice
For voice services the UMTS UE in the drive test van should call an ISDN line in
the PLMN because otherwise it is hard to distinguish if the first or the second
mobile is responsible for observed failures or also for voice quality
degradations. This will help the RF planner to analyse the failure and propose
additional network changes.
The voice test call sequence for the UMTS UE in the drive test van should be as
follows:
Network attach
Mobile Originating Call (MOC), duration 2 minutes, alternating speech

sample from the UE to the PLMN and vice versa.
Network detach and pause of around 10 seconds
Network attach
Mobile Terminating Call (MTC), duration 2 minutes, alternating speech

sample from UE to the PLMN and vice versa.
Network detach and pause of around 10 seconds
The used drive test equipment should be capable of do generating this

measurement sequence automatically.
In parallel the RF conditions of the UE and the neighbouring cells should be
recorded using the drive test tool and a 3G and 2G scanner in parallel.
A.2. Measurement definition data
When doing KPI performance verification of data services the FTP server
should be directly connected to the GGSN to avoid any latency and delay
caused by the Internet. For security reasons a special test APN should be used.
The FTP throughput should be measured in motion and in addition also
stationary in case that there are some Hot Spots inside the UMTS cluster e.g.
railway stations, big hotels or airports.
It is recommended to do testing via scripts; the advantage being the
repeatability leading to ease of comparison and analysis. Data scripts are
supported by most of the drive test tools, but can also be made with tools like
19
cygwin providing a full Linux command shell environment [38] .
The data test call sequence should be as follows:
Network attach and PDP context activation
FTP download of three times 2 MB file, 5 seconds pause in between
Pause of 20 seconds
FTP download of three times 2 MB file, 5 seconds pause in between
Pause of 20 seconds
19
The original DOS FTP client should be used instead the FTP client from cygwin (/usr/bin/ftp). This
can be achieved by defining a variable called FTP_CMD = c:\winnt\system32\ftp.exe in the scripts.
Page 102 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
FTP upload of three times 1 MB file, 5 seconds pause in between
Network detach, PDP context deactivation and pause of around 10

seconds
For troubleshooting purposes it might be necessary to record the TCP/IP

protocol analyser as Ethereal on both the UE and the FTP server side [30].
In parallel the RF conditions should be recorded.
For measuring the maximum possible throughput on a radio link UDP shall be
used because TCP retransmission might give an incorrect picture of the
bandwidth capability.
The TCP configuration of the client PC and the server should be comparable
with the settings most common used by normal UMTS subscribers and in the
Internet. TCP window size of the sending entity should be large enough so the
RLC queue in the RNC is not going into underrun. For that reason it is helpful to
measure the amount of in-flight-packets to calculate the right settings for the
TCP window size.
Table 75 below is listing the default TCP/IP parameter that should be used
during the testing:
Entity
Feature
Setting
Short description
Client
SACK
Set to TRUE
SACK allows the receiver to inform the sender about all

segments that are successfully received
Server
TCP window
size
35 kbyte
The TCP window is the amount of outstanding data a

sender can send before it gets an acknowledgment for
the receiving entity
Client/server
PDCP
compression
Disable
When doing root cause analysis the feature should be

disabled
Client/server
PPP
compression
Disable
When doing root cause analysis the feature should be

disabled
Server
Starting
MSS
4 packets
The amount of TCP/IP packets sent by the sending

entity at the beginning. Further packets will be send after
reception of the first TCP ACK
Client
ICMP packet
size
40 byte
To measure the ICMP RTT an IP packet should be sent

with the size of 40 byte (8 byte header plus 32 byte
payload)
MSS
960 byte
The MSS should be 960 byte resulting in a MTU of 1000

byte (= MSS + 20 byte TCP header + 20 byte IP
header). The actual TCP/IP packet size used might be
smaller if Internet router is segmenting the packets
Client/server
Table 75: Default TCP/IP parameter settings used for testing

The TCP/IP settings can be verified using Ethereal. The settings can be set for
Windows PCs in the registry or with help of shareware tools like [39]. For UNIX
and Linux operating systems the settings can be set in the corresponding
configuration files.
In case ciphering on RLC/MAC and data compression on PPP/PDCP are not
used, special prepared ASCII files shall be used. This will ease the identification
of each single packet in Ethereal, Iub or Iu traces to detect retransmission on
TCP or RLC. Note that on Iu, Gn and Gi there is no compression and ciphering
used so using the particular tracing equipment can identify the ASCII payload.
Page 103 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
The special ASCII files should contain only one (!) line and as an example the
following sequence:
umts000000000umts000000001umts000000002umts000000003umts0000000
04umts000000005umts000000006
In case PPP data compression is on, zipped data shall be used to avoid
irregular throughput measurements.
Finally care should be taken that no other application on the PC are generating
any unnecessary network traffic.
Figure 38 below is showing a snapshot of the Ethereal protocol analyser:
Figure 38: Ethereal protocol analyser
Page 104 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
A.3. Measurement definition VT

For VT one mobile should be located in the drive test van, the other mobile
should be stationary located close to a UMTS site outside the UMTS cluster
under test; this will minimise possible failure causes for this second UE and help
the RF planner at the root cause analysis.
The measurement sequence should be the same as defined for voice calls
except that a network attach/detach is not necessary because this is service
independent.
So the full measurement sequence for the VT should be as follows:
Mobile Originating Call (MOC), duration 2 minutes, alternating speech

sample from UE 1 to UE 2 and vice versa.
Pause of around 10 seconds
Mobile Terminating Call (MTC), duration 2 minutes, alternating speech

sample from UE 1 to UE 2 and vice versa
Pause of around 10 seconds.
B. Time synchronisation of measurement traces

When collecting traces from different interfaces it might be necessary to ensure
rd
time synchronisation to enable a 3 party software like Actix to do the crosscorrelation.
There are many possibilities to synchronise clocks of the particular
measurement PC like NTP, GPS or also using a radio clock available in some
European countries. Under no circumstances NTP should be used via an UMTS
link because NTP is not designed for wireless network showing a high variance
on the lower protocol layer like RLC.
One software that can be used for time synchronisation is Tardis2000 [32]. It
can be configured as a NTP server and NTP client or using GPS. Furthermore it
is possible to configure the Tardis2000 NTP client that it adjusts its internal
clock within a predefined time frame.
It has to be verified if the application running on the PC has to be restarted in
order to retrieve the updated time.
Figure 39 below is showing the measurement setup for analysing PS data
services when doing drive testing in a van, Figure 40 for doing VT testing in a
lab.
Page 105 of 106
Document name:
Date:
2007-06-08
Rev: 2.1
Figure 39: Measurement setup for PS data analysis in a van
Uu
(cabled)
Stationary
voice/VT
evaluation drive
test equipment
2nd mobile in
shadowing box
Uu
(cabled)
Mobile voice
evaluation drive
test equipment
Fading
simulator
Iub
NodeB
Iu
CN
RNC
UMTS protocol
analyser
Local
NTP server
Figure 40: Measurement setup for VT testing in the lab
Page 106 of 106

UMTS RF Troubleshooting Guideline Draft V21

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UMTS RF Troubleshooting Guideline Draft V21

Uploaded by

Copyright:

Available Formats

Document name:

UMTS RF Troubleshooting Guideline U04.03

6th August 2007

UMTS Network Performance Engineering

UMTS RF Troubleshooting Guideline U04.03

GLOSSARY OF TERMS AND ABBREVIATIONS................................................................. 5

ABOUT THIS DOCUMENT..................................................................................................... 12

DESCRIPTION OF THE OPTIMISATION PROCESS ........................................................ 14

CALL SETUP ............................................................................................................................. 16

CALL RELIABILITY (RETAINABILITY)............................................................................ 43

UMTS Network Performance Engineering

UMTS RF Troubleshooting Guideline U04.03

CALL QUALITY ....................................................................................................................... 92

UMTS Network Performance Engineering

UMTS RF Troubleshooting Guideline U04.03

QoS general ............................................................................................................... 96

APPENDIX ....................................................................................................................................... 102

Updated draft after review with following

Editorial throughout the document

UMTS Network Performance Engineering

UMTS RF Troubleshooting Guideline U04.03

1. Glossary of terms and abbreviations

Access Class Barring

Acquisition Indication Channel

Access Link Control Application Protocol

Access Point Number

Automatic Repeat Request

Asynchronous Transfer Mode

Broadcast Control Channel

Bit Error Rate

Block Error Rate

Base Station Identity Code (GSM)

Base Station Subsystem (GSM)

Call Admission Control

Common Control Physical Channel

Configuration Management / Connection Management

Common Pilot Channel

Channel Quality Indicator

Cyclic Redundancy Checksum

Dynamic Bearer Control

Dedicated Control Channel

UMTS Network Performance Engineering

UMTS RF Troubleshooting Guideline U04.03

European Telecommunication Standard Institute

Forward Access Channel

Frequency Division Duplex

File Transfer Protocol

Gateway GPRS Support Node

General Packet Radio Services

Global Positioning System

Global System for Mobile Communication

Hierarchical Cell Structure

Home Location Register

High Speed Downlink Packet Access

High Speed Downlink Shared Channel

High Speed Uplink Packet Access

Hyper Text Transfer Protocol

High Speed Downlink Packet Access

Internet Control Message Protocol

Inter Radio Access Technology

Key Performance Indicator

Lucent Worldwide Services

Medium Access Control

Medium Access Control high speed