Document name: UMTS RF Troubleshooting Guideline UA6.

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

UMTS RF
Troubleshooting Guideline
UA6.0

(For internal Use Only)

Kiosk Live: UMT/IRC/INF/026976 V01/EN UMTS RF

Troubleshooting Guidelines
Editor: Irfan Mahmood

Date: 26th June 2009

Version: 1.02

UMTS Operational Network Engineering (For Internal Use Only) Page 1 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Table of Contents

1. GLOSSARY OF TERMS AND ABBREVIATIONS......................................................................4

2. REFERENCES...................................................................................................................................9

3. ABOUT THIS DOCUMENT.........................................................................................................11

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

5. CALL SETUP...................................................................................................................................15
5.1. CALL SETUP – RRC CONNECTION ESTABLISHMENT...............................................................................15
5.2. CALL SETUP – FAILURES DURING THE CALL SETUP PHASE........................................................................31
5.3. CALL SETUP – CORE NETWORK FAILURES...........................................................................................33
5.4. CALL SETUP – RAB ESTABLISHMENT.................................................................................................36
6. CALL RELIABILITY (RETAINABILITY).................................................................................41
6.1. CALL RELIABILITY – RADIO LINK FAILURE (RLF)..............................................................................42
6.2. CALL RELIABILITY – DROP OF THE RAB.............................................................................................46
6.3. CALL RELIABILITY – DROP OF RRC CONNECTION AFTER CALL SETUP.......................................................49
6.4. CALL RELIABILITY – RF PLANNING RELATED ISSUES.............................................................................52
6.5. CALL RELIABILITY – CONGESTION CONTROL .......................................................................................59
6.6. CALL RELIABILITY – FAILURES IN URA_PCH/CELL_PCH MODE......................................................60
6.7. CALL RELIABILITY – FAILURES IN CELL_FACH MODE.......................................................................62
6.8. CALL RELIABILITY – HARDWARE AND NETWORK INTERFACE OUTAGES.......................................................65
6.9. CALL RELIABILITY – INTRA FREQUENCY SOFT/ER HANDOVER...................................................................65
6.10. CALL RELIABILITY – IRAT HANDOVER.............................................................................................69
6.11. CALL RELIABILITY – CELL CHANGE ORDER FROM UTRAN.................................................................73
6.12. CALL RELIABILITY – INTER FREQUENCY HANDOVER.............................................................................74
6.13. CALL RELIABILITY – FAILURES ON THE TRANSPORT NETWORK..............................................................76
6.14. CALL RELIABILITY – FAILURES ON RLC...........................................................................................76
6.15. CALL RELIABILITY – HSDPA.........................................................................................................80
6.16. CALL RELIABILITY – HSUPA/EDCH.............................................................................................86
6.17. CALL RELIABILITY – MISCELLANEOUS FAILURES..................................................................................90
7. CALL QUALITY.............................................................................................................................94
7.1. CALL QUALITY - BLOCK ERROR RATE (BLER)..................................................................................94
7.2. CALL QUALITY – QUALITY OF SERVICE (QOS).....................................................................................98
APPENDIX........................................................................................................................................104
A. MEASUREMENT DEFINITION...............................................................................................................104
B. TIME SYNCHRONISATION OF MEASUREMENT TRACES..............................................................................107

UMTS Operational Network Engineering (For Internal Use Only) Page 2 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Change Record
This table details the changes done to the document since the last version

Date Changes Issue#

th
28 February 2009 Updated draft after ONE team review for UA6 1.01
converged UTRAN
26th June 2009 Updated final version after SDT/ONE/SBG 1.02
teams review for UA6 converged UTRAN

UMTS Operational Network Engineering (For Internal Use Only) Page 3 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

1. Glossary of terms and abbreviations

ACB Access Class Barring

ACK Acknowledgement
AICH Acquisition Indication Channel
ALCAP Access Link Control Application Protocol
APN Access Point Number
AM Acknowledged Mode
ARFCN Absolute Radio Frequency Channel Number
AO Always On
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
CEM Channel Element Module
CM Configuration Management / Connection Management
CN Core Network
CPICH Common Pilot Channel
CQI Channel Quality Indicator
CRC Cyclic Redundancy Checksum
CRCI CRC Indicator
CS Circuit Switched
CT Call Trace
DAHO Database Assisted HO
DBC Dynamic Bearer Control
DCCH Dedicated Control Channel
DCH Dedicated Channel
DL Downlink
DRNC Drift RNC
DRX Discontinuous Reception

UMTS Operational Network Engineering (For Internal Use Only) Page 4 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

EDCH Enhanced DCH

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
IMCTA Intelligent Multi-Carrier Traffic Allocation
IP Internet Protocol
IRAT Inter Radio Access Technology
IRM Intelligent Rate Matching
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

UMTS Operational Network Engineering (For Internal Use Only) Page 5 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

MM Mobility Management
MMS Multi Media SMS
MO Mobile Originating
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
OAM 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

UMTS Operational Network Engineering (For Internal Use Only) Page 6 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

RLF Radio Link Failure

RF Radio Frequency
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
SBG Services Business Group
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
TFCI Transport Format Combination Indicator
TGPS Transmission Gap Pattern Sequence
TM Transparent Mode
TPC Transmit Power Control
TSSI Transmitted Signal Strength Indicator
TX Transmitted
UDP User Datagram Protocol

UMTS Operational Network Engineering (For Internal Use Only) Page 7 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

UE User Equipment (mobile station)

UL Uplink
UM Unacknowledged Mode
UMTS Universal Mobile Telecommunication Standard
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 2.

UMTS Operational Network Engineering (For Internal Use Only) Page 8 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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] HSxPA Parameter User Guide for UA6.0, https://wcdmall.app.alcatel-
lucent.com/livelink/livelink.exe?
func=ll&objId=42687602&objAction=browse&sort=name&viewType=1
[17] UMTS Parameter User Guide for UA6.0, https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?
func=ll&objId=41590109&objAction=browse&sort=name&viewType=1
[18] Actix, http://www.actix.com
[19] Wireshark, documentation and download at http://www.wireshark.org/
[20] tcptrace, documentation and download at www.tcptrace.org
[21] Tardis2000, www.kaska.demon.co.uk/tardis.htm
[22] TS 25322 RLC protocol specification
[23] TS 21905 Vocabulary for 3GPP Specifications
[24] Cygwin available at http://www.cygwin.com/

[25] DR TCP available at http://www2.kansas.net/drtcp.asp

[26] TS 25323 Packet Data Convergence Protocol (PDCP) Specification
[27] Alcatel-Lucent 9300 W-CDMA product family counters dictionary –
RNC/NodeB Counters, NN20500-028PX: https://wcdma-ll.app.alcatel-

UMTS Operational Network Engineering (For Internal Use Only) Page 9 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

lucent.com/livelink/livelink.exe?
func=ll&objId=44811811&objAction=browse&sort=name&viewType=3
[28] TR 26975 Performance characterisation of the AMR speech codec Report
[29] Performance monitoring guidelines for UA06, https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?
func=ll&objId=43991232&objAction=browse&sort=name&viewType=1
[30] Wireless Quality Aanalysis (WQA) Tool, https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?
func=ll&objId=37186755&objAction=browse&sort=name&viewType=3
[31] Feature strategy and monitoring document, 33821 & 34700, PS RRC re-
establishment UA06 feature, https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?
func=ll&objId=41699995&objAction=browse&sort=name&viewType=1
[32] ITU-T J.144 Objective perceptual video quality measurement techniques
for digital cable television in the presence of a full reference
[33] RF Optimisation and Analysis Tool Suit
http://navigator.web.lucent.com/
[34] EDCH Settings cookbook - UA5.x and UA6

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?
func=ll&objid=35999228

[35] Technical Card – How to reach HSxPA Highest Throughput, U-TC-19

http://frctfd0f06660.ad2.ad.alcatel.com/GPS_Tools/tcardsUMTS/list.php?
idP=10&idR=14&idT=T
[36] RNC9370 Call trace (CT) User Guide,
https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?
func=ll&objid=37184418&objAction=browse&sort=name
[37] Iub Engineering Guidelines, https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?
func=ll&objId=51388411&objAction=browse&sort=name&viewType=1

UMTS Operational Network Engineering (For Internal Use Only) Page 10 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

3. About this document

3.1. Introduction
The UMTS RF Troubleshooting Guideline is one of the base documents for the
UMTS deployment process and is used for the identification, classification and
resolution of problems, failures or performance degradations that might be
observed during this activity.
This document covers the following items:
• Drive test data analysis (Uu traces and 2G/3G scanner measurements)
• UTRAN call trace analysis (Uu and Iub tracing)
• 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 ALU UTRAN
and/or CN and gives references. All configuration parameters are given in the
format OAM Object.Parameter Name to facilitate finding it.

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.

UMTS Operational Network Engineering (For Internal Use Only) Page 11 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

3.3. How to read this guide

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 parameters 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 – two 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)
o The second table is listing the PM KPIs as retrieved by the
UTRAN PM system

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 ALU
equipment only. Whenever a new UTRAN release is available certain tables
and descriptions have to be updated while others parameters are project /
market 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 SBG engineers who are optimising and
troubleshooting ALU 9370 based UMTS network.
This document assumes that the reader has a good understanding of the UMTS
call processing and is familiar with the various troubleshooting and monitoring
tools that are available like RFO, LDAT3G, CT (g, b or n), WQA, SPO in US and
NPO in Global market.

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
documentation refered to in this document.
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.

UMTS Operational Network Engineering (For Internal Use Only) Page 12 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 optimisation
• CM audit and optimisation
• PM audit and optimisation
• Drive testing and investigation
• Network interface tracing and analysis
• Lab investigation and optimisation

These fields of UMTS optimisation are displayed in Figure 1 in yellow below.

Figure 1: ALU UMTS optimisation process – process flow

UMTS Operational Network Engineering (For Internal Use Only) Page 13 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.

UMTS Operational Network Engineering (For Internal Use Only) Page 14 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

5. Call setup
One important 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 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.
The NAS part is described in 2 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

UMTS Operational Network Engineering (For Internal Use Only) Page 15 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.
The AS part is defined in 2 for UMTS and in 2 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 OAM 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 – P_MAX, 0) (UMTS),
Max(MS_TXPWR_MAX_CCH – P, 0) (GSM)
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 OAM parameters of the formula above are listed in Table 1 below:

Parameter Description
CellSelectionInfo Minimum required quality level in the cell (dB). Not applicable for TDD
.qQualMin cells or GSM cells, broadcasted via SIB3 and SIB4
CellSelectionInfo Minimum required RX level in the cell (dBm), broadcasted via SIB3 and
.qRxLevMin SIB4
PowerConfClass Maximum allowed UE Tx power (dBm) broadcasted on SIB3 and SIB4
.
sibMaxAllowedUlTxPo
werOnRach
Table 1: Parameters used for cell selection

The current formulas can only be used in case HCS is not deployed i.e.
FDDCell.isHcsUsed = False.

UMTS Operational Network Engineering (For Internal Use Only) Page 16 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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
FDD_Qmin defines minimum UMTS quality before UE can reselect from GSM
to UMTS layer. 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 neighbouring 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 whether a first or second ranking is being
performed, respectively. Qhysts is an hysteresis to avoid ping-pong effects,
Qoffsets,n is an offset defined on a per-neighbour definition. .
The reselection process using the mentioned parameters (Qoffsets,n = 0) is
visualised in Figure 3 below:

Figure 3: Cell reselection process

UMTS Operational Network Engineering (For Internal Use Only) Page 17 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Table 2 below is listing the main parameters configuring the cell reselection
process in case no HCS is used:

Parameter Description
CellSelectionInfo Time hysteresis for the cell reselection
.tReselection
CellSelectionInfo UMTS parameter broadcasted via the SIB3/SIB4 defining whether
.sSearchRatGsm or not to start with inter-RAT measurements (setting of SSearchRAT)

CellSelectionInfo UMTS parameter broadcasted via the SIB3/SIB4 defining whether

.sInterSearch or not to start with UMTS interfrequency measurements (setting of
Sintersearch)
CellSelectionInfo Hysteresis to avoid ping-pong effects (RSCP, Ec/No specific
.qHyst1 respectively)
.qHyst2
UmtsNeighbouringRelation or UMTS parameter broadcasted via the SIB11/SIB12 defining an
GsmNeighbouringCell offset on a per neighbour basis
.qOffset1sn
UmtsNeighbouringRelation. UMTS parameter broadcasted via the SIB11/SIB12 defining an
qOffset2sn offset on a per UMTS FDD neighbour basis

Table 2: Most important parameter used for cell reselection, non HCS

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 2.

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 2. ACB is used during the integration of cells.
Common problems of the cell selection/reselection procedure are non-optimised
configuration of the UTRAN parameters shown in Table 1 and Table 2. 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.

UMTS Operational Network Engineering (For Internal Use Only) Page 18 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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
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 Uu Any occurrence of the MNC of the cell the UE is camping on is different from
selected the MNC of the H-PLMN
ACB Uu Any occurrence of IE “Access Class Barred” = TRUE in SIB3/SIB4
Call setup on non- Uu, 3G The call is setup via RRCConnectionSetup message on a cell that is not on the
optimal cell scanner x best cell listed by the 3G scanner within y dB window.
Call setup on non- Uu, 2G/3G The RXLEV of the best measured 2G cell is within a x dB window (or even
optimal RAN scanner better) for y seconds compared to the RSCP of the cell the UE is camping on
technology when sending the RRC Connection Request or Cell Update message on
RACH
Ping-pong LU Uu There are two consecutive LUs between 2G and 3G within x seconds and the
between 2G / 3G 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
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 time period. In addition the RNC might trigger the

UMTS Operational Network Engineering (For Internal Use Only) Page 19 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.
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. Failure symptoms, identification and fixes for improvement

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
• UTRAN sending paging to incorrect URA area or mismatch in paging
DRX cycle coefficient (sent in SIB1, RRC connection setup and RB
reconfiguration messages) or UE timing issues to lock on PCH (i.e. UE
still asleep when paging is sent) especially if no response from UE
while RF conditions are good
Table 4 below is listing the main UTRAN parameters configuring the PICH, PCH
and AICH:

Parameter Description
PCH. UTRAN parameter defining the power settings of the
pichPowerRelativeToPcpich PICH
SCCPCH. UTRAN parameter defining the power settings of the
SccpchPowerRelativeToPcpich SCCPCH
RACH. UTRAN parameter defining the power settings of the
aichPowerRelativeToPcpich AICH

xxPagingTimer1 Timeout when the RNC will repeat the paging

PCH. nrOfPagingRepetition Number of Type 1 paging repetitions sent by the

RNC provided isPagingRepetitionAllowed
= True

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

1
Note this is a static MIB parameter and is not visible via OAM (e.g. WiPS)

UMTS Operational Network Engineering (For Internal Use Only) Page 20 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.
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.

VS.IuReleaseReq.PS.UtranPageFail

Figure 4: Dropped RRC connection due to unsuccessful paging

A solution of lowering the paging load might be to separate the FACH and PCH
on two SCCPCH by introducing an additional SCCPCH channel. 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 using advanced UE log collection. In such cases UE
repeats RACH preamble and there is no AICH reply even after max number of
preambles exhausted; on the other hand if AICH reports NACK it means power
settings for AICH is optimum but we could have UL RSSI issue which leads to
maximum preamble being transmitted but still NACK received on AICH.

UMTS Operational Network Engineering (For Internal Use Only) Page 21 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Note that PHY ACK on AICH can only be recorded and analysed by certain UE
tools like Qualcomm QXDM and QCAT respectively. In addition “normal” RF
optimisation for areas with low Ec/No will improve the situation and power
increase can also help if no AICH response seen on PHY.
Table 5 below is listing of how failures on the PICH/AICH/PCH can be identified
in network traces:
Table 5: Identification of PICH/PCH/AICH failures in traces
Problem Trace Trigger
RRC drop due to CT Cross correlation Iu and CTg trace: any occurrence where a UE page is
unsuccessful paging recorded in CT, there is no Cell Update recorded on CT 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)
Unsuccessful paging CT Any occurrence where a UE is paged and recorded on the CT and there is no
answer by the UE on UL CCCH also recorded in the CT within x seconds

Table 6 below is listing the identification possibilities using KPIs/Counters

retrieved by the UTRAN PM system.
Table 6: PM KPIs/Counters for PICH/PCH/AICH failures
PM Counter / KPI KPI Name / Description
system
UtranCell (VS.NbrCellUpdates.PagingResponse / UTRAN pagging response success rate
(VS.IuReleaseReqPS.UtranPageFail +
VS.NbrCellUpdates.PagingResponse))
RNC VS.UnhandledPagingRequests.OverloadControls This measurement provides the number of
paging attempts discarded by the RNC TPU
due to processor load for CS and PS calls
RNC VS.ReceivedPagingRequest This measurement provides the number of
paging attempts received by the RNC
UtranCell VS.CommonMacDownlinkPcchSdu Provides the channel occupancy for the PCH
channel

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.
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:

UMTS Operational Network Engineering (For Internal Use Only) Page 22 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 5: RACH procedure with RACH Preambles and Message Part

When the UE sends the RRC Connection Request message for the first time, it
resets its internal counter V300 to 1 and stars its internal guard timer T300
(taken from 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
establishment cause> is incremented by one2. 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 2.
For the Cell Update and URA Update procedure N302 and T302 are used (from
network broadcasted parameters n302 and t302). Figure 6 below is showing as
an example the Cell Update procedure:

Figure 6: Cell Update procedure supervised by T302 and N302

2
“<per establishment cause>” is a placeholder for e.g. OrigConvCall, OrigStrmCall etc. A full list is
available in 2.

UMTS Operational Network Engineering (For Internal Use Only) Page 23 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 RACH search Window3
• 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.
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
RACH. constantValue Used by UE to calculate Initial Preamble Power

RACH. powerOffsetPo Determines the power increment between two successive RACH
Preambles

RACH. Determines the maximum number of preambles allowed within one

preambleRetransMax Power Ramping Cycle
RACH. The threshold for preamble detection. The ratio between received
preambleThreshold preamble power during the preamble period and interference level
shall be above this threshold in order to be acknowledged. This
parameter is ignored by OneBTS, as it uses its internal value.
PowerConfClass This parameter defines the maximum allowed power the UE may
. use when accessing the cell on PRACH in idle mode
sibMaxAllowedUlTxPo
werOnRach
RACHTxParameters. Determine the maximum number of power ramping cycles allowed
mMax
UeTimerCstIdelMode UE guard timer that is supervising the RRC Connection Setup
procedure when the UE is waiting for the RRC Connection Setup
.t300 message
UeTimerCstIdelMode Defines the number of times the UE is allowed to send the same
RRC Connection Request message
.n300
UeTimerCstConnected UE guard timer that is supervising the Cell/URA Update procedure
Mode when the UE is waiting for the Cell Update Confirm/ URA Update
Confirm message
.t302
UeTimerCstConnected Defines the number of times the UE is allowed to send the same
Mode

3
Static NodeB tunable parameters for OneBTS and Class 0 parameter BTSCell.cellSize in iBTS

UMTS Operational Network Engineering (For Internal Use Only) Page 24 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Parameter Description
.n302 Cell Update/ URA Update message

Table 7: Parameter used for configuring the RACH

5.1.3.2. Failure symptoms, identification and fixes for improvement

The RACH Preambles may only be recorded in internal UE or NodeB traces,
but not by “normal” drive test tools. In most cases only limited statistic about the
PHY and MAC procedure of the RACH is listed in the drive test logs e.g.
number of RACH Preambles sent, last transmitted power etc4.
The RACH performance can be improved by changing of the power settings
and/or changing of the timer/counter as listed in Table 7. Also refer to
suggestions in section 5.1.2.2 in this regards.
Table 8 below is listing the identification possibilities for network and UE traces;
Table 9 below is listing the identification possibilities using KPIs retrieved by the
UTRAN PM system.

Problem Trace Trigger

RACH message Uu and CT Cross-correlation Uu/CT trace: RACH Message Part (RRC Connection
lost Request, Cell Update or URA Update) is recorded on the Uu, but not
captured in CT traces.

Table 8: Identification of RACH failures in traces

PM Counter / KPI KPI Name / Description

system
UtranCell (VS.CommonMacUplinkCcchSdu / KPI “RACH transport block good CRC rate” is
(VS.CommonRlcCcchDiscardSdu + the percentage of RACH Transport Blocks with
VS.CommonMacUplinkCcchSdu)) good CRC.
UtranCell VS.CommonMacUplinkDcchOverRachSdu + This measurement provides the channel
VS.CommonMacUplinkDtchOverRachSdu occupancy for Radio Access Channel.
UtranCell VS.NbrCellUpdates.<causes> Number of cell updates received with a specific
cause like RLC error, RLF, Cell re-selection, re-
entered service area, paging response, uplink
data transmission and periodic cell update

Table 9: PM KPIs for RACH failures

5.1.4. Call Admission Control (CAC)

5.1.4.1. Concept
The Call Admission Control (CAC) procedure admits or denies the
establishment of the RRC connection upon RACH access to avoid an overload
of the UMTS system. The CAC thresholds can be defined based on uplink noise

4
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 to 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).

UMTS Operational Network Engineering (For Internal Use Only) Page 25 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

rise and downlink load separately. The CAC algorithms and the corresponding
parameter are described in detail in 2.
The CAC is started after the RNC receives the RRC Connection Request
message on RACH and executes UL and DL CAC before setting up the first RL
on NBAP for the initial SRB channel (see Figure 7 below):

RRC.FailConnEstab.Cong.Sum

Figure 7: CAC executed after reception of RACH Message Part

If the defined 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 and the
power control settings don’t result in consuming too much resources to support
a call. Table 10 below is listing the main parameters configuring CAC before
RRC connection setup is sent back from UTRAN:

Parameter Description
CacConfClass Specifies the threshold for UL call admission of a RRC connection request
received on RACH.
.maxUlInterferenceLevel
PowerPartConfClass Specfies the threshold for DL call admission of a first RL setup in response to
.callAdmissionRatio RRC connection request received

Table 10: Parameters configuring CAC at RRC connection setup

5.1.4.2. Failure symptoms, identification and fixes for improvement

CAC failures can only be identified in a reliable manner via PM counters or
internal call trace/ UE logs.

Problem Trace Trigger

UMTS Operational Network Engineering (For Internal Use Only) Page 26 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

RRC Connection Uu or CT After the UE sends a RRC Connection Request message and RNC replies with
Reject RRC Connection Reject message with cause “Congestion”.

Table 11: Identification of RRC Connection Reject due to Congestion

For CAC related PM KPIs see 2 however the main PM counter is given below:
PM Counter / KPI Name / Description
system
UtranCell RRC.FailConnEstab.Cong.Sum This measurement provides the number of RRC connection rejects
sent with cause “Congestion”
UtranCell RRC.FailConnEstab.DLPowRsrc This measurement provides the number of failed RRC connection due
to lack of DL power
UtranCell VS.RadioLinkFirstSetupFailure.R First RL setup failure caused by rejection due to lack of resources
rmRefusal

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 AAL5 bearer.

UMTS Operational Network Engineering (For Internal Use Only) Page 27 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 8: Initial RRC Setup Steps after successful CAC

5.1.5.2. Failure symptoms, identification and fixes for improvement

The NBAP First Radio Link Setup procedure may fail and the NodeB sends
back the Radio Link Setup Failure message.
According to 2 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”, “DL Radio resources unavailable”, ”Semantic
error” etc. 3GPP has defined a variety of failure causes. Here one major reason
for NodeB resources problem can be UCU/CEM capacity shortage, while
transport resources issue can point to the backhaul bandwidth limitation.
RNC can also cancel an on-going NBAP pocedure if nbap_TimerInMsec
expires. This is a static parameter in 9370 and all such parameters need a MIB
patch if a change is required.
Table 13 below is listing the identification possibilities for network interface
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, CT traces
are mandatory. Reason is that on Uu, 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 and Cross-correlation Uu/CT trace: Any occurrence of the NBAP Radio
CT Link Setup Failure message in CT and RRC Connection Reject with
cause “unspecified” or “congestion” after that
Radio Link Setup II CT Any occurrence of the NBAP Radio Link Setup Failure message in CT

Table 13: Identification of failures in the Radio Link Setup

PM Counter / KPI KPI Name / Description

system
UtranCell (RRC.FailConnEstab.Unspec / RRC.AttConnEstab.<sum>) Failed RRC Connection
Establishment Rate due to
cause “unspecified”
UtranCell (VS.RadioLinkSetupSuccess / VS.RadioLinkSetupRequest.<sum>) Radio link setup success rate on
Iub
UtranCell ((RLM.FailRLSetupIub.PS.Resource + RLM.FailRLSetupIub.CS.Resource) / Radio link setup failure rate on
VS.RadioLinkSetupRequest.<sum>) Iub due to lack of resources
(NodeB &/or transport)
UtranCell VS.RadioLinkFirstSetupFailure.<cause>5 First RL setup attempt failure
with 8 different screenings
RNC (VS.IurDrncRadioLinkSetupSuccess / (VS.IurDrncRadioLinkSetupUnsuccess + Radio link setup success rate on

UMTS Operational Network Engineering (For Internal Use Only) Page 28 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

VS.IurDrncRadioLinkSetupSuccess)) Iur

Table 14: PM KPIs for Radio Link Setup procedure

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.
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). Here we only discuss RRC
connection procedure …
The RNC sends the FACH message, resets internal counter V351 and starts its
guard timer T351. When the RNC receives the answer by the UE (i.e. RRC
Connection Setup Complete) before T351 expires, the RNC stops T351. If the
RNC does not receive the message before T351 expires, the RNC may resend
the FACH message depending on the status of V351. If V351<= N351
(maximum number of retries), the RNC increments V351 by one, resets timer
T351 and sends the FACH message again. If V351 > N351, the RNC will stop
sending FACHs to the UE and will release the reserved resources on NBAP
and ALCAP. This UE context release will be initiated by counter T352. Note that
the RNC will not send any failure message on the Uu.
The whole procedure is visualised in Figure 9 below:

5
<cause> include RRM refusal, INode refusal, timeout, RL setup failure, Iub congestion, lack of Iub
CID, lack of CEM L1 resources, lack of Iub bandwidth.

UMTS Operational Network Engineering (For Internal Use Only) Page 29 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

RRC.FailConnEstab.TimeoutRepeat +
RRC.FailConnEstab.Reselect

Figure 9: Failures on FACH during RRC connection phase

Table 15 below is listing the parameters configuring the FACH:

Parameter Description
FACH. fachTrbPowerOffset UTRAN parameter defining the power settings of the FACH data part

FACH. fachSrbPowerOffset UTRAN parameter defining the power settings of the FACH control
part

CallAccessPerformanceConf. UTRAN timer to repeat RRC connection setup upon expiry

t351
CallAccessPerformanceConf. Maximum number of RRC connection setup repititions
n351
CallAccessPerformanceConf. UTRAN timer to release UE context upon expiry, should be =>
t351*(n351+1)
t352
Table 15: Parameters used for configuring the FACH

UMTS Operational Network Engineering (For Internal Use Only) Page 30 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

5.1.6.2. Failure symptoms, identification and fixes for improvement

There are the following possible reasons for failures on FACH:
• Non optimal UTRAN parameter settings (e.g. FACH signalling and
traffic power)
• FACH message is not successfully decoded due to poor FACH
coverage. This can be improved by enabling the RRC connection quick
repeat and FACH power adjustment feature by setting
CallAccessPerformanceConf.isQuickRepeatAllowed = TRUE
• Call setup not done on an optimal cell (subsection 5.1.1)
• 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)
• Rogue UE keeps retrying to setup RRC connection via RACH but does
not repond to RRC connection setup from RNC. No IMSI assigned at
this stage so difficult to pinpoint the UE. One can use propagation delay
IE in the RRC connection setup request and LAC/RAC to validate if
single UE is responsible.
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 using call trace and
UE logs, Table 17 the corresponding PM KPIs:

Problem Trace Trigger

Lost FACH SRB Uu and CT Cross-correlation Uu/CT trace: one or more FACH messages are recorded in
message CT, but not on the Uu interface
FACH Failure Uu and CT Occurrence of Cell Update messages (repeated Cell Update Confirms ignored
by the UE as seen in CT), then RRC Connection Release message with
specified cause other than “normal event” sent back by the RNC on Uu

Table 16: Identification of failures on the FACH

PM Counter / KPI KPI Name / Description

system
UtranCell ((RRC.FailConnEstab.TimeoutRepeat + Failed RRC connection
RRC.FailConnEstab.Reselect) / RRC.AttConnEstab.<sum>) Establishment Rate timeout
UtranCell VS.CommonMacDownlinkDcchOverFachSdu + BW Occupancy on FACH
VS.CommonMacDownlinkDtchOverFachSdu

Table 17: PM KPIs for failures on the FACH

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 CELL_DCH mode. The
next message will already be sent in the new mode (RRC Connection Setup
Complete sent on UL DCCH).
Straight after transitioning to CELL_DCH, UE can be put in soft/softer handover.
This is the case if

UMTS Operational Network Engineering (For Internal Use Only) Page 31 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• UE is configured to report the measurements of more than one NodeB

by activation of Event 1A measurement on SIB 11
• The measurement from more than current cell is reported
• RNC then directs the UE to soft/softer HO through ASU procedure
Table below is listing the parameters that are important for the call setup phase:

Parameter Description
HoConfClass Object that contains the event 1A related parameters like reporting
.Event1AHoConfInSIB11 range, time to trigger, hysteresis etc broadcasted on SIB 11
FDDCell. Activates the event 1A measurement to be broadcasted on SIB11
isSib11MeasReportingAllowed
Table 18: Parameter important for the call setup phase

For more details about the translations see 2.

If the call is setup in an area where several NodeBs are providing marginal
coverage and if it is not possible to add the radio legs quickly, there is a big
likelihood that the call will fail before RAB is actually established. The above
feature tries to minimise the wait for the reception of the Measurement Control
message and helps in avoiding a call drop in such conditions.

5.2.2.Failure symptoms, identification and fixes for improvement

The RRC connection might drop in this early stage due to the following reasons:
• Non optimal handover parameter configuring the call setup in soft/softer
handover mode
• Non optimal power settings
• 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 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 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 UE traces as listed in Table 19
below:

Problem Trace Trigger

Call setup on a non- Uu, 3G The call is setup via RRCConnectionSetup message on a cell and at the
optimal cell scanner 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 Uu, 3G The number of cells in the Active Set is smaller than max AS size, but one
call setup scanner neighbouring cell is within xdB window compared to the Ec/No of the best
cell in the Active Set
Drop of RRC connection Uu The call is dropped within x seconds after sending the RRC Connection

UMTS Operational Network Engineering (For Internal Use Only) Page 32 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

at call setup Request

Table 19: 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
involves only 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 2 and 2. CM failures causes like “CM
Service Reject Cause” is mapped on the Reject Cause of the Mobility
Management IE 2.
Note that (almost) any failure in this subsection is not UTRAN related because
Direct Transfer messages are transparent to the UTRAN6. 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 3G-
MSC is a prerequisite for the initialisation of voice, data or VT services.

5.3.1.2. Failure symptoms, identification and fixes for improvement

For the root cause analysis please review the timer settings supervising the
mobility management protocols as specified in 2 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 2 chapter 9.2 (MM/CM)
and 9.4 (GMM). Table 20 below is listing the Mobility Management failures as
they can be retrieved by UE or call traces:

6
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.

UMTS Operational Network Engineering (For Internal Use Only) Page 33 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Problem Trace Trigger

MM Authentication Uu or CT Any occurrence of a MM Authentication reject message sent by the CN
Reject e.g. because of not-allowed national/international roaming
CM Service Reject Uu or CT 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 CT 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 RRC connection.
MM Abort Uu or CT 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 Uu or CT Any occurrence of a MM Location updating reject message sent by the
Updating Reject 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 CT 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.
GMM Authentication Uu or CT Any occurrence of a GMM Authentication and Ciphering Failure
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 Uu or CT Any occurrence of a GMM Authentication and Ciphering Reject
and Ciphering Reject message sent by the CN.
GMM Routing Area Uu or CT Any occurrence of a GMM Routing area update reject message sent
Update Reject 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 CT Any occurrence of a GMM Service reject message sent by the CN

Table 20: Identification of Mobility Management failures in interface traces

For listing of the PM KPIs of the Mobility Management refer to the PM counters
documentation of the 3G-MSC and SGSN from applicable vendor.

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, calls
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).

5.3.2.2. Failure symptoms, identification and fixes for improvement

Table 21 below is listing the CC failures as they can be retrieved by various
traces 2; note that the specified cause might depend on the 3G-MSC/UE
vendors:
Problem Trace Trigger
Abnormal CC Uu or CT Any occurrence of a CC Disconnect message (either UE or CN initiated) with
Disconnect specified cause other than “normal event”

UMTS Operational Network Engineering (For Internal Use Only) Page 34 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Abnormal CC Uu or CT Any occurrence of a CC Release / Release Complete message (either UE or

Release CN initiated) with specified cause other than “normal event”

Table 21: Identification of CC failures in interface traces

For listing of the PM KPIs of the CC failures as they can be retrieved by the PM
system of the 3G-MSC, refer to PM counters documentation from applicable CN
vendor.
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 2 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. Failure symptoms, identification and fixes for improvement

The failure messages are retrieved from 2. Table 22 below is listing the SM
failures as they can be retrieved by either UE logs or UTRAN call trace:

Problem Trace Trigger

SM Activate PDP Context Uu or CT Any occurrence of a SM Activate PDP Context Reject
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 Uu or CT Any occurrence of a SM Activate Secondary PDP Context
PDP Context Reject 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 Request PDP Context Uu or CT Any occurrence of a SM Request PDP Context Activation
Activation Reject 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 Uu or CT Any occurrence of a SM Modify PDP Context Reject
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 22: Identification of SM failures in interface traces

Again for listing of the PM KPIs of the SM failures as they can be retrieved by
the PM system of the GGSN, refer to PM counters documentation from
applicable CN vendor.

UMTS Operational Network Engineering (For Internal Use Only) Page 35 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 the timer settings supervising the SM
protocol in 2 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:

Figure 10: RAB establishment procedure

RAB establishment procedure is always initiated by the RANAP RAB

Assignment Request and terminated by the RAB Assignment Response. The
failure and failure causes of the RAB Establishment are specified in 2.
In ALU UTRAN, a RRC RB reconfiguration for RLC settings change is also
done straight after RNC receives the RB setup complete. And UTRAN only
sends back RAB Assignment Response upon completion of this reconfiguration.
This is the case if SRB with high data rate is used to setup call and later
changed to lower rate and both use different RLC settings. In case low rate
SRB channel is used throughout or same RLC settings employed for the two
SRB then this extra reconfiguration doesn’t take place and call flow as per
Figure 10 applies. Table 23 below is listing how to identify failures of the RAB
establishment procedure in network call trace:

UMTS Operational Network Engineering (For Internal Use Only) Page 36 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Problem Trace Trigger

RAB establishment failure CT Any occurrence of an RAB Assignment Response with
specified failure cause according to 3GPP7

Table 23: 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. Intelligent Rate Matching CAC (iRM CAC)

5.4.1.1. Concept
iRM CAC is used to prevent overload of the system due to high call load, in
case new resources or increase in resources are requested. In case Fair
sharing (feature 33694) is enabled, in addition of R99 traffic, GBR calls on
HSDPA will also be taken into account, in DL power and code cell colour
calculations. This check takes place
• During the RAB establishment after the RNC is receiving the RAB
Assignment Request on RANAP
• During the transition of CELL_FACH/URA_PCH to CELL_DCH mode
(see also subsection 6.6) after the RNC is receiving the corresponding
RACH messages
• In case data rate increase is triggered (see also subsection 7.2.3) after
the RNC measures the DL BO/throughput increase or receives a UL
BO RRC Measurement Report from the UE
• In case data rate change is triggered due to downlink dedicated Tx
code power crossing certain thresholds for a R99 PS call
Cell colour thresholds can be defined for UL (noise rise, CEM) and DL (power,
code, CEM) loads separately and options exist to disregard taking into account
some of these resources in overall cell colour calculations.
In case iRM CAC 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 CAC has not granted the
requested service:
o The assigned PS RB is smaller than the default one or the one
requested in the PDP Context Activation message8; 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”
o The VT call is not granted or instead a voice call is setup

7
There are a huge number of failure causes, but not all related to RAB assignment failure.
8
The requested QoS profile in the PDP Context Activation message might be ignored and only a
default one is assigned

UMTS Operational Network Engineering (For Internal Use Only) Page 37 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

o The Voice call receives a CC Disconnect message with specified

cause “resource unavailable”
• During the transition of CELL_FACH/URA_PCH to CELL_DCH mode:
o The RNC sends back the UE to idle mode with the RRC
Connection Release message and specified cause “congestion”
OR
o 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_FACH/URA_PCH.
• In case of throughput or BO measurement based data rate increase:
the internal RNC BO or throughput or UE RRC Measurement is just
ignored so the UTRAN keeps the current RB data rate
Not granting the requested service by iRM CAC indicates either high cell
loading (reflected by Red cell colour) or an area of high interference. The
approach in interference is to optimise the RF environment in terms of reducing
pilot pollution, improving RF coverage, neighbour list optimisation etc.
Features like iMCTA CAC can be enabled to divert the newly setup calls by
triggering HHO to different 3G or 2G layer in case these experience CAC. Even
iMCTA service can be configured to offload on-going calls to other 3G carriers
or 2G once originating cell colour turns Red while the target 2G/3G cell is
Green.
One may confirm that the various resource thresholds to change cell colour are
not set to trigger early transition to Red. An example threshold is given below,
please refer to 2 volume 5 for detailed discussion on iRM CAC and colour
thresholds.

Parameter Description
IrmOnCellColourParameters. Threshold for DL power
yellow2RedPLCThreshold
IrmOnCellColourParameters. Threshold for DL code
yellow2RedCLCThreshold
DlIrmCEMParameters. Threshold for DL CEM/UCU usage
yellow2RedDlCEMThresold
UlIrmRadioLoadParameters. Threshold for UL noise level
yellow2RedUlRadioLoadThreshold
UlIrmCEMParameters. Threshold for UL CEM/UCU usage
yellow2RedUlCEMThresold
IrmIubTransportLoadParameter. Threshold for Iub usage
yellow2RedDlTLCThresold
Table 24: Cell colour threshold (Yellow to Red) for various resources

5.4.1.2. Failure symptoms, identification and fixes for improvement

Table 25 is listing the identification techniques in traces in case CAC is not
granting the requested service:

Problem Trace Trigger

CAC RAB not CT Any occurrence of a RAB Assignment Response message on RANAP with
granted on Iu specified cause “No resource available”

UMTS Operational Network Engineering (For Internal Use Only) Page 38 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

CAC RAB not CT and Cross-correlation Uu/CT trace: Any occurrence of a RAB Assignment Response
granted on Iu Uu message on RANAP with specified cause “No resource available”
and Uu
CAC RAB PS CT or Any occurrence of a SM Activate PDP Context Reject message sent by the CN to
not granted Uu the UE and the specified cause is “Insufficient resources”
CAC RB Setup Uu On Uu, in the RRC RB Setup Message the IE “Spreading Factor” is larger than the
PS 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
CAC RB Setup Uu The VT call has been requested, the called entity is also a UE with VT capabilities
VT but a voice RB is setup
CAC RRC Uu Any occurrence of an RRC Cell Update/URA Update message following within x
Release seconds a RRC Connection Release message with specified cause “congestion”
and the UE is in either CELL_PCH or URA_PCH mode
CAC RB Setup Uu The UE is sending a CC Setup message and within x seconds gets a CC
voice Disconnect with cause “resource unavailable”
CAC Cell/URA Uu The UE is sending a Cell Update/URA Update message and the RNC is sending
update failed back within x seconds a Cell Update Confirm/URA Update Confirm message with
RRC State Indicator set to CELL_PCH/URA_PCH.

Table 25: Identification of iRM CAC rejections in interface traces

For iRM CAC related PM counters see 2 with a summarized version shown
below. Note that <Cause> can be UL interference, DL code starvation or DL
power. There are also counters that track the duration of time cell color was red
or yellow for UL and DL.

PM Counter / KPI Name / Description

system
UtranCell RAB.FailEstab.PS.<cause> Number of RAB Establishment Failures due to a given cause for CS
domain.
UtranCell RAB.FailEstab.CS.<cause> Number of RAB Establishment Failures due to a given cause for PS
domain.
UtranCell VS.IRMTimeCellRadioColorR Counter that tracks the percentage of time that a particular cell is
ed, …Yellow considered red or yellow by iRM

Table 26: PM Counters indicating potential R99 iRM CAC failures

5.4.2.Radio Link Reconfiguration

5.4.2.1. Concept
After iRM CAC 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.
RNC tries to allocate resources on the Iub by sending a RL Reconfiguration
Prepare message on NBAP. The NodeB answers 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 at a given activation CFN. The whole procedure is described in 2.

UMTS Operational Network Engineering (For Internal Use Only) Page 39 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

5.4.2.2. Failure symptoms, identification and fixes for improvement

For the failure analysis, please refer to subsection 5.1.5.2 as same failure
causes are used in both cases. Table 27 below is listing the identification
triggers for network traces, Table 28 the corresponding UTRAN KPIs.

Problem Trace Trigger

Radio Link CT Any occurrence of the NBAP Radio Link Reconfiguration Failure message on
Reconfiguration Iub x seconds after there was a Radio Link Reconfiguration Prepare on NBAP
failure

Table 27: Identification of RL reconfiguration failures in traces

PM Counter / KPI KPI Name / Description

system
UtranCell (VS.RadioLinkReconfigurationPrepareSuccess / Radio link reconfiguration preparation
(VS.RadioLinkReconfigurationPrepareUnsuccess.<sum> + success rate
VS.RadioLinkReconfigurationPrepareSuccess))
UtranCell VS.RadioLinkReconfigurationPrepareUnsuccess.<cause>9 Radio link reconfiguration prepare
failure with 9 different screenings
UtranCell VS.RadioLinkReconfigurationCancel Radio link reconfiguration cancel sent
by RNC in case of ALAP problem,
NBAP timeout etc

Table 28: 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
NodeB, 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 2. Table 29 below is listing the parameters for the RB
Establishment:

Parameter Description
UeTimerCstConnectedMode UTRAN parameter configuring timer T312
.t312
UeTimerCstConnectedMode UTRAN parameter configuring maximum count N312

9
<cause> include RRM refusal, INode refusal, NBAP timeout, RL reconfiguration failure, Iub
congestion, lack of Iub CID, lack of CEM L1 resources, lack of Iub bandwidth and NodeB out of
order

UMTS Operational Network Engineering (For Internal Use Only) Page 40 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

.n312
Table 29: Parameter important for the RB Establishment

5.4.3.2. Failure symptoms, identification and fixes for improvement

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
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 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 2. Again it is up to the UE vendor, which cause out of this list is
chosen for the particular failure that has occurred.
Table 30 is listing the identification techniques in traces, Table 31 the
corresponding PM KPIs for failures in the Radio Bearer Setup procedure:

Problem Trace Trigger

RB setup failure Uu or CT Any occurrence of the RRC Radio Bearer Setup Failure message

Table 30: Identification of Radio Bearer Setup failures in traces

PM Counter / KPI10 KPI Name / Description

system
UtranCell (RAB.FailEstab.CS.RBSetupFail / CS RAB establishment failure
RAB.AttEstab.CS) rate due to RB setup failure
UtranCell (RAB.FailEstab.PS.RBSetupFail / PS RAB establishment failure
RAB.AttEstab.PS) rate due to RB setup failure

Table 31: PM KPIs for Radio Bearer Setup failures

6. Call Reliability (Retainability)

This section is describing failures and occurrences that might happen after the
call has been successfully setup. This can not only 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.
For a detailed discussion on relationship between possible reason of PS call
drop and corresponding failure cause sent in the Iu release request to the CN,
refer to 2.

10
For corresponding definitions of CS RAB Attempts and PS RAB Attempts see 2.

UMTS Operational Network Engineering (For Internal Use Only) Page 41 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

6.1. Call reliability – Radio Link Failure (RLF)

6.1.1. Concept
According to 2 the PHY layer in the NodeB and UE checks every radio frame
the synchronisation status. The status is indicated to higher layers using the
CPHY-Sync-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 2).
Upon reception of this message the RNC starts timer T_RL_RESYNC (defined
by timer RadioAccessService.rlRestoreTimerAfterRlFailure). 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 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”. 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:

UMTS Operational Network Engineering (For Internal Use Only) Page 42 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

CN

Figure 11: RAB release call flow

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 2).
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:

UMTS Operational Network Engineering (For Internal Use Only) Page 43 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 12: Transitions between different states

Table 32 below is listing the parameters that are configuring the RLF and RL
Restore procedure:

Parameter Direction Description

SynchronisationConfiguration UL This parameter is defining the setting of
T_RLFAILURE
.tRLFailure
SynchronisationConfiguration UL This parameter is defining the setting of
N_OUTSYNC_IND
.noOutSyncInd
SynchronisationConfiguration UL This parameter is defining the setting of
N_INSYNC_IND
.noInSyncInd
RadioAccessService UL Configure guard timer to allow time for radio
link restore to occur for the first RL when
.RlRestoreTimer setting up the call. On expiry the RNC releases
the call.

RadioAccessService UL Configure guard timer T_RL_RESYNC to allow

time for the normal operation of the handover
.rlRestoreTimerAfterRlFailure 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.
UeTimerCstConnectedMode DL This parameter is defining the setting of T313
.t313
UeTimerCstConnectedMode DL This parameter is defining the setting of N313
.n313
UeTimerCstConnectedMode DL This parameter is defining the setting of T314
.t314
UeTimerCstConnectedMode DL This parameter is defining the setting of T315
.t315
UeTimerCstConnectedMode DL This parameter is defining the setting of N315
.n315
Table 32: Parameter configuring the RLF and RL Restore procedure

UMTS Operational Network Engineering (For Internal Use Only) Page 44 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 (subsections 6.4.2 & 6.4.3)
• 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 6.4.6)
RLF in the UL that is causing a removal of a radio leg can be directly identified
in UTRAN traces, if there is no Measurement Report with type 1b/1c sent
previously and a NBAP radio link failure indication is received with cause
‘Synchronisation failure’. If RLF with any other cause is received, the RNC
should delete the RL straightaway without waiting for RL restore timer. UL RLF
could also be due to DL RLC disrupttion detected at UE which turns off its PA
and later sends Cell Update with cause ‘RLC unrecoverable error’.
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 does
not have a unique cause id. For a reliable identification additional Iub/UTRAN
tracing is required.
Dropped calls due to RLF in the DL can be easily identified in UE logs or
network traces with the Cell Update message sent by the UE. There might be
an optional failure cause specified. Other cell update failures are covered in
subsection 6.3 and 6.14.2. Table 33 below is listing the identification
possibilities using UE and network traces.

Problem Trace Trigger

Dropped call due Uu Any occurrence of a RRC Cell Update message with specified cell update cause
to RLF in the DL (not failure cause) “radio link failure”. Note that the dropped call is the previous call
on Uu and not the current one! There might be an optional failure cause specified.
RLF and RL CT and Cross-correlation of Uu/CT traces: Any occurrence of an Radio Link Failure
Restore in CT and Uu Indication on NBAP with the cause “Synchronisation Failure” and after x seconds
Uu a Radio Link Restore Indication on NBAP
RLF and RL CT and Cross-correlation of Uu/CT traces: Any occurrence of an Radio Link Failure
Deletion in CT Uu Indication on NBAP with the cause “Synchronisation Failure” and after x seconds
and Uu a Radio Link Deletion on NBAP and the number of radio legs is more than one
RLF and dropped CT and Cross-correlation of Uu/CT traces: Any occurrence of an Radio Link Failure
call in CT and Uu Uu Indication on NBAP with the cause “Synchronisation Failure” and after x seconds
a Radio Link Deletion on NBAP and the number of radio legs is equal to one
UL RLF and leg Uu Any occurrence of an Active Set Update containing any entries in the group
removal on Uu “RemovalInformationList” and there was no Measurement Report within x seconds
before either with specified event id 1b/1c or without any specified event id11
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 33: Identification of RLF in traces

11
To be noted: the group “eventResults” containing the IE “eventID” is optional, for example when
periodic reporting is enabled.

UMTS Operational Network Engineering (For Internal Use Only) Page 45 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Table 34 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.

PM Counter / KPI KPI Name / Description

system
UtranCell (VS.RAB.Drop.CS.Cause.DL_RLF / CS RAB Drop Rate due to DL RLF
((RAB.AttEstab.CSV.RelocIratHO
-RAB.FailEstab.CSV.RelocIratHO) + RAB.SuccEstab.CS))
UtranCell (VS.RAB.Drop.CS.Cause.UL_RLF / CS RAB Drop Rate due to UL RLF
((RAB.AttEstab.CSV.RelocIratHO
-RAB.FailEstab.CSV.RelocIratHO) + RAB.SuccEstab.CS))
UtranCell (VS.RAB.Drop.PS.Cause.DL_RLF / RAB.SuccEstab.PS.<sum>) PS RAB Drop Rate due to DL RLF
UtranCell (VS.RAB.Drop.PS.Cause.UL_RLF / PS RAB Drop Rate due to UL RLF
RAB.SuccEstab.PS.<sum>)

Table 34: 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 2). 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.
Note that in Figure 13, T_RL_RESYNCH is shown as radio link failure
resynchronisation response timer.
RAB drop due to CN reasons
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 CN vendor dependent.

UMTS Operational Network Engineering (For Internal Use Only) Page 46 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 13: Drop of the RAB due to RLF on single RLS

6.2.2. Failure symptoms, identification and fixes for improvement

Table 35 is showing the identification techniques in call trace and UE logs:

Problem Trace Trigger

RAB drop due to CT Any occurrence of an Iu Release Request message with cause “Release due
UTRAN reasons to UTRAN generated reason” on Iu
on Iu
RAB drop due to CT and Uu Cross-correlation CT and Uu: Any occurrence of an Iu Release Request
UTRAN reasons message with cause “Release due to UTRAN generated reason” on Iu
on Iu and Uu
RAB drop due to CT Any occurrence of an Iu Release Command message with cause other than
CN reasons on Iu “Release due to UTRAN generated reason” or “normal-release” on Iu
RAB drop due to CT and Uu Cross-correlation CT and Uu: Any occurrence of an Iu Release Command
CN reasons on Iu message with cause other than “Release due to UTRAN generated reason” or
and Uu “normal-release” on Iu

Table 35: Identification of RAB drops in network interface traces

There are different PM KPIs describing RAB drops and can be seen in Table
36. The different PM KPIs describing RAB drops are differentiated as:

UMTS Operational Network Engineering (For Internal Use Only) Page 47 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• 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

PM Counter / KPI KPI Name / Description

system
UtranCell VS.RAB.Drop.CSV.UESigConnRel Dropped CS Voice RAB Connections
due to UE Initiated Signalling
Connection Release
UtranCell VS.RAB.Drop.CS.Cause.DL_RLF Dropped CS RAB connection per
failure cause: Downlink/Uplink Radio
VS.RAB.Drop.CS.Cause.UL_RLF Link Failure
UtranCell VS.RAB.Drop.CS.RelocUEInvol Dropped CS RAB connection due to
SRNS relocation.
UtranCell VS.RAB.Drop.CS.InterFreqHHO Dropped CS RAB connections due
to unrecoverable failures during
inter-frequency hard handover
UtranCell VS.RAB.Drop.CN.Init.CSV Dropped CN (core network) initiated
CS Voice RAB Connections.
UtranCell VS.RAB.Drop.CS.CodecChange Dropped CS RAB connections
during AMR codec change due to
unsuccessful termination of the Iu
Rate Control procedure.
UtranCell VS.RAB.Drop.PS.CellDCH.RelProc.<causes> Dropped UTRAN Initiated PS RAB
Connections with UE in Cell_DCH.
UtranCell VS.RAB.Drop.PS.CellFACH Dropped UTRAN Initiated PS RAB
Connections with UE in Cell_FACH
UtranCell VS.RAB.Drop.PS.Cause.DL_RLCErrRate Dropped PS RAB connection per
failure cause.
VS.RAB.Drop.PS.Cause.UL_RLCErrRate
VS.RAB.Drop.PS.Cause.DL_RLF
VS.RAB.Drop.PS.Cause.UL_RLF
UtranCell VS.RAB.Drop.PS.UESigConnRel Dropped PS RAB Connections due
to UE Initiated Signalling Connection
Release
UtranCell VS.RAB.Drop.PS.Reloc.UEInvol Dropped RAB connection caused by
SRNS relocation for the PS domain.
UtranCell VS.RAB.Drop.PS.InterFreqHHO Dropped PS RAB connections due
to unrecoverable failures at inter-
frequency hard handover.
UtranCell VS.RAB.Drop.CN.Init.PS.CellDCH.<causes> CN (core network) initiated dropped
PS RAB connections for Ues in
Cell_DCH state per transport
channel type.
UtranCell VS.RAB.Drop.PS.CsIratHo Dropped PS RAB connections due
to successful CS IRAT HO.

Table 36: PM Counters for RAB Drops

UMTS Operational Network Engineering (For Internal Use Only) Page 48 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

6.3. 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
cause ”unspecified” or “pre-emptive release”12
• 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). 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
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 2. 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 iRM CAC (subsection 5.4.1) or Congestion Control
(subsection 6.5).
ALU supports the RRC connection re-establishment for PS, CS and simbearer
services, where by on detection of the RLF or RLC error, the UE sends a cell
update with corresponding cause 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. Further information on activation, configuration and monitioring of
this feature set can be obtained from 2.

Parameter Description
RadioAccessService Activation flag for PS call re-
establishment feature
.isPsRrcReestablishAllowed
RadioAccessService Activation flag for CS call re-
establishment feature
.isCSRrcReestablishAllowed
RadioAccessService Activation flag for PS call re-
establishment for invalid configuration
.isPSRrcReestablishforICFailureAllowed failure scenario while doing UL data rate
change for HSDPA call

RadioAccessService Timer started at RNC on reception of

NBAP RLF for a CS call, if no cell update
.rrcReestCSMaxAllowedTimer from UE received within this time, call is
dropped

12
The case RRCConnectionRelease with cause “congestion” is covered in subsection 5.4.1.

UMTS Operational Network Engineering (For Internal Use Only) Page 49 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

RadioAccessService Timer started at RNC on reception of

NBAP RLF for a PS call, if no cell update
. rrcReestPSMaxAllowedTimer from UE received within this time, call is
dropped

RadioAccessService Quality threshold for deciding if PS re-

establishment should take place based
.rrcReestablishPSThreshold on EcNo reported by UE in cell update

RadioAccessService Quality threshold for deciding if CS re-

establishment should take place based
.rrcReestablishCSThreshold on EcNo reported by UE in cell update

Table 37: Parameter configuring the RRC connection re-establishment

UE Node B RNC CN

RNC suspends 1) Cell Update (Cause Radio Link Failure)

RL C, MAC
2) Radio Link Deletion Request
3) Radio Link Deletion Response

4) ALCAP Release

New radio links 5) Radio Link Setup

based upon
measured Ec/I o 6) Radio Link Setup Response

UE Moved back 7) ALCAP & FP Synch

to Cell DCH
8) Cell Update Confirm
9) Radio Bearer Reconfiguration Complete

10) UE Measurements

Figure 14: DL RLF and RRC re-establishment

UE Node B RNC CN

T_RL_RESYNCH
expires, UE is PS 1) Radio Link Failure Indication
only

2) Radio Link Deletion Request T_RL_RESYNCH

RNC suspends
RL C & MAC, 3) Radio Link Deletion Response
Starts Timer
4) ALCAP Release

RNC stops
Timer
5) Cell Update (Cause Radio Link Failure)

New radio links 6) Radio Link Setup

based upon
measured Ec/I o 7) Radio Link Setup Response

UE Moved back 8) ALCAP & FP Synch

to Cell DCH
9) Cell Update Confirm
10) Radio Bearer Reconfiguration Complete

UMTS Operational Network Engineering (For Internal Use Only) Page 50 of 108
11) UE Measurements
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 15: UL RLF and RRC re-establishment

6.3.2.Failure symptoms, identification and fixes for improvement

Table 38 and Table 39 below list the identification of dropped RRC connection
and the corresponding PM KPIs respectively:

Problem Trace Trigger

Drop of RRC Uu Any occurrence of a RRC Connection Release message on Uu with specified
connection I cause ”unspecified” or “pre-emptive release”
Drop of RRC Uu Any occurrence of a RRC Connection Request message on Uu with
connection II establishment cause “Call re-establishment”
Drop of RRC Uu The UE is simply going to idle mode without dropping the call in a regular way.
connection III 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 33 on page 45).
Drop of RRC Uu RNC sent a ‘Cell update confirm’ but the UE didn’t respond back with a ‘RB
connection IV reconfiguration complete’ within x seconds showing failure of the re-
establishment

Table 38: Identification of dropped RRC connections in interface traces

PM Counter / KPI KPI Name / Description

system
UtranCell (VS.RrcReEstablishmentSuccess.<sum> / RRC Connection Re-establishment
VS.RrcReEstablishmentAttempt.<sum>) success rate
UtranCell VS.RrcConnectionRelease.ReestablishmentReject Number of RRC connection release
when re-establishment was not
successful or when RNC receiving
the cell update is drift
UtranCell VS.RrcReEstablishmentAttempt.PS_Other Number of attempts for RRC
connection re-establishment

UMTS Operational Network Engineering (For Internal Use Only) Page 51 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

VS.RrcReEstablishmentAttempt.PSULRLFail procedure for different re-

establishment types.
VS.RrcReEstablishmentAttempt.PSDLRLFail
VS.RrcReEstablishmentAttempt.PSULRlcUnrecoverErr
VS.RrcReEstablishmentAttempt.PSDLRlcUnrecoverErr
VS.RrcReEstablishmentAttempt.PSInvCfgFail
VS.RrcReEstablishmentAttempt.CS_Other
VS.RrcReEstablishmentAttempt.CSULRLFail
VS.RrcReEstablishmentAttempt.CSDLRLFail
UtranCell VS.RrcReEstablishmentSuccess.PS_Other Number of successes for RRC
connection re-establishment
VS.RrcReEstablishmentSuccess.PSULRLFail procedure for different re-
VS.RrcReEstablishmentSuccess.PSDLRLFail establishment types.

VS.RrcReEstablishmentSuccess.PSULRlcUnrecoverErr
VS.RrcReEstablishmentSuccess.PSDLRlcUnrecoverErr
VS.RrcReEstablishmentSuccess.PSInvCfgFail
VS.RrcReEstablishmentSuccess.CS_Other
VS.RrcReEstablishmentSuccess.CSULRLFail
VS.RrcReEstablishmentSuccess.CSDLRLFail

Table 39: PM KPIs of RRC connection Re-establishment

6.4. Call reliability – RF planning related issues

6.4.1. Introduction
A detailed explanation of how to improve the RF environment is outside the
scope of this document. 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 previous sections 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 RL 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 by acting as interference.
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. Failure symptoms, identification and fixes for improvement

This is a typical issue for RF optimisation and can be detected via Uu interface
traces and 2G/3G scanner measurements of the PHY layer. In addition the

UMTS Operational Network Engineering (For Internal Use Only) Page 52 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

number of cells in the active set is also a good metric of handover zone
definition within the UMTS network.
Table 40 is listing identification techniques in drive test and scanner
measurement data while gives a way to identify areas with multiple pilot overlap
at sector level:

Problem Trace Trigger

Pilot pollution I UE or 3G There are more than x cells with a measured Ec/No within x dB compared to
scanner the best measured Ec/No
Pilot pollution II UE or 3G The aggregate Ec/No of the cells in the active set is below x dB while the
scanner measured RSCP is above y dBm for z ms
High number of Uu The active set size is > 1 in more than x % of all measured samples13
cells in active set
Overshooting UE or 3G Ec/No of a site y km away is within x dB of the best measured Ec/No
cells scanner

Table 40: Identification of pilot pollution

PM Counter / KPI KPI Name / Description

system
UtranCell VS. UeWithNRadioLinksEstCellsBts.<causes> Distribution of the number of
mobiles having N Radio-Links
in their Active Set
UtranCell (( ( VS.UeWithNRadioLinksEstCellsBts.N1Rl * 1 ) Average active set size
+ ( ( VS.UeWithNRadioLinksEstCellsBts.N2RL1Rc1SBts +
VS.UeWithNRadioLinksEstCellsBts.N2RL1Rc1ABts ) * 2 )
+ ( ( VS.UeWithNRadioLinksEstCellsBts.N3RL1Rc2SBts +
VS.UeWithNRadioLinksEstCellsBts.N3RL1Rc1SBts1ABts +
VS.UeWithNRadioLinksEstCellsBts.N3RL1Rc2ABts ) * 3 )
+ ( ( VS.UeWithNRadioLinksEstCellsBts.N4RL1Rc2SBts1ABts +
VS.UeWithNRadioLinksEstCellsBts.N4RL1Rc1SBts2ABts +
VS.UeWithNRadioLinksEstCellsBts.N4RL1Rc3ABts ) * 4 )
+ ( ( VS.UeWithNRadioLinksEstCellsBts.N5RL1Rc2SBts2ABts +
VS.UeWithNRadioLinksEstCellsBts.N5RL1Rc1SBts3ABts +
VS.UeWithNRadioLinksEstCellsBts.N5RL1Rc4ABts ) * 5 )+
( (VS.UeWithNRadioLinksEstCellsBts.N6RL1Rc2SBts3ABts +
VS.UeWithNRadioLinksEstCellsBts.N6RL1Rc1SBts4ABts +
VS.UeWithNRadioLinksEstCellsBts.N6RL1Rc5ABts ) * 6 ) )
/
VS.UeWithNRadioLinksEstCellsBts.<sum>)

Table 41: PM Counter for estimation of soft handover zone

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

13
This is not really a problem to be identified in a trace; it is more an indication for in general non-
optimal RF conditions.

UMTS Operational Network Engineering (For Internal Use Only) Page 53 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

cells in the active set decreases dramatically (in terms of Ec/No and RSCP) and
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).
If a drop does happen, provided it’s not over the Iur, RRC connection re-
establishment feature will be able to recover the call.

6.4.3.2. Failure symptoms, identification and fixes for improvement

Around-the-corner effect can be detected via UE traces when analyzing the
PHY layer; Table 42 is summarising the triggers in UE traces:

Problem Trace Trigger

Around-the-corner Uu Sudden drop/increase of the Ec/No of cells in the active set by x dB for the
effect I next at least y ms; the average aggregate Ec/No is below z dB
Around-the-corner Uu Sudden drop/increase of the RSCP of cells in the active set by x dB for the
effect II next at least y ms; the average aggregate RSCP is below z dBm

Table 42: Identification of around-the-corner effect

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 OAM:

UMTS Operational Network Engineering (For Internal Use Only) Page 54 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• 3G-3G soft/softer MAHO list

• 3G-2G neighbour MAHO list
• 3G-2G neighbour DAHO/blind HO list
• 2G-3G neighbour list
The parameters configuring the intra-frequency soft/softer HO are listed in
subsection 6.9, 2G 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)
o Sector id (to check if a 2G cell is identical resulting in identical
coverage footprint for a possible DAHO/ blind HO definition)
o Userlabel
o Flag borderCellToGSM
• Table keeping site specific information of the GSM cells
o Site id (for identification for co-located 2G/3G cells)
o Sector id (to check if a 3G cell is identical resulting in identical
coverage footprint for a possible DAHO/ blind HO definition)
o BCCH frequency
• Different neighbour lists including
o Priority flag for 3G-3G HO definition in case Type 1 is the
selected NL selection algorithm (see also subsection 6.9 for
details)
o 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, 2G-
3G)
• Check for right Priority flag
• Check for missing DAHO/ blind HO definitions
Figure 17 below is showing a sample database in MS Access format:

UMTS Operational Network Engineering (For Internal Use Only) Page 55 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 17: neighbour list checking using MS Access

RF drive data analysis tools like LDAT 2 have the missing neighbour list
analysis feature that can be used to debug existing network as well as suggest
NL for technology overlay deployment based on GSM HO matrix:

Figure 18: 3G/IFHHO neighbour list visualisation using LDAT

UMTS Operational Network Engineering (For Internal Use Only) Page 56 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

6.4.4.2. Failure symptoms, identification and fixes for improvement

Following methods can be used to fix/detect a non-optimal neighbour list
assignment:
• Cross-correlation of Uu drive test logs with 2G/3G scanner
measurements
o Missing 3G-3G neighbour definition: measured RSSI is
relatively high, but the RSCP of the cells in the active set is
relatively low
o Missing 3G-2G neighbour definition: the UE measured RSSI is
relatively low and the GSM coverage footprint is relatively strong
as measured by the 2G scanner.
o 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
o Analysis of the UE Measurement Reports: the UE might report
cells of the detected set but these cells are not defined in the
Compund NLA (see also subsection 6.9)
• RF prediction tool analysis like LDAT3G
• CTn traces 2 which specifically capture 3G-3G and 3G-2G mobility
data. For example from these IRAT HO Matrix can be derived and
analysed using WQA tool 2 with the focus on
o Deletion of unnecessary handover definitions
o Investigation of high amount of HO failures
In a similar way the intra-frequency HO matrix can be derived and analysed
using CTn and WQA for discovering possible missing neighbor list entries or
over-shooting sectors.
Table 43 below is listing the identification possibilities for network interface
traces:

Problem Trace Trigger

Missing 3G/3G Uu, 3G Any occurrence where the measured RSSI (retrieved by 3G scanner) is
neighbour definition scanner 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 The measured RXLEV of the best 2G cell (measured by the 2G scanner) is
neighbour definition scanner 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 Any occurrence where the measured RSSI (retrieved by 3G scanner) is
neighbour definition scanner 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

UMTS Operational Network Engineering (For Internal Use Only) Page 57 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 Tx
code power in the DL when using a PS R99 data service (subsection 6.17.1) or
a HHO handover towards 3G or 2G cell has to be triggered to rescue the call
using iMCTA Alarm mechanism.
In subsection 6.7.1 a drop of the RRC is described for a mobile in CELL_FACH
mode. In subsection 6.6 a similar scenario is described for a UE in
CELL_PCH/URA_PCH mode.

6.4.5.2. Failure symptoms, identification and fixes for improvement

Low RF coverage can be identified as follows:
• Low receive level in terms of RSSI (means low measured RSCP values
for all pilots in the active set)
• 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 Alarm data (see also subsection 6.8). Table 44 below is
listing identification triggers for low RF coverage in various traces:

Problem Trace Trigger

Low RF 3G scanner Measured RSSI of the 3G cells is below x dBm for y seconds
coverage I or Uu
Low RF 3G scanner, Measured aggregate RSCP of the cells in the active set is below x dBm for y
coverage II Uu 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, CT The reported NodeB TX power is for x second above y dBm and the measured
coverage III RSCP of that NodeB is below z dBm
Low Ec/No Uu Measured aggregate Ec/No of the cells in the active set is below x dB for y
seconds

Table 44: Identification of low RF coverage in network interface traces

ALU PM System does allow the monitoring of Ec/Io, RSCP and CQI values
reported by the UE. Knowing the cell selection criteria (UPUG default Qqualmin
= -16dB and Qrxlevmin = -115dBm) and design coverage probability of the 3G
network one can roughly estimate if coverage hole exist at sector level.

PM Counter / KPI KPI Name / Description

system
UtranCell VS.IrmcacDistributionEcNO.<screenings> Ec/No distribution
UtranCell VS. IrmcacDistributionRscp.<screenings> RSCP distribution
UtranCell VS. HsdpaReceivedCQI.<screenings> CQI distribution

Table 45: Ec/Io and CQI distribution counters

UMTS Operational Network Engineering (For Internal Use Only) Page 58 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.
In case proper rules are not followed, the UE may experience 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). WQA should permit to
detect PSC duplication using CTn traces.
The following counters can also be used to detect cells that may contain
ambiguous PSC entries after neighbor list compounding. For intra-frequency
neighbors the PSC entries must be unique, while for inter-Freq enteries the
ARFCN and PSC combination should be unique, and this may be the case for
first teir neighbors. However this may not be the case when neighbor list
compounding is used, as several neighbor lists will be combined to create the
final neighbor list.

PM Counter/KPI KPI Name / Description

system
UtranCell VS.AggregateCellListAmbiguousCellIntraFreq The aggregate intra-frequency
neighbour list contains an
ambiguous cell.
UtranCell VS.AggrCellListAmbigCellInterFreq The aggregate inter-frequency
neighbour list contains an
ambiguous cell.

Table 46: Count of NL sent with at least one ambiguous cell at RRC

6.5. Call reliability – Congestion Control

6.5.1. Concept
The Congestion Control function is used to handle situations when the system
is going into overload or getting close to an overload situation. Congestion
Control is based on UL and DL load estimations as reported by a change in
downlink cell congestion colour or uplink cell congestion colour from 'normal' to
'congested'. It handles user already in connected mode and is activated by
RadioAccessService.isCongestionDowngradeAllowed.
The RNC can initiate the following actions for already connected users to
resolve the overload situation:
• Rank the PS R99 users according to their preemptionVulnerability
(taken either from ARP IE in RAB request or from OAM object
PreemptionOmcrPcPvInfo ) depending upon preemptionMode,
PreemptionServiceInfo.preemptionPriorityOfService and gain from
downgrade

UMTS Operational Network Engineering (For Internal Use Only) Page 59 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• Transit IrmPreemptionCacParams.numUsersDowngrade out of top

ranked users connected to PS data services to a lower bit rate (e.g.
from 384 kbit/s to 128 kbit/s)
• Transfer of rest of PS data users to another state e.g. from CELL_DCH
to CELL_FACH or idle depending upon the setting for
RadioAccessService.congestionDowngradeReleaseTarget if initial
data rate is 8k/8k
The lowering of the PS data rate is done by using the RB 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, RAB is set to inactive); in both cases the PDP context is
retained.
The initiating of Congestion Control is indicating a high interference in the RF
environment.

6.5.2. Failure symptoms, identification and fixes for improvement

Table 47 is listing the identification techniques in traces in case of Congestion
control, relevant PM KPIs are also listed below in Table 48:

Problem Trace Trigger

Congestion Uu, TCP/IP trace Cross-correlation of interface traces on Uu and TCP/ in or after CN
Control RRC PS in or after CN side: Any occurrence when either the PS data rate is reduced or the
data reduction DL 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 Wireshark

Table 47: Identification of Congestion Control in interface traces

PM Counter / KPI KPI Name / Description

system
UtranCell VS.DataRateAtt.Dec.CongDowngrade.DL Number of attempts to
downgrade data rate due to
VS.DataRateAtt.Dec.CongDowngrade.UL congestion
UtranCell VS.IrmPreemptionTimeCellColorCongested Percentage of time Cell color
congested in DL
UtranCell VS.IrmPreemptionTimeCellColorCongestedBecauseOfOvsfCodes Percentage of time Cell color
congested in DL due to power,
VS.IrmPreemptionTimeCellColorCongestedBecauseOfPower code, CEM or Iub transport
VS.QosDlCemLdCellPreemptClrCngstd
VS.IrmPreemptionTimeDlIubTransportCongested

Table 48: PM KPIs identifying congestion control activation

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 S-
CCPCH 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

UMTS Operational Network Engineering (For Internal Use Only) Page 60 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

always a RAB associated with the RRC connection but the RAB is marked
(inside the RNC) as inactive. When there is data received from the CN side, the
RLC buffer in the RNC belonging to the RAB is queues the data and the RNC
initiates 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 might indicate to the RNC if the UE RLC buffer is filled up rapidly by
sending cell update with cause ‘Uplink data transmission’ on RACH. ALU
UTRAN initiates a state transition to Cell_FACH by sending back a cell update
confirm.
According to 2 the UE has to monitor the PICH and PCH, do periodical
URA/PCH updates and perform cell reselections while being in URA_PCH or
Cell_PCH state. It might be that URA_PCH/CELL_PCH mode is not used.
Instead for a PS call when the inactivity timer T1 elapses, 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 to the idle mode
is that the re-establishment can be done faster because the RAB and RRC
connection does not need to be re-established again. Disadvantage is that there
are still some (very low) UTRAN resources that the RNC has to maintain. Figure
19 below is showing the transition phases between different UE states:

Figure 19: Transition phases between the different UE states

6.6.2. Failure symptoms, identification and fixes for improvement

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 updates (subsection 5.3.1).
For Call admission (iRM CAC) 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 as described in subsection 5.1.2. In this case the RAB will be
removed.
If RNC traces show that cell update was sent in good RF (better than -10dB) but
UE repeatedly didn’t respond to cell update confirm, this can either be a UE or

UMTS Operational Network Engineering (For Internal Use Only) Page 61 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

an RNC bug. It probably causes the UE to ignore the cell update confirm, so
after sending cell update five times the UE drops this call and establishes a new
PS call. This results in CN sending Iu release command for the old call to the
RNC. Following table shows the PM counters useful in monitoring the
URA_PCH transitions and success rate

PM Counter / KPI KPI Name / Description

system
UtranCell VS.UEStateTransAtt.UraPCH.CellDCH Attempts and Successes UE state
transitions to move a UE from URA
VS.UEStateTransSucc.UraPCH.CellDCH PCH to Cell DCH.
UtranCell VS.UEStateTransAtt.UraPCH_CellDCH.DCH_HSDSCH Attempted and succesful
reconfigurations for transitions from
VS.UEStateTransFail.UraPCH_CellDCH.DCH_HSDSCH URA_PCH to Cell_DCH with an HS-
DSCH.

Table 49: PM Counters for URA_PCH Transitions

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 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 dedicated 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).
According to 2 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 19
is showing the different UE states and possible transition between them. In all
cases the RNC will initiate the transition by using the RB Reconfiguration 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).
The algorithm to transition to/from CELL_FACH takes into account the data
activity which is measured over fixed time windows. RNC only decides to send
the UE to CELL_FACH once both UL and DL data transmission falls below a
threshold for a T1 time period.
Figure 20 and Figure 21 below are visualising the call handling for the transition
from CELL_DCH to CELL_FACH and vice versa:

UMTS Operational Network Engineering (For Internal Use Only) Page 62 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 20: Call handling for transition from CELL_DCH to CELL_FACH

Figure 21: Call handling for transition from CELL_FACH to CELL_DCH

UMTS Operational Network Engineering (For Internal Use Only) Page 63 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 22: Parameters govering various UE states controlled through AO

The RNC may decide to release the RRC connection due to extended data
inactivity especially if URA_PCH is disabled. 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 on Iu with cause: ‘user-inactivity’.

6.7.2. Failure symptoms, identification and fixes for improvement

A drop of the RRC connection might occur if the UE is leaving the RF coverage
area and upon selecting a cell the UE has to inform the UTRAN by sending a
Cell Update message with cause “Re-enter service area”. This happens when
the UE can’t find a suitable cell to camp on for at least 4 seconds. In the
meantime the UTRAN might already have dropped the RRC if it had tried and
failed to send PS data in the DL.
It is recommended to make SRB and TRB in FACH/RACH robust by making the
RLC timers long, so to avoid call drop in case of short disruption in data
transfer. Since FACH is a slow channel and there is no dedicated link so it can
also suffer from contention between different users. As a rule of thumb the RLC
UL/DL timeout should be >15 sec for TRB_FACH/RACH and greater than
timeout for DCCH_3.4k for SRB_FACH/RACH.
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 procedure on RRC
(subsection 6.17.1)

UMTS Operational Network Engineering (For Internal Use Only) Page 64 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Table 50 is listing failures for UEs in CELL_FACH mode and how to identify it in
traces:

Problem Trace Trigger

Dropped call in Uu Any occurrence when the RRC connection dropped while the UE was in
CELL_FACH CELL_FACH state

Table 50: Failure identification in traces if the UE is in CELL_FACH mode

There are a lot of PM counters available counting the number of attempts and
failures for the state transitions, see 2 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.

6.8.2. Failure symptoms, identification and fixes for improvement

Outages can be easily identified when tracing the interfaces that have been out-
of-sync. Table 51 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 a Reset on RANAP

Table 51: Identification of outages in network interface traces

Transport engineering guidelines 2 may also have useful information about

transport outage.

6.9. Call reliability – intra frequency soft/er handover

6.9.1. Concept
Within UMTS networks intra-frequency soft/softer handover is one basic feature
that ensures seamless mobility as well as call performance and quality
improvement.
The soft/softer handovers requested by the UE (mobile evaluated HO) are the
ones supported by ALU RNC. In addition the reporting criteria are set to “event

UMTS Operational Network Engineering (For Internal Use Only) Page 65 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

triggered” rather than “periodically”. All intra-frequency measurement reporting

events (1a to 1j) are defined in 2.
According to 2 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)
• SHO decision
• 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.2)
• 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 RRM parameters. As an
example Figure 23 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 23: HO parameter for event 1a, 1b and 1c

The call handling depends on the type of event; as an example Figure 24 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):

UMTS Operational Network Engineering (For Internal Use Only) Page 66 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 24: Call handling flowchart of Active Set Update event 1a (event
1c)

6.9.2. Failure symptoms, identification and fixes for improvement

There are many different reasons why the HO procedure might fail or not be
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 non-
optimal neighbour definitions, pilot pollution, weak PSC plan etc. (see
subsection 6.4 for details)
• Misconfiguration of UTRAN parameter setting up the filtering, timing
and SHO 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.2
• Failures during the release of network resources on NBAP (e.g. event
1c); these failures should occur very rarely (subsection 6.17.3)

UMTS Operational Network Engineering (For Internal Use Only) Page 67 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• Measurement Control Failure message (e.g. 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
o Incompatible simultaneous reconfiguration
o Invalid Active Set Update message
o UE in non Cell_DCH state to receive that message
o Protocol error
o Physical channel error

The filtering, timing and SHO algorithm are configurable by UTRAN parameters.
Especially in dense urban environment these parameter have to be optimised
e.g. to react faster to the around-the-corner effect or in areas with weak
coverage (in 3G border areas) to trigger the 3G-2G HO quickly.
Table 52 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). As a general point LDAT3G allows delay between two RRC
messages to be quantified using the “UDR Time difference” option under
“Report” Menu.
Long handover delays can result in dropped calls and in a decrease of the
overall UMTS RF conditions. ALU RNC does have blocking phases that means
that an on-going procedure like RB Reconfiguration may cause the SHO to be
blocked. Enabling the RadioAccessService.shoAfterBlockingPhaseEnable
will ensure that all received reports are queued for processing once blocking
ends.

Problem Trace Trigger

Intra Frequency Handover Uu Any occurrence where the UE sends a Measurement Report 1x
Delay 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 Uu Any occurrence where the RNC is not sending the Measurement
Control message after Active Control message within y seconds after the UE has sent the Active
Set Update Complete for event Set Update Complete message and the event ID of the last
1x 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 There is one (or more) intra-frequency cell measured by the 3G
scanner 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

14
In case of e.g. periodic reporting an update via Measurement Control message is not required

UMTS Operational Network Engineering (For Internal Use Only) Page 68 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Measurement Control Failure Uu Any occurrence where the UE is sending an Measurement Control
Failure message

Table 52: Identification handover issues in traces

PM KPIs related to the intra-frequency handover process are available in 2.

6.10. Call reliability – IRAT handover

6.10.1. Concept (UMTS->GSM)
IRAT handover are used to maintain UMTS voice call in case 3G coverage
(RSCP) and/or quality (Ec/No) is not sufficient and trigger iMCTA Alarm.
Furthermore they can be used for traffic distribution from loaded sites (iMCTA
Service) or initiated after a call is rejected by CAC (iMCTA CAC). IRAT
handovers are always hard handovers and mobile assisted in ALU RNC.
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 compressed mode (CM) activation Report Event 2d to the RNC
and after receiving the RRC measurement control message from the UTRAN
activates the pre-configured compressed mode pattern to start the IRAT
measurements as specified in the message. When the measured Ec/No or
RSCP of the cells in the active set exceeds a specific threshold the UE sends a
Measurement Report Event 2f. RNC allows the current CM pattern to proceed
till expiry but doesn’t setup a new CM.
While in compressed mode, the UE sends periodic Measurement Report every
0.5sec with the measured level on the GSM/GPRS neighbour cells. The
UTRAN might decide to trigger the IRAT handover by sending the “Handover
From Utran command” on RRC if the reported level exceeds a predefined
threshold RadioAccessService.minimumGsmRssiValueForHO. Figure 25
below shows the call flow chart across the UMTS and GSM network for
performing UMTS to GSM CS voice handover including the 3G and 2G CN:

UMTS Operational Network Engineering (For Internal Use Only) Page 69 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Phases

Figure 25: Flow chart of successful UMTS to GSM voice handover

6.10.2. Failure symptoms, identification and fixes for improvement

(UMTS->GSM)
UMTS to GSM Handover failure may occur during one of the phases as
following:
• Relocation procedure failures (subsection 6.17.2/phase 1 in figure)
• Handover procedure failures in GSM network (phase 2 in figure)
• Release procedure failures (subsection 6.17.3/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
the UE. If the UE fails to complete the requested handover then SRNC receives
a “Handover From UTRAN Command Failure” message from the UE. According
to 2 the failure causes specified within this message can be subdivided as
follows:
• Physical channel failure
• Unacceptable configuration
• Protocol error
The first cause refers to the case when there is loss of synchronisation between
UE and 2G-NodeB. This is mainly caused by poor RF conditions, especially if
the coverage of the co-located 2G site/neighbour is not as good as that for 3G
network or if UE reported 2G neighbor’s BSIC is ambiguis and CN prepared a
different 2G NodeB. This problem can also occur due to incorrect provisioning
in 2G network. The last 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 2.
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

UMTS Operational Network Engineering (For Internal Use Only) Page 70 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

conditions. However this may increase the proportion of CS calls going over to
2G, which may be against customer expectations.
Table 53 below is listing the identification triggers for IRAT HO problems in
traces:
Problem Trace Trigger
Delayed IRAT HO Uu Any occurrence of a periodic Measurement Report sent by the UE, but there is
after UE report no Handover From UTRAN Command within x seconds
Handover From Uu Any occurrence of a Handover From UTRAN Command Failure message sent
UTRAN by the UE
Command Failure
RRC drop in Uu Any occurrence of a drop of the RRC connection when the UE was in
compressed compressed mode
mode

Table 53: Identification of IRAT HO problems in traces

PM Counter / KPI KPI Name / Description

system
UtranCell (IRATHO.SuccOutCS.<sum> / IRATHO.AttRelocPrepOutCS) Outgoing CS Inter RAT handover
success rate (UMTS->GSM)
UtranCell VS.AggrCellListAmbigCellInterRAT The aggregate inter-RAT neighbour
list contains an ambiguous cell

Table 54: PM KPI for outgoing CS IRAT success rate

For counters dealing with preparation phase during IRAT-HO, refer to section
6.17.2.

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
RadioAccessService.is2gto3gCSHandoverAllowedWithinRNC is used to
ensure that RNC will accept the incoming relocation procedure involving SCCP
connection initiated by the CN.

UMTS Operational Network Engineering (For Internal Use Only) Page 71 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 26: 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.
• 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
PM KPIs related to the IRAT Handover process are detailed in 2 with some
example shown below:

PM Counter / KPI KPI Name / Description

system
UtranCell ((VS.IuRelocationRequests.Cs2Gto3GRelocation - Incoming CS Inter RAT handover
VS.IuRelocationRequestFailuresCs.2Gto3G.<sum>) / success rate (GSM->UMTS)
VS.IuRelocationRequests.Cs2Gto3GRelocation)

Table 55: PM KPI for incoming CS IRAT success rate

UMTS Operational Network Engineering (For Internal Use Only) Page 72 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 mode.
PS inter-system/RAT handover can be initiated due to reasons that are similar
to the ones for the CS inter-system handover (subsection 6.10). Furthemore, a
two-step approach to first measure BCCH/RXLEV of the neighbouring GSM
cells and then the BSIC is specified by ALU RNC in the Measurement Control
message which sets the compressed mode patterns. However BSIC
confirmation is not normally used as it substantially increases the UE
measurement time.
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 “Cell Change Order from
UTRAN” message. In the UE, timer T309 supervises this procedure.

Figure 27: Flow chart of successful UMTS to GSM PS handover

The SRNS context transfer procedure is not fully supported by the ALU source
RNC (i.e. the messaging is supported but the PDU counters are not
transferred). Furthermore data forwarding is also not supported by the ALU
SRNC. Therefore, some packets will be lost during the handover. End-to-end
reliability is supposed to be provided by end-to-end transport layer (e.g. TCP).

6.11.2. Failure symptoms, identification and fixes for improvement

In case the UE cannot successfully complete the procedure and T309 expires,
the UE will

UMTS Operational Network Engineering (For Internal Use Only) Page 73 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• Re-establish the UTRAN 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 "Inter-RAT
change failure" to "physical channel failure"
• OR when not successful in re-establishing the UTRA channels, perform
a cell update procedure with cause "Radio link failure"
Table 56 below is listing the parameter for the cell change order from UTRAN
procedure:

Parameter Description
UeTimerCstConnectedMode. Timer starts upon reception of CELL CHANGE ORDER FROM UTRAN
message, and stops when a successful establishment is made in the new 2G
t309 cell.

Table 56: Parameter used for configuring the cell change order from
UTRAN
Table 57 below is listing the identification in interface traces possibilities for the
cell change order from UTRAN procedure:

Problem Trace Trigger

Cell Change Order from UTRAN I Uu Any occurrence of the RRC message
CellChangeOrderFromUTRANFailure
Cell Change Order from UTRAN II Uu Any occurrence of the RRC message
CellChangeOrderFromUTRAN and within x seconds there is a
cell update message with cause "Radio link failure"

Table 57: Identification of cell change order from UTRAN failures in traces

PM KPIs related to the process are available in 2 with an example below.

PM Counter / KPI KPI Name / Description

system
UtranCell (IRATHO.SuccOutPSUTRAN.<sum> / Outgoing PS CCO success rate
VS.RrcCellChgOrderUtranCmd.<sum>) (UMTS->GSM)

Table 58: PM KPI for outgoing PS CCO success rate

6.12. Call reliability – inter frequency handover

6.12.1. Concept
In UMTS networks inter-frequency hard handover is a feature that ensures
seamless mobility between frequency carriers in same or different spectrum
bands on same or different RNC.
In ALU UTRAN, hard handovers can be triggered by the degrading quality of
the current frequency or if a newly setup signalling call experiences CAC failure
while setting up the traffic RB or to offload an on-going call if the primary or best
cell is congested. All inter-frequency measurement-reporting events (2a to 2f)
are defined in 2.
According to 2 this procedure consists of the following steps:

UMTS Operational Network Engineering (For Internal Use Only) Page 74 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• 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.2)
DAHO (or blind) 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 RB
reconfiguration message is used to performe this HHO.

6.12.2. Failure symptoms, identification and fixes for improvement

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:

• Target 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).

• The UE may not be able to perform the new configuration and returns a
Radio Bearer Reconfiguration Failure. The newly allocated resources on the
target cell are released by means of the NBAP Radio Link Deletion
procedure by the RNC. The call continues on the current configuration.

• If the Inter-Frequency Handover Timer

Imcta.measurementGuardTimerFdd expires and no neighbouring cell is
found to be suitable candidate for HHO (no inter-frequency cell has been
reported or the reported cells are not found to be elligible). Then
Compressed Mode is reactivated if Event 2f for same quantity (i.e EcNo or
RSCP) has not been received which triggered the measurements in the first
place in the form of Event 2d, i.e. trigger was Alarm. However, UE remains
on the original frequency if trigger was due to CAC or Service without
invoking CM again.

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. Table 59 shows some failures that can be identified using
network traces

Problem Trace Trigger

Inter Frequency HO Delay Uu Any occurrence where the UE sends a inter-frequency
Measurement Report and the RNC does not reply with RB
Reconfiguration message immediately
Dropped call during IF HHO Uu and RNC sends a RB Reconfiguration message but the UE does not
CT respond back with either complete or failure message within
RNC static timer T361. This will be followed by RNC initiaiting Iu
release procedure with cause Unspecified.

Table 59: Identification of inter Freq HO failures from traces UTRAN

Some important KPIs/Counters pegged during this process are given below:

UMTS Operational Network Engineering (For Internal Use Only) Page 75 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

PM Counter / KPI KPI Name / Description

system
UtranCell (HHO.SuccOutInterFreq / HHO.AttOutInterFreq) Inter-frequency hard handover
success rate - Outgoing
UtranCell (VS.IncomInterFreqHoSuc.<trigger>15 / Inter-frequency hard handover
VS.IncomInterFreqHoAtt.<trigger>) success rate - Incoming

Table 60: PM KPI - Inter-Freq HHO success rate

6.13. Call reliability – failures on the Transport Network

The underlying transport network on the Iub and Iu interface is mostly ATM. On
the Iub interface AAL2 and AAL5 are used, and 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. But it
would be advisable to check for any VCC Alarms that may have occurred on the
NodeB (identified by the PSC of its sector) where the drop occurred and there is
no other possible explanation like bad RF, RLC error etc.
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 2. A detailed description of
the ALU implementation is available in 2. RLC is a sublayer in layer 2 of UMTS
protocol stack. 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
changing 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
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

15
Triggers include Rescue (Alarm due to 2d/2f), Service (due to Red cell colour) and
NoRsrcAvailCacFailure (no resources available)

UMTS Operational Network Engineering (For Internal Use Only) Page 76 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

o No protocol overhead added; transparent to the RLC

o 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
o Segmentation, concatenation and padding into RLC PDUs. Each
PDU is transferred as one physical layer TB.
o Reassembly of PHY data from TB into RLC PDUs and RLC SDUs
o Used for fast signalling (e.g. SRB1 on DCCH)
• AM data transfer
o UM data transfer features plus
o Error control feedback, retransmission of erroneous or lost PDUs
and in sequence delivery of RLC PDUs by ARQ
o 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 28 below is showing the UMTS protocol stack of the user plane for a
TCP/IP data application:

Figure 28: UMTS protocol stack of the userplane for a TCP/IP application
TCP has its own flow control and ARQ algorithms so the OAM 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.

UMTS Operational Network Engineering (For Internal Use Only) Page 77 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

A RLC PDU for PS RB has a size of 42 bytes 16 (40 byte payload and 2 byte
header), which is relatively small compared to a TCP/IP packet size of around
1000 byte17. 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’ed 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 by setting a poll bit
in the RLC-PDU header forcing the acknowledgement of previous PDU
by the RX
• 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
o If data PDU retransmission did not succeed, go either to SDU
discard or RLC reset of the RLC connection between the two entities
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)

16
Size of signaling SRB is 16 bytes plus 2 bytes header
17
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

UMTS Operational Network Engineering (For Internal Use Only) Page 78 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Parameters configuring the RLC are available in 2 along with features that can
improve RLC performance.
Reason for problems on the RLC might be due to
• RF related issues like pilot pollution, incorrect neighbouring definitions
• Lower layer problems on the Iub, ATM cell discarding occurs causing
the packets to be lost
• Forced decrease of the data rate due to congestion control resulting in
SDU discarding in RNC
• UE or RNC software bugs where the behaviour does not follow 3GPP
standard

6.14.2. Failure symptoms, identification and fixes for improvement

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.
However, CTg or CTb with RLC information can also be used in this
investigation especially if explicit Iub tracing is not possible or allowed.
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). However these limitations don’t apply to CT tracing feature as
RNC recorded each call separately.
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 First SN
(number of octets determined by LENGTH) 2.
A dropped (CS or PS) call due to a RLC error can be easily identified by a Cell
Update message in UE log with cell update cause “RLC unrecoverable error”.
Note that an RLC error in the SRB2-4 (represented by cell update IE “AM_RLC
error indication = True for RB2-4) cannot be reconnected for CS voice and
always results in drop call as per 3GPP 2.
The SDU discard function removes the RLC PDU from the buffer on the
transmitter side, when the transmission of the RLC PDU does not succeed for a
long time. Hence it 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 61 is listing problems that can be detected in interface traces and Table
62 the corresponding KPIs in the PM system:

Problem Trace Trigger

RLC Resets Iub Any occurrence of RLC Resets in Iub traces
RLC retransmission Iub Any occurrence of retransmission of RLC PDUs per RLC session
SDU discard with Iub Any occurrence of a Move Receiving Window (MRW) command indicating a
explicit signalling SDU discard and/or a MRW-ACK
Dropped call due to Uu Any occurrence of a RRC Cell Update message with specified cell update
RLC error cause (not failure cause) “RLC unrecoverable error”. The IE AM_RLC error

UMTS Operational Network Engineering (For Internal Use Only) Page 79 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

might be set to True depending upon if error occurred on SRB/ RB2-4 or

TRB/RB5 and above.

Table 61: Identification of RLC problems in traces

PM Counter / KPI KPI Name / Description

system
UtranCell VS.NbrCellUpdates.RlcUnrecoverableError Number of requested cell updates with cause
“Radio Link Control (RLC) Unrecoverable
Error” received by the RNC from the UE
UtranCell VS.DedicatedDownlinkRetransmittedPdusRlcRefer Number of PS RLC PDUs Retransmitted on
enceCell.<screenings> Reference Cell provided for various data rates
and traffic classes
UtranCell VS.HsdpaDiscTransportBlocksOnMaxRetrans Number of HSDPA Transport Blocks
Discarded due to Max. Number of
VS.HsdpaDiscMACdPDUsTimerExpiry Retransmissions Reached or timer expiry

Table 62: PM Counters to monitor drop or BLER at RLC layer

6.15. Call reliability – HSDPA

6.15.1. Introduction
From 3GPP 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 29 below is visualising the changes in the UMTS protocol stack in order
to support HSDPA:

UMTS Operational Network Engineering (For Internal Use Only) Page 80 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

UE Uu No de B Iu b RNC Iu p s SGSN Gn GGSN

SM SM
SM MM
IP P MM
MM P MM
SM Q IP
2 1 5 0 .1
P DC P RR C R R C P D C P G T P-U G T P-C G T P-U
G T P-U G T P-C
P H RY R C RRC
R AN AP R AN AP
Q 2 1 5 0 .1
R LC FP UDP UDP
c o d e c R LC R LC UDP
R LC Q 2 1 5 0 .1
M AC M AC Iu U P
M AC MAC
P h y-u p ALC AP
P h y-u p A LC A P P h y-u p IP SCCP SCCP IP IP
P h y-u p SCCP S C C P Q 2 1 5 0 .1 Q 21 50.
M A C-h s S T C .2 N B A P N B A P S T C .2 M T P -b
3 M T P -b
3 1
N B A P A LC A P M T P 3 BM T P 3 B MT P 3 B
H S-
DCH H S- S S C -FU N I S S C -FU N I FP S S CF-N S S C -FN
FP DS CH S S C F S S CFDS CH DCH SSCF SSCF SSCF SSCF
FP FP
PHY PHY P HY P HY FP SSCOP SSCOP SSCOP SSCOP SSCOP
S S C O PS S C O P SSCOP SSCOP
DCH HS DP A HS DP A DCH PHY
AA L2 A A L5 AA L5 A A L2 AA L5 AAL5 L2 L2
A AL5 A AL5 AAL2 A AL2 AAL5 A AL5 A AL5 AAL5 AA L5
AAL2
ATM AT M AT M L1 L1
AT M AT M
E 1 / S T -1
M S T M-1 S T M-1
E1 E1

C o n tr o l Plan e U ser Plan e T r an sp or t Plan e Comm on

Figure 29: HSDPA protocol stack enhancements

The following subsections are describing different aspects of HSDPA data calls.

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 based
on the reception of Event 1d.
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 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.
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 1a
• RNC adds NodeB B to the Active Set via Active Set Update procedure
• UE sending Measurement Report with Event 1d
• RNC triggers Hard Handover via Radio Bearer Reconfiguration
procedure

UMTS Operational Network Engineering (For Internal Use Only) Page 81 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• UE sends Measurement Report with Event “1b” to remove NodeB A

from the active set
The optimisation approach when triggering Event “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).
If the new primary cell does not support HSDPA or suffers from CAC failure,
then the HS-DSCH RB(s) is (are) reconfigured to DCH (if iRM CAC is
successful). In case of CAC failure for the DCH then the PS RAB(s) is (are)
released. For parameters configuring HSDPA see 2. Again like DCH calls
iMCTA CAC can also trigger (if DCH fallback not enabled or fails) to transfer the
call to another inter-frequency 3G or inter-system 2G cell.

6.15.2.2. Failure symptoms, identification and fixes for improvement

HSDPA performance degradations due to mobility issues can be best observed
by analysing drive test data. It is very important to trigger handover at the right
time as too late and UE may be served by a NodeB that is much worse
compared to the best cell in the active set or too early and frequent handovers
can hurt throughput as well.
Furthermore non-optimal handover settings might cause unnecessary
transitions from HS-DSCH to DCH if too many HSDPA users; as a result the
benefits from HSDPA will not be available to a HS capable 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 30 below shows an
example cross-correlated by Actix 2; 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 Wireshark (previously Ethereal):

UMTS Operational Network Engineering (For Internal Use Only) Page 82 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 30: Hard handover problems identified by cross-correlated

RRC and TCP data
Table 63 below is listing the identification techniques for HSDPA mobility
problems:

Problem Trace Trigger

HSDPA ping-pong Uu There are two consecutive Radio Bearer Reconfiguration procedures within x
seconds
Transmission gap Uu, TCP Cross-correlation Uu and TCP trace: during a Radio Bearer Reconfiguration
during HO in procedure there is a transmission gap on TCP layer in the DL for x seconds
HSDPA call

Table 63: 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 (subsection 6.4.2).

6.15.3.1. RF related issues - CQI

The DL quality of the HSDPA shared channel is reflected by the channel quality
indicator (CQI) UE sends back to the Node B in the UL 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. NodeB decides based
upon the reported CQI values which Transport Format Resource Combination

UMTS Operational Network Engineering (For Internal Use Only) Page 83 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

(TFRC) can be transmitted given a certain transmit power and an expected

error rate that is directly impacting the expected throughput.
3GPP 2 defines the meaning of the reported CQI values for each UE category.
In 2 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 which correspond to the reported CQI. The measurement power offset Γ
is signaled by the RNC and the reference power adjustment ∆ is given for each
UE category in 2. PCPICH is the transmit power of the Primary CPICH. It should
be noted that the 3GPP specification does not demand that P CPICH + Γ is equal
to the total available HSDPA power.
The aim of analysing CQI is to understand in the even of throughput
degradation, if the scheduler is efficiently utilising the air-interface by cross
correlating CQI with codes, modulation and TB used to achieve a target HARQ
BLER. Such information is readily available in UE logs.
Figure 31 below show as a graphical distribution of the throughput versus CQI;
the test has been done stationary, the cell was unloaded and application was
FTP download via TCP/IP:

1800

1600
App Fwd Throughput [kbps]

1400

1200

1000

800

600

400

200

0
0 5 10 15 20 25
CQI

Figure 31: 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 the maximum TBS (see also subsection 6.15.4).

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 32:

UMTS Operational Network Engineering (For Internal Use Only) Page 84 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

1800

1600

1400
App Fwd Throughput [kbps]

1200

1000

800

600

400

200

0
-20 -18 -16 -14 -12 -10 -8 -6 -4

Ec/No [dB]

Figure 32: 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 UE limitations.

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.4 Mbit/s at physical layer, see also 2 and 2. 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 especially in good RF.

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:

UMTS Operational Network Engineering (For Internal Use Only) Page 85 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• Indirectly by execution of UE performance tests during the busy hour

and a comparison to the non-busy hour; another good test method
might be static automatic tests over a day
• By evaluation of PM counter statistics to examine the frequency of UEs
of certain category being scheduled and how often multiple users were
scheduled per TTI
• Evaluation of Iub traces in regards to the HS-DSCH FP flow control and
congestion management especially if number of E1/T1 are low.

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 following and
are easily identifiable in the CT as HsdpaCacFailure.
Hard limits
During call set up, HS-DSCH serving cell change via hard handover 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
hsdpaCellClass.maximumNumberOfUsers. HSDPA hardware and
processing resources are limited in the NodeB, for more details see 2. For ALU
UA6.0x the UCU-III/xCEM hardware limitation due to UL (and default parameter
setting) is 32, although more than 64 users have been shown to be supported
per sector-carrier under lab conditions and with very low UL data rates of 8kbps.
Soft limits
Each time when a UE tries to establish a HSDPA call on a new NodeB via a
RadioBearerReconfiguration procedure iRM CAC is also checking the soft
limitations for the associated DCH. For ALU UTRAN the corresponding
parameter and algorithm configuring iRM CAC are explained in 2.
In case Fair-sharing (33694) is truned on, the CAC will depend upon the
resources reserved for the existing HSDPA users and can trigger a failure even
with less number of users per cell than above. So this depends upon the QoS
requirements of existing users and can change with the dynamics of the traffic
mix.
HSDPA related PM counters are available in 2.

6.16. Call reliability – HSUPA/EDCH

6.16.1. Introduction
From 3GPP 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 UA6 release HSUPA is only supported in UL, if
HSDPA is configured in the DL. Furthermore new UL MAC functionality has
been split into RNC (MAC-es) and NodeB (MAC-e) entities respectively. below
is visualising the changes in the UMTS protocol stack in order to support
HSUPA:

UMTS Operational Network Engineering (For Internal Use Only) Page 86 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 33: 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 for
networks supporting EDCH Macrodiversity, event 1j is also configured.
This event is used to keep the DCH active set and the EDCH active
set consistent when certain active set updates take place 2
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.
UA6.0 only supports HSUPA over Iur boundary if feature 30744 is enabled on
SRNC and DRNC and both are RNC9370. So in markets where the above
scenario is not applicable (like USA), if the primary radio leg goes over to the
drift RNC, the HSDPA/E-DCH call will be reconfigured to HSDPA/DCH state
with a maximum data rate controlled by
DchRateCapping.maxUlRateHsdpaAndEdchToHsdpaAndDch.
A timer is used to supervise the 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 don’t 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.

UMTS Operational Network Engineering (For Internal Use Only) Page 87 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

6.16.2.2. Failure symptoms, identification and fixes for improvement

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 Uu There are consecutive Radio Bearer Reconfiguration procedures within x
along Iur seconds doing E-DCH ↔ DCH state changes frequently
Reduction in Uu There is no subsequent Radio Bearer Reconfiguration procedure observed
throughput during after the initial procedure that configured UL to DCH
HO along Iur

Table 64: HSUPA HO related issues involving Iur

Some relavent KPIs/Counters are given that deal with the handover and call
reliability aspects of HSUPA

PM Counter/KPI KPI Name / Description

system
UtranCell VS.EdchCellDeletion.RadioLinkFail Number of E-DCH Cell Deletion.
Deletion due to Radio Link failure
UtranCell VS.RAB.Drop.PS.CellDCH.EDCH_HSDSCH Dropped UTRAN Initiated PS RAB
Connections with UE in Cell_DCH
per transport channel format. UL
EDCH and DL HSDSCH
UtranCell VS.RAB.Drop.CN.Init.PS.CellDCH.EDCH_HSDSCH CN (core network) initiated dropped
PS RAB connections for UEs in
Cell_DCH state per transport
channel type
UtranCell (VS.EdchSucMobility.EdchCallToEdchCallIntraFreqMob / EDCH Serving Cell change Success
(VS.EdchSucMobility.EdchCallToEdchCallIntraFreqMob rate
+VS.EdchUnsucMobility.EdchCallToEdchCallIntraFreqMob))

Table 65: PM Counter/KPI for E-DCH Mobility & Call Drop

6.16.1. 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
current grant. This can act as an indicator of how fairly each UE is being
scheduled.

UMTS Operational Network Engineering (For Internal Use Only) Page 88 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.2. 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 2 and 2. 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.3. 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.3.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 34
• The bandwidth on the backhaul transport network is limited
These kinds of capacity issues can be detected in a similar way to what has
been described for HSDPA

Figure 34: User versus Cell throughput variation with increase in users

UMTS Operational Network Engineering (For Internal Use Only) Page 89 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

6.16.3.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 parameters
BTSEquipment.edchMaxNumberUserEbbu & BTSEquipment
.edchMaxNumberUserNodeB.
HSUPA capacity is also heavily dependent on hardware and processing
resources which are limited in the NodeB, for more details see [16].
Some relevant KPIs/Counters are given that deal with NodeB capacity aspects
of HSUPA. A full set of HSUPA related PM counters are available in [28].

PM Counter/KPI KPI Name / Description

system
UtranCell VS.EdchIubTnlCongestIndc.Reserved Number of E-DCH Congestion
Indication sent: Reserved
UtranCell VS.EdchIubTnlCongestIndc.DelayBuildUp Number of E-DCH Congestion
Indication sent: Delay Build Up
UtranCell VS.EdchIubTnlCongestIndc.FrameLoss Number of E-DCH Congestion
Indication sent: Frame loss
UtranCell VS.EdchIubTnlCongestIndc.NoCongestion Number of E-DCH Congestion
Indication sent: No Congestion
UtranCell VS.EdchIuRelAbnormal.CACReject Number of Iu release requested for
E-DCH call. CAC Reject on the
EDCH Cell
NodeB VS.eDCHBLReductionFactor.IuBFactor At each expiry of the
EdchBLSupervisionTimer timer, the
IubReductionFactor is computed.
Depending on the value the
corresponding sub counter is
incremented.

Table 66: PM Counters dealing with EDCH capacity aspects

6.17. Call reliability – miscellaneous failures

6.17.1. RB Reconfiguration failure
6.17.1.1. Concept
RB Reconfiguration is used in ALU RNC for most of the RRM procedures:
• 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 Congestion Control (subsection 6.5)
• Hard handover for HSDPA best cell change (subsection 6.15.2) and for
inter-frequency mobility (subsection 6.12)
• In case RNC requests the UE to change the RB due to e.g. PS traffic
measurements triggered either on receipt of a Measurement Report 4a
from the UE or by the UTRAN monitoring the UL or DL RLC buffer
occupancy (subsection 7.2.3)

UMTS Operational Network Engineering (For Internal Use Only) Page 90 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• In case RNC requests the UE to change the DL R99 data rate due to
high DL TX code power reported by the NodeB (iRM scheduling)
In case of a change of R99 UL/DL data rate or HSDPA best cell, first a
synchronised Radio Link Reconfiguration on NBAP is executed following
changes of the ATM resources on the Iub via ALCAP procedures. RNC sends a
RB Reconfiguration message on RRC and in case of a failure the UE sends
back the RB reconfiguration failure.

6.17.1.2. Failure symptoms, identification and fixes for improvement

One reason for a failure in this procedure is that the UE is not supporting the
requested new configuration. Failure can also occur due to un-optimised
activation CFN in case of SRLR and physical channel failure while performing
inter-frequency handover.
Also during DCH to/from FACH transitions, the RNC is not able to listen to both
FACH and DCH channels, which makes it vulnerable especially if UE
experinces a failure and remains in one state while RNC changes the state
causing either RB reconfiguration timeout or RLC disruption depending upon
which is smaller.
Table 67 and Table 68 are listing the identification of RB Reconfiguration
Failures in traces and in the PM system:

Problem Trace Trigger

RB Reconfiguration failure Uu or CT Any occurrence of the RRC message RB Reconfiguration
Failure

Table 67: Identification of RB Reconfiguration Failures in traces

PM Counter / KPI KPI Name / Description

system
UtranCell (VS.RRC.RBReconfigSucc / VS.RRC.RBReconfigAtt) RadioBearerReconfiguration
and RNC Success rate
UtranCell VS.RadioBearerReconfigurationUnsuccess.Timeout Number of radio bearer
reconfiguration not successful due to
timeout
UtranCell VS.RadioBearerReconfigFailure.<cause>18 Number of Radio Bearers that failed
to be reconfigured due to various
causes

Table 68: PM KPIs identifying RB Reconfiguration Success and Failures

6.17.2. Relocation failures

6.17.2.1. Concept
The relocation procedure is used in case of
• IRAT-HO (subsection 6.10 for details)
• Inter-RNC HO (SRNS relocation (UE not involved))
• In case of a Cell Update on a new RNC
18
Causes include no DL code resources, no DL power resources, unspecified, CAC RNC processing
resources, lack of bandwidth on Iu, Iur and Iub

UMTS Operational Network Engineering (For Internal Use Only) Page 91 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

The procedure is described in 2. 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).

6.17.2.2. Failure symptoms, identification and fixes for improvement

Failures of the relocation procedure occur most likely during the IRAT-HO,
which is described here. A failure is detected during the RANAP Relocation
Preparation procedure due to the following causes:
• Timer TRELOCprep (5sec) 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.
In the second case upon receiving a Relocation Preparation Failure message
from the 3G CN, 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 69 is listing methods of how to identify relocation problems in call trace:

Problem Trace Trigger

Relocation Preparation CT Any occurrence of the RANAP message Relocation Preparation Failure
Failure
Relocation Cancel CT Any occurrence of the RANAP message Relocation Cancel

Table 69: Identification of relocation failures in interface traces

Figure 35: Call Flow – IRAT HO relocation cancellation due to timer expiry

Tables below are listing the PM KPIs describing relocation failure and success:

UMTS Operational Network Engineering (For Internal Use Only) Page 92 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

PM Counter / KPI KPI Name / Description

system
UtranCell VS.RAB.Drop.CS.RelocUEInvol / RAB.SuccEstab.CS CS RAB Drop Rate due to SRNS
Relocation (UE involved)
UtranCell VS.RAB.Drop.PS.RelocUEInvol / RAB.SuccEstab.PS.Sum PS RAB Drop Rate due to SRNS
Relocation (UE involved)

Table 70: Drop rate due to Failure in SRNS relocation – UE involved

PM Counter / KPI KPI Name / Description

system
UtranCell (IRATHO.AttRelocPrepOutCS - Relocation preparation for CS UMTS
IRATHO.FailRelocPrepOutCS.<sum>)/ to GSM HHO success rate
IRATHO.AttRelocPrepOutCS
UtranCell IRATHO.FailRelocPrepOutCS.TRELOCprep_exp/ Relocation preparation UMTS to
IRATHO.AttRelocPrepOutCS GSM fail rate T Relocprep expiry

Table 71: PM KPIs for IRAT-HO relocation failure and success rates

6.17.3. 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.

UMTS Operational Network Engineering (For Internal Use Only) Page 93 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 how to overcome these.

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 addition VT calls will result in a fragmented and
interrupted video signal. In case of data call the poor quality may cause
throughput degradation or high ping delay times.
The DL and UL Block Error Rate (BLER) are the KPIs providing an indication of
the quality of the UMTS call from 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 retrieved via UE logging or by
setting up DL-BLER measurements from the UE:
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) as:
UL BLER = 100 * (NumTransBlockErrUL / NumTransBlockTotUL)
The DL and UL PC algorithms are there to control the BLER to a maximum
value. 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 Power control settings
• 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 of keeping the DL BLER in a pre-
defined range. The DL closed loop power control can be split into two loops:
outer and inner loop. Figure 36 below is showing the principle of the DL PC:

UMTS Operational Network Engineering (For Internal Use Only) Page 94 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 36: Downlink 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.
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 some UE performances in given RF
conditions are specified in 2. When the UE is in compressed mode higher SIR
target values will be defined, as there is no power control during transmission
gaps.
DL inner loop PC:
The inner loop PC purpose is fast adaptation of the NodeB transmit power in
order to achieve the targeted SIR 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.
TPC pattern that the UE is sending to the NodeB is based on the comparison of
the SIR estimation versus the SIR target. However the NodeB transmit power is
limited to parameters given by the RNC on NBAP.

7.1.1.2. Failure symptoms, identification and fixes for improvement

The DL BLER is reported by any drive test system in Uu traces while the DL Tx
code power can be captured using NodeB logging tool like OTCell or CDM/x or
even with RNC initiated Call Trace if it is configured with
NbapDedicatedMeasurements. Table 72 is listing the triggers in these traces:

Problem Trac Trigger

e
High DL BLER in Uu Uu DL BLER higher than x % for more than y seconds
NodeB Tx Pwr via CT CT NodeB transmit power is exceeding for service x more than y seconds z dBm.

Table 72: Identification of high DL BLER in interface traces

UMTS Operational Network Engineering (For Internal Use Only) Page 95 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

7.1.2. UL Block Error Rate (BLER) analysis

7.1.2.1. Concept
The UL closed loop power control is in charge of keeping the UL BLER in a pre-
defined range. The UL closed loop power control can be split into two loops:
outer and inner loop:
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 up to 100
Hz. For updating the SIR target the RNC takes into account not only the
measured BLER, but also the reported Quality estimates (QE) provided by the
NodeB. In case Power Control Enhancements (DynamicParameterPerDch.
qeThresholdForUlOlpc = 255) is not available then RNC relies only on the
reported CRCI from the NodeB. Figure 37 below is visualising the principle:

Figure 37: UL outer loop power control

If the UE is in soft/softer HO mode and one 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
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 layer and
adding a CRCI to the DCH-FP frame. In addition NodeB can also estimate the
quality of the link and send to the SRNC via same frame in QE field. QE value
ranges from 0 to 255 (small QEs are indicating good quality) and can be based

UMTS Operational Network Engineering (For Internal Use Only) Page 96 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

upon Physical or Tranmsport channel BER. QE can also be used by the OLPC
in the SRNC if 0 < DynamicParameterPerDch. qeThresholdForUlOlpc < 255.
UL inner loop PC:
The UL inner loop PC is adjusting the transmit power of the UE in order to
achieve the SIR target provided by SRNC. All NodeBs involved in the particular
call are sending TPC commands with a rate of up to 1500 Hz. The TPC
commands of NodeBs can differ from one another. In this case if only one of the
NodeBs is sending a “power down” command, the UE will lower it’s 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 2.

7.1.2.2. Failure symptoms, identification and fixes for improvement

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 IMSI based call trace (CTb) in parallel to tracking the PMs 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).
A high UL BLER at RNS level may indicate inappropriate provisioning of TFCI
for the various R99 UL services. For example TFI0 = 0x81 is chosen instead of
1x0 then this would disable the reporting of CRC from UE per TTI and hence
impact the OLPC performance if silent mode is activated on the NodeB via
activation flags: NodeB.isSilentModeAllowed and UlRbSetConf.ulFpMode =
ulFpModeSilent. Table 73 and Table 74 are listing the triggers in interface
traces and the corresponding PM KPIs:

Problem Trace Trigger

High UL BLER CT UL BLER higher than x % for more than y seconds
High UE power Uu Any occurrence where the UE is sending with at least y dB UE power for more
reached than x seconds19
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.
SIR target Iub The SIR target for service x is exceeding value y.
exceeded
UL SIR target not Iub Any occurrence where the UL SIR target is not updated for more than x
updated seconds. This is an indication of failure in the UL that might lead to an UL RLF.

Table 73: Identification of high UL BLER in interface traces

PM Counter / KPI KPI Name / Description

system
RNC (VS.DdUlAmrABtBadFrm / (VS.DdUlAmrABtGoodFrm + UL BLER rate for All CSV AMR
VS.DdUlAmrABtBadFrm)) codec rates
RNC (VS.DedicatedUplinkBadPdus.<sum> / UL BLER rate for PS
(VS.DedicatedUplinkPduRlc + VS.DedicatedUplinkBadPdus))

Table 74: PM KPIs identifying BLER issues

19
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).

UMTS Operational Network Engineering (For Internal Use Only) Page 97 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

7.2. Call quality – Quality of service (QoS)

QoS reflects 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. Monioring these or similar KPIs can act as trigger
points for identifying non-optimal performance.

KPI
No network [%]
Attach failure [%]
Attach setup time [s]
Location update success rate [%]
SMS failure rate [%]
MMS failure rate [%]
SMS delivery time [s]
MMS delivery time [s]

Table 75: General QoS KPI measured on application level

In ALU UA6.0 QoS parameters like TC, ARP and THP given in the RANAP RAB
Assignment Request message can be used for the OLS differentiation in
various features like power control, iRM CAC, AO and iRM pre-emption, see 2
for details.

7.2.2. QoS – voice service

Because UMTS UL and DL links are uncorrelated due to different frequencies
and reception paths it is necessary to measure the UL and DL voice quality
separately. The voice quality equipment compares 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.
Table 77 below is giving the QoS KPIs 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 2. A good voice quality can be considered when the MOS is exceeding 3.0.

UMTS Operational Network Engineering (For Internal Use Only) Page 98 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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 76: QoS of voice services - MOS

KPI
Call completion success rate voice [%]
Block call rate voice [%]
Dropped calls voice [%]
HandoverSuccess3G2G [%]
HandoverSuccess2G3G [%]
Call setup success rate voice [%]
Good voice quality [%]

Table 77: 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 2. 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 2.
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 data
rate can be dynamically changed (or even the mobile is sent to idle
mode/URA_PCH mode) depending on the data to be sent in the UL and/or DL.
Depending on the status of the RLC buffer in the UE, the mobile might send a
Measurement Report Event 4a (in case the buffer occupancy exceeds an
absolute threshold) depending upon whether feature 34227.1 is enabled in
UA6.0 via RadioAccessService.isBOTriggerForRbAdaptationAllowed. The
RNC would then 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). Furthermore data rates assigned at various state transitions can also be
capped thanks to feature 34227.3 enabled via RadioAccessService.
isOamCappingOfDataAllowd.
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

UMTS Operational Network Engineering (For Internal Use Only) Page 99 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Context is removed from the GGSN or the FTP session drops. After the re-
establishment of the RRC connection or the new establishment of the RAB, the
FTP session can be resumed in case the session has not timed out. For the
user the drop of the RRC and RAB is visible by stalling of the FTP transfer and
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 operating
systems, compression is an available option in the PPP settings of the dial-up
networking. In addition PDCP layer is providing header compression for e.g.
TCP, UDP, RTP and IP header 2.
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. Failure symptoms, identification and fixes for improvement

For analysing low PS data performance the following has to be considered:
• UE state (Cell_DCH with HSPA, Cell_DCH, Cell_FACH or URA_PCH)
• Chosen RB rate (in case of R99 Cell_DCH)
• 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)
• Retransmissions 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 38 below. The
throughput of a FTP transfer is measured by Wireshark 2 and visualised by
tcptrace 2 is low. The root cause for the non-optimal performance is Congestion
Control:

UMTS Operational Network Engineering (For Internal Use Only) Page 100 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 38: FTP performance degradation caused by Congestion Control

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 traces with Wireshark traces recorded at
the FTP server and also with RF data like Ec/No or Active Set Update
messages recorded by the UE logging tools. 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 would be necessary to correlate the PC clocks by using
time synchronisation. Otherwise tools like Actix or RFO can do event-based
cross correlation.
Another example for an end-to-end analysis is shown in Figure 39 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 Wireshark 2.
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 help further the investigation.

UMTS Operational Network Engineering (For Internal Use Only) Page 101 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 39: 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 40 below. As expected the delay is very small and don’t
have a big impact on the overall delay. This trace was recorded using a
Tektronix K12 protocol tracer.

Figure 40: delay measured on the Gn interface

UMTS Operational Network Engineering (For Internal Use Only) Page 102 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Table 78 below is listing the identification triggers in network interface traces:

Problem Trace Trigger

TCP reset TCP Number of occurrences if the REST flag of the TCP options is set to TRUE.
Statistic counted per TCP session
TCP TCP Number of occurrences of TCP retransmissions. Statistic counted per TCP
retransmission session
TCP SACKs TCP Number of SACK. Statistic counted per TCP session

Table 78: Identification of QoS issues for data service

Table 79 below is listing the data QoS for identifying non-optimal performance:

KPI
PDP context activation failure [%]
PDP context activation time [s]
PDP context cut off rate [%]
FTP cut off rate [%]
FTP throughput [kbit/s]
Ping delay [s]
HTTP failures [%]
RB Assignment Success Rate [%]

Table 79: 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 ALU’s
LVAT. Although there is an ITU standard that defines the framework of video
quality measurement 2, 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 80 below is listing the KPIs to retrieve the other QoS parameters for VT:

KPI
Call completion success rate VT [%]
Block call rate VT [%]
Dropped calls VT [%]
Call setup success rate VT [%]

Table 80: QoS of VT services – KPIs

UMTS Operational Network Engineering (For Internal Use Only) Page 103 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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.
One suggested voice test call sequence for the UMTS UE in the drive test van
can 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 drive test kit should be capable of 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 along with a 3G and 2G scanner for parallel
verification.

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
cygwin providing a full Linux command shell environment 220.
The data test call sequence should be as follows:
• Network attach and PDP context activation
• FTP download of three times 5 MB file, 5 seconds pause in between
• Pause of 20 seconds
• FTP download of three times 5 MB file, 5 seconds pause in between
• Pause of 20 seconds
20
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.

UMTS Operational Network Engineering (For Internal Use Only) Page 104 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

• FTP upload of three times 2 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 Wireshark on both the UE and the FTP server side.
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.
Table 81 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 64 kbyte The TCP window is the amount of outstanding data a
size sender can send before it gets an acknowledgment for
the receiving entity
Client/server PDCP Disable When doing root cause analysis the feature should be
compression disabled
Client/server PPP Disable When doing root cause analysis the feature should be
compression disabled
Server Starting 4 packets The amount of TCP/IP packets sent by the sending
MSS entity at the beginning. Further packets will be send after
reception of the first TCP ACK
Client ICMP packet 40 byte To measure the ICMP RTT an IP packet should be sent
size with the size of 40 byte (8 byte header plus 32 byte
payload)
Client/server MSS 1460 byte The MSS should be 1460 byte resulting in a MTU of
1500 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

Table 81: Default TCP/IP parameter settings used for testing

The TCP/IP settings can be verified using Wireshark. The settings can be set
for Windows PCs in the registry or with help of shareware tools like 2. 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 Wireshark, 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.
The special ASCII files should contain only one (!) line and as an example the
following sequence:

UMTS Operational Network Engineering (For Internal Use Only) Page 105 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

“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 like keep alive signals.
Figure 41 below is showing a snapshot of the Wireshark protocol analyser:

Figure 41: Wireshark protocol analyser

UMTS Operational Network Engineering (For Internal Use Only) Page 106 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

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
time synchronisation to enable a 3rd party software like Actix to do the cross-
correlation.
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.2 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 42 below is showing the measurement setup for analysing PS data
services when doing drive testing in a van, Figure 43 for doing VT testing in a
lab.

UMTS Operational Network Engineering (For Internal Use Only) Page 107 of 108
Document name: UMTS RF Troubleshooting Guideline UA6.0

Date: 2009-26-06 Rev: 1.02 Status: Approved-STANDARD

Figure 42: Measurement setup for PS data analysis in a van

Uu
(cabled)

Stationary
voice/VT
evaluation drive 2nd mobile in
test equipment shadowing box

Uu
(cabled) Iub Iu

Mobile voice Fading NodeB CN

RNC
evaluation drive simulator
test equipment

UMTS protocol
analyser

Local
NTP server

Figure 43: Measurement setup for VT testing in the lab

UMTS Operational Network Engineering (For Internal Use Only) Page 108 of 108