umts troubleshooting RF Guide line (Alcatel Lucent).pdf

7/22/2019 umts troubleshooting RF Guide line (Alcatel Lucent).pdf

http://slidepdf.com/reader/full/umts-troubleshooting-rf-guide-line-alcatel-lucentpdf 1/106

Document name: UMTS RF Troubleshooting Guideline U04.03

Date: 2007-06-08 Rev: 2.1

UMTS Network Performance Engineering of 106

UMTS RF

Troubleshooting Guideline

U04.03

Author: Matthias Braun

Editor: Irfan Mahmood

Date: 6th August 2007

Version: 2.1




Date: 2007-06-08 Rev: 2.1


Table of Contents

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

2. REFERENCES ...........................................................................................................................10

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

3.1. INTRODUCTION ...................................................................................................................... 12 3.2. CONTENT............................................................................................................................... 12 3.3. HOW TO READ ....................................................................................................................... 13 3.4. UTRAN/CN RELEASE AND VENDOR DEPENDENCY ...............................................................13 3.5. INTENDED AUDIENCE.............................................................................................................13

3.6. DISCLAIMER

-WHAT IS NOT COVERED

................................................................................... 13 4. DESCRIPTION OF THE OPTIMISATION PROCESS ........................................................ 14

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

5.1. CALL SETUP – RRC CONNECTION ESTABLISHMENT...............................................................16 5.1.1. PLMN/cell selection and reselection ............. ............ .............. ............. .............. .......... 16 5.1.2. Failures on the AICH, PICH and PCH........ ............. ............ .............. ............. ............. 20 5.1.3. Random Access Procedure ........................ ............ .............. ............. .............. ............ .. 23 5.1.4. Call Admission Control (CAC)..................................................................................... 26 5.1.5. Radio Link Setup...... .............. ............. ............. ............. .............. ............. ............ ......... 28 5.1.6. Call setup failures on the FACH.... .............. ............. ............ .............. ............. ............. 29 5.1.7. RRC Connection Reject message with specified cause “unspecified”.................... ...... 31

5.2. CALL SETUP – FAILURES DURING THE CALL SETUP PHASE .....................................................32 5.2.1.

Concept......................................................................................................................... 32

5.2.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 32 5.3. CALL SETUP – CORE NETWORK FAILURES.............................................................................33

5.3.1. Mobility Management failures...... ............. ............ .............. ............. .............. ............ .. 34 5.3.2. Call Control failures .............. ............. ............. ............. .............. ............. ............ ......... 35 5.3.3. Session Management failures ............. ............. ............. .............. ............. ............ ......... 36

5.4. CALL SETUP – RAB ESTABLISHMENT.................................................................................... 37 5.4.1. Dynamic bearer control (DBC) ............ ............. .............. ............ ............. .............. ...... 38 5.4.2. Radio Link Reconfiguration....... ............. .............. ............ .............. ............. ............ ..... 40 5.4.3. Radio Bearer Establishment .......... .............. ............. ............ .............. ............. ............. 41

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

6.1. CALL RELIABILITY – RADIO LINK FAILURE (RLF)................................................................43 6.1.1. Concept......................................................................................................................... 43 6.1.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 45

6.2. CALL RELIABILITY – DROP OF THE RAB................................................................................ 47 6.2.1. Concept......................................................................................................................... 47 6.2.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 48

6.3. CALL RELIABILITY – DROP OF RRC CONNECTION AFTER CALL SETUP ................................... 49 6.3.1. Concept......................................................................................................................... 49 6.3.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 51

6.4. CALL RELIABILITY – RF PLANNING RELATED ISSUES ............................................................ 52 6.4.1. Introduction ........................ .............. ............. ............ .............. ............. .............. .......... 52 6.4.2. Pilot pollution ...............................................................................................................52 6.4.3. Around-the-corner-effect .............. ............. ............ .............. ............. ............ .............. .. 53




Date: 2007-06-08 Rev: 2.1


6.4.4. Non-optimal neighbour definitions.............. ............. ............ .............. ............. ............. 54 6.4.5. Poor RF coverage......................................................................................................... 57 6.4.6. Poor PSC plan..............................................................................................................58

6.5. CALL RELIABILITY – CONGESTION CONTROL (CONGC) ........................................................ 58 6.5.1. Concept......................................................................................................................... 58 6.5.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 59

6.6. CALL RELIABILITY – FAILURES IN URA_PCH/CELL_PCH MODE........................................59 6.6.1. Concept......................................................................................................................... 59 6.6.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 60

6.7. CALL RELIABILITY – FAILURES IN CELL_FACH MODE ........................................................ 60 6.7.1. Concept......................................................................................................................... 60 6.7.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 62

6.8. CALL RELIABILITY – HARDWARE AND NETWORK INTERFACE OUTAGES ................................63 6.8.1. Concept......................................................................................................................... 63 6.8.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 63

6.9. CALL RELIABILITY – INTRA FREQUENCY HANDOVER ............................................................. 63 6.9.1. Concept......................................................................................................................... 63

6.9.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 65 6.10. CALL RELIABILITY – IRAT HANDOVER .............................................................................67

6.10.1. Concept (UMTS->GSM)..... .............. ............. ............ .............. ............. .............. .......... 67 6.10.2. Failure symptoms, identification and fixes for improvement (UMTS->GSM).... .......... 69 6.10.3. Concept (CS GSM ->UMTS) ........................................................................................69 6.10.4. Failure symptoms, identification and fixes for improvement (CS GSM ->UMTS) ....... 70

6.11. CALL RELIABILITY – CELL CHANGE ORDER FROM UTRAN...............................................71 6.11.1. Concept......................................................................................................................... 71 6.11.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 71

6.12. CALL RELIABILITY – INTER FREQUENCY HANDOVER ......................................................... 72 6.12.1. Concept......................................................................................................................... 72 6.12.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 72

6.13. CALL RELIABILITY – FAILURES ON THE TRANSPORT NETWORK ........................................75 6.14. CALL RELIABILITY – FAILURES ON RLC............................................................................ 75

6.14.1. Concept......................................................................................................................... 75 6.14.2. Failure symptoms, identification and fixes for improvement .............. ............. ............. 78 6.15. CALL RELIABILITY – HSDPA............................................................................................79

6.15.1. Introduction ........................ .............. ............. ............ .............. ............. .............. .......... 79 6.15.2. Mobility aspects of HSDPA .................. ............. .............. ............ ............. .............. ...... 80 6.15.3. RF related issues.......... .............. ............. .............. ............ .............. ............. ............ ..... 82 6.15.4. UE limitations............................................................................................................... 84 6.15.5. Capacity issues ............ .............. ............. .............. ............ .............. ............. ............ ..... 84

6.16. CALL RELIABILITY – HSUPA/EDCH................................................................................ 85 Introduction .............. ............. ............ .............. ............. ............ .............. ............. .............. .......... 85 6.16.2. Mobility aspects of HSUPA .................. ............. .............. ............ ............. .............. ...... 85 6.16.3. MAC/ RF related Issues.......... .............. ............. .............. ............ ............. .............. ...... 86 6.16.4. UE Limitations..............................................................................................................87 6.16.5. Capacity issues ............ .............. ............. .............. ............ .............. ............. ............ ..... 87

6.17. CALL RELIABILITY

–MISCELLANEOUS FAILURES

...............................................................88 6.17.1. RB Reconfiguration / Transport Channel Reconfiguration failure.............. ............ ..... 88 6.17.2. Physical Channel Reconfiguration failures ........... .............. ............. .............. ............ .. 89 6.17.3. Relocation failures... .............. ............. ............. ............. .............. ............. ............ ......... 89 6.17.4. Failures during the RAB and RL release procedure................ ............. .............. .......... 91

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

7.1. CALL QUALITY - BLOCK ERROR RATE (BLER).....................................................................92 7.1.1. DL Block Error Rate (BLER) analysis........ .............. ............ .............. ............. ............. 92 7.1.2. UL Block Error Rate (BLER) analysis........... ............ .............. ............. .............. .......... 94

7.2. CALL QUALITY – QUALITY OF SERVICE (QOS) ...................................................................... 96




Date: 2007-06-08 Rev: 2.1


7.2.1. QoS – general ...............................................................................................................96 7.2.2. QoS – voice service...... .............. ............. .............. ............ .............. ............. ............ ..... 96 7.2.3. QoS – data services............. .............. ............. ............ .............. ............. .............. .......... 97

7.2.4. QoS – VT service ............ .............. ............. ............ .............. ............. ............ .............. 101 APPENDIX ....................................................................................................................................... 102

A. MEASUREMENT DEFINITION ....................................................................................................... 102 A.1. Measurement definition – voice .................. ............. ............. .............. ............. ............ ....... 102 A.2. Measurement definition – data....... ............. ............. ............. .............. ............. ............ ....... 102 A.3. Measurement definition – VT .......... .............. ............. .............. ............ ............. .............. .... 105

B. TIME SYNCHRONISATION OF MEASUREMENT TRACES .................................................................105

Change Record

This table details the changes done to the document since the last baseline version

Date Changes Issue#

6th August 2007 Updated draft after review with following

changes

• Editorial throughout the document

• Added sections like HSUPA, Inter-Freq HO, RRC connection re-establishment, 2G->3G IRAT HO

2.1




Date: 2007-06-08 Rev: 2.1


1. Glossary of terms and abbreviations

3GPP 3G Partnership Project

ACB Access Class Barring

ACK Acknowledgement

AICH Acquisition Indication Channel

ALCAP Access Link Control Application Protocol

APN Access Point Number

AM Acknowledged Mode

ARQ Automatic Repeat Request

AS Access Stratum

ATM Asynchronous Transfer Mode

BCCH Broadcast Control Channel

BER Bit Error Rate

BLER Block Error Rate

BSIC Base Station Identity Code (GSM)

BSS Base Station Subsystem (GSM)

CAC Call Admission Control

CCPCH Common Control Physical Channel

CM Configuration Management / Connection ManagementCN Core Network

CongC Congestion Control

CPICH Common Pilot Channel

CQI Channel Quality Indicator

CRC Cyclic Redundancy Checksum

CRCI CRC Indicator

CS Circuit Switched

DAHO Database Assisted HO

DBC Dynamic Bearer Control

DCCH Dedicated Control Channel

DCH Dedicated Channel

DL Downlink

DRNC Drift RNC

DRX Discontinuous Reception

EDCH Enhanced DCH




Date: 2007-06-08 Rev: 2.1


ETSI European Telecommunication Standard Institute

FACH Forward Access Channel

FDD Frequency Division Duplex

FM Fault Management

FP Framing Protocol

FSN First SN

FTP File Transfer Protocol

GGSN Gateway GPRS Support Node

GMM GPRS MM

GPRS General Packet Radio Services

GPS Global Positioning System

GSM Global System for Mobile CommunicationHCS Hierarchical Cell Structure

HLR Home Location Register

HHO Hard Handover

HO Handover

H-PLMN Home PLMN

HSDPA High Speed Downlink Packet Access

HS-DSCH High Speed Downlink Shared Channel

HSUPA High Speed Uplink Packet Access

HTTP Hyper Text Transfer Protocol

H-USDPA High Speed Downlink Packet Access

HW Hardware

IE Information Element

ICMP Internet Control Message Protocol

IP Internet Protocol

IRAT Inter Radio Access Technology

KPI Key Performance Indicator

LA Location Area

LWS Lucent Worldwide Services

MAC Medium Access Control

MAC-hs Medium Access Control high speed

MAHO Mobile Assisted HO

MIB Master Information Block

MM Mobility Management

MMS Multi Media SMS

MO Mobile Originating




Date: 2007-06-08 Rev: 2.1


MOS Mean Opinion Score

MSC Mobile Switching Centre

MSS Maximum Segment Size

MNC Mobile Network Code

MT Mobile Terminating

NACK Negative ACK

NAS Non access stratum

NBAP NodeB Application Part

NTP Network Time Protocol

O&M Operation and Maintenance

OMC-U Operations and Maintenance Centre UMTS

PCPICH Primary CPICHPC Power Control

PCH Paging Channel

PDCP Packet Data Convergence Protocol

PDP Packet Data Protocol

PDU Protocol Data Unit

PHY Physical Layer

PICH Paging Indication Channel

PLMN Public Land Mobile Network

PM Performance Measurement

PPP Point to Point Protocol

PS Packet Switched

PSC Primary Scrambling Code

QE Quality Estimate

QoS Quality of Service

RA Routing Area

RAB Radio Access Bearer

RACH Random Access Channel

RAN Radio Access Network

RANAP Radio Access Network Application Part

RB Radio Bearer

RL Radio Link

RLC Radio Link Control

RLF Radio Link Failure

RF Radio Frequency

RFCT RF Call Trace (also called IMSI tracing)




Date: 2007-06-08 Rev: 2.1


RNC Radio Network Controller

RNSAP Radio Network Subsystem Application Part

RRC Radio Resource Control

RRM Radio Resource Management

RSSI Received Signal Strength Indicator

RSCP Received Signal Code Power

RTP Real Time Protocol

RTT Round Trip Time

RXLEV Receive Level (GSM)

SACK Selective ACKs

SC Scrambling Code

SCCPCH Secondary CCPCHSCH Synchronization Channel

SDU Service Data Unit

SGSN Serving GPRS Support Node

SHO Soft/softer Handover

SIB System Information Broadcast

SIM Subscriber Identity Module

SIR Signal to Interference Ratio

SM Session Management

SMS Short Message Service

SN Sequence Number

SRB Signalling Radio Bearer

SRNC Serving RNC

TB Transport Block

TBS Transport Block Size

TCP Transmission Control Protocol

TGPS Transmission Gap Pattern Sequence

TM Transparent Mode

TPC Transmit Power Control

TSSI Transmitted Signal Strength Indicator

TX Transmitted

UDP User Datagram Protocol

UE User Equipment (mobile station)

UL Uplink

UM Unacknowledged Mode

UMTS Universal Mobile Telecommunication Standard




Date: 2007-06-08 Rev: 2.1


URA UTRAN Registration Area

U-SIM UMTS Subscriber Identity Module

UTRAN UMTS Terrestrial Radio Access Network

VT Video Telephony

A reference for abbreviations can be found in [37].




Date: 2007-06-08 Rev: 2.1


2. References

[1] TS 23122 NAS Functions related to Mobile Station (MS) in idle mode

[2] TS 11.11 Specification of the SIM – ME interface

[3] TS 25304 UE Procedures in Idle Mode and Procedures for Cell Reselectionin Connected Mode”

[4] GSM 03.22 Functions related to Mobile Station in idle mode and groupreceive mode

[5] TS 24008 Mobile radio interface layer 3 specification; Core NetworkProtocols – 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; generalaspects

[9] TS 25413 UTRAN Iu Interface RANAP Signalling

[10] TS 25423 UTRAN Iur Interface RNSAP Signalling

[11] TS 25214 Physical layer procedures (FDD)

[12] TS 25922 Radio resource management strategies

[13] TS 25201 User Equipment (UE) Radio transmission and reception (FDD)

[14] TS 25306 UE Radio Access Capabilities

[15] TS 34121 Terminal conformance specification; Radio transmission and

reception (FDD)

[16] UMTS RF Translation Application Note (TAN) for HSDPA

[17] UMTS RF Translation Application Note (TAN) for EDCH

[18] UMTS RF Translation Application Note (TAN) for Cell Selection andReselection

[19] UMTS RF Translation Application Note (TAN) for Access Procedures

[20] UMTS RF Translation Application Note (TAN) for Load Control

[21] UMTS RF Translation Application Note (TAN) RLC

[22] UMTS RF Translation Application Note (TAN) RF Call Trace

[23] UMTS RF Translation Application Note (TAN) Handover

[24] UMTS RF Translation Application Note (TAN) Inter-Frequency Handover

[25] UMTS RF Translation Application Note (TAN) Inter-RAT Handover

[26] UMTS RF Translation Application Note (TAN) Inter Frequency Handover

[27] UMTS RF Translation Application Note (TAN) Radio Link Control

[28] UMTS RF Translation Application Note (TAN) Power Control

[29] Actix, http://www.actix.com




Date: 2007-06-08 Rev: 2.1


3. About this document

3.1. Introduction

The UMTS RF Troubleshooting Guideline is the base document for the UMTSoptimisation process and is used for the identification, classification andresolution of problems, failures or performance degradations that might beobserved during the optimisation activity.

This document covers the following items:

• Drive test data analysis (Uu traces and 2G/3G scanner measurements)

• Network interface tracing analysis (e.g. Iu, Iur and Iub interface tracing)

• PM KPI analysis

• End-to-end performance analysis

Furthermore this guideline is cross correlating the observed occurrences to thecorresponding UTRAN parameter, PM counters and KPIs of the UTRAN and/orCN and gives references.

Last but not least this document is used as a specification for writing queriesthat automatically identify and classify failures and problems from networkinterface traces and drive test data. For more information see [41].

3.2. Content

There are five main chapters in this document:

• Chapter “About this document” is providing an introduction and anoverview of the UMTS RF Troubleshooting Guideline.

• Chapter “Description of the optimisation process” is providing a shortoverview of the UMTS optimisation process as covered by the UMTSRF Troubleshooting Guideline.

• Chapter “Call setup” is listing all problems that might occur at the callestablishment phase.

• Chapter “Call reliability” is describing failures and problems that mightoccur after call establishment; examples are dropped calls, radio linkfailures or handover problems.

• Chapter “Call quality” is dealing with quality problems as perceived bythe UMTS subscriber.




Date: 2007-06-08 Rev: 2.1


3.3. How to read

The main analysis chapters are subdivided into subsections that are describingthe particular problems and failures step by step. Basis for the structure is theUMTS call handling. The subsections are structured as follows:

• In the first part, the problem and when applicable correspondingUTRAN parameter are described and listed; this part has the subtitle“concept”.

• In the second part called “failure symptoms, identification and fixes forimprovement” there are – if applicable – three tables:

o The first table is specifying the trigger points for the identification inthe network interface trace or in the drive test data including the typeof traces necessary for problem identification (e.g. Uu trace, 3Gscanner measurements or TCP/IP protocol interface trace)

o The second table is listing the PM KPIs as retrieved by the UTRANor CN PM system

o The third table is listing the corresponding parameter(s)

3.4. UTRAN/CN release and vendor dependency This document is a “living” document and is updated on a regular basis basedon the experience coming from the different projects.

This version of the UMTS RF Troubleshooting Guideline is supporting ex-Lucent equipment only. However it is geared towards supporting multi-vendorequipment so long as they follow 3GPP mandated procedures. Whenever anew UTRAN or CN network release is available certain tables and descriptionshave to be updated while others parameters are project dependent and hence

no particular value is assigned to them.

3.5. Intended audience

This document is directed to system engineers, network planners, RFoptimisation engineers and all engineers that are going to analyse network withthe aim of optimising a UMTS network.

3.6. Disclaimer - what is not covered

This document is not covering Element Management Layer activities. As aconsequence this Guideline cannot be used for troubleshooting maintenancetask issues. This document does not support how to trace and to operatemeasurements instruments and tools. For more details check the correspondingreference documentation.

Currently the Fault Management (FM) analysis is also not covered in thisguideline, but might be added in later releases.

This guideline is only shortly covering RF network planning and dimensioningissues; these topics are covered in more details in [33] and [34].

Core Network specific problems are only covered in this guideline in the way toexplain how to identify these kind of problems during the analysis. The questionof the root cause and how to overcome this problem is not part of the UMTS RFTroubleshooting Guideline.




Date: 2007-06-08 Rev: 2.1


4. Description of the optimisation processThe different fields of UMTS RF optimisation can be summarised by thefollowing items:

• FM audit and analysis

• RF design audit and optimisation (see [33]and [34] for a detailed description)

• CM audit and optimisation

• PM audit and optimisation

• Drive testing and investigation

• Network interface tracing and analysis

•

Lab investigation and optimisationThese fields of UMTS optimisation are displayed in Figure 1 in yellow below.

Figure 1: Ex-Lucent UMTS optimisation process – process flow




Date: 2007-06-08 Rev: 2.1


Pre-requisite before starting with a performance verification and optimisation isthat

• The FM analysis shows no severe alarms that might influence theperformance measurements as retrieved by the PM statistic or drivetest data

• The RF design audit and optimisation has been finished for the regionto be optimised

In case, one or both pre-requisites are not fulfilled starting with the performanceinvestigation and troubleshooting does not make much sense. Fortroubleshooting and optimizing new clusters, the Drive test and interfaces’traces would be more relevant than PMs that may get skewed because of smallnumber of users.




Date: 2007-06-08 Rev: 2.1


5. Call setupOne main user perception of a UMTS network is the success of setting-up aUMTS call. This section is describing all kind of failures and problems that mightoccur during the call establishment phase. The different phases during the callsetup 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 indetail in the following subsections:

Figure 2: PLMN (re-)selection and cell (re-) selection process

If the UE is in CELL_FACH, CELL_PCH or URA_PCH the UE also performs cellreselections; however possible failures that may occur are covered in thesubsection 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.




Date: 2007-06-08 Rev: 2.1


Description of the NAS part during PLMN/cell selection and reselection

The NAS part is described in [1] and depends mainly on the information stored

on the U-SIM [2].After power-on the UE starts with the initial cell search procedure and tries todecode the network information as broadcasted by the 2G or 3G cells on theBCCH. The UE is either selecting the best suitable cell (in terms of the cellselection criteria, see below) of its H-PLMN and starts with the locationregistration procedure or otherwise when the H-PLMN is not available the UE isselecting a non-forbidden PLMN, camping on the best suitable cell and startswith the location registration procedure.

In case there is no suitable cell of a non-forbidden network (no roamingagreement, 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 emergencycalls in case it detects any PLMN coverage.

Description of the AS part during PLMN/cell selection and reselection

The AS part is defined in [3] (for UMTS) and [4] (for GSM). Optimisationapproach is to ensure that the UE camps on the best suitable cell (in terms ofRF conditions, traffic distribution assumptions etc.) to setup a call. The processcan be configured by O&M parameters as explained below:

In case ACB is used the UE is selecting a non-barred cell based on either cellinformation stored on the U-SIM or after doing the initial cell search.

Prerequisite for the cell selection (and also cell reselection) are that thefollowing 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 CPICHEc/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 themaximum power for the given mobile power class.

The different O&M parameters of the formula above are listed in Table 1 below:

Parameter Description

Qqualmin Minimum required quality level in the cell (dB). Not applicable for TDD cells orGSM cells, broadcasted via SIB3 and SIB4

Qrxlevmin Minimum required RX level in the cell (dBm), broadcasted via SIB3 and SIB4

Table 1: Parameters used for cell selection




Date: 2007-06-08 Rev: 2.1


Remark

The current formulas can only be used in case HCS is not deployed.

Furthermore while camping the UE shall start to perform inter-RATmeasurements if Squal <= SSearchRAT, otherwise not. SSearchRAT is a configurableUMTS parameter broadcasted on SIB3/SIB4. However note that to avoid pingponging between UMTS and GSM the following condition should be fulfilled:

FDD_Qmin > Qqualmin + SsearchRAT

If the above condition is not satisfied, a UE will move from GSM to UMTS andimmediately start monitoring neighboring GSM cells again, an undesirablecondition. Furthermore frequent re-selections between UMTS and GSM cancause mobile terminating call failure in case the PLMN pages the currentnetwork 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 thereselection list that are broadcasted via SIB11/SIB12 on the BCCH.

For cell reselection the target cell has to fulfill the same criteria as specified forthe cell selection case. The UE ranks the cells according to the cell rankingcriteria Rs (serving cell) and Rn (neighbour cell). The UE will reselect the bestGSM 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 thefollowing formulas are used (both for GSM and UMTS cells):

Rs = Qmeas,s + Qhysts

Rn = Qmeas,n - Qoffsets,n

For UMTS Qmeas is based either on RSCP or Ec/No measurements of theserver/neighbour cell depending on the setting of the UTRAN parameter

configuring the selection and reselection quality measure. Qhysts is an hysteresisto avoid ping-pong effects, Qoffsets,n is an offset defined on a per-neighbourdefinition (for both GSM and UMTS neighbours).

The reselection process using the mentioned parameters (Qoffsets,n = 0) isvisualised in Figure 3 below:

Figure 3: Cell reselection process




Date: 2007-06-08 Rev: 2.1


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


cellSelAndResQualMeas Parameter defining whether CPICH or RSCP measurement shall be used forUMTS measurements

sIB3Treselection Time hysteresis for the cell reselection

sIB3RAT.sSearchRAT UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start

with inter-RAT measurements (setting of SSearchRAT)

sIB3SInterSearch UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start

with UMTS interfrequency measurements (setting of Sintersearch)

sIB3Qhyst1, sIB3Qhyst2 Hysteresis to avoid ping-pong effects (RSCP, Ec/No hysteresis)

outFDDAdjCells.cellOffset UMTS parameter broadcasted via the SIB11/SIB12 defining an offset on a perneighbour basis

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

Description of the Location Registration part during PLMN/cell selection andreselection

The Location Registration procedure is initiated by the UE by sending MM/GMMDirect Transfer messages. For these kinds of failures see subsection 5.3.1.

The cell selection and reselection process and its translations are covered inmore details in [18].

5.1.1.2. Failure symptoms, identification and fixes for improvement

A failure of the PLMN selection/reselection during a drive test can be easilyidentified 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 causemight be a network outage due to NodeB, RNC or any particular networkinterface like Iub or Iu (see also subsection 6.4.5 and 6.8) or when the test vanis driven out of the coverage footprint of the (GSM and UMTS) network. In thatcase the drive test route should be checked.

When the PM counters of the CN are showing a high rejection rate due tomissing national roaming it may be caused by an interface problem to or anoutage in the roaming networks be it UMTS or GSM.

Another problem might be ACB on one or several of the surrounding GSMand/or UMTS cells. Information regarding Access Class Barring is broadcastedvia SIB3 or SIB4 [6]. ACB is used during the integration of cells see [35] fordetails.

Common problems of the cell selection/reselection procedure are non-optimisedconfiguration of the corresponding UTRAN parameter. As a consequence thecall will be setup on a non-optimal cell or a non-optimal RAN so the call-setupmight 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). Aconsistency check of the parameters listed in Table 1 and Table 2 might help tofind parameter misconfiguration. Parameter Qoffsets,n used for optimisation of aper-cell basis should be reviewed.

In case of poor 3G coverage and low call setup success rate the parameterSSearchRAT might be set to a lower value so the UE will start earlier with inter-RAT




Date: 2007-06-08 Rev: 2.1


measurements. Also the cell offsets for the GSM cells can be adapted to prefercall setup on the 2G layer.

Another problem arises when different LA codes are defined for the GSM andUMTS networks and the Inter-RAT reselection criterion is met. This is inparticular the case for subscribers inside a building where the UMTS coverageis not as strong compared to the GSM coverage, but the preference is on theUMTS network. As a consequence it is recommended to assign the same LAcodes to GSM and UMTS cells that are providing coverage to the same area toavoid LAU ping-pong.

Table 3 below is listing the identification techniques of PLMN/cell (re-)selectionfailures in drive test traces and scanner measurements:

Problem Trace Trigger

Wrong PLMNselected

Uu Any occurrence of the MNC of the cell the UE is camping on is different fromthe MNC of the H-PLMN

ACB Uu Any occurrence of IE “Access Class Barred” = TRUE in SIB3/SIB4

Call setup on non-optimal cell

Uu, 3Gscanner

The call is setup via RRCConnectionSetup message on a cell that is not on thex best cell listed by the 3G scanner within y dB window.

Call setup on non-optimal RANtechnology

Uu, 2G/3Gscanner

The RXLEV of the best measured 2G cell is within a x dB window (or evenbetter) for y seconds compared to the RSCP of the cell the UE is camping onwhen sending the RRC Connection Request or Cell Update message onRACH

Ping-pong LUbetween 2G / 3G

Uu There are two consecutive LUs between 2G and 3G within x seconds and theLA 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 theprocess is within the UE. Failures during the Location Registration procedureare 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 followingevents:

• 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 orCell_PCH mode and downlink PS data are scheduled to be delivered inthe downlink

If the UE is in idle, URA_PCH or CELL_PCH modes and the UE is receiving aPaging 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 inconnected mode and is paged, then the UTRAN is sending the paging viaDCCH (“Paging Type 2”).

The CN might perform a repetition of paging process in case the UE has notanswered within a certain period in time. In addition the RNC might trigger therepetition of the UE paging in the UTRAN. The repetition timers of the RNC andCN have to be set accordantly.

In the following it is assumed that the UE is not in connected mode so it hasreceived a Paging Type 1.




Date: 2007-06-08 Rev: 2.1


After the UE has successfully decoded the paging on the PCH it sends a RACHPreamble using the open loop power control algorithm. When the NodeBreceives 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 ConnectionRequest/Cell Update/URA Update message using the RACH (so called RACHMessage Part). Upon successful decoding the NodeB forwards the RACHMessage 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 UpdateConfirm/URA Update Confirm message (successful case). FACH failures arecovered in subsection 5.1.6.


Failures on the PCH, PICH and AICH are most l ikely due to

• Non-optimal power settings of the PICH, AICH or PCH

• Poor radio conditions in terms of low RSCP or Ec/No because of e.g.

pilot pollution (subsection 6.4.1), poor RF coverage (subsection 6.4.5),camping on a non-optimal cell (see subsection 5.1.1) etc.

• Congestion on the PCH

Table 4 below is listing the main UTRAN parameters configuring the PICH, PCHand AICH:


pICHPower UTRAN parameter defining the power settings of the PICH

pCHPower UTRAN parameter defining the power settings of the PCH

aICHPower UTRAN parameter defining the power settings of the AICH

CN_PCH_Timer1 Timeout when the CN will reinitiate the paging

tPageRep Timeout when the RNC will reinitiate the paging

CN_PCH_Max Maximum number of paging repetitions by the CN

nUtranPageRep Maximum number of paging repetitions by the RNC

Table 4: Parameter used for configuring the PICH, AICH and PCH

The paging itself is sent on the PCH that is a PHY channel on Uu. The drive testequipment can record paging requests. However analysing drive test logs is nota good way to investigate paging problems because paging that is not receivedby the UE can only be detected via parallel Iub tracing.

A better approach for analysing call setup problems due to paging failures is touse PM counters of the UTRAN and the CN.

If the UE is in URA_PCH or CELL_PCH mode, the RRC connection ismaintained via the common physical channels (subsection 6.6). When the UEcannot be reached via paging the UTRAN may decide to drop the RRCconnection.

1 CN_PCH_Timer & CN_PCH_Max are dummy names for the parameters




Date: 2007-06-08 Rev: 2.1


Figure 4: Dropped RRC connection due to unsuccessful paging

Congestion on the PCH is also indicated by the UTRAN PM system. A solutionof lowering the paging load might be to separate the FACH and PCH on theSCCPCH by introducing an additional SCCPCH. In addition creating smallerLocation Areas / Routing Areas will also lower the paging load.

Failures on the AICH or PICH (PHY channels, no corresponding Transportchannels) can be detected only indirectly because standard drive test tools donot record these messages that are sent only on the Uu interface. Increasingthe power settings of the particular Physical Channels will reduce the failurerate. In addition “normal” RF optimisation for areas with low Ec/No will improvethe situation.

Table 5 below is listing of how failures on the PICH/AICH/PCH can be identified

in interface traces:


RRC drop due tounsuccessful paging

Iub and Iu Cross correlation Iu and Iub trace: any occurrence where a UE page isrecorded on Iub, there is no Cell Update recorded on Iub within x seconds andthe RNC is sending back within y seconds an Iu Release Request messagewith cause “Release due to UTRAN generated reason” (UE is either inURA_PCH or CELL_PCH mode)

Unsuccessful paging Iub Any occurrence where a UE is paged and recorded on the Iub and there is noanswer by the UE on UL CCCH also recorded on the Iub within x seconds




Date: 2007-06-08 Rev: 2.1


Table 5: Identification of PICH/PCH/AICH failures in traces

Table 6 below is listing the identification possibilities using KPIs/Countersretrieved by the CN and/or UTRAN PM system.

Table 6: PM KPIs/Counters for PICH/PCH/AICH failures

5.1.3. Random Access Procedure

5.1.3.1. Concept

The RACH Access Procedure is used when attaching to the network, setting upa call, answering to a page or performing a LA Update/RA Update. The RACHprocedure has been successfully performed when the RACH Message Part isreceived by the RNC upon successful decoding at the NodeB.

The RACH is transmitted on the PHY in two separated parts: first a certainnumber of RACH Preambles are sent. The power of the first RACH Preamble isrelatively low and calculated using Open Loop Power Control. Each of thefollowing RACH Preambles are transmitted with an increased power level till anACK is received on the AICH. This is the case when received preamble powerexceeds the parameter “physicalRACHPreambleThreshold”.

Then the UE transmits the RRC Connection Request (Cell Update, URAUpdate) message in the RACH Message Part. Figure 5 below illustrates thetransmission of several RACH Preambles in different Ramping Cycles and only

after the reception of an ACK on AICH, the transmission of the RACH messagepart:

PMsystem

Counter / KPI KPI Name / Description

RNC VS.MM.RRCConnDrop.UTRANPagingFailure Counting the number of RRC drops due toUTRAN Paging failures

UtranCell VS.MM.PagAttDiscard.ProcessorLoad This measurement provides the number ofpaging attempts discarded by the RNC TPUdue to processor load

RNC VS.MM.PagAttRec This measurement provides the number ofpaging attempts received by the RNC

3G-SGSN (MM.SuccPsPagingProcIu + SuccPsPagingRepititionsIu) /(MM.AttPsPagingProcIu + AttPsPagingRepititionsIu)*100

KPI ”Paging success rate”. Paging success ratedefines the rate of successful paging in thepacket network.

3G-MSC VS.succFirstPageReqs The measurement provides the number ofsuccessful page responses from MS. Theattempt and success counts are used tomonitor the paging performance.

RNC VS.ChannelOccupRatePCH Provides the channel occupancy rate for thePCH channel




Date: 2007-06-08 Rev: 2.1


Figure 5: RACH procedure with RACH Preambles and Message Part

When the UE is sending the RRC Connection Request message for the firsttime, it resets its internal counter V300 to 1 and starting its internal guard timerT300 (to UTRAN parameter t300); if the UE has already sent one or severalRRC Connection Request messages before, counter V300 is incremented byone and guard timer T300 is restarted. Upon reception of the RRC ConnectionRequest message at the RNC, PM counter RRC.AttConnEstab.<perestablishment cause> is incremented by one

2. Upon expiry of timer T300 the

UE may start again by sending RACH Preambles depending on the status ofcounter V300. If V300 <= N300 (configured by UTRAN parameter n300), the UEincrements V300 by one, resets T300 and sends the RACH Preamble again. IfV300 > N300, the UE stops sending on the RACH and stays in idle mode [6].

For the Cell Update and URA Update procedure V302 and T302 are used, thecorresponding PM counters are named VS.MM.CellUpdateReq.<per

establishment cause>. Figure 6 below is showing as an example the CellUpdate procedure:

Figure 6: Cell Update procedure supervised by T302 and V302

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

available in [42].




Date: 2007-06-08 Rev: 2.1


Failures in the RACH procedure occur if either the RACH Preamble or theRACH Message Part cannot be decoded.

Possible reasons for these decoding problems are:• Non optimal RACH power settings

• Non optimal RACH counter/timer settings

• RACH congestion

• Non optimal setting of physicalRACHPreambleThreshold & RACHsearch Window

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


constantVal Used by UE to calculate Initial Preamble Power

PowerRampStep Determines the power increment between two successive RACHPreambles

maxRetranPreamble Determines the maximum number of preambles allowed within onePower Ramping Cycle

physicalRACHPreambleThreshold

The threshold for preamble detection. The ratio between receivedpreamble power during the preamble period and interference levelshall be above this threshold in order to be acknowledged.

SIB3MAXAllowedULTXPower,SIB4MAXAllowedULTXPower

These parameters define the maximum allowed power the UE mayuse when accessing the cell on PRACH in idle mode

mMax Determine the maximum number of power ramping cycles allowed

t300 UE guard timer that is supervising the RRC Connection Setupprocedure when the UE is waiting for the RRC Connection Setupmessage

n300 Defines the number of times the UE is allowed to send the sameRRC Connection Request message

t302 UE guard timer that is supervising the Cell/URA Update procedurewhen the UE is waiting for the Cell Update Confirm/ URA UpdateConfirm message

n302 Defines the number of times the UE is allowed to send the sameCell Update/ URA Update message

Table 7: Parameter used for configuring the RACH

For a complete list of RACH parameters see also [19].


The RACH Preambles may only be recorded in internal UE or NodeB traces,but not by “normal” drive test tools. In most cases only a statistic about the PHY




Date: 2007-06-08 Rev: 2.1


and MAC procedure of the RACH is listed in the drive test logs e.g. number ofRACH Preambles sent, last transmitted power etc

3.

Possible congestion on the RACH could be detected by supervision of PMUTRAN counters (Table 9 below).

The RACH performance can be improved by changing of the power settingsand/or changing of the timer/counter as listed in Table 7.

Table 8 below is listing the identification possibilities for network interfacetraces, Table 9 below is listing the identification possibilities using KPIsretrieved by the UTRAN PM system.


RACH messagelost

Uu, Iub Cross-correlation Uu/Iub trace: RACH Message Part (RRC ConnectionRequest, Cell Update or URA Update) is recorded on the Uu, but notrecorded on the Iub interface.

Table 8: Identification of RACH failures in traces

PMsystem


UtranCell VS.RACHcongestion This measurement provides the percentage oftime that the RACH is in congested state.

UtranCell VS.RACHTransBlock.Good / (VS.RACHTransBlock.Bad+ VS.RACHTransBlock.Good) * 100

KPI “RACH transport block good CRC rate” isthe percentage of RACH Transport Blocks withgood CRC.

UtranCell VS.ChannelOccupRateRACH This measurement provides the channeloccupancy rates for Radio Access Channel.

Table 9: PM KPIs for RACH failures

More RACH related PM KPIs are available in [19].

5.1.4. Call Admission Control (CAC)

5.1.4.1. Concept

The Call Admission Control (CAC) procedure is used in order to admit or denythe establishment of the RRC connection to avoid an overload of the UMTSsystem. The CAC thresholds can be defined for uplink and downlink loadseparately. The CAC algorithms and the corresponding parameter aredescribed in detail in [20].

The CAC is started after the RNC receives the RRC Connection Requestmessage on RACH and executes CAC before setting up the RL on NBAP (see

Figure 7 below):

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

The higher layer (RRC) initiates the transmission of the RACH message. In case of a lower layer

failure ro deliver preamble it is up to the higher layer re-initiate the whole RACH procedure again

(means in the RRC decoding another RACH Message would be listed).




Date: 2007-06-08 Rev: 2.1


Figure 7: CAC executed after reception of RACH Message Part

If the defined load thresholds for CAC are exceeded the RRC connectionestablishment request is denied and a RRC Connection Reject message withcause “Congestion” is sent back to the UE.

The only optimisation approach in case of CAC rejections is to optimise the RFenvironment in terms of pilot pollution, neighbour list optimisation etc. Inaddition it should be verified that the CAC thresholds are set correctly.

Table 10 below is listing the main parameters configuring CAC:


thrCAC2UL Specifies the load threshold for UL call admission of a non-emergency RRC connectionrequest.

thrCAC2DL Specifies the load threshold for DL call admission of a non-emergency RRC connectionrequest when HSDPA is disabled.

thrCAC2DLHSDPA

Specifies the load threshold for DL call admission of a non-emergency RRC connectionrequest when HSDPA is enabled.

Table 10: Parameter configuring CAC


CAC failures can only be identified in a reliable manner via PM counters orinternal traces. Reason is that the RRC Connection Reject message with cause“Congestion” might also be sent in case of missing resources during the RLsetup procedure (subsection 5.1.5) or also for other failures.


RRC ConnectionReject

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

Table 11: Identification of RRC Connection Reject due to Congestion ormissing resources

For CAC related PM KPIs see [20] however the main PM counter is givenbelow:




Date: 2007-06-08 Rev: 2.1


PM

system

Counter / KPI Name / Description

UtranCell RRC.FailConnEstab.CAC This measurement provides the number of failed RRC connectionestablishment with cause “Call Admission Control” (CAC).

Table 12: PM Counter for CAC failures

5.1.5. Radio Link Setup

5.1.5.1. Concept

The Radio Link Setup procedure is initiated in two cases:

• During the call establishment phase after the CAC is granted the RNCrequests the NodeB to allocate resources through the NBAP Radio LinkSetup 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 theestablishment of the AAL2 bearer over the Iub interface using ALCAP (ALCAPEstablishment Request and ALCAP Establishment Confirm). Problems onALCAP could be due to ATM configuration and are outside the scope of thisdocument. ATM synchronisation problems are not expected at this stage of thecall because of the already successful NBAP procedure.

The same is valid for the synchronisation between NodeB and RNC via theDCH-FP over AAL2 bearer.

Figure 8: Initial RRC Setup Steps after successful CAC


The NBAP Radio Link Setup procedure may fail and the NodeB sends back theRadio Link Setup Failure message.




Date: 2007-06-08 Rev: 2.1


According to [7] the failure causes can be classified as follows:

• Radio Network Layer Cause

• Transport Layer Cause

• Protocol Cause

• Miscellaneous Cause

Each category has many subcauses like “Transport Resources unavailable”,“NodeB Resources unavailable” or ”Semantic error” etc. 3GPP has defined avariety of failure causes. Here one major reason for NodeB resources problemcan be UCU capacity shortage, while transport resources issue can point to thebackhaul bandwidth limitation.

Table 13 below is listing the identification possibilities for network interfacetraces, Table 14 is listing the identification possibilities using KPIs retrieved bythe UTRAN PM system.

For identification of failures during the Radio Link Setup procedure Iub tracesare mandatory. Reason is that on Uu only the RRC Connection Reject messageis available with only two possible failure causes (“congestion” and“unspecified”), see also subsection 5.1.4.


Radio Link Setup I Uu, Iub Cross-correlation Uu/Iub trace: Any occurrence of the NBAP RadioLink Setup Failure message on Iub and RRC Connection Reject withcause “unspecified” or “congestion” on Iub/Uu

Radio Link Setup II Iub Any occurrence of the NBAP Radio Link Setup Failure message on Iub

Table 13: Identification of failures in the Radio Link Setup

PMsystem


UtranCell RRC.FailConnEstab.RLSetupFailure/RRC.AttConnEstab.sum*100 Failed RRC ConnectionEstablishment Rate due to RLSetup failures

UtranCell RLM.SuccRLSetupIub / RLM.AttRLSetupIub*100 Radio link setup success rate onIub

UtranCell (RLM.FailRLSetupIub.NodeBRes.CSV + RLM.FailRLSetupIub.NodeBRes.CSD+ RLM.FailRLSetupIub.NodeBRes.PSD) / RLM.AttRLSetupIub*100

Radio link setup failure rate onIub NodeB resource

UtranCell (RLM.FailRLSetupIub.TransRes.CSV + RLM.FailRLSetupIub.TransRes.CSD +RLM.FailRLSetupIub.TransRes.PSD) / RLM.AttRLSetupIub*100

Radio link setup failure rate onIub transport resource

RNC (RLM.AttRLSetupIur – RLM.FailRLSetupIur.sum) / RLM.AttRLSetupIur * 100 Radio link setup success rate onIur

Table 14: PM KPIs for Radio Link Setup failures

5.1.6. Call setup failures on the FACH

5.1.6.1. Concept

This subsection is covering only call setup related failures on FACH; for failuresin CELL_FACH mode see subsection 6.7.




Date: 2007-06-08 Rev: 2.1


It is assumed that the RACH Message Part has been successfully received, theCAC has been granted and the RL are established. In this case the RNC sendsback either the RRC Connection Setup, Cell Update Confirm or URA Update

Confirm message on FACH (successful case).

The RNC sends the FACH message, resets counter V30001 and starts itsguard timer T30001. When the RNC receives the answer by the UE (RRCConnection Setup Complete, UTRAN Mobility Information Confirm, RadioBearer Reconfiguration Complete, … ) before T30001 expires, the RNC stopsT30001. If the RNC does not receive the message before T30001 expires, theRNC may resend the FACH message depending on the status of counterV30001. If V30001<= N30001 (maximum number of retries), the RNCincrements V30001 by one, resets timer T30001 and sends the FACH messageagain. If V30001 > N30001, the RNC will stop sending FACHs to the UE andwill release the reserved resources on NBAP and ALCAP. Note that the RNCwill not send any failure message on the Uu.

The whole procedure is visualised in Figure 9 below:

Figure 9: Failures on FACH




Date: 2007-06-08 Rev: 2.1


Table 15 below is listing the parameters configuring the FACH:


fACHTrafPower UTRAN parameter defining the power settings of the FACH data part

fACHSigPower UTRAN parameter defining the power settings of the FACH control part

uERRCConnectionSetupResponseTimer

UTRAN parameter defining setting of T30001

maxRRCConnSetupRetries UTRAN parameter defining setting of N30001

Table 15: Parameter used for configuring the FACH


There are the following possible reasons for failures on FACH:

• Non optimal UTRAN parameter settings (e.g. FACH signalling and

traffic power)• Call setup not done on an optimal cell (subsection 5.1.1)

• The FACH message is not successfully decoded due to poor FACHcoverage

• The message on the FACH is successfully decoded by the UE, butafterwards the RNC cannot successfully decode the answer sent by theUE (UE is already in CELL_DCH mode, see also subsection 5.2)

Failures on the FACH can be indicated by UTRAN PM statistics, Iub and Uutraces. On Uu FACH failures cannot be directly observed because there is nocorresponding failure message sent.

Table 16 below is listing the identification of FACH failures on Iub, Table 17 thecorresponding PM KPIs:


Lost FACHmessage

Iub andUu

Cross-correlation Uu/Iub trace: one or more FACH messages are recorded onthe Iub, but not on the Uu interface

FACH Failure Uu or Iub Any occurrence of a Cell Update/URA Update message and within x secondsthere is a RRC Connection Release message with specified cause other than“normal event” sent back by the RNC

Table 16: Identification of failures on the FACH

PMsystem


UtranCell RRC.FailConnEstab.SetupIncomplete /RRC.AttConnEstab.sum*100

Failed RRC connectionEstablishment Rate timeout

UtranCell VS.PercentageFACHOccupancy Occupancy rate on FACH

Table 17: PM KPIs for failures on the FACH

5.1.7. RRC Connection Reject message with specified cause “unspecified”

The UE might receive a rejection when trying to establish a RRC Connectionwith specified cause “unspecified”.




Date: 2007-06-08 Rev: 2.1


Possible reasons for that failure message are problems in the Radio Link Setupprocedure, protocol errors or problems when sending the FACH etc. Table 18below is listing how to identify this kind of error in Uu logs:


RRC ConnectionReject with causeunspecified

Uu Any occurrence of an RRC Connection Reject message with specified cause“unspecified”.

Table 18: RRC Connection Reject – unspecified

There are no specific PM counters for that case; instead other PM counters withthe name RRC.FailConnEstab.<different rejection causes> are used.

5.2. Call setup – failures during the call setup phase

5.2.1. Concept

At this point in time the UE is in the transition phase to either CELL_FACH orCELL_DCH mode. The next message will already be sent in the new mode (asan example next message to be sent by the UE is RRC Connection SetupComplete or UTRAN Mobility Information Confirm).

When transiting to the CELL_DCH mode there is the possibility that the UE isalready in soft/softer handover mode when sending this message. This is thecase if

• The UE is allowed to report the measurements of more than one NodeBin the RRC Connection Request / Cell Update message

• The UE is supporting this feature

• The measurement of more than one cell is reported in RRC ConnectionRequest / Cell Update message

• The RNC is then directing the UE to soft/softer HO via RRC ConnectionSetup, Cell Update Confirm or URA Update Confirm message

Table 19 below is listing the parameters that are important for the call setupphase:


measQty.maxNoReportedCellsOnRACH

Defines the maximum number of cells the UE may report on RACH

addThresholdSHO Defines the hysteresis used at call setup to add neighbour cells to the Active Set

Table 19: Parameter important for the call setup phase

For more details about the translations see [23].

If the call is setup in an area where several NodeBs are providing marginalcoverage and it is not possible to add the radio legs quickly, there is a biglikelihood that the call setup will fail. When the call is not setup in soft/softer HOmode the UE has to wait for the reception of the Measurement Controlmessageand time-to-trigger before sending Measurement Report 1a etc.

5.2.2. Failure symptoms, identification and fixes for improvement

The RRC connection might drop in this early stage due to the following reasons:




Date: 2007-06-08 Rev: 2.1


• Non optimal handover parameter configuring the call setup in soft/softerhandover 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 issuesduring the call setup phase because at this point the UE is already inCELL_DCH/CELL_FACH mode so a drop of the RRC connection cannot bedifferentiated from an RRC drop occurred in a later stage of the call. Also thedrop might occur only a very short time later, but the root cause for the failure isone of the issues mentioned above.

Nevertheless it is possible to identify issues in network interface traces as listedin Table 20 below:


Call setup on a non-optimal cell

Uu, 3Gscanner

The call is setup via RRCConnectionSetup message on a cell and at thesame time the 3G scanner is reporting at least x cells that are within a y dBwindow compared to the best measured cell.

Not best cells in AS atcall setup

Uu, 3Gscanner

The number of cells in the Active Set is smaller than max AS size, but oneneighbouring cell is within xdB window compared to the Ec/No of the bestcell in the Active Set

Drop of RRC connectionat call setup

Uu The call is dropped within x seconds after sending the RRC ConnectionRequest or Cell/URA Update

Call Setup not insoft/softer HO mode

Uu, 3Gscanner

The call is setup in non soft/softer HO mode (# of SCs in RRC ConnectionSetup message is 1), the assigned SC is under the best x SCs measuredby the 3G scanner, and these SCs are within y dB window as measured by

the 3G scanner

Table 20: Identification of call setup in traces

5.3. Call setup – Core Network failures

After establishment of the RRC connection the UE and the CN exchange DirectTransfer messages so the UE can GPRS attach to the PS network, perform aLocation or Routing Area Update or initiate a data, voice or VT call. LAU/RAUinvolve just the mobility management procedures while the Call setup alsoincludes call control and session management protocols for CS and PS callsrespectively.

The following subsections are summarising possible failures that might occur

during these procedures. The subsections are grouped by the following threedifferent protocols:

• Mobility Management (MM) and GPRS Mobility Management (GMM)

• Call Control (CC)

• Session Management (SM)

The three protocols are sublayer protocols of the Connection Management(CM); these protocols are specified in [5] and [8]. CM failures causes like “CM




Date: 2007-06-08 Rev: 2.1


Service Reject Cause” is mapped on the Reject Cause of the MobilityManagement IE [5].

Note that (almost) any failure in this subsection is not UTRAN related becauseDirect Transfer messages are transparent to the UTRAN4. Any of the failurescan be easily detected by the corresponding failure messages.

Because the protocols are transparent to the UTRAN all PM KPIs are definedwithin 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 userterminals, such as informing the network of its present location and providinguser 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 improvementFor the root cause analysis please review the timer settings supervising themobility management protocols as specified in [5] chapter 11.2. The settings ofthese timers are specified and not configurable. In addition MobilityManagement failures might be due to missing roaming agreement, locked SIMcard, CN problems like authentication not possible due to inaccessible HLRdatabase etc.

The failure messages are retrieved from [5] chapter 9.2 (MM/CM) and 9.4(GMM). Table 21 below is listing the Mobility Management failures as they canbe retrieved by interface traces:


MM AuthenticationReject

Uu or Iub or Iu Any occurrence of a MM Authentication reject message sent by the CNe.g. because of not-allowed national/international roaming

CM Service Reject Uu or Iub or Iu Any occurrence of a CM Service reject message sent by the CN; thereject cause will give an indication of the occurred failure.

CM Service Abort Uu or Iub or Iu Any occurrence of a CM Service abort message sent by the UE. Thismessage is sent by the mobile station to the network to request theabortion of the first MM connection establishment in progress and therelease of the RR connection.

MM Abort Uu or Iub or Iu Any occurrence of a MM Abort message sent by the CN. Thismessage is sent by the network to the mobile station to initiate theabortion of all MM connections and to indicate the reason for theabortion. The rejection cause will give an indication about the occurredfailure.

MM LocationUpdating Reject

Uu or Iub or Iu Any occurrence of a MM Location updating reject message sent by theCN. The specified rejection cause will indicate the reason for the

failure e.g. IMSI unknown in the HLR, illegal MS/ME, roaming notallowed etc.

GMM Attach Reject Uu or Iub or Iu Any occurrence of a GMM Attach Reject message sent by the CN Thespecified rejection cause will indicate the reason for the failure e.g.protocol error, wrong or incorrect IE format etc.

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




Date: 2007-06-08 Rev: 2.1


GMM Authenticationand Ciphering Failure

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

GMM Authenticationand Ciphering Reject

Uu or Iub or Iu Any occurrence of a GMM Authentication and Ciphering Rejectmessage sent by the CN.

GMM Routing AreaUpdate Reject

Uu or Iub or Iu Any occurrence of a GMM Routing area update reject message sentby the CN. The specified rejection cause will indicate the reason forthe failure e.g. protocol error, wrong or incorrect IE format etc.

GMM Service Reject Uu or Iub or Iu Any occurrence of a GMM Service reject message sent by the CN

Table 21: Identification of Mobility Management failures in interface traces

Table 22 below is listing the PM KPIs of the Mobility Management as they canbe retrieved by the PM system of the 3G-MSC and SGSN:

PMsystem


SGSN (MM.AttGprsAttach.U – MM.SuccGprsAttach.U) /MM.AttGprsAttach.U * 100

GPRS attach failure rate

SGSN (attAuthInSgsn – succAuthInSgsn) / attAuthInSgsn * 100 Authentication failure rate

SGSN (MM.AttGprsDetachSgsn.U –MM.SuccGprsDetachSgsn.U) /

MM.AttGprsDetachSgsn.U * 100

SGSN initiated GPRS detach failure rate

3G-MSC (attInterVLRLocationUpdates +attIntraVLRLocationUpdates) /

(succInterVLRLocationUpdates +succIntraVLRLocationUpdates) * 100

Location Update Success Rate

SGSN MM.SuccInterSgsnRaUpdate.U /MM.AttInterSgsnRaUpdate.U * 100

Inter SGSN routing area update successrate

SGSN MM.SuccIntraSgsnRaUpdate.U /MM.AttIntraSgsnRaUpdate.U * 100

Intra SGSN routing area update successrate

3G-MSC VS.mobileOrigAttRejected The counter is incremented for a mobileorigination attempt that MSC for reasonsother than system resource overloadrelated.

3G-MSC VS.mobileTermAttRejected The counter is incremented for a mobiletermination attempt that is rejected bythe MSC for reasons other than systemresource overload related.

Table 22: PM KPIs/Counters for (GPRS) Mobility Management failures

5.3.2. Call Control failures

5.3.2.1. Concept

This subsection describes failures on the Call Control (CC) protocol. The CCprotocol is responsible for CS call establishment and clearing procedures, callinformation phase procedures etc. CC procedures can only be performed if aMM context has been established between the UE and the CN (subsection5.3.1).




Date: 2007-06-08 Rev: 2.1



Table 23 below is listing the CC failures as they can be retrieved by interfacetraces [5]; note that the specified cause might depend on the 3G-MSC/UEvendors:


Ubnormal CCDisconnect

Uu or Iubor Iu

Any occurrence of a CC Disconnect message (either UE or CN initiated) withspecified cause other than “normal event”

Ubnormal CCRelease

Uu or Iubor Iu

Any occurrence of a CC Release / Release Complete message (either UE orCN initiated) with specified cause other than “normal event”

Table 23: Identification of CC failures in interface traces

Table 24 below is listing the PM KPIs of the CC failures as they can be retrievedby the PM system of the 3G-MSC:

PMsystem

Counter / KPI5 KPI Name / Description

3G-MSC NoCCDisconnectUbnormalEvent / NoCCDisconnects * 100 Ubnormal CC Disconnect Rate

3G-MSC NoCCReleaseUbnormalEvent / NoCCReleases * 100 Ubnormal CC Release Rate

Table 24: PM KPIs for CC failures

Depending on the specified failure cause the failure might be due to missingresources (e.g. “requested circuit/channel not available”), drive testconfiguration issue (e.g. “User busy”) or protocol failure.

For the root cause analysis please check the timer settings supervising the CCprotocol in [5] chapter 11.3. The settings of these timers are not configurable.

5.3.3. Session Management failures5.3.3.1. Concept

The main function of SM is to support the PDP context handling of the PSservices. The SM comprises procedures for identified PDP context activation,deactivation and modification. SM procedures for identified access can only beperformed if a GMM context has been established between the UE and the CN(subsection 5.3.1).


The failure messages are retrieved from [5]. Table 25 below is listing the SMfailures as they can be retrieved by interface traces:

Problem Trace TriggerSM Activate PDP ContextReject

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

SM Activate SecondaryPDP Context Reject

Uu or Iub or Iu Any occurrence of a SM Activate Secondary PDP ContextReject message sent by the CN. The specified rejectioncause is giving an indication of the type of failure e.g.

5 Dummy names




Date: 2007-06-08 Rev: 2.1


protocol error, missing or faulty APN, lack of resources etc.

SM Request PDP ContextActivation Reject

Uu or Iub or Iu Any occurrence of a SM Request PDP Context ActivationReject 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 ContextReject

Uu or Iub or Iu Any occurrence of a SM Modify PDP Context Rejectmessage sent by the CN. The specified rejection cause isgiving an indication of the type of failure e.g. protocol error,service option not supported, lack of resources etc.

Table 25: Identification of SM failures in interface traces

Table 26 below is listing the PM KPIs of the SM failures as they can beretrieved by the PM system of the GGSN:

PMsystem


SGSN (1-((SM.FailActPdpCtxMs.Cause) /(SM.FailActPdpCtxMs.Cause+SM.SuccActPdpCtxMs)))*100

Session establishment success rate

SGSN SM.SuccModPdpContextSgsn.U /SM.AttModPdpContextSgsn.U * 100

Network originated sessionmodification success rate

Table 26: PM KPIs for SM failures

The most common SM failures are PDP Context activation failures due to wrongor missing APN or if the user is not allowed to subscribe to PS services. This isalso a typical configuration issue of the drive test equipment.

For the root cause analysis please review also the timer settings supervising theSM protocol in [5] chapter 11.2.3. The settings of these timers are specified andnot configurable.

5.4. Call setup – RAB establishmentThe RAB establishment is started at higher layer signalling after the RRCConnection establishment and CM procedures are successful. Figure 10 belowis showing the flow chart for a PS data call:




Date: 2007-06-08 Rev: 2.1


Figure 10: RAB establishment procedure

The RAB establishment procedure is always initiated by the RANAP RABAssignment Request and always terminated by the RAB Assignment Response.The failure and failure causes of the RAB Establishment are specified in [9];there are a variety of causes and it is up to the infrastructure vendor as to whatfailure is mapped to which particular failure cause.

Table 27 below is listing how to identify failures of the RAB establishmentprocedure in network interface traces:


RAB establishment failure Iu Any occurrence of an RAB Assignment Response withspecified failure cause according to 3GPP

6

Table 27: Identification of RAB establishment failures in traces

In the following subsections possible root causes for an unsuccessful RABestablishment are discussed in detail.

5.4.1. Dynamic bearer control (DBC)

5.4.1.1. Concept

Dynamic bearer control (DBC) is used to prevent overload of the R99 system incase new radio resources or radio resources requiring more power arerequested. DBC takes place

• During the RAB establishment after the RNC is receiving the RABAssignment Request on RANAP

6 There are a huge amount of failure causes, but not all related to RAB assignment failure.




Date: 2007-06-08 Rev: 2.1


• During the transition of CELL_PCH/URA_PCH to CELL_DCH mode(see also subsection 6.6) after the RNC is receiving the correspondingRACH messages

• In case service based data rate increase is triggered (see alsosubsection 7.2.3) after the RNC receives a corresponding RRCMeasurement Report from the UE

DBC thresholds can be defined for UL and DL load separately and DBC failurecan also occur at stages other than RAB establishment.

In case DBC grants the requested service the call handling proceeds asspecified (depending on the phase of the call), otherwise the call handling is asfollows:

• During the RAB establishment the RNC sends a RAB AssignmentResponse message on RANAP with specified cause “No resourceavailable” under “miscellaneous” class. On Uu the followingmessages/outcomes will be indicating that DBC has not granted the

requested service:

o The assigned PS RB is smaller than the default one or the onerequested in the PDP Context Activation message

7; the default PS

RB is configurable

OR the PDP Context Activation is rejected with an appropriatespecified cause like “QoS not accepted” or “Insufficient resources”

o The VT call is not granted or instead a voice call is setup

o The Voice call receives a CC Disconnect message with specifiedcause “resource unavailable”

• During the transition of CELL_PCH/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 setto CELL_PCH/URA_PCH.

• In case of service based data rate increase: the RRC MeasurementReport message is just ignored so the UTRAN is keeping the currentRB and Transport Channels

Not granting the requested service by DBC indicates either high cell loading oran area of high interference. The optimisation approach in the later case is tooptimise the RF environment in terms of reducing pilot pollution, improving RFcoverage, neighbour list optimisation etc.

DBC uses a QoS parameter in order to prioritise different user whendowngrading, see also [20] for details.


Table 28 is listing the identification techniques in traces in case DBC is notgranting the requested service:

7 The requested QoS profile in the PDP Context Activation message might be ignored and only a

default one is assigned




Date: 2007-06-08 Rev: 2.1



DBC RAB notgranted on Iu

Iu Any occurrence of a RAB Assignment Response message on RANAP withspecified cause “No resource available”

DBC RAB notgranted on Iuand Uu

Iu, Uu Cross-correlation Uu/Iu trace: Any occurrence of a RAB Assignment Responsemessage on RANAP with specified cause “No resource available”

DBC RAB PSnot granted

Iu or Iub,or Uu

Any occurrence of a SM Activate PDP Context Reject message sent by the CN tothe UE and the specified cause is “Insufficient resources”

DBC RB SetupPS

Uu On Uu, in the RRC RB Setup Message the IE “Spreading Factor” is larger than thedefault one and a PDP Context Activation message was sent within the last xseconds with the requested bit rate in the DL higher than the granted one

DBC RB SetupVT

Uu The VT call has been requested, the called entity is also a UE with VT capabilitiesbut a voice RB is setup

DBC RRCRelease

Uu Any occurrence of an RRC Cell Update/URA Update message following within xseconds a RRC Connection Release message with specified cause “congestion”

and the UE is in either CELL_PCH or URA_PCH mode

DBC RB Setupvoice

Uu The UE is sending a CC Setup message and within x seconds gets a CCDisconnect with cause “resource unavailable”

DBC Cell/URAupdate failed

Uu The UE is sending a Cell Update/URA Update message and the RNC is sendingback within x seconds a Cell Update Confirm/URA Update Confirm message withRRC State Indicator set to CELL_PCH/URA_PCH.

Table 28: Identification of DBC rejections in interface traces

For DBC related PM counters see [20] with a summarized version shown below.Note that <Cause> can be UL interference or DL power.

PMsystem

Counter / KPI Name / Description

UtranCell RAB.FailEstabCSNoQueuing.<Cause>

Number of RAB Establishment Failures due to a given cause for CSdomain.

UtranCell RAB.FailEstabPSNoQueuing.<Cause>

Number of RAB Establishment Failures due to a given cause for PSdomain.

Table 29: PM Counters indicating potential R99 DBC failures

5.4.2. Radio Link Reconfiguration

5.4.2.1. Concept

After DBC has taken place the RLs on the Iub have to be reconfigured using theRadio Link Reconfiguration procedure on NBAP. The flowchart can be seen inFigure 10.

The RNC tries to allocate resources on the Iub by sending a RL Reconfiguration

Prepare message on NBAP. The NodeB is answering by either sending a RadioLink Reconfiguration Ready (successful case) or Radio Link ReconfigurationFailure (unsuccessful case). The successful case ends in the RNC sending aRadio Link Reconfiguration Commit to the NodeB. This procedure is used toorder the Node B to switch to the new configuration for the Radio Link(s) withinthe Node B. The whole procedure is described in [7].


For the failure analyses please refer to subsection 5.1.5.2.




Date: 2007-06-08 Rev: 2.1


Table 30 below is listing the identification triggers for network interface traces,Table 31 the corresponding UTRAN KPIs.


Radio LinkReconfiguration Iub

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

Table 30: Identification of RL reconfiguration failures in traces

PMsystem


UtranCell (VS.RLM.AttRLReconfig – VS.RLM.FailRLReconfig.sum) /VS.RLM.AttRLReconfig * 100

Total radio link reconfiguration successrate

Table 31: PM KPIs for RL reconfiguration failures

5.4.3. Radio Bearer Establishment

5.4.3.1. Concept

Once the required resources have been successfully reconfigured in theNodeBthe RNC sends the Radio Bearer Setup message to the UE that sendsback the Radio Bearer Setup Complete message upon successfully allocatingresources for the new RB. The Radio Bearer Establishment procedure may failfor different reasons (see below); in that case the UE sends back a RadioBearer Setup Failure message to the RNC.

When a physical dedicated channel establishment is initiated by the UE, the UEshall start a timer T312 and wait for N312 successive “in sync” indications. Onreceiving N312 successive “in sync” indications, the physical channel isconsidered established and the timer T312 is stopped and reset. If the timer

T312 expires before the physical channel is established, the UE shall considerthis as a “physical channel establishment failure”. The whole procedure isexplained in [6].

Table 32 below is listing the parameters for the RB Establishment:


t312 The UTRAN parameter is configuring timer T312

n312 The UTRAN parameter is configuring N312

Table 32: Parameter important for the RB Establishment


In case the UE sends back the Radio Bearer Setup Failure message to theRNC 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 availableanymore from the code tree)

• Protocol Error




Date: 2007-06-08 Rev: 2.1


In general, the physical channel failure occurs when there is loss ofsynchronisation between UE and NodeB. This is mainly caused by poor RFconditions; see also subsection 6.1 and 6.4 for details. The other two causes

are expected to occur infrequently and in general are not related to RF issues.

The causes of the Radio Bearer Setup Failure message are listed in chapter10.3.3.13 in [6]. Again it is up to the UTRAN vendor, which cause out of this listis chosen for the particular failure that has occurred.

Table 33 is listing the identification techniques in traces, Table 34 thecorresponding PM KPIs for failures in the Radio Bearer Setup procedure:


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

Table 33: Identification of Radio Bearer Setup failures in traces

PMsystem

Counter / KPI8 KPI Name /

Description

RNC /Utrancell

RAB.FailEstabCSNoQueuing.RBSetupFail /CS RAB Attempts * 100

CS RAB establishment failurerate due to RB setup failure

RNC /Utrancell

RAB.FailEstabPSNoQueuing.RBSetupFail /PS RAB Attempts * 100

PS RAB establishment failurerate due to RB setup failure

Table 34: PM KPIs for Radio Bearer Setup failures

8 For corresponding definitions of CS RAB Attempts and PS RAB Attempts see [42].




Date: 2007-06-08 Rev: 2.1


6. Call Reliability (Retainability)This section is describing failures and occurrences that might happen after thecall has been successfully setup. This might endanger the single particular callto drop, but also the overall quality of the UMTS network as well as userperceived quality (section 7) might be degraded.

6.1. Call reliability – Radio Link Failure (RLF)

6.1.1. Concept

According to [11] the PHY in the NodeB and UE checks every radio frame thesynchronisation status. The status is indicated to higher layers using the CPHY-Sync-IND and CPHY-Out-of-Sync-IND primitives indicating in-sync state andout-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 onNBAP; the UL radio link sets are monitored to trigger if necessary RLF and RLRestore procedures. When the radio link set is in the in-sync state and theNodeB is receiving consecutive N_OUTSYNC_IND out-of-sync indications,NodeB starts timer T_RLFAILURE. The NodeB stops and resets timerT_RLFAILURE upon receiving successive N_INSYNC_IND in-sync indications.If timer T_RLFAILURE expires, the NodeB triggers the RLF procedure andindicates which radio link set is out-of-sync. In that case, the state of the radiolink set changes to the out-of-sync state and the NodeB indicates the RLF to theRNC by sending a Radio Link Failure Indication on NBAP with the cause“Synchronisation Failure” (see [7]).

Upon reception of this message the RNC starts timer T_RL_RESYNC (internalRNC timer defined by the UTRAN vendor). This timer is stopped and no furtheraction is taken if the RNC receives from the NodeB the NBAP Radio LinkRestore Indication message. The NodeB sends this message if the radio linkset is in the out-of-sync state and the NodeB is receiving successiveN_INSYNC_IND in-sync indications. The NodeB indicates which radio link sethas re-established synchronisation. When the RL Restore procedure istriggered, 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 inthe NodeB via the NBAP Radio Link Deletion procedure. After the deletion ofthe RL the RNC starts either

• With the Active Set Update procedure on RRC in case the UE is insoft/softer HO mode; note that this is not a dropped call (in terms RAB

or RRC drop)• Timer T314/T315 (configured by parameter T314rnc for CS / T315rnc

for PS, see also Figure 17) giving the UE the possibility to re-establishthe RRC connection. In case timer T314/T315 is expired the RNCreleases the call by sending RANAP Iu Release Request message withspecified cause “Release due to UTRAN generated reason” to the CN.Afterwards the RNC also releases the RRC connection by sending theRRC Connection Release message with cause other than “normalevent”. The identification of this event only with Uu traces is difficultbecause it is up to the UTRAN vendor of what kind of specified cause is




Date: 2007-06-08 Rev: 2.1


sent in case of an UL RLF. Finally the UE sends back a RRCConnection Release Complete and the procedure ends.

Figure 11 below is showing the call handling of the RAB release in case of adropped call:

CN

Figure 11: RLF is resulting in RAB drops

RLF and RL Restore in the DL:

The RLF procedure in the DL is supervised on RRC on the UE side.

In CELL_DCH state, the UE starts timer T313 after receiving N313 consecutiveout-of-sync indications for the established DPCCH physical channel. The UEstops and resets timer T313 upon receiving successive N315 in-syncindications.

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 reselectioncriteria and will initiate a Cell Update procedure with specified cause “radio link

failure” (chapter 8.5.6 in [6]).

Subsequently the RLF in the UL will be triggered when the UE is in idle modeby the UTRAN on its own accord.

Figure 12 below is showing the transitions between the different states; theinitial state of a RL is defined as the state when a new RL is to setup:




Date: 2007-06-08 Rev: 2.1


Figure 12: Transitions between different states

Table 35 below is listing the parameters that are configuring the RLF and RL

Restore procedure:


tRLFailure This parameter is defining the setting of T_RLFAILURE

noOutSyncInd This parameter is defining the setting of N_OUTSYNC_IND

noInSyncInd This parameter is defining the setting of N_INSYNC_IND

radioLinkFailureResynchronisationResponseTimer

Configure guard timer T_RL_RESYNC to allow time for re-synchronization to occur when a loss of synchronization isdetected on the last or only radio link associated with aUE connection.

RadioLinkFailureDeletionResponseTimer

Configure guard timer T_RL_RESYNC to allow time for thenormal operation of the handover and power control

algorithm to delete a radio link affected by a loss ofsynchronization or for re-synchronization to occur when theradio link is one of several associated with a UEconnection.

t313 This parameter is defining the setting of T313

n313 This parameter is defining the setting of N313



n315 This parameter is defining the setting of N315

Table 35: Parameter configuring the RLF and RL Restore procedure


There are a variety of causes responsible for RLFs possibly resulting in droppedcalls:

• Pilot pollution and around-the-corner effect (subsection 6.4.1)

• Weaknesses in the neighbour planning (subsection 6.4.4)

• Problems during (or before) the call establishment phase (section 5)

• Problems with the RF coverage (subsection 6.4.5)

• Problems with the SC plan (subsection 0)




Date: 2007-06-08 Rev: 2.1


For more information please take a look in these subsections.

A RLF in the UL that is causing a removal of a radio leg can be indirectlyidentified if there is no Measurement Report with type 1b/1c sent previously.Problem is that it can be that the Measurement Report message may not havebeen recorded resulting in false identification.

Identification of a dropped call due to RLF in the UL only with Uu traces isdifficult because the RRC Connection Release message sent by the RNC hasnot a unique cause id. For a reliable identification additional Iub tracing isrequired.

Dropped calls due to RLF in the DL can be easily identified in Uu traces with theCell Update message sent by the UE. There might be an optional failure causespecified. Please review the status of the IE AM_RLC error indication, whichcan be set to True. Other cell update failures are covered in subsection 6.3 and6.14.2.

Table 36 below is listing the identification possibilities for network interface

traces.


Dropped call dueto RLF in the DLon Uu

Uu Any occurrence of a RRC Cell Update message with specified cell update cause(not failure cause) “radio link failure”. Note that the dropped call is the previous calland not the current one! There might be an optional failure cause specified.

RLF and RLRestore on Iuband Uu

Iub andUu

Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link FailureIndication on NBAP with the cause “Synchronisation Failure” and after x secondsa Radio Link Restore Indication on NBAP

RLF and RLDeletion on Iuband Uu

Iub andUu

Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link FailureIndication on NBAP with the cause “Synchronisation Failure” and after x secondsa Radio Link Deletion on NBAP and the number of radio legs is more than one

RLF and dropped

call on Iub and Uu

Iub and

Uu

Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure

Indication on NBAP with the cause “Synchronisation Failure” and after x secondsa Radio Link Deletion on NBAP and the number of radio legs is equal to one

UL RLF and legremoval on Uu

Uu Any occurrence of an Active Set Update containing any entries in the group“RemovalInformationList” and there was no Measurement Report within x secondsbefore either with specified event id 1b/1c or without any specified event id

9

High UE Tx power Uu Any occurrence if the UE is transmitting with maximum allowed power for xseconds

High DL BLER Uu Any occurrence if the UE is reporting a BLER higher than x% for y seconds

Table 36: Identification of RLF in traces

Table 37 below is listing the identification possibilities using KPIs retrieved bythe UTRAN PM system. Refer to Figure 13 that shows at what point during thecall flow the PM counters are updated.

9 To be noted: the group “eventResults” containing the IE “eventID” is optional, for example when

periodic reporting is enabled.




Date: 2007-06-08 Rev: 2.1


PM

system


UtranCell VS.RAB.Drop.CS.DL_RLF/(RAB.SuccEstabCSNoQueuing.CSV+(RAB.AttEstabCS.CSV.RelocIratHO-RAB.FailEstabCSNoQueuing.CSV.RelocIratHO) +RAB.SuccEstabCSNoQueuing.CSD)*100

CS RAB Drop Rate due to DL RLF

UtranCell (VS.RAB.Drop.CSV.CauseULRLF+VS.RAB.Drop.CSD.CauseULRLF)/(RAB.SuccEstabCSNoQueuing.CSV+(RAB.AttEstabCS.CSV.RelocIratHO-RAB.FailEstabCSNoQueuing.CSV.RelocIratHO) +RAB.SuccEstabCSNoQueuing.CSD)*100

CS RAB Drop Rate due to UL RLF

UtranCell VS.RAB.Drop.PS.DL_RLF/RAB.SuccEstabPSNoQueuing.PS*100 PS RAB Drop Rate due to DL RLF

UtranCell VS.RAB.Drop.PS.DCH.CauseULRLF+VS.RAB.Drop.PS.HSDSCH.CauseULRLF+VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail/

RAB.SuccEstabPSNoQueuing.PS*100

PS RAB Drop Rate due to UL RLF

UtranCell VS.RAB.Drop.PS.DCH.CauseULRLF+VS.RAB.Drop.PS.HSDSCH.CauseULRLF+VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail

Total PS Dropped RABs cause UL RLF

UtranCell VS.RRC.AttConnRel.Drop.ULRLF/RRC.SuccConnEstab.sum*100 RRC connection drop rate caused byRLF

Table 37: PM KPIs indicating RLF

6.2. Call reliability – drop of the RAB

6.2.1. Concept

RAB drop due to UTRAN reasons

The drop of the RAB that is caused by a failure within the UTRAN is always

initiated by an Iu Release Request message on RANAP with cause “Releasedue to UTRAN generated reason”; the call handling is shown in Figure 11. TheCN will send back an Iu Release Command message on RANAP with the samespecified cause (chapter 9.2.1.4 in [9]). After sending this message the UTRANwill release the RRC connection (subsection 6.3).

To be noted that this does not mean the PDP context is removed, but e.g. aFTP session that is up and running might time out. The UE can re-establish theRRC connection after doing a cell reselection by sending RRC ConnectionRequest message with establishment cause “Call re-establishment” (subsection7.2.3).

There are a variety of reasons why the RAB drops due to UTRAN reasons:

• RLF (subsection 6.1) because of e.g. RF issues (subsection 6.4)

• Hardware failures and outages on UTRAN (subsection 6.8)

• Failures that occurred on NBAP (e.g. subsection 5.4.2)

• General drops of the RRC connection (subsection 6.3)

• (…)

For the reasons of these failures please refer to the corresponding sections.

RAB drop due to CN reasons




Date: 2007-06-08 Rev: 2.1


RAB drops that are not caused within the UTRAN can be identified by the IuRelease Command message on RANAP; the specified cause is other than“Release due to UTRAN generated reason” and “normal-release”.

The specified cause is vendor dependent. For the root cause analysis pleasecheck with the corresponding UTRAN vendor documentation and thedocumentation of the CN vendor.

Figure 13: Drop of the RABs after RLF


Table 38 is showing the identification techniques in interface traces:




Date: 2007-06-08 Rev: 2.1



RAB drop due toUTRAN reasonson Iu

Iu Any occurrence of an Iu Release Request message with cause “Release dueto UTRAN generated reason” on Iu

RAB drop due toUTRAN reasonson Iu and Uu

Iu and Uu Cross-correlation Iu and Uu: Any occurrence of an Iu Release Requestmessage with cause “Release due to UTRAN generated reason” on Iu

RAB drop due toCN reasons on Iu

Iu Any occurrence of an Iu Release Command message with cause other than“Release due to UTRAN generated reason” or “normal-release” on Iu

RAB drop due toCN reasons on Iuand Uu

Iu and Uu Cross-correlation Iu and Uu: Any occurrence of an Iu Release Commandmessage with cause other than “Release due to UTRAN generated reason” or“normal-release” on Iu

Table 38: Identification of RAB drops in network interface traces

There are different PM KPIs describing RAB drops defined inchapter 5, and following in [42]. The different PM KPIs describing RAB dropsare differentiated as follows:

• CS/PS RAB drops

• Reason (due to UE inactivity, due to DL power, due to Inter-frequencyHHO, UE Poor Quality Minimum Rate, SRNS Relocation, …)

• RNC level and Utrancell level

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 RRCconnection can be identified as follows:

• The RNC sends a RRC Connection Release message with specifiedcause ”unspecified” or “pre-emptive release”

10

• The UE sends a Cell Update message with cell update cause “radio linkfailure” or “RLC unrecoverable error” and/or AM_RLC error indication isset to TRUE (see below)

• The UE sends a RRC Connection Request message with cause “Callre-establishment” (see comments in subsection 6.2.1 and 7.2.3)

• RRC Cell Update message with specified failure cause and with a cellupdate cause other than “radio link failure” or “RLC unrecoverableerror” (these failures are covered in subsections 6.1 and 6.14.2; forthese two failures it might be that in addition a failure cause is specified;this is up to the UTRAN vendor

11).

•

For the variety of reasons of dropped calls (paging, RLF, Random Accessprocedure etc.) please refer to the corresponding subsections in this document.

Note that the IE “AM_RLC error indication” in the Cell Update/URA Update isspecifying whether an error occurred on the RLC or not. If this IE is set to TRUE

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

11 The likelihood of this is not very high because the specified failure causes do not match to the cell

update causes




Date: 2007-06-08 Rev: 2.1


it is indicating that the RLC in the UE has detected a failure on one of its AMRLC entities that has not been resolved by e.g. resetting of the RLC [36]. Formore details regarding failures on the RLC see subsection 6.14.

If there is a RRC Connection Release message with cause “congestion” thereason might be either Dynamic Bearer Control (subsection 5.4.1) orCongestion Control (subsection 6.5).

Ex-Lucent supports the RRC connection re-establishment for PS, CS andsimbearer services, where by on detection of the RLF, the UE sends a cellupdate with cause “RLF” and consequently old radio links are deleted and thenew radio links are established by the RNC.

This procedure fails if the UE does not send the cell update, a RANAPprocedure 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, aRANAP procedure is in progress or UE indicates that the T314 or T315 timerhas expired.

"RRC ConnectionRe-Establishment Fe

Figure 14: DL RLF and RRC re-establishment

UE Node B RNC CN

6) Radio Link Setup Response

5) Radio Link Setup

8) Cell Update Confirm

9) Radio Bearer Reconfiguration Complete

7) ALCAP & FP Synch

1) Cell Update (Cause Radio Link Failure)

10) UE Measurements

3) Radio Link Deletion Response

2) Radio Link Deletion Request

New radio linksbased upon

measur ed Ec/Io

UE Moved back

to Cell DCH

4) ALCAP Release

RNC suspends

RLC, MAC




Date: 2007-06-08 Rev: 2.1


Figure 15: UL RLF and RRC re-establishment


Table 39 and Table 40 below listing the identification of dropped RRCconnection and the PM KPIs:


Drop of RRCconnection I

Uu Any occurrence of a RRC Connection Release message on Uu with specifiedcause ”unspecified” or “pre-emptive release”

Drop of RRCconnection II

Uu Any occurrence of a RRC Connection Request message on Uu withestablishment cause “Call re-establishment”

Drop of RRCconnection III

Uu The UE is simply going to idle mode without dropping the call in a regular way.There are no RRC/Direct Transfer messages indicating a regular/irregular calltermination within x ms. The UE start monitoring the BCCH and might performa cell re-selection following a Cell Update with cause “RLF” or “RLCunrecoverable error” (see also Table 36 on page 46).

Drop of RRCconnection IV

Uu RNC sent a ‘Cell update confirm’ but the UE didn’t respond back with a ‘RBreconfiguration complete’ within x seconds showing failure of the re-establishment

Table 39: Identification of dropped RRC connections in interface traces

PMsystem


Utrancell VS.RRC.AttConnRel.Drop.ULRLF /RRC.SuccConnEstab.sum*100

RRC Connection drop rate causedby RLF

Table 40: PM KPIs of dropped RRC connections

UE Node B RNC CN

7) Radio Link Setup Response

6) Radio Link Setup

9) Cell Update Confirm

10) Radio Bearer Reconfiguration Complete

8) ALCAP & FP Synch

T_RL_RESYNCHexpires, UE is PS

only

5) Cell Update (Cause Radio Link Failure)

11) UE Measurements

1) Radio Link Failure Indication

3) Radio Link Deletion Response

2) Radio Link Deletion RequestRNC suspends

RLC & MAC,

Starts Timer

RNC stops

Timer

New radio links

based upon

measured Ec/Io

UE Moved back

to Cell DCH

T_RL_RESYNCH

4) ALCAP Release




Date: 2007-06-08 Rev: 2.1


6.4. Call reliability – RF planning related issues

6.4.1. Introduction

A detailed explanation of how to improve the RF environment is given in [33].This guideline only briefly provides the techniques to identify these issues usingUu traces and 2G/3G scanner measurements.

There are no specific PM counters available that could differentiate RRC andRAB drops in terms of e.g. pilot pollution, round-the-corner effect etc. For thatreason no PM KPIs describing dropped calls are listed in this subsection,reference the corresponding subsections 6.1, 6.2 and 6.3.

6.4.2. Pilot pollution

6.4.2.1. Concept

Pilot pollution means an excessive overlapping of coverage footprints ofdifferent cells with no dominant pilot. This leads to poor Ec/Io ratios. As a

consequence, the RLF could fail due to out-of-synchronisation (subsection 6.1).Pilot pollution is in particular an issue when the number of best cells within acertain range is exceeding the maximum size of the cells in the active set. Inthis case the cells that cannot be included into the active set are decreasing thequality of the signal.

Remark:

Because in HSDPA there is no soft/softer HO gain in the downlink HSDPA ismuch more sensitive to pilot pollution compared to R99 services, see alsochapter 6.15 for details.


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

cells in the active set is a good metric of how well defined are the handoverzone within the UMTS network.

Table 41 is listing identification techniques in drive test and scannermeasurement data:


Pilot pollution I UE or 3Gscanner

There are more than x cells with a measured Ec/No within x dB compared tothe best measured Ec/No

Pilot pollution II UE or 3Gscanner

The aggregate Ec/No of the cells in the active set is below x dB while themeasured RSCP is above y dBm for z ms

High number ofcells in active set

Uu The active set size is > 1 in more than x % of all measured samples12

.

Overshooting

cells

UE or 3Gscanner

The Ec/No of a site y km away is within x dB of the best measured Ec/No

Table 41: Identification of pilot pollution

12 This is not really a problem to be identified in a trace; it is more an indication for in general non-

optimal RF conditions.




Date: 2007-06-08 Rev: 2.1


6.4.3. Around-the-corner-effect

6.4.3.1. Concept

Around-the-corner-effect is quite often encountered in a dense urbanenvironment. The effect describes a moving UE where the receive level of thecells in the active set decreases dramatically (in terms of Ec/No and RSCP)whereas the receive level of cells in the monitored or detected set suddenlyincreases. The root cause for this problem is shadowing of buildings or otherobstructions. As a consequence the quality of the call will always drop if the UEis 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

Active Set Pilot

Interfering Pilot

Figure 16: Around-the-corner problem

To overcome around-the-corner problem local optimisation of the RFenvironment is required. In addition the RF planer has to ensure that theparameters configuring the handover procedure is fast enough (subsection 6.9).

A detailed explanation of how to improve the RF environment is explainedin [33].


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


Around-the-cornereffect I

Uu Sudden drop/increase of the Ec/No of cells in the active set by x dB for thenext at least y ms; the average aggregate Ec/No is below z dB

Around-the-cornereffect II

Uu Sudden drop/increase of the RSCP of cells in the active set by x dB for thenext at least y ms; the average aggregate RSCP is below z dBm

Table 42: Identification of around-the-corner effect




Date: 2007-06-08 Rev: 2.1


6.4.4. Non-optimal neighbour definitions

6.4.4.1. Concept

One of the essential tasks of RF planning is neighbour list assignment. Whenthe neighbour lists are not well defined the UE might not be on an optimal cell(or set of cells) and the call is endangered to drop.

The following neighbour lists exist in the OMC:

• 3G-3G soft/softer MAHO list

• 3G-3G soft/softer DAHO list

• 3G-2G neighbour MAHO list

• 3G-2G neighbour DAHO list

• 2G-3G neighbour list

The parameters configuring the intra-frequency soft/softer HO are listed in

subsection 6.9, IRAT parameter settings are covered in subsection 6.10. Thissubsection is focused on the integrity of the different neighbour lists definitionsitself.

To maintain the integrity of the different HO list it is required to use a databasesystem 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 identicalcoverage footprint for a possible DAHO 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 identicalcoverage footprint for a possible DAHO definition)

o BCCH frequency

• Different neighbour lists including

o nLSAPriority flag for 3G-3G HO definition (see also subsection6.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 nLSAPriority flag

• Check for missing DAHO definitions

Figure 17 below is showing a sample database in MS Access format:




Date: 2007-06-08 Rev: 2.1


Figure 17: neighbour list checking using MS Access

The RF template files that are converting OMC XML data into MS Excel formatcan be reused for these kinds of consistency checks see also [43] for details.Some consistency checks are also available in the Ex-Lucent Intranet [44].Some ex-Lucent tools like LDAT [49] have the missing neighbour list analysisfeature that can be used to debug.


Following methods can be used to fix/detect a non-optimal neighbour listassignment:

• Cross-correlation of Uu drive test logs with 2G/3G scannermeasurements

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

o Missing 3G-2G neighbour definition: the measured RSSI isrelatively low and the GSM coverage footprint is relatively strongas measured by the 2G scanner, but the IRAT handover is nottriggered




Date: 2007-06-08 Rev: 2.1


o Missing 2G-3G neighbour definition: UE is staying in 2G althoughthere is sufficient 3G coverage as indicated by the RSSImeasurements of the 3G scanner

o Analysis of the UE Measurement Reports: the UE might reportcells of the detected set but these cells are not defined in theNLSA (see also subsection 6.9 and [23] for details)

• Analysis of the handover matrix as available in the PM system (seebelow)

• RF prediction tool analysis, see also [33] and [34]

Example for an analysis of the PM Handover matrix

The following is giving an example of the analysis of the IRAT HO matrix.

In the PM system the IRAT HO Matrix is given as follows:

• NumUMTS.GSM.HOPerNCell.Att

• NumUMTS.GSM.HOPerNCell.Fail

• NumUMTS.GSM.HOPerNCell.Ncell.CI

• NumUMTS.GSM.HOPerNCell.Ncell.LAC

• NumUMTS.GSM.HOPerNCell.Ncell.MCC

• NumUMTS.GSM.HOPerNCell.Ncell.MNC

The counters have to be imported into a database as described in [45].Afterwards the analysis can be done using SQL queries with the focus on

• Deletion of unnecessary handover definitions

• Investigation of high amount of HO failures

In a similar way the intra-frequency HO matrix can be analysed.Table 43 below is listing the identification possibilities for network interfacetraces, Table 44 is listing the identification possibilities using KPIs retrieved bythe UTRAN PM system:


Missing 3G/3Gneighbour definition

Uu, 3Gscanner

Any occurrence where the measured RSSI (retrieved by 3G scanner) iswithin a xdB window compared with the measured aggregate RSCP of thecells in the active set (measured by the UE) for y seconds; at the time ofthe measurement the UE is in 3G

Missing 3G/2Gneighbour definition

Uu, 2Gscanner

The measured RXLEV of the best 2G cell (measured by the 2G scanner) iswithin a xdB window compared to the measured aggregate RSCP of thecells in the active set (measured by the UE) for y seconds; at the time of

the measurement the UE is in 3GMissing 2G/3Gneighbour definition

Uu, 3Gscanner

Any occurrence where the measured RSSI (retrieved by 3G scanner) iswithin a xdB window compared with the measured RXLEV of the 2Gserving cell (measured by the UE) for y seconds; at the time of themeasurement the UE is in 2G

Table 43: Identification of non-optimal neighbour definitions in traces




Date: 2007-06-08 Rev: 2.1


PMsystem


UtranCell (VS.MX.HHO.IntraFreq.Succ /VS.MX.HHO.IntraFreq.Att) * 100 Intra-frequency HHO success rateper neighbour cell

UtranCell ((HHO.SuccOutInterFreq.Qual + HHO.SuccOutInterFreq.Load) / (HHO.AttOutInterFreq.Qual +HHO.AttOutInterFreq.Load)) *

100

Inter-frequency hard handoversuccess rate

UtranCell (RRC.SuccConnEstab.IratCCO /RRC.AttConnEstab.IratCCO) * 100

Incoming IRAT PS success rate(GSM -> UMTS)

UtranCell ((IRATHO.AttIncCS - IRATHO.FailIncCS.sum) /IRATHO.AttIncCS) * 100

Incoming CS Inter RAT handoversuccess rate (GSM->UMTS)

UtranCell (IRATHO.SuccOutPSUTRAN /IRATHO.AttOutPSUTRAN)*100

Outgoing PS Inter RAT handoversuccess rate (UMTS->GSM)

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

Table 44: PM KPIs identifying non-optimal neighbour definitions

6.4.5. Poor RF coverage

6.4.5.1. Concept

Especially in the early days of 3G there will be many areas with a poor RFcoverage. 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 toguarantee for some services like 384 kbit/s sufficient RF coverage. When thishappens either the radio bearer has to be reconfigured due to an increasingBLER in the DL when using a PS data service (subsection 6.17.1 and 7.1.1) ora 3G/2G IRAT handover has to be triggered to rescue the call (subsection6.10).

In subsection 6.7.1 a drop of the RRC is described for a mobile in CELL_FACH

mode. In subsection Error! Reference source not found. a similar scenario isdescribed for a UE in CELL_PCH/URA_PCH mode.


Low RF coverage can be identified as follows:

• Low receive level in terms of RSSI (means low measured RSCPvalues)

• 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 becrosschecked with the FM data (see also subsection 6.8).

Table 45 below is listing identification triggers for low RF coverage in networkinterface traces:


Low RFcoverage I

3G scanneror Uu

Measured RSSI of the 3G cells is below x dBm for y seconds

Low RFcoverage II

3G scanner,Uu

Measured aggregate RSCP of the cells in the active set is below x dBm for yseconds and there is no RSCP of a 3G cell measured by the 3G scannerbetter than z dB compared to the aggregate RSCP

Low RF Uu, RFCT The reported NodeB TX power is for x second above y dBm and the measured




Date: 2007-06-08 Rev: 2.1


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 yseconds

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

6.4.6. Poor PSC plan

The PSC is used for cell identification during the initial cell search and whenmeasuring the neighbour cells in idle and connected mode. Different strategiesand a guideline for PSC planning and how to unveil weaknesses in the PSCassignment are described in [33].

In case the rules in that guideline are not followed the UE may make failures inthe neighbour list measurements or in case of overlapping coverage areas oftwo NodeBs sharing the same PSC, interference and synchronisation issueswill occur. This will be the case if an overshooting site has the same PSC asone of the cells in the active set causing co-pilot interference or if theneighbours of the two existing active set cells share the same PSC creating NLambiguity.

It is hardly possible to identify PSC issues in drive test data because themeasured low Ec/No values or even RLF can also be the result of pilot pollutionor around-the-corner effect (subsection 6.1 and 6.4.1). Also there are nospecific PM counters that may track these issues.

6.5. Call reliability – Congestion Control (CongC)

6.5.1. Concept

The Congestion Control (CongC) function is used to monitor, detect and handlesituations when the system is going into overload or getting close to an overloadsituation. CongC is based on UL and DL load estimations. CongC handles

users already in connected mode.

Congestion control is configurable using UTRAN parameters; the algorithm isproprietary, see reference UTRAN vendor documentation. The RNC can initiatethe following actions for already connected users to resolve the overloadsituation:

• Transit (several or all) users connected to PS data services to a lowerbit rate (e.g. from 384 kbit/s to 128 kbit/s)

• Transfer of (several or all) PS data users to another state e.g. fromCELL_DCH to CELL_FACH, idle or URA_PCH/CELL_PCH or fromCELL_FACH mode to URA_PCH/CELL_PCH or idle mode (subsection6.7 and 6.6).

• Start dropping (several or all) RRC connections of non PS users

The lowering of the PS data rate is done by using either the RB Reconfigurationprocedure or the Transport Channel Reconfiguration procedure (subsection6.17.1).

The state transfer is done by the RRC Connection Release procedure (transferto idle mode, RAB is released) or by the RB Reconfiguration procedure (transferto CELL_FACH or URA_PCH/CELL_PCH mode, RAB is set to inactive); in bothcases the PDP context is retained.




Date: 2007-06-08 Rev: 2.1


Dropping of the RRC connection is done using the RRC Connection Releasemessage with specified cause “congestion”.

The initiating of CongC is indicating a high noise raise of the RF environment.The only optimisation approach in that case is to optimise the RF environmentin terms of pilot pollution, neighbour list optimisation etc.

More detailed information can be found in [20].


Table 46 is listing the identification techniques in traces in case of CongC,relevant PM KPIs are also listed in [20].


CongC RRCRelease

Uu Any occurrence of an RRC Connection Release message withspecified cause “congestion” and the UE is either in CELL_FACH orCELL_DCH PS mode

13

CongC RRC PSdata reduction DL

Uu, TCP/IP tracein or after CN

Cross-correlation of interface traces on Uu and TCP/ in or after CNside: Any occurrence when either the PS data rate is reduced or theUE is transferred from CELL_DCH to CELL_FACH / CELL_PCH /URA_PCH mode and at the same time there is still data in the RLCbuffer of the RNC as measured in Ethereal

Table 46: Identification of CongC in interface traces

6.6. Call reliability – failures in URA_PCH/CELL_PCH mode

6.6.1. Concept

When the UE is in CELL_PCH or URA_PCH, the RRC Connection ismaintained using common physical channels (RACH in the UL and the PCCH inthe DL). On the UTRAN side no dedicated radio resources are allocated(means no RB on RRC and RL on NBAP). On the CN side there is always a

RAB associated with the RRC connection but the RAB is marked (inside theRNC) as inactive. When there are any data coming from the CN side, the RLCbuffer in the RNC belonging to the RAB is buffering the data and the RNC willinitiate a state transition of the UE to deliver the DL data. For TCP applicationsthis is appropriate because TCP traffic always starts using the Slow Startprocedure, but for UDP or RTP this might result in lost data frames.

The UE can send data via the RACH in UL. The UE might indicate to the RNC ifthe UE RLC buffer is filled up rapidly by sending RRC Measurement Report 4aon RACH. The UTRAN may or may not initiate a state transition. The behaviouris UTRAN vendor dependent and configurable via O&M parameter.

According to [6] the UE has to monitor the PICH and PCH, do periodicalURA/PCH updates and perform cell reselections.

In might be that URA_PCH/CELL_PCH mode is not used. Instead for a PS callwhen the inactivity timer elapsed the RRC resources are released whilemaintaining the PDP context; the UE is sent to idle mode. The associated RABis removed.

The advantage of the URA_PCH/CELL_PCH mode compared of the idle modeis that the re-establishment can be done faster because the RAB and RRC

13 Note that when the UE is in URA_PCH mode or CELL_PCH mode the release message with cause

“congestion” is used when DBC is triggered.




Date: 2007-06-08 Rev: 2.1


connection does not need to be re-established again. Disadvantage is that thereare still some (very low) UTRAN resources the RNC has to maintain.

Figure 18 below is showing the transition phases between different UE states:

Cell DCH

DCH

URA_PCH /CELL_PCH

Cell FACH

IDLE

Cell DCH

HSDPA

Figure 18: Transition phases between the different UE states


Failures and dropped RRC connections when the UE is in URA_PCH orCELL_PCH mode might occur in the cell selection/reselection process(subsection 5.1.1), failures due to periodical URA/PCH updates (subsection5.3.1). For dynamic bearer control (DBC) failures see subsection 5.4.1. Failuresdue to PCH/AICH/PICH or the RACH procedure might lead to a drop of theRRC connection and drop of the PDP context as described in subsection 5.1.2.In this case the RAB will be removed.

Failures due to the RB Reconfiguration procedure are described in subsection6.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 inCELL_FACH mode camping on one cell in order to save battery and RFnetwork resources. The UE has no dedicated UTRAN radio resources; the RRCconnection is established using the common channels (FACH in the DL and theRACH in the UL), on Iub there are no reserved resources available. There isalways a RAB associated with the RRC connection because any DL datareceived by the GGSN has to be forwarded to the UE. The concept is similar tothat described in subsection 6.6.1; difference is that a state transition is notmandatory (but might be useful).




Date: 2007-06-08 Rev: 2.1


According to [6] the UE has to monitor the FACH transport channels in thedownlink. The UE in CELL_FACH mode informs the UTRAN when reselecting anew 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 procedureends with the UE sending an UTRAN Mobility Information Confirm messageagain on RACH.

The SRNC decides whether or not to transit the UE to another state. Figure 18is showing the different UE states and possible transition between them. In allcases the RNC will initiate the transition by using either the RB Reconfigurationor the Transport Channel Reconfiguration procedure on RRC (subsection6.17.1). It might be necessary to either delete or setup resources on the Iub viathe corresponding NBAP procedures (exception is the transition fromCELL_FACH to URA_PCH/CELL_PCH but this should occur rarely).

The algorithms are vendor dependent taking into account traffic measurementsand the RF environment. Please check in the particular UTRAN vendorparameter description.

Figure 19 and Figure 20 below are visualising the call handling for the transitionfrom CELL_DCH to CELL_FACH and vice versa:

Figure 19: Call handling for transition from CELL_DCH to CELL_FACH




Date: 2007-06-08 Rev: 2.1


Figure 20: Call handling for transition from CELL_FACH to CELL_DCH

The RNC may decide to release the RRC connection due to e.g. CongC. In thiscase the RNC sends a RRC Connection Release message on FACH and theUE sends back a RRC Connection Release Complete message on RACHbefore transiting to idle mode. In parallel the RAB will be released.

A drop of the RRC connection might occur if the UE is leaving the RF coveragearea and then when coming back the UE has to inform the UTRAN by sendinga Cell Update message with cause “Re-enter service area”. In the meantime theUTRAN might already have dropped the RRC if it had tried and failed to sendPS data in the DL.

6.7.2. Failure symptoms, identification and fixes for improvementThe following failures might occur for UEs in CELL_FACH mode or during thetransition 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/ TransportChannel Reconfiguration procedure on RRC (subsection 6.17.1)

Table 47 is listing failures for UEs in CELL_FACH mode and how to identify it intraces:


Dropped call inCELL_FACH

Uu Any occurrence when the RRC connection dropped while the UE was inCELL_FACH state

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




Date: 2007-06-08 Rev: 2.1


There are a lot of PM counters available counting the number of attempts andfailures for the state transitions, see [42] for details.

6.8. Call reliability – hardware and network interface outages6.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. Thereare many reasons for outages; analysing the retrieved FM data can give a goodindication for the failure cause.

Outages may lead to drops of the RAB and the RRC connection because ofmissing synchronisation. Furthermore coverage issues (subsection 6.4.5),problems in the neighbour definition (subsection 6.4.4) and problems in thecell/PLMN selection/reselection procedure (subsection 5.1.1) may also occurleading to dropped calls and network degradation even on NodeBs not affectedby the outages.


Outages can be easily identified when tracing the interfaces that have been out-of-sync. Table 48 is listing possibilities of detecting the outages:


Iub out-of-sync I Iub Missing STAT PDUs on AAL5 for more than 5 seconds

Iub out-of-sync II Iub Any occurrence of an AuditRequiredInformation on NBAP

Iu out-of-sync I Iu Missing STAT PDUs on AAL5 for more than 5 seconds

Iu out-of-sync II Iu Any occurrence of an Reset on RANAP

Table 48: Identification of outages in network interface traces

6.9. Call reliability – intra frequency handover

6.9.1. Concept

In UMTS networks intra-frequency soft/softer handover is one basic feature thatensure seamless mobility as well as call performance and quality improvement.

The soft/softer handovers can be either requested by the UE (mobile evaluatedHO) or can be triggered by the UTRAN (network evaluated HO). In addition it isassumed that the reporting criteria are set to “event triggered” rather than“periodically”. All intra-frequency measurement reporting events (1a to 1i) aredefined in [6].

According to [12] the soft/softer HO procedure consists of the following steps:

• Cell search and measurements of cells in the active set and themonitored set

• Reporting of measurement results by the UE (RRC MeasurementReport message including specified event id)

• The HO algorithm

• Allocation/release/change of network resources on NBAP

• Execution of the HO (RRC Active Set Update message) by the RNC

• If necessary execution of RNS relocation procedure (subsection 6.17.3)




Date: 2007-06-08 Rev: 2.1


• Active Set Update Complete message on RRC from UE (successfulcase)

•RNC updates the measurement parameters including cells belonging tothe new monitored set and other measurement parameters via the RRCMeasurement Control Message

The different steps are configurable using UTRAN O&M parameters. As anexample Figure 21 below is visualising the HO parameter like time to trigger

(∆T) and the HO hysteresis for the Measurement Report events 1a, 1b and 1c:

Figure 21: HO parameter for event 1a, 1b and 1c

The call handling depends on the type of event; as an example Figure 22 belowis showing a flowchart for an intra-RNC Active Set Update procedure of typeevent 1a (the grey box contains the RL deletion in case of event 1c):




Date: 2007-06-08 Rev: 2.1


Figure 22: Call handling flowchart of Active Set Update event 1a (event 1c)HO related parameters and more detailed information about the Ex-Lucentimplementation is available in [23].


There are many different reasons why the HO procedure might fail or notexecuted 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. (seesubsection 6.4 for details)

• Misconfiguration of UTRAN parameter setting up the filtering, timingand HO algorithm

• Problems with the allocation of network resources on NBAP: Radio LinkSetup procedure in case no RL exists to the particular (new) NodeB(subsection 5.1.5) and Radio Link Addition procedure in case there isalready a RL to the NodeB

• Problems during RNS relocation procedure are covered in subsection6.17.3

• Failures during the release of network resources on NBAP (e.g. event1c); these failures should occur very rarely (subsection 6.17.4)




Date: 2007-06-08 Rev: 2.1


• Measurement Control Failure message (e.g. because the UTRANinstructs the UE to perform a measurement that is not supported by theUE)

• 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 The UE is in a wrong state to receive that message (meansanother state than CELL_DCH)

o Protocol error

o Physical channel error

o (…)

The filtering, timing and HO algorithm are configurable by UTRAN parameter.For each UTRAN vendor default parameter settings should be in place.Especially in dense urban environment these parameter had to be optimisede.g. to react faster to the around-the-corner effect or in areas with weakcoverage to trigger the 3G-2G HO faster.

Table 49 below is summarising how to identify these issues in network interfacetraces. Note that the handover delay can be confused with missing RRCmessages (check event id of Measurement Report with removal/addition list ofASU message). Long handover delays can result in dropped calls and in adecrease of the overall UMTS RF conditions.


Intra Frequency HandoverDelay

Uu Any occurrence where the UE sends a Measurement Report 1xand the RNC does not reply with an Active Set Update messagewithin y seconds

Active Set Update Failure Uu Any occurrence where the UE is sending an Active Set UpdateFailure message

Long delay of MeasurementControl message after ActiveSet Update Complete for event1x

Uu Any occurrence where the RNC is not sending the MeasurementControl message within y seconds after the UE has sent the ActiveSet Update Complete message and the event ID of the lastMeasurement Report has been event 1x

14

Dropped call during event 1x Uu Any occurrence of a dropped call within y seconds after the RNChas sent an the Active Set Update message and the event ID ofthe last Measurement Report has been event 1x

HO event 1a/1c is too slow Uu, 3Gscanner

There is one (or more) intra-frequency cell measured by the 3Gscanner that is not in the active set and its Ec/No is for x secondsbetter than y dB compared to the best cell in the active set and the

UE is not sending within that time period a Measurement Reportwith id 1a or 1c

Ping-pong HO Uu Whenever a cell is added to the active set (event 1a) , it isremoved within x seconds again (event 1b or 1c) or vice versa

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

Table 49: Identification handover issues in traces

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




Date: 2007-06-08 Rev: 2.1


PM KPIs related to the intra-frequency handover process are available in [23].

6.10. Call reliability – IRAT handover

6.10.1. Concept (UMTS->GSM)

IRAT handover are used to maintain the UMTS voice call in case the 3G RFcoverage and/or quality is not sufficient. Furthermore they can be used for trafficdistribution. IRAT handovers are always hard handovers and can be eithermobile assistant or database assistant.

Two different procedures might be used:

Procedure 1:

The measurement reporting and filtering methods are similar to the one of theintra-frequency handover as explained in subsection 6.9. When the measuredEc/No or RSCP of the cells in the active sets drops below a certain threshold,

the UE sends a Measurement Report “2d” to the RNC and after receiving theRB Reconfiguration message from the UTRAN goes in compressed mode tostart the IRAT measurements as specified in the Measurement Controlmessage. When the measured Ec/No or RSCP of the cells in the active setsexceeds a specific threshold the UE sends a Measurement Report “2f”. The UEmay then leave compressed mode after it receives the Measurement Controlmessage with IE “tgps-Status deactivate”.

While in compressed mode, if the measured level on the GSM/GPRS systemexceeds a predefined threshold and the measured Ec/No or RSCP of the cellsin the active set is below a predefined threshold, the UE sends theMeasurement Report “3a”. The UTRAN/BSS might decide to trigger the IRAThandover by sending the Handover From Utran command on RRC.

Procedure 2:

This procedure is using Measurement Report “1f” and Measurement Report“6a” based on which UTRAN may send the UE (via RB Reconfigurationmessage) into compressed mode. The RNC sends two Measurement Controlmessages (a short one defining when the UE will automatically leavecompressed mode as specified by IE TGPS and a following MeasurementControl message with the IRAT handover list including BSIC and BCCH; the IE“BSIC verification required” is set to “not required”). The UE is now starting toperiodically report the BCCH and RXLEV, but not of the BSIC. The UE maysend in between a Measurement Report “1e” including SC and measured Ec/Noand/or RSCP of a 3G cell exceeding the “1e” threshold; the RNC may or maynot react on this Measurement Report by sending an Active Set Updatemessage.

Meanwhile the UTRAN may send another Measurement Control message

including a modified (shorter) GSM neighbouring list to measure, but now the IE“BSIC verification required” is set to “required”. The UE is continuing reportingthe IRAT neighbouring cells, but now not only the BCCH and RXLEV, but alsoincluding the decoded BSICs.

After some time the UE either automatically leaves compressed mode or theUTRAN selects one of the reported GSM cells as handover candidate bysending the Handover From Utran command on RRC.




Date: 2007-06-08 Rev: 2.1


Figure 23 below shows the call flow chart across the UMTS and GSM networkfor performing UMTS to GSM voice handover including the UMTS and GSMCN:

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

The major components that constitute failures of UMTS to GSM Handover maybe classified as following:

• RB reconfiguration failures when entering/leaving compressed mode(subsection 6.17.2/not in this figure)

• Relocation procedure failures (subsection 6.17.3/phase 1 in figure)

• Handover procedure failures in GSM network (phase 2 in figure)

• Release procedure failures (subsection 6.17.4/phase 3 in figure)

Upon successful completion of the relocation procedure, the SRNC sends theHandover From UTRAN Command including the GSM Handover Command to




Date: 2007-06-08 Rev: 2.1


the UE. If the UE fails to complete the requested handover then the SRNCreceives a Handover From UTRAN Command Failure message from the UE.According to [9] the failure causes specified within this message can be

subdivided as follows:

• Physical channel failure

• Unacceptable configuration

• Protocol error

The first failure refers to the case when there is loss of synchronisation betweenUE and NodeB. This is mainly caused by poor RF conditions. The other twocauses are expected to occur seldom and in general are not related to RFissues.

The IRAT HO can be configured with the parameters as described in [25].

More information about IRAT Handover optimisation is available in [46].

6.10.2. Failure symptoms, identification and fixes for improvement (UMTS->GSM)

In case of a high failure rate during the IRAT handover procedure it should bechecked if the HO has to be triggered earlier under better 2G and 3G radioconditions.

Table 50 below is listing the identification triggers for IRAT HO problems intraces:


Delayed IRAT HOafter event 3a

Uu Any occurrence of a Measurement Report 3a sent by the UE, but there is noHandover From UTRAN Command within x seconds

Handover From

UTRANCommand Failure

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

by the UE

RRC drop incompressedmode

Uu Any occurrence of a drop of the RRC connection when the UE was incompressed mode

Table 50: Identification of IRAT HO problems in traces

6.10.3. Concept (CS GSM ->UMTS)

The IRAT for GSM to UMTS would allow the operator to make use of the 3Gcoverage in case of GSM network overload or simply to maximise the usage ofUMTS network. However the HO is actually initiated by the GSM network andhence not discussed any further. This HO is limited to CS calls and in case ofcombined CS/PS call the UE is required to setup the PS part of the call uponsuccessful completion of CS handover.

The following figure shows HO execution signaling flow that starts with the RNCreceiving ‘Relocation Request’ from 3G MSC and ends when the RNC sendsback ‘Relocation Complete’ after receiving ‘Handover to UTRAN Complete’RRC message from the UE. From UTRAN perspective hoToUtranCompleteTimer is used to ensure that RNC will release the resources if it does not receive anyabort or failure messages, in case of unsuccessful attempt.




Date: 2007-06-08 Rev: 2.1


Figure 24: Flow chart of successful GSM to UMTS CS handover

6.10.4. Failure symptoms, identification and fixes for improvement (CS GSM ->UMTS)

Some main reasons as to why the GSM to UMTS handover procedure may failcan be as follows. For a full list please refer to [25].

• The GSM to UMTS handover feature is not enabled in UTRAN target cell

• The UE does not support the target cell frequency band

• The requested radio resources cannot be established, e.g. radio link setupfails on Iub or the ALCAP Iu transport bearer cannot be established

• The RNC does not receive a HANDOVER TO UTRAN COMPLETE messagefrom the UE, because the UE has received an invalid HANDOVER TO UTRANCOMMAND message or it does not support the configuration included in themessage. In this case the timer expires

• The MSC cancels the relocation by releasing the Iu connection




Date: 2007-06-08 Rev: 2.1


PM KPIs related to the IRAT Handover process are detailed in [25].

6.11. Call reliability – Cell change order from UTRAN

6.11.1. Concept

The cell change order from UTRAN procedure may be initiated by the UTRANwhen the UE is in CELL_DCH or CELL_FACH mode.

The approach for PS inter-system/RAT handover is similar to the one describedfor the CS inter-system handover in subsection 6.10. It might be that the two-step approach to first only measure BCCH/RXLEV of the neighbouring GSMcells, and then the BSIC, may not be adopted. In the Measurement Controlmessage it is only specified that the UE has to report the BCCH/RXLEV.

Nevertheless when the UTRAN decides to direct the UE to the GPRS domain, aBSIC and BCCH are specified. The UE is doing an inter-RAT cell reselection asspecified within IE "Target cell description" of the CCO from UTRAN message.In the UE, timer T309 supervises this procedure.


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

• in CELL_DCH mode

o Re-establish the UTRA physical channel(s) used at the time forreception of cell change order from UTRAN and transmit the cellchange order from UTRAN failure message and set the IE "Inter-RAT change failure" to "physical channel failure"

o OR when not successful, perform a cell update procedure withcause "Radio link failure"

• in CELL_FACH mode

o Revert to the cell it was camped on at the reception of thereception of cell change order from UTRAN and transmit the cellchange order from UTRAN failure message and set the IE "Inter-RAT change failure" to "physical channel failure" Select a UTRANsuitable cell and initiate the cell update procedure using the cause"cell re-selection"

Table 51 below is listing the parameter for the cell change order from UTRANprocedure:


t309 Defining timer T309

Table 51: Parameter used for configuring the cell change order fromUTRAN

Table 52 below is listing the identification in interface traces possibilities for thecell change order from UTRAN procedure:


Cell Change Order from UTRAN I Uu Any occurrence of the RRC messageCellChangeOrderFromUTRANFailure




Date: 2007-06-08 Rev: 2.1


Failure. The newly allocated resources on the NodeB are released bymeans of the NBAP Radio Link Deletion procedure by the RNC. In case ofHS-DSCH configuration the transport channel is re-configured to DCH.

Otherwise the call continues on the current configuration.

• If the Inter-Frequency Handover Procedure Timer expires before thePhysical Channel or Transport Channel or Radio Bearer Reconfigurationmessage has been sent to the UE then the SRNC undoes all actionsalready performed and releases all radio resources newly allocated for thishandover using the NBAP Radio Link Deletion Procedure. The callcontinues on the current configuration.

If the timer expires after any of the above Reconfiguration message hasbeen sent to the UE then the SRNC releases all radio resources newlyallocated using the NBAP Radio Link Deletion Procedure. The old radioresources are no more available and the call will drop. The RNC initiates theRANAP Iu Release Request procedure with cause 'Failure in the Radio

Interface Procedure' towards the CN.




Date: 2007-06-08 Rev: 2.1


Figure 25: Inter-frequency Handover Message Flow (HS-DSCH to HS-DSCH) - Intra-Node B, Intra-SRNC

Note that the phase “UE detected” refers to the achievement of RLsynchronisation with the new target cell. The user plane interruption is likely tobe longer for the UL as DL data is sent on both the old and new RL while UL isonly sent on old RL until either it fails or the new RL is restored.


Inter Frequency HO Delay Uu Any occurrence where the UE sends a Measurement Report 2xand the RNC does not reply with Physical or Transport ChannelReconfiguration message within y seconds

Dropped call during IF HHO Uu, Iu RNC sends a Physical or Transport Channel Reconfigurationmessage but the UE does not respond back with either




Date: 2007-06-08 Rev: 2.1


complete or failure message within y seconds. This will befollowed by RNC initiaiting Iu release procedure.

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

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

PMsystem

Counter / KPI15

KPI Name / Description

UtranCell (HHO.SuccOutInterFreq.<trigger> /HHO.AttOutInterFreq.<trigger>) * 100

Inter-frequency hard handoversuccess rate

UtranCell HHO.FailOuterInterFreq.<trigger>.<failure cause> Hard handover failure count

UtranCell VS.HHO.AttPrepOutInterFreq.<trigger> Hard handover preparation attemptcount

Table 54: PM KPIs identifying Inter-Freq HO problems

6.13. Call reliability – failures on the Transport Network

The underlying transport network on the Iub and Iu interface is ATM. On the Iubinterface AAL2 and AAL5 are used, with help of the ALCAP protocol resourcesare allocated. On the Iu interface the underlying ATM protocol is AAL5.

ATM failures and performance statistics of the Transport Network are notreported at the FM/PM system of the UTRAN, but on the ATM system. Pleasecheck the corresponding documentation.

Main problems that might occur on the Transport Network are as follows:

• Link synchronisation problems e.g. when using microwave links

• Configuration issues

6.14. Call reliability – failures on RLC

6.14.1. Concept

The specification of the RLC protocol is provided in [36]. A detailed descriptionof the ex-Lucent implementation is available in [21].

The RLC is a layer 2 sublayer. RLC provides three basic tasks:

1. Buffering

Buffering is required in RLC to compensate for the data rate variations of higherand lower layers: TCP/IP based applications typically generate IP packets atvariable data rate, while the air interface provides varying throughput due tovarying channel conditions.

2. Segmentation and reassemblyVariable-sized IP packets provided by the PDCP as RLC SDUs are segmentedinto fixed sized RLC PDUs. Concatenation and padding are used for efficientpacking. Each RLC PDU is transferred as one fixed-sized PHY TB.

3. Error control

15 <trigger> refers to quality or load based HO initiation and <failure cause> can be physical channel

reconfig failure or protocol error or configuration not supported.




Date: 2007-06-08 Rev: 2.1


AM RLC provides the link-layer ARQ scheme that is required to hide PHY blockerrors from higher layers.

The RLC provides three different types of data transfer modes:

• TM data transfer

o No protocol overhead added; transparent to the RLC

o Used for signalling SRB (e.g. broadcast SRB on BCCH, pagingSRBs on PCH), voice services and CS data

• UM data transfer

o Buffer control of RLC SDUs for smoothing data rate variationsintroduced by burst-traffic sources (e.g. TCP flow control) andlower layer variations

o Segmentation, concatenation and padding into RLC PDUs. EachPDU 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

o UM data transfer features plus

o Error control feedback, retransmission of erroneous or lost PDUsand 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 notconsidered any further because there is no performance impact due to RLC.

Figure 26 below is showing the UMTS protocol stack of the user plane for aTCP/IP data application:

Figure 26: UMTS protocol stack of the userplane for a TCP/IP application




Date: 2007-06-08 Rev: 2.1


TCP has its own flow control and ARQ algorithms so the O&M parameter ofRLC has to be adapted to interwork with TCP in an optimal way. Because theTCP settings could be different on each client PC (and the corresponding server

in the Internet or corporate business network) a reference client-server systemshould be defined and used to optimise the RLC settings.

A RLC PDU for PS RB has a size of 42 bytes16

(40 byte payload and 2 byteheader), which is relatively small compared to a TCP/IP packet size of around1000 byte

17. As a consequence retransmission on RLC results in a

retransmission of relatively small amount of data compared to that on TCP/IPlayer. 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 isadding the CRCI to each TB set (see also subsection 7.1.2.1). Furthermore thephysical frames on Iub are protected by additional CRCs. If one of both CRCfails lower layer discards the whole frame on Iub / the whole TB set. It is up tothe 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 dataPDUs are stored in a retransmission buffer when they are submitted to the MACand PHY layer. If a data PDU is NACK it can be quickly retransmitted. ARQ isusing the following mechanism:

• Status reporting on the RX: the RX sends a status report in so-calledSTATUS PDUs containing a detailed list of received and missing PDUs.STATUS PDUs have priority over retransmitted data. They can be sentperiodically or unsolicited e.g. after loss detection

• Polling from TX: the TX can request a status report

• Window mechanism: a sliding window allows the TX to transmit newPDUs while waiting for the ACKs till end of the window size.

• SDU discard function: when the delivery of a SDU cannot be managedbecause of e.g. repeated errors, the transmission of SDUs is stoppedand discarded on both TX and RX side.

Protocol error recovery

• Data PDUs carrying poll requests and status or other control PDUsrequire a special ACK and are protected by timers

• When timer protected PDUs are not acknowledged before the timerelapses these PDUs are retransmitted

• If timer protected PDUs are retransmitted and still no ACK receivedthen

o If data PDU retransmission did not succeed, go either to SDUdiscard or RLC reset of the RLC connection between the two entities

16 The size of signaling SRBs is 16 bytes plus 2 bytes header

17 The size of the TCP/IP packet is depending on the MSS negotiated for each TCP session during the

connection setup. In addition it might be that the IP packet is further segmented by one Internet server

routing the packets




Date: 2007-06-08 Rev: 2.1


o If SDU discard does not succeed, go to RLC reset of the RLCconnection between the two entities

o If RLC reset does not succeed, signal unrecoverable error to higherlayers. In this case the RRC might be dropped and the UE performsa Cell Update and the IE “AM_RLC error indication” is set to TRUE(subsection 6.3.1)

Parameters configuring the RLC are available in [27].

Reason for problems on the RLC might be due to

• RF related issues like pilot pollution, incorrect neighbouring definitionsetc.

• Lower layer problems on the Iub

• Decrease of the data rate because of .e.g. CongC resulting in SDUdiscards

6.14.2. Failure symptoms, identification and fixes for improvementThe retransmission on RLC layer can be easily identified by a not-in-sequencedelivery of RLC PDUs on Iub; this information is normally not available in Uutraces. The RX acknowledges in its status reports all PDUs with a SN < LSN.

For better identification on Iub the particular call has to be extracted so as not tomix up with RLC PDUs of other calls. In addition special ASCII files downloadedvia FTP can be used to easily identify retransmission (only possible when PPPand PDCP compression techniques as well as ciphering is disabled, see alsosubsection 7.2.3).

Another (but quite complicated) possibility is the analysis of the BITMAP in thestatus reports of the RX. The BITMAP is giving the TX an indication about whichPDUs have been successfully received and which not starting from the FSN(number of octets determined by LENGTH) [36].

A dropped call due to a RLC error can be easily identified by a Cell Updatemessage with cell update cause “RLC unrecoverable error”. See Table 55.

The SDU discard function allows discharging RLC PDU from the buffer on thetransmitter side, when the transmission of the RLC PDU does not succeed for along time. The SDU discard function allows avoiding buffer overflow. There willbe several alternative operation modes of the RLC SDU discard function, andwhich discard function to use will be given by the QoS requirements of theRadio Access Bearer.

Table 55 is listing problems that can be detected in interface traces and Table56 the corresponding KPIs in the PM system:

Problem Trace TriggerRLC 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 withexplicit signalling

Iub Any occurrence of a Move Receiving Window (MRW) command indicating aSDU discard and/or a MRW-ACK

Dropped call due toRLC error

Uu Any occurrence of a RRC Cell Update message with specified cell updatecause (not failure cause) “RLC unrecoverable error”. There might be optional afailure cause specified. The IE AM_RLC error might be set to TRUE.

Table 55: Identification of RLC problems in traces




Date: 2007-06-08 Rev: 2.1


PM

system


UtranCell VS.MM.CellUpdateReq.RLCError The measurement provides the number ofrequested cell updates with cause “Radio LinkControl (RLC) Unrecoverable Error” received

by the RNC from the UE.

Table 56: PM KPIs on RLC layer

6.15. Call reliability – HSDPA

6.15.1. Introduction

From UMTS Release 5 onwards HSDPA is supported in order to provide UMTSsubscribers higher throughput rates in the downlink as well as better resourceallocation in the UTRAN.

Compared to Release 99 the following changes have been done for HSDPA:

• On UTRAN, new modulation schemes, fast scheduling and resourcesharing techniques,…

• New UMTS physical channels

• New handsets with high speed capability

• Core Network accommodation for more traffic

• …

Figure 27 below is visualising the changes in the UMTS protocol stack in orderto support HSDPA:

PHY

Q2150.1

SGSNRNC

Control Plane User Plane Transport Plane Common

MM

SM

MAC

Phy-up

PHY

codec

RRC

RLC

SM

MAC

Phy-up

PHY

DCH

IP

PDCP

SSCOP

NBAP

AAL5

SSCOP

ALCAP

AAL5

SSCF SSCFFP

AAL2 AAL2 AAL5 AAL5

SSCF

RLC

MAC

Phy-up SCCP

FPRRC

ATM

E1

NBAP

AAL5

SSCOP

MTP3-b

SSCF-N

SCCP

RANAP

RRC

ATM

STM-1

GTP-U

UDP

PDCP

ALCAP

STC.2

SSCF-UNI

SSCOP

IP

RLC

MAC

Phy-up

DCH

FP

AAL5

ATM

E1/ STM-1

NBAP

ALCAP

HS-

DSCH

FPSSCOP

MTP3B

AAL5

SSCF

Q2150.1

Q2150.1

Iu UP

ATM

E1

AAL2

SSCOP

MTP3B

AAL5

SSCF

SCCP

SM

MM

RANAP

SSCOP

MTP3-b

SSCF-N

SCCP

PMM

SM

ATM

STM-1

AAL5

IP

GTP-U GTP-C

UDP

L1

L2

SSCOP

MTP3B

AAL5

SSCF

Q2150.

Q2150.1

IP

GTP-C

L1

GTP-U

UDP

L2

IP

GGSNUu Iub Iups Gn

PHY

HSDPA

PMM

RRC

RLC

PHY

HSDPA

AAL2 AAL5

SSCOP

SSCF-UNI

MAC-hs

DCH

FP

STC.2

PHY

DCH

HS-

DSCH

FP

AAL2

Node B UE

Figure 27: HSDPA protocol stack enhancements

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




Date: 2007-06-08 Rev: 2.1


6.15.2. Mobility aspects of HSDPA

6.15.2.1. Concept

The mobility aspect of a HSDPA user is as follows:

• For the UL the mobility procedures are largely mostly the same as forPS calls over DCH (e.g. soft/softer HO triggered via event 1a, 1b and1c)

• For the DL the HS-DSCH for a given UE belongs to only one of theradio links of one sector of the NodeB where the UL is connected. As aconsequence only Hard Handovers (Cell Changes) are triggered

The RNC is forwarding the DL application data to the NodeB from the MAClayer to the new MAC-hs layer that is scheduling the data for delivery. In case ofa Hard Handover the NodeB discards data that has been not been transmittedyet. In this case it is up to the higher layer protocols (RLC or TCP) to retransmitlost data. As a consequence too many serving HS-DSCH Cell Changes within a

short period of time (Ping-Pong handovers) may cause a reduced throughputdue to loss of data.

The number of HS-DSCH Hard Handovers is tracked by the UTRAN. If thisnumber exceeds an unusual amount of serving cell changes, the call ischanged from HS-DSCH to DCH. The algorithms are proprietary and depend onthe infrastructure vendor.

A typically scenario might look as follows:

• UE connected to NodeB A, NodeB B is becoming stronger and stronger

• UE sends Measurement Report with event id “1a”

• RNC adds NodeB B to the Active Set via Active Set Update procedure

• UE sending Measurement Report with event id “1d”

• RNC triggers Hard Handover via Transport Channel Reconfiguration orRadio Bearer Reconfiguration procedure

• UE sends Measurement Report with event id “1b” to remove NodeB Afrom the active set

The optimisation approach when triggering event id “1d” is as follows:

• HSDPA cell change should not be performed too late, when the UE hasalready moved 'far' into the area of another cell where it could havebetter throughput.

• HSDPA Hard Handovers should not be executed too early, so that itimmediately changes back to the previous cell if the radio conditionsvary (Ping-Pong effect).

In ex-Lucent UTRAN for each UE a timer hSDPAMobilityTimer is definedtracking the number of cell changes in a certain time frame. Depending on thestatus of this timer the UE

• Might setup the call either on DCH or HS-DSCH, if call is inCELL_FACH state

• Might be asked to change state from HS-DSCH to DCH or vice versa

For parameters configuring HSDPA see [16] section 9.2.




Date: 2007-06-08 Rev: 2.1



HSDPA performance degradations due to mobility issues can be best observedby analysing drive test data. It is very important to avoid unnecessary HardHandovers, in particular Ping-Ponging effects. On the other hand the HardHandover should not be triggered too late so that the UE is not served by aNodeB that is much worse compared to the best cell; in this case the throughputwill decrease or even the call may drop.

Furthermore non-optimal handover settings might cause unnecessarytransitions from HS-DSCH to DCH; as a result the benefits from HSDPA will notbe available to that particular UE.

Finally during the Hard Handover there might be major transmission gapsincluding TCP retransmission. The reason might be synchronisation problemsor not optimal timing during the handover procedure e.g. the timing when theRNC stops forwarding data towards the old NodeB. This problem can be easilydetected when correlating RRC with TCP/IP data. Figure 28 below shows anexample cross-correlated by Actix [29]; in the upper left part of the picture the

RRC protocol is shown, the lower left picture shows the TCP SQN recorded atthe client site by Ethereal:

Figure 28: Hard handover problems identified by cross-correlatedRRC and TCP data

Table 57 below is listing the identification techniques for HSDPA mobilityproblems:


HSDPA ping-pong Uu There are two consecutive Transport Channel Reconfiguration / Radio BearerReconfiguration procedures within x seconds




Date: 2007-06-08 Rev: 2.1


Transmission gapduring HO inHSDPA call

Uu, TCP Cross-correlation Uu and TCP trace: during a Transport ChannelReconfiguration / Radio Bearer Reconfiguration procedure there is atransmission gap on TCP layer in the DL for x seconds

Table 57: HSDPA related problems indicated by network interface traces

6.15.3. RF related issues

RF related issues on the air interface are one of the main reasons forperformance throughput degradations of HSDPA calls. The optimisation has tobe done on a per-cell basis using UE drive test data. In the followingsubsections the most important measures are summarised.

Due to the fact that in the downlink there is no gain from soft/softer HO a UE inHSDPA mode is more sensitive regarding pilot pollution, see also subsection6.4.2 for details.

6.15.3.1. RF related issues - CQI

The most important measure of the DL quality of the HSDPA shared channel isthe channel quality indicator (CQI) the UE is reporting back to the Node B onthe HS-DPCCH. The CQI ranges from 0 to 30, with greater values indicatingbetter quality. It is based on the instantaneous measurements of the RFconditions. The NodeB is deciding upon the reported CQI values whichTransport Format Resource Combination (TFRC) can be transmitted given acertain transmit power and an expected CRC error rate that is directly impactingthe expected throughput.

3GPP [11] defines the meaning of the reported CQI values for each UEcategory. In [15] requirements for the accuracy of the channel qualitymeasurements are given. The UE shall assume for the purpose of CQIreporting a total received HS-PDSCH power

PHSDPSCH = PCPICH + Γ + ∆ in dB

where the total received power is evenly distributed among the HS-PDSCHcodes of the reported CQI value. The measurement power offset Γ is signaledby the RNC and the reference power adjustment ∆ is given for each UEcategory in [11]. PCPICH is the transmit power of the Primary or SecondaryCPICH. It should be noted that the 3GPP specification does not demand thatthe power PCPICH + Γ is equal to the total available HSDPA power.

Figure 29 below show as a graphical distribution of the throughput versus CQI;the test has been done stationary, the cell was unloaded, application was FTPdownload via TCP/IP:




Date: 2007-06-08 Rev: 2.1


0

200

400

600

800

1000

1200

1400

1600

1800

0 5 10 15 20 25

CQI

A p p F w d T h r o u g h p u t [ k b p s ]

Figure 29: HSDPA - throughput versus CQI for TCP download

Note: when the CQI is exceeding 15 there is no obvious throughputimprovement observed anymore because the UE capability of 12 is in this casethe limiting factor (see also subsection 6.15.4 for details).

6.15.3.2. RF related issues – Ec/No

For the same test case as described in previous subsection the HSDPAthroughput versus Ec/No were analysed. Again a strong correlation betweenboth measures has been recorded as visualised in Figure 30:

0

200

400

600

800

1000

1200

1400

1600

1800

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

Ec/No [dB]

A p p F w d T h r o u g h p u t [ k b p s

Figure 30: HSDPA - throughput versus Ec/No for TCP download

To be noted: the Ec/No is never exceeding (excluding single measurementsamples) around –6 dB because the “No” term includes the HSDPA traffic of theuser. Furthermore for Ec/No values exceeding around –8 dB no throughputperformance could be observed indicating again that the limiting factor is the UEcapability (see also subsection 6.15.4).




Date: 2007-06-08 Rev: 2.1


6.15.3.3. RF related issues – other optimisation problems

For any other optimisation problems as neighbour list planning, accessparameters or power control settings please take a look in the correspondingsubsections of this guideline.

6.15.4. UE limitations

HSDPA capable terminals with resulting peak data rates ranging from 1.2 Mbit/sto 14 Mbit/s at physical layer, see also [14] and [16]. Depending on the terminaltype different maximum number of HS-DSCH codes, different maximum TBS ormodulation schemes are supported. As a consequence the maximumachievable throughput is terminal dependent and should be taken intoconsideration when analysing HSDPA UE traces.

As described in subsection 6.15.3 currently the UE is the limiting factor in caseof optimal RF conditions.

6.15.5. Capacity issues

Because the HS-DSCH is a shared channel the throughput of one UE highlydepends on the overall HSDPA traffic in the particular NodeB. Two cases canbe differentiated:

6.15.5.1. Capacity issues – sharing of the bandwidth

When sharing the HSDPA bandwidth with other users the applicationthroughput will not be optimal due to the fact that

• The bandwidth provided by the HS-DSCH is limited

• The bandwidth on the backhaul transport network is limited

These kinds of capacity issues can be detected as follows:

• Indirectly by execution of UE performance tests during the busy hourand a comparison to the non-busy hour (e.g. on Sunday or at the earlymorning); a good test method might be static automatic tests for a fullday.

• By evaluation of PM counter statistic

• Evaluation of Iub traces

6.15.5.2. Capacity issues – HSDPA call cannot be established on a particularNodeB

Failed establishment of HSDPA call on a NodeB can be due to

Hard limits

During call set up, HS-DSCH serving cell change and transition fromURA_PCH/CELL_FACH to CELL_DCH with HSDPA the number of active

HSDPA users is checked on a cell level against the parametermaxHsdpaUsersPerCell. HSDPA hardware and processing resources arelimited in the NodeB, for more details see [16]. For ex-Lucent U04.0x the UCU-IIhardware limitation (and default parameter setting) is 24.

For this event there is no corresponding PM counter available in ex-LucentUTRAN.

Soft limits

Each time when a UE tries to establish a HSDPA call on a new NodeB via aRadioBearerReconfiguration procedure DBC is checking the soft limitations. For




Date: 2007-06-08 Rev: 2.1


ex-Lucent UTRAN the corresponding parameter and algorithm configuring DBCare explained in [18].

HSDPA related PM counters are available in [16] section 11.

6.16. Call reliability – HSUPA/EDCH

6.16.1. Introduction

From UMTS Release 6 onwards HSUPA is supported in order to provide UMTSsubscribers’ higher throughput rates in the uplink as well as better resourcesharing in the UTRAN. But in this release HSUPA is only supported in UL, ifHSDPA is configured in the DL. Furthermore new UL MAC functionality hasbeen split into RNC entity (MAC-es) and NodeB entity (MAC-e) respectively.

Figure 27 below is visualising the changes in the UMTS protocol stack in orderto support HSUPA:

Figure 31: HSUPA changes done to the Protocol Stack

The following subsections are describing different aspects of HSUPA data call.

6.16.2. Mobility aspects of HSUPA

6.16.2.1. Concept

The mobility aspect of a HSUPA user is as follows:

• In general the mobility procedures are the same as for PS calls overDCH (e.g. soft/softer HO triggered via event 1a, 1b and 1c).

• However one of the radio links acts as the “serving cell” which is

selected to be the same as for HSDPA in the DL

In HSUPA serving cell is responsible for issuing absolute serving grants (AG)for the UE to send data. And as such this cell change only involves changingthe physical channels E-AGCH/E-RGCH to accommodate the new role of thecell. The support of soft/softer HO means that the possibility of performancedegradation is much less as compared to HSDPA.

However 04.03 does not support HSUPA over Iur boundary. Consequently if allthe radio legs are from drift RNC, the HSDPA/E-DCH call will be reconfigured toHSDPA/DCH state with a minimum data rate. A timer is used to supervise the




Date: 2007-06-08 Rev: 2.1


reconfiguration back to HSDPA/E-DCH state (only possible in SRNS relocationor when all radio legs handover back to SRNC) and an optimum value shouldavoid 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 cellsinvolved which don’t support E-DCH or cells are fully loaded with maximumallowed number of E-DCH users or if UTRAN wants to activate compressedmode on the UE.


Depending upon the initial E-DCH throughput, the new DCH bearer throughputwill be lower at application level. If some of the radio legs go back to SRNC thenthere is possibility that bearer will never configure back up to E-DCH. Howeversuch situation will only occur if the user only moves along the Iur boundary.


HSUPA ping-pongalong Iur Uu There are consecutive Transport Channel Reconfiguration / Radio BearerReconfiguration procedures within x seconds doing E-DCH ↔ DCH statechanges frequently

Reduction inthroughput duringHO along Iur

Uu There is no subsequent Transport Channel Reconfiguration / Radio BearerReconfiguration procedure observed after the initial procedure that configuredUL to DCH

Table 58: HSUPA HO related issues involving Iur

Some relavent KPIs/Counters are given that deal with the handover aspect ofHSUPA

PMsystem

Counter/KPI KPI Name / Description

UtranCell (VS.SuccServCellChangeEDCH /VS.AttServCellChangeEDCH)*100

EDCH Serving Cell change Successrate

UtranCell VS.ReconfSucc.EDCH-HSDSCH_ULDCH-HSDSCH Total number of successfulreconfiguration E-DCH to DCH in UL

with HSDPA in DL

UtranCell VS.ReconfSucc.ULDCH-HSDSCH_EDCH-HSDSCH Total number of successfulreconfiguration DCH to E-DCH in UL

with HSDPA in DL

Table 59: PM Counter/KPI for E-DCH Mobility

6.16.3. MAC/ RF related Issues

The scheduling mechanism for EDCH involves UEs sending schedulingrequests that are assigned resources by the MAC-e entity upon evaluation of aset of criteria. This scheduling grant takes the form of absolute (giving max

uplink power that can be transmitted) or relative (stipulating change/no-changein power with respect to previous TTI).

However in case of overload (on Uu or Iub) the scheduler will not honour therequest and would most likely start downgrading the served and non-servedUEs through absolute and relative grants respectively. Hence it is important toensure that UL target load and Iub links are setup correctly to give desired cellthroughput.

The scheduler is also responsible for the hybrid ARQ to ensure error-freedelivery avoiding re-transmissions at higher layers, reducing delay. Furthermorethe UL EDPCCH contains a “happy bit” that shows if the UE is satisfied with the




Date: 2007-06-08 Rev: 2.1


current grant. This can act as an indicator of how fairly each UE is beingscheduled.

Under bad RF conditions the UE is likely to be transmitting at high power toreach the NodeB and hence will not have sufficient power available to send thedata resulting in loss of throughput.

6.16.4. UE Limitations

HSUPA capable terminals have peak data rates ranging from 0.7 Mbit/s to 5.7Mbit/s at physical layer, see also [14] and [17]. Depending on the terminal type,various options for maximum number of UL codes, minimum SF and TTIdurations are supported. As a consequence the maximum achievablethroughput is terminal dependent and should be taken into consideration whenanalysing HSUPA UE traces.

6.16.5. Capacity issues

Because the E-DPDCH is a shared channel the throughput of one UE highly

depends on the overall HSUPA traffic in the particular NodeB. Two cases canbe differentiated:

6.16.5.1. Capacity issues – sharing of the bandwidth

When sharing the HSUPA bandwidth with other users the applicationthroughput will not be optimal due to the fact that

• The bandwidth provided by the E-DPDCH is limited, see Figure 32

• The bandwidth on the backhaul transport network is limited

These kinds of capacity issues can be detected as follows:

• Indirectly by execution of UE performance tests during the busy hourand a comparison to the non-busy hour

• By evaluation of PM counter statistics• Evaluation of Iub traces

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




Date: 2007-06-08 Rev: 2.1


6.16.5.2. Capacity issues – HSUPA call cannot be established on a particularNodeB

During call set up, E-DCH serving cell change and transition fromURA_PCH/CELL_FACH/CELL_DCH to CELL_DCH with E-DCH the number ofactive HSUPA users is checked on a cell level against the parametermaxEdchUsersPerCell. For ex-Lucent U04.0x, default setting for this parameteris 30. Currently PM system only records this failure if it happens during DCH toE-DCH reconfiguration.

HSUPA hardware and processing resources are limited in the NodeB, for moredetails see [17] section 5. NodeB equipped with UCU-II does not support E-DCH. And as a result the E-DCH call can be reconfigured to DCH if thecorresponding HS-DSCH serving cell changes to the NodeB with UCU-II.

Full set of HSUPA related PM counters are available in [17] section 11.

6.17. Call reliability – miscellaneous failures6.17.1. RB Reconfiguration / Transport Channel Reconfiguration failure

6.17.1.1. Concept

The RB Reconfiguration or alternatively the Transport Channel Reconfigurationprocedure might be initiated for several reasons:

• In case of UE state transitions e.g. when going from CELL_DCH modeto CELL_FACH mode in case the inactivity timer expires (subsection6.7) or because of CongC (subsection 6.5)

• Hard handover for HSDPA calls (subsection 6.15.2)

• In case RNC requests the UE to change the RB due to e.g. PS trafficmeasurements triggered either by UE sending a Measurement Report

4a/4b or by the UTRAN monitoring the DL RLC buffer occupancy(subsection 7.2.3)

• Due to a high BLER in the DL indicated by Measurement Report 5asent by the UE (subsection 7.1.1)

• To direct to direct the UE into compressed mode

In case of a change of the data rate first a Radio Link Reconfiguration on NBAPis executed following changes of the ATM resources on the Iub via ALCAPprocedures.

The RNC is sending a RB Reconfiguration message/Transport ChannelReconfiguration on RRC and in case of a failure the UE is sending back thecorresponding failure message.


Main reason for a failure in this procedure is that the UE is not supporting therequested new configuration.

Table 60 and Table 61 are listing the identification of RB ReconfigurationFailures in traces and in the PM system:




Date: 2007-06-08 Rev: 2.1



RB Reconfiguration failure Uu Any occurrence of the RRC message RB ReconfigurationFailure

Transport ChannelReconfiguration failures

Uu Any occurrence of the RRC message Transport ChannelReconfiguration Failure

Table 60: Identification of RB Reconfiguration Failures in traces

PMsystem


UtranCelland RNC

(VS.RRC.RBReconfigSucc/VS.RRC.RBReconfigAtt)*100 RadioBearerReconfigurationSuccess rate

UtranCelland RNC

(VS.RRC.TransChanReconfigSucc/VS.RRC.TransChanReconfigAtt)*100

TransportChannelReconfigurationSuccess rate

Table 61: PM KPIs identifying RB / Transportchannel

Reconfiguration Failures

6.17.2. Physical Channel Reconfiguration failures

6.17.2.1. Concept

The Physical Channel Reconfiguration procedure can be initiated by theUTRAN e.g. during inter-Frequency hard handover for DCH. Upon receiving thePhysical Channel Reconfiguration message the UE has to change its physicalconfiguration as requested and is sending back a Physical ChannelReconfiguration Complete message (successful case) or Physical ChannelReconfiguration Failure (unsuccessful case).


Table 62 is listing the identification of Physical Channel Reconfiguration

Failures in traces:


Physical ChannelReconfiguration Failure

Uu Any occurrence of a Physical Channel ReconfigurationFailure message

Table 62: Identification of Physical Channel Reconfiguration Failures

PM counters pegging failures in the Physical Channel Reconfigurationprocedures are listed in the corresponding subsections e.g. in the subsection6.12.2.

6.17.3. Relocation failures

6.17.3.1. Concept

The relocation procedure is used in case of

• IRAT-HO (subsection 6.10)

• Inter-RNC HO

• In case of a Cell Update on a new RNC

The procedure is described in [9]. The SRNC sends a Relocation Requiredmessage on RANAP. The CN sends back the Relocation Command message(successful case) or Relocation Preparation Failure (unsuccessful case).




Date: 2007-06-08 Rev: 2.1


Table 63 below is listing parameters used for the relocation procedure:


IRATHORelocGuardTimer This parameter configuring the IRAT-HO relocation guard timer.

RelocationGuardTimer This parameter configuring the relocation guard timer.

Table 63: Parameter used for the relocation


Failures of the relocation process occur most likely during the IRAT-HOprocess. A failure is detected during the RANAP Relocation Preparationprocedure (e.g. GSM handover resource allocation fails or the CN rejects theUMTS to GSM handover request) due to the following causes:

• Timer TRELOCprep expiry at the SRNC

• Relocation Preparation Failure

In the first case the SRNC initiates the Relocation Cancel procedure at the Iuinterface. This procedure enables the CN to initiate the release of the resourcesallocated during the Relocation Preparation procedure in the GSM network. TheSRNC considers the UMTS to GSM handover as not possible at this point intime and keeps the existing radio connections established. This means that theexisting Iu-signalling connection can still be used for the call as the timerIRATHORelocGuardTimer is still running when RelocationGuardTimer expires.

In the second case upon receiving a Relocation Preparation Failure messagefrom the 3G MSC, the SRNC still maintains the call. If the failure causespecified within the message is “Relocation Failure in Target CN/RNC or TargetSystem” or “Relocation not supported in Target RNC or Target System” then

SRNC repeats the Relocation Preparation procedure with the next suitable cellfrom the list of potential GSM target cells otherwise the SRNC considers theUMTS to GSM handover as not possible at this point in time.

Table 64 is listing methods of how to identify relocation problems in interfacetraces:


Relocation PreparationFailure

Iu Any occurrence of the RANAP message Relocation Preparation Failure

Relocation Cancel Iu Any occurrence of the RANAP message Relocation Cancel

Table 64: Identification of relocation failures in interface traces

Table 65 below is listing the PM KPIs describing relocation failures:




Date: 2007-06-08 Rev: 2.1


PM

system


UtranCell VS.RAB.Drop.CS.RelocUEInvol/CS RAB Success*100 CS RAB Drop Rate due to SRNSRelocation

UtranCell VS.RAB.Drop.PS.RelocUEInvol/RAB.SuccEstabPSNoQueuing.PS*100

PS RAB Drop Rate due to SRNSRelocation

UtranCell (IRATHO.AttRelocPrepOutCS -IRATHO.FailRelocPrepOutCS.sum)/IRATHO.AttRelocPrepOutCS*100

Relocation preparation for CS UMTSto GSM HHO success rate

UtranCell IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp/IRATHO.AttRelocPrepOutCS*100

Relocation preparation UMTS toGSM fail rate T Relocprep expiry

RNC VS.RAB.Drop.PS.RelocUEInvol /RAB.SuccEstabPSNoQueuing.PS*100

PS RAB Drop Rate due to SRNSRelocation RNC

Table 65: PM KPIs identifying relocation failures

6.17.4. Failures during the RAB and RL release procedure

The release of the RAB and the RL is not only used when terminating the voiceor 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 isshown in Figure 11; the normal release procedure is identical with this callhandling, the only exception is that it is not initiated by an Iu Release Request.

In the 3GPP there are no failure messages defined for the NBAP Radio LinkDeletion Request or the RANAP Iu Release Request.




Date: 2007-06-08 Rev: 2.1


7. Call qualityIn this section those aspects are investigated that have a direct influence of theuser perceived call quality. In the first part the BLER in the DL and UL isdiscussed. 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 adescription of performance weaknesses and of how to overcome these issues.

7.1. Call quality - Block Error Rate (BLER)

For the different types of services like voice, data and VT a specific BLER hasto be maintained to guarantee a good call quality.

In case of voice or VT call the quality degradation can be directly experiencedduring the conversation. In case of data call the poor quality may causethroughput degradation or high ping delay times. In addition VT calls will result

in a fragmented and interrupted video signal.The DL and UL Block Error Rate (BLER) are the KPIs providing an indication ofthe quality of the UMTS call from the user perspective.

The DL BLER is the percentage of corrupted blocks over the total number ofblocks received by the UE; this KPI can be only retrieved via UE logging:

DL BLER = 100 * (NumRecBlocksErrDL / NumRecBlocksTotDL)

The UL BLER is the percentage of corrupted blocks received by the ServingRNC (before frame selection) over the total number of blocks received (beforeframe selection). The UL BLER is provided via the following formula on a perRNC basis; statistics can be retrieved via the PM system (subsection 7.1.2):

UL BLER = 100 * (NumTransBlockErrUL / NumTransBlockTotUL)

High values of one or both of these KPIs indicate that the perceived quality ofthe call is poor.

The DL and UL PC algorithms are there to control the BLER to a maximum.BLER degradation occurs in case of pilot pollution, non-optimal neighbouringdefinitions etc. as explained in subsection 6.4. High BLER can be observed inthe UL or in the DL separately. The reasons observing high BLER might be asfollows:

• Non-optimal PC settings

• The maximum NodeB or UE transmit power for the dedicated channelshas been reached

• Power restrictions to avoid system overload

In the following subsections the DL and UL BLER analysis is reflected in more

detail.

7.1.1. DL Block Error Rate (BLER) analysis

7.1.1.1. Concept

The DL closed loop power control is in charge to keep the DL BLER in a pre-defined range. The DL closed loop power control can be split into two loops: DLouter and inner loop PC. Figure 33 below is showing the principle of the DL PC:




Date: 2007-06-08 Rev: 2.1


Figure 33: Downlink outer loop power control principle

DL outer loop PC:

The RNC sends a target value for the BLER to the UE on the DCCH. This valueshould guarantee an optimal performance for the (voice or data) service basedon the requested QoS parameters. During the call the BLER target can be re-adjusted by the RNC. The decision is based on the BLER and SIRmeasurements UE sends back in the UL via the DCCH.

The DL outer loop PC in the UE defines a SIR target based on the BLER. Thecontrol loop runs autonomously in the UE with a maximum speed of 100Hz. Themethod on how to set SIR target in order to provide the requested BLER is notspecified in the 3GPP standard. However minimal UE performances in given RFconditions are specified in [13]. When the UE is in compressed mode higher

SIR target values will be defined, as there is no power control duringtransmission gap.

DL inner loop PC:

The inner loop PC purpose is fast adaptation of the NodeB transmit power inorder to achieve the targeted SIR ratio for the considered downlink radiochannel. Because of the speed of the control loop (up to 1500 Hz), the onlyelements involved in the inner loop power control are the UE and the NodeB.

The TPCs the UE is sending to the NodeB is based on the comparison of theSIR estimation versus the SIR target. The NodeB transmit power is limited toparameters given by the RNC on NBAP.


The DL BLER is reported by any drive test system in Uu traces. Furthermorethe UE may send a Measurement Report “5a” in case the number of bad CRCson a certain transport channel is exceeding a certain threshold specified by aprevious Measurement Control message [6]. The UTRAN may or may not reacton this Measurement Report.

Table 67 is listing the triggers in interface traces:




Date: 2007-06-08 Rev: 2.1



High DL BLER inUu

Uu DL BLER higher than x % for more than y seconds

NodeB Tx Pwr viaRFCT

RFCT The NodeB transmit power is exceeding for service x more than y seconds zdBm.

MeasurementReport 5a

Uu Any occurrence of a Measurement Report 5a sent by the UE

Table 66: Identification of high DL BLER in interface traces

7.1.2. UL Block Error Rate (BLER) analysis

7.1.2.1. Concept

The UL closed loop power control is in charge to keep the UL BLER in a pre-defined range. The UL closed loop power control can be split into two loops: ULouter and inner loop PC:

UL outer loop PC:

The UL outer loop PC is located at the RNC and is responsible for updating theUL SIR target so that the UL BLER ensures the QoS of the requested (voice ordata) service. The RNC provides the NodeB the updated SIR target via theDCH FP on the Iub. The control loop runs in the RNC with a speed of 100 Hz.For updating the SIR target the RNC takes into account not only the measuredBLER, but also the reported RSSI measured by the NodeB and otherparameters.Figure 34 below is visualising the principle:

Figure 34: UL outer loop power control

If the UE is in soft/softer HO mode and a particular NodeB has more than oneleg, the NodeB does frame selection in the NodeB(called “micro-diversity”). Forframes coming from different NodeBs belonging to the same RNC the RNC isdoing the frame selection (termed “macro-diversity”). In case the NodeBs




Date: 2007-06-08 Rev: 2.1


belong to different RNCs the SRNC is doing the frame selection; the data isprovided via the Iur interface.

For each UL TB set the NodeB is performing a CRC check on PHY and addinga CRCI to the frame. In addition the quality of the link is estimated; the QE ineach TB provides the results. The QE is vendor proprietary, different metricsmight be used to derive it. The QE ranges from 0 to 255 (small QEs areindicating good quality).

UL inner loop PC:

The UL inner loop PC is adjusting the transmit power of the UE in order toachieve the provided SIR target. All NodeBs involved in the particular call aresending TPC commands with a rate of up to 1500 Hz. The TPC commands ofthe particular NodeBs can differ. In this case if only one of the NodeBs issending a “power down” command, the UE will lower its transmit power by thedefined power-down-step. In case there is no TPC at all the transmit power ofthe UE remains unchanged.

More information including parameter can be found in [28].


Cells suffering with high UL BLER can be easily identified using data from thePM system. When doing drive testing high UL BLER can be identified by usingthe RFCT feature in parallel to tracking the KPIs as retrieved by the RNC. HighUL BLER might cause a RLF in the UL and/or the drop of the call (see alsosubsection 6.1).

Table 67 and Table 68 are listing the triggers in interface traces and thecorresponding PM KPIs:


High UL BLER inRFCT

RFCT UL BLER higher than x % for more than y seconds

High UE powerreached

Uu Any occurrence where the UE is sending with at least y dB UE power for morethan x seconds

18

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 targetexceeded

Iub The SIR target for service x is exceeding value y.

UL SIR target notupdated

Iub Any occurrence where the UL SIR target is not updated for more than xseconds. This is an indication of failure in the UL that might lead to an UL RLF.

Table 67: Identification of high UL BLER in interface traces

PMsystem


RNC (VS.ULTransBlockErr.CSV.All / VS.ULTransBlock.CSV.All)*100 UL BLER rate for All CSV AMRcodec rates

RNC (VS.ULTransBlockErr.CSD / VS.ULTransBlock.CSD)*100 UL BLER rate for CSD

18 Note that according to the 3GPP specification there are four power classes defined (power class 1 to 4) with maximum

output power +33 dBm, +27 dBm, +24 dBm and +21 dBm. The most common mobiles on the market are class 3 (+24 dBm).




Date: 2007-06-08 Rev: 2.1


RNC (VS.ULTransBlockErr.PS / VS.ULTransBlock.PS)*100 UL BLER rate for PS

Table 68: PM KPIs identifying BLER issues

UL BLER measurements can also be retrieved via the ex-Lucent RF Call tracefeature [22].

7.2. Call quality – Quality of service (QoS)

QoS is reflecting the quality of a wireless network from the user perspective interms of voice quality, data throughput or the quality of the video signal usingVT. The QoS can be measured with special drive test equipment. Forevaluation purposes the drive test equipment should use a predefinedmeasurement sequence for each of the service types as given in the appendixof this document.

In this chapter the QoS for the different service types are discussed as well ashow to identify possible failures and quality degradations.

It is assumed that the number of measurement samples is sufficient to get areliable result;

7.2.1. QoS – general

In this subsection general QoS KPIs are listed that are not linked to a particularservice like voice, data or VT. These can act as trigger points for identifyingnon-optimal performance.

KPI Counter / KPI

No network [%] (1- NoCallAttwithNoNetworkDetected / NoAllCallAtt) * 100

Attach failure [%] NoUnsuccessfulAttachAtt / NoAllAttachAtt * 100

Attach setup time [s] t_attach_complete – t_attach_request

Location update success rate [%] NoSuccessfullLU / NoAllLUAtt * 100

SMS failure rate [%] NoFailedSMSTasks / NoStartedSMSTasks * 100

MMS failure rate [%] NoFailedMMSTasks / NoStartedMMSTasks * 100

SMS delivery time [s] t_sms_delivered – t_sms_start

MMS delivery time [s] t_mms_delivered – t_mms_start

Table 69: General QoS parameters measured on application level

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

7.2.2. QoS – voice service

Because of the uncorrelation of UMTS links it is necessary to measure the ULand DL voice quality separately. Using special drive test equipment provided bye.g. QVoice or SwissQual one can do this. This equipment is comparing thereceived voice samples with the transmitted voice samples. In that way theevaluation software can do a voice quality classification for both directionsindependently.




Date: 2007-06-08 Rev: 2.1


Table 70 below is giving the QoS parameter for voice services. For the voicequality evaluation the Mean Opinion Score (MOS) is used. The MOS is definedby 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 codecrates see [47]. A good voice quality can be considered when the MOS isexceeding 3.0. Voice quality degradations like e.g. echo or voice delay arereflected by this measure.

Mean Opinion Score (MOS) QoS value

Below 2.0 Poor

2.0 to 3.0 Fair

3.0 to 4.0 Good

Above 4.0 Excellent

Table 70: QoS of voice services - MOS

Table 71 below is listing the formulas to retrieve the QoS KPIs for voice:

KPI Counter / KPI

Call completion success ratevoice [%]

NoSuccCompletedCallsVoice / NoSuccSetupCallsVoice * 100

Block call rate voice [%] (NoSetupFailedCallsVoice - SetupFailedCallNoNetworkVoice) /NoCallAttVoice *100

Dropped calls voice [%] NoDroppedCallsVoice / NoSuccSetupCallsVoice * 100

HandoverSuccess3G2G [%] No3G2GHandoverSuccSeiz / No3G2GHandoverAtt * 100

HandoverSuccess2G3G [%] No2G3G HandoverSuccSeiz / No2G3GHandoverAtt * 100

Call setup success rate voice [%] NoSuccCallSetupVoice / NoCallAttVoice * 100

Good voice quality [%] NoVoiceSampleGoodExcellent / NoAllVoiceSamples * 100

Table 71: QoS of voice services – KPIs

7.2.3. QoS – data services

7.2.3.1. Concept

There are different metrics available defining the QoS of data services likethroughput, delay, jitter etc. In the PDP Context Activation Request messagethe UE can optionaly request pre-defined QoS profiles as specified in [5]. TheCN can check the requested QoS profile with entries from the HLR. The CNmakes these negotiated QoS parameters available to the UTRAN via the RABAssignment Request [9].

Dedicated and common UTRAN resources can be dynamically assigneddepending on traffic measurements or load. The initially assigned PS RB at thebeginning of a PDP session depends on the UTRAN configuration. The RB canbe dynamically changed (or even the mobile is sent to idlemode/URA_PCH/CELL_PCH mode) depending on the data to be sent in the ULand/or DL. Depending on the status of the RLC queue in the UE the mobilemight send a Measurement Report “4a” (in case the transport channel trafficvolume exceeds an absolute threshold) or Measurement Report “4b” (in casethe transport channel traffic volume becomes smaller than an absolute




Date: 2007-06-08 Rev: 2.1


threshold). The RNC may or may not react on this Measurement Report bydoing a RB reconfiguration (see subsection 5.4.1 and 6.17.1). Furthermore asmaller RB can be assigned in case of overload estimations done by the RNC

(subsection 6.5).

Another difference when describing the PS data user perceived QoS is that adrop of the RAB and RRC connection does not (necessarily) mean that the PDPContext is removed from the GGSN or the FTP session drops. After the newestablishment of the RRC connection and the new establishment of the RABthe FTP session can be resumed in case the session has not timed out inbetween. For the user the drop of the RRC and RAB is visible by stalling of theFTP transfer for the particular timeframe and because of low throughput rates.In case of real time applications like video streaming or web radio the drop willbe noticed by the user if the buffer of the application is emptied and no newdata is received. It might be that the application will re-start with codecsrequiring lower bandwidth to fill the internal buffer again.

On the PPP link of the PS data session the TCP/IP header and data can be

compressed resulting in a throughput increase. For most Microsoft platforms,the PPP compression is an available option in the PPP settings of the dial-upnetworking. .

In addition also the PDCP layer is providing header compression for e.g. TCP,UDP, RTP and IP header [40].

Simple FTP-download tests of files with the size of 1MB in the UMTS networkshas shown that the throughput for zipped binary files is around 25% lesscompared with the ASCII files.


For analysing low PS data performance the following has to be considered:

• UE state

• Chosen RB

• Reported failures of the transport network (subsection 6.13)

• Problems detected on the RLC layer e.g. RLC retransmission or RLCresets (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.1and the remarks in the appendix of this document)

• Retransmission on TCP layer

• PPP/PDCP compression used/not-used. Usage of zipped files/unzippedASCII 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 theperformance degradation (e.g. delay due to non-optimal RLC queue,retransmission on RLC etc.)

One example of an (graphical) analysis is shown in Figure 35 below. Thethroughput of a FTP transfer is measured by Ethereal [30] and visualised bytcptrace [31] is low. The root cause for the non-optimal performance is ConC:




Date: 2007-06-08 Rev: 2.1


Figure 35: FTP performance degradation caused by ConC

The FTP throughput is the gradient of the curve; in addition TCP retransmissioncaused by SDU discards on RLC are shown in the right part of the picture (seealso subsection 6.14.1).

It is possible to cross-correlate the UE Ethereal traces with Ethereal tracesrecorded at the FTP server and also with RF data like Ec/No or Active SetUpdate messages recorded by the UE by e.g. using Actix [29]. In that way FTPperformance degradations can be linked to handover problems, bad radio

conditions in terms of Ec/No or neighbour definition problems. When the tracesare recorded by different mechanisms, it might be necessary to correlate the PCclocks by using time synchronisation see also subsection B in the appendix.Otherwise tools like Actix can do event-based cross correlation.

Another example for an end-to-end analysis is shown in Figure 36 below; thepicture is visualising the delay of an ICMP ping between Internet server and PCclient for UL and DL separately. The trace was recorded with Ethereal [30].

Furthermore by tracing on the Iub, Iu and Gn interface it is possible to makesimilar delay plots for the particular interfaces. This will unveil where the highdelay peaks are coming from and will give indications of how to improve theend-to-end performance.




Date: 2007-06-08 Rev: 2.1


Figure 36: end-to-end delay of an ICMP ping

For the same measurement the delay on the Gn interface were also measuredas shown in Figure 37 below. As expected the delay is very small and don’thave a big impact on the overall delay. This trace was recorded using aTektronix K12 protocol tracer.

Figure 37: delay measured on the Gn interface

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




Date: 2007-06-08 Rev: 2.1



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

TCPretransmission

TCP Number of occurrences of TCP retransmissions. Statistic counted per TCPsession

TCP SACKs TCP Number of SACK. Statistic counted per TCP session

Table 72: Identification of QoS issues for data service

Table 73 below is listing the data QoS parameter including the trigger points foridentifying non-optimal performance:

KPI Counter / KPI

PDP context activation failure [%] NoUnsuccessfulPDPActivation / NoPDPActivationAtt * 100

PDP context activation time [s] t_pdp_activation_complete – t_pdp_request

PDP context cut off rate [%] NoPDPLosses / NoSuccessInitiatedPDP * 100

FTP cut off rate [%] NoFTPLosses / NoSuccessStartedFTP * 100

FTP throughput [kbit/s] UserDataTransferred [kbit] / (t_ftpend – t_ftpstart)

Ping delay [s] RTT of a ICMP with a payload of 32 bytes

HTTP failures [%] NoSuccHTTPTasks / NoHTTPTasksStarted *100

RB Assignment Success Rate [%] NoSuccAssignedRB / NoRequestedRB * 100

Table 73: QoS of data services – KPIs

7.2.4. QoS – VT service

For VT calls the QoS consists of voice and video quality. One Tool that canprovide the quality assessment of the video samples, as a MOS value, is ex-Lucent’s LVAT. Although there is an ITU standard that defines the framework ofvideo quality measurement [48], it does not layout the algorithm and calibrationof the MOS and hence that remains vendor propriatry. For voice QoS parameterthe metric of subsection 7.2.2 is used.

Table 74 below is listing the formulas to retrieve the other QoS parameters forVT:

KPI Counter / KPI

Call completion success rate VT[%]

NoSuccCompletedCallsVT / NoSuccSetupCallsVT * 100

Block call rate VT [%] (NoSetupFailedCallsVT - SetupFailedCallNoNetworkVT) /NoCallAttVT *100

Dropped calls VT [%] NoDroppedCallsVT / NoSuccSetupCallsVT * 100

Call setup success rate VT [%] NoSuccCallSetupVT / NoCallAttVT * 100

Table 74: QoS of VT services – KPIs




Date: 2007-06-08 Rev: 2.1


Appendix

A. Measurement definitionA.1. Measurement definition – voice

For voice services the UMTS UE in the drive test van should call an ISDN line inthe PLMN because otherwise it is hard to distinguish if the first or the secondmobile is responsible for observed failures or also for voice qualitydegradations. This will help the RF planner to analyse the failure and proposeadditional network changes.

The voice test call sequence for the UMTS UE in the drive test van should be asfollows:

• Network attach

• Mobile Originating Call (MOC), duration 2 minutes, alternating speechsample 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 speechsample from UE to the PLMN and vice versa.

• Network detach and pause of around 10 seconds

The used drive test equipment should be capable of do generating thismeasurement sequence automatically.

In parallel the RF conditions of the UE and the neighbouring cells should berecorded using the drive test tool and a 3G and 2G scanner in parallel.

A.2. Measurement definition – data

When doing KPI performance verification of data services the FTP servershould be directly connected to the GGSN to avoid any latency and delaycaused by the Internet. For security reasons a special test APN should be used.

The FTP throughput should be measured in motion and in addition alsostationary 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 therepeatability leading to ease of comparison and analysis. Data scripts aresupported by most of the drive test tools, but can also be made with tools likecygwin providing a full Linux command shell environment [38]

19.

The data test call sequence should be as follows:

• Network attach and PDP context activation• FTP download of three times 2 MB file, 5 seconds pause in between

• Pause of 20 seconds

• FTP download of three times 2 MB file, 5 seconds pause in between

• Pause of 20 seconds

19 The original DOS FTP client should be used instead the FTP client from cygwin (/usr/bin/ftp). This

can be achieved by defining a variable called FTP_CMD = “c:\winnt\system32\ftp.exe” in the scripts.




Date: 2007-06-08 Rev: 2.1


• FTP upload of three times 1 MB file, 5 seconds pause in between

• Network detach, PDP context deactivation and pause of around 10

secondsFor troubleshooting purposes it might be necessary to record the TCP/IPprotocol analyser as Ethereal on both the UE and the FTP server side [30].

In parallel the RF conditions should be recorded.

For measuring the maximum possible throughput on a radio link UDP shall beused because TCP retransmission might give an incorrect picture of thebandwidth capability.

The TCP configuration of the client PC and the server should be comparablewith the settings most common used by “normal” UMTS subscribers and in theInternet. TCP window size of the sending entity should be large enough so theRLC queue in the RNC is not going into underrun. For that reason it is helpful tomeasure the amount of “in-flight-packets” to calculate the right settings for the

TCP window size.Table 75 below is listing the default TCP/IP parameter that should be usedduring the testing:

Entity Feature Setting Short description

Client SACK Set to TRUE SACK allows the receiver to inform the sender about allsegments that are successfully received

Server TCP windowsize

35 kbyte The TCP window is the amount of outstanding data asender can send before it gets an acknowledgment for

the receiving entity

Client/server PDCPcompression

Disable When doing root cause analysis the feature should bedisabled

Client/server PPPcompression Disable When doing root cause analysis the feature should bedisabled

Server StartingMSS

4 packets The amount of TCP/IP packets sent by the sendingentity at the beginning. Further packets will be send after

reception of the first TCP ACK

Client ICMP packetsize

40 byte To measure the ICMP RTT an IP packet should be sentwith the size of 40 byte (8 byte header plus 32 byte

payload)

Client/server MSS 960 byte The MSS should be 960 byte resulting in a MTU of 1000byte (= MSS + 20 byte TCP header + 20 byte IP

header). The actual TCP/IP packet size used might besmaller if Internet router is segmenting the packets

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

The TCP/IP settings can be verified using Ethereal. The settings can be set forWindows PCs in the registry or with help of shareware tools like [39]. For UNIXand Linux operating systems the settings can be set in the correspondingconfiguration files.

In case ciphering on RLC/MAC and data compression on PPP/PDCP are notused, special prepared ASCII files shall be used. This will ease the identificationof each single packet in Ethereal, Iub or Iu traces to detect retransmission onTCP or RLC. Note that on Iu, Gn and Gi there is no compression and cipheringused so using the particular tracing equipment can identify the ASCII payload.




Date: 2007-06-08 Rev: 2.1


The special ASCII files should contain only one (!) line and as an example thefollowing sequence:

“umts000000000umts000000001umts000000002umts000000003umts000000004umts000000005umts000000006 …”

In case PPP data compression is on, zipped data shall be used to avoidirregular throughput measurements.

Finally care should be taken that no other application on the PC are generatingany unnecessary network traffic.

Figure 38 below is showing a snapshot of the Ethereal protocol analyser:

Figure 38: Ethereal protocol analyser




Date: 2007-06-08 Rev: 2.1


A.3. Measurement definition – VT

For VT one mobile should be located in the drive test van, the other mobileshould be stationary located close to a UMTS site outside the UMTS clusterunder test; this will minimise possible failure causes for this second UE and helpthe RF planner at the root cause analysis.

The measurement sequence should be the same as defined for voice callsexcept that a network attach/detach is not necessary because this is serviceindependent.

So the full measurement sequence for the VT should be as follows:

• Mobile Originating Call (MOC), duration 2 minutes, alternating speechsample from UE 1 to UE 2 and vice versa.

• Pause of around 10 seconds

• Mobile Terminating Call (MTC), duration 2 minutes, alternating speechsample 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 ensuretime synchronisation to enable a 3

rd party software like Actix to do the cross-

correlation.

There are many possibilities to synchronise clocks of the particularmeasurement PC like NTP, GPS or also using a radio clock available in someEuropean countries. Under no circumstances NTP should be used via an UMTSlink because NTP is not designed for wireless network showing a high variance

on the lower protocol layer like RLC.One software that can be used for time synchronisation is Tardis2000 [32]. Itcan be configured as a NTP server and NTP client or using GPS. Furthermore itis possible to configure the Tardis2000 NTP client that it adjusts its internalclock within a predefined time frame.

It has to be verified if the application running on the PC has to be restarted inorder to retrieve the updated time.

Figure 39 below is showing the measurement setup for analysing PS dataservices when doing drive testing in a van, Figure 40 for doing VT testing in alab.




Date: 2007-06-08 Rev: 2.1

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

RNC

Iub Iu

Uu

(cabled)

UMTS protocol

analyser

NodeB CNFadingsimulator

Mobile voiceevaluation drive

test equipment

Stationaryvoice/VT

evaluation drive

test equipment

Uu(cabled)

2nd mobile inshadowing box

umts troubleshooting RF Guide line (Alcatel Lucent).pdf

Documents

Transcript of umts troubleshooting RF Guide line (Alcatel Lucent).pdf