Document name

:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

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

UMTS Network Performance Engineering

Page 1 of 106

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

Table of Contents
1. 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

UMTS Network Performance Engineering

Page 2 of 106

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

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

UMTS Network Performance Engineering

Page 3 of 106

........................... QoS – general .............................1.......................1 UMTS Network Performance Engineering Page 4 of 106 .......................... TIME SYNCHRONISATION OF MEASUREMENT TRACES ......................................3............... Measurement definition – VT ................................................................................. 96 QoS – data services........................... RRC connection reestablishment............................ Measurement definition – voice ..... MEASUREMENT DEFINITION ...........2........ 7.....4.............................................. 102 A...2. 97 QoS – VT service ..................................................2.......................................................................................................................................................................................... 7. 102 A...............................1 Date: 2007-06-08 7........03 Rev: 2......................................2...................... 105 Change Record This table details the changes done to the document since the last baseline version Date 6 August 2007 th Changes Updated draft after review with following changes • • Editorial throughout the document Added sections like HSUPA......... 101 APPENDIX ................................................ 102 A........ 96 QoS – voice service..............................................2...........................1..............2......................................... 102 A.... InterFreq HO..........3.............................................. 2G->3G IRAT HO Issue# 2.....Document name: UMTS RF Troubleshooting Guideline U04.......................... Measurement definition – data......... 105 B............... 7..........

Glossary of terms and abbreviations 3GPP 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 UMTS Network Performance Engineering Page 5 of 106 .03 Rev: 2.1 Date: 2007-06-08 1.Document name: UMTS RF Troubleshooting Guideline U04.

1 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 UMTS Network Performance Engineering Page 6 of 106 .Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2.

Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2.1 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) UMTS Network Performance Engineering Page 7 of 106 .

03 Rev: 2.1 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 UMTS Network Performance Engineering Page 8 of 106 .Document name: UMTS RF Troubleshooting Guideline U04.

03 Rev: 2. UMTS Network Performance Engineering Page 9 of 106 .1 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].Document name: UMTS RF Troubleshooting Guideline U04.

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.actix.Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2. References [1] TS 23122 NAS Functions related to Mobile Station (MS) in idle mode [2] TS 11. http://www.1 Date: 2007-06-08 2. 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. 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.22 Functions related to Mobile Station in idle mode and group receive mode [5] TS 24008 Mobile radio interface layer 3 specification.com UMTS Network Performance Engineering Page 10 of 106 . 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.

com/RFCoreSupportWebPage/guidelines.com/ UMTS Network Performance Engineering Page 11 of 106 .lucent.asp [40] TS 25323 Packet Data Convergence Protocol (PDCP) Specification [41] Network Performance Engineering LWS Europe http://npe.htm [34] UMTS RF Engineering Guidelines available at http://rfcoresupport.de.31210&_d ad=portal&_schema=PORTAL [44] Parameter consistency checks http://mobility.63.htm [43] NDP homepage http://ge1884ndp01.com/AL/arca/index.ethereal. documentation and download at www.com/~caateam/ [45] Multi-vendor PM database system http://135.03 available at http://ns.net/drtcp.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.cfm [42] Performance Measurements Definitions Manual (PMDM) for U04.wh.ih.org [32] Tardis2000.lucent.lucent.htm [33] UMTS RF Optimization Guidelines available at http://rfcoresupport.com/pub/cygwin [39] DR TCP available at http://www2.129/pm_db/login.com:7779/portal/page?_pageid=35.uk.wh.com/ctip/gsmnav/gsmsysdoc/mnode/webdocs/libfiles/pmd mindex.co.com [31] tcptrace.lucent. documentation and download at www.com/RFCoreSupportWebPage/guidelines.03 Rev: 2.uk/tardis.Document name: UMTS RF Troubleshooting Guideline U04.lucent.lucent.de. www.kansas.lucent.tcptrace.wh.demon.246.php [46] UMTS IRAT Optimization Guidelines http://rfcoresupport.lucent.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.kaska.web.planetmirror.1 Date: 2007-06-08 [30] Ethereal.com/RFCoreSupportWebPage/guidelines.htm [47] TR 26975 Performance characterisation of the AMR speech codec Report [48] ITU-T J.

Chapter “Description of the optimisation process” is providing a short overview of the UMTS optimisation process as covered by the UMTS RF Troubleshooting Guideline. Content There are five main chapters in this document: • • Chapter “About this document” is providing an introduction and an overview of the UMTS RF Troubleshooting Guideline. Chapter “Call quality” is dealing with quality problems as perceived by the UMTS subscriber. About this document 3.03 Rev: 2. For more information see [41]. Introduction The UMTS RF Troubleshooting Guideline is the base document for the UMTS optimisation process and is used for the identification. Iu. • • • UMTS Network Performance Engineering Page 12 of 106 .1 Date: 2007-06-08 3.g. radio link failures or handover problems. 3. PM counters and KPIs of the UTRAN and/or CN and gives references.Document name: UMTS RF Troubleshooting Guideline U04. Chapter “Call reliability” is describing failures and problems that might occur after call establishment. Chapter “Call setup” is listing all problems that might occur at the call establishment phase. classification and resolution of problems. failures or performance degradations that might be observed during the optimisation activity. 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.2.1. examples are dropped calls. This document covers the following items: • • • • Drive test data analysis (Uu traces and 2G/3G scanner measurements) Network interface tracing analysis (e. 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.

However it is geared towards supporting multi-vendor equipment so long as they follow 3GPP mandated procedures. 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. In the second part called “failure symptoms. UTRAN/CN release and vendor dependency This document is a “living” document and is updated on a regular basis based on the experience coming from the different projects.03 Rev: 2. this part has the subtitle “concept”. 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.3. For more details check the corresponding reference documentation. How to read The main analysis chapters are subdivided into subsections that are describing the particular problems and failures step by step. Uu trace. but might be added in later releases. Intended audience This document is directed to system engineers. 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. network planners.what is not covered This document is not covering Element Management Layer activities. RF optimisation engineers and all engineers that are going to analyse network with the aim of optimising a UMTS network. As a consequence this Guideline cannot be used for troubleshooting maintenance task issues. these topics are covered in more details in [33] and [34].1 Date: 2007-06-08 3. UMTS Network Performance Engineering Page 13 of 106 . 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. The question of the root cause and how to overcome this problem is not part of the UMTS RF Troubleshooting Guideline.6. 3. the problem and when applicable corresponding UTRAN parameter are described and listed. Disclaimer . 3. This guideline is only shortly covering RF network planning and dimensioning issues.Document name: UMTS RF Troubleshooting Guideline U04. Currently the Fault Management (FM) analysis is also not covered in this guideline.g. This version of the UMTS RF Troubleshooting Guideline is supporting exLucent equipment only.4. Basis for the structure is the UMTS call handling. The subsections are structured as follows: • In the first part. This document does not support how to trace and to operate measurements instruments and tools.5.

1 Date: 2007-06-08 4.Document name: UMTS RF Troubleshooting Guideline U04. Figure 1: Ex-Lucent UMTS optimisation process – process flow UMTS Network Performance Engineering Page 14 of 106 . Description of the optimisation process The different fields of UMTS RF optimisation can be summarised by the following items: • • • • • • • FM audit and analysis RF design audit and and [34] for a detailed description) CM audit and optimisation PM audit and optimisation Drive testing and investigation Network interface tracing and analysis Lab investigation and optimisation optimisation (see [33] These fields of UMTS optimisation are displayed in Figure 1 in yellow below.03 Rev: 2.

UMTS Network Performance Engineering Page 15 of 106 . the Drive test and interfaces’ traces would be more relevant than PMs that may get skewed because of small number of users.03 Rev: 2. one or both pre-requisites are not fulfilled starting with the performance investigation and troubleshooting does not make much sense.1 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.Document name: UMTS RF Troubleshooting Guideline U04. For troubleshooting and optimizing new clusters.

6).1.03 Rev: 2.1.1. 5. Call setup One main user perception of a UMTS network is the success of setting-up a UMTS call. 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. In the following it is assumed that the UE is in idle mode. UMTS Network Performance Engineering Page 16 of 106 .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.1.1 Date: 2007-06-08 5. The different phases during the call setup are covered step-by-step in the following subsections of this chapter. This section is describing all kind of failures and problems that might occur during the call establishment phase.Document name: UMTS RF Troubleshooting Guideline U04. • • • Concept PLMN selection and reselection Cell selection and reselection Location registration 5.1.1. Call setup – RRC connection establishment 5.3) and FACH (subsection 5.

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. The UE is either selecting the best suitable cell (in terms of the cell selection criteria.1 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]. This is received signal. Not applicable for TDD cells or GSM cells. The quality of the received signal expressed in CPICH Ec/N0 (dB) for FDD cells. 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. Not applicable for TDD cells or GSM cells.) to setup a call. Prerequisite for the cell selection (and also cell reselection) are that the following criteria are fulfilled: For UMTS: Squal = Qqualmeas . 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.Qqualmin > 0 AND Srxlev = Qrxlevmeas – Qrxlevmin . 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.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. traffic distribution assumptions etc.) the mobile enters the “Limited Service” state.03 Rev: 2. In this state the UE is only allowed to initiate emergency calls in case it detects any PLMN coverage. In case there is no suitable cell of a non-forbidden network (no roaming agreement.Document name: UMTS RF Troubleshooting Guideline U04. Qrxlevmeas is cell RX level value. 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. SIM locked in the HLR etc. camping on the best suitable cell and starts with the location registration procedure. The different O&M parameters of the formula above are listed in Table 1 below: Parameter Qqualmin Qrxlevmin Description Minimum required quality level in the cell (dB). 0) (GSM) – P_MAX. 0) (UMTS). broadcasted via SIB3 and SIB4 Minimum required RX level in the cell (dBm). CPICH RSCP for FDD cells (dBm). broadcasted via SIB3 and SIB4 Table 1: Parameters used for cell selection UMTS Network Performance Engineering Page 17 of 106 . Optimisation approach is to ensure that the UE camps on the best suitable cell (in terms of RF conditions. lack of 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).

SSearchRAT is a configurable UMTS parameter broadcasted on SIB3/SIB4. For UMTS network without HCS the following formulas are used (both for GSM and UMTS cells): Rs = Qmeas. 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. otherwise not. an undesirable condition.n . Qoffsets. For cell reselection the target cell has to fulfill the same criteria as specified for the cell selection case.s + Qhysts Rn = Qmeas.1 Date: 2007-06-08 Remark The current formulas can only be used in case HCS is not deployed. Qhysts is an hysteresis to avoid ping-pong effects. However note that to avoid ping ponging between UMTS and GSM the following condition should be fulfilled: FDD_Qmin > Qqualmin + SsearchRAT If the above condition is not satisfied.n is an offset defined on a per-neighbour definition (for both GSM and UMTS neighbours). The UE ranks the cells according to the cell ranking criteria Rs (serving cell) and Rn (neighbour cell). for this parameter Sintersearch is used and is broadcasted on SIB3/SIB4. 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.03 Rev: 2.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. The reselection process using the mentioned parameters (Qoffsets.n = 0) is visualised in Figure 3 below: Figure 3: Cell reselection process UMTS Network Performance Engineering Page 18 of 106 .Qoffsets. a UE will move from GSM to UMTS and immediately start monitoring neighboring GSM cells again. Furthermore while camping the UE shall start to perform inter-RAT measurements if Squal <= SSearchRAT. 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.Document name: UMTS RF Troubleshooting Guideline U04. In a similar way the criterion for UMTS Interfrequency measurements is defined.

1. sIB3Qhyst2 outFDDAdjCells.sSearchRAT sIB3SInterSearch sIB3Qhyst1. In that case the drive test route should be checked. For these kinds of failures see subsection 5.1.2) or during the call setup procedure (subsection 5. The cell selection and reselection process and its translations are covered in more details in [18].1. Common problems of the cell selection/reselection procedure are non-optimised configuration of the corresponding UTRAN parameter. Another problem might be ACB on one or several of the surrounding GSM and/or UMTS cells.Document name: UMTS RF Troubleshooting Guideline U04.5 and 6.cellOffset Description Parameter 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. A consistency check of the parameters listed in Table 1 and Table 2 might help to find parameter misconfiguration. the paging procedure (subsection 5. 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 UMTS Network Performance Engineering Page 19 of 106 .03 Rev: 2.2). As a consequence the call will be setup on a non-optimal cell or a non-optimal RAN so the call-setup might fail during the RACH procedure (subsection 5. Parameter Qoffsets. ACB is used during the integration of cells see [35] for details.3).8) or when the test van is driven out of the coverage footprint of the (GSM and UMTS) network. Information regarding Access Class Barring is broadcasted via SIB3 or SIB4 [6]. 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.1.1 Date: 2007-06-08 Table 2 below is listing the main parameters configuring the cell reselection process in case no HCS is used: Parameter cellSelAndResQualMeas sIB3Treselection sIB3RAT. Failure symptoms.3.4.1. 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. RNC or any particular network interface like Iub or Iu (see also subsection 6. The root cause might be a network outage due to NodeB. 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.2. 5.n used for optimisation of a per-cell basis should be reviewed. 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.

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. In addition the RNC might trigger the repetition of the UE paging in the UTRAN. UMTS Network Performance Engineering Page 20 of 106 . This is in particular the case for subscribers inside a building where the UMTS coverage is not as strong compared to the GSM coverage. 5. In case the UE is in connected mode and is paged.1.1. but the preference is on the UMTS network.Document name: UMTS RF Troubleshooting Guideline U04. In the following it is assumed that the UE is not in connected mode so it has received a Paging Type 1. Another problem arises when different LA codes are defined for the GSM and UMTS networks and the Inter-RAT reselection criterion is met. Table 3 below is listing the identification techniques of PLMN/cell (re-)selection failures in drive test traces and scanner measurements: Problem Wrong PLMN selected ACB Call setup on nonoptimal cell Call setup on nonoptimal RAN technology Ping-pong LU between 2G / 3G Trace Uu Uu Uu. URA_PCH or CELL_PCH modes and the UE is receiving a Paging Indication on the PICH from the NodeB.2. then the UE is starting to monitor the PCH to receive the paging (“Paging Type 1”). 3G scanner Uu.1 Date: 2007-06-08 measurements. 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.3. 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. Failures during the Location Registration procedure are identified via CN PMs and covered in subsection 5. Failures on the AICH.1.03 Rev: 2.1. PICH and PCH 5. 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. The repetition timers of the RNC and CN have to be set accordantly. The CN might perform a repetition of paging process in case the UE has not answered within a certain period in time. 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. Also the cell offsets for the GSM cells can be adapted to prefer call setup on the 2G layer.2. then the UTRAN is sending the paging via DCCH (“Paging Type 2”). 2G/3G scanner Trigger Any 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.

6). RACH failures are covered in subsection 5. identification and fixes for improvement Non-optimal power settings of the PICH. the RRC connection is maintained via the common physical channels (subsection 6.4.2. A better approach for analysing call setup problems due to paging failures is to use PM counters of the UTRAN and the CN.1. Congestion on the PCH Failures on the PCH. The drive test equipment can record paging requests. Upon successful decoding the NodeB forwards the RACH Message Part to the RNC. camping on a non-optimal cell (see subsection 5. pilot pollution (subsection 6. AICH and PCH The paging itself is sent on the PCH that is a PHY channel on Uu.1.4. • • Failure symptoms. 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.1) etc.g. PICH and AICH are most likely due to • Table 4 below is listing the main UTRAN parameters configuring the PICH. 1 CN_PCH_Timer & CN_PCH_Max are dummy names for the parameters Page 21 of 106 UMTS Network Performance Engineering .1. poor RF coverage (subsection 6. 5.3.Document name: UMTS RF Troubleshooting Guideline U04. 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).5).1 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. FACH failures are covered in subsection 5.1).03 Rev: 2. When the NodeB receives the RACH Preamble it answers by sending an indication on the AICH.2. When the UE cannot be reached via paging the UTRAN may decide to drop the RRC connection. AICH or PCH Poor radio conditions in terms of low RSCP or Ec/No because of e.6. If the UE is in URA_PCH or CELL_PCH mode.1. The RNC sends back (on the FACH) the RRC Connection Setup/Cell Update Confirm/URA Update Confirm message (successful case). PCH and AICH: Parameter pICHPower pCHPower aICHPower CN_PCH_Timer tPageRep CN_PCH_Max nUtranPageRep 1 Description UTRAN 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.

1 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.03 Rev: 2. A solution of lowering the paging load might be to separate the FACH and PCH on the SCCPCH by introducing an additional SCCPCH. Failures on the AICH or PICH (PHY channels. In addition “normal” RF optimisation for areas with low Ec/No will improve the situation. 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 UMTS Network Performance Engineering Page 22 of 106 .Document name: UMTS RF Troubleshooting Guideline U04. Table 5 below is listing of how failures on the PICH/AICH/PCH can be identified in interface traces: Problem RRC drop due to unsuccessful paging Trace Iub and Iu Trigger Cross correlation Iu and Iub trace: any occurrence where a UE page is recorded on Iub. Increasing the power settings of the particular Physical Channels will reduce the failure rate. 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. In addition creating smaller Location Areas / Routing Areas will also lower the paging load.

The RACH is transmitted on the PHY in two separated parts: first a certain number of RACH Preambles are sent. The measurement provides the number of successful page responses from MS. URA Update) message in the RACH Message Part.succFirstPageReqs 3G-MSC RNC VS.PagAttDiscard.Document name: UMTS RF Troubleshooting Guideline U04. Random Access Procedure 5. Figure 5 below illustrates the transmission of several RACH Preambles in different Ramping Cycles and only after the reception of an ACK on AICH. Paging success rate defines the rate of successful paging in the packet network. The attempt and success counts are used to monitor the paging performance.RRCConnDrop.SuccPsPagingProcIu + SuccPsPagingRepititionsIu) / (MM. setting up a call.03 Rev: 2.AttPsPagingProcIu + AttPsPagingRepititionsIu)*100 VS. Each of the following RACH Preambles are transmitted with an increased power level till an ACK is received on the AICH.1.1 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. the transmission of the RACH message part: UMTS Network Performance Engineering Page 23 of 106 . Concept The RACH Access Procedure is used when attaching to the network. Then the UE transmits the RRC Connection Request (Cell Update. 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. PM system RNC UtranCell Counter / KPI VS. The power of the first RACH Preamble is relatively low and calculated using Open Loop Power Control.PagAttRec (MM. This is the case when received preamble power exceeds the parameter “physicalRACHPreambleThreshold”.MM.3. Provides the channel occupancy rate for the PCH channel RNC 3G-SGSN VS.1.1.MM.ChannelOccupRatePCH Table 6: PM KPIs/Counters for PICH/PCH/AICH failures 5.3.MM.UTRANPagingFailure VS.ProcessorLoad KPI Name / Description Counting 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”.

AttConnEstab.MM. OrigConvCall. OrigStrmCall etc.1 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. If V300 <= N300 (configured by UTRAN parameter n300). the UE increments V300 by one.g. the UE stops sending on the RACH and stays in idle mode [6]. it resets its internal counter V300 to 1 and starting its internal guard timer T300 (to UTRAN parameter t300).<per establishment cause>. If V300 > N300.03 Rev: 2. the corresponding PM counters are named VS. Figure 6 below is showing as an example the Cell Update procedure: Figure 6: Cell Update procedure supervised by T302 and V302 2 “<per establishment cause>” is a placeholder for e. For the Cell Update and URA Update procedure V302 and T302 are used. if the UE has already sent one or several RRC Connection Request messages before.Document name: UMTS RF Troubleshooting Guideline U04. PM counter RRC.<per 2 establishment cause> is incremented by one . Upon reception of the RRC Connection Request message at the RNC. A full list is available in [42]. UMTS Network Performance Engineering Page 24 of 106 .CellUpdateReq. resets T300 and sends the RACH Preamble again. counter V300 is incremented by one and guard timer T300 is restarted. Upon expiry of timer T300 the UE may start again by sending RACH Preambles depending on the status of counter V300.

1).1.1) etc. In the following only the RACH specific issues are covered.3. 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].4.1.03 Rev: 2. The ratio between received preamble power during the preamble period and interference level shall be above this threshold in order to be acknowledged. pilot pollution (subsection 6. camping on a non-optimal cell (see subsection 5. SIB4MAXAllowedULTXPower mMax t300 Description Used 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.2.4.1 Date: 2007-06-08 Failures in the RACH procedure occur if either the RACH Preamble or the RACH Message Part cannot be decoded. 5. but not by “normal” drive test tools. for the other (common) RF issues see the corresponding subsections. In most cases only a statistic about the PHY UMTS Network Performance Engineering Page 25 of 106 . identification and fixes for improvement The RACH Preambles may only be recorded in internal UE or NodeB traces. poor RF coverage (subsection 6.Document name: UMTS RF Troubleshooting Guideline U04.g. Failure symptoms.5). Table 7 below is listing the main UTRAN parameters configuring the RACH: Parameter constantVal PowerRampStep maxRetranPreamble physicalRACHPreambleThres hold SIB3MAXAllowedULTXPower. 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.

number of 3 RACH Preambles sent. The CAC thresholds can be defined for uplink and downlink load separately. last transmitted power etc . 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). This measurement provides the channel occupancy rates for Radio Access Channel.1. 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.g. The RACH performance can be improved by changing of the power settings and/or changing of the timer/counter as listed in Table 7. Iub Trigger Cross-correlation Uu/Iub trace: RACH Message Part (RRC Connection Request.RACHTransBlock.Document name: UMTS RF Troubleshooting Guideline U04. 5. Problem RACH message lost Trace Uu.RACHTransBlock. but the RACH message part is never transmitted via the air interface in case the RACH preamble has already failed.1. Cell Update or URA Update) is recorded on the Uu. Table 9 below is listing the identification possibilities using KPIs retrieved by the UTRAN PM system. Table 8: Identification of RACH failures in traces PM system UtranCell UtranCell Counter / KPI VS. but not recorded on the Iub interface.Good) * 100 VS.1 Date: 2007-06-08 and MAC procedure of the RACH is listed in the drive test logs e.Good / (VS.Bad + VS. Table 8 below is listing the identification possibilities for network interface traces. The CAC algorithms and the corresponding parameter are described in detail in [20]. Possible congestion on the RACH could be detected by supervision of PM UTRAN counters (Table 9 below).4.4.RACHTransBlock.03 Rev: 2. KPI “RACH transport block good CRC rate” is the percentage of RACH Transport Blocks with good CRC. The higher layer (RRC) initiates the transmission of the RACH message.RACHcongestion VS. UMTS Network Performance Engineering Page 26 of 106 . UtranCell Table 9: PM KPIs for RACH failures More RACH related PM KPIs are available in [19].ChannelOccupRateRACH KPI Name / Description This measurement provides the percentage of time that the RACH is in congested state. Call Admission Control (CAC) 5.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.

1 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. neighbour list optimisation etc. Failure symptoms.1.4. 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: UMTS Network Performance Engineering Page 27 of 106 . The only optimisation approach in case of CAC rejections is to optimise the RF environment in terms of pilot pollution. Specifies the load threshold for DL call admission of a non-emergency RRC connection request when HSDPA is enabled. 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. Specifies the load threshold for DL call admission of a non-emergency RRC connection request when HSDPA is disabled. Table 10 below is listing the main parameters configuring CAC: Parameter thrCAC2UL thrCAC2DL thrCAC2DLHS DPA Description Specifies the load threshold for UL call admission of a non-emergency RRC connection request.03 Rev: 2. Problem RRC Connection Reject Trace Uu or Iub Trigger After the UE sends a RRC Connection Request message the RNC replies with RRC Connection Reject message with cause “Congestion” . In addition it should be verified that the CAC thresholds are set correctly. Table 10: Parameter configuring CAC 5.1.5) or also for other failures.Document name: UMTS RF Troubleshooting Guideline U04. identification and fixes for improvement CAC failures can only be identified in a reliable manner via PM counters or internal traces.2.

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. Problems on ALCAP could be due to ATM configuration and are outside the scope of this document. Table 12: PM Counter for CAC failures 5. 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).5.5. Failure symptoms.5.CAC Name / Description This measurement provides the number of failed RRC connection establishment with cause “Call Admission Control” (CAC).03 Rev: 2.FailConnEstab. UMTS Network Performance Engineering Page 28 of 106 .1 Date: 2007-06-08 PM system UtranCell Counter / KPI RRC. Radio Link Setup 5. 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.2. ATM synchronisation problems are not expected at this stage of the call because of the already successful NBAP procedure.1.Document name: UMTS RF Troubleshooting Guideline U04. identification and fixes for improvement The NBAP Radio Link Setup procedure may fail and the NodeB sends back the Radio Link Setup Failure message.1.

AttRLSetupIur * 100 Table 14: PM KPIs for Radio Link Setup failures 5.TransRes.NodeBRes.FailRLSetupIub.CSD + RLM.AttConnEstab.PSD) / RLM.CSV + RLM.1.CSD + RLM. while transport resources issue can point to the backhaul bandwidth limitation. Problem Radio Link Setup I Trace Uu.7.NodeBRes.Call setup failures on the FACH 5. for failures in CELL_FACH mode see subsection 6.FailRLSetupIub.AttRLSetupIub*100 (RLM.FailRLSetupIub.sum*100 KPI Name / Description Failed 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.AttRLSetupIub*100 (RLM.4.1.AttRLSetupIub*100 (RLM. For identification of failures during the Radio Link Setup procedure Iub traces are mandatory. Table 14 is listing the identification possibilities using KPIs retrieved by the UTRAN PM system.03 Rev: 2.TransRes.AttRLSetupIur – RLM.NodeBRes. Table 13 below is listing the identification possibilities for network interface traces.TransRes.RLSetupFailure/RRC. “NodeB Resources unavailable” or ”Semantic error” etc.PSD) / RLM. Iub Trigger Cross-correlation Uu/Iub trace: Any occurrence of the NBAP Radio Link Setup Failure message on Iub and RRC Connection Reject with cause “unspecified” or “congestion” on Iub/Uu 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 system UtranCell Counter / KPI RRC. UMTS Network Performance Engineering Page 29 of 106 .FailRLSetupIub.FailRLSetupIur.FailConnEstab.FailRLSetupIub.SuccRLSetupIub / RLM.6. Concept This subsection is covering only call setup related failures on FACH. Reason is that on Uu only the RRC Connection Reject message is available with only two possible failure causes (“congestion” and “unspecified”).FailRLSetupIub. Here one major reason for NodeB resources problem can be UCU capacity shortage.1 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”.1.Document name: UMTS RF Troubleshooting Guideline U04.1.6.sum) / RLM. 3GPP has defined a variety of failure causes.CSV + RLM. see also subsection 5.

… ) before T30001 expires.1 Date: 2007-06-08 It is assumed that the RACH Message Part has been successfully received. Radio Bearer Reconfiguration Complete. The whole procedure is visualised in Figure 9 below: Figure 9: Failures on FACH UMTS Network Performance Engineering Page 30 of 106 . resets counter V30001 and starts its guard timer T30001. If V30001 > N30001. If V30001<= N30001 (maximum number of retries). In this case the RNC sends back either the RRC Connection Setup. UTRAN Mobility Information Confirm. the RNC stops T30001. When the RNC receives the answer by the UE (RRC Connection Setup Complete. Cell Update Confirm or URA Update Confirm message on FACH (successful case). If the RNC does not receive the message before T30001 expires.03 Rev: 2. the CAC has been granted and the RL are established. Note that the RNC will not send any failure message on the Uu. resets timer T30001 and sends the FACH message again. The RNC sends the FACH message.Document name: UMTS RF Troubleshooting Guideline U04. the RNC will stop sending FACHs to the UE and will release the reserved resources on NBAP and ALCAP. the RNC may resend the FACH message depending on the status of counter V30001. the RNC increments V30001 by one.

6. UMTS Network Performance Engineering Page 31 of 106 .sum*100 VS.FailConnEstab.AttConnEstab. Iub and Uu traces.Document name: UMTS RF Troubleshooting Guideline U04.1. 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 PM system UtranCell UtranCell Counter / KPI RRC. see also subsection 5.PercentageFACHOccupancy KPI Name / Description Failed RRC connection Establishment Rate timeout Occupancy rate on FACH Table 17: PM KPIs for failures on the FACH 5. Table 16 below is listing the identification of FACH failures on Iub.1. FACH signalling and traffic power) Call setup not done on an optimal cell (subsection 5.1) The FACH message is not successfully decoded due to poor FACH coverage The message on the FACH is successfully decoded by the UE. Table 17 the corresponding PM KPIs: Problem Lost FACH message FACH Failure Trace Iub and Uu Uu or Iub Trigger Cross-correlation Uu/Iub trace: one or more FACH messages are recorded on the Iub.1 Date: 2007-06-08 Table 15 below is listing the parameters configuring the FACH: Parameter fACHTrafPower fACHSigPower uERRCConnectionSetupRes ponseTimer maxRRCConnSetupRetries Description UTRAN 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.SetupIncomplete / RRC. • • • • Failure symptoms. identification and fixes for improvement Non optimal UTRAN parameter settings (e. 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”. but afterwards the RNC cannot successfully decode the answer sent by the UE (UE is already in CELL_DCH mode.2) There are the following possible reasons for failures on FACH: Failures on the FACH can be indicated by UTRAN PM statistics.2.g.03 Rev: 2.7. On Uu FACH failures cannot be directly observed because there is no corresponding failure message sent.

5.2. protocol errors or problems when sending the FACH etc. 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. 5.FailConnEstab. instead other PM counters with the name RRC.2. 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.maxNoReport edCellsOnRACH addThresholdSHO Description Defines 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].1. identification and fixes for improvement The RRC connection might drop in this early stage due to the following reasons: UMTS Network Performance Engineering Page 32 of 106 .Failure symptoms. there is a big likelihood that the call setup will fail.<different rejection causes> are used. Table 18 below is listing how to identify this kind of error in Uu logs: Problem RRC Connection Reject with cause unspecified Trace Uu Trigger Any occurrence of an RRC Connection Reject message with specified cause “unspecified”. 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. 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.2.1 Date: 2007-06-08 Possible reasons for that failure message are problems in the Radio Link Setup procedure. Cell Update Confirm or URA Update Confirm message 5.2. Table 18: RRC Connection Reject – unspecified There are no specific PM counters for that case. Concept Table 19 below is listing the parameters that are important for the call setup phase: Parameter measQty. Call setup – failures during the call setup phase At this point in time the UE is in the transition phase to either CELL_FACH or CELL_DCH mode.03 Rev: 2. 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).Document name: UMTS RF Troubleshooting Guideline U04.

1) etc. 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. these protocols are specified in [5] and [8]. pilot pollution (subsection 6. perform a Location or Routing Area Update or initiate a data. 3G scanner Uu. poor RF coverage (subsection 6. The following subsections are summarising possible failures that might occur during these procedures. camping on a non-optimal cell resulting in non-optimal reselection list (see subsection 5.4.1.03 Rev: 2. but the root cause for the failure is one of the issues mentioned above.1). The number of cells in the Active Set is smaller than max AS size. the assigned SC is under the best x SCs measured by the 3G scanner.1 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. voice or VT call. CM failures causes like “CM UMTS Network Performance Engineering Page 33 of 106 .4.Document name: UMTS RF Troubleshooting Guideline U04. 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).g. 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). 3G scanner Uu Uu. Nevertheless it is possible to identify issues in network interface traces as listed in Table 20 below: Problem Call 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 Trace Uu. Also the drop might occur only a very short time later. 3G scanner Trigger The call is setup via RRCConnectionSetup message on a cell and at the same time the 3G scanner is reporting at least x cells that are within a y dB window compared to the best measured cell.5). 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. and these SCs are within y dB window as measured by the 3G scanner Table 20: Identification of call setup in traces 5. Call setup – Core Network failures After establishment of the RRC connection the UE and the CN exchange Direct Transfer messages so the UE can GPRS attach to the PS network.3.

wrong or incorrect IE format etc. data or VT services.1.3. IMSI unknown in the HLR. such as informing the network of its present location and providing user identity confidentiality. 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. CN problems like authentication not possible due to inaccessible HLR database etc. A mobility management context in the SGSN or 3GMSC is a prerequisite for the initialisation of voice. Concept The main function of the mobility management is to support the mobility of user terminals.03 Rev: 2.3. The specified rejection cause will indicate the reason for the failure e.1.g.g.2. Table 21 below is listing the Mobility Management failures as they can be retrieved by interface traces: Problem MM Authentication Reject CM Service Reject CM Service Abort Trace Uu or Iub or Iu Uu or Iub or Iu Uu or Iub or Iu Trigger Any occurrence of a MM Authentication reject message sent by the CN e. protocol error. CC.Document name: UMTS RF Troubleshooting Guideline U04. 3G-MSC. Any occurrence of a GMM Attach Reject message sent by the CN The specified rejection cause will indicate the reason for the failure e.2. The rejection cause will give an indication about the occurred failure. Any of the failures can be easily detected by the corresponding failure messages. The settings of these timers are specified and not configurable. Any occurrence of a MM Abort message sent by the CN. Failure symptoms. In addition Mobility Management failures might be due to missing roaming agreement. 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. … basis. RLC resets etc. because of not-allowed national/international roaming Any occurrence of a CM Service reject message sent by the CN. Any occurrence of a MM Location updating reject message sent by the CN. Because the protocols are transparent to the UTRAN all PM KPIs are defined within the CN entities e. roaming not allowed 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.g. Any occurrence of a CM Service abort message sent by the UE.2 (MM/CM) and 9. 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. UMTS Network Performance Engineering Page 34 of 106 . the reject cause will give an indication of the occurred failure. Note that (almost) any failure in this subsection is not UTRAN related because 4 Direct Transfer messages are transparent to the UTRAN . Mobility Management failures 5. 5.1. The failure messages are retrieved from [5] chapter 9.g. MM or SM) to react accordantly of the discarded message.1 Date: 2007-06-08 Service Reject Cause” is mapped on the Reject Cause of the Mobility Management IE [5].1. locked SIM card. GMM.g.3. 5. illegal MS/ME. SGSN / GGSN.4 (GMM). It is up to the corresponding higher layer (e.

AttGprsDetachSgsn.1 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.2. Any occurrence of a GMM Authentication and Ciphering Reject message sent by the CN. Call Control failures 5.1). a sync failure. The CC protocol is responsible for CS call establishment and clearing procedures. protocol error. The counter is incremented for a mobile termination attempt that is rejected by the MSC for reasons other than system resource overload related.1.mobileOrigAttRejected KPI Name / Description GPRS 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.3.3.SuccGprsAttach.g.U * 100 MM.U * 100 (attAuthInSgsn – succAuthInSgsn) / attAuthInSgsn * 100 (MM.U * 100 VS.mobileTermAttRejected Table 22: PM KPIs/Counters for (GPRS) Mobility Management failures 5.SuccGprsDetachSgsn.U – MM.SuccIntraSgsnRaUpdate. Any occurrence of a GMM Routing area update reject message sent by the CN.SuccInterSgsnRaUpdate.Document name: UMTS RF Troubleshooting Guideline U04.AttGprsAttach. Concept This subsection describes failures on the Call Control (CC) protocol.U) / MM.U * 100 (attInterVLRLocationUpdates + attIntraVLRLocationUpdates) / (succInterVLRLocationUpdates + succIntraVLRLocationUpdates) * 100 MM.U / MM.U / MM.g.AttInterSgsnRaUpdate.U) / MM. UMTS Network Performance Engineering Page 35 of 106 . call information phase procedures etc.03 Rev: 2.AttGprsDetachSgsn. 3G-MSC VS.AttIntraSgsnRaUpdate.2.3.U – MM. wrong or incorrect IE format etc. The specified rejection cause will indicate the reason for the failure e. The specified rejection cause will indicate the reason for the failure e.AttGprsAttach. 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 system SGSN SGSN SGSN Counter / KPI (MM. CC procedures can only be performed if a MM context has been established between the UE and the CN (subsection 5.

For the root cause analysis please check the timer settings supervising the CC protocol in [5] chapter 11. note that the specified cause might depend on the 3G-MSC/UE vendors: Problem Ubnormal Disconnect Ubnormal Release CC CC Trace Uu or Iub or Iu Uu or Iub or Iu Trigger Any 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 / KPI5 NoCCDisconnectUbnormalEvent / NoCCDisconnects * 100 NoCCReleaseUbnormalEvent / NoCCReleases * 100 PM system 3G-MSC 3G-MSC KPI Name / Description Ubnormal 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. Any occurrence of a SM Activate Secondary PDP Context Reject message sent by the CN.1 Date: 2007-06-08 5. The settings of these timers are not configurable. 5.g.3. The specified rejection cause is giving an indication of the type of failure e.Document name: UMTS RF Troubleshooting Guideline U04.3. Table 25 below is listing the SM failures as they can be retrieved by interface traces: Problem SM Activate PDP Context Reject Trace Uu or Iub or Iu Trigger Any occurrence of a SM Activate PDP Context Reject message sent by the CN. identification and fixes for improvement Table 23 below is listing the CC failures as they can be retrieved by interface traces [5].3.g.g. identification and fixes for improvement The failure messages are retrieved from [5]. drive test configuration issue (e.2. protocol error. Failure symptoms.03 Rev: 2. 5.3.3.1).2.3. deactivation and modification. lack of resources etc. “User busy”) or protocol failure.3. The SM comprises procedures for identified PDP context activation.1.2.3. “requested circuit/channel not available”). SM Activate Secondary PDP Context Reject Uu or Iub or Iu 5 Dummy names Page 36 of 106 UMTS Network Performance Engineering .3. missing or faulty APN. Failure symptoms.Session Management failures 5. SM procedures for identified access can only be performed if a GMM context has been established between the UE and the CN (subsection 5. Concept The main function of SM is to support the PDP context handling of the PS services. The specified rejection cause is giving an indication of the type of failure e.

feature not supported.2.Document name: UMTS RF Troubleshooting Guideline U04. 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 system SGSN Counter / KPI (1-((SM.1 Date: 2007-06-08 protocol error. For the root cause analysis please review also the timer settings supervising the SM protocol in [5] chapter 11. lack of resources etc.AttModPdpContextSgsn. 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.Cause) / (SM. The specified rejection cause is giving an indication of the type of failure e.U * 100 KPI Name / Description Session 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. protocol error.g. protocol error.3.Cause+SM. The settings of these timers are specified and not configurable.SuccActPdpCtxMs)) )*100 SM.03 Rev: 2. service option not supported. missing or faulty APN.g. Call setup – RAB establishment The RAB establishment is started at higher layer signalling after the RRC Connection establishment and CM procedures are successful.FailActPdpCtxMs. The specified rejection cause is giving an indication of the type of failure e.FailActPdpCtxMs.U / SM. This is also a typical configuration issue of the drive test equipment. Any occurrence of a SM Modify PDP Context Reject message sent by the CN. lack of resources etc.SuccModPdpContextSgsn. lack of resources etc. 5. Figure 10 below is showing the flow chart for a PS data call: UMTS Network Performance Engineering Page 37 of 106 .4.

1. Dynamic bearer control (DBC) 5.Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2. Page 38 of 106 UMTS Network Performance Engineering . 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.1. 5. 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.1.1 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.4. Table 27 below is listing how to identify failures of the RAB establishment procedure in network interface traces: Problem RAB establishment failure Trace Iu Trigger Any occurrence of an RAB Assignment Response with specified failure cause according to 3GPP6 Table 27: Identification of RAB establishment failures in traces In the following subsections possible root causes for an unsuccessful RAB establishment are discussed in detail. The failure and failure causes of the RAB Establishment are specified in [9]. 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.4.

03 Rev: 2. 5.1. 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 . 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 . improving RF coverage.4. DBC uses a QoS parameter in order to prioritise different user when downgrading. see also [20] for details.6) after the RNC is receiving the corresponding RACH messages In case service based data rate increase is triggered (see also subsection 7.1 Date: 2007-06-08 • During the transition of CELL_PCH/URA_PCH to CELL_DCH mode (see also subsection 6. but the RRC State Indicator is set to CELL_PCH/URA_PCH. 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.2. In case DBC grants the requested service the call handling proceeds as specified (depending on the phase of the call).2. neighbour list optimisation etc. Failure symptoms. 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.Document name: UMTS RF Troubleshooting Guideline U04. The optimisation approach in the later case is to optimise the RF environment in terms of reducing pilot pollution.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. 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.

4. Uu Trigger Any 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. The flowchart can be seen in Figure 10.2. Failure symptoms. The whole procedure is described in [7].<Cause> RAB.1.Radio Link Reconfiguration 5. Table 29: PM Counters indicating potential R99 DBC failures 5.2. This procedure is used to order the Node B to switch to the new configuration for the Radio Link(s) within the Node B.2. 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. identification and fixes for improvement For the failure analyses please refer to subsection 5.<Cause> Name / Description Number of RAB Establishment Failures due to a given cause for CS domain. UMTS Network Performance Engineering Page 40 of 106 . 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 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). 5.4.4.1 Date: 2007-06-08 Problem DBC 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 Trace Iu Iu.FailEstabPSNoQueuing . PM system UtranCell UtranCell Counter / KPI RAB. The successful case ends in the RNC sending a Radio Link Reconfiguration Commit to the NodeB.Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2.5. Iu or Iub.FailEstabCSNoQueuing .1. Number of RAB Establishment Failures due to a given cause for PS domain. Note that <Cause> can be UL interference or DL power. Concept After DBC has taken place the RLs on the Iub have to be reconfigured using the Radio Link Reconfiguration procedure on NBAP. 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.2.2.

in that case the UE sends back a Radio Bearer Setup Failure message to the RNC. T312 expiry) Unsupported or invalid configuration in the UE Code starvation (the required channelisation code is not available anymore from the code tree) Protocol Error UMTS Network Performance Engineering Page 41 of 106 . 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.RLM. Problem Radio Link Reconfiguration Iub Trace Iub Trigger Any 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 system UtranCell Counter / KPI (VS.RLM. The Radio Bearer Establishment procedure may fail for different reasons (see below). the UE shall start a timer T312 and wait for N312 successive “in sync” indications. Failure symptoms.e. Radio Bearer Establishment 5. Table 31 the corresponding UTRAN KPIs.4.sum) / VS. When a physical dedicated channel establishment is initiated by the UE.1.03 Rev: 2.FailRLReconfig.RLM.4.AttRLReconfig * 100 KPI Name / Description Total radio link reconfiguration success rate Table 31: PM KPIs for RL reconfiguration failures 5.AttRLReconfig – VS.3.3. identification and fixes for improvement In case the UE sends back the Radio Bearer Setup Failure message to the RNC and the Radio Bearer Establishment procedure fails.2. Main reason for the failure can be subdivided as follows: • • • • Physical Channel Failure (i. On receiving N312 successive “in sync” indications. If the timer T312 expires before the physical channel is established. the UE shall consider this as a “physical channel establishment failure”.Document name: UMTS RF Troubleshooting Guideline U04.1 Date: 2007-06-08 Table 30 below is listing the identification triggers for network interface traces.4. The whole procedure is explained in [6]. the physical channel is considered established and the timer T312 is stopped and reset.3. Table 32 below is listing the parameters for the RB Establishment: Parameter t312 n312 Description The UTRAN parameter is configuring timer T312 The UTRAN parameter is configuring N312 Table 32: Parameter important for the RB Establishment 5.

the physical channel failure occurs when there is loss of synchronisation between UE and NodeB. which cause out of this list is chosen for the particular failure that has occurred. Table 33 is listing the identification techniques in traces.1 and 6.03 Rev: 2. This is mainly caused by poor RF conditions. see also subsection 6.RBSetupFail / CS RAB Attempts * 100 RAB.3. Page 42 of 106 UMTS Network Performance Engineering .FailEstabCSNoQueuing.1 Date: 2007-06-08 In general.13 in [6].FailEstabPSNoQueuing.3.Document name: UMTS RF Troubleshooting Guideline U04.RBSetupFail / PS RAB Attempts * 100 PM system RNC / Utrancell RNC / Utrancell KPI Name / Description CS RAB establishment failure rate due to RB setup failure PS RAB establishment failure rate 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]. Table 34 the corresponding PM KPIs for failures in the Radio Bearer Setup procedure: Problem RB setup failure Trace Uu Trigger Any occurrence of the RRC Radio Bearer Setup Failure message Table 33: Identification of Radio Bearer Setup failures in traces Counter / KPI8 RAB. Again it is up to the UTRAN vendor. The causes of the Radio Bearer Setup Failure message are listed in chapter 10. The other two causes are expected to occur infrequently and in general are not related to RF issues.4 for details.

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

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

6.1.

Call reliability – Radio Link Failure (RLF)
According to [11] the PHY in the NodeB and UE checks every radio frame the synchronisation status. The status is indicated to higher layers using the CPHYSync-IND and CPHY-Out-of-Sync-IND primitives indicating in-sync state and out-of-sync state respectively. In the following the UL and DL are treated separately. RLF and RL Restore in the UL The RLF and restore procedures in the UL are supervised in the NodeB on NBAP; the UL radio link sets are monitored to trigger if necessary RLF and RL Restore procedures. When the radio link set is in the in-sync state and the NodeB is receiving consecutive N_OUTSYNC_IND out-of-sync indications, NodeB starts timer T_RLFAILURE. The NodeB stops and resets timer T_RLFAILURE upon receiving successive N_INSYNC_IND in-sync indications. If timer T_RLFAILURE expires, the NodeB triggers the RLF procedure and indicates which radio link set is out-of-sync. In that case, the state of the radio link set changes to the out-of-sync state and the NodeB indicates the RLF to the RNC by sending a Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” (see [7]). Upon reception of this message the RNC starts timer T_RL_RESYNC (internal RNC timer defined by the UTRAN vendor). This timer is stopped and no further action is taken if the RNC receives from the NodeB the NBAP Radio Link Restore Indication message. The NodeB sends this message if the radio link set is in the out-of-sync state and the NodeB is receiving successive N_INSYNC_IND in-sync indications. The NodeB indicates which radio link set has re-established synchronisation. When the RL Restore procedure is triggered, the state of the radio link set changes to the in-sync state again. Upon expiration of timer T_RL_RESYNC, the RNC removes the particular RL in the NodeB via the NBAP Radio Link Deletion procedure. After the deletion of the RL the RNC starts either • With the Active Set Update procedure on RRC in case the UE is in soft/softer HO mode; note that this is not a dropped call (in terms RAB or RRC drop) Timer T314/T315 (configured by parameter T314rnc for CS / T315rnc for PS, see also Figure 17) giving the UE the possibility to re-establish the RRC connection. In case timer T314/T315 is expired the RNC releases the call by sending RANAP Iu Release Request message with specified cause “Release due to UTRAN generated reason” to the CN. Afterwards the RNC also releases the RRC connection by sending the RRC Connection Release message with cause other than “normal event”. The identification of this event only with Uu traces is difficult because it is up to the UTRAN vendor of what kind of specified cause is

6.1.1. Concept

UMTS Network Performance Engineering

Page 43 of 106

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

sent in case of an UL RLF. Finally the UE sends back a RRC Connection Release Complete and the procedure ends. Figure 11 below is showing the call handling of the RAB release in case of a dropped call:

CN

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

UMTS Network Performance Engineering

Page 44 of 106

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

Figure 12: Transitions between different states Table 35 below is listing the parameters that are configuring the RLF and RL Restore procedure:

Parameter
tRLFailure noOutSyncInd noInSyncInd radioLinkFailureResynchronisationR esponseTimer

Description
This parameter is defining the setting of T_RLFAILURE This parameter is defining the setting of N_OUTSYNC_IND This parameter is defining the setting of N_INSYNC_IND Configure guard timer T_RL_RESYNC to allow time for resynchronization to occur when a loss of synchronization is detected on the last or only radio link associated with a UE connection. Configure guard timer T_RL_RESYNC to allow time for the normal operation of the handover and power control algorithm to delete a radio link affected by a loss of synchronization or for re-synchronization to occur when the radio link is one of several associated with a UE connection. This parameter is defining the setting of T313 This parameter is defining the setting of N313 This parameter is defining the setting of T314 This parameter is defining the setting of T315 This parameter is defining the setting of N315

RadioLinkFailureDeletionResponse Timer

t313 n313 t314 t315 n315

Table 35: Parameter configuring the RLF and RL Restore procedure 6.1.2. Failure symptoms, identification and fixes for improvement There are a variety of causes responsible for RLFs possibly resulting in dropped calls: • • • • • Pilot pollution and around-the-corner effect (subsection 6.4.1) Weaknesses in the neighbour planning (subsection 6.4.4) Problems during (or before) the call establishment phase (section 5) Problems with the RF coverage (subsection 6.4.5) Problems with the SC plan (subsection 0)

UMTS Network Performance Engineering

Page 45 of 106

2. Note that the dropped call is the previous call and not the current one! There might be an optional failure cause specified.Document name: UMTS RF Troubleshooting Guideline U04.1 Date: 2007-06-08 For more information please take a look in these subsections. A RLF in the UL that is causing a removal of a radio leg can be indirectly identified if there is no Measurement Report with type 1b/1c sent previously. There might be an optional failure cause specified. for example when periodic reporting is enabled.14.03 Rev: 2.3 and 6. Problem Dropped call due to RLF in the DL on Uu RLF and RL Restore on Iub and Uu RLF and RL Deletion on Iub and Uu RLF and dropped call on Iub and Uu UL RLF and leg removal on Uu High UE Tx power High DL BLER Trace Uu Trigger Any occurrence of a RRC Cell Update message with specified cell update cause (not failure cause) “radio link failure”. Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” and after x seconds a Radio Link Restore Indication on NBAP Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” and after x seconds a Radio Link Deletion on NBAP and the number of radio legs is more than one Cross-correlation of Uu/Iub traces: Any occurrence of an Radio Link Failure Indication on NBAP with the cause “Synchronisation Failure” and after x seconds a Radio Link Deletion on NBAP and the number of radio legs is equal to one Any occurrence of an Active Set Update containing any entries in the group “RemovalInformationList” and there was no Measurement Report within x seconds before either with specified event id 1b/1c or without any specified event id9 Any occurrence if the UE is transmitting with maximum allowed power for x seconds Any occurrence if the UE is reporting a BLER higher than x% for y seconds Iub and Uu Iub and Uu Iub and Uu Uu Uu Uu Table 36: Identification of RLF in traces Table 37 below is listing the identification possibilities using KPIs retrieved by the UTRAN PM system. Dropped calls due to RLF in the DL can be easily identified in Uu traces with the Cell Update message sent by the UE. For a reliable identification additional Iub tracing is required. Table 36 below is listing the identification possibilities for network interface traces. Please review the status of the IE AM_RLC error indication. which can be set to True. Refer to Figure 13 that shows at what point during the call flow the PM counters are updated. Problem is that it can be that the Measurement Report message may not have been recorded resulting in false identification. UMTS Network Performance Engineering Page 46 of 106 . Identification of a dropped call due to RLF in the UL only with Uu traces is difficult because the RRC Connection Release message sent by the RNC has not a unique cause id. 9 To be noted: the group “eventResults” containing the IE “eventID” is optional. Other cell update failures are covered in subsection 6.

SuccEstabPSNoQueuing.HSDSCH. RF issues (subsection 6.Drop.FailEstabCSNoQueuing.RAB.CSV +(RAB. RAB drop due to CN reasons UMTS Network Performance Engineering Page 47 of 106 .4 in [9]).Drop.PS.Drop.g.8) Failures that occurred on NBAP (e.SuccEstabCSNoQueuing.PS*100 VS.3).Drop. To be noted that this does not mean the PDP context is removed.Drop.AttEstabCS.PS.SuccEstabPSNoQueuing.RAB.PS.PS. Call reliability – drop of the RAB RAB drop due to UTRAN reasons The drop of the RAB that is caused by a failure within the UTRAN is always initiated by an Iu Release Request message on RANAP with cause “Release due to UTRAN generated reason”.2.Drop.PS.ULRLF/RRC.RelocIratHORAB.ReconfFail/ RAB.RAB.AttConnRel. Concept For the reasons of these failures please refer to the corresponding sections.Drop.1.FailEstabCSNoQueuing.RAB.DL_RLF/(RAB.RelocIratHO) + RAB.ReconfFail VS.SuccEstabCSNoQueuing.SuccEstabCSNoQueuing.RAB.CSD)*100 VS.CauseULRLF)/( RAB.CauseULRLF+ VS.PS.sum*100 KPI Name / Description CS RAB Drop Rate due to DL RLF UtranCell CS RAB Drop Rate due to UL RLF UtranCell UtranCell PS RAB Drop Rate due to DL RLF PS RAB Drop Rate due to UL RLF UtranCell Total PS Dropped RABs cause UL RLF UtranCell RRC connection drop rate caused by RLF Table 37: PM KPIs indicating RLF 6. After sending this message the UTRAN will release the RRC connection (subsection 6.PS*100 VS. a FTP session that is up and running might time out.DL_RLF/RAB.CauseULRLF+ VS.SuccConnEstab.CSV.PS.AttEstabCS.3).Drop.RAB.HSDSCH.RAB.CSV.g.CauseULRLF.CauseULRLF+ VS.RelocIratHO) + RAB.SuccEstabCSNoQueuing.CauseULRLF.1 Date: 2007-06-08 PM system UtranCell Counter / KPI VS.2.CSV.DCH. The CN will send back an Iu Release Command message on RANAP with the same specified cause (chapter 9.03 Rev: 2.Drop.1) because of e.CSV. subsection 5.HSDSCH.g.Drop.RRC.CauseULRLF+ VS.RAB. but e.DCH.RAB.4.RAB.CSD.1.CauseULRLF+ VS.Document name: UMTS RF Troubleshooting Guideline U04. The UE can re-establish the RRC connection after doing a cell reselection by sending RRC Connection Request message with establishment cause “Call re-establishment” (subsection 7. the call handling is shown in Figure 11.3) (…) 6. There are a variety of reasons why the RAB drops due to UTRAN reasons: • • • • • RLF (subsection 6.CSD)*100 (VS.2.4) Hardware failures and outages on UTRAN (subsection 6.2) General drops of the RRC connection (subsection 6.HSDSCH.2.CS.RelocIratHORAB.CSV+ (RAB.CSV.Drop.

Failure symptoms.Document name: UMTS RF Troubleshooting Guideline U04. The specified cause is vendor dependent. For the root cause analysis please check with the corresponding UTRAN vendor documentation and the documentation of the CN vendor. Figure 13: Drop of the RABs after RLF 6.2.1 Date: 2007-06-08 RAB drops that are not caused within the UTRAN can be identified by the Iu Release Command message on RANAP. the specified cause is other than “Release due to UTRAN generated reason” and “normal-release”.2.03 Rev: 2. identification and fixes for improvement Table 38 is showing the identification techniques in interface traces: UMTS Network Performance Engineering Page 48 of 106 .

2.1 and 7.1. UE Poor Quality Minimum Rate. 11 this is up to the UTRAN vendor ). The likelihood of this is not very high because the specified failure causes do not match to the cell update causes Page 49 of 106 UMTS Network Performance Engineering .2.1.1 Date: 2007-06-08 Problem RAB drop due to UTRAN reasons on Iu RAB drop due to UTRAN reasons on Iu and Uu RAB drop due to CN reasons on Iu RAB drop due to CN reasons on Iu and Uu Trace Iu Trigger Any occurrence of an Iu Release Request message with cause “Release due to UTRAN generated reason” on Iu Cross-correlation Iu and Uu: Any occurrence of an Iu Release Request message with cause “Release due to UTRAN generated reason” on Iu Any occurrence of an Iu Release Command message with cause other than “Release due to UTRAN generated reason” or “normal-release” on Iu Cross-correlation Iu and Uu: Any occurrence of an Iu Release Command message with cause other than “Release due to UTRAN generated reason” or “normal-release” on Iu Iu and Uu Iu Iu and Uu Table 38: Identification of RAB drops in network interface traces There are different PM KPIs describing RAB drops defined in chapter 5.03 Rev: 2. The different PM KPIs describing RAB drops are differentiated as follows: • • • CS/PS RAB drops Reason (due to UE inactivity. Concept • • • For the variety of reasons of dropped calls (paging. Random Access procedure etc.2.1 and 6. due to Inter-frequency HHO. RLF. If this IE is set to TRUE 10 11 The case RRCConnectionRelease with cause “congestion” is covered in subsection 5.3) RRC Cell Update message with specified failure cause and with a cell update cause other than “radio link failure” or “RLC unrecoverable error” (these failures are covered in subsections 6. 6. for these two failures it might be that in addition a failure cause is specified. and following in [42].) please refer to the corresponding subsections in this document.14. …) RNC level and Utrancell level 6.Document name: UMTS RF Troubleshooting Guideline U04. Call reliability – drop of RRC connection after call setup The RRC is the context between UE and RNC on layer 3. Note that the IE “AM_RLC error indication” in the Cell Update/URA Update is specifying whether an error occurred on the RLC or not. due to DL power.4.3. SRNS Relocation. A drop of the RRC connection can be identified as follows: • • The RNC sends a RRC Connection Release message with specified 10 cause ”unspecified” or “pre-emptive release” The UE sends a Cell Update message with cell update cause “radio link failure” or “RLC unrecoverable error” and/or AM_RLC error indication is set to TRUE (see below) The UE sends a RRC Connection Request message with cause “Call re-establishment” (see comments in subsection 6.3.

This procedure fails if the UE does not send the cell update.ppt" UE Node B RNC CN RN C su spen ds RLC.5).g. Ex-Lucent supports the RRC connection re-establishment for PS.03 Rev: 2. a RANAP procedure has started or a NAS message is received to be forwarded to the UE. "RRC Connection Re-Establishment Feature. For more details regarding failures on the RLC see subsection 6.Document name: UMTS RF Troubleshooting Guideline U04. the UE sends a cell update with cause “RLF” and consequently old radio links are deleted and the new radio links are established by the RNC. The procedure will also not occur if all the radio legs are on the Drift RNC. CS and simbearer services. resetting of the RLC [36].1 Date: 2007-06-08 it is indicating that the RLC in the UE has detected a failure on one of its AM RLC entities that has not been resolved by e.14. a RANAP procedure is in progress or UE indicates that the T314 or T315 timer has expired.4. MAC 1) Cell Update (Cause Radio Link Failure) 2) Radio Link Deletion Request 3) Radio Link Deletion Response 4) ALCAP Release N ew r a d io lin k s ba sed u p on m ea su r ed E c/Io U E Moved ba ck t o Cell DCH 5) Radio Link Setup 6) Radio Link Setup Response 7) ALCAP & FP Synch 8) Cell Update Confirm 9) Radio Bearer Reconfiguration Complete 10) UE Measurements Figure 14: DL RLF and RRC re-establishment UMTS Network Performance Engineering Page 50 of 106 . where by on detection of the RLF. If there is a RRC Connection Release message with cause “congestion” the reason might be either Dynamic Bearer Control (subsection 5.1) or Congestion Control (subsection 6.

3. There are no RRC/Direct Transfer messages indicating a regular/irregular call termination within x ms. UE is PS only Node B RNC CN 1) Radio Link Failure Indication 2) Radio Link Deletion Request 3) Radio Link Deletion Response 4) ALCAP Release T_RL_RESYNCH RNC su spen ds RLC & MAC.RRC. RNC sent a ‘Cell update confirm’ but the UE didn’t respond back with a ‘RB reconfiguration complete’ within x seconds showing failure of the reestablishment Drop of RRC connection IV Uu Table 39: Identification of dropped RRC connections in interface traces PM system Utrancell Counter / KPI VS. Sta r t s Timer RNC st ops Tim er 5) Cell Update (Cause Radio Link Failure) 6) Radio Link Setup 7) Radio Link Setup Response 8) ALCAP & FP Synch 9) Cell Update Confirm 10) Radio Bearer Reconfiguration Complete 11) UE Measurements N ew ra dio lin ks ba sed u pon m ea su r ed E c/Io UE Moved ba ck t o Cell DCH Figure 15: UL RLF and RRC re-establishment 6. The UE start monitoring the BCCH and might perform a cell re-selection following a Cell Update with cause “RLF” or “RLC unrecoverable error” (see also Table 36 on page 46).sum*100 KPI Name / Description RRC Connection drop rate caused by RLF Table 40: PM KPIs of dropped RRC connections UMTS Network Performance Engineering Page 51 of 106 .Document name: UMTS RF Troubleshooting Guideline U04.Drop.2.03 Rev: 2. identification and fixes for improvement Table 39 and Table 40 below listing the identification of dropped RRC connection and the PM KPIs: Problem Drop of RRC connection I Drop of RRC connection II Drop of RRC connection III Trace Uu Uu Uu Trigger Any occurrence of a RRC Connection Release message on Uu with specified cause ”unspecified” or “pre-emptive release” Any occurrence of a RRC Connection Request message on Uu with establishment cause “Call re-establishment” The UE is simply going to idle mode without dropping the call in a regular way.SuccConnEstab.1 Date: 2007-06-08 UE T_RL_RESYNCH expires.ULRLF / RRC.AttConnRel.Failure symptoms.

For that reason no PM KPIs describing dropped calls are listed in this subsection.4.g. This guideline only briefly provides the techniques to identify these issues using Uu traces and 2G/3G scanner measurements. In this case the cells that cannot be included into the active set are decreasing the quality of the signal. This leads to poor Ec/Io ratios. Call reliability – RF planning related issues A detailed explanation of how to improve the RF environment is given in [33]. Pilot pollution 6. it is more an indication for in general nonoptimal RF conditions. There are no specific PM counters available that could differentiate RRC and RAB drops in terms of e. In addition the number of cells in the active set is a good metric of how well defined are the handover zone within the UMTS network. Failure symptoms. identification and fixes for improvement This is a typical issue for RF optimisation and can be detected via Uu interface traces and 2G/3G scanner measurements of the PHY.Document name: UMTS RF Troubleshooting Guideline U04.3.4. round-the-corner effect etc. Table 41 is listing identification techniques in drive test and scanner measurement data: Problem Pilot pollution I Pilot pollution II High number of cells in active set Overshooting Trace UE or 3G scanner UE or 3G scanner Uu UE or 3G scanner Trigger There are more than x cells with a measured Ec/No within x dB compared to the best measured Ec/No The aggregate Ec/No of the cells in the active set is below x dB while the measured RSCP is above y dBm for z ms The active set size is > 1 in more than x % of all measured samples12.1.1.2 and 6.15 for details. 6.1.4.03 Rev: 2. the RLF could fail due to out-of-synchronisation (subsection 6. 6.2. reference the corresponding subsections 6.1). Introduction 6. see also chapter 6.1 Date: 2007-06-08 6.2.4. 6. pilot pollution. The Ec/No of a site y km away is within x dB of the best measured Ec/No cells Table 41: Identification of pilot pollution 12 This is not really a problem to be identified in a trace. Page 52 of 106 UMTS Network Performance Engineering .4.2. Remark: Because in HSDPA there is no soft/softer HO gain in the downlink HSDPA is much more sensitive to pilot pollution compared to R99 services. Pilot pollution is in particular an issue when the number of best cells within a certain range is exceeding the maximum size of the cells in the active set.2. Concept Pilot pollution means an excessive overlapping of coverage footprints of different cells with no dominant pilot. As a consequence.

Failure symptoms. The root cause for this problem is shadowing of buildings or other obstructions. the average aggregate RSCP is below z dBm Table 42: Identification of around-the-corner effect UMTS Network Performance Engineering Page 53 of 106 . In addition the RF planer has to ensure that the parameters configuring the handover procedure is fast enough (subsection 6.3.4. The effect describes a moving UE where the receive level of the cells in the active set decreases dramatically (in terms of Ec/No and RSCP) whereas the receive level of cells in the monitored or detected set suddenly increases.1. Around-the-corner-effect 6. A detailed explanation of how to improve the RF environment is explained in [33].Document name: UMTS RF Troubleshooting Guideline U04. As a consequence the quality of the call will always drop if the UE is not fast enough to adapt (via Active Set Update) to the new RF conditions.3.9). 6.3.03 Rev: 2. the average aggregate Ec/No is below z dB Sudden drop/increase of the RSCP of cells in the active set by x dB for the next at least y ms. identification and fixes for improvement Around-the-corner effect can be detected via UE traces when analyzing the PHY.1 Date: 2007-06-08 6. Concept Around-the-corner-effect is quite often encountered in a dense urban environment.4. Figure 16 is showing the effect in a dense urban environment: Active Set Pilot Interfering Pilot Figure 16: Around-the-corner problem To overcome around-the-corner problem local optimisation of the RF environment is required.4.2. Table 42 is summarising the triggers in UE traces: Problem Around-the-corner effect I Around-the-corner effect II Trace Uu Uu Trigger Sudden drop/increase of the Ec/No of cells in the active set by x dB for the next at least y ms.

Document name: UMTS RF Troubleshooting Guideline U04. Concept One of the essential tasks of RF planning is neighbour list assignment. IRAT parameter settings are covered in subsection 6. Non-optimal neighbour definitions 6.4. 2G3G) Check for right nLSAPriority flag Check for missing DAHO definitions Figure 17 below is showing a sample database in MS Access format: UMTS Network Performance Engineering Page 54 of 106 .9 for details) Distance between the two cells With this kind of information the following database queries might be defined • • • • Check for symmetry or reciprocity Check for missing co-located neighbour definition (3G-3G. This subsection is focused on the integrity of the different neighbour lists definitions itself. 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.4.9. To maintain the integrity of the different HO list it is required to use a database system with the following tables: • Table keeping site specific information of the UMTS cells o o o o • Site id (for identification for co-located 2G/3G cells) Sector id (to check if a 2G cell is identical resulting in identical coverage footprint for a possible DAHO definition) Userlabel Flag borderCellToGSM Table keeping site specific information of the GSM cells o o o Site id (for identification for co-located 2G/3G cells) Sector id (to check if a 3G cell is identical resulting in identical coverage footprint for a possible DAHO definition) BCCH frequency • Different neighbour lists including o o nLSAPriority flag for 3G-3G HO definition (see also subsection 6. 3G-2G.1.4.1 Date: 2007-06-08 6.03 Rev: 2. When the neighbour lists are not well defined the UE might not be on an optimal cell (or set of cells) and the call is endangered to drop.4.10.

but the RSCP of the cells in the active set is relatively low Missing 3G-2G neighbour definition: the measured RSSI is relatively low and the GSM coverage footprint is relatively strong as measured by the 2G scanner.Document name: UMTS RF Troubleshooting Guideline U04.4. Some consistency checks are also available in the Ex-Lucent Intranet [44]. Some ex-Lucent tools like LDAT [49] have the missing neighbour list analysis feature that can be used to debug. but the IRAT handover is not triggered UMTS Network Performance Engineering Page 55 of 106 .03 Rev: 2.4.2. 6. Failure symptoms.1 Date: 2007-06-08 Figure 17: neighbour list checking using MS Access The RF template files that are converting OMC XML data into MS Excel format can be reused for these kinds of consistency checks see also [43] for details. identification and fixes for improvement Following methods can be used to fix/detect a non-optimal neighbour list assignment: • Cross-correlation measurements o o of Uu drive test logs with 2G/3G scanner Missing 3G-3G neighbour definition: measured RSSI is relatively high.

LAC NumUMTS. at the time of the measurement the UE is in 2G Missing 3G/2G neighbour definition Uu.1 Date: 2007-06-08 o Missing 2G-3G neighbour definition: UE is staying in 2G although there is sufficient 3G coverage as indicated by the RSSI measurements of the 3G scanner Analysis of the UE Measurement Reports: the UE might report cells of the detected set but these cells are not defined in the NLSA (see also subsection 6.HOPerNCell.MNC The counters have to be imported into a database as described in [45].GSM.HOPerNCell.GSM.GSM.03 Rev: 2.HOPerNCell. Table 44 is listing the identification possibilities using KPIs retrieved by the UTRAN PM system: Problem Missing 3G/3G neighbour definition Trace Uu.Document name: UMTS RF Troubleshooting Guideline U04.GSM.HOPerNCell.9 and [23] for details) o • • Analysis of the handover matrix as available in the PM system (see below) RF prediction tool analysis. In the PM system the IRAT HO Matrix is given as follows: • • • • • • NumUMTS.Att NumUMTS.Ncell.GSM. 3G scanner Trigger Any occurrence where the measured RSSI (retrieved by 3G scanner) is within a xdB window compared with the measured aggregate RSCP of the cells in the active set (measured by the UE) for y seconds. 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. at the time of the measurement the UE is in 3G The measured RXLEV of the best 2G cell (measured by the 2G scanner) is within a xdB window compared to the measured aggregate RSCP of the cells in the active set (measured by the UE) for y seconds.CI NumUMTS.Fail NumUMTS. 2G scanner Missing 2G/3G neighbour definition Uu.HOPerNCell.MCC NumUMTS. Table 43 below is listing the identification possibilities for network interface traces.Ncell. 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.GSM.HOPerNCell. 3G scanner Table 43: Identification of non-optimal neighbour definitions in traces UMTS Network Performance Engineering Page 56 of 106 .Ncell. at the time of the measurement the UE is in 3G Any occurrence where the measured RSSI (retrieved by 3G scanner) is within a xdB window compared with the measured RXLEV of the 2G serving cell (measured by the UE) for y seconds.Ncell.

2.5.1.IntraFreq.AttIncCS) * 100 (IRATHO.IratCCO) * 100 ((IRATHO. In subsection Error! Reference source not found.MX.Att) * 100 ((HHO.Qual +HHO.Qual + HHO.8). 6.Succ / VS.Load)) * 100 (RRC.7.IntraFreq. Table 45 below is listing identification triggers for low RF coverage in network interface traces: Problem Low coverage I RF Trace 3G scanner or Uu 3G scanner.4.1) or a 3G/2G IRAT handover has to be triggered to rescue the call (subsection 6.4.AttOutPSUTRAN)*100 (IRATHO.HHO.AttRelocPrepOutCS)*100 KPI Name / Description Intra-frequency HHO success rate per neighbour cell Inter-frequency hard handover success rate Incoming IRAT PS success rate (GSM -> UMTS) Incoming CS Inter RAT handover success rate (GSM->UMTS) Outgoing PS Inter RAT handover success rate (UMTS->GSM) Outgoing CS Inter RAT handover success rate (UMTS->GSM) UtranCell UtranCell UtranCell UtranCell Table 44: PM KPIs identifying non-optimal neighbour definitions 6.SuccOutInterFreq. RFCT Trigger Measured RSSI of the 3G cells is below x dBm for y seconds Measured aggregate RSCP of the cells in the active set is below x dBm for y seconds and there is no RSCP of a 3G cell measured by the 3G scanner better than z dB compared to the aggregate RSCP The reported NodeB TX power is for x second above y dBm and the measured Low RF coverage II Low RF UMTS Network Performance Engineering Page 57 of 106 .1 a drop of the RRC is described for a mobile in CELL_FACH mode.1.03 Rev: 2. identification and fixes for improvement Low receive level in terms of RSSI (means low measured RSCP values) High NodeB TX power (probably also high UE TX power) Low RF coverage can be identified as follows: One root cause for low RF coverage might be a NodeB outage.17.IratCCO / RRC. When this happens either the radio bearer has to be reconfigured due to an increasing BLER in the DL when using a PS data service (subsection 6.AttConnEstab.4.AttOutInterFreq. Poor RF coverage 6.FailIncCS. Uu Uu.5.IRATHO. • • Failure symptoms.HHO.AttIncCS .SuccOutInterFreq. But also after the integration of the sites it might happen that due to “cell breathing” especially in the busy hour the Ec/No is not sufficient to guarantee for some services like 384 kbit/s sufficient RF coverage.SuccOutCS / IRATHO.1 and 7. a similar scenario is described for a UE in CELL_PCH/URA_PCH mode. this has to be crosschecked with the FM data (see also subsection 6.Document name: UMTS RF Troubleshooting Guideline U04.Load) / (HHO.MX. Concept Especially in the early days of 3G there will be many areas with a poor RF coverage.SuccConnEstab.5.1 Date: 2007-06-08 PM system UtranCell UtranCell Counter / KPI (VS.10). In subsection 6.sum) / IRATHO.AttOutInterFreq.SuccOutPSUTRAN / IRATHO.

17. see reference UTRAN vendor documentation. RAB is released) or by the RB Reconfiguration procedure (transfer to CELL_FACH or URA_PCH/CELL_PCH mode. in both cases the PDP context is retained. Call reliability – Congestion Control (CongC) The Congestion Control (CongC) function is used to monitor. Concept • The lowering of the PS data rate is done by using either the RB Reconfiguration procedure or the Transport Channel Reconfiguration procedure (subsection 6.4. The state transfer is done by the RRC Connection Release procedure (transfer to idle mode.g.03 Rev: 2.4. from 384 kbit/s to 128 kbit/s) Transfer of (several or all) PS data users to another state e.1). interference and synchronisation issues will occur. Congestion control is configurable using UTRAN parameters. 6.Document name: UMTS RF Troubleshooting Guideline U04.Poor PSC plan The PSC is used for cell identification during the initial cell search and when measuring the neighbour cells in idle and connected mode. UMTS Network Performance Engineering Page 58 of 106 . In case the rules in that guideline are not followed the UE may make failures in the neighbour list measurements or in case of overlapping coverage areas of two NodeBs sharing the same PSC. Different strategies and a guideline for PSC planning and how to unveil weaknesses in the PSC assignment are described in [33]. Start dropping (several or all) RRC connections of non PS users 6. This will be the case if an overshooting site has the same PSC as one of the cells in the active set causing co-pilot interference or if the neighbours of the two existing active set cells share the same PSC creating NL ambiguity. idle or URA_PCH/CELL_PCH or from CELL_FACH mode to URA_PCH/CELL_PCH or idle mode (subsection 6. The RNC can initiate the following actions for already connected users to resolve the overload situation: • • Transit (several or all) users connected to PS data services to a lower bit rate (e.1. It is hardly possible to identify PSC issues in drive test data because the measured low Ec/No values or even RLF can also be the result of pilot pollution or around-the-corner effect (subsection 6. RAB is set to inactive). Also there are no specific PM counters that may track these issues. the algorithm is proprietary. CongC handles users already in connected mode.5. detect and handle situations when the system is going into overload or getting close to an overload situation.5.g.6.1 and 6.1). CongC is based on UL and DL load estimations.6).1 Date: 2007-06-08 coverage III Low Ec/No Uu RSCP of that NodeB is below z dBm Measured aggregate Ec/No of the cells in the active set is below x dB for y seconds Table 45: Identification of low RF coverage in network interface traces 6.7 and 6. from CELL_DCH to CELL_FACH.

Concept 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.1. In might be that URA_PCH/CELL_PCH mode is not used. but for UDP or RTP this might result in lost data frames. the RRC Connection is maintained using common physical channels (RACH in the UL and the PCCH in the DL). More detailed information can be found in [20]. The associated RAB is removed. identification and fixes for improvement Table 46 is listing the identification techniques in traces in case of CongC. Instead for a PS call when the inactivity timer elapsed the RRC resources are released while maintaining the PDP context.03 Rev: 2. The UTRAN may or may not initiate a state transition. The initiating of CongC is indicating a high noise raise of the RF environment.Document name: UMTS RF Troubleshooting Guideline U04. According to [6] the UE has to monitor the PICH and PCH. the RLC buffer in the RNC belonging to the RAB is buffering the data and the RNC will initiate a state transition of the UE to deliver the DL data. TCP/IP trace in or after CN Table 46: Identification of CongC in interface traces 6. On the UTRAN side no dedicated radio resources are allocated (means no RB on RRC and RL on NBAP). do periodical URA/PCH updates and perform cell reselections. The only optimisation approach in that case is to optimise the RF environment in terms of pilot pollution. neighbour list optimisation etc. relevant PM KPIs are also listed in [20].6. When there are any data coming from the CN side. The behaviour is UTRAN vendor dependent and configurable via O&M parameter.5. On the CN side there is always a RAB associated with the RRC connection but the RAB is marked (inside the RNC) as inactive. Call reliability – failures in URA_PCH/CELL_PCH mode When the UE is in CELL_PCH or URA_PCH.1 Date: 2007-06-08 Dropping of the RRC connection is done using the RRC Connection Release message with specified cause “congestion”. Problem CongC Release RRC Trace Uu Trigger Any occurrence of an RRC Connection Release message with specified cause “congestion” and the UE is either in CELL_FACH or CELL_DCH PS mode13 Cross-correlation of interface traces on Uu and TCP/ in or after CN side: Any occurrence when either the PS data rate is reduced or the UE is transferred from CELL_DCH to CELL_FACH / CELL_PCH / URA_PCH mode and at the same time there is still data in the RLC buffer of the RNC as measured in Ethereal CongC RRC PS data reduction DL Uu.2. The advantage of the URA_PCH/CELL_PCH mode compared of the idle mode is that the re-establishment can be done faster because the RAB and RRC 6. Failure symptoms. The UE can send data via the RACH in UL. For TCP applications this is appropriate because TCP traffic always starts using the Slow Start procedure. the UE is sent to idle mode. UMTS Network Performance Engineering Page 59 of 106 . 6. The UE might indicate to the RNC if the UE RLC buffer is filled up rapidly by sending RRC Measurement Report 4a on RACH.6.

The concept is similar to that described in subsection 6.1. The UE has no dedicated UTRAN radio resources.2. Failures due to PCH/AICH/PICH or the RACH procedure might lead to a drop of the RRC connection and drop of the PDP context as described in subsection 5.1.1. Call reliability – failures in CELL_FACH mode When only a small amount of data has to be exchanged the UE can be in CELL_FACH mode camping on one cell in order to save battery and RF network resources.1 Date: 2007-06-08 connection does not need to be re-established again. Concept UMTS Network Performance Engineering Page 60 of 106 .1.1). on Iub there are no reserved resources available. For dynamic bearer control (DBC) failures see subsection 5. difference is that a state transition is not mandatory (but might be useful). Failures due to the RB Reconfiguration procedure are described in subsection 6.03 Rev: 2. the RRC connection is established using the common channels (FACH in the DL and the RACH in the UL). Disadvantage is that there are still some (very low) UTRAN resources the RNC has to maintain.Document name: UMTS RF Troubleshooting Guideline U04.2.7.17.1.6.1). Failure symptoms. There is always a RAB associated with the RRC connection because any DL data received by the GGSN has to be forwarded to the UE.6. Figure 18 below is showing the transition phases between different UE states: URA_PCH / CELL_PCH Cell DCH HSDPA Cell FACH Cell DCH DCH IDLE Figure 18: Transition phases between the different UE states 6.3. identification and fixes for improvement Failures and dropped RRC connections when the UE is in URA_PCH or CELL_PCH mode might occur in the cell selection/reselection process (subsection 5. In this case the RAB will be removed. failures due to periodical URA/PCH updates (subsection 5.7.4. 6. 6.1.

The UE in CELL_FACH mode informs the UTRAN when reselecting a new cell by sending a RRC Cell Update message on RACH. The algorithms are vendor dependent taking into account traffic measurements and the RF environment.1 Date: 2007-06-08 According to [6] the UE has to monitor the FACH transport channels in the downlink. It might be necessary to either delete or setup resources on the Iub via the corresponding NBAP procedures (exception is the transition from CELL_FACH to URA_PCH/CELL_PCH but this should occur rarely).17. Figure 18 is showing the different UE states and possible transition between them. Figure 19 and Figure 20 below are visualising the call handling for the transition from CELL_DCH to CELL_FACH and vice versa: Figure 19: Call handling for transition from CELL_DCH to CELL_FACH UMTS Network Performance Engineering Page 61 of 106 .Document name: UMTS RF Troubleshooting Guideline U04. the RNC answers by sending a Cell Update Confirm message on the FACH and the procedure ends with the UE sending an UTRAN Mobility Information Confirm message again on RACH.1). The SRNC decides whether or not to transit the UE to another state. In all cases the RNC will initiate the transition by using either the RB Reconfiguration or the Transport Channel Reconfiguration procedure on RRC (subsection 6. Please check in the particular UTRAN vendor parameter description.03 Rev: 2.

In the meantime the UTRAN might already have dropped the RRC if it had tried and failed to send PS data in the DL. In this case the RNC sends a RRC Connection Release message on FACH and the UE sends back a RRC Connection Release Complete message on RACH before transiting to idle mode. A drop of the RRC connection might occur if the UE is leaving the RF coverage area and then when coming back the UE has to inform the UTRAN by sending a Cell Update message with cause “Re-enter service area”.1. Failure symptoms.7.5) Failures related to the Radio Bearer Reconfiguration/ Transport Channel Reconfiguration procedure on RRC (subsection 6.2.03 Rev: 2.Document name: UMTS RF Troubleshooting Guideline U04.1 Date: 2007-06-08 Figure 20: Call handling for transition from CELL_FACH to CELL_DCH The RNC may decide to release the RRC connection due to e.1.g.3) Failures related to the FACH (subsection 5.1. CongC. identification and fixes for improvement The following failures might occur for UEs in CELL_FACH mode or during the transition from/to CELL_FACH mode: • • • • • Failures related to the cell selection / reselection (subsection 5.1) Failures related to the Random Access Procedure (subsection 5.17.1.1) Table 47 is listing failures for UEs in CELL_FACH mode and how to identify it in traces: Problem Dropped call in CELL_FACH Trace Uu Trigger Any occurrence when the RRC connection dropped while the UE was in CELL_FACH state Table 47: Failure identification in traces if the UE is in CELL_FACH mode UMTS Network Performance Engineering Page 62 of 106 . 6.6) Failures related to the setup of the RL on NBAP (subsection 5. In parallel the RAB will be released.

According to [12] the soft/softer HO procedure consists of the following steps: • • • • • • Cell search and measurements of cells in the active set and the monitored set Reporting of measurement results by the UE (RRC Measurement Report message including specified event id) The HO algorithm Allocation/release/change of network resources on NBAP Execution of the HO (RRC Active Set Update message) by the RNC If necessary execution of RNS relocation procedure (subsection 6.1.1. The soft/softer handovers can be either requested by the UE (mobile evaluated HO) or can be triggered by the UTRAN (network evaluated HO).9. Table 48 is listing possibilities of detecting the outages: Problem Iub out-of-sync I Iub out-of-sync II Iu out-of-sync I Iu out-of-sync II Trace Iub Iub Iu Iu Trigger Missing STAT PDUs on AAL5 for more than 5 seconds Any occurrence of an AuditRequiredInformation on NBAP Missing STAT PDUs on AAL5 for more than 5 seconds Any occurrence of an Reset on RANAP Table 48: Identification of outages in network interface traces 6.8. All intra-frequency measurement reporting events (1a to 1i) are defined in [6].3) 6.4. Furthermore coverage issues (subsection 6. Failure symptoms. analysing the retrieved FM data can give a good indication for the failure cause. Concept UMTS Network Performance Engineering Page 63 of 106 .9.8. 6. In addition it is assumed that the reporting criteria are set to “event triggered” rather than “periodically”. Concept 6. Outages may lead to drops of the RAB and the RRC connection because of missing synchronisation. identification and fixes for improvement Outages can be easily identified when tracing the interfaces that have been outof-sync. Call reliability – hardware and network interface outages Hardware failures can occur on the different nodes of the UTRAN and the CN.5).2. problems in the neighbour definition (subsection 6. see [42] for details. Call reliability – intra frequency handover In UMTS networks intra-frequency soft/softer handover is one basic feature that ensure seamless mobility as well as call performance and quality improvement.1) may also occur leading to dropped calls and network degradation even on NodeBs not affected by the outages.03 Rev: 2.Document name: UMTS RF Troubleshooting Guideline U04.4) and problems in the cell/PLMN selection/reselection procedure (subsection 5. but also on the particular interfaces as defined in the 3GPP specification. 6. There are many reasons for outages.4.1.17.1 Date: 2007-06-08 There are a lot of PM counters available counting the number of attempts and failures for the state transitions.8.

as an example Figure 22 below is showing a flowchart for an intra-RNC Active Set Update procedure of type event 1a (the grey box contains the RL deletion in case of event 1c): UMTS Network Performance Engineering Page 64 of 106 . 1b and 1c: Figure 21: HO parameter for event 1a. As an example Figure 21 below is visualising the HO parameter like time to trigger (∆T) and the HO hysteresis for the Measurement Report events 1a.03 Rev: 2.1 Date: 2007-06-08 • • Active Set Update Complete message on RRC from UE (successful case) RNC updates the measurement parameters including cells belonging to the new monitored set and other measurement parameters via the RRC Measurement Control Message The different steps are configurable using UTRAN O&M parameters.Document name: UMTS RF Troubleshooting Guideline U04. 1b and 1c The call handling depends on the type of event.

03 Rev: 2. 6.g. These failures are most likely due to RF planning issues like nonoptimal neighbour definitions. pilot pollution.3 Failures during the release of network resources on NBAP (e.9.1 Date: 2007-06-08 Figure 22: Call handling flowchart of Active Set Update event 1a (event 1c) HO related parameters and more detailed information about the Ex-Lucent implementation is available in [23].4) • • • • UMTS Network Performance Engineering Page 65 of 106 .1. event 1c). (see subsection 6. these failures should occur very rarely (subsection 6.Document name: UMTS RF Troubleshooting Guideline U04.17. Failure symptoms. identification and fixes for improvement There are many different reasons why the HO procedure might fail or not executed in an optimal manner: • Measurement problems of the cells in the active and monitored set.2. weak PSC plan etc. timing and HO algorithm Problems with the allocation of network resources on NBAP: Radio Link Setup procedure in case no RL exists to the particular (new) NodeB (subsection 5.4 for details) Misconfiguration of UTRAN parameter setting up the filtering.17.5) and Radio Link Addition procedure in case there is already a RL to the NodeB Problems during RNS relocation procedure are covered in subsection 6.

because the UTRAN instructs the UE to perform a measurement that is not supported by the UE) RRC Active Set Update failure message from UE in case of o o o o o o o Unsupported or invalid configuration Incompatible simultaneous reconfiguration Invalid Active Set Update message The UE is in a wrong state to receive that message (means another state than CELL_DCH) Protocol error Physical channel error (…) • The filtering. timing and HO algorithm are configurable by UTRAN parameter.g.03 Rev: 2. periodic reporting an update via Measurement Control message is not required Page 66 of 106 UMTS Network Performance Engineering . Especially in dense urban environment these parameter had to be optimised e. to react faster to the around-the-corner effect or in areas with weak coverage to trigger the 3G-2G HO faster. Problem Intra Delay Frequency Handover Trace Uu Trigger Any occurrence where the UE sends a Measurement Report 1x and the RNC does not reply with an Active Set Update message within y seconds Any occurrence where the UE is sending an Active Set Update Failure message Any occurrence where the RNC is not sending the Measurement Control message within y seconds after the UE has sent the Active Set Update Complete message and the event ID of the last Measurement Report has been event 1x14 Any occurrence of a dropped call within y seconds after the RNC has sent an the Active Set Update message and the event ID of the last Measurement Report has been event 1x There is one (or more) intra-frequency cell measured by the 3G scanner that is not in the active set and its Ec/No is for x seconds better than y dB compared to the best cell in the active set and the UE is not sending within that time period a Measurement Report with id 1a or 1c Whenever a cell is added to the active set (event 1a) . Table 49 below is summarising how to identify these issues in network interface traces.g. Long handover delays can result in dropped calls and in a decrease of the overall UMTS RF conditions. it is removed within x seconds again (event 1b or 1c) or vice versa Any occurrence where the UE is sending an Measurement Control Failure message Active Set Update Failure Long delay of Measurement Control message after Active Set Update Complete for event 1x Dropped call during event 1x Uu Uu Uu HO event 1a/1c is too slow Uu. For each UTRAN vendor default parameter settings should be in place.g.1 Date: 2007-06-08 • Measurement Control Failure message (e.Document name: UMTS RF Troubleshooting Guideline U04. 3G scanner Ping-pong HO Measurement Control Failure Uu Uu Table 49: Identification handover issues in traces 14 In case of e. Note that the handover delay can be confused with missing RRC messages (check event id of Measurement Report with removal/addition list of ASU message).

10. When the measured Ec/No or RSCP of the cells in the active sets exceeds a specific threshold the UE sends a Measurement Report “2f”. Furthermore they can be used for traffic distribution. Call reliability – IRAT handover 6. When the measured Ec/No or RSCP of the cells in the active sets drops below a certain threshold. IRAT handovers are always hard handovers and can be either mobile assistant or database assistant.10. the IE “BSIC verification required” is set to “not required”). Meanwhile the UTRAN may send another Measurement Control message including a modified (shorter) GSM neighbouring list to measure. The UE is continuing reporting the IRAT neighbouring cells.1.Document name: UMTS RF Troubleshooting Guideline U04. The UE may send in between a Measurement Report “1e” including SC and measured Ec/No and/or RSCP of a 3G cell exceeding the “1e” threshold. Two different procedures might be used: Procedure 1: The measurement reporting and filtering methods are similar to the one of the intra-frequency handover as explained in subsection 6. but not of the BSIC.1 Date: 2007-06-08 PM KPIs related to the intra-frequency handover process are available in [23]. The UE is now starting to periodically report the BCCH and RXLEV. After some time the UE either automatically leaves compressed mode or the UTRAN selects one of the reported GSM cells as handover candidate by sending the Handover From Utran command on RRC.03 Rev: 2. if the measured level on the GSM/GPRS system exceeds a predefined threshold and the measured Ec/No or RSCP of the cells in the active set is below a predefined threshold. While in compressed mode. the RNC may or may not react on this Measurement Report by sending an Active Set Update message. UMTS Network Performance Engineering Page 67 of 106 . but now not only the BCCH and RXLEV. the UE sends a Measurement Report “2d” to the RNC and after receiving the RB Reconfiguration message from the UTRAN goes in compressed mode to start the IRAT measurements as specified in the Measurement Control message. The UE may then leave compressed mode after it receives the Measurement Control message with IE “tgps-Status deactivate”. The RNC sends two Measurement Control messages (a short one defining when the UE will automatically leave compressed mode as specified by IE TGPS and a following Measurement Control message with the IRAT handover list including BSIC and BCCH. but now the IE “BSIC verification required” is set to “required”. Procedure 2: This procedure is using Measurement Report “1f” and Measurement Report “6a” based on which UTRAN may send the UE (via RB Reconfiguration message) into compressed mode.9. the UE sends the Measurement Report “3a”. Concept (UMTS->GSM) IRAT handover are used to maintain the UMTS voice call in case the 3G RF coverage and/or quality is not sufficient. 6. but also including the decoded BSICs. The UTRAN/BSS might decide to trigger the IRAT handover by sending the Handover From Utran command on RRC.

1 Date: 2007-06-08 Figure 23 below shows the call flow chart across the UMTS and GSM network for performing UMTS to GSM voice handover including the UMTS and GSM CN: Figure 23: Flow chart of successful UMTS to GSM voice handover The major components that constitute failures of UMTS to GSM Handover may be classified as following: • • • • RB reconfiguration failures when entering/leaving compressed mode (subsection 6.17.03 Rev: 2.2/not in this figure) Relocation procedure failures (subsection 6. the SRNC sends the Handover From UTRAN Command including the GSM Handover Command to UMTS Network Performance Engineering Page 68 of 106 .Document name: UMTS RF Troubleshooting Guideline U04.17.4/phase 3 in figure) Upon successful completion of the relocation procedure.3/phase 1 in figure) Handover procedure failures in GSM network (phase 2 in figure) Release procedure failures (subsection 6.17.

Failure symptoms.3.1 Date: 2007-06-08 the UE. More information about IRAT Handover optimisation is available in [46]. According to [9] the failure causes specified within this message can be subdivided as follows: • • • Physical channel failure Unacceptable configuration Protocol error The first failure refers to the case when there is loss of synchronisation between UE and NodeB.10. Table 50 below is listing the identification triggers for IRAT HO problems in traces: Problem Delayed IRAT HO after event 3a Handover From UTRAN Command Failure RRC drop compressed mode in Trace Uu Uu Trigger Any occurrence of a Measurement Report 3a sent by the UE. The following figure shows HO execution signaling flow that starts with the RNC receiving ‘Relocation Request’ from 3G MSC and ends when the RNC sends back ‘Relocation Complete’ after receiving ‘Handover to UTRAN Complete’ RRC message from the UE. The other two causes are expected to occur seldom and in general are not related to RF issues. identification and fixes for improvement (UMTS>GSM) In case of a high failure rate during the IRAT handover procedure it should be checked if the HO has to be triggered earlier under better 2G and 3G radio conditions. This is mainly caused by poor RF conditions. The IRAT HO can be configured with the parameters as described in [25]. Concept (CS GSM ->UMTS) The IRAT for GSM to UMTS would allow the operator to make use of the 3G coverage in case of GSM network overload or simply to maximise the usage of UMTS network.10. This HO is limited to CS calls and in case of combined CS/PS call the UE is required to setup the PS part of the call upon successful completion of CS handover. 6. but there is no Handover From UTRAN Command within x seconds Any occurrence of a Handover From UTRAN Command Failure message sent by the UE Any occurrence of a drop of the RRC connection when the UE was in compressed mode Uu Table 50: Identification of IRAT HO problems in traces 6.Document name: UMTS RF Troubleshooting Guideline U04. in case of unsuccessful attempt. From UTRAN perspective hoToUtranCompleteTimer is used to ensure that RNC will release the resources if it does not receive any abort or failure messages.03 Rev: 2.2. If the UE fails to complete the requested handover then the SRNC receives a Handover From UTRAN Command Failure message from the UE. However the HO is actually initiated by the GSM network and hence not discussed any further. UMTS Network Performance Engineering Page 69 of 106 .

10. Failure symptoms. radio link setup fails on Iub or the ALCAP Iu transport bearer cannot be established • The RNC does not receive a HANDOVER TO UTRAN COMPLETE message from the UE. In this case the timer expires • The MSC cancels the relocation by releasing the Iu connection UMTS Network Performance Engineering Page 70 of 106 . For a full list please refer to [25]. identification and fixes for improvement (CS GSM >UMTS) Some main reasons as to why the GSM to UMTS handover procedure may fail can be as follows.g. • 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.03 Rev: 2. because the UE has received an invalid HANDOVER TO UTRAN COMMAND message or it does not support the configuration included in the message.Document name: UMTS RF Troubleshooting Guideline U04.4.1 Date: 2007-06-08 Figure 24: Flow chart of successful GSM to UMTS CS handover 6. e.

2. Call reliability – Cell change order from UTRAN 6.11.Document name: UMTS RF Troubleshooting Guideline U04. In the Measurement Control message it is only specified that the UE has to report the BCCH/RXLEV. It might be that the twostep approach to first only measure BCCH/RXLEV of the neighbouring GSM cells.11. timer T309 supervises this procedure. perform a cell update procedure with cause "Radio link failure" o • in CELL_FACH mode o Revert to the cell it was camped on at the reception of the reception of cell change order from UTRAN and transmit the cell change order from UTRAN failure message and set the IE "InterRAT change failure" to "physical channel failure" Select a UTRAN suitable cell and initiate the cell update procedure using the cause "cell re-selection" Table 51 below is listing the parameter for the cell change order from UTRAN procedure: Parameter t309 Description Defining timer T309 Table 51: Parameter used for configuring the cell change order from UTRAN Table 52 below is listing the identification in interface traces possibilities for the cell change order from UTRAN procedure: Problem Cell Change Order from UTRAN I Trace Uu Trigger Any occurrence of the RRC message CellChangeOrderFromUTRANFailure UMTS Network Performance Engineering Page 71 of 106 . may not be adopted. identification and fixes for improvement In case the UE cannot successfully complete the procedure and T309 expires. The UE is doing an inter-RAT cell reselection as specified within IE "Target cell description" of the CCO from UTRAN message. and then the BSIC. The approach for PS inter-system/RAT handover is similar to the one described for the CS inter-system handover in subsection 6.11. Concept The cell change order from UTRAN procedure may be initiated by the UTRAN when the UE is in CELL_DCH or CELL_FACH mode. a BSIC and BCCH are specified.10. 6. the UE will • in CELL_DCH mode o Re-establish the UTRA physical channel(s) used at the time for reception of cell change order from UTRAN and transmit the cell change order from UTRAN failure message and set the IE "InterRAT change failure" to "physical channel failure" OR when not successful. 6. Nevertheless when the UTRAN decides to direct the UE to the GPRS domain.03 Rev: 2. In the UE.1 Date: 2007-06-08 PM KPIs related to the IRAT Handover process are detailed in [25].1. Failure symptoms.

All interfrequency measurement-reporting events (2a to 2f) are defined in [6].3) The different steps are configurable using UTRAN O&M parameters. 6. The call continues on the current configuration (old frequency).1.2. Furthermore transport channel reconfiguration is only used if doing HS-DSCH-to-HS-DSCH HO (as shown in Figure 25) else physical channel is reconfigured for DCH-toDCH HO. Failure symptoms. The whole procedure (from receipt of measurement report till HO success or failure) is supervised by a timer interFreqHoProcedureTimer. the call flow follows slightly different sequence if the HO is inter/intra-NodeB and inter/intra-RNC. Transport Channel . According to [24] this procedure consists of the following steps: • • • • Detection of the need for inter-Frequency HO HO algorithm selection and measurement report setup Measurement event report reception and HO execution If necessary execution of RNS relocation procedure (subsection 6. Concept In UMTS networks inter-frequency hard handover is a feature that ensure seamless mobility between frequency carriers in same or different spectrum bands.Document name: UMTS RF Troubleshooting Guideline U04. Irrespective of the reason for initiation. Call reliability – inter frequency handover 6.03 Rev: 2.12.or Radio Bearer Reconfiguration • UMTS Network Performance Engineering Page 72 of 106 . The UE may not able to perform the new configuration and returns a Physical Channel -. Then it returns a NBAP Radio Link Addition Failure or Radio Link Setup Failure message to the SRNC (section 5. Otherwise MAHO is recommended for most scenarios. DAHO algorithm is only used when handing over from a Micro to a Macro site.1. In addition it is assumed that the reporting reports are set to “event triggered” rather than “periodically”. The hard handovers can either be triggered by the degrading quality of the current frequency or by a high load condition. as constituent procedures are the same.17.5) either directly or via DRNC.12.1 Date: 2007-06-08 Cell Change Order from UTRAN II Uu Any occurrence of the RRC message CellChangeOrderFromUTRAN and within x seconds there is a cell update message with cause "Radio link failure" Any occurrence of the RRC message CellChangeOrderFromUTRAN and within x seconds there is a cell update message with cell update cause "cellReselection" Cell Change Order from UTRAN III Uu Table 52: Identification of cell change order from UTRAN failures in traces PM KPIs related to the process is available in [25].12. however some salient failure mechanisms are • The Node B is unable to allocate the resources requested. 6. Two algorithms are available namely DAHO and MAHO with the later requiring compressed mode unless UE capability indicates otherwise. identification and fixes for improvement The reasons for inter-frequency HO failures are similar to the ones that may be encountered during intra-frequency or IRAT HO.

The newly allocated resources on the NodeB are released by means of the NBAP Radio Link Deletion procedure by the RNC. The old radio resources are no more available and the call will drop. • If the Inter-Frequency Handover Procedure Timer expires before the Physical Channel or Transport Channel or Radio Bearer Reconfiguration message has been sent to the UE then the SRNC undoes all actions already performed and releases all radio resources newly allocated for this handover using the NBAP Radio Link Deletion Procedure. UMTS Network Performance Engineering Page 73 of 106 . The RNC initiates the RANAP Iu Release Request procedure with cause 'Failure in the Radio Interface Procedure' towards the CN. In case of HS-DSCH configuration the transport channel is re-configured to DCH. If the timer expires after any of the above Reconfiguration message has been sent to the UE then the SRNC releases all radio resources newly allocated using the NBAP Radio Link Deletion Procedure.Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2. The call continues on the current configuration. Otherwise the call continues on the current configuration.1 Date: 2007-06-08 Failure.

Intra-SRNC Note that the phase “UE detected” refers to the achievement of RL synchronisation with the new target cell. Iu UMTS Network Performance Engineering Page 74 of 106 .03 Rev: 2.Intra-Node B.1 Date: 2007-06-08 Figure 25: Inter-frequency Handover Message Flow (HS-DSCH to HSDSCH) . Problem Inter Frequency HO Delay Trace Uu Trigger Any occurrence where the UE sends a Measurement Report 2x and the RNC does not reply with Physical or Transport Channel Reconfiguration message within y seconds RNC sends a Physical or Transport Channel Reconfiguration message but the UE does not respond back with either Dropped call during IF HHO Uu. The user plane interruption is likely to be longer for the UL as DL data is sent on both the old and new RL while UL is only sent on old RL until either it fails or the new RL is restored.Document name: UMTS RF Troubleshooting Guideline U04.

Segmentation and reassembly Variable-sized IP packets provided by the PDCP as RLC SDUs are segmented into fixed sized RLC PDUs.<trigger>. RLC provides three basic tasks: 1. Call reliability – failures on RLC 6. Concept The specification of the RLC protocol is provided in [36].<failure cause> VS. 2.14. ATM failures and performance statistics of the Transport Network are not reported at the FM/PM system of the UTRAN.<trigger> KPI Name / Description Inter-frequency hard handover success rate Hard handover failure count Hard handover preparation attempt count Table 54: PM KPIs identifying Inter-Freq HO problems 6. Concatenation and padding are used for efficient packing. when using microwave links Configuration issues 6. Each RLC PDU is transferred as one fixed-sized PHY TB.14.AttOutInterFreq. while the air interface provides varying throughput due to varying channel conditions.Document name: UMTS RF Troubleshooting Guideline U04. with help of the ALCAP protocol resources are allocated. but on the ATM system. On the Iu interface the underlying ATM protocol is AAL5. On the Iub interface AAL2 and AAL5 are used.1 Date: 2007-06-08 complete or failure message within y seconds.FailOuterInterFreq.HHO.1. Table 53: Identification of inter Freq HO failures from traces UTRAN Some important KPIs/Counters pegged during this process are given below: PM system UtranCell UtranCell UtranCell Counter / KPI15 (HHO. Page 75 of 106 UMTS Network Performance Engineering . 3. Buffering Buffering is required in RLC to compensate for the data rate variations of higher and lower layers: TCP/IP based applications typically generate IP packets at variable data rate. This will be followed by RNC initiaiting Iu release procedure. Main problems that might occur on the Transport Network are as follows: • • Link synchronisation problems e.g. The RLC is a layer 2 sublayer.<trigger> / HHO. A detailed description of the ex-Lucent implementation is available in [21]. Please check the corresponding documentation.03 Rev: 2.13. 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.AttPrepOutInterFreq. Call reliability – failures on the Transport Network The underlying transport network on the Iub and Iu interface is ATM.<trigger>) * 100 HHO.SuccOutInterFreq.

1 Date: 2007-06-08 AM RLC provides the link-layer ARQ scheme that is required to hide PHY block errors from higher layers. concatenation and padding into RLC PDUs. Figure 26 below is showing the UMTS protocol stack of the user plane for a TCP/IP data application: Figure 26: UMTS protocol stack of the userplane for a TCP/IP application UMTS Network Performance Engineering Page 76 of 106 . transparent to the RLC Used for signalling SRB (e. Reassembly of PHY data from TB into RLC PDUs and RLC SDUs Used for fast signalling (e.Document name: UMTS RF Troubleshooting Guideline U04.g. retransmission of erroneous or lost PDUs and in sequence delivery of RLC PDUs by ARQ Used for signalling (SRB 2-4) and PS data services There is one pair of AM RLC entities per RB. broadcast SRB on BCCH.03 Rev: 2. Each PDU is transferred as one physical layer TB.g. voice services and CS data UM data transfer o Buffer control of RLC SDUs for smoothing data rate variations introduced by burst-traffic sources (e. In the following TM is not considered any further because there is no performance impact due to RLC. TCP flow control) and lower layer variations Segmentation. SRB1 on DCCH) o o o • AM data transfer o o o o UM data transfer features plus Error control feedback. The RLC provides three different types of data transfer modes: • TM data transfer o o • No protocol overhead added.g. paging SRBs on PCH).

Furthermore if a data PDU is not completely filled with data of one SDU. It is up to the RLC of how to react on lost data and possibly initiate retransmission. They can be sent periodically or unsolicited e.g. A RLC PDU for PS RB has a size of 42 bytes (40 byte payload and 2 byte header). in the UL the NodeB is adding the CRCI to each TB set (see also subsection 7.Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2. Because the TCP settings could be different on each client PC (and the corresponding server in the Internet or corporate business network) a reference client-server system should be defined and used to optimise the RLC settings.2. STATUS PDUs have priority over retransmitted data. SDU discard function: when the delivery of a SDU cannot be managed because of e. which is relatively small compared to a TCP/IP packet size of around 17 1000 byte . 16 RLC ARQ mechanism For identification each PDU has (for DL and UL and per RLC entity separately) an increasing SN (0. If a data PDU is NACK it can be quickly retransmitted.g. • • • Protocol error recovery • • • Data PDUs carrying poll requests and status or other control PDUs require a special ACK and are protected by timers When timer protected PDUs are not acknowledged before the timer elapses these PDUs are retransmitted If timer protected PDUs are retransmitted and still no ACK received then o If data PDU retransmission did not succeed. 0. after loss detection Polling from TX: the TX can request a status report Window mechanism: a sliding window allows the TX to transmit new PDUs while waiting for the ACKs till end of the window size. In addition it might be that the IP packet is further segmented by one Internet server routing the packets 17 UMTS Network Performance Engineering Page 77 of 106 .…. For each TB set the PHY is performing a CRC check.1). concatenation and/or padding are applied. If one of both CRC fails lower layer discards the whole frame on Iub / the whole TB set. the transmission of SDUs is stopped and discarded on both TX and RX side.127 for UM).1.1 Date: 2007-06-08 TCP has its own flow control and ARQ algorithms so the O&M parameter of RLC has to be adapted to interwork with TCP in an optimal way. ARQ is using the following mechanism: • Status reporting on the RX: the RX sends a status report in so-called STATUS PDUs containing a detailed list of received and missing PDUs. As a consequence retransmission on RLC results in a retransmission of relatively small amount of data compared to that on TCP/IP layer. repeated errors. Furthermore the physical frames on Iub are protected by additional CRCs. At the TX the data PDUs are stored in a retransmission buffer when they are submitted to the MAC and PHY layer. go either to SDU discard or RLC reset of the RLC connection between the two entities 16 The size of signaling SRBs is 16 bytes plus 2 bytes header The size of the TCP/IP packet is depending on the MSS negotiated for each TCP session during the connection setup. 4095 for AM. ….

g. identification and fixes for improvement The retransmission on RLC layer can be easily identified by a not-in-sequence delivery of RLC PDUs on Iub. There might be optional a failure cause specified. see also subsection 7. Failure symptoms. Another (but quite complicated) possibility is the analysis of the BITMAP in the status reports of the RX. Table 55 is listing problems that can be detected in interface traces and Table 56 the corresponding KPIs in the PM system: Problem RLC Resets RLC retransmission SDU discard with explicit signalling Dropped call due to RLC error Trace Iub Iub Iub Uu Trigger Any occurrence of RLC Resets in Iub traces Any occurrence of retransmission of RLC PDUs per RLC session Any occurrence of a Move Receiving Window (MRW) command indicating a SDU discard and/or a MRW-ACK Any occurrence of a RRC Cell Update message with specified cell update cause (not failure cause) “RLC unrecoverable error”.3. incorrect neighbouring definitions etc. The IE AM_RLC error might be set to TRUE. In this case the RRC might be dropped and the UE performs a Cell Update and the IE “AM_RLC error indication” is set to TRUE (subsection 6. Lower layer problems on the Iub Decrease of the data rate because of . when the transmission of the RLC PDU does not succeed for a long time.2. A dropped call due to a RLC error can be easily identified by a Cell Update message with cell update cause “RLC unrecoverable error”. The SDU discard function allows avoiding buffer overflow. go to RLC reset of the RLC connection between the two entities o If RLC reset does not succeed. Reason for problems on the RLC might be due to • • • RF related issues like pilot pollution. Table 55: Identification of RLC problems in traces UMTS Network Performance Engineering Page 78 of 106 . There will be several alternative operation modes of the RLC SDU discard function. The SDU discard function allows discharging RLC PDU from the buffer on the transmitter side.2. this information is normally not available in Uu traces.1) Parameters configuring the RLC are available in [27]. For better identification on Iub the particular call has to be extracted so as not to mix up with RLC PDUs of other calls.3). signal unrecoverable error to higher layers.14. In addition special ASCII files downloaded via FTP can be used to easily identify retransmission (only possible when PPP and PDCP compression techniques as well as ciphering is disabled. The BITMAP is giving the TX an indication about which PDUs have been successfully received and which not starting from the FSN (number of octets determined by LENGTH) [36]. The RX acknowledges in its status reports all PDUs with a SN < LSN.Document name: UMTS RF Troubleshooting Guideline U04.e.1 Date: 2007-06-08 o If SDU discard does not succeed. and which discard function to use will be given by the QoS requirements of the Radio Access Bearer. See Table 55.03 Rev: 2. CongC resulting in SDU discards 6.

1 M TP3-b M TP3B M TP3B SSCF-N SSCF SSCF SSCOP SSCOP SSCOP A L5 A L2 A L5 A L5 A A A L2 A L1 A TM A TM STM -1 E1 UDP RA P NA FP RA P NA GTP-U GTP-C Q2150. fast scheduling and resource sharing techniques. Compared to Release 99 the following changes have been done for HSDPA: • • • • • On UTRAN.MM.RLCError KPI Name / Description The measurement provides the number of requested cell updates with cause “Radio Link Control (RLC) Unrecoverable Error” received by the RNC from the UE. Call reliability – HSDPA 6.CellUpdateReq.1 PHY DCH PHY HSDPA PHY PHY HSDPA DCH HSFP SSCF-UNI SSCF SSCF DSCH FP SSCOP SSCOP SSCOP A L5 A A L5 A L5 A A A L2 A A L2 A L2 A A A TM A TM STM -1 E1 Control Plane User Plane Transport Plane Com on m Figure 27: HSDPA protocol stack enhancements The following subsections are describing different aspects of HSDPA data calls.15.03 Rev: 2. Table 56: PM KPIs on RLC layer 6.15. 1 M TP3B SSCF SSCOP L2 A L5 A L1 IP Q2150.… New UMTS physical channels New handsets with high speed capability Core Network accommodation for more traffic … Figure 27 below is visualising the changes in the UMTS protocol stack in order to support HSDPA: UE Uu Node B Iub RNC Iups SGSN Gn GGSN SM SM PM M M M PDCP RRC RRC PHY RLC codec RLC MC A MC A Phy-up Phy-up IP SM M M PM M SM RRC PDCP GTP-U RRC RLC RLC MC A MC A A P LCA P M C-hs STC.1 Date: 2007-06-08 PM system UtranCell Counter / KPI VS.2 NBA A DCH FP HSDSCH FP PHY A L2 A A TM E1/ STM -1 SSCF-UNI SSCOP A L5 A A P LCA NBA STC.1. new modulation schemes. UMTS Network Performance Engineering Page 79 of 106 .1 UDP Iu UP IP Q2150. Introduction From UMTS Release 5 onwards HSDPA is supported in order to provide UMTS subscribers higher throughput rates in the downlink as well as better resource allocation in the UTRAN.Document name: UMTS RF Troubleshooting Guideline U04.2 P NBA A P P LCA Phy-up Phy-up IP SCCP SCCP M TP3-b DCH FP SSCF-N SSCF SSCOP A L5 A A A L5 A L5 A IP SCCP SCCP Q2150.1 GTP-C GTP-U UDP Q2150.

UMTS Network Performance Engineering Page 80 of 106 .2. if call is in CELL_FACH state Might be asked to change state from HS-DSCH to DCH or vice versa For parameters configuring HSDPA see [16] section 9. NodeB B is becoming stronger and stronger UE sends Measurement Report with event id “1a” RNC adds NodeB B to the Active Set via Active Set Update procedure UE sending Measurement Report with event id “1d” RNC triggers Hard Handover via Transport Channel Reconfiguration or Radio Bearer Reconfiguration procedure UE sends Measurement Report with event id “1b” to remove NodeB A from the active set The optimisation approach when triggering event id “1d” is as follows: • HSDPA cell change should not be performed too late. when the UE has already moved 'far' into the area of another cell where it could have better throughput.15.2. • In ex-Lucent UTRAN for each UE a timer hSDPAMobilityTimer is defined tracking the number of cell changes in a certain time frame. In this case it is up to the higher layer protocols (RLC or TCP) to retransmit lost data. As a consequence too many serving HS-DSCH Cell Changes within a short period of time (Ping-Pong handovers) may cause a reduced throughput due to loss of data. A typically scenario might look as follows: • • • • • • UE connected to NodeB A.1 Date: 2007-06-08 6. The algorithms are proprietary and depend on the infrastructure vendor. In case of a Hard Handover the NodeB discards data that has been not been transmitted yet.15. 1b and 1c) For the DL the HS-DSCH for a given UE belongs to only one of the radio links of one sector of the NodeB where the UL is connected. the call is changed from HS-DSCH to DCH. • The mobility aspect of a HSDPA user is as follows: • The RNC is forwarding the DL application data to the NodeB from the MAC layer to the new MAC-hs layer that is scheduling the data for delivery. Mobility aspects of HSDPA Concept For the UL the mobility procedures are largely mostly the same as for PS calls over DCH (e. so that it immediately changes back to the previous cell if the radio conditions vary (Ping-Pong effect). As a consequence only Hard Handovers (Cell Changes) are triggered 6.2.03 Rev: 2.1.Document name: UMTS RF Troubleshooting Guideline U04. If this number exceeds an unusual amount of serving cell changes. HSDPA Hard Handovers should not be executed too early. soft/softer HO triggered via event 1a. Depending on the status of this timer the UE • • Might setup the call either on DCH or HS-DSCH. The number of HS-DSCH Hard Handovers is tracked by the UTRAN.g.

Finally during the Hard Handover there might be major transmission gaps including TCP retransmission. Failure symptoms. the timing when the RNC stops forwarding data towards the old NodeB. in particular Ping-Ponging effects. identification and fixes for improvement HSDPA performance degradations due to mobility issues can be best observed by analysing drive test data.2.2.03 Rev: 2.1 Date: 2007-06-08 6.Document name: UMTS RF Troubleshooting Guideline U04. in this case the throughput will decrease or even the call may drop. It is very important to avoid unnecessary Hard Handovers. Figure 28 below shows an example cross-correlated by Actix [29]. in the upper left part of the picture the RRC protocol is shown. as a result the benefits from HSDPA will not be available to that particular UE.g. The reason might be synchronisation problems or not optimal timing during the handover procedure e. the lower left picture shows the TCP SQN recorded at the client site by Ethereal: Figure 28: Hard handover problems identified by cross-correlated RRC and TCP data Table 57 below is listing the identification techniques for HSDPA mobility problems: Problem HSDPA ping-pong Trace Uu Trigger There are two consecutive Transport Channel Reconfiguration / Radio Bearer Reconfiguration procedures within x seconds UMTS Network Performance Engineering Page 81 of 106 .15. This problem can be easily detected when correlating RRC with TCP/IP data. Furthermore non-optimal handover settings might cause unnecessary transitions from HS-DSCH to DCH. On the other hand the Hard Handover should not be triggered too late so that the UE is not served by a NodeB that is much worse compared to the best cell.

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

Again a strong correlation between both measures has been recorded as visualised in Figure 30: 1800 1600 1400 1200 1000 800 600 400 200 0 -20 -18 -16 -14 -12 -10 -8 -6 -4 App Fwd Throughput [kbps] Ec/No [dB] Figure 30: HSDPA .15. Furthermore for Ec/No values exceeding around –8 dB no throughput performance could be observed indicating again that the limiting factor is the UE capability (see also subsection 6.03 Rev: 2.4 for details).Document name: UMTS RF Troubleshooting Guideline U04.3. UMTS Network Performance Engineering Page 83 of 106 .throughput versus Ec/No for TCP download To be noted: the Ec/No is never exceeding (excluding single measurement samples) around –6 dB because the “No” term includes the HSDPA traffic of the user. 6.2.1 Date: 2007-06-08 1800 1600 App Fwd Throughput [kbps] 1400 1200 1000 800 600 400 200 0 0 5 10 15 20 25 CQI Figure 29: HSDPA .4). RF related issues – Ec/No For the same test case as described in previous subsection the HSDPA throughput versus Ec/No were analysed.15.throughput versus CQI for TCP download Note: when the CQI is exceeding 15 there is no obvious throughput improvement observed anymore because the UE capability of 12 is in this case the limiting factor (see also subsection 6.15.

1 Date: 2007-06-08 6. For UMTS Network Performance Engineering Page 84 of 106 . see also [14] and [16].15.1.15.2 Mbit/s to 14 Mbit/s at physical layer.Document name: UMTS RF Troubleshooting Guideline U04. Depending on the terminal type different maximum number of HS-DSCH codes. for more details see [16]. a good test method might be static automatic tests for a full day. As a consequence the maximum achievable throughput is terminal dependent and should be taken into consideration when analysing HSDPA UE traces.15. Capacity issues Because the HS-DSCH is a shared channel the throughput of one UE highly depends on the overall HSDPA traffic in the particular NodeB. Two cases can be differentiated: 6. For this event there is no corresponding PM counter available in ex-Lucent UTRAN. RF related issues – other optimisation problems For any other optimisation problems as neighbour list planning. 6. UE limitations HSDPA capable terminals with resulting peak data rates ranging from 1.3. 6. Capacity issues – sharing of the bandwidth When sharing the HSDPA bandwidth with other users the application throughput will not be optimal due to the fact that • • The bandwidth provided by the HS-DSCH is limited The bandwidth on the backhaul transport network is limited These kinds of capacity issues can be detected as follows: • Indirectly by execution of UE performance tests during the busy hour and a comparison to the non-busy hour (e.4.g.03 Rev: 2.2.3. access parameters or power control settings please take a look in the corresponding subsections of this guideline. As described in subsection 6. For ex-Lucent U04. By evaluation of PM counter statistic Evaluation of Iub traces • • 6. Capacity issues – HSDPA call cannot be established on a particular NodeB Failed establishment of HSDPA call on a NodeB can be due to Hard limits During call set up. Soft limits Each time when a UE tries to establish a HSDPA call on a new NodeB via a RadioBearerReconfiguration procedure DBC is checking the soft limitations.15.15. on Sunday or at the early morning).5.5. HSDPA hardware and processing resources are limited in the NodeB.0x the UCU-II hardware limitation (and default parameter setting) is 24.15.5.3 currently the UE is the limiting factor in case of optimal RF conditions. HS-DSCH serving cell change and transition from URA_PCH/CELL_FACH to CELL_DCH with HSDPA the number of active HSDPA users is checked on a cell level against the parameter maxHsdpaUsersPerCell. different maximum TBS or modulation schemes are supported.

6.1.1 Date: 2007-06-08 ex-Lucent UTRAN the corresponding parameter and algorithm configuring DBC are explained in [18].16.16. Figure 27 below is visualising the changes in the UMTS protocol stack in order to support HSUPA: Figure 31: HSUPA changes done to the Protocol Stack The following subsections are describing different aspects of HSUPA data call.03 does not support HSUPA over Iur boundary.2.g.2. The support of soft/softer HO means that the possibility of performance degradation is much less as compared to HSDPA. However 04. Introduction From UMTS Release 6 onwards HSUPA is supported in order to provide UMTS subscribers’ higher throughput rates in the uplink as well as better resource sharing in the UTRAN. Mobility aspects of HSUPA Concept In general the mobility procedures are the same as for PS calls over DCH (e.16.Document name: UMTS RF Troubleshooting Guideline U04.16. Consequently if all the radio legs are from drift RNC. And as such this cell change only involves changing the physical channels E-AGCH/E-RGCH to accommodate the new role of the cell.1. A timer is used to supervise the UMTS Network Performance Engineering Page 85 of 106 . HSDPA related PM counters are available in [16] section 11. the HSDPA/E-DCH call will be reconfigured to HSDPA/DCH state with a minimum data rate. • • The mobility aspect of a HSUPA user is as follows: In HSUPA serving cell is responsible for issuing absolute serving grants (AG) for the UE to send data. 6. Furthermore new UL MAC functionality has been split into RNC entity (MAC-es) and NodeB entity (MAC-e) respectively.03 Rev: 2. if HSDPA is configured in the DL. Call reliability – HSUPA/EDCH 6. 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 6. But in this release HSUPA is only supported in UL. soft/softer HO triggered via event 1a.

However in case of overload (on Uu or Iub) the scheduler will not honour the request and would most likely start downgrading the served and non-served UEs through absolute and relative grants respectively.16. identification and fixes for improvement Depending upon the initial E-DCH throughput.SuccServCellChangeEDCH / VS. reducing delay.ULDCH-HSDSCH_EDCH-HSDSCH Table 59: PM Counter/KPI for E-DCH Mobility 6. The scheduler is also responsible for the hybrid ARQ to ensure error-free delivery avoiding re-transmissions at higher layers. This scheduling grant takes the form of absolute (giving max uplink power that can be transmitted) or relative (stipulating change/no-change in power with respect to previous TTI).ReconfSucc. Problem HSUPA ping-pong along Iur Reduction in throughput during HO along Iur Trace Uu Trigger There are consecutive Transport Channel Reconfiguration / Radio Bearer Reconfiguration procedures within x seconds doing E-DCH ↔ DCH state changes frequently There is no subsequent Transport Channel Reconfiguration / Radio Bearer Reconfiguration procedure observed after the initial procedure that configured UL to DCH Uu Table 58: HSUPA HO related issues involving Iur Some relavent KPIs/Counters are given that deal with the handover aspect of HSUPA PM system UtranCell UtranCell Counter/KPI (VS.EDCH-HSDSCH_ULDCH-HSDSCH KPI Name / Description EDCH Serving Cell change Success rate Total number of successful reconfiguration E-DCH to DCH in UL with HSDPA in DL Total number of successful reconfiguration DCH to E-DCH in UL with HSDPA in DL UtranCell VS. If some of the radio legs go back to SRNC then there is possibility that bearer will never configure back up to E-DCH.2.1 Date: 2007-06-08 reconfiguration back to HSDPA/E-DCH state (only possible in SRNS relocation or when all radio legs handover back to SRNC) and an optimum value should avoid ping ponging between DCH and E-DCH states in case call stays around Iur boundary. However reconfiguration to DCH can also occur if there are cells involved which don’t support E-DCH or cells are fully loaded with maximum allowed number of E-DCH users or if UTRAN wants to activate compressed mode on the UE. the new DCH bearer throughput will be lower at application level.3. Hence it is important to ensure that UL target load and Iub links are setup correctly to give desired cell throughput.Document name: UMTS RF Troubleshooting Guideline U04.AttServCellChangeEDCH)*100 VS.03 Rev: 2. Furthermore the UL EDPCCH contains a “happy bit” that shows if the UE is satisfied with the UMTS Network Performance Engineering Page 86 of 106 .2. 6. However such situation will only occur if the user only moves along the Iur boundary.ReconfSucc.16. Failure symptoms. MAC/ RF related Issues The scheduling mechanism for EDCH involves UEs sending scheduling requests that are assigned resources by the MAC-e entity upon evaluation of a set of criteria.

various options for maximum number of UL codes. Capacity issues – sharing of the bandwidth When sharing the HSUPA bandwidth with other users the application throughput will not be optimal due to the fact that • • The bandwidth provided by the E-DPDCH is limited. 6. This can act as an indicator of how fairly each UE is being scheduled. see Figure 32 The bandwidth on the backhaul transport network is limited These kinds of capacity issues can be detected as follows: • • • Indirectly by execution of UE performance tests during the busy hour and a comparison to the non-busy hour By evaluation of PM counter statistics Evaluation of Iub traces Figure 32: User versus Cell throughput variation with increase in users UMTS Network Performance Engineering Page 87 of 106 .5. 6.16.1. minimum SF and TTI durations are supported.4.5.16. see also [14] and [17].7 Mbit/s to 5.Document name: UMTS RF Troubleshooting Guideline U04. 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. Under bad RF conditions the UE is likely to be transmitting at high power to reach the NodeB and hence will not have sufficient power available to send the data resulting in loss of throughput.16. Two cases can be differentiated: 6. UE Limitations HSUPA capable terminals have peak data rates ranging from 0.1 Date: 2007-06-08 current grant.03 Rev: 2. As a consequence the maximum achievable throughput is terminal dependent and should be taken into consideration when analysing HSUPA UE traces. Depending on the terminal type.7 Mbit/s at physical layer.

1) To direct to direct the UE into compressed mode • • • • In case of a change of the data rate first a Radio Link Reconfiguration on NBAP is executed following changes of the ATM resources on the Iub via ALCAP procedures. Currently PM system only records this failure if it happens during DCH to E-DCH reconfiguration.1.03 Rev: 2.16. And as a result the E-DCH call can be reconfigured to DCH if the corresponding HS-DSCH serving cell changes to the NodeB with UCU-II.2.17.17.Document name: UMTS RF Troubleshooting Guideline U04.g.5. PS traffic measurements triggered either by UE sending a Measurement Report 4a/4b or by the UTRAN monitoring the DL RLC buffer occupancy (subsection 7.1.7) or because of CongC (subsection 6.0x. default setting for this parameter is 30. Full set of HSUPA related PM counters are available in [17] section 11. E-DCH serving cell change and transition from URA_PCH/CELL_FACH/CELL_DCH to CELL_DCH with E-DCH the number of active HSUPA users is checked on a cell level against the parameter maxEdchUsersPerCell. 6. Capacity issues – HSUPA call cannot be established on a particular NodeB During call set up. The RB Reconfiguration or alternatively the Transport Channel Reconfiguration procedure might be initiated for several reasons: • In case of UE state transitions e. when going from CELL_DCH mode to CELL_FACH mode in case the inactivity timer expires (subsection 6.1 Date: 2007-06-08 6.1.15. HSUPA hardware and processing resources are limited in the NodeB. for more details see [17] section 5.3) Due to a high BLER in the DL indicated by Measurement Report 5a sent by the UE (subsection 7.17. The RNC is sending a RB Reconfiguration message/Transport Channel Reconfiguration on RRC and in case of a failure the UE is sending back the corresponding failure message. For ex-Lucent U04. 6. RB Reconfiguration / Transport Channel Reconfiguration failure Concept 6.5) Hard handover for HSDPA calls (subsection 6. Table 60 and Table 61 are listing the identification of RB Reconfiguration Failures in traces and in the PM system: UMTS Network Performance Engineering Page 88 of 106 .g.17. Failure symptoms.1.2.1.2) In case RNC requests the UE to change the RB due to e. identification and fixes for improvement Main reason for a failure in this procedure is that the UE is not supporting the requested new configuration. NodeB equipped with UCU-II does not support EDCH.2. Call reliability – miscellaneous failures 6.

2.RRC. Physical Channel Reconfiguration failures Concept 6. during inter-Frequency hard handover for DCH.12.RBReconfigAtt)*100 (VS.17.g.g.1. Relocation failures Concept IRAT-HO (subsection 6. in the subsection 6.03 Rev: 2.RRC. • • • The relocation procedure is used in case of The procedure is described in [9].10) Inter-RNC HO In case of a Cell Update on a new RNC 6. The SRNC sends a Relocation Required message on RANAP. Failure symptoms. UMTS Network Performance Engineering Page 89 of 106 .2.1. 6.Document name: UMTS RF Troubleshooting Guideline U04.TransChanReconfigSucc/ VS. The CN sends back the Relocation Command message (successful case) or Relocation Preparation Failure (unsuccessful case).3.17. The Physical Channel Reconfiguration procedure can be initiated by the UTRAN e.17.2.RBReconfigSucc/VS.TransChanReconfigAtt)*100 KPI Name / Description RadioBearerReconfiguration Success rate TransportChannelReconfiguration Success rate Table 61: PM KPIs identifying RB / Transportchannel Reconfiguration Failures 6.RRC.2. Upon receiving the Physical Channel Reconfiguration message the UE has to change its physical configuration as requested and is sending back a Physical Channel Reconfiguration Complete message (successful case) or Physical Channel Reconfiguration Failure (unsuccessful case).17.1 Date: 2007-06-08 Problem RB Reconfiguration failure Transport Channel Reconfiguration failures Trace Uu Uu Trigger Any occurrence of the RRC message RB Reconfiguration Failure Any occurrence of the RRC message Transport Channel Reconfiguration Failure Table 60: Identification of RB Reconfiguration Failures in traces PM system UtranCell and RNC UtranCell and RNC Counter / KPI (VS.RRC. 6. identification and fixes for improvement Table 62 is listing the identification of Physical Channel Reconfiguration Failures in traces: Problem Physical Channel Reconfiguration Failure Trace Uu Trigger Any occurrence of a Physical Channel Reconfiguration Failure message Table 62: Identification of Physical Channel Reconfiguration Failures PM counters pegging failures in the Physical Channel Reconfiguration procedures are listed in the corresponding subsections e.2.3.17.

In the second case upon receiving a Relocation Preparation Failure message from the 3G MSC. Table 64 is listing methods of how to identify relocation problems in interface traces: Problem Relocation Preparation Failure Relocation Cancel Trace Iu Iu Trigger Any occurrence of the RANAP message Relocation Preparation Failure 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: UMTS Network Performance Engineering Page 90 of 106 .1 Date: 2007-06-08 Table 63 below is listing parameters used for the relocation procedure: Parameter IRATHORelocGuardTimer RelocationGuardTimer Description This parameter configuring the IRAT-HO relocation guard timer. This means that the existing Iu-signalling connection can still be used for the call as the timer IRATHORelocGuardTimer is still running when RelocationGuardTimer expires. identification and fixes for improvement Failures of the relocation process occur most likely during the IRAT-HO process.g. This procedure enables the CN to initiate the release of the resources allocated during the Relocation Preparation procedure in the GSM network. The SRNC considers the UMTS to GSM handover as not possible at this point in time and keeps the existing radio connections established.03 Rev: 2. If the failure cause specified within the message is “Relocation Failure in Target CN/RNC or Target System” or “Relocation not supported in Target RNC or Target System” then SRNC repeats the Relocation Preparation procedure with the next suitable cell from the list of potential GSM target cells otherwise the SRNC considers the UMTS to GSM handover as not possible at this point in time.17.3.2. This parameter configuring the relocation guard timer.Document name: UMTS RF Troubleshooting Guideline U04. A failure is detected during the RANAP Relocation Preparation procedure (e. Failure symptoms. GSM handover resource allocation fails or the CN rejects the UMTS to GSM handover request) due to the following causes: • • Timer TRELOCprep expiry at the SRNC Relocation Preparation Failure In the first case the SRNC initiates the Relocation Cancel procedure at the Iu interface. the SRNC still maintains the call. Table 63: Parameter used for the relocation 6.

SuccEstabPSNoQueuing.PS.03 Rev: 2. In the 3GPP there are no failure messages defined for the NBAP Radio Link Deletion Request or the RANAP Iu Release Request. the only exception is that it is not initiated by an Iu Release Request.RAB.Document name: UMTS RF Troubleshooting Guideline U04.AttRelocPrepOutCS IRATHO.AttRelocPrepOutCS*100 VS. the normal release procedure is identical with this call handling.RelocUEInvol/ RAB.SuccEstabPSNoQueuing.PS*100 (IRATHO.CS.FailRelocPrepOutCS.AttRelocPrepOutCS*100 IRATHO.T_RELOCprep_exp/ IRATHO.17.PS. UMTS Network Performance Engineering Page 91 of 106 .RelocUEInvol / RAB.RelocUEInvol/CS RAB Success*100 VS.Drop.4.Drop.RAB.sum)/ IRATHO. The call handling is shown in Figure 11.Drop. but also when doing an IRAT HO from 3G to 2G.PS*100 KPI Name / Description CS RAB Drop Rate due to SRNS Relocation PS RAB Drop Rate due to SRNS Relocation Relocation preparation for CS UMTS to GSM HHO success rate Relocation preparation UMTS to GSM fail rate T Relocprep expiry PS RAB Drop Rate due to SRNS Relocation RNC UtranCell RNC Table 65: PM KPIs identifying relocation failures 6.RAB. Failures during the RAB and RL release procedure The release of the RAB and the RL is not only used when terminating the voice or data call.1 Date: 2007-06-08 PM system UtranCell UtranCell UtranCell Counter / KPI VS. In general failures are not expected to occur on this stage.FailRelocPrepOutCS.

7. as explained in subsection 6.Block Error Rate (BLER) For the different types of services like voice. The UL BLER is provided via the following formula on a per RNC basis. 7.DL Block Error Rate (BLER) analysis 7.1. statistics can be retrieved via the PM system (subsection 7. data and VT and a description of performance weaknesses and of how to overcome these issues. data and VT a specific BLER has to be maintained to guarantee a good call quality. this KPI can be only retrieved via UE logging: DL BLER = 100 * (NumRecBlocksErrDL / NumRecBlocksTotDL) The UL BLER is the percentage of corrupted blocks received by the Serving RNC (before frame selection) over the total number of blocks received (before frame selection).1. In case of data call the poor quality may cause throughput degradation or high ping delay times.03 Rev: 2. The DL closed loop power control can be split into two loops: DL outer and inner loop PC. non-optimal neighbouring definitions etc.1. The second part gives a definition of the Quality of Service (QoS) parameters for the different types of services like voice. In case of voice or VT call the quality degradation can be directly experienced during the conversation. In addition VT calls will result in a fragmented and interrupted video signal.Document name: UMTS RF Troubleshooting Guideline U04. High BLER can be observed in the UL or in the DL separately. Concept The DL closed loop power control is in charge to keep the DL BLER in a predefined range. The DL and UL Block Error Rate (BLER) are the KPIs providing an indication of the quality of the UMTS call from the user perspective. Call quality . BLER degradation occurs in case of pilot pollution.1. Call quality In this section those aspects are investigated that have a direct influence of the user perceived call quality.2): UL BLER = 100 * (NumTransBlockErrUL / NumTransBlockTotUL) High values of one or both of these KPIs indicate that the perceived quality of the call is poor. The DL and UL PC algorithms are there to control the BLER to a maximum. The reasons observing high BLER might be as follows: • • • Non-optimal PC settings The maximum NodeB or UE transmit power for the dedicated channels has been reached Power restrictions to avoid system overload In the following subsections the DL and UL BLER analysis is reflected in more detail.4.1. The DL BLER is the percentage of corrupted blocks over the total number of blocks received by the UE.1. Figure 33 below is showing the principle of the DL PC: UMTS Network Performance Engineering Page 92 of 106 .1. In the first part the BLER in the DL and UL is discussed.1 Date: 2007-06-08 7.

The UTRAN may or may not react on this Measurement Report. When the UE is in compressed mode higher SIR target values will be defined. The decision is based on the BLER and SIR measurements UE sends back in the UL via the DCCH.1. Table 67 is listing the triggers in interface traces: UMTS Network Performance Engineering Page 93 of 106 . The method on how to set SIR target in order to provide the requested BLER is not specified in the 3GPP standard.03 Rev: 2. This value should guarantee an optimal performance for the (voice or data) service based on the requested QoS parameters.2. Failure symptoms. as there is no power control during transmission gap. DL inner loop PC: The inner loop PC purpose is fast adaptation of the NodeB transmit power in order to achieve the targeted SIR ratio for the considered downlink radio channel. The TPCs the UE is sending to the NodeB is based on the comparison of the SIR estimation versus the SIR target.Document name: UMTS RF Troubleshooting Guideline U04. Furthermore the UE may send a Measurement Report “5a” in case the number of bad CRCs on a certain transport channel is exceeding a certain threshold specified by a previous Measurement Control message [6]. During the call the BLER target can be readjusted by the RNC.1 Date: 2007-06-08 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. However minimal UE performances in given RF conditions are specified in [13].1. identification and fixes for improvement The DL BLER is reported by any drive test system in Uu traces. The NodeB transmit power is limited to parameters given by the RNC on NBAP. The control loop runs autonomously in the UE with a maximum speed of 100Hz. the only elements involved in the inner loop power control are the UE and the NodeB. Because of the speed of the control loop (up to 1500 Hz). The DL outer loop PC in the UE defines a SIR target based on the BLER. 7.

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

Problem
High DL BLER in Uu NodeB Tx Pwr via RFCT Measurement Report 5a

Trace
Uu RFCT Uu

Trigger
DL BLER higher than x % for more than y seconds The NodeB transmit power is exceeding for service x more than y seconds z dBm. Any occurrence of a Measurement Report 5a sent by the UE

Table 66: Identification of high DL BLER in interface traces 7.1.2. UL Block Error Rate (BLER) analysis 7.1.2.1. Concept

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

Figure 34: UL outer loop power control If the UE is in soft/softer HO mode and a particular NodeB has more than one leg, the NodeB does frame selection in the NodeB(called “micro-diversity”). For frames coming from different NodeBs belonging to the same RNC the RNC is doing the frame selection (termed “macro-diversity”). In case the NodeBs

UMTS Network Performance Engineering

Page 94 of 106

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

belong to different RNCs the SRNC is doing the frame selection; the data is provided via the Iur interface. For each UL TB set the NodeB is performing a CRC check on PHY and adding a CRCI to the frame. In addition the quality of the link is estimated; the QE in each TB provides the results. The QE is vendor proprietary, different metrics might be used to derive it. The QE ranges from 0 to 255 (small QEs are indicating good quality). UL inner loop PC: The UL inner loop PC is adjusting the transmit power of the UE in order to achieve the provided SIR target. All NodeBs involved in the particular call are sending TPC commands with a rate of up to 1500 Hz. The TPC commands of the particular NodeBs can differ. In this case if only one of the NodeBs is sending a “power down” command, the UE will lower its transmit power by the defined power-down-step. In case there is no TPC at all the transmit power of the UE remains unchanged. More information including parameter can be found in [28]. 7.1.2.2. Failure symptoms, identification and fixes for improvement

Cells suffering with high UL BLER can be easily identified using data from the PM system. When doing drive testing high UL BLER can be identified by using the RFCT feature in parallel to tracking the KPIs as retrieved by the RNC. High UL BLER might cause a RLF in the UL and/or the drop of the call (see also subsection 6.1). Table 67 and Table 68 are listing the triggers in interface traces and the corresponding PM KPIs:

Problem
High UL BLER in RFCT High UE reached Bad CRCI Bad QE SIR exceeded target power

Trace
RFCT Uu Iub Iub Iub Iub

Trigger
UL BLER higher than x % for more than y seconds Any occurrence where the UE is sending with at least y dB UE power for more than x seconds18 More than x % of the CRCIs within y seconds have a CRCI equal to 1. More than x % of the QEs within y seconds have a QE more than y. The SIR target for service x is exceeding value y. Any occurrence where the UL SIR target is not updated for more than x seconds. This is an indication of failure in the UL that might lead to an UL RLF.

UL SIR target not updated

Table 67: Identification of high UL BLER in interface traces

PM system
RNC RNC

Counter / KPI
(VS.ULTransBlockErr.CSV.All / VS.ULTransBlock.CSV.All)*100 (VS.ULTransBlockErr.CSD / VS.ULTransBlock.CSD)*100

KPI Name / Description
UL BLER rate for All CSV AMR codec rates 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).

UMTS Network Performance Engineering

Page 95 of 106

Document name:

UMTS RF Troubleshooting Guideline U04.03
Rev: 2.1

Date:

2007-06-08

RNC

(VS.ULTransBlockErr.PS / VS.ULTransBlock.PS)*100

UL BLER rate for PS

Table 68: PM KPIs identifying BLER issues UL BLER measurements can also be retrieved via the ex-Lucent RF Call trace feature [22].

7.2.

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

7.2.1. QoS – general In this subsection general QoS KPIs are listed that are not linked to a particular service like voice, data or VT. These can act as trigger points for identifying non-optimal performance.

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

Counter / KPI
(1- NoCallAttwithNoNetworkDetected / NoAllCallAtt) * 100 NoUnsuccessfulAttachAtt / NoAllAttachAtt * 100 t_attach_complete – t_attach_request NoSuccessfullLU / NoAllLUAtt * 100 NoFailedSMSTasks / NoStartedSMSTasks * 100 NoFailedMMSTasks / NoStartedMMSTasks * 100 t_sms_delivered – t_sms_start t_mms_delivered – t_mms_start

Table 69: General QoS parameters measured on application level In ex-Lucent U04.03 QoS parameters as given in the PDP Context Activation Request message are used for the DBC feature, see also subsection 5.4.1 and [20] for details.

7.2.2. QoS – voice service Because of the uncorrelation of UMTS links it is necessary to measure the UL and DL voice quality separately. Using special drive test equipment provided by e.g. QVoice or SwissQual one can do this. This equipment is comparing the received voice samples with the transmitted voice samples. In that way the evaluation software can do a voice quality classification for both directions independently.

UMTS Network Performance Engineering

Page 96 of 106

0 to 4.2. Voice quality degradations like e. The initially assigned PS RB at the beginning of a PDP session depends on the UTRAN configuration. delay. for details see also ITU P. Concept There are different metrics available defining the QoS of data services like throughput. For the voice quality evaluation the Mean Opinion Score (MOS) is used.1 Date: 2007-06-08 Table 70 below is giving the QoS parameter for voice services.0 2.0 QoS value Poor Fair Good Excellent Table 70: QoS of voice services . Dedicated and common UTRAN resources can be dynamically assigned depending on traffic measurements or load.0.0 Above 4.Document name: UMTS RF Troubleshooting Guideline U04. jitter etc.MOS Table 71 below is listing the formulas to retrieve the QoS KPIs for voice: KPI Call completion success rate voice [%] Block call rate voice [%] Dropped calls voice [%] HandoverSuccess3G2G [%] HandoverSuccess2G3G [%] Call setup success rate voice [%] Good voice quality [%] Counter / KPI NoSuccCompletedCallsVoice / NoSuccSetupCallsVoice * 100 (NoSetupFailedCallsVoice .0 to 3.1. echo or voice delay are reflected by this measure.SetupFailedCallNoNetworkVoice) / NoCallAttVoice *100 NoDroppedCallsVoice / NoSuccSetupCallsVoice * 100 No3G2GHandoverSuccSeiz / No3G2GHandoverAtt * 100 No2G3G HandoverSuccSeiz / No2G3GHandoverAtt * 100 NoSuccCallSetupVoice / NoCallAttVoice * 100 NoVoiceSampleGoodExcellent / NoAllVoiceSamples * 100 Table 71: QoS of voice services – KPIs 7. The RB can be dynamically changed (or even the mobile is sent to idle mode/URA_PCH/CELL_PCH mode) depending on the data to be sent in the UL and/or DL.862. The CN can check the requested QoS profile with entries from the HLR.3. A good voice quality can be considered when the MOS is exceeding 3.g.3.800 and ITU P.2. For further discussion on the MOS performance of various AMR codec rates see [47]. Depending on the status of the RLC queue in the UE the mobile might send a Measurement Report “4a” (in case the transport channel traffic volume exceeds an absolute threshold) or Measurement Report “4b” (in case the transport channel traffic volume becomes smaller than an absolute UMTS Network Performance Engineering Page 97 of 106 . The CN makes these negotiated QoS parameters available to the UTRAN via the RAB Assignment Request [9]. The MOS is defined by the ITU and is ranging from 1 to 5. QoS – data services 7.03 Rev: 2. In the PDP Context Activation Request message the UE can optionaly request pre-defined QoS profiles as specified in [5].0 3. Mean Opinion Score (MOS) Below 2.

On the PPP link of the PS data session the TCP/IP header and data can be compressed resulting in a throughput increase.1 and 6.17. UDP.Document name: UMTS RF Troubleshooting Guideline U04. It might be that the application will re-start with codecs requiring lower bandwidth to fill the internal buffer again.13) Problems detected on the RLC layer e. In case of real time applications like video streaming or web radio the drop will be noticed by the user if the buffer of the application is emptied and no new data is received.1 and the remarks in the appendix of this document) Retransmission on TCP layer PPP/PDCP compression used/not-used. RLC retransmission or RLC resets (subsection 6.2. . After the new establishment of the RRC connection and the new establishment of the RAB the FTP session can be resumed in case the session has not timed out in between.4.1) TCP configuration like TCP window size or MSS (see subsection 6. the PPP compression is an available option in the PPP settings of the dial-up networking.2.g. The RNC may or may not react on this Measurement Report by doing a RB reconfiguration (see subsection 5. 7.14.03 Rev: 2.1 Date: 2007-06-08 threshold). In addition also the PDCP layer is providing header compression for e.g.1). TCP.5). retransmission on RLC etc. • • • • • • • • Failure symptoms. For most Microsoft platforms. identification and fixes for improvement UE state Chosen RB Reported failures of the transport network (subsection 6. RTP and IP header [40]. Another difference when describing the PS data user perceived QoS is that a drop of the RAB and RRC connection does not (necessarily) mean that the PDP Context is removed from the GGSN or the FTP session drops. For the user the drop of the RRC and RAB is visible by stalling of the FTP transfer for the particular timeframe and because of low throughput rates.g. delay due to non-optimal RLC queue.3. Simple FTP-download tests of files with the size of 1MB in the UMTS networks has shown that the throughput for zipped binary files is around 25% less compared with the ASCII files. The root cause for the non-optimal performance is ConC: UMTS Network Performance Engineering Page 98 of 106 .) One example of an (graphical) analysis is shown in Figure 35 below.14) Reported BLER in UL and/or DL (subsection 7. The throughput of a FTP transfer is measured by Ethereal [30] and visualised by tcptrace [31] is low. Furthermore a smaller RB can be assigned in case of overload estimations done by the RNC (subsection 6. Usage of zipped files/unzipped ASCII files For analysing low PS data performance the following has to be considered: The analysis should follow a top-down-approach: • • First the end-to-end data performance should be investigated Then delay measurements should be done indicating the source of the performance degradation (e.

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

As expected the delay is very small and don’t have a big impact on the overall delay. Figure 37: delay measured on the Gn interface Table 72 below is listing the identification triggers in network interface traces: UMTS Network Performance Engineering Page 100 of 106 .Document name: UMTS RF Troubleshooting Guideline U04. This trace was recorded using a Tektronix K12 protocol tracer.03 Rev: 2.1 Date: 2007-06-08 Figure 36: end-to-end delay of an ICMP ping For the same measurement the delay on the Gn interface were also measured as shown in Figure 37 below.

1 Date: 2007-06-08 Problem TCP reset TCP retransmission TCP SACKs Trace TCP TCP TCP Trigger Number of occurrences if the REST flag of the TCP options is set to TRUE. it does not layout the algorithm and calibration of the MOS and hence that remains vendor propriatry. is exLucent’s LVAT. For voice QoS parameter the metric of subsection 7.Document name: UMTS RF Troubleshooting Guideline U04.4.SetupFailedCallNoNetworkVT) / NoCallAttVT *100 NoDroppedCallsVT / NoSuccSetupCallsVT * 100 NoSuccCallSetupVT / NoCallAttVT * 100 Table 74: QoS of VT services – KPIs UMTS Network Performance Engineering Page 101 of 106 .03 Rev: 2. QoS – VT service For VT calls the QoS consists of voice and video quality. One Tool that can provide the quality assessment of the video samples. Statistic counted per TCP session Number of SACK. Although there is an ITU standard that defines the framework of video quality measurement [48]. Statistic counted per TCP session Table 72: Identification of QoS issues for data service Table 73 below is listing the data QoS parameter including the trigger points for identifying non-optimal performance: KPI PDP context activation failure [%] PDP context activation time [s] PDP context cut off rate [%] FTP cut off rate [%] FTP throughput [kbit/s] Ping delay [s] HTTP failures [%] RB Assignment Success Rate [%] Counter / KPI NoUnsuccessfulPDPActivation / NoPDPActivationAtt * 100 t_pdp_activation_complete – t_pdp_request NoPDPLosses / NoSuccessInitiatedPDP * 100 NoFTPLosses / NoSuccessStartedFTP * 100 UserDataTransferred [kbit] / (t_ftpend – t_ftpstart) RTT of a ICMP with a payload of 32 bytes NoSuccHTTPTasks / NoHTTPTasksStarted *100 NoSuccAssignedRB / NoRequestedRB * 100 Table 73: QoS of data services – KPIs 7. as a MOS value. Table 74 below is listing the formulas to retrieve the other QoS parameters for VT: KPI Call completion success rate VT [%] Block call rate VT [%] Dropped calls VT [%] Call setup success rate VT [%] Counter / KPI NoSuccCompletedCallsVT / NoSuccSetupCallsVT * 100 (NoSetupFailedCallsVT .2. Statistic counted per TCP session Number of occurrences of TCP retransmissions.2.2 is used.

Measurement definition A. The voice test call sequence for the UMTS UE in the drive test van should be as follows: • • • • • • Network attach Mobile Originating Call (MOC). alternating speech sample from UE to the PLMN and vice versa. but can also be made with tools like 19 cygwin providing a full Linux command shell environment [38] . the advantage being the repeatability leading to ease of comparison and analysis. Network detach and pause of around 10 seconds Network attach Mobile Terminating Call (MTC). UMTS Network Performance Engineering Page 102 of 106 . duration 2 minutes.Document name: UMTS RF Troubleshooting Guideline U04. The data test call sequence should be as follows: • • • • • 19 Network attach and PDP context activation FTP download of three times 2 MB file. The FTP throughput should be measured in motion and in addition also stationary in case that there are some “Hot Spots” inside the UMTS cluster e. This can be achieved by defining a variable called FTP_CMD = “c:\winnt\system32\ftp. This will help the RF planner to analyse the failure and propose additional network changes. It is recommended to do testing via scripts. Network detach and pause of around 10 seconds The used drive test equipment should be capable of do generating this measurement sequence automatically.exe” in the scripts. alternating speech sample from the UE to the PLMN and vice versa. In parallel the RF conditions of the UE and the neighbouring cells should be recorded using the drive test tool and a 3G and 2G scanner in parallel. 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 The original DOS FTP client should be used instead the FTP client from cygwin (/usr/bin/ftp). Data scripts are supported by most of the drive test tools.1. Measurement definition – voice For voice services the UMTS UE in the drive test van should call an ISDN line in the PLMN because otherwise it is hard to distinguish if the first or the second mobile is responsible for observed failures or also for voice quality degradations. A. For security reasons a special test APN should be used. big hotels or airports. railway stations.2.03 Rev: 2. Measurement definition – data When doing KPI performance verification of data services the FTP server should be directly connected to the GGSN to avoid any latency and delay caused by the Internet.g.1 Date: 2007-06-08 Appendix A. duration 2 minutes.

1 Date: 2007-06-08 • • FTP upload of three times 1 MB file. UMTS Network Performance Engineering Page 103 of 106 .Document name: UMTS RF Troubleshooting Guideline U04. TCP window size of the sending entity should be large enough so the RLC queue in the RNC is not going into underrun. PDP context deactivation and pause of around 10 seconds For troubleshooting purposes it might be necessary to record the TCP/IP protocol analyser as Ethereal on both the UE and the FTP server side [30]. For measuring the maximum possible throughput on a radio link UDP shall be used because TCP retransmission might give an incorrect picture of the bandwidth capability. This will ease the identification of each single packet in Ethereal. For that reason it is helpful to measure the amount of “in-flight-packets” to calculate the right settings for the TCP window size. Table 75 below is listing the default TCP/IP parameter that should be used during the testing: Entity Client Server Feature SACK TCP window size PDCP compression PPP compression Starting MSS ICMP packet size MSS Setting Set to TRUE 35 kbyte Short description SACK allows the receiver to inform the sender about all segments that are successfully received The TCP window is the amount of outstanding data a sender can send before it gets an acknowledgment for the receiving entity When doing root cause analysis the feature should be disabled When doing root cause analysis the feature should be disabled The amount of TCP/IP packets sent by the sending entity at the beginning. 5 seconds pause in between Network detach. special prepared ASCII files shall be used.03 Rev: 2. For UNIX and Linux operating systems the settings can be set in the corresponding configuration files. The TCP configuration of the client PC and the server should be comparable with the settings most common used by “normal” UMTS subscribers and in the Internet. Gn and Gi there is no compression and ciphering used so using the particular tracing equipment can identify the ASCII payload. In case ciphering on RLC/MAC and data compression on PPP/PDCP are not used. Iub or Iu traces to detect retransmission on TCP or RLC. The settings can be set for Windows PCs in the registry or with help of shareware tools like [39]. Further packets will be send after reception of the first TCP ACK To measure the ICMP RTT an IP packet should be sent with the size of 40 byte (8 byte header plus 32 byte payload) The MSS should be 960 byte resulting in a MTU of 1000 byte (= MSS + 20 byte TCP header + 20 byte IP header). Note that on Iu. The actual TCP/IP packet size used might be smaller if Internet router is segmenting the packets Client/server Client/server Server Disable Disable 4 packets Client 40 byte Client/server 960 byte Table 75: Default TCP/IP parameter settings used for testing The TCP/IP settings can be verified using Ethereal. In parallel the RF conditions should be recorded.

Finally care should be taken that no other application on the PC are generating any unnecessary network traffic.03 Rev: 2.Document name: UMTS RF Troubleshooting Guideline U04.1 Date: 2007-06-08 The special ASCII files should contain only one (!) line and as an example the following sequence: “umts000000000umts000000001umts000000002umts000000003umts0000000 04umts000000005umts000000006 …” In case PPP data compression is on. zipped data shall be used to avoid irregular throughput measurements. Figure 38 below is showing a snapshot of the Ethereal protocol analyser: Figure 38: Ethereal protocol analyser UMTS Network Performance Engineering Page 104 of 106 .

GPS or also using a radio clock available in some European countries. Under no circumstances NTP should be used via an UMTS link because NTP is not designed for wireless network showing a high variance on the lower protocol layer like RLC. Pause of around 10 seconds Mobile Terminating Call (MTC). The measurement sequence should be the same as defined for voice calls except that a network attach/detach is not necessary because this is service independent. It has to be verified if the application running on the PC has to be restarted in order to retrieve the updated time. alternating speech sample from UE 1 to UE 2 and vice versa Pause of around 10 seconds. Figure 40 for doing VT testing in a lab. There are many possibilities to synchronise clocks of the particular measurement PC like NTP. duration 2 minutes. Time synchronisation of measurement traces When collecting traces from different interfaces it might be necessary to ensure rd time synchronisation to enable a 3 party software like Actix to do the crosscorrelation. B.Document name: UMTS RF Troubleshooting Guideline U04. UMTS Network Performance Engineering Page 105 of 106 .03 Rev: 2.1 Date: 2007-06-08 A. Figure 39 below is showing the measurement setup for analysing PS data services when doing drive testing in a van. alternating speech sample from UE 1 to UE 2 and vice versa. So the full measurement sequence for the VT should be as follows: • • • • Mobile Originating Call (MOC).3. One software that can be used for time synchronisation is Tardis2000 [32]. Furthermore it is possible to configure the Tardis2000 NTP client that it adjusts its internal clock within a predefined time frame. the other mobile should be stationary located close to a UMTS site outside the UMTS cluster under test. this will minimise possible failure causes for this second UE and help the RF planner at the root cause analysis. duration 2 minutes. It can be configured as a NTP server and NTP client or using GPS. Measurement definition – VT For VT one mobile should be located in the drive test van.

Document name: UMTS RF Troubleshooting Guideline U04.03 Rev: 2.1 Date: 2007-06-08 Figure 39: Measurement setup for PS data analysis in a van Uu (cabled) Stationary voice/VT evaluation drive test equipment 2nd mobile in shadowing box Uu (cabled) Iub Iu Mobile voice evaluation drive test equipment Fading simulator NodeB RNC CN UMTS protocol analyser Local NTP server Figure 40: Measurement setup for VT testing in the lab UMTS Network Performance Engineering Page 106 of 106 .

Sign up to vote on this title
UsefulNot useful