umts rf troubleshooting guideline

Document name:

UMTS RF Troubleshooting Guideline U04.03Rev: 2.1

Date:

2007-06-08

UMTS RF Troubleshooting Guideline U04.03Author: Editor: Date: Version:Matthias Braun Irfan Mahmood 6th August 2007 2.1

UMTS Network Performance Engineering

Page 1 of 106

Document name:


Date:

2007-06-08

Table of Contents1. 2. 3. GLOSSARY OF TERMS AND ABBREVIATIONS................................................................. 5 REFERENCES ........................................................................................................................... 10 ABOUT THIS DOCUMENT..................................................................................................... 12 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 4. 5. INTRODUCTION ...................................................................................................................... 12 CONTENT ............................................................................................................................... 12 HOW TO READ ....................................................................................................................... 13 UTRAN/CN RELEASE AND VENDOR DEPENDENCY ............................................................... 13 INTENDED AUDIENCE ............................................................................................................. 13 DISCLAIMER - WHAT IS NOT COVERED ................................................................................... 13

DESCRIPTION OF THE OPTIMISATION PROCESS ........................................................ 14 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


Page 2 of 106

Document name:


Date:

2007-06-08

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


Page 3 of 106

Document name:


Date:

2007-06-08

7.2.1. 7.2.2. 7.2.3. 7.2.4.

QoS general ............................................................................................................... 96 QoS voice service....................................................................................................... 96 QoS data services....................................................................................................... 97 QoS VT service ........................................................................................................ 101

APPENDIX ....................................................................................................................................... 102 A. MEASUREMENT DEFINITION ....................................................................................................... 102 A.1. Measurement definition voice .......................................................................................... 102 A.2. Measurement definition data............................................................................................ 102 A.3. Measurement definition VT .............................................................................................. 105 B. TIME SYNCHRONISATION OF MEASUREMENT TRACES ................................................................. 105

Change RecordThis table details the changes done to the document since the last baseline version

Date 6 August 2007th

Changes Updated draft after review with following changes Editorial throughout the document Added sections like HSUPA, InterFreq HO, RRC connection reestablishment, 2G->3G IRAT HO

Issue# 2.1


Page 4 of 106

Document name:


Date:

2007-06-08

1. Glossary of terms and abbreviations3GPP ACB ACK AICH ALCAP APN AM ARQ AS ATM BCCH BER BLER BSIC BSS CAC CCPCH CM CN CongC CPICH CQI CRC CRCI CS DAHO DBC DCCH DCH DL DRNC DRX EDCH 3G Partnership Project Access Class Barring Acknowledgement Acquisition Indication Channel Access Link Control Application Protocol Access Point Number Acknowledged Mode Automatic Repeat Request Access Stratum Asynchronous Transfer Mode Broadcast Control Channel Bit Error Rate Block Error Rate Base Station Identity Code (GSM) Base Station Subsystem (GSM) Call Admission Control Common Control Physical Channel Configuration Management / Connection Management Core Network Congestion Control Common Pilot Channel Channel Quality Indicator Cyclic Redundancy Checksum CRC Indicator Circuit Switched Database Assisted HO Dynamic Bearer Control Dedicated Control Channel Dedicated Channel Downlink Drift RNC Discontinuous Reception Enhanced DCH


Page 5 of 106

Document name:


Date:

2007-06-08

ETSI FACH FDD FM FP FSN FTP GGSN GMM GPRS GPS GSM HCS HLR HHO HO H-PLMN HSDPA HS-DSCH HSUPA HTTP H-USDPA HW IE ICMP IP IRAT KPI LA LWS MAC MAC-hs MAHO MIB MM MMS MO

European Telecommunication Standard Institute Forward Access Channel Frequency Division Duplex Fault Management Framing Protocol First SN File Transfer Protocol Gateway GPRS Support Node GPRS MM General Packet Radio Services Global Positioning System Global System for Mobile Communication Hierarchical Cell Structure Home Location Register Hard Handover Handover Home PLMN High Speed Downlink Packet Access High Speed Downlink Shared Channel High Speed Uplink Packet Access Hyper Text Transfer Protocol High Speed Downlink Packet Access Hardware Information Element Internet Control Message Protocol Internet Protocol Inter Radio Access Technology Key Performance Indicator Location Area Lucent Worldwide Services Medium Access Control Medium Access Control high speed Mobile Assisted HO Master Information Block Mobility Management Multi Media SMS Mobile Originating


Page 6 of 106

Document name:


Date:

2007-06-08

MOS MSC MSS MNC MT NACK NAS NBAP NTP O&M OMC-U PCPICH PC PCH PDCP PDP PDU PHY PICH PLMN PM PPP PS PSC QE QoS RA RAB RACH RAN RANAP RB RL RLC RLF RF RFCT

Mean Opinion Score Mobile Switching Centre Maximum Segment Size Mobile Network Code Mobile Terminating Negative ACK Non access stratum NodeB Application Part Network Time Protocol Operation and Maintenance Operations and Maintenance Centre UMTS Primary CPICH Power Control Paging Channel Packet Data Convergence Protocol Packet Data Protocol Protocol Data Unit Physical Layer Paging Indication Channel Public Land Mobile Network Performance Measurement Point to Point Protocol Packet Switched Primary Scrambling Code Quality Estimate Quality of Service Routing Area Radio Access Bearer Random Access Channel Radio Access Network Radio Access Network Application Part Radio Bearer Radio Link Radio Link Control Radio Link Failure Radio Frequency RF Call Trace (also called IMSI tracing)


Page 7 of 106

Document name:


Date:

2007-06-08

RNC RNSAP RRC RRM RSSI RSCP RTP RTT RXLEV SACK SC SCCPCH SCH SDU SGSN SHO SIB SIM SIR SM SMS SN SRB SRNC TB TBS TCP TGPS TM TPC TSSI TX UDP UE UL UM UMTS

Radio Network Controller Radio Network Subsystem Application Part Radio Resource Control Radio Resource Management Received Signal Strength Indicator Received Signal Code Power Real Time Protocol Round Trip Time Receive Level (GSM) Selective ACKs Scrambling Code Secondary CCPCH Synchronization Channel Service Data Unit Serving GPRS Support Node Soft/softer Handover System Information Broadcast Subscriber Identity Module Signal to Interference Ratio Session Management Short Message Service Sequence Number Signalling Radio Bearer Serving RNC Transport Block Transport Block Size Transmission Control Protocol Transmission Gap Pattern Sequence Transparent Mode Transmit Power Control Transmitted Signal Strength Indicator Transmitted User Datagram Protocol User Equipment (mobile station) Uplink Unacknowledged Mode Universal Mobile Telecommunication Standard


Page 8 of 106

Document name:


Date:

2007-06-08

URA U-SIM UTRAN VT

UTRAN Registration Area UMTS Subscriber Identity Module UMTS Terrestrial Radio Access Network Video Telephony

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


Page 9 of 106

Document name:


Date:

2007-06-08

2. References[1] TS 23122 NAS Functions related to Mobile Station (MS) in idle mode [2] TS 11.11 Specification of the SIM ME interface [3] TS 25304 UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected Mode [4] GSM 03.22 Functions related to Mobile Station in idle mode and group receive mode [5] TS 24008 Mobile radio interface layer 3 specification; Core Network Protocols Stage3 [6] TS 25331 RRC Protocol Specification [7] TS 25433 UTRAN Iub Interface NBAP Signalling [8] TS 24007 Mobile radio interface signalling layer 3 specification; general aspects [9] TS 25413 UTRAN Iu Interface RANAP Signalling [10] TS 25423 UTRAN Iur Interface RNSAP Signalling [11] TS 25214 Physical layer procedures (FDD) [12] TS 25922 Radio resource management strategies [13] TS 25201 User Equipment (UE) Radio transmission and reception (FDD) [14] TS 25306 UE Radio Access Capabilities [15] TS 34121 Terminal conformance specification; Radio transmission and reception (FDD) [16] UMTS RF Translation Application Note (TAN) for HSDPA [17] UMTS RF Translation Application Note (TAN) for EDCH [18] UMTS RF Translation Application Note (TAN) for Cell Selection and Reselection [19] UMTS RF Translation Application Note (TAN) for Access Procedures [20] UMTS RF Translation Application Note (TAN) for Load Control [21] UMTS RF Translation Application Note (TAN) RLC [22] UMTS RF Translation Application Note (TAN) RF Call Trace [23] UMTS RF Translation Application Note (TAN) Handover [24] UMTS RF Translation Application Note (TAN) Inter-Frequency Handover [25] UMTS RF Translation Application Note (TAN) Inter-RAT Handover [26] UMTS RF Translation Application Note (TAN) Inter Frequency Handover [27] UMTS RF Translation Application Note (TAN) Radio Link Control [28] UMTS RF Translation Application Note (TAN) Power Control [29] Actix, http://www.actix.com


Page 10 of 106

Document name:


Date:

2007-06-08

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


Page 11 of 106

Document name:


Date:

2007-06-08

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

Furthermore this guideline is cross correlating the observed occurrences to the corresponding UTRAN parameter, PM counters and KPIs of the UTRAN and/or CN and gives references. Last but not least this document is used as a specification for writing queries that automatically identify and classify failures and problems from network interface traces and drive test data. For more information see [41].

3.2.

ContentThere are five main chapters in this document: Chapter About this document is providing an introduction and an overview of the UMTS RF Troubleshooting Guideline. Chapter Description of the optimisation process is providing a short overview of the UMTS optimisation process as covered by the UMTS RF Troubleshooting Guideline. Chapter Call setup is listing all problems that might occur at the call establishment phase. Chapter Call reliability is describing failures and problems that might occur after call establishment; examples are dropped calls, radio link failures or handover problems. Chapter Call quality is dealing with quality problems as perceived by the UMTS subscriber.


Page 12 of 106

Document name:


Date:

2007-06-08

3.3.

How to readThe main analysis chapters are subdivided into subsections that are describing the particular problems and failures step by step. Basis for the structure is the UMTS call handling. The subsections are structured as follows: In the first part, the problem and when applicable corresponding UTRAN parameter are described and listed; this part has the subtitle concept. In the second part called failure symptoms, identification and fixes for improvement there are if applicable three tables: o The first table is specifying the trigger points for the identification in the network interface trace or in the drive test data including the type of traces necessary for problem identification (e.g. Uu trace, 3G scanner measurements or TCP/IP protocol interface trace) The second table is listing the PM KPIs as retrieved by the UTRAN or CN PM system The third table is listing the corresponding parameter(s)

o o

3.4. UTRAN/CN release and vendor dependencyThis document is a living document and is updated on a regular basis based on the experience coming from the different projects. This version of the UMTS RF Troubleshooting Guideline is supporting exLucent equipment only. However it is geared towards supporting multi-vendor equipment so long as they follow 3GPP mandated procedures. Whenever a new UTRAN or CN network release is available certain tables and descriptions have to be updated while others parameters are project dependent and hence no particular value is assigned to them.

3.5.

Intended audienceThis document is directed to system engineers, network planners, RF optimisation engineers and all engineers that are going to analyse network with the aim of optimising a UMTS network.

3.6.

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


Page 13 of 106

Document name:


Date:

2007-06-08

4. Description of the optimisation processThe different fields of UMTS RF optimisation can be summarised by the following items: FM audit and analysis RF design audit and and [34] for a detailed description) CM audit and optimisation PM audit and optimisation Drive testing and investigation Network interface tracing and analysis Lab investigation and optimisation optimisation (see [33]

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

Figure 1: Ex-Lucent UMTS optimisation process process flow


Page 14 of 106

Document name:


Date:

2007-06-08

Pre-requisite before starting with a performance verification and optimisation is that The FM analysis shows no severe alarms that might influence the performance measurements as retrieved by the PM statistic or drive test data The RF design audit and optimisation has been finished for the region to be optimised

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


Page 15 of 106

Document name:


Date:

2007-06-08

5. Call setupOne main user perception of a UMTS network is the success of setting-up a UMTS call. This section is describing all kind of failures and problems that might occur during the call establishment phase. The different phases during the call setup are covered step-by-step in the following subsections of this chapter.

5.1.

Call setup RRC connection establishment5.1.1.1. Concept PLMN selection and reselection Cell selection and reselection Location registration

5.1.1. PLMN/cell selection and reselection

The UE in idle mode has to perform the following tasks:

The whole procedure is visualised in Figure 2 below and will be explained in detail in the following subsections:

Figure 2: PLMN (re-)selection and cell (re-) selection process If the UE is in CELL_FACH, CELL_PCH or URA_PCH the UE also performs cell reselections; however possible failures that may occur are covered in the subsection regarding failures on RACH (subsection 5.1.3) and FACH (subsection 5.1.6). In the following it is assumed that the UE is in idle mode.


Page 16 of 106

Document name:


Date:

2007-06-08

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

For UMTS:

Squal = Qqualmeas - Qqualmin > 0 AND Srxlev = Qrxlevmeas Qrxlevmin - Pcompensation > 0 Srxlev = Qrxlevmeas Qrxlevmin - Pcompensation > 0

For GSM:

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

UE_TXPWR_MAX_RACH is the maximum allowed power for the RACH and P_MAX is the maximum power for the given mobile power class.

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

Parameter Qqualmin Qrxlevmin

DescriptionMinimum required quality level in the cell (dB). Not applicable for TDD cells or GSM cells, broadcasted via SIB3 and SIB4 Minimum required RX level in the cell (dBm), broadcasted via SIB3 and SIB4

Table 1: Parameters used for cell selection


Page 17 of 106

Document name:


Date:

2007-06-08

Remark The current formulas can only be used in case HCS is not deployed. Furthermore while camping the UE shall start to perform inter-RAT measurements if Squal Qqualmin + SsearchRAT If the above condition is not satisfied, a UE will move from GSM to UMTS and immediately start monitoring neighboring GSM cells again, an undesirable condition. Furthermore frequent re-selections between UMTS and GSM can cause mobile terminating call failure in case the PLMN pages the current network while the UE is in the process of registering with the other network. In a similar way the criterion for UMTS Interfrequency measurements is defined; for this parameter Sintersearch is used and is broadcasted on SIB3/SIB4. The UE can only reselect one of the 2G or 3G cells that are defined in the reselection list that are broadcasted via SIB11/SIB12 on the BCCH. For cell reselection the target cell has to fulfill the same criteria as specified for the cell selection case. The UE ranks the cells according to the cell ranking criteria Rs (serving cell) and Rn (neighbour cell). The UE will reselect the best GSM or UMTS cell of the ranking list if at least Treselection (UMTS parameter) has elapsed when camping on the cell. For UMTS network without HCS the following formulas are used (both for GSM and UMTS cells): Rs = Qmeas,s + Qhysts Rn = Qmeas,n - Qoffsets,n For UMTS Qmeas is based either on RSCP or Ec/No measurements of the server/neighbour cell depending on the setting of the UTRAN parameter configuring the selection and reselection quality measure. Qhysts is an hysteresis to avoid ping-pong effects, Qoffsets,n is an offset defined on a per-neighbour definition (for both GSM and UMTS neighbours). The reselection process using the mentioned parameters (Qoffsets,n = 0) is visualised in Figure 3 below:

Figure 3: Cell reselection process


Page 18 of 106

Document name:


Date:

2007-06-08

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

ParametercellSelAndResQualMeas sIB3Treselection sIB3RAT.sSearchRAT sIB3SInterSearch sIB3Qhyst1, sIB3Qhyst2 outFDDAdjCells.cellOffset

DescriptionParameter defining whether CPICH or RSCP measurement shall be used for UMTS measurements Time hysteresis for the cell reselection UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start with inter-RAT measurements (setting of SSearchRAT) UMTS parameter broadcasted via the SIB3/SIB4 defining whether or not to start with UMTS interfrequency measurements (setting of Sintersearch) Hysteresis to avoid ping-pong effects (RSCP, Ec/No hysteresis) UMTS parameter broadcasted via the SIB11/SIB12 defining an offset on a per neighbour basis

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

A failure of the PLMN selection/reselection during a drive test can be easily identified when the screen of the drive test mobile is showing Limited Service and the MNC of the selected cell is different from the H-PLMN. The root cause might be a network outage due to NodeB, RNC or any particular network interface like Iub or Iu (see also subsection 6.4.5 and 6.8) or when the test van is driven out of the coverage footprint of the (GSM and UMTS) network. In that case the drive test route should be checked. When the PM counters of the CN are showing a high rejection rate due to missing national roaming it may be caused by an interface problem to or an outage in the roaming networks be it UMTS or GSM. Another problem might be ACB on one or several of the surrounding GSM and/or UMTS cells. Information regarding Access Class Barring is broadcasted via SIB3 or SIB4 [6]. ACB is used during the integration of cells see [35] for details. Common problems of the cell selection/reselection procedure are non-optimised configuration of the corresponding UTRAN parameter. As a consequence the call will be setup on a non-optimal cell or a non-optimal RAN so the call-setup might fail during the RACH procedure (subsection 5.1.3), the paging procedure (subsection 5.1.2) or during the call setup procedure (subsection 5.2). A consistency check of the parameters listed in Table 1 and Table 2 might help to find parameter misconfiguration. Parameter Qoffsets,n used for optimisation of a per-cell basis should be reviewed. In case of poor 3G coverage and low call setup success rate the parameter SSearchRAT might be set to a lower value so the UE will start earlier with inter-RAT


Page 19 of 106

Document name:


Date:

2007-06-08

measurements. Also the cell offsets for the GSM cells can be adapted to prefer call setup on the 2G layer. Another problem arises when different LA codes are defined for the GSM and UMTS networks and the Inter-RAT reselection criterion is met. This is in particular the case for subscribers inside a building where the UMTS coverage is not as strong compared to the GSM coverage, but the preference is on the UMTS network. As a consequence it is recommended to assign the same LA codes to GSM and UMTS cells that are providing coverage to the same area to avoid LAU ping-pong. Table 3 below is listing the identification techniques of PLMN/cell (re-)selection failures in drive test traces and scanner measurements:

ProblemWrong PLMN selected ACB Call setup on nonoptimal cell Call setup on nonoptimal RAN technology Ping-pong LU between 2G / 3G

TraceUu Uu Uu, 3G scanner Uu, 2G/3G scanner

TriggerAny occurrence of the MNC of the cell the UE is camping on is different from the MNC of the H-PLMN Any occurrence of IE Access Class Barred = TRUE in SIB3/SIB4 The call is setup via RRCConnectionSetup message on a cell that is not on the x best cell listed by the 3G scanner within y dB window. The RXLEV of the best measured 2G cell is within a x dB window (or even better) for y seconds compared to the RSCP of the cell the UE is camping on when sending the RRC Connection Request or Cell Update message on RACH There are two consecutive LUs between 2G and 3G within x seconds and the LA codes for the cells are different.

Uu

Table 3: Identification of PLMN/cell (re-)selection failures in traces Cell selection and reselection failures cannot be detected via PMs because the process is within the UE. Failures during the Location Registration procedure are identified via CN PMs and covered in subsection 5.3.1. 5.1.2. Failures on the AICH, PICH and PCH 5.1.2.1. Concept

The UTRAN might initiate the paging procedure because of the following events: The UTRAN is receiving a paging request from the CN via RANAP The UE has an established PDP context, but the UE is in URA_PCH or Cell_PCH mode and downlink PS data are scheduled to be delivered in the downlink

If the UE is in idle, URA_PCH or CELL_PCH modes and the UE is receiving a Paging Indication on the PICH from the NodeB; then the UE is starting to monitor the PCH to receive the paging (Paging Type 1). In case the UE is in connected mode and is paged, then the UTRAN is sending the paging via DCCH (Paging Type 2). The CN might perform a repetition of paging process in case the UE has not answered within a certain period in time. In addition the RNC might trigger the repetition of the UE paging in the UTRAN. The repetition timers of the RNC and CN have to be set accordantly. In the following it is assumed that the UE is not in connected mode so it has received a Paging Type 1.


Page 20 of 106

Document name:


Date:

2007-06-08

After the UE has successfully decoded the paging on the PCH it sends a RACH Preamble using the open loop power control algorithm. When the NodeB receives the RACH Preamble it answers by sending an indication on the AICH, the reception of the AICH is answered by the UE by sending a RRC Connection Request/Cell Update/URA Update message using the RACH (so called RACH Message Part). Upon successful decoding the NodeB forwards the RACH Message Part to the RNC. RACH failures are covered in subsection 5.1.3. The RNC sends back (on the FACH) the RRC Connection Setup/Cell Update Confirm/URA Update Confirm message (successful case). FACH failures are covered in subsection 5.1.6. 5.1.2.2. Failure symptoms, identification and fixes for improvement 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

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

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

ParameterpICHPower pCHPower aICHPower CN_PCH_Timer tPageRep CN_PCH_Max nUtranPageRep1

DescriptionUTRAN parameter defining the power settings of the PICH UTRAN parameter defining the power settings of the PCH UTRAN parameter defining the power settings of the AICH Timeout when the CN will reinitiate the paging Timeout when the RNC will reinitiate the paging Maximum number of paging repetitions by the CN Maximum number of paging repetitions by the RNC

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

The paging itself is sent on the PCH that is a PHY channel on Uu. The drive test equipment can record paging requests. However analysing drive test logs is not a good way to investigate paging problems because paging that is not received by the UE can only be detected via parallel Iub tracing. A better approach for analysing call setup problems due to paging failures is to use PM counters of the UTRAN and the CN. If the UE is in URA_PCH or CELL_PCH mode, the RRC connection is maintained via the common physical channels (subsection 6.6). When the UE cannot be reached via paging the UTRAN may decide to drop the RRC connection.

1

CN_PCH_Timer

& CN_PCH_Max are dummy names for the parameters Page 21 of 106


Document name:


Date:

2007-06-08

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

TraceIub and Iu

TriggerCross correlation Iu and Iub trace: any occurrence where a UE page is recorded on Iub, there is no Cell Update recorded on Iub within x seconds and the RNC is sending back within y seconds an Iu Release Request message with cause Release due to UTRAN generated reason (UE is either in URA_PCH or CELL_PCH mode) Any occurrence where a UE is paged and recorded on the Iub and there is no answer by the UE on UL CCCH also recorded on the Iub within x seconds

Unsuccessful paging

Iub


Page 22 of 106

Document name:


Date:

2007-06-08

Table 5: Identification of PICH/PCH/AICH failures in traces Table 6 below is listing the identification possibilities using KPIs/Counters retrieved by the CN and/or UTRAN PM system. PM systemRNC UtranCell

Counter / KPIVS.MM.RRCConnDrop.UTRANPagingFailure VS.MM.PagAttDiscard.ProcessorLoad

KPI Name / DescriptionCounting the number of RRC drops due to UTRAN Paging failures This measurement provides the number of paging attempts discarded by the RNC TPU due to processor load This measurement provides the number of paging attempts received by the RNC KPI Paging success rate. Paging success rate defines the rate of successful paging in the packet network. The measurement provides the number of successful page responses from MS. The attempt and success counts are used to monitor the paging performance. Provides the channel occupancy rate for the PCH channel

RNC 3G-SGSN

VS.MM.PagAttRec (MM.SuccPsPagingProcIu + SuccPsPagingRepititionsIu) / (MM.AttPsPagingProcIu + AttPsPagingRepititionsIu)*100 VS.succFirstPageReqs

3G-MSC

RNC

VS.ChannelOccupRatePCH

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

5.1.3. Random Access Procedure 5.1.3.1. Concept

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


Page 23 of 106

Document name:


Date:

2007-06-08

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

Figure 6: Cell Update procedure supervised by T302 and V3022

is a placeholder for e.g. OrigConvCall, OrigStrmCall etc. A full list is available in [42]. UMTS Network Performance Engineering Page 24 of 106

Document name:


Date:

2007-06-08

Failures in the RACH procedure occur if either the RACH Preamble or the RACH Message Part cannot be decoded. Possible reasons for these decoding problems are: Non optimal RACH power settings Non optimal RACH counter/timer settings RACH congestion Non optimal setting of physicalRACHPreambleThreshold & RACH search Window 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:

ParameterconstantVal PowerRampStep maxRetranPreamble physicalRACHPreambleThres hold SIB3MAXAllowedULTXPower, SIB4MAXAllowedULTXPower mMax t300

DescriptionUsed by UE to calculate Initial Preamble Power Determines the power increment between two successive RACH Preambles Determines the maximum number of preambles allowed within one Power Ramping Cycle The threshold for preamble detection. The ratio between received preamble power during the preamble period and interference level shall be above this threshold in order to be acknowledged. These parameters define the maximum allowed power the UE may use when accessing the cell on PRACH in idle mode Determine the maximum number of power ramping cycles allowed UE guard timer that is supervising the RRC Connection Setup procedure when the UE is waiting for the RRC Connection Setup message Defines the number of times the UE is allowed to send the same RRC Connection Request message UE guard timer that is supervising the Cell/URA Update procedure when the UE is waiting for the Cell Update Confirm/ URA Update Confirm message Defines the number of times the UE is allowed to send the same Cell Update/ URA Update message

n300 t302

n302

Table 7: Parameter used for configuring the RACH For a complete list of RACH parameters see also [19]. 5.1.3.2. Failure symptoms, identification and fixes for improvement

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


Page 25 of 106

Document name:


Date:

2007-06-08

and MAC procedure of the RACH is listed in the drive test logs e.g. number of 3 RACH Preambles sent, last transmitted power etc . Possible congestion on the RACH could be detected by supervision of PM UTRAN counters (Table 9 below). The RACH performance can be improved by changing of the power settings and/or changing of the timer/counter as listed in Table 7. Table 8 below is listing the identification possibilities for network interface traces, Table 9 below is listing the identification possibilities using KPIs retrieved by the UTRAN PM system.

ProblemRACH message lost

TraceUu, Iub

TriggerCross-correlation Uu/Iub trace: RACH Message Part (RRC Connection Request, Cell Update or URA Update) is recorded on the Uu, but not recorded on the Iub interface.

Table 8: Identification of RACH failures in traces

PM systemUtranCell UtranCell

Counter / KPIVS.RACHcongestion VS.RACHTransBlock.Good / (VS.RACHTransBlock.Bad + VS.RACHTransBlock.Good) * 100 VS.ChannelOccupRateRACH

KPI Name / DescriptionThis measurement provides the percentage of time that the RACH is in congested state. KPI RACH transport block good CRC rate is the percentage of RACH Transport Blocks with good CRC. This measurement provides the channel occupancy rates for Radio Access Channel.

UtranCell

Table 9: PM KPIs for RACH failures More RACH related PM KPIs are available in [19].

5.1.4. Call Admission Control (CAC) 5.1.4.1. Concept

The Call Admission Control (CAC) procedure is used in order to admit or deny the establishment of the RRC connection to avoid an overload of the UMTS system. The CAC thresholds can be defined for uplink and downlink load separately. The CAC algorithms and the corresponding parameter are described in detail in [20]. The CAC is started after the RNC receives the RRC Connection Request message on RACH and executes CAC before setting up the RL on NBAP (see Figure 7 below):

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 already failed. The higher layer (RRC) initiates the transmission of the RACH message. In case of a lower layer failure ro deliver preamble it is up to the higher layer re-initiate the whole RACH procedure again (means in the RRC decoding another RACH Message would be listed). UMTS Network Performance Engineering Page 26 of 106

Document name:


Date:

2007-06-08

Figure 7: CAC executed after reception of RACH Message Part If the defined load thresholds for CAC are exceeded the RRC connection establishment request is denied and a RRC Connection Reject message with cause Congestion is sent back to the UE. The only optimisation approach in case of CAC rejections is to optimise the RF environment in terms of pilot pollution, neighbour list optimisation etc. In addition it should be verified that the CAC thresholds are set correctly. Table 10 below is listing the main parameters configuring CAC:

ParameterthrCAC2UL thrCAC2DL thrCAC2DLHS DPA

DescriptionSpecifies the load threshold for UL call admission of a non-emergency RRC connection request. Specifies the load threshold for DL call admission of a non-emergency RRC connection request when HSDPA is disabled. Specifies the load threshold for DL call admission of a non-emergency RRC connection request when HSDPA is enabled.

Table 10: Parameter configuring CAC 5.1.4.2. Failure symptoms, identification and fixes for improvement

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

ProblemRRC Connection Reject

TraceUu or Iub

TriggerAfter the UE sends a RRC Connection Request message the RNC replies with RRC Connection Reject message with cause Congestion .

Table 11: Identification of RRC Connection Reject due to Congestion or missing resources For CAC related PM KPIs see [20] however the main PM counter is given below:


Page 27 of 106

Document name:


Date:

2007-06-08

PM systemUtranCell

Counter / KPIRRC.FailConnEstab.CAC

Name / DescriptionThis measurement provides the number of failed RRC connection establishment with cause Call Admission Control (CAC).

Table 12: PM Counter for CAC failures 5.1.5. Radio Link Setup 5.1.5.1. Concept During the call establishment phase after the CAC is granted the RNC requests the NodeB to allocate resources through the NBAP Radio Link Setup message. In case of soft handover when allocating resources on a new NodeB

The Radio Link Setup procedure is initiated in two cases:

Note that after the Radio Link Setup on NBAP the RNC should initiate the establishment of the AAL2 bearer over the Iub interface using ALCAP (ALCAP Establishment Request and ALCAP Establishment Confirm). Problems on ALCAP could be due to ATM configuration and are outside the scope of this document. ATM synchronisation problems are not expected at this stage of the call because of the already successful NBAP procedure. The same is valid for the synchronisation between NodeB and RNC via the DCH-FP over AAL2 bearer.

Figure 8: Initial RRC Setup Steps after successful CAC

5.1.5.2.

Failure symptoms, identification and fixes for improvement

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


Page 28 of 106

Document name:


Date:

2007-06-08

According to [7] the failure causes can be classified as follows: Radio Network Layer Cause Transport Layer Cause Protocol Cause Miscellaneous Cause

Each category has many subcauses like Transport Resources unavailable, NodeB Resources unavailable or Semantic error etc. 3GPP has defined a variety of failure causes. Here one major reason for NodeB resources problem can be UCU capacity shortage, while transport resources issue can point to the backhaul bandwidth limitation. Table 13 below is listing the identification possibilities for network interface traces, Table 14 is listing the identification possibilities using KPIs retrieved by the UTRAN PM system. For identification of failures during the Radio Link Setup procedure Iub traces are mandatory. Reason is that on Uu only the RRC Connection Reject message is available with only two possible failure causes (congestion and unspecified), see also subsection 5.1.4.

ProblemRadio Link Setup I

TraceUu, Iub

TriggerCross-correlation Uu/Iub trace: Any occurrence of the NBAP Radio Link Setup Failure message on Iub and RRC Connection Reject with cause unspecified or congestion on Iub/Uu Any occurrence of the NBAP Radio Link Setup Failure message on Iub

Radio Link Setup II

Iub

Table 13: Identification of failures in the Radio Link Setup PM systemUtranCell

Counter / KPIRRC.FailConnEstab.RLSetupFailure/RRC.AttConnEstab.sum*100

KPI Name / DescriptionFailed RRC Connection Establishment Rate due to RL Setup failures Radio link setup success rate on Iub Radio link setup failure rate on Iub NodeB resource Radio link setup failure rate on Iub transport resource Radio link setup success rate on Iur

UtranCell UtranCell UtranCell RNC

RLM.SuccRLSetupIub / RLM.AttRLSetupIub*100 (RLM.FailRLSetupIub.NodeBRes.CSV + RLM.FailRLSetupIub.NodeBRes.CSD + RLM.FailRLSetupIub.NodeBRes.PSD) / RLM.AttRLSetupIub*100 (RLM.FailRLSetupIub.TransRes.CSV + RLM.FailRLSetupIub.TransRes.CSD + RLM.FailRLSetupIub.TransRes.PSD) / RLM.AttRLSetupIub*100 (RLM.AttRLSetupIur RLM.FailRLSetupIur.sum) / RLM.AttRLSetupIur * 100

Table 14: PM KPIs for Radio Link Setup failures

5.1.6.Call setup failures on the FACH 5.1.6.1. Concept

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


Page 29 of 106

Document name:


Date:

2007-06-08

It is assumed that the RACH Message Part has been successfully received, the CAC has been granted and the RL are established. In this case the RNC sends back either the RRC Connection Setup, Cell Update Confirm or URA Update Confirm message on FACH (successful case). The RNC sends the FACH message, resets counter V30001 and starts its guard timer T30001. When the RNC receives the answer by the UE (RRC Connection Setup Complete, UTRAN Mobility Information Confirm, Radio Bearer Reconfiguration Complete, ) before T30001 expires, the RNC stops T30001. If the RNC does not receive the message before T30001 expires, the RNC may resend the FACH message depending on the status of counter V30001. If V30001 N30001, the RNC will stop sending FACHs to the UE and will release the reserved resources on NBAP and ALCAP. Note that the RNC will not send any failure message on the Uu. The whole procedure is visualised in Figure 9 below:

Figure 9: Failures on FACH


Page 30 of 106

Document name:


Date:

2007-06-08

Table 15 below is listing the parameters configuring the FACH:

ParameterfACHTrafPower fACHSigPower uERRCConnectionSetupRes ponseTimer maxRRCConnSetupRetries

DescriptionUTRAN parameter defining the power settings of the FACH data part UTRAN parameter defining the power settings of the FACH control part UTRAN parameter defining setting of T30001 UTRAN parameter defining setting of N30001

Table 15: Parameter used for configuring the FACH 5.1.6.2. Failure symptoms, identification and fixes for improvement Non optimal UTRAN parameter settings (e.g. FACH signalling and traffic power) Call setup not done on an optimal cell (subsection 5.1.1) The FACH message is not successfully decoded due to poor FACH coverage The message on the FACH is successfully decoded by the UE, but afterwards the RNC cannot successfully decode the answer sent by the UE (UE is already in CELL_DCH mode, see also subsection 5.2)

There are the following possible reasons for failures on FACH:

Failures on the FACH can be indicated by UTRAN PM statistics, Iub and Uu traces. On Uu FACH failures cannot be directly observed because there is no corresponding failure message sent. Table 16 below is listing the identification of FACH failures on Iub, Table 17 the corresponding PM KPIs:

ProblemLost FACH message FACH Failure

TraceIub and Uu Uu or Iub

TriggerCross-correlation Uu/Iub trace: one or more FACH messages are recorded on the Iub, but not on the Uu interface Any occurrence of a Cell Update/URA Update message and within x seconds there is a RRC Connection Release message with specified cause other than normal event sent back by the RNC

Table 16: Identification of failures on the FACH


Counter / KPIRRC.FailConnEstab.SetupIncomplete / RRC.AttConnEstab.sum*100 VS.PercentageFACHOccupancy

KPI Name / DescriptionFailed RRC connection Establishment Rate timeout Occupancy rate on FACH

Table 17: PM KPIs for failures on the FACH 5.1.7. RRC Connection Reject message with specified cause unspecified The UE might receive a rejection when trying to establish a RRC Connection with specified cause unspecified.


Page 31 of 106

Document name:


Date:

2007-06-08

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

ProblemRRC Connection Reject with cause unspecified

TraceUu

TriggerAny occurrence of an RRC Connection Reject message with specified cause unspecified.

Table 18: RRC Connection Reject unspecified There are no specific PM counters for that case; instead other PM counters with the name RRC.FailConnEstab. are used.

5.2.

Call setup failures during the call setup phaseAt this point in time the UE is in the transition phase to either CELL_FACH or CELL_DCH mode. The next message will already be sent in the new mode (as an example next message to be sent by the UE is RRC Connection Setup Complete or UTRAN Mobility Information Confirm). When transiting to the CELL_DCH mode there is the possibility that the UE is already in soft/softer handover mode when sending this message. This is the case if The UE is allowed to report the measurements of more than one NodeB in the RRC Connection Request / Cell Update message The UE is supporting this feature The measurement of more than one cell is reported in RRC Connection Request / Cell Update message The RNC is then directing the UE to soft/softer HO via RRC Connection Setup, Cell Update Confirm or URA Update Confirm message

5.2.1. Concept

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

ParametermeasQty.maxNoReport edCellsOnRACH addThresholdSHO

DescriptionDefines the maximum number of cells the UE may report on RACH Defines the hysteresis used at call setup to add neighbour cells to the Active Set

Table 19: Parameter important for the call setup phase For more details about the translations see [23]. If the call is setup in an area where several NodeBs are providing marginal coverage and it is not possible to add the radio legs quickly, there is a big likelihood that the call setup will fail. When the call is not setup in soft/softer HO mode the UE has to wait for the reception of the Measurement Control messageand time-to-trigger before sending Measurement Report 1a etc. 5.2.2.Failure symptoms, identification and fixes for improvement The RRC connection might drop in this early stage due to the following reasons:


Page 32 of 106

Document name:


Date:

2007-06-08

Non optimal handover parameter configuring the call setup in soft/softer handover mode Non optimal power settings Poor radio conditions in terms of low RSCP or Ec/No because of e.g. pilot pollution (subsection 6.4.1), poor RF coverage (subsection 6.4.5), camping on a non-optimal cell resulting in non-optimal reselection list (see subsection 5.1.1) etc.

There are no specific PM counters available that can be used to identify issues during the call setup phase because at this point the UE is already in CELL_DCH/CELL_FACH mode so a drop of the RRC connection cannot be differentiated from an RRC drop occurred in a later stage of the call. Also the drop might occur only a very short time later, but the root cause for the failure is one of the issues mentioned above. Nevertheless it is possible to identify issues in network interface traces as listed in Table 20 below:

ProblemCall setup on a nonoptimal cell Not best cells in AS at call setup Drop of RRC connection at call setup Call Setup not soft/softer HO mode in

TraceUu, 3G scanner Uu, 3G scanner Uu Uu, 3G scanner

TriggerThe call is setup via RRCConnectionSetup message on a cell and at the same time the 3G scanner is reporting at least x cells that are within a y dB window compared to the best measured cell. The number of cells in the Active Set is smaller than max AS size, but one neighbouring cell is within xdB window compared to the Ec/No of the best cell in the Active Set The call is dropped within x seconds after sending the RRC Connection Request or Cell/URA Update The call is setup in non soft/softer HO mode (# of SCs in RRC Connection Setup message is 1), the assigned SC is under the best x SCs measured by the 3G scanner, and these SCs are within y dB window as measured by the 3G scanner

Table 20: Identification of call setup in traces

5.3.

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

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


Page 33 of 106

Document name:


Date:

2007-06-08

Service Reject Cause is mapped on the Reject Cause of the Mobility Management IE [5]. Note that (almost) any failure in this subsection is not UTRAN related because 4 Direct Transfer messages are transparent to the UTRAN . Any of the failures can be easily detected by the corresponding failure messages. Because the protocols are transparent to the UTRAN all PM KPIs are defined within the CN entities e.g. SGSN / GGSN, 3G-MSC, basis. 5.3.1. Mobility Management failures 5.3.1.1. Concept

The main function of the mobility management is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. A mobility management context in the SGSN or 3GMSC is a prerequisite for the initialisation of voice, data or VT services. 5.3.1.2. Failure symptoms, identification and fixes for improvement

For the root cause analysis please review the timer settings supervising the mobility management protocols as specified in [5] chapter 11.2. The settings of these timers are specified and not configurable. In addition Mobility Management failures might be due to missing roaming agreement, locked SIM card, CN problems like authentication not possible due to inaccessible HLR database etc. The failure messages are retrieved from [5] chapter 9.2 (MM/CM) and 9.4 (GMM). Table 21 below is listing the Mobility Management failures as they can be retrieved by interface traces:

ProblemMM Authentication Reject CM Service Reject CM Service Abort

TraceUu or Iub or Iu Uu or Iub or Iu Uu or Iub or Iu

TriggerAny occurrence of a MM Authentication reject message sent by the CN e.g. because of not-allowed national/international roaming Any occurrence of a CM Service reject message sent by the CN; the reject cause will give an indication of the occurred failure. Any occurrence of a CM Service abort message sent by the UE. This message is sent by the mobile station to the network to request the abortion of the first MM connection establishment in progress and the release of the RR connection. Any occurrence of a MM Abort message sent by the CN. This message is sent by the network to the mobile station to initiate the abortion of all MM connections and to indicate the reason for the abortion. The rejection cause will give an indication about the occurred failure. Any occurrence of a MM Location updating reject message sent by the CN. The specified rejection cause will indicate the reason for the failure e.g. IMSI unknown in the HLR, illegal MS/ME, roaming not allowed etc. Any occurrence of a GMM Attach Reject message sent by the CN The specified rejection cause will indicate the reason for the failure e.g. protocol error, wrong or incorrect IE format etc.

MM Abort

Uu or Iub or Iu

MM Location Updating Reject

Uu or Iub or Iu

GMM Attach Reject

Uu or Iub or Iu

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. UMTS Network Performance Engineering Page 34 of 106

Document name:


Date:

2007-06-08

GMM Authentication and Ciphering Failure GMM Authentication and Ciphering Reject GMM Routing Area Update Reject GMM Service Reject

Uu or Iub or Iu

Any occurrence of a GMM Authentication and Ciphering Failure message sent by the UE. The specified rejection cause will indicate the reason for the failure e.g. a sync failure. Any occurrence of a GMM Authentication and Ciphering Reject message sent by the CN. Any occurrence of a GMM Routing area update reject message sent by the CN. The specified rejection cause will indicate the reason for the failure e.g. protocol error, wrong or incorrect IE format etc. Any occurrence of a GMM Service reject message sent by the CN

Uu or Iub or Iu Uu or Iub or Iu

Uu or Iub or Iu

Table 21: Identification of Mobility Management failures in interface traces Table 22 below is listing the PM KPIs of the Mobility Management as they can be retrieved by the PM system of the 3G-MSC and SGSN:

PM systemSGSN SGSN SGSN

Counter / KPI(MM.AttGprsAttach.U MM.SuccGprsAttach.U) / MM.AttGprsAttach.U * 100 (attAuthInSgsn succAuthInSgsn) / attAuthInSgsn * 100 (MM.AttGprsDetachSgsn.U MM.SuccGprsDetachSgsn.U) / MM.AttGprsDetachSgsn.U * 100 (attInterVLRLocationUpdates + attIntraVLRLocationUpdates) / (succInterVLRLocationUpdates + succIntraVLRLocationUpdates) * 100 MM.SuccInterSgsnRaUpdate.U / MM.AttInterSgsnRaUpdate.U * 100 MM.SuccIntraSgsnRaUpdate.U / MM.AttIntraSgsnRaUpdate.U * 100 VS.mobileOrigAttRejected

KPI Name / DescriptionGPRS attach failure rate Authentication failure rate SGSN initiated GPRS detach failure rate

3G-MSC

Location Update Success Rate

SGSN SGSN 3G-MSC

Inter SGSN routing area update success rate Intra SGSN routing area update success rate The counter is incremented for a mobile origination attempt that MSC for reasons other than system resource overload related. The counter is incremented for a mobile termination attempt that is rejected by the MSC for reasons other than system resource overload related.

3G-MSC

VS.mobileTermAttRejected

Table 22: PM KPIs/Counters for (GPRS) Mobility Management failures 5.3.2. Call Control failures 5.3.2.1. Concept

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


Page 35 of 106

Document name:


Date:

2007-06-08

5.3.2.2.

Failure symptoms, identification and fixes for improvement

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

ProblemUbnormal Disconnect Ubnormal Release CC CC

TraceUu or Iub or Iu Uu or Iub or Iu

TriggerAny occurrence of a CC Disconnect message (either UE or CN initiated) with specified cause other than normal event Any occurrence of a CC Release / Release Complete message (either UE or CN initiated) with specified cause other than normal event

Table 23: Identification of CC failures in interface traces Table 24 below is listing the PM KPIs of the CC failures as they can be retrieved by the PM system of the 3G-MSC: Counter / KPI5NoCCDisconnectUbnormalEvent / NoCCDisconnects * 100 NoCCReleaseUbnormalEvent / NoCCReleases * 100

PM system3G-MSC 3G-MSC

KPI Name / DescriptionUbnormal CC Disconnect Rate Ubnormal CC Release Rate

Table 24: PM KPIs for CC failures Depending on the specified failure cause the failure might be due to missing resources (e.g. requested circuit/channel not available), drive test configuration issue (e.g. User busy) or protocol failure. For the root cause analysis please check the timer settings supervising the CC protocol in [5] chapter 11.3. The settings of these timers are not configurable. 5.3.3.Session Management failures 5.3.3.1. Concept

The main function of SM is to support the PDP context handling of the PS services. The SM comprises procedures for identified PDP context activation, deactivation and modification. SM procedures for identified access can only be performed if a GMM context has been established between the UE and the CN (subsection 5.3.1). 5.3.3.2. Failure symptoms, identification and fixes for improvement

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

ProblemSM Activate PDP Context Reject

TraceUu or Iub or Iu

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

SM Activate Secondary PDP Context Reject

Uu or Iub or Iu

5

Dummy names Page 36 of 106


Document name:


Date:

2007-06-08

protocol error, missing or faulty APN, lack of resources etc. SM Request PDP Context Activation Reject Uu or Iub or Iu Any occurrence of a SM Request PDP Context Activation Reject message sent by the UE. The specified rejection cause is giving an indication of the type of failure e.g. protocol error, feature not supported, lack of resources etc. Any occurrence of a SM Modify PDP Context Reject message sent by the CN. The specified rejection cause is giving an indication of the type of failure e.g. protocol error, service option not supported, lack of resources etc.

SM Modify PDP Context Reject

Uu or Iub or Iu

Table 25: Identification of SM failures in interface traces Table 26 below is listing the PM KPIs of the SM failures as they can be retrieved by the PM system of the GGSN:

PM systemSGSN

Counter / KPI(1-((SM.FailActPdpCtxMs.Cause) / (SM.FailActPdpCtxMs.Cause+SM.SuccActPdpCtxMs)) )*100 SM.SuccModPdpContextSgsn.U / SM.AttModPdpContextSgsn.U * 100

KPI Name / DescriptionSession establishment success rate

SGSN

Network originated session modification success rate

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

5.4.

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


Page 37 of 106

Document name:


Date:

2007-06-08

Figure 10: RAB establishment procedure The RAB establishment procedure is always initiated by the RANAP RAB Assignment Request and always terminated by the RAB Assignment Response. The failure and failure causes of the RAB Establishment are specified in [9]; there are a variety of causes and it is up to the infrastructure vendor as to what failure is mapped to which particular failure cause. Table 27 below is listing how to identify failures of the RAB establishment procedure in network interface traces:

ProblemRAB establishment failure

TraceIu

TriggerAny occurrence of an RAB Assignment Response with specified failure cause according to 3GPP6

Table 27: Identification of RAB establishment failures in traces In the following subsections possible root causes for an unsuccessful RAB establishment are discussed in detail. 5.4.1. Dynamic bearer control (DBC) 5.4.1.1. Concept

Dynamic bearer control (DBC) is used to prevent overload of the R99 system in case new radio resources or radio resources requiring more power are requested. DBC takes place During the RAB establishment after the RNC is receiving the RAB Assignment Request on RANAP

6

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


Document name:


Date:

2007-06-08

During the transition of CELL_PCH/URA_PCH to CELL_DCH mode (see also subsection 6.6) after the RNC is receiving the corresponding RACH messages In case service based data rate increase is triggered (see also subsection 7.2.3) after the RNC receives a corresponding RRC Measurement Report from the UE

DBC thresholds can be defined for UL and DL load separately and DBC failure can also occur at stages other than RAB establishment. In case DBC grants the requested service the call handling proceeds as specified (depending on the phase of the call), otherwise the call handling is as follows: During the RAB establishment the RNC sends a RAB Assignment Response message on RANAP with specified cause No resource available under miscellaneous class. On Uu the following messages/outcomes will be indicating that DBC has not granted the requested service: o The assigned PS RB is smaller than the default one or the one 7 requested in the PDP Context Activation message ; the default PS RB is configurable OR the PDP Context Activation is rejected with an appropriate specified cause like QoS not accepted or Insufficient resources o o o The VT call is not granted or instead a voice call is setup The Voice call receives a CC Disconnect message with specified cause resource unavailable

During the transition of CELL_PCH/URA_PCH to CELL_DCH mode: The RNC sends back the UE to idle mode with the RRC Connection Release message and specified cause congestion OR The RNC sends back to the UE either a Cell Update Confirm / URA Update Confirm message, but the RRC State Indicator is set to CELL_PCH/URA_PCH. In case of service based data rate increase: the RRC Measurement Report message is just ignored so the UTRAN is keeping the current RB and Transport Channels

o

Not granting the requested service by DBC indicates either high cell loading or an area of high interference. The optimisation approach in the later case is to optimise the RF environment in terms of reducing pilot pollution, improving RF coverage, neighbour list optimisation etc. DBC uses a QoS parameter in order to prioritise different user when downgrading, see also [20] for details. 5.4.1.2. Failure symptoms, identification and fixes for improvement

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

7

The requested QoS profile in the PDP Context Activation message might be ignored and only a default one is assigned UMTS Network Performance Engineering Page 39 of 106

Document name:


Date:

2007-06-08

ProblemDBC RAB not granted on Iu DBC RAB not granted on Iu and Uu DBC RAB PS not granted DBC RB Setup PS DBC RB Setup VT DBC Release RRC

TraceIu Iu, Uu

TriggerAny occurrence of a RAB Assignment Response message on RANAP with specified cause No resource available Cross-correlation Uu/Iu trace: Any occurrence of a RAB Assignment Response message on RANAP with specified cause No resource available Any occurrence of a SM Activate PDP Context Reject message sent by the CN to the UE and the specified cause is Insufficient resources On Uu, in the RRC RB Setup Message the IE Spreading Factor is larger than the default one and a PDP Context Activation message was sent within the last x seconds with the requested bit rate in the DL higher than the granted one The VT call has been requested, the called entity is also a UE with VT capabilities but a voice RB is setup Any occurrence of an RRC Cell Update/URA Update message following within x seconds a RRC Connection Release message with specified cause congestion and the UE is in either CELL_PCH or URA_PCH mode The UE is sending a CC Setup message and within x seconds gets a CC Disconnect with cause resource unavailable The UE is sending a Cell Update/URA Update message and the RNC is sending back within x seconds a Cell Update Confirm/URA Update Confirm message with RRC State Indicator set to CELL_PCH/URA_PCH.

Iu or Iub, or Uu Uu

Uu Uu

DBC RB Setup voice DBC Cell/URA update failed

Uu Uu

Table 28: Identification of DBC rejections in interface traces For DBC related PM counters see [20] with a summarized version shown below. Note that can be UL interference or DL power.


Counter / KPIRAB.FailEstabCSNoQueuing . RAB.FailEstabPSNoQueuing .

Name / DescriptionNumber of RAB Establishment Failures due to a given cause for CS domain. Number of RAB Establishment Failures due to a given cause for PS domain.

Table 29: PM Counters indicating potential R99 DBC failures 5.4.2.Radio Link Reconfiguration 5.4.2.1. Concept

After DBC has taken place the RLs on the Iub have to be reconfigured using the Radio Link Reconfiguration procedure on NBAP. The flowchart can be seen in Figure 10. The RNC tries to allocate resources on the Iub by sending a RL Reconfiguration Prepare message on NBAP. The NodeB is answering by either sending a Radio Link Reconfiguration Ready (successful case) or Radio Link Reconfiguration Failure (unsuccessful case). The successful case ends in the RNC sending a Radio Link Reconfiguration Commit to the NodeB. This procedure is used to order the Node B to switch to the new configuration for the Radio Link(s) within the Node B. The whole procedure is described in [7]. 5.4.2.2. Failure symptoms, identification and fixes for improvement

For the failure analyses please refer to subsection 5.1.5.2.


Page 40 of 106

Document name:


Date:

2007-06-08

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

ProblemRadio Link Reconfiguration Iub

TraceIub

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

Table 30: Identification of RL reconfiguration failures in traces PM systemUtranCell

Counter / KPI(VS.RLM.AttRLReconfig VS.RLM.FailRLReconfig.sum) / VS.RLM.AttRLReconfig * 100

KPI Name / DescriptionTotal radio link reconfiguration success rate

Table 31: PM KPIs for RL reconfiguration failures 5.4.3. Radio Bearer Establishment 5.4.3.1. Concept

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

Parametert312 n312

DescriptionThe UTRAN parameter is configuring timer T312 The UTR

umts rf troubleshooting guideline

Documents

alternating

periodical

dense urban

counter kpivs

counter kpirrc

dynamic bearer

drive test

app fwd throughput