UMT IRC INF 012027 Performance Monitoring Guidelines V07.02 Preliminary

UTRAN PERFORMANCE MONITORING GUIDELINES
Document number:
UMT/IRC/INF/012027
Document issue:
V07.02/EN
Document status:
Preliminary
Date:
25/June/2010
Internal document - Not to be circulated outside Alcatel-Lucent
- UA7 -
Copyright 2008 Alcatel-Lucent, All Rights Reserved
ALCATEL-LUCENT CONFIDENTIAL:
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is write
protected; it may be altered only by authorized persons. While copies may be printed, it is not recommended.
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded
as uncontrolled copies.
ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of AlcatelLucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know, and shall
protect the information from disclosure and dissemination to third parties. Except as expressly authorized in
writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have
received this document in error, please notify the sender and destroy it immediately.
UA7 Performance Monitoring Guidelines
PUBLICATION HISTORY
25/June/2010
07.02/ EN, Status Preliminary
Updates of all sections done following comments received and posted on LL:
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=57969683&objAction=browse&sort=nam
e
Update of section 8.2 with information on new/modified UA7 accessibility indicators,
with 2 new sections on cell range monitoring and on paging performance monitoring,
with information on RL setup and RRC connection requests without UE repetition
monitoring in RRC connection monitoring section, add description of new RAB
accessibility views and metrics in RAB monitoring section,
Several Graphic views added in section 8.3 mainly on RRC Redirection and 3G3G
mobility monitoring, and also in section 8.3.3 on 3G2G mobility
Update of section 8.4 with information on new/modified UA7 retainability indicators;
add details on some VS_IuReleaseReqPs counter screenings.
In section 8.5, many new views description added for the detailed monitoring of traffic.
Addition of monitoring methods for several possible bottlenecks in UTRAN network in
section 8.6
Update of section 8.8 with a detailed list of available views for HSDPA view and a
status of some indicators
Update of section 8.9 with information on some HSUPA indicators
Update of section 8.10 with details on the monitoring of Preemption, always-on, RB
rate adaptation and IRM scheduling features.
7/March/2010
Update of sections 4, 5 and 6: add of UA7.1 information (mainly LL locations and
counter description)
Update of section 7 with UA7 information.
Update of section 8.2: add UA7.1 information; add of information on AT&T
accessibility KPIs; add an example of PS accessibility issue troubleshooting in 8.2.3;
add of section 8.2.4 on RB versus RAB counters.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 3/275

In section 8.3: adding of RRC Redirection mobility monitoring and 3G3G mobility
monitoring sections;
In section 8.4, update of the information on the Iu Release Request counter
screenings.
Update of section 8.5 : update of traffic monitoring views description ; add description
of new views; add UA7 information.
Update of monitoring views list in sections 8.6.
Update of monitoring views list and information on new added views in section 8.7 and
8.8.
Update of section 8.9 with a list of views useful to monitor HSUPA service and a list of
views to assess HSUPA features. Add of information on some HSUPA indicators
(warnings/restrictions).
Update of section 8.10 with new features monitoring families introduced in the detailed
monitoring dictionary for UA7 features assessment.
28/June/2009
06.03/ EN, Status Standard
Update after review.
Add of section 8.3.2.3 on the decrease of cell update success rate observed between
UA05 and UA06.
Add a note in section 8.3.2.3 on the potential impact of UA06 pre-emption feature
activation on the RL reconfiguration success rate.
Update of the troubleshooting sections: 7.3 (troubleshooting dictionary), 8.2.3
Accessibility troubleshooting) 8.3.3 (Mobility troubleshooting), 8.4.3 (Retainability
troubleshooting), 8.5.2 Traffic troubleshooting. Patrice Doulin
9/June/2009
Update of chapter 4 on NPO basics. Pedro Martins
Add of chapter 5 on counters, indicators and dictionaries and of chapter 6 on
indicators consolidation. Pedro Martins.
Add of chapter 7 on views and reports dictionaries. Update of monitoring and
performance analysis part (chapter 8) with a new organisation by monitoring domain.
Fabienne Roosen.
Add of section 8.4.2.2 on VS.IuReleaseReqPs counter screenings. Pedro Martins.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 4/275

Add of a section on NPO QOS Alerter in chapter 9. Amira Saafan.
18/Feb/2009
06.01/ EN, Status Draft
Update of detailed monitoring sections. Add of detailed dashboard views description in
section 5.3. Fabienne Roosen.
First draft of KPIs troubleshooting views (section 5.5). Patrice Doulin.
Add of an example of diagnosis reports (section 5.7). Pedro Martins.
19/Nov/2008
06.01/ EN, Status Draft
Description of detailed dashboard views has been completed. Pedro Martins.
Update of the document structure. Add of sections on detailed monitoring, KPIs
troubleshooting and diagnosis.
21/July/2008
06.01/ EN, Status Draft. Pedro Martins
Reorganization of document, following new structure of document deliverables in
UA06.
Rewriting of performance analysis chapters taking into consideration introduction of
NPO in the monitoring process.
24/September/2007
05.03/ EN, Status Standard. Updates after DR5.
Post-upgrade monitoring chapter
Panel update (excel file)
Links
Threshold determination table
02/April/2007
05.02 / EN, Status Preliminary. Review updates.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 5/275

15/March/2007
05.01 / EN, Status Preliminary
Panel updates for 5.0
Performance Analysis:
Restructuring of performance report chapter to improve clearness
Thresholds updated based on UA4.2 assessment
Panel chart updates
Some capacity links. Note that capacity chapter is only updated in terms of
capacity monitoring panel (see xls) but not troubleshooting charts
5.0 call trace updates
Acronymous list added
Nortel references removed
10/July/2006
Issue 04.22 / EN, Status Standard Gloria Alvarez., Eric Juillot, Florence Holodiuk,
Olivier Pinelli, Habib El Kadhir , Aaron Partouche.
Document review
23/June/2006
Draft 04.21 / EN, Status Standard Gloria Alvarez., Eric Juillot, Florence Holodiuk,
Olivier Pinelli, Habib El Kadhir , Aaron Partouche.
Document update for ChR 4.2.
UMT/IRC/INF/012027
Update in call profile according to 4.2 validation
Update in panel report after VO period to include and remove metrics
Update in post upgrade monitoring
Update in livelinks: ie, documentation, status after VO, etc
Update is monitoring panels to include links to feature monitoring guidelines

and HSDPA assessment introduction guides
07.02 /EN
Preliminary
25/June/2010
Page 6/275
Update in troubleshooting panels & charts
Update in capacity monitoring methodology
23/January/2006
Issue 04.20/ EN, Status Standard Gloria Alvarez., Eric Juillot, Florence Holodiuk, ,
Aaron Partouche, Olivier Pinelli.
Document update for CuR 4.2.
Panel report Updates with 4.2 metrics
Troubleshooting chart updates
20/December/2005
Issue 04.12 / EN, Status Standard Gloria Alvarez., Eric Juillot, Florence Holodiuk, ,
Aaron Partouche.
Document update for ChR 4.1.
Update in threshold determination methodology.
Update in call profile calculation according to 4.1 execution.
Update in metric reports after VO period.
Troubleshooting example: CELL FACH issues
Table and Figure numbering
Resource panel
22/June/2005
Issue 04.11 / EN, Status Preliminary Gloria Alvarez., Eric Juillot, Florence Holodiuk, ,
Aaron Partouche.
Document update for 4.1
11/March/2005
Issue 04.03 / EN, Status Preliminary Gloria Alvarez.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 7/275

Introduction of metric/counter ids for the metric used in the reports.
Update of some troubleshooting analysis.
3/Feb/2005
Issue 04.02 / EN, Status Preliminary (Gloria Alvarez, Florence Holodiuk, Jean Charles
Monceau, Olivier Pinelli, Philippe Deprez, Aaron Partouche, Arnaud Piazza).
New document structure.
Documents update after VO 4.0 tests.
Addition of:
A capacity and blocking analysis chapter. Aaron Partouche, Florin Iordache, Eric
Juillot.
Metric thresholds for investigation
Several troubleshooting cases based on field experience.
New predefine reports for RF Audits and 3G 2G troubleshooting.
RNC panel, Capacity panel and Call Profile panel
Update from the cases opened.

Update with the new metrics from ALCATEL-LUCENTs experience and studies.
30/Jul/2004
Issue 04.01 / EN, Status Draft
Documents creation (Gloria Alvarez, Florence Holodiuk, Jean Charles Monceau,
Olivier Pinelli, Philippe Deprez).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 8/275
CONTENTS
1.
INTRODUCTION............................................................................................... 13
1.1.
OBJECTIVE ................................................................................................. 13
1.2.
AUDIENCE FOR THIS DOCUMENT ................................................................... 13
2.
REFERENCE DOCUMENTS ............................................................................ 14
3.
PERFORMANCE MONITORING OVERVIEW.................................................. 15
4.
3.1.
PERFORMANCE MONITORING OBJECTIVES .................................................... 15
3.2.
MONITORING PROCESS ............................................................................... 15
3.3.
AVAILABLE TOOLS ........................................................................................ 16
NPO BASICS .................................................................................................... 17

4.1.
PRESENTATION ........................................................................................... 17
4.2.
USER INTERFACE ........................................................................................ 19
4.2.1 Analysis Desktop .................................................................................. 19
4.2.2 Indicator, View and Report Editors ....................................................... 21
5.
COUNTERS, INDICATORS AND DICTIONARIES .......................................... 24

5.1.
COUNTERS ................................................................................................. 24
5.1.1 Counters in NPO................................................................................... 24
5.1.2 Global Market and AT&T Counters ....................................................... 24
5.1.3 Counter Activation in RNC .................................................................... 25
5.2.
INDICATORS ................................................................................................ 25
5.2.1 Indicator Types ..................................................................................... 25
5.2.1.1
5.2.1.2
5.2.1.3
5.2.1.4
5.2.1.5
5.2.1.6
5.2.1.7
5.2.2
5.2.3
5.3.
6.
Stored Indicators.................................................................................................................. 26
Calculated Indicators ........................................................................................................... 27
Basic Indicators ................................................................................................................... 29
Baseline Indicators .............................................................................................................. 30
Extended Indicators ............................................................................................................. 30
System Indicators ................................................................................................................ 31
Customer Indicators ............................................................................................................. 31
Indicator Attributes ................................................................................ 31

USA Market Indicators and Contractual AT&T Indicators ..................... 34
DICTIONARIES ............................................................................................. 34
INDICATORS CONSOLIDATION ..................................................................... 36

6.1.
NORMALISATION.......................................................................................... 36
6.1.1 Retrieve and Ordering of Raw Data ...................................................... 38
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 9/275
6.1.2
6.1.3
6.1.4
Synchronisation with Display Period ..................................................... 38

Interpolation of Missing Data ................................................................ 38
Consolidation to the Requested Normalized Period Size ..................... 39
6.2.
AGGREGATION ............................................................................................ 40
6.2.1 Spatial and Temporal Aggregation ....................................................... 40
6.2.2 Busy Hour Indicators ............................................................................ 42
6.2.2.1
6.2.2.2
7.
How to Create Busy Hour Indicators in NPO ....................................................................... 42

Busy Hour Indicators in System Dictionaries ....................................................................... 44
VIEWS AND REPORTS DICTIONARIES ......................................................... 45

7.1.
DASHBOARD DICTIONARY ............................................................................ 45
7.1.1 Overview ............................................................................................... 45
7.1.2 Monitoring level and usage ................................................................... 46
7.2.
DETAILED MONITORING DICTIONARY .............................................................. 47
7.2.1 Overview ............................................................................................... 47
7.3.
TROUBLESHOOTING DICTIONARY .................................................................. 49
7.3.1 Overview ............................................................................................... 49
8.
MONITORING AND PERFORMANCE ANALYSIS .......................................... 51

8.1.
GLOBAL PERFORMANCE MONITORING ............................................................ 51
8.2.
ACCESSIBILITY MONITORING AND TROUBLESHOOTING ..................................... 52
8.2.1 High level of accessibility monitoring .................................................... 52
8.2.1.1
8.2.2
8.2.2.1
8.2.2.2
8.2.2.3
8.2.2.4
8.2.2.5
8.2.3
8.2.4
Global accessibility views .................................................................................................... 53
Detailed accessibility monitoring ........................................................... 64

Cell Range monitoring ......................................................................................................... 65
Paging performance monitoring ........................................................................................... 66
RRC connection monitoring ................................................................................................. 72
Iu SCCP connection phase monitoring ................................................................................ 84
RAB establishment phase monitoring .................................................................................. 84
Accessibility troubleshooting ................................................................. 98

UA7 counter validation (accessibility part) .......................................... 102
8.2.4.1
Radio Bearer vs RAB Counters Assessment ..................................................................... 102
8.3.
MOBILITY MONITORING AND TROUBLESHOOTING .......................................... 105
8.3.1 RRC Redirection mobility monitoring .................................................. 105
8.3.1.1
8.3.2
8.3.2.1
8.3.2.2
8.3.2.3
8.3.2.4
8.3.3
Global 3G3G mobility views for compressed mode ........................................................... 111

Global 3G3G mobility views for Inter Frequency Intra RNC ............................................... 113
Global 3G3G mobility views for Inter Frequency Inter RNC ............................................... 117
Global 3G3G mobility views for Radio Bearer Reconfiguration.......................................... 119
High level of 3G2G mobility monitoring............................................... 120
8.3.3.1
8.3.4
Global RRC Redirection mobility views ............................................................................. 106
3G3G mobility monitoring ................................................................... 110
Global 3G2G mobility views ............................................................................................... 121
Detailed mobility monitoring ................................................................ 126
8.3.4.1
8.3.4.2
8.3.4.3
3G2G mobility detailed monitoring ..................................................................................... 127

Mobility detailed monitoring views ..................................................................................... 127
Decrease of cell update success rate between UA05 and UA06 ....................................... 130
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 10/275
8.3.5
Mobility troubleshooting ...................................................................... 131
8.3.5.1
3G-2G HHO troubleshooting.............................................................................................. 132
8.4.
RETAINABILITY MONITORING AND TROUBLESHOOTING .................................. 136
8.4.1 First level of retainability monitoring.................................................... 136
8.4.1.1
8.4.2
8.4.2.1
8.4.2.2
8.4.3
Global retainability views ................................................................................................... 136
Retainability detailed monitoring ......................................................... 140

Retainability detailed monitoring views .............................................................................. 141
Description of VS_IuReleaseReqPs counter screenings ................................................... 146
Retainability troubleshooting ............................................................... 168
8.5.
TRAFFIC MONITORING AND TROUBLESHOOTING ............................................ 170
8.5.1 First level of traffic monitoring ............................................................. 170
8.5.1.1
8.5.1.2
8.5.2
Detailed traffic monitoring ................................................................... 175
8.5.2.1
8.5.2.2
8.5.2.3
8.5.2.4
8.5.3
RNC dashboard traffic views ............................................................................................. 171

Cell dashboard traffic views ............................................................................................... 173
Gobal traffic monitoring ...................................................................................................... 175
CS and PS traffic monitoring.............................................................................................. 207
HSDPA traffic monitoring ................................................................................................... 207
HSUPA traffic monitoring views ......................................................................................... 209
Traffic troubleshooting ........................................................................ 211
8.6.
LOAD AND CAPACITY MONITORING AND TROUBLESHOOTING ........................... 212
8.6.1 Global Monitoring for Resource Usage ............................................... 213
8.6.1.1
8.6.1.2
8.6.1.3
8.6.1.4
8.6.1.5
8.6.1.6
8.6.2
BTS Channel Element Usage ............................................................................................ 214

Iub Interface Occupancy .................................................................................................... 222
DL Power Usage................................................................................................................ 226
OVSF Codes Utilization ..................................................................................................... 233
RNC CPU Utilization .......................................................................................................... 235
UL Load and RSSI ............................................................................................................. 237
Additional Load and Capacity detailed monitoring views .................... 241
8.7.
QUALITY MONITORING AND TROUBLESHOOTING ............................................ 241
8.7.1 Quality detailed monitoring views ....................................................... 242
8.7.2 Quality troubleshooting ....................................................................... 243
8.8.
HSDPA MONITORING AND TROUBLESHOOTING ............................................ 244
8.8.1 HSDPA detailed monitoring views/reports .......................................... 244
8.8.2 HSDPA indicators status .................................................................... 246
8.8.2.1
8.8.2.2
HSDPA throughput ............................................................................................................ 246

HSDPA Codes ................................................................................................................... 247
8.9.
HSUPA MONITORING AND TROUBLESHOOTING ............................................ 248
8.9.1 HSUPA detailed monitoring views/reports .......................................... 248
8.9.2 HSUPA indicators status .................................................................... 250
8.9.2.1
8.9.2.2
8.9.2.3
8.9.2.4
HSUPA counters................................................................................................................ 250

HSUPA retainability ........................................................................................................... 250
HSUPA Load and Capacity................................................................................................ 252
HSUPA Quality .................................................................................................................. 252
8.10. FEATURES MONITORING ............................................................................. 253

8.10.1
Features monitoring views ............................................................... 253
9.
ADVANCED NPO MONITORING FEATURES............................................... 261

9.1.
NPO QOS ALERTER ................................................................................. 261
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 11/275
9.1.1
9.1.2
9.1.3
9.1.4
Definitions ........................................................................................... 261

NPO alerts property (periodicity/validity) ............................................. 264
NPO Alerter Status ............................................................................. 264
NPO Alerter GUI ................................................................................. 265
9.2.
DIAGNOSIS SCENARIOS ............................................................................. 267
9.2.1 Description of Diagnosis Scenario ...................................................... 268
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 12/275
1.
INTRODUCTION
1.1.
OBJECTIVE
This document provides the main methods for performance monitoring in a UMTS network, based on
a set of NPO reports.
It applies to release UA07. Note that the metrics formulas and related information are release
dependent, but the workflow and guidelines are valid over several UMTS releases.
In addition to this document, UMTS RF Troubleshooting Guideline [R1] presents processes for QoS
analysis based on counters.
1.2.
AUDIENCE FOR THIS DOCUMENT
This document is internal and intended to TIS-FOA, ST Team and TIS-ONE team elements.
Pre-requisites to use this guideline are:
Knowledge of UMTS counters and metrics definition;
Understanding of basic procedures and operations in NPO.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 13/275
2.
REFERENCE DOCUMENTS
[R1] UMT/IRC/INF/026976
UMTS RF Troubleshooting Guidelines
[R2] UMT/IRC/DD/024681
UTRAN Baseline Performance Monitoring Indicators
[R3] UMT/OAM/APP/024030
UTRAN Extended Performance Monitoring Indicators
[R4] 3BK 21215 AAAA PCZZA Ed10c
NPO Administration Guide
[R5] 3BK 21216 AAAA PCZZA Ed10f
NPO User Guide
[R6] UMT/RNC/DD/022432
PM34211 Q01670755 PM Counters Convergence HLD/DD
[R7] UMT/OMC/DD/023896
Functional Note RNC Counter list management
[R8] 3BK 21314 AAAA PCZZA Ed07
NPO Diagnosis Development Guide
[R9] 3BK 11274 0174 DSZZA Ed02
MUSE M2 SWAD Diagnosis
[R10] 3BK 11274 0175 DSZZA
MUSE UIS Diagnosis Editor
[R11] NN-20500-028
Alcatel-Lucent 9300 W-CDMA Product Family Counters

Dictionary (customer documents: https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=50098859&objA
ction=browse&sort=name&viewType=3)
[R12]
Technical Note - feature 34648 RNC Counter Control and

Capacity Improvements
[R13]
FRS - feature 34436 RNC Counter Volume Control
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 14/275
3.
PERFORMANCE MONITORING OVERVIEW
3.1.
PERFORMANCE MONITORING OBJECTIVES
To guarantee good level of service to subscribers and to keep good network Qos performance over
the time, it is first necessary to periodically evaluate the network performances. This allows detecting
any degradation, bad spots or needed improvements in the network, and then to correct or improve
them.
Monitoring the quality of service regularly helps operators to determine what to improve in the network
and how to improve it.
3.2.
MONITORING PROCESS
Performance monitoring and reporting are based on a complete set of counters and indicators and are
performed at different levels (Network level, RNC level, cell level, etc.), for different time intervals
(busy hour, daily, weekly) and with different level of details. Some generic reports (RNC panel or
dashboard) will be executed daily or weekly at network or RNC level to give a global view of the
network or the monitored RNC behaviour and some reports will be more focus on a specific monitoring
domain and will be use at RNC or cell level for detailed monitoring and investigations when an issue
has been encountered.
In order to have a relevant monitoring, one month data with daily values could be needed to be sure of
the network behaviour and performances over the time. The behaviour of a network may vary a lot,
depending on the time of the day, the day of the week or of the month. So, to make sure that the
picture of the network is complete, data shall be taken every day over a long period. Some data could
also be captured at the times the network is the most demanded: daily data for busy hour can also
help in performance monitoring.
Network daily tracking of events (that contains any network configuration change software, hardware,
parameter changes) and network stability status is also needed to find and solve any bad
performances of the network.
The aim of monitoring is:
Provide global information of network behaviour
Detect the different problems, analyzing and correlating them with the rest of statistics in order
to fix problems encountered.
Monitor new features activated on a network in the scope of feature assessment activities
In case of a QoS issue, if a first analysis is not enough or some hypothesis has to be confirmed,
detailed investigation and troubleshooting are necessary. After issue analysis, description of the issue
and solutions or corrective actions proposed to solve the issue should be written to keep a trace of the
analysis: this can help for other investigations. A solution can be a new setting of some parameters or
a change in network configuration.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 15/275

When the corrective action has been implemented, monitoring on a long term period (one week)
allows to check that the problem has disappeared or that QoS has been improved and that the other
parts of the network have not been degraded by the correction.
3.3.
AVAILABLE TOOLS
Performance monitoring in UA7.1 is done using NPO (Network Performance Optimizer) tool that
allows to collect all needed data (counters, indicators, parameters and topology information) from the
different network elements in a centralized way and to generate views and reports that gather metrics
to monitor. NPO has some advanced features very useful for QoS monitoring:
QoS alerters allows to be immediately informed when some network elements do not fill predefined quality criteria;
Diagnosis scenarios can be launched to investigate a specific QoS issue or to check a

specific network object or a set of network objects.
Iub, Iu and Iur Interface traces and mobile traces may be needed to complete investigations and to
confirm analysis outputs based on KPIs detailed monitoring and troubleshooting.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 16/275
4.
NPO BASICS
From UA06 onwards, the main tool used for QoS follow-up is NPO (Network Performance
Optimisation).
When compared to the previous method based on PrOptima, a NPO based monitoring provides visible
advantages in several aspects:
Multi-release capability
o
Integration
o
Network Qos evaluation, monitoring, diagnosis, reporting and tuning integrated in a

single product
Field proven, intuitive and friendly user interface
Additional features
o
Roll up/drill down capability (direct access to aggregated information or to lower level
information)
Historic of network parameters (correlation between parameter changes and

performance) and usage of parameters as indicators (definition of configuration
dependent KPIs)
Improved export capability (dynamic export to Excel)
Circular analysis using Propagate function
Capacity
o
4.1.
Definition of indicators which provide results for several UTRAN releases, taking into
consideration counter evolutions
Target capacity of up to 50 000 cells
PRESENTATION
NPO provides a centralized monitoring of the network performance, which is accomplished by:
Using a data warehouse containing all data sources (indicators, parameters, topology)
collected from different OMC-Rs;
Incorporating consolidation processes to manipulate the data warehouse contents

(consolidation per hour, day, week, month and also on topology level);
The analysis desktop, composed of a graphical user interface that allows browsing data
from data warehouse, creating and displaying views and reports;
External interfaces that allow an external system to extract QoS information from NPO.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 17/275
Optimisation (NPO)
NPO Browser
Migration Facilities
Administration Facilities
Offline Tools
Analysis Desktop
Administration
User Interface
Diagnostic
Diagnostic Device
Device
Environment
Environment
Data
Data Warehouse
Warehouse
Consolidations
Platform
RNO/NPA
RNO/NPA
MAAT
Tomcat
External
External
Systems
Systems
EQL
Text
Mediations
Security
Generic Loader
Loading Plug-in
System and Utilities
OMC-R/RNP (data sources)
Generic Tuner
Tuning Plug-in
OMC-R (tuneable system)
Figure 4-1: NPO Logical Architecture
NPO collects periodical measurements from the network elements through the declared OMC-Rs. The
permanent network-wide QoS monitoring relies on the regular collection of the same performance
counters on all managed Network Elements. Raw measurements are stored in the NPO database.
Based on raw measurements, indicators are built and stored for up to two years. Calculated indicators
can later be defined, based on stored and/or other calculated indicators.
The indicators are consolidated in daily, weekly, and monthly values, and can be additionally
consolidated on a group of Network Elements. The indicators correspond to high level information
which can be directly managed by the operator and are defined by Alcatel-Lucent.
The user can select and launch any predefined or user-defined QoS report. NPO provides a powerful
dynamic graphical user interface which simplifies QoS report analysis. For specific needs where the
provided standard indicators are not appropriate, the operator can define via the Indicator Editor its
own indicators, called customer indicators.
The NPO operator can display the results in the form of reports containing both tables and graphs
(several indicators graphically displayed simultaneously). The customer can also customize reports,
for an easier adaptation to operator needs. Special functions allow identification of the worst or best
cells related to a QoS indicator, to get reports on the QoS evolution, and to compare the service
quality of different cells. Comparing QoS indicator values with predefined thresholds, the NPO ensures
rapid verification of the quality of service in each single cell.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 18/275
4.2.
USER INTERFACE
Just as for its predecessor A9156 RNO the user interface is a main asset of NPO. The user
interface is intuitive, allowing the optimizer to interact with the tool in a friendly and straightforward way.
The NPO user interface uses the latest graphical methods to provide a clear representation of any
kind of data. So-called gadgets are used to present objects (e.g. GSM or UMTS cells, QoS indicators,
logical parameters, ...) and sort data by different criteria. Gadgets are grouped into tabs according to
their use (e.g. selection of cells and parameters, or display of QoS indicators). Data is displayed in
tables or charts, and some facilities allow the user to quickly reorganize the user interface look.
4.2.1
Analysis Desktop
The following picture shows the main interface of the tool: the Analysis Desktop.
Figure 4-2: NPO Analysis Desktop Main Window
The user interface is based on an object-oriented design, all actions being accessible through
contextual menus. Depending on the selected objects, only the relevant commands are provided.
Most operations can be done through the drag-and-drop mechanism or with the help of menu bars
and toolbars.
Five main zones are defined in the Analysis Desktop, as seen in the picture below:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 19/275
Objects Zone The type of network object (cell, Node B, RNC, ) on which the analysis
will be done is defined in this window. The selection will define the available counters,
indicator, views and reports that will be available in the Indicators, Views and Reports Zone.
Network Elements Zone After selection of the object type, the list of network elements
will automatically be updated in this zone. If the user selects the analysis on cell level
(CELL3G) all the available cells will be shown, either in a complete list or divided according
to the network topology, meaning they will be separated per RNC. Drag and drop operations
between this window and the Objects Zone allow a fast selection of the network elements
within one specific object (for instance, filtering the cells within a RNC).
Indicators, Views and Reports Zone In this area the relevant counters, indicators, views
and reports can be selected for execution. In addition, the available rules and diagnosis can
be selected from here too.
Executed Views Zone This area is used to display the results of an executed view.
Executed Reports Zone The results of an executed report or diagnosis are shown in this
zone.
Objects
Zone
Network
Elements
Zone
Indicators,
Views and
Reports Zone
Executed
Reports Zone
Executed
Views Zone
Figure 4-3: Analysis Desktop Main Working Areas
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 20/275
4.2.2
Indicator, View and Report Editors
When the user needs to create or modify indicators according to his/her needs the Indicator Editor is
the interface to perform such operation, when the number of additions and modifications is limited.
The information to include in the several fields when defining an indicator is specified in the Indicator
Attributes section in the next chapter.
Figure 4-4: Indicator Editor
Note: Number of changes and Indicator Editor

When the number of changes is limited, the Indicator Editor should be used. However, in case
of a very large number of changes, the new/modified indicators should be imported using a
customer dictionary in XML format, using NPO import tool.
In order to fully benefit from NPO potential, in terms of graphical presentation of results, views and
reports should be created. The NPO user can save the views and reports as templates, so that the
same structure can be used to display the same information for a different network element or period.
A view template is a formal description of a graphical presentation of QoS indicator or parameter
values, and it is used when building a view. A view, displays these results in a tabular or graphical
way. View templates can be created and edit using the View Template Editor, accessible from the
Analysis Desktop main window.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 21/275

The information necessary to define a view template (besides the basic information like name, title,
description and family organisation) is the list of indicators to present within the view and the type of
preferred display. In case of graphical display, the user can select which indicators to show on the
chart and on which axis.
The View Template Editor window is presented below:
Figure 4-5: View Template Editor
A report template describes a sequence of tabular and graphical representations of a Qos indicator or
parameter values. It is mainly composed of one or more view templates and comment zones and it is
used to build a report. Report templates can be created and edited using the Report Template Editor,
accessible from the Analysis Desktop main window.
The information necessary to define a report template (besides the basic information like name, title,
description and family organisation) is the list of views to show.
The Report Template Editor window is presented in the figure below (please note that only views are
included in as the building blocks, on the right side of the window).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 22/275
Figure 4-6: Report Template Editor
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 23/275
5.
COUNTERS, INDICATORS AND DICTIONARIES
Counters and indicators are the basis for any process of performance monitoring and they are
managed within NPO by means of dictionaries.
5.1.
Counters
5.1.1
Counters in NPO
Counters are retrieved from network elements extracted from QoS files and used as building
blocks in the formation of indicators. Although being the basis for indicator construction, they are not
directly used in NPO (as described below) when executing views/reports.
When retrieving counter values in NPO, the counters are only available in the source network element
(for instance, RRC counters are available at CELL3G level, but not RNC level).
Counters #409
are available at
CELL3G level,
but not at RNC level
Figure 5-1: Counters Availability and Network Elements
5.1.2
Global Market and AT&T Counters
In order to ensure convergence of the Alcatel-Lucent RNC to the ex-Lucent RNC, new RNC
performance measurement counters were introduced, intended to fulfil the AT&T requirements.
Feature 34211 PM Counters Convergence (additional information available in [R6]) aims at covering
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 24/275

the identified gaps in terms of counters, giving a higher priority to the ones that are either contractually
committed or necessary to define major AT&T KPIs.
5.1.3
Counter Activation in RNC
The number of counters screening records supported by the RNC has continually been growing with
every UTRAN release. The main reasons for this growth are the introduction of new features and
functionalities, the introduction of new services, external requirements to have additional counters at
cell level and the increase of the number of cells handled by the RNC.
New mechanisms are provided by the system to ensure that the volume of configured counters
records does not exceed the RNC capacity limit, and to ease the configuration and the audit of the
counters to be collected by the RNC.
In UA06, feature 34436 RNC Counter Volume Control (please read [R13] for detailed information)
sets the limits for the maximum counter volume supported by the RNC9370. Feature 34266 RNC
Counter List Management (please read [R7] for more detailed information) allows the activation or
deactivation of counters at RNC level, saving RNC processing resources. Even if deactivated, the
counters will still appear in the 3GPP observation XML files produced by W-NMS, with NULL values.
In addition
IN UA07, this is complemented with feature 34648 RNC Counter Control and Capacity
Improvements (please read [R12] for detailed information), which introduces a mechanism to control
the reporting of PM counters on a screening basis. The RNC will thus collect and report only selected
screenings.
A list of counters which are recommended for monitoring and cover all the needs in terms of indicator
definitions has been defined and is stored in the following location:
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=51569291&objAction=browse&sort=name.
5.2.
Indicators
QoS monitoring in NPO is based on indicators. An indicator is computed from counter values, other
indicators or any other available values, such as radio parameters.
5.2.1
Indicator Types
Indicators can be divided in several groups as shown below (not all of them are mutually exclusive).
The ones highlighted in green are the most relevant to understand indicator definition in NPO.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 25/275
Visible Indicators
Reference Indicators
Basic Indicators
Session Indicators
Presentation Indicators
Calculated Indicators
Extended Indicators
Stored Indicators
Temporal Aggregation Indicators
System Indicators
Customer Indicators
Baseline Indicators
Reliability Indicators
Telecom Indicators
Figure 5-2: Indicator Types in NPO (most relevant in green)
5.2.1.1
Stored Indicators
Stored indicators, as the name itself states, are stored in the data warehouse and they are computed
at counters import. A counters formula is specified per release. In case of changes in the formulas,
those will be taken into account only for the new imported counters. Besides, when a new stored
indicator is defined in a dictionary, it will report data only for the period after dictionary import.
The most relevant aspect about the stored indicators is the way they are used to ensure multi-release
compatibility. As stated before, the indicators that are defined in NPO provide results for several
UTRAN releases, taking into consideration counter evolutions. That is done by defining counter
dependent formulas using the stored indicators.
Example: Definition of Indicator RRCConnectionFailures_RRC018_CR
In UA6.0, this indicator was defined using the following counter formula:
UC404_0 + UC404_1 + UC404_2 + UC404_3 + UC404_4 + UC404_5 + UC404_6 +
UC404_7 + UC404_8 + UC404_9 + UC404_10 + UC404_11 + UC404_12 + UC404_13 +
UC404_15
Counter #404 has two additional screenings in UA7.0, when compared to UA6.0 and one
screening removed in UA7.1, when compared to UA7.0. This screening is replaced by a new
counter.
ID
#0404
Name and Description
Modification
RRC.FailConnEstab Failed RRC connection

establishments by cause
Screenings added or
removed
Table 5-1: Counter for RRC Connection establishment failures in UA6.0, UA7.0 and UA7.1
ID
#0436
Name and Description
Modification
RRC.FailConnEstab.Unspecified.Sum Failed RRC

Connection establishments, rejected with cause 'Unspecified'
Screenings added or
removed
Table 5-2: Counter for RRC Connection establishment failures in UA6.0, UA7.0 and UA7.1
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 26/275

UA6.0 Screenings
UA7.0 Screenings
UA7.1 Screenings
TimeoutRepeat
TimeoutRepeat
TimeoutRepeat
DLCodeRsrc
DLCodeRsrc
DLCodeRsrc
DLPowRsrc
DLPowRsrc
DLPowRsrc
Unspec
Unspec
Unspec
RSSI
RSSI
RSSI
FACH_CAC_or_Unspec
FACH_CAC_or_Unspec
FACH_CAC_or_Unspec
Overload
Overload
Overload
3G2GRedirectEmergency
CAC
CAC
CAC
DCH_LackContext
DCH_LackContext
DCH_LackContext
10
FACH_LackContext
10
FACH_LackContext
10
FACH_LackContext
11
NoRespNodeB
11
NoRespNodeB
11
NoRespNodeB
12
CPNTI
12
CPNTI
12
CPNTI
13
UE_EcNo
13
UE_EcNo
13
UE_EcNo
14
Reselect
14
Reselect
14
Reselect
15
Filtered_RLS_CAC
15
Filtered_RLS_CAC
15
Filtered_RLS_CAC
16
RLSetupFail
16
RLSetupFail
17
3G2GRedirectCellLoad
17
3G2GRedirectCellLoad
Table 5-3: Screening Differences for AO Downsize Step1 Counters in UA5.x and UA6.0
In order to consider the new screenings in the formula, the expression for UA7.0 has been
modified (additional screenings, marked in green, included in the formula):
UC404_0 + UC404_1 + UC404_2 + UC404_3 + UC404_4 + UC404_5 + UC404_6 +
UC404_7 + UC404_8 + UC404_9 + UC404_10 + UC404_11 + UC404_12 + UC404_13 +
UC404_15 + UC404_16 + UC404_17
With the removal of screening 3 (marked in red in UA7.0 formula above) and the introduction of
new counter #0436 in UA7.1, the formula needs further change for this release:
UC404_0 + UC404_1 + UC404_2 + UC436 + UC404_4 + UC404_5 + UC404_6 +
UC404_7 + UC404_8 + UC404_9 + UC404_10 + UC404_11 + UC404_12 + UC404_13 +
UC404_15 + UC404_16 + UC404_17
The indicator is thus defined using counter formulas, each one valid per UTRAN release.
5.2.1.2
Calculated Indicators
Calculated indicators are used when the same formula is valid for all the releases. They are built from
basic, stored or other calculated indicators (counters are not directly used) and are not stored in the
data warehouse, meaning that the result provided by NPO is calculated when the request is done by
the user.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 27/275

The most widely used types of calculated indicators are the following:
Classical (without any particular aggregation);
With stored temporal aggregation.
Example: Difference in calculation for calculated indicators

An indicator generically defined as Call Drop Rate = Dropped Calls / Call Attempts is
calculated differently if is classical or if it has a stored temporal aggregation.
For a classical calculated indicator:
Call Drop Rate [hour] = Dropped Calls [hour] / Call Attempts [hour]
Call Drop Rate [day] = Dropped Calls [day] / Call Attempts [day]
Call Drop Rate [week] = Dropped Calls [week] / Call Attempts [week]
Call Drop Rate [month] = Dropped Calls [month] / Call Attempts [month]
For a calculated indicator with stored temporal aggregation, MAX for example:
Call Drop Rate [hour] = Dropped Calls [hour] / Call Attempts [hour]
Call Drop Rate [day] = Max all hours (Dropped Calls [hour] / Call Attempts [hour])
Call Drop Rate [week] = Max all days of the week (Dropped Calls [day] / Call Attempts [day])
Call Drop Rate [month] = Max all days of the month (Dropped Calls [day] / Call Attempts [day])
Note: Indicators calculating the number of hours in a day for which a specific condition
is fulfilled
One of the most common scenarios for using calculated indicators using a stored temporal
aggregation is the definition of indicators calculating the number of hours during a day when a
specific condition is fulfilled. In the Extended Indicators Dictionary, the following ones have
been defined:
HSDPA062 Number of hours with back pressure activity higher than a given percentage
HSDPA063 Number of hours with Iub HSDPA activity rate above a specific percentage
Iub006 Number of hours with average Iub load higher than a percentage
Iub007 Number of hours with maximum Iub load higher than a percentage
Traffic046 Number of hours with percentage of R99 DL traffic higher than a percentage
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 28/275

Traffic047 Number of hours with HSDPA bandwidth occupancy above a given
percentage
ULOAD011 Number of hours with minimum RSSI above a specific level (dBm)
ULOAD013 Number of hours with maximum UL Cell Load above a specific percentage
ULOAD014 Number of hours with average UL Cell Load above a specific percentage
ULOAD015 Number of hours when difference between average RTWP between main
and diversity branches is higher than 2dB
The definition of these indicators involves an IF statement in the (calculated) formula and the
definition of Indicator Group and temporal aggregation method.
5.2.1.3
Basic Indicators
A very important notion when using NPO is that the monitoring is based on indicators. This means that,
within NPO, the counters are not directly used. In fact, after successfully loading the contents of the
PM counter files, these are deleted from NPO and only kept in the OMC-R. The basic indicators are
generated directly from the counters, with a one-to-one mapping, hence dependent on the release.
Basic indicators are always stored in the data warehouse of NPO.
Although they are extracted directly from the counters, they are available not solely in the source
network element. Due to the spatial aggregation procedure (described in next chapter), they are also
available in network elements higher up in the hierarchy (for instance, RRC basic indicators are
available at CELL3G level, IUB level, RNC level and NETWORK level).
Basic indicators
available at CELL3G
and RNC (and IUB)
Figure 5-3: Basic Indicators Availability and Network Elements
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 29/275

Note: Executed views with counters
When executing a view using counters in NPO, in reality, the calculation is performed using the
associated basic indicator.
The full set of basic indicators is able to cope with all the releases handled by NPO (multi-release
dictionary) but when some screenings or counter names are modified from one release to the next, the
calculated indicators cant directly rely on basic indicators.
Example: Definition of Indicator AODownsizingStep2Success_AO013_C

If we compare the basic indicator formulas for this indicator, the differences are visible,
meaning that a single formula cant be used and a stored indicator must be used in the
definition.
UA5.x formula (screening in red not used in UA6.0 formula):
VS_DownsizingStep1Success_DchHsdpa + VS_DownsizingStep1Success_DchPsIb32 +
VS_DownsizingStep1Success_DchPsIb64 + VS_DownsizingStep1Success_DchPsIb128 +
VS_DownsizingStep1Success_DchPsIb256 + VS_DownsizingStep1Success_DchPsIb384.
UA6.0 formula (screenings in green not present in UA5.x formula):
VS_DownsizingStep1Success_DchOther + VS_DownsizingStep1Success_DchHsdpa +
VS_DownsizingStep1Success_DchPsLt64 + VS_DownsizingStep1Success_DchPsIb64 +
VS_DownsizingStep1Success_DchPsIb128 + VS_DownsizingStep1Success_DchPsIb256 +
VS_DownsizingStep1Success_DchPsIb384.
5.2.1.4
Baseline Indicators
The baseline indicators are used for basic network performance assessment and include stored and
calculated indicators. The starting bases for these indicators were the previous ones included in the
PrOptima libraries, which have been converted to multi-release indicators. Some other indicators were
also created, in order to increase the monitoring capabilities (split of Cs in voice, video and streaming,
or Ps in Release 99 and HSxPA). A total of 1706 baseline indicators are defined (version 03.08).
The UA7.1 indicators specification is stored in Livelink at the following location:
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=54504971&objAction=browse&sort=name&viewType=1.
5.2.1.5
Extended Indicators
The extended indicators also result from migration of previous PrOptima libraries (with a large number
of additions for increased monitoring potential) and complement the baseline indicators, providing the
capability of in-depth analysis of the network performance, including metrics for detailed feature
assessment. Extended indicators can be stored or calculated and may use baseline indicators in their
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 30/275

definition, but baseline indicators cant use extended indicators. A total of 1525 extended indicators
are defined (version 03.07).
The UA7.1 indicators specification is stored in Livelink at the following location:
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=54504971&objAction=browse&sort=name&viewType=1.
5.2.1.6
System Indicators
System indicators are delivered by Alcatel-Lucent and are not editable by the customer. Basic,
Baseline (as a default) and Extended (in specific cases) Indicator Dictionaries are delivered by AlcatelLucent as System Indicators. For more details on dictionaries please refer to the next chapter.
5.2.1.7
Customer Indicators
The customer indicators are created by the customer. As mentioned above, the operator may create
new indicators using the Indicator Editor window, accessible from the Analysis Desktop. These new
indicators will be included in the Customer Indicator Dictionary.
5.2.2
Indicator Attributes
The following information is necessary when defining indicators in NPO (corresponds to the
information included in the indicators specification):
Field
Reference Name
Description
Short name of the indicator. Must start with U. Maximum length of 26 characters.
Originally derived from PrOptima metric ID.
Long Name
Name of the indicator. Converted directly from PrOptima metric name.
Description
Explanation of the indicator behaviour (how it is incremented, triggering events).
Unit
Unit of the indicator.
Precision
Number of decimal places, when presenting the indicator.
Calculated Formula
Only used for calculated indicators, defined by a single formula, valid for all
releases, using other indicators (basic, stored or calculated).
Counters Formula UA5.0
Only used for stored indicators, to define a formula which is specific for a release
(UA5.0). Supplier and technology also specified.
Type
Numerical type of the indicator (always FLOAT).
Availability Domain
Network elements on which the indicator is valid (CELL3G, NODEB, RNC).
Consolidation Method
Normalization method. Only defined for stored indicators.
Indicator Group
Maximum length of 10 characters. Only defined for stored indicators (can be stored
temporal aggregations of calculated indicators).
Spatial Aggregation
UMT/IRC/INF/012027
Aggregation at spatial level. Only specified for stored indicators.
07.02 /EN
Preliminary
25/June/2010
Page 31/275

Field
Description
Aggregation at temporal level. Only specified for stored indicators (can be stored
Temporal Aggregation
temporal aggregations of calculated indicators).

Stored Temporal Aggregation
Aggregation at temporal level for calculated indicators, normally of type MAX (for
definition of reference indicators) or BHPos. New in UA7.1.
Reference indicator used for calculation of busy hour indicator. This implies stored
Busy Hour indicator
temporal aggregation of type BH. For the indicator using this reference. New in
UA7.1.
First and second interpolation methods. By default, no interpolation is used. Only
Interpolation Method
applicable to stored indicators.

Allows computing consolidation only for relevant hours. By default all hours are
Relevant Hour
used. Only applicable to stored indicators.

Flag indicating whether the quality is better when the value of the indicator is
UpperIsFault
higher (False) or lower (True) than the sensitivity thresholds.

Three alert thresholds defined, indicating QoS requirement levels (Yellow, Orange
High Sensitivity Thresholds
and Red) according to sensitivity level.

Medium Sensitivity Thresholds
Low Sensitivity Thresholds
Sampling Values
Defines minimum number of samples (sampling indicator) for each sensitivity

level).
Table 5-4: Information necessary to define an indicator
Note: Availability domain of calculated indicators

The availability domain of a calculated indicator is defined by the intersection of the availability
domains of all the indicators used in its formula.
Note: Iur indicators and NZ operator

Some counters are incremented when the reference cell of the connection is in the drift RNC
(IUR), which complement counters available at reference cell only (CELL3G). This means that
when defining RNC level indicators there are two contributions to be considered: one from the
cells within the RNC and another from the Iur.
When there is no interface between the RNCs, there is no value returned by the Iur counters. In
order to get values for the RNC indicator, the NZ operator must be used, which converts NULL
values to zero. This way, the Iur contribution is set to zero, which still allows valid results for
RNC level indicators (only the reference cell part is considered).
The NZ operation is only used in calculated formulas.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 32/275

Note: Indicator Groups and RNC level stored indicators
The indicator group is defined for stored indicators. It designates the table in the database
where they are stored and spatial aggregation path. An indicator group is defined according to
the following rules:
1) A group has only one source for a given release, where the source is a unique
combination of PM type, collecting network element and source network element;
2) All the indicator from the same group have the same spatial aggregation path;
3) An indicator group can include a maximum of 250 indicators.
The convention used in the Baseline and Extended indicators dictionaries is presented below:
Figure 5-4: Indicator Group Definition
The notion of indicator group, poses some challenges when defining RNC level indicators.
When defining a stored indicator, all the counters in the formula must have the same collecting
network object, which means they are associated to basic indicators that belong to the same
indicator group. As such, it is not possible to define a stored indicator for RNC, including both
CELL3G and IUR counters. It must be defined as calculated.
Example: Definition of IuAbnormalReleaseRequest_IU008_R_CsVoice
UA5.x formula: VS_IuAbnormalReleaseRequestCs_DlAsCnfCsSpeech +
VS_IuAbnormalReleaseRequestCs_DlAsCnfCsSpeech =
= UC572_2 + UC560_2
UA6.0 formula: VS_IuAbnormalReleaseRequestCs_DlAsCnfCsSpeechNbLrAmr +
VS_IuAbnormalReleaseRequestCs_DlAsCnfCsSpeechWbAmr +
VS_IuAbnormRelReqCsNrnc_DlAsCnfCsSpeechNbLrAmr +
VS_IuAbnormRelReqCsNrnc_DlAsCnfCsSpeechWbAmr =
= UC595_2 + UC595_3 + UC592_2 + UC592_3
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 33/275

The CELL3G counters (#572 and #595) do not have the same source network object as the
IUR counters (#560 and #592), so they cant coexist in the same stored formula. The RNC
indicator must be defined as a calculated indicator, as the sum of a CELL 3G stored indicator
and an IUR stored indicator.
5.2.3
USA Market Indicators and Contractual AT&T Indicators
When browsing through the list of available indicators, one will notice that some indicators have a very
similar name and their meaning is exactly the same. This is the case of indicators
CallSetupSuccessRate_CSSR005_R_Cs and CallSetupSuccessRateCS_CSSR006_R, for which
the naming does not specify the difference between them and on which cases they should be
applicable Global Market or USA Market.
To specify on which cases these indicators would be used, the Indicator Status sheet in the Indicator
Specification document includes two columns that identify the market for which these indicators are
applicable: Market and iBTS/oneBTS. After the globalization of AT&T counters (please refer to section
5.1.2) the indicators built solely on counters collected in RNC will provide a result in both environments.
iBTS indicators are only available for Global Market, while oneBTS indicators are applicable to AT&T.
A special case of USA Market indicators are the AT&T Contractual indicators, which can be identified
by looking at their description field (either using indicator properties in NPO, or in the Indicator
Description field in the Indicator Specification document) which includes the corresponding AT&T KPI
number.
5.3.
Dictionaries
NPO aims at being a generic solution for network performance optimisation, and part of this purpose is
achieved by using external files to take care of the list of indicators, parameters and objects. Those
configuration files are called Metadata. NPO Metadata is composed of several dictionaries. The
dictionary files are in XML format and allow customisation of the data warehouse according to the
operation needs. NPO relies on dictionaries to describe radio parameters, QoS counters and
indicators, reports and views templates.
By default, NPO is delivered to all the customers with the following dictionaries:
Counters A total of three dictionaries are included, one for each release NPO handles.
This dictionary is created by NPO team.
Basic Indicators One multi-release dictionary is included, containing references to the

counters dictionaries of the UTRAN releases dealt by this dictionary.
Baseline Indicators A single multi-release dictionary is delivered, which also includes

references to the counter dictionaries.
Views and Reports The Dashboard report dictionary is included by default with the NPO
delivery, containing views and reports for generic performance assessment (covering
accessibility, retainability, mobility and traffic). These views and reports use only Baseline
indicators.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 34/275

The following dictionaries are delivered with NPO package, but not installed by default. It is planned to
install them as part of a monitoring service. They have been installed for FOA customers, but should
be removed at the end of the FOA period.
Extended Indicators One multi-release dictionary containing references to the counters

dictionaries.
Views and Reports Detailed Monitoring report dictionary, containing views and reports for
thorough performance analysis on accessibility, retainability, mobility, traffic, quality,
HSDPA, HSUPA, load and capacity and features monitoring. Troubleshooting reports for
high detail investigation. Both Baseline and Extended indicators are used. These reports
dictionaries are customer dictionaries.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 35/275
6.
INDICATORS CONSOLIDATION
Indicator consolidation is used to normalise and aggregate QoS data within the data warehouse. The
processes of normalisation and aggregation only apply to stored indicators.
Every night, the data loaded during the day is consolidated. Weekly consolidation is done, by default,
each Monday at 1AM. Monthly consolidation is automatically performed on the first day of the month
at 1AM. Consolidation can also be manually performed at any desired time.
Qos
Counters
Files
DecodeRelease(Counter)
Release(Counter)
Stored
Indicators
Calculated
Indicators
(Indicator)
Object(Indicator)
Period(Indicator)
Figure 6-1: Consolidation Consists in Operations on the Stored Indicators within the Data Warehouse
As soon as consolidation is completed the data whose storage duration has expired is removed from
the data warehouse. By default, the storage period is:
6.1.
21 days for hourly data;
400 days for daily data;
58 weeks for weekly data;
25 months for monthly data.
Normalisation
Measurements can be reported with different periods and unsynchronised and can be lost for several
reasons, either normal network management or due to an incident in the procedure.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 36/275
Cell A
Cell B
1h
1h
h h h h h h h h h
Cell C
Cell D
Cell E
53m
1h
h h h h h h
2h
1h
2h
1h
1h
time
Figure 6-2: Different Measurement Reports
It is not possible to compare the different objects and the different measurements by directly using
those measurements. For that to be possible, normalisation is applied. It consists of adapting basic
indicator values for display purpose (normalized period) and indicator formula calculation or
aggregation. This is done by:
Retrieve and ordering of raw data;
Synchronisation with display period;
Interpolation of missing data;
Consolidation to the requested normalized period size.
Figure 6-3: Different Measurement Periods after Normalisation
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 37/275
6.1.1
Retrieve and Ordering of Raw Data
The measurements can arrive in the wrong order or with some delay. The aim of this procedure is to
provide time-sorted data to the next step in the normalization process.
Figure 6-4: Retrieve and Ordering of Raw Data
6.1.2
Synchronisation with Display Period
The aim of this step (also called alignment) is to divide all the periods that are covering two or more
display periods.
Figure 6-5: Synchronisation with Display Period
6.1.3
Interpolation of Missing Data
Interpolation is optional, and is used to fill in the intervals for which there are no measurements and
can be made in a single step or in two steps (using display periods, meaning that it is made first on the
partially available display periods and then on the full lost display periods).
Figure 6-6: Interpolation of Missing Data
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 38/275

There are six interpolation methods in NPO:
Linear (missing values are replaced by a linear interpolation between the previous known
value and the next known value);
Padding by zero (missing data is replaced by zero);
Linear padding (missing data replaced by a numerical value defined by the operator/user);
Only OK (only periods comprising all elementary results are taken into account, the other
periods are filled with NULL; allows seeing only periods for which all data was really
collected);
Extend (reuse of last value);
No interpolation (data blanks are not filled).
In the NPO dictionaries (basic, baseline and extended indicators), no interpolation is used, meaning
that consolidation is based strictly on collected data.
6.1.4
Consolidation to the Requested Normalized Period Size
A display period may contain several measurements (after interpolation). Consolidation of values
ensures a single value per display period.
Figure 6-7: Consolidation to Display Period
Several consolidation methods are supported, and the most common are MAX, MIN, AVG and SUM.
Example: Consolidation of 15min data

For counters generated every 15 minutes, an hourly value will be build using the four
measurements available, and it is defined by the consolidation method used.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 39/275
Measurement (0 14 min) = 10
Consolidation = MAX
Hourly Value = maximum {10, 0, 5 , 17} = 17
Consolidation = MIN
Hourly Value = minimum {10, 0, 5, 17} = 0
Consolidation = AVG
Hourly Value = average {10, 0, 5, 17} = 8
Consolidation = SUM
Hourly Value = sum {10, 0, 5, 17} = 32
Figure 6-8: Consolidation of 15 Minute Data in NPO
6.2.
Aggregation
The aggregation procedure is used to compute spatial or temporal aggregated values. It is only
performed for normalised data and aggregated data. It is never applied to raw measurements.
6.2.1
Spatial and Temporal Aggregation
In the spatial domain, it is used to compute the aggregated values for a network element higher up in
the hierarchy order, for instance from CELL3G level to IUB level and RNC level (following the spatial
aggregation path). For the temporal domain, it is used to calculate daily, weekly and monthly
aggregated data (to get hourly data, the normalisation process is used).
In NPO, temporal aggregation is always performed after spatial aggregation, meaning that daily values
for RNC are calculated from hourly RNC values and not daily cell level values, as shown in the picture
below.
Stored
Indicators
Cell
RNC
Hourly
Network
Hourly
Spatial
Aggregation
Normalization
Spatial
Aggregation
Temporal
Aggregation
Temporal
Aggregation
Daily
Temporal
Aggregation
Daily
Temporal
Aggregation
Temporal
Aggregation
Monthly
Hourly
Weekly
Monthly
Daily
Temporal
Aggregation
Weekly
Monthly
Weekly
Figure 6-9: Spatial and Temporal Aggregations in NPO
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 40/275

Note: RNC level, daily results for indicators counting the number of network elements
that fulfil a specific condition
The order on which NPO and PrOptima perform the aggregation is different. As stated above,
NPO always perform the spatial aggregation before computing the temporal aggregated values,
while PrOptima execute these operations in the reverse order. As such, some indicators wont
provide the same values, when comparing the two tools.
Taking for example, the case of indicator Cell010 number of cells which have been red at
least once (using MAX for temporal aggregation and SUM for spatial aggregation), it is clear
from the tables below that the PrOptima and NPO results are different.
00:00
01:00
02:00
03:00
04:00
Cell 1
Cell 2
Cell 3
RNC Result:
Table 6-1: PrOptima Aggregation Results

00:00
01:00
02:00
03:00
04:00
Cell 1
Cell 2
RNC
Cell 3
Result:
Table 6-2: NPO Aggregation Results
The difference lies in the fact that PrOptima first performs the temporal aggregation on the cell
up to daily level, and only then spatially aggregates on the RNC (at daily level), while NPO
performs the temporal aggregation on the cell at hourly level, then spatially aggregates on the
RNC (still hourly level) and aggregates temporally at daily level.
In order to obtain the same results in NPO as in PrOptima, the following indicators should be
used with objects zones (for which the aggregation order is the same as in PrOptima)
coincident with the RNC:
Board003 Number of BTS with CEM usage higher than 60%
Board004 Percentage of BTS with CEM usage above higher than 60%
UCell010 Number of cells that have been red at least once
UCell011 Percentage of cells that have been red at least once
UCell012 Number of cells with blocking rate higher than 2%
UCell013 Percentage of cells with blocking rate higher than 2%
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 41/275
6.2.2
Busy Hour Indicators
Different types of aggregation methods can be used, the same way as for consolidation. While for
spatial aggregation the most common methods are MAX, MIN, AVG and SUM (the same as for
consolidation), in the temporal domain a special aggregation type exists: the Busy Hour (BH).
The busy hour principle consists in retrieving the hourly value of an indicator (ex: call drop rate) when
the peak is observed for a reference indicator (ex: traffic measured in number of established RABs).
Figure 6-10: Definition of Busy Hour Indicator and Reference Indicator
6.2.2.1
How to Create Busy Hour Indicators in NPO
To create a busy hour indicator in NPO, the Indicator Editor should be used. The following steps
should be taken:
1) In NPO Indicator Editor, copy (or create) an indicator to be calculated at busy hour.
Figure 6-11: Step 1 when Creating BH Indicator
2) Define Reference and Long Name and clink on New Temporal Aggregation button.
(1)
(2)
(3)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 42/275

3) Select Stored
4) Select the temporal aggregation (busy hour), and define the reference indicator (can be
dragged and dropped from the indicator list on the right)
(1)
(2)
5) Type the reference extension to append to the original reference, long name and select the
indicator group
(2)
(1)
(3)
6) Apply the changes and close the Indicator Editor
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 43/275
The busy hour indicator will then be available on the following day, following the automatic
consolidation of the day.
When an indicator with BH aggregation is displayed with an hourly time dimension (or less than a
day), it takes the same value as the corresponding indicator with the standard aggregation. The busy
hour aggregation is only relevant with a daily time dimension, because the returned value, by
definition, is the one at the busiest hour of the day, as measured by the reference indicator.
If the reference indicator has the same value for several hours of the day, the first occurrence will be
considered the busy hour.
Note: NPO limitations when dealing with busy hour indicators
If a customer indicator uses a system indicator as a busy hour reference, then the reference
indicator must have a stored temporal aggregation of type MAX. If both busy hour and
reference indicators are customer indicators or system indicators, NPO will automatically create
a stored temporal aggregation (MAX) for the reference indicator.
This has the obvious limitation of preventing the usage of classical calculated indicators from a
system dictionary, for a customer creating busy hour indicators. Changing this constraint in
NPO is currently not foreseen in the near future.
The workaround for the customer will be creating a calculated indicator with the same formula
as the desired system indicator and then create a stored temporal aggregation.
6.2.2.2
Busy Hour Indicators in System Dictionaries
In UA7.1, several busy hour indicators have been defined in the system dictionaries, so that the user
may overcome the limitations when dealing with customer indicators, and also as an effort to include
indicators used in Benchmark and detailed Capacity Monitoring.
In NPO, they can be identified by their long name, which will have extensions _atBusyHour and
_atTrafficBusyHour. The reason for having two different nomenclatures is related to the reference
indicator that is used: busy hour indicators can have reference indicators for number of established
bearers (for instance, call drop rate for voice at the hour for which there are more voice calls
established) and traffic busy hour indicators can have reference indicators for RLC payload (for
instance Ps call drop rate at the hour for which the volume of RLC payload is at its maximum).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 44/275
7.
VIEWS AND REPORTS DICTIONARIES
The aim of this section is to give an overview of the structure and content of main dictionaries (views
and reports) used for monitoring on NPO. Monitoring views and reports have been gathered under
three main families (dashboard, detailed monitoring and KPI troubleshooting) according to the level of
details reported. Each family is associated to a different dictionary. The performance monitoring
process is based on the 3 following dictionaries of views and reports:
Dashboard
Dashboard level performance monitoring provides a generic assessment of the network performance,
and strictly uses baseline indicators. Dashboard views and reports are integrated in the NPO software
package.
Detailed monitoring
Detailed monitoring performance level provides a detailed analysis of the network performance: it
covers detailed RNC dashboard and feature monitoring and uses Baseline and Extended indicators. It
is planned to be installed as part of a monitoring service and is delivered separately from the NPO
software package
KPI Troubleshooting
KPIs troubleshooting level provides a set of main indicators for troubleshooting investigation and uses
Baseline and Extended indicators. It is planned to be installed as part of a monitoring service and is
delivered separately from the NPO software package.
7.1.
DASHBOARD DICTIONARY
The aim of this section is to give an overview of the structure and content of Dashboard dictionary
(views and reports) and to explain globally the usage of this dictionary for performance monitoring.
The detailed description of views is given in performance analysis section in the corresponding
monitoring domain,
7.1.1
Overview
The dashboard dictionary contains global views and reports. They can be used for a regular
monitoring of main KPIs to have a high level overview of the network performance. All views and
reports of this dictionary belong to the same family (named DASHBOARD). Views are organised in
several sub-family levels, sub-families at level1 corresponding to the main monitoring domains such
as accessibility or retainability. The sub-family2 level is used to separate CELL level views and RNC
level views. All dashboard views are used in Dashboard reports but some of them can be used in
detailed monitoring reports.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 45/275

Subfamily1 level
Subfamily2 level
Views
CELL
Rrc_Connection_Overview
RNC
Security_Mode_Command_Overview
Rnc_Call_Setup_Overview_Cs
Rnc_Call_Setup_Overview_Ps
CELL
Cell_3G2G_Mobility_Overview_Cs
Cell_3G2G_Mobility_Overview_Ps
RNC
Rnc_3G2G_Mobility_Overview_Cs
Rnc_3G2G_Mobility_Overview_Ps
CELL
Cell_Retainability_Overview_Cs
Cell_Retainability_Overview_Ps
RNC
Rnc_Retainability_Overview_Cs
Rnc_Retainability_Overview_Ps
CELL
Cell_Dl_Traffic_Overview
Cell_Ul_Traffic_Overview
RNC
Rnc_Dl_Traffic_Overview
Rnc_Ul_Traffic_Overview
ACCESSIBILITY
MOBILITY
RETAINABILITY
TRAFFIC
Table 7-1: Structure of dashboard views family
Dashboard reports are organised in 2 sub-families (CELL and RNC). Each subfamily contains one
report that allows to have a global overview of the network performance in terms of accessibility,
retainability, mobility and traffic at cell level or at RNC level:
Subfamily1 level
Report
Content
CELL
Cell_Dashboard
All CELL level dashboard views
RNC
Rnc_Dashboard
All RNC level dashboard views
Table 7-2: Structure of dashboard reports family.
The UA6 dashboard report dictionary (xml document) and the UA6 dashboard report definition (excel
https://wcdma-ll.app.alcateldocument)
are
stored
in
the
following
location:
lucent.com/livelink/livelink.exe?func=ll&objId=46403303&objAction=browse&sort=name&viewType=1.
There is no update for this dictionary in UA7. The UA6 dashboard report dictionary is used.
7.1.2
Monitoring level and usage
Dashboard views and reports are useful to have a global view of a RNC or a cell behaviour in terms of
accessibility, mobility, retainability and traffic over the considered period. Dashboard reports can be
executed for each day or for each hour of the monitoring period and give the evolution of main KPIs
over a period. These reports are mainly used as a starting point for detailed investigations or to keep a
high level overview of the network performance.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 46/275
7.2.
DETAILED MONITORING DICTIONARY
The aim of this section is to give an overview of the structure and content of Detailed Monitoring
dictionary (views and reports) and to explain globally what is the performance monitoring scope of this
dictionary.
7.2.1
Overview
The detailed monitoring dictionary contains a lot of detailed views and some example of reports more
commonly used for detailed performance analysis per monitoring domain. Detailed Monitoring views
display one or several indicators and/or parameter values on a specific field or feature in a graphical
form or in a tabular form for a defined object and period. Reports are composed of views mainly
available in the detailed monitoring dictionary but some reports can also use views from dashboard
dictionary such as the detailed dashboard reports (detailed version of the dashboard reports).
Views and reports are organised in several sub-family levels (see table below), sub-families at level1
corresponding to the main monitoring domains such as accessibility or retainability. The last level is
only used to separate views at CELL level and at RNC level.
Subfamily1 level
Subfamily2 level
Subfamily3 level
ACCESSIBILITY
CS
GLOBAL
HSDPA
HSUPA
IUX TRANSPORT
PS
CELL
RNC
FEATURES MONITORING
33331_ALARM_HHO_UETX
34227_ST_TRANS_ENHANCEMENT
34231_SHO_ENHANCEMENTS
34246_POWER_CONTROL_ENHANCEMENTS
34480 3G2G REDIRECTION BASED ON CELL LOAD
ALWAYS ON
AMR
COMPRESSED MODE HLS
DEFENSE MECHANISM FOR UES NOT SUPPORTING CM
WITH HSPA
DISTRIBUTION COUNTERS FOR BLER
DISTRIBUTION COUNTERS FOR RSCP AND ECNO
IMCTA
IP SYNCHRONIZATION
IRAT_ENH
IRM CAC
IRM SCHEDULING
PS CORE NETWORK REQUESTED RAB MODIFICATION
RB BIT RATE ADAPTATION
RRC QUICK REPEAT
RRC QUICK REPEAT FACH POWER ADJ
RRC REESTABLISHMENT
SIM_MC
SINGLE CALL CLEANUP
USER PERCEIVED THROUGHPUT COUNTERS
CELL
RNC
CODE USAGE
FAIR SHARING OF RESOURCES
GBR ON HSDPA
HSDPA PLUS
SCHEDULING
UE CATEGORY
CELL
RNC
FOA PANEL
HSDPA
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 47/275

Subfamily1 level
Subfamily2 level
Subfamily3 level
HSUPA
SRB ON EDCH
CELL
RNC
LOAD AND CAPACITY
CELL
IUX TRANSPORT
LOAD COLOR
RADIO
NODE B
POWER USAGE
RNC
TRANSPNODE
CELL
RNC
Subfamily3 level only
for RADIO and POWER
USAGE subfamilies
MOBILITY
CELL UPDATE
COMPRESSED MODE
HHO 3G2G
HHO 3G3G
HSDPA
HSUPA
PRIMARY CELL CHANGE
RELOCATIONS
SOFT HANDOVER
URA UPDATE
CELL
RNC
QUALITY
BLER
CS_SPEECH
DEDICATED MEASUREMENTS
HSDPA
HSUPA
IUX TRANSPORT
PS R99
CELL
RNC
NODEB (only for one
HSUPA view)
RETAINABILITY
CS
GLOBAL
HSDPA
HSUPA
PS
CELL
RNC
TRAFFIC
CS
GLOBAL
HSDPA
HSUPA
PS
CELL
RNC
Table 7-3: Structure of detailed monitoring views family.(with new UA7 families listed in bold text)
The detailed monitoring report definition excel document gives a complete list of all detailed monitoring
views and reports including in the detailed monitoring dictionary and is stored in the following location
for UA7.1:
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=56780279&objAction=browse&sort=name&viewType=1
7.2.2
Detailed monitoring views and reports are useful to have a detailed overview of RNC or cell behaviour
in one or several monitoring domain over the considered period.
Detailed Monitoring views are mainly used to make detailed investigations on the monitoring period
and allow completing information given by dashboard views on accessibility, retainability, traffic and
mobility aspects. For that purpose, the detailed monitoring dictionary covers the same monitoring
domains as the dashboard dictionary but with a large set of views and a lot of KPIs. It covers also
additional domains such as Load and Capacity domain with views that can be used, for example, to
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 48/275

analyse network load in terms of power or Quality domain that contains views to analyse the network
performance in terms of BLER or throughput. For each monitoring domain, more commonly used
views are detailed in Performance Analysis section.
Detailed monitoring views are also used for feature assessment: the Feature Monitoring subfamily
gathers views on UA06 features and new UA7.0 features and also on some specific features or
functions such as IMCTA. HSDPA and HSUPA subfamilies gather views on specific HSDPA/HSUPA
features as well as on some specific HSPA topic. A description of views used for features assessment
can be found in the corresponding FSM (all useful links on FSM are included in this document). For
these subfamilies some views are given as an example in Performance Analysis section.
Note: HSDPA/HSUPA views related to a generic monitoring domain such as accessibility or mobility
are classified under HSDPA or HSUPA subfamily of the concerned domain in the detailed monitoring
dictionary (ex views to monitor HSUPA mobility are under MOBILITY/HSUPA subfamily) but the
guidelines to monitor HSDPA and HSUPA performance are gathered in section 8.8 and 8.9 of this
document.
7.3.
TROUBLESHOOTING DICTIONARY
7.3.1
Overview
A troubleshooting report dictionary usually contains one report with one detailed view in a tabular form
including all indicators (basic, baseline and extended) required to do detailed investigation on a
specific item.
The Troubleshooting dictionary includes the following KPI Troubleshooting views families:
CSSR CS
CSSR PS
Call drop CS
Call drop PS
And the following troubleshooting reports:
Retainability_1
Mobility_1
Global_1
Mobility_2
Accessibility_2_RAB
Accessibility_1_RRC
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 49/275
The UA7.1 troubleshooting dictionary is available in XML format on Livelink at:

7.3.2
Troubleshooting monitoring views and reports are useful for deeper KPI issue analysis (for the
mentioned KPI family specified above) once the problem has been characterized thanks to Detail
monitoring and when affected services, affected network elements and affected period of time have
been identified.
Views are organised in several sub-family levels (see table below), sub-families at level1
corresponding to the main monitoring domains such as CSSR PS or Call Drop PS. The last level is
only used to separate views at CELL level and at RNC level.
SubFamily1
CSSR CS
CSSR PS
CALL DROP CS
CALL DROP PS
SubFamily2
RNC
CELL
RNC
CELL
RNC
CELL
RNC
CELL
Table 7-4: Structure of troubleshooting views family.
The troubleshooting monitoring report definition excel document gives a complete list of all
troubleshooting views and reports including in the troubleshooting dictionary (see ViewTemplate excel
sheet of the report definition document). For UA7.1, it has been stored in the following location:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 50/275
8.
MONITORING AND PERFORMANCE ANALYSIS
The aim of this chapter is to explain in details the performance monitoring process based on the
available dictionaries. The first section describes the role of high level reports in the monitoring
process. The following sections describe how to perform detailed investigations on a particular
monitoring domain and how to use the available dictionaries to analyze a problem. For each of these
sections, some views are presented in details starting from views with major KPIs to go on with
detailed monitoring views and troubleshooting views. The last section gives an overview of feature
views and reports available for features monitoring including new views introduced for UA7 features
assessment.
8.1.
GLOBAL PERFORMANCE MONITORING
Performance monitoring of a network is based on a top to bottom approach and starts with the
analysis of high level reports on the different network elements. These reports give a global view of
the network, of one RNC or of one cell or a cluster of cells. They allow highlighting the evolution of
main KPIs over a pre-defined period of time. They may lead to more detailed investigations in case of
KPIs degradations.
Examples of high level reports are available in the DASHBOARD dictionary but high level customer
reports may also be used to follow the performance evolution. For instance, a high level report at RNC
level such as Rnc_dashboard report allows to display the evolution of the RNCs performances over
several days or several weeks with hourly or daily values and allow to detect quickly any degradation
of the QOS. It is often the starting point of more detailed monitoring and performance analysis of a
specific domain. The following chart gives an example of the first steps of detailed investigations at
RNC level.
Rnc_dashboard report
Daily report over
several days
Degradation of Call
setup success rate
CS or PS or both ?
yes
Detailed Accessibility
Monitoring
Increase of Call drop

rate CS or PS or both ?
Degradation of 3G-2G
HHO success rate CS or
PS or both ?
yes
yes
Detailed Retainability
Monitoring
Detailed Mobility
Monitoring
UMT/IRC/INF/012027
07.02 /EN
Decrease of DL/UL RLC

payload for CS or PS or
both ?
yes
Detailed Traffic
Monitoring
Preliminary
25/June/2010
Page 51/275

Figure 8-1: First level of performance monitoring
8.2.
ACCESSIBILITY MONITORING AND TROUBLESHOOTING
8.2.1
High level of accessibility monitoring
The first level of accessibility monitoring consists in checking the main metrics of the different phases
of call establishment to detect if any issue occurs during these phases. The main phases of call
establishment are the RRC connection setup, the Iu SCCP connection establishment, the Security
Mode Command procedure and the RAB establishment procedure.
UE
Node B
MSC / SGSN
RNC
Paging if mobile terminated

RRC Connection Setup
SCCP Connection Establishment
Authentication
Security & Integrity
RAB Assignment
Figure 8-2: Accessibilty call flow
Accessibility monitoring usually starts with the checking of the Call Setup Success Rate metric (CSSR)
for CS and for PS calls. The CSSR is computed according to the following formula :
For example for PS calls, CSSR PS = First RRC success rate (PS calls only) * Iu PS SCCP success
rate * RAB establishment success rate Ps. The same formula is used for CS calls.
It provides an indication of the performance of the whole call setup procedure for PS or CS excluding
the Security procedure. The CSSR degradation may be explained by an issue in one or more of the
following procedures: the RRC establishment phase, the Iu SCCP connection and the RAB
establishment stage.
As the CSSR does not cover the Security Mode Command procedure, the metrics related to this
procedure should be also checked during accessibility monitoring.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 52/275

The figure below sums up the first steps of accessibility monitoring:
Accessibility Monitoring
RNC level
Decrease of Security
Mode Command
success rate ?
Degradation of Call
setup success rate ?
yes
yes
Degradation of RRC
connection success
rate ?
yes
RRC connection
Monitoring
Degradation of RAB
establishment success
Degradation of Iu SCCP
rate ?
connection success
rate ?
yes
Ciphering
Monitoring
yes
Iu SCCP Monitoring
RAB establishment
Monitoring
Figure 8-3: First steps of Accessibility monitoring
This level of monitoring can be performed at RNC level for both CS and PS with generic accessibility
views. These views are described below in section 8.2.1.1. Most of them are included in dashboard
dictionary but some are available in Detailed Monitoring dictionary.
8.2.1.1
Global accessibility views
These views allow checking the CSSR and the performance of the main phases of call establishment
in case of an accessibility issue. Results given by global views should be complemented with Detailed
Accessibility views for the different call setup phases mentioned above. Main detailed accessibility
views are described later in the document in section 8.2.2 in the corresponding detailed accessibility
monitoring section.
8.2.1.1.1 Call Setup checking

To start accessibility monitoring, the 2 views described below are very useful: they give an indication
of the performance of the whole call setup procedure for PS and for CS, from the RRC establishment
phase (not considering repetitions and for causes only related to calls) up to the RAB establishment
stage, including the Iu SCCP connection. In case of a degradation of call setup success, the first RRC
success rate, the Iu SCCP success rate and RAB establishment success rate for could be checked by
using views described in sections 8.2.1.1.2, 8.2.1.1.3 and 8.2.1.1.3.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 53/275

This view provides the CSSR and the volume of first RRC connection requests for PS calls at RNC
level and allows checking PS accessibility.
Figure 8-4: Display of View Rnc_Call_Setup_Overview_Ps
Name
Description
Overview of call setup procedure for Ps at RNC level.
Preferred Display Type
Graph
Families
DASHBOARD
ACCESSIBILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
FirstRRCConnectionRequest_RRC015_CR_Ps
Number of RRC connection requests for Ps

calls. Repetitions not taken into consideration.
Presented on primary axis.
CallSetupSuccessRate_CSSR005_R_Ps
Rate of successful Ps call establishment

versus Ps call establishment attempts. Results
of multiplication of First RRC Success Rate
(Ps calls only) per Iu SCCP success rate per
RAB establishment success rate. Presented
on secondary axis.
Table 8-1: Properties of View Rnc_Call_Setup_Overview_Ps
This view provides the CSSR and the volume of first RRC connection requests for CS calls at RNC
level and allows checking CS accessibility.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 54/275
Figure 8-5: Display of View Rnc_Call_Setup_Overview_Cs
Name
Description
Overview of call setup procedure for Cs at RNC level.
Graph
Families
DASHBOARD
ACCESSIBILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
FirstRRCConnectionRequest_RRC015_CR_Cs
Number of RRC connection requests for Cs

calls.First RRC Repetitions are not taken into
consideration. Presented on primary axis.
CallSetupSuccessRate_CSSR005_R_Cs
Rate of successful Cs call establishment

versus Cs call establishment attempts. Results
of multiplication of First RRC Success Rate
(Cs calls only) per Iu SCCP success rate per
RAB establishment success rate. Presented
on secondary axis.
Table 8-2: Properties of View Rnc_Call_Setup_Overview_Cs
Metrics modification in UA7.1: CallSetupSuccessRate_CSSR005_R_Cs

CallSetupSuccessRate_CSSR005_R_Cs is modified to take into account the 3G2G RRC
Redirection feature when activated. Please refer to section 8.2.2.3.1 for further explanation.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 55/275

Metrics difference: Difference between CSSR005 and CSSR006
Another possibility to monitor the Call Setup Success Rate at RNC level is to use the
baseline Indicator CallSetupSuccessRateCS_CSSR006_R, this indicator provides a more
exact way of monitoring for the CSSR, the main differences between both indicators are:
CallSetupSuccessRateCS_CSSR006_R computes RRC connection Success Rate

without taking into consideration the UE repetitions for the RRC Connection
Requests on the same cell or a different cell in case of cell reselection, whereas
CallSetupSuccessRate_CSSR005_R_Cs computes the First RRC Connection Success
Rate for a given UE on a given cell.
CallSetupSuccessRateCS_CSSR006_R considers the Signalling Radio Bearer

Retainability, which provides the probability of maintaining the RRC connection after
it has been established, whereas CallSetupSuccessRate_CSSR005_R_Cs doesnt
monitor this probability.
When Computing the RAB establishment Success Rate

CallSetupSuccessRateCS_CSSR006_R deducts the total RAB Establishment
Cancels based on MSC requests from the total of RAB establishment Attempts, to
provide the accurate rate of attempted RAB establishments, whereas
CallSetupSuccessRate_CSSR005_R_Cs considers the total Requested RAB
establishments directly.
To monitor the Call Setup Success Rate at cell level, use

CallSetupSuccessRateCS_CSSR006_C and CallSetupSuccessRatePS_CSSR007_C for
CS calls and PS calls respectively.
8.2.1.1.2 RRC Connection checking

The next step is to check each component of the CSSR indicator. To check if a degradation of the Call
Setup Success Rate is due the first RRC Connection success rate component., the first view
described below (First_Rrc_Success) could be used : it provides an indication of the performance of
the RRC establishment phase (not considering RRC request repetitions received in the same cell and
for causes only related to calls). If there is a degradation of the first RRC Connection success rate,
then the RRC connection phase for PS or CS or both should be monitored in details (see section
8.2.2.1). The second view described below (Rrc_Connection_Overview) is useful to have information
in terms of volume and success rate on RRC connection establishment phase taking into account
repetitions. In case there is an issue with RRC connection, the information obtained should be
complemented by the results retrieved from other RRC accessibility views presented later in the
document.
First_Rrc_Success
This view gives the behaviour of the network elements during First RRC connection establishment
phase, both in terms of volume and success rate. This success rate without taking into repetitions
corresponds more to the user view.
Note: First RRC Connection request indicator does not consider RRC request repetitions received in
the same cell, but those received in different cells. There are new UA06 counters in US market to
avoid counting repetitions in case of cell change.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 56/275
First_Rrc_Success - RNC: RNC2005 ( RNC2005 ) - 09/16/2008 00:00 To 09/16/2008

17:00 (Working Zone: Global - Medium)
RNC2005
450
120,00%
400
100,00%
350
80,00%
250
60,00%
Event
300
200
150
FirstRRCConnectionRequest_RRC015_
CR_Calls(URRC015_CR_Calls)
FirstRRCConnectionSuccessRate_RR
C013_CR_Calls(URRC013_CR_Calls)
40,00%
100
20,00%
50
09/16/2008 17:00
09/16/2008 15:00
09/16/2008 16:00
09/16/2008 14:00
09/16/2008 12:00
09/16/2008 13:00
09/16/2008 11:00
09/16/2008 10:00
09/16/2008 08:00
09/16/2008 09:00
09/16/2008 07:00
09/16/2008 06:00
09/16/2008 04:00
09/16/2008 05:00
09/16/2008 03:00
09/16/2008 01:00
09/16/2008 02:00
00,00%
09/16/2008 00:00
Figure 8-6: Display of View First_Rrc_Success
Name
First_Rrc_Success
Description
Overview of first RRC connection establishment procedure.
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
FirstRRCConnectionRequest_RRC015_CR_Calls
Number of First RRC Connection Requests

(Calls). Presented on primary axis.
FirstRRCConnectionSuccessRate_RRC013_CR_Calls
Number of RRC connection success versus the

first RRC connection requests (Calls). This
metric shows the success rate of the first step of
accessibility. Presented on secondary axis.
Table 8-3: Properties of View First_Rrc_Success
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 57/275
This view gives the behaviour of the network elements in terms of RRC connection establishment,
both in terms of volume and success rate and including RRC request repetitions.
Figure 8-7: Display of View Rrc_Connection_Overview
Name
Description
Overview of global RRC connection establishment procedure.
Graph
Families
DASHBOARD
ACCESSIBILITY
CELL
DASHBOARD
ACCESSIBILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RRCConnectionRequests_RRC002_CR
Number of RRC Connection Requests (global).

RRCConnectionSuccessRate_RRC003_CR

RRC connection requests. This metric shows the
success rate of the first step of accessibility .This
metric takes into account the RRC establishment
repetitions that can be transparent for the user.
Presented on secondary axis.
Table 8-4: Properties of View Rrc_Connection_Overview
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 58/275

8.2.1.1.3 Iu_Sccp Connection checking
The Iu SCCP connection phase can be quickly checked thanks to the view described below for both
CS and PS domain.
Iu_Sccp_Connection_Global
This view gives statistics in terms of volume and success rate for Iu-PS and Iu-CS SCCP connection
phase. In case of an Iu SCCP connection issue, detailed monitoring of Iu SCCP connection phase
(see section 8.2.2.4) is needed.
Iu_Sccp_Connection - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To 09/15/2008

(Working Zone: Global - Medium) RNC2005
IuSCCPConnectionAttempts_IuSCCP005_R_Cs(UIuSCCP005_R_Cs)
IuSCCPConnectionAttempts_IuSCCP005_R_Ps(UIuSCCP005_R_Ps)
IuSCCPSuccessRate_IuSCCP006_R_Cs(UIuSCCP006_R_Cs)
IuSCCPSuccessRate_IuSCCP006_R_Ps(UIuSCCP006_R_Ps)
14000
120,00%
12000
100,00%
10000
8000
60,00%
Event
80,00%
6000
40,00%
4000
20,00%
2000
00,00%
08
/2
6/
08 200
8
/2
7/
08 200
8
/2
8/
08 200
8
/2
9/
08 200
/3
8
0/
08 200
8
/3
1/
09 200
8
/0
1/
09 200
8
/0
2/
09 200
/0
8
3/
09 200
8
/0
4/
09 200
8
/0
5/
09 200
8
/0
6/
09 200
8
/0
7/
09 200
/0
8
8/
09 200
8
/0
9/
09 200
8
/1
0/
09 200
8
/1
1/
09 200
/1
8
2/
09 200
8
/1
3/
09 200
8
/1
4/
09 200
8
/1
5/
20
08
Figure 8-8: Display of View Iu_Sccp_Connection_Global
Name
Iu_Sccp_Connection_Global
Number of Iu SCCP connection attempts and success rate
for CS and PS.
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
CELL3G
OZ_CELL3G
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 59/275

NETWORK
Indicators
IuSCCPConnectionAttempts_IuSCCP005_R_Cs
IuSCCPConnectionAttempts_IuSCCP005_R_Ps
IuSCCPSuccessRate_IuSCCP006_R_Cs
IuSCCPSuccessRate_IuSCCP006_R_Ps
Number of Iu SCCP connection attempts

for Cs. Presented on primary axis.
Number of Iu SCCP connection attempts
for Ps. Presented on primary axis.
Number of Iu-CS SCCP connection
success versus the number of Iu-CS
SCCP connections attempts. Presented
on secondary axis.
Number of Iu-PS SCCP connection
success versus the number of Iu-PS
SCCP connections attempts for Ps.
Table 8-5: Properties of Iu_Sccp_Connection_Global
Metrics modification in UA7.0: IuSCCPConnectionAttempts_IuSCCP005_R_Ps and

IuSCCPConnectionAttempts_IuSCCP005_R_Cs
Starting UA7.0 release baseline Indicator dictionary modifies the formula for both Indicators
IuSCCPConnectionAttempts_IuSCCP005_R_Ps and
IuSCCPConnectionAttempts_IuSCCP005_R_Cs to add 2 newly introduced counter
screenings UC502_5 and UC502_4 respectively for failures of SCCP connection on IU
interface due to request of CS/PS core network with trigger overload.
8.2.1.1.4 RAB establishment phase checking

The last component to check in case of CSSR degradation is the RAB establishment success rate.
The indicator RABEstablishmentSuccessRatePerRequestedRAB_RAB011_R allows checking the
RAB establishment success rate for both domains. In case of RAB establishment issue, detailed
monitoring of this call setup phase is needed (see section 8.2.2.5).
Rab_Establishment_Ps
This view is used to have statistics on the RAB establishment phase for PS calls in terms of volume
and success rate.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 60/275
Rab_Establishment_Ps - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To 09/15/2008

RABEstablishmentRequestsPerRABType_RAB013_R_Ps(URAB013_R_Ps)
5000
120,00%
RABEstablishmentSuccessRatePerRequestedRAB_RAB011_R_Ps(URAB011_R_Ps)
4500
100,00%
4000
3500
80,00%
60,00%
2500
Event
3000
2000
40,00%
1500
1000
20,00%
500
00,00%
08
/2
6
08 /2 0
/2 08
7
08 /2 0
/2 08
8
08 /2 0
/2 08
9
08 /2 0
/3 08
0
08 /2 0
/3 08
1
09 /2 0
/0 08
1
09 /2 0
/0 08
2
09 /2 0
/0 08
3
09 /2 0
/0 08
4
09 /2 0
/0 08
5
09 /2 0
/0 08
6
09 /2 0
/0 08
7
09 /2 0
/0 08
8
09 /2 0
/0 08
9
09 /2 0
/1 08
0
09 /2 0
/1 08
1
09 /2 0
/1 08
2
09 /2 0
/1 08
3
09 /2 0
/1 08
4
09 /2 0
/1 08
5/
20
08
Figure 8-9: Display of View Rab_Establishment_Ps
Name
Rab_Establishment_Ps
Number of PS RAB establishment requests and success
rate
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
PS
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RABEstablishmentRequestsPerRABType_RAB013
Number of PS RAB assignment requests.
_R_Ps
PS RAB success rate per requested RAB
RABEstablishmentSuccessRatePerRequestedRAB
type (not necessarily the granted RAB).
_RAB011_R_Ps
Table 8-6: Properties of Rab_Establishment_Ps
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 61/275
New metric: RABEstablishmentSuccessRatePerGrantedRAB_RAB011_C

In UA7.1 the baseline Dictionary introduces a new indicator
RABEstablishmentSuccessRatePerGrantedRAB_RAB011_C for the total RAB
establishment success rate at Cell Level for both CS and PS domains.
Rab_Establishment_Cs
This view is used to have statistics on the RAB establishment phase for CS calls (voice and video).
Rab_Establishment_Cs - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To 09/15/2008

RABEstablishmentRequestsPerRABType_RAB013_R_CsVoice(URAB013_R_CsVoice)
RABEstablishmentRequestsPerRABType_RAB013_R_CsVideo(URAB013_R_CsVideo)
RABEstablishmentSuccessRatePerRequestedRAB_RAB011_R_CsSpeech(URAB011_R_CsSpeech)
3500
RABEstablishmentSuccessRatePerRequestedRAB_RAB011_R_CsVideo(URAB011_R_CsVideo)
3000
120,00%
100,00%
2500
80,00%
60,00%
Event
2000
1500
40,00%
1000
20,00%
500
00,00%
08
/2
6/
20
08
08
/2
7/
20
08
/ 2 08
8/
20
08
08
/2
9/
20
08
/ 3 08
0/
20
08
/ 3 08
1/
20
09
08
/0
1/
20
09
/ 0 08
2/
20
09
08
/0
3/
20
09
/ 0 08
4/
20
09
08
/0
5/
20
09
/ 0 08
6/
20
09
/ 0 08
7/
20
09
08
/0
8/
20
09
/ 0 08
9/
20
09
08
/1
0/
20
09
/ 1 08
1/
20
09
08
/1
2/
20
09
/ 1 08
3/
20
09
/ 1 08
4/
20
09
08
/1
5/
20
08
Figure 8-10: Display of View Rab_Establishment_Cs
Name
Rab_Establishment_Cs
Number of CS voice and video RAB establishment
requests and success rate
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
CS
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 62/275

OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
_R_CsVoice
_R_CsVideo
_RAB011_R_CsSpeech
_RAB011_R_CsVideo
Number of CS voice RAB assignment

requests. Presented on primary axis.
Number of CS video RAB assignment
requests. Presented on primary axis.
RAB success rate per requested RAB
type (not necessarily the granted RAB) Cs Voice. Presented on secondary axis.
RAB success rate per requested RAB
type (not necessarily the granted RAB) Cs Video. Presented on secondary axis.
Table 8-7: Properties of Rab_Establishment_Cs
8.2.1.1.5 Security_Mode_Command procedure checking

The CSSR does not cover the Security Mode Command procedure but the metrics related to this
procedure should be also checked as an issue during this procedure may affect the accessibility
performance. The Security Mode Command procedure is used to trigger the start of ciphering and
integrity protection for the radio bearers. The success rate of this procedure can be quickly checked
thanks to the view described below for both CS and PS domain.
This view gives the SMC success rate for PS and CS and takes into consideration the total number of
security mode procedures, accounting for the successes (RNC sends SECURITY MODE COMPLETE
message to core network), failures (RNC sends SECURITY MODE REJECT message with cause
Failure in the radio interface procedure) and rejections (RNC sends SECURITY MODE REJECT
message with cause different from the one above). If the Security Mode Command success rate is
degraded for CS or PS, the procedure should be monitored in details for the concerned service thanks
to CTg traces and CN counters if available.
Figure 8-11: Display of View Security_Mode_Command_Overview
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 63/275
Name
Description
Overview of security mode procedure.
Graph
Families
DASHBOARD
ACCESSIBILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
SecurityModeCommand_SMC001_R_Cs
Total number of SMC procedures

performed (successful, rejected and
failed) for Cs. Presented on primary axis.
SecurityModeCommand_SMC001_R_Ps
Total number of SMC procedures

performed (successful, rejected and
failed) for Ps. Presented on primary axis.
SecurityModeCommandSuccessRate_SMC002_R_Cs
Number of SMC procedures successful

versus the total number of SMC
procedures performed (successful,
rejected and failed) for Cs. Presented on
secondary axis.
SecurityModeCommandSuccessRate_SMC002_R_Ps
Number of SMC procedures successful

versus the total number of SMC
procedures performed (successful,
rejected and failed) for Ps. Presented on
secondary axis.
Table 8-8: Properties of View Security_Mode_Command_Overview
8.2.2
Detailed accessibility monitoring
Detailed accessibility monitoring consists in checking main metrics associated to the affected
accessibility procedures to identify for each procedure metrics that are degraded and to characterize
more precisely the problem. The aim is to find:
the affected services
the main failures causes
the affected network elements : the issue may concern all the network or could be limited to
some network elements (search of the worst cells or observe KPIs per cells zone (F1, F2,
xCEM, iCEM may help in investigations)
the affected period of time : the degradation may be the same over all the observed period or
could be more huge for certain periods of time (observe daily KPI values over several weeks
and hourly values over several day may help to characterize the issue)
the events occurred on the network : the degradation may occur after some specific events
(upgrade, feature activation, parameters change, HW configuration change)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 64/275

Once this analysis has been done and a list of degraded accessibility metrics has been found, a more
detailed investigation based on accessibility troubleshooting reports may be useful depending on the
analysis results.
8.2.2.1
Cell Range monitoring
The cell radius governs both the geographic area covered by a cell and also, for a given subscriber
density, the number of subscribers that the cell must service.
To configure the Cell Radius parameter, one can rely on propagation delay counters which provide the
distribution of propagation delays, as expressed in the 3GPP25.433 (Nbap Rl Setup
Request.Propagation Delay IE when present).
The following table present the calculated cell radius based on the screening of the counters
VS.DistPropDelayPerRange.
Propagation Delay
Corresponding cell radius
Counter name
Delay < 6 Chips

6 Delay < 9 Chips
9 Delay < 15 Chips
15 Delay < 18 Chips
18 Delay < 27 Chips
27 Delay < 51 Chips
51 Delay < 129 Chips
VS_DistPropDelayPerRange_Delay
Lt6Chips (U1041_4)
Ge6Lt9Chips (U1041_5)
Ge129Chips (U1041_11)
Delay > 129 Chips
Cell size < 468m

468m Cell size < 702m
Cell size equal to or above
10072m
With the associated metrics:
Reference
LongName
Counters
UA7.1
Description
Formula
Number of RACH messages

CellRadius_Cell016_C_10k
UCell016_C_10kmto30km
received between 10 kms and UC1041_8
mto30km
30 kms
UCell016_C_5kmto10km
UMT/IRC/INF/012027
CellRadius_Cell016_C_5kmt
Number of RACH messages UC1041_7
o10km
received between 5 kms and
07.02 /EN
Preliminary
25/June/2010
Page 65/275

10 kms
UCell016_C_larger30km

CellRadius_Cell016_C_large
UC1041_9+UC1041_1
received from more than 30
r30km
0
kms
UCell016_C_less5km

CellRadius_Cell016_C_less5
UC1041_4+UC1041_5
received between 0 and 5
km
+UC1041_6
kms
8.2.2.2
Paging performance monitoring
When RNC receives a paging message from CN, together with an IMSI, it first decides whether to
send a paging Type 1 (if there is no UE context for this IMSI in the RNC), or a paging Type 2 (if there
is already a UE context for this IMSI in the RNC).
PAGING TYPE 1 message is used to send information on the paging channel (PCCH
channel). One or several UEs, in idle or connected mode (idle mode, CELL_PCH or
URA_PCH state), can be paged in one message, which also can contain other information.
PAGING TYPE 2 message is used to page an UE in connected mode (CELL_DCH or

CELL_FACH state), when using the DCCH for CN originated paging.
The following paging counters could be used during paging performance monitoring:
Paging counters
VS.ReceivedPagingRequest
VS.ReceivedPagingRequestType2CellDch
VS.ReceivedPagingRequestType2CellFach
VS.PagingMessagesSentOnPcch
VS.PagingCancelledRecords
VS.PagingRejectedRequests
VS.PagingDelayedRecords
VS.UnhandledPagingRequestsCs
VS.UnhandledPagingRequestsPs
VS.PagingRecordsSentOnPcchCs
VS.PagingRecordsUnscheduledCs
UMT/IRC/INF/012027
07.02 /EN
Number of received paging requests

Number of received paging requests received for
UEs in Cell_DCH state
Number of received paging requests received for
UEs in Cell_FACH state
Number of paging messages sent on the PCCH
of the cell
Number of paging records that are cancelled
after having been scheduled but before being
sent.
Note: The cancellation is not caused by the
paging discard timer or lack of buffer, it will be
due to the low bandwidth of Iub.
Number of paging requests that are rejected
Number of paging records that are delayed
before being sent
Number of CS paging request not sent to the INode to be broadcasted
Number of PS paging request not sent to the INode to be broadcasted
Number of paging records sent on the PCCH of
the cell
Number of paging records that have invalid
format or cannot be scheduled because the
paging occasion is full.
Note: In this case, the paging repetition is taken
into account. Pagings which cannot be schedule
are not due to buffer congestion or paging
discard timer.
Preliminary
25/June/2010
Page 66/275
VS.agingRecordsUnscheduledPs
VS.PagingRecordsType2SentCs
VS.PagingRecordsType2SentPs
VS.PagingRecordsSentOnPcchPs
VS.PagingRequestsIuPagCauseCs
VS.PagingRequestsIuPagCausePs
VS.UtranPagingRecSentOnPcch
Number of paging records that have invalid

format or cannot be scheduled because the
paging occasion is full.
Note: In this case, the paging repetition is taken
into account. Pagings which cannot be schedule
are not due to buffer congestion or paging
discard timer.
Number of type 2 paging records sent to a Ue
with a given reference cell per paging cause for
Core Network CS
Number of type 2 paging records sent to a Ue
with a given reference cell per paging cause for
Core Network PS
Number of paging records sent on the PCCH of
the cell
Number of paging request messages received
on an Iu CS per paging cause
Number of paging request messages received
on an Iu PS per paging cause.
Number of UTRAN initiated pagings type 1 sent
on the PCCH of the cell
Based on these counters, some metrics are available to directly assess the paging performance.
Paging metrics
NumberofPagingRecordonPCCH_Paging005_CR
NumberofPagingRecordonPCCH_Paging005_CR_Cs
NumberofPagingRecordonPCCH_Paging005_CR_Ps
NumberofPagingRequest_Paging004_R
NumberofPagingRequest_Paging004_R_atTrafficBusyHour
NumberofPagingRequest_Paging004_R_Cs
NumberofPagingRequest_Paging004_R_Ps
PagingRatePerHour_Paging009_R
PagingType1sentbyCoreNetwork_Paging003_R
PagingType1sentbyCoreNetwork_Paging003_R_atTrafficBusyHour
PagingType1sentbyCoreNetwork_Paging003_R_Cs
PagingType1sentbyCoreNetwork_Paging003_R_Ps
PagingType1SuccessRate_Paging006_R
PagingType2Requests_Paging002_CR
PagingType2Requests_Paging002_CR_Cs
PagingType2Requests_Paging002_CR_Ps
RepeatedPagingFailure_Paging008_CR
UnscheduledPagingRecords_Paging007_CR_Cs
UnscheduledPagingRecords_Paging007_CR_Ps
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 67/275

8.2.2.2.1 Paging Records
Volume of paging record stored by the RNC.
Paging Records On PCCH - RNC: - 04/20/2010 To 04/26/2010
4000000000
3500000000
3000000000
2500000000
Event
NumberofPagingRecordonPCCH_Paging005_CR(UPaging005_CR)
2000000000
NumberofPagingRecordonPCCH_Paging005_CR_Cs(UPaging005_CR_Cs)
NumberofPagingRecordonPCCH_Paging005_CR_Ps(UPaging005_CR_Ps)
1500000000
1000000000
500000000
0
04/20/2010
UMT/IRC/INF/012027
04/21/2010
04/22/2010
07.02 /EN
04/23/2010
Preliminary
04/24/2010
04/25/2010
25/June/2010
04/26/2010
Page 68/275

Volume of paging records that are cancelled after having been scheduled but before being sent.
Note: The cancellation is not caused by the paging discard timer or lack of buffer, it will be due to the low
bandwidth of Iub.
PagingCancellation_PagingRecords_RRCconnectionRequests - 04/20/2010 To
04/26/2010
18000000
4000000000
16000000
3500000000
14000000
3000000000
12000000
2500000000
Event
10000000
2000000000
8000000
1500000000
6000000
1000000000
4000000
RRCConnectionRequests_RRC002_CR(URRC002_CR)
NumberofPagingRecordonPCCH_Paging005_CR(UPaging005_CR)
500000000
2000000
VS_PagingCancelledRecords(U807)
0
04/20/2010
04/21/2010
04/22/2010
04/23/2010
04/24/2010
04/25/2010
04/26/2010
Paging Cancelled
0,180%
2000
0,160%
1800
1600
0,140%
1400
0,120%
1200
0,100%
1000
0,080%
800
0,060%
600
0,040%
400
0,020%
200
0,000%
1 Feb 08
3 Feb 08
5 Feb 08
7 Feb 08
9 Feb 11
08 Feb 13
08 Feb 15
08 Feb 17
08 Feb 19
08 Feb 21
08 Feb 23
08 Feb 25
08 Feb 27
08 Feb 29
08 Feb
08 04-mars-08
02-mars-08
06-mars-08
VS.PagingCancelledRecords
VS.PagingCancelledRecords/RRC Connection Requests
(Ratio Paging Cancelled vs Number of Paging Records on PCH)*100
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 69/275

8.2.2.2.2 Paging Requests
Volume of Paging request. This volume includes the paging Type 1 and the paging Type 2.
500000
500000
450000
450000
400000
400000
350000
350000
300000
300000
250000
250000
200000
200000
150000
150000
100000
100000
50000
50000
508Feb
608Feb
708Feb
808Feb
908Feb
0811
0812
1 Feb
2 Feb
308Feb
408Feb
10
Feb
Feb
0813
Feb
08
14
Feb
08
15
Feb
0816
Feb
0817
Feb
0818
Feb
08
08
19
Feb
20
Feb
0821
Feb
0822
Feb
0823
Feb
08
24
Feb
08
25
Feb
08
26
Feb
0827
Feb
0828
Feb
0829
Feb
08
Feb
08
08
01-mars-08
02-mars-08
03-mars-08
04-mars-08
05-mars-08
06-mars-08
Number of Paging Request%Cs_Paging004_R Number of Paging Request%Ps_Paging004_R Number of Paging Request_Paging004_R
Distribution of Paging request Type 1 and Type 2
Paging Type 1 sent by Core Network vs Paging Type 2
500000
450000
4000
3500
400000
3000
350000
2500
300000
250000
2000
200000
1500
150000
1000
100000
500
50000
0
1 Feb2 08
Feb3 08
Feb4 08
Feb5 08
Feb6 08
Feb7 08
Feb8 08
Feb9 08
Feb
1008
Feb
11 08
Feb
12 08
Feb
13 08
Feb
14 08
Feb
15 08
Feb
16 08
Feb
17 08
Feb
18 08
Feb
19 08
Feb
20 08
Feb
21 08
Feb
22 08
Feb
23 08
Feb
24 08
Feb
25 08
Feb
26 08
Feb
27 08
Feb
28 08
Feb
29 08
Feb
08
01-mars-08
02-mars-08
03-mars-08
04-mars-08
05-mars-08
06-mars-08
Paging Type 1 sent by Core Network%Cs_Paging003_R
Paging Type 1 sent by Core Network%Ps_Paging003_R
Paging Type 2 Requests%Cs_Paging002_CR
Paging Type 2 Requests%Ps_Paging002_CR
Paging Type 1 sent by Core Network_Paging003_R
Paging Type 2 Requests_Paging002_CR
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 70/275

8.2.2.2.3 Unscheduled Paging Records
Distribution of unscheduled paging record for PS and CS:
5000000
4500000
4000000
3500000
3000000
2500000
2000000
1500000
1000000
500000
0
12/01/2009 12/02/2009 12/03/2009 12/04/2009 12/05/2009 12/06/2009 12/07/2009 12/08/2009 12/09/2009 12/10/2009 12/11/2009 12/12/2009 12/13/2009 12/14/2009 12/15/2009 12/16/2009
PagingRecordsUnscheduledCs.TerminatingBackgroundCall
PagingRecordsUnscheduledCs.TerminatingHighPrioritySignalling
PagingRecordsUnscheduledCs.TerminatingStreamingCall
PagingRecordsUnscheduledPs.TerminatingConversationalCall
PagingRecordsUnscheduledPs.TerminatingLowPrioritySignalling
PagingRecordsUnscheduledCs.TerminatingCauseUnknown
PagingRecordsUnscheduledCs.TerminatingInteractiveCall
PagingRecordsUnscheduledPs.TerminatingBackgroundCall
PagingRecordsUnscheduledPs.TerminatingHighPrioritySignalling
PagingRecordsUnscheduledPs.TerminatingStreamingCall
PagingRecordsUnscheduledCs.TerminatingConversationalCall
PagingRecordsUnscheduledCs.TerminatingLowPrioritySignalling
PagingRecordsUnscheduledPs.TerminatingCauseUnknown
PagingRecordsUnscheduledPs.TerminatingInteractiveCall
Distribution of the caused of the unscheduled paging records for CS and PS:
7000
6000
5000
4000
3000
2000
1000
0
12/01/2009 12/02/2009 12/03/2009 12/04/2009 12/05/2009 12/06/2009 12/07/2009 12/08/2009 12/09/2009 12/10/2009 12/11/2009 12/12/2009 12/13/2009 12/14/2009 12/15/2009 12/16/2009
UnhandledPagingRequestsCs.InternalResourcesNotAvailable
UnhandledPagingRequestsCs.InvalidFormat
UnhandledPagingRequestsCs.InvalidInformation
UnhandledPagingRequestsCs.OtherCause
UnhandledPagingRequestsCs.OverloadControls
UnhandledPagingRequestsCs.ResetInProgress
UnhandledPagingRequestsPs.InternalResourcesNotAvailable
UnhandledPagingRequestsPs.InvalidFormat
UnhandledPagingRequestsPs.InvalidInformation
UnhandledPagingRequestsPs.OtherCause
UnhandledPagingRequestsPs.OverloadControls
UnhandledPagingRequestsPs.ResetInProgress
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 71/275

8.2.2.3
RRC connection monitoring
An issue in RRC accessibility is usually detected by a low RRC connection success (<96/%) or by a
degradation compared to a reference. The monitoring of RRC phase starts by checking the RRC
accessibility of both domains PS and CS and by checking the global RRC connection failure rate and
the reject rate. This can be done thanks to the 2 following views Rrc_Success_Global_Cs_Ps and
Rrc_Failure_Global described in section 8.2.2.3.1.
Then the next step should be to check in parallel:
the RRC accessibility per RRC establishment cause (service cause) to determine if the issue
affects all services or only a few services. RRC connection success rate per establishment
cause can be computed thanks to the screenings of basic indicators RRC_SuccConnEstab
(U403) and RRC_AttConnEstab (U409). The view Rrc_Success_InterRat_Registration
described in section 8.2.2.3.1 gives information on RRC accessibility for registration and interRAT cell reselection causes.
the distribution of RRC failure causes to find the main cause of failures. This distribution is
given by the 2 following detailed monitoring views Rrc_Failure_Distribution_Without_T352
and Rrc_Failure_T352 described in section 8.2.2.3.1.
the distribution of Radio Link First Setup Failure causes to detect the type failure related to the
first radio link of a call or rejection due to lack of resources.
After identification of more affected services and main failures cause, a characterization of affected
networks elements and periods of time should be done as well as an analysis of events that may have
introduced accessibility degradation
The RL setup procedure should be also checked during RRC accessibility analysis. In section
8.2.2.3.7, view showing the distribution per cause of unsuccessful RL setup is described.
8.2.2.3.1 RRC accessibility detailed views

Main detailed RRC accessibility views available in detailed monitoring dictionary are described in this
section.
Rrc_Success_Global_Cs_Ps
This view is useful to have statistics on the volume of first RRC connection requests and on the
Success Rate taking into repetitions for PS and CS. This success rate corresponds to system view of
RRC connection performance.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 72/275
Rrc_Success_Global_Cs_Ps - RNC: RNC2005 ( RNC2005 ) - 09/16/2008 00:00 To

09/16/2008 17:00 (Working Zone: Global - Medium)
RNC2005
450
120,00%
400
100,00%
350
CR_Ps(URRC015_CR_Ps)
80,00%
CR_Cs(URRC015_CR_Cs)
250
60,00%
Event
300
RRCConnectionSuccessRate_RRC003
_CR_Ps(URRC003_CR_Ps)
200
150
_CR_Cs(URRC003_CR_Cs)
40,00%
100
20,00%
50
09/16/2008 17:00
09/16/2008 15:00
09/16/2008 16:00
09/16/2008 14:00
09/16/2008 12:00
09/16/2008 13:00
09/16/2008 11:00
09/16/2008 10:00
09/16/2008 08:00
09/16/2008 09:00
09/16/2008 07:00
09/16/2008 06:00
09/16/2008 04:00
09/16/2008 05:00
09/16/2008 03:00
09/16/2008 01:00
09/16/2008 02:00
00,00%
09/16/2008 00:00
Figure 8-12: Display of View Rrc_Success_Global_Cs_Ps
Name
Rrc_Success_Global_Cs_Ps
Description
RRC connection establishment for success for CS and PS
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
FirstRRCConnectionRequest_RRC015_CR_Cs
FirstRRCConnectionRequest_RRC015_CR_Ps
RRCConnectionSuccessRate_RRC003_CR_Cs
UMT/IRC/INF/012027
07.02 /EN
Number of RRC connection requests for Cs

calls. [] First RRC Repetitions are not taken into
Number of RRC connection requests for Ps calls.
First RRC Repetitions are not taken into
Preliminary
25/June/2010
Page 73/275
RRCConnectionSuccessRate_RRC003_CR_Ps

Cs. Presented on secondary axis.
PS. Presented on secondary axis.
Table 8-9: Properties of View Rrc_Success_Global_Cs_Ps
Metric modification in UA7.1: FirstRRCConnectionRequest_RRC015_CR_Cs and

RRCConnectionSuccessRate_RRC001_CR_Cs
Indicator FirstRRCConnectionRequest_RRC015_CR_Cs has been modified in UA7.1 to
take into account the 3G2G RRC Redirection feature when activated, so the formula now
takes into consideration the sum of RRC_FailConnEstab_3G2GRedirectCellLoad and
RRC_FailConnEstab_3G2GRedirectEmergency which are counted as First RRC
connection requests in case UE fails to be redirected to 2G cells.
Also Indicator RRCConnectionSuccessRate_RRC001_CR_Cs is modified to take into
account the Success of the RRC connections on 3G cells resulting from the UE reattempting
to connect to 3G cells after failure to be redirected to 2G Cells
So new formula for RRCConnectionSuccess takes into consideration :
(RRC_FailConnEstab_3G2GRedirectCellLoad +
RRC_FailConnEstab_3G2GRedirectEmergency VS_RRC_ConnectionReAttempt_3G2GRedirectCellLoad VS_RRC_ConnectionReAttempt_3G2GRedirectEmergency) to represent these portion of
RRC Connection Success.
8.2.2.3.2 Impact to Accessibility KPI with RRC Redirection (iMCRA)

When monitoring accessibility KPI with RRC redirection feature activated, the following rule needs to
be followed:
Rule: Impact to Accessibility KPI with RRC Redirection (iMCRA)
With RRC Redirection the Accessibility view per cell will be not accurate due to RRC
Connection Request sent on Cell 1 and RRC Connection Setup Complete sent on Cell 2.
Accessibility KPIs should be retrieved at least for the entire group of collocated cells eligible
for Redirection.
8.2.2.3.3 RRC Failure view

This view is useful to have statistics on the number of RRC connection failures and rejects.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 74/275
Rrc_Failure_Global - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To 09/15/2008

(Working Zone: Global - Medium)
RNC2005
70,00%
30000
60,00%
25000
50,00%
20000
(URRC002_CR)
RRCConnectionFailureRatio_RRC018_
CR(URRC018_CR)
Event
40,00%
15000
30,00%
RRCConnectionRejectRateSystem_RR
C008_CR(URRC008_CR)
10000
20,00%
5000
10,00%
00,00%
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
09
08
/0
1/
20
09
08
/0
3/
20
09
08
/0
5/
20
09
08
/0
7/
20
09
08
/0
9/
20
09
08
/1
1/
20
09
08
/1
3/
20
09
08
/1
5/
20
08
Figure 8-13: Display of View Rrc_Failure_Global
Name
Rrc_Failure_Global
Description
Overview of RRC connection failures and rejects.
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
Number of RRC Connection Requests (Calls).

RRCConnectionFailureRatio_RRC018_CR
Ratio of RRC connection failure, taking into

account Traffic Segmentation Presented on
secondary axis.
RRCConnectionRejectRateSystem_RRC008_CR
Ratio of RRC connection reject versus the

number of RRC connection request - Global
metric Presented on secondary axis.
Table 8-10: Properties of View Rrc_Failure_Global
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 75/275
Metric modification: RRCConnectionRejectRateSystem_RRC008_CR

Indicator RRCConnectionRejectRateSystem_RRC008_CR has been modified in Baseline
dictionary to take into account RRC Rejections due to cell reselections (counter screening
U404_14),which wasnt not previously counted in UA6.0 baseline dictionary.
8.2.2.3.4 Rrc_Success_InterRat_Registration
This view is used to have statistics on RRC connection requests and success rate for interRAT cell
reselection and registration causes
Rrc_Success_InterRat_Registration - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To

09/15/2008 (Working Zone: Global - Medium)
RNC2005
25000
120,00%
100,00%
20000
RRC_AttConnEstab_Registration(U409
_12)
80,00%
RRC_AttConnEstab_IRATCellResel(U4
09_10)
60,00%
Event
15000
10000
40,00%
5000
_CR_Registration(URRC003_CR_Regis
tration)
_CR_InterRAT(URRC003_CR_InterRAT
)
20,00%
00,00%
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
09
08
/0
1/
20
09
08
/0
3/
20
09
08
/0
5/
20
09
08
/0
7/
2
0
09
/0 08
9/
20
09
08
/1
1/
20
09
08
/1
3/
2
0
09
/1 08
5/
20
08
Figure 8-14: Display of View Rrc_ Success_InterRat_Registration
Name
Rrc_ Success_InterRat_Registration
RRC connection success rate for interRAT cell reselection
and registration causes
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
UMT/IRC/INF/012027
07.02 /EN
Daily
Preliminary
Weekly
25/June/2010
Monthly
Page 76/275

CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RRC_AttConnEstab_Registration (U409_12)
RRC_AttConnEstab_IRATCellResel (U409_10)
RRCConnectionSuccessRate_RRC003_CR_Registration
RRCConnectionSuccessRate_RRC003_CR_InterRAT
Number of RRC connection request received

(cause registration). Presented on primary
axis.
Number of RRC connection request received
(cause Inter-RAT cell re-selection. Presented
on primary axis.
Number of RRC connection success versus
the RRC connection requests. This metric
shows the success rate of the first step of
accessibility (cause Registration) .This metric
takes into account the RRC establishment
repetitions that can be transparent for the
user. Presented on secondary axis.
Number of RRC connection success versus
the RRC connection requests. This metric
shows the success rate of the first step of
accessibility (cause Inter-RAT cell
reselection) .This metric takes into account
the RRC establishment repetitions that can
be transparent for the user. Presented on
secondary axis.
Table 8-11: Properties of Rrc_ Success_InterRat_Registration
8.2.2.3.5 Rrc_Failure_Distribution_Without_T352
This view gives the ratio of RRC connection failure distribution (for all failures types except failure due
to timer T352 expiry) versus the total number of RRC connection failures.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 77/275

RRCConnFailureDistribution_RRC017_CR
Rrc_Failure_Distribution_Without_T352 - RNC: RNC2005 ( RNC2005

) - 08/26/2008
_UnvailRRCcontext(URRC017_CR_UnvailR
RCctx)
To 09/15/2008 (Working Zone: Global - Medium)
RNC2005
_UnvailFACHcontext(URRC017_CR_Unvail
FACHctx)
100%
_Unspecified(URRC017_CR_Unspecified)
_RSSI(URRC017_CR_RSSI)
60%
_RRCcontextCAC(URRC017_CR_RRCcon
textCAC)
80%
_Overload(URRC017_CR_Overload)
40%
_NoAnswerNodeB(URRC017_CR_NoAnsw
erNodeB)
20%
_LackCRNTI(URRC017_CR_LackCRNTI)
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
08
09
/0
1/
20
08
09
/0
3/
20
08
09
/0
5/
20
08
09
/0
7/
20
08
09
/0
9/
20
08
09
/1
1/
20
08
09
/1
3/
20
08
09
/1
5/
20
08
0%
_EcN0LowqQualMin(URRC017_CR_EcN0
LowqQualMin)
_DLPowerResources(URRC017_CR_DLP
wrResources)
Figure 8-15: Display of View Rrc_Failure_Distribution_Without_T352
Name
Rrc_Failure_Distribution_Without_T352
Description
Distribution of RRC failures excluding T352 expiry
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RRCConnFailureDistribution_RRC017_CR_3G2GRedirec
tEmerg
RRCConnFailureDistribution_RRC017_CR_CellFACHCA
C
RRCConnFailureDistribution_RRC017_CR_DLCodeReso
urces
RRCConnFailureDistribution_RRC017_CR_DLPowerRes
ources
UMT/IRC/INF/012027
07.02 /EN
Number of RRC connection failure by type

versus the total number of RRC connection
failures. Presented on primary axis.
Preliminary
25/June/2010
Page 78/275

RRCConnFailureDistribution_RRC017_CR_EcN0LowqQu
alMin
RRCConnFailureDistribution_RRC017_CR_LackCRNTI
RRCConnFailureDistribution_RRC017_CR_NoAnswerNo
deB
RRCConnFailureDistribution_RRC017_CR_Overload
RRCConnFailureDistribution_RRC017_CR_RRCcontextC
AC
RRCConnFailureDistribution_RRC017_CR_RSSI
RRCConnFailureDistribution_RRC017_CR_Unspecified
RRCConnFailureDistribution_RRC017_CR_UnvailFACHc
ontext
RRCConnFailureDistribution_RRC017_CR_UnvailRRCco
ntext

Table 8-12: Properties of View Rrc_Failure_Distribution_Without_T352
Inter-Release Delta:
New UA7.1 counter screening RRC.FailConnEstab.Unspecified.Sum to replace counter
screening
RRC_FailConnEstab_Unspec
in
both
Indicators
RRCConnectionFailures_RRC018_CR and RRCConnectionReject_RRC029_CR.
Indicators URRC029_CR and URRC018_CR peg all screenings for Counter # 404 ,except
for URRC029_CR it provides the RRC Connection Failure without T352 by excluding
screening 404_0.
8.2.2.3.6 Rrc_Failure_T352
This view gives the ratio of RRC connection failure due to timer T352 expiry versus the total number of
RRC connection failures.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 79/275
Rrc_Failure_T352 - RNC: RNC2005 ( RNC2005 ) - 09/16/2008 00:00 To 09/16/2008

17:00 (Working Zone: Global - Medium)
RNC2005
1,2
0,8
RRCConnFailureDistribution_RRC017_
CR_T352Expiration(URRC017_CR_T35
2Expiration)
0,6
0,4
0,2
09
/1
6/
20
08
09
00
/1
:0
6/
0
20
08
09
02
/1
:0
6/
0
20
08
09
04
/1
:0
6/
0
20
08
09
06
/1
:0
6/
0
20
08
09
08
/1
:0
6/
0
20
08
09
10
/1
:0
6/
0
20
08
09
12
/1
:0
6/
0
20
08
09
14
/1
:0
6/
0
20
08
16
:0
0
Figure 8-16: Display of View Rrc_Failure_T352
Name
Rrc_Failure_T352
Ratio of RRC connection establishment failure by timer T352
expiry.
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RRCConnFailureDistribution_RRC017_CR_T352Expiration
Number of RRC connection failure (cause

timer T352 expiry) versus Total number of
RRC connection failure.
Table 8-13: Properties of View Rrc_Failure_T352
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 80/275

8.2.2.3.7 Radio link first setup failure view
The following view has been provided to study RL setup failures during RRC connection phase.
These counters are pegged on reception of NBAP RL Setup Response/Failure related to the first radio
link of a call or rejection due to lack of resources (RRM refusal).
Radio link first setup failure counters

VS.RadioLinkFirstSetupFailure.InodeRefusal
VS.RadioLinkFirstSetupFailure.IubLayerCongestion
VS.RadioLinkFirstSetupFailure.LackBwthIub
VS.RadioLinkFirstSetupFailure.LackCidOrUdpPortIub
VS.RadioLinkFirstSetupFailure.MultiCellNotAvailable
VS.RadioLinkFirstSetupFailure.NodeBCEMLackL1Rsrc
VS.RadioLinkFirstSetupFailure.RadioLinkSetupFailure
VS.RadioLinkFirstSetupFailure.RrmRefusal
VS.RadioLinkFirstSetupFailure.TimeOut
8.2.2.3.8 Radio_Link_Setup_Unsuccess_Per_Cause
This view gives the number of unsuccessful Radio Link Setup per cause. The unsuccessful
management of radio link setup (RADIO_LINK_SETUP_FAILURE OR TIMEOUT) is counted per failed
radio link and not per message.
Radio_Link_Setup_Unsuccess_Per_Cause - RNC: RNC2005 ( RNC2005 ) 08/26/2008 To 09/15/2008 (Working Zone: Global - Medium)
RNC2005
VS_RadioLinkSetupUnsuccess_unused(U
2_3)
12000
VS_RadioLinkSetupUnsuccess_TimeOut(
U38_1)
VS_RadioLinkSetupUnsuccess_RrmRefus
al(U38_2)
10000
VS_RadioLinkSetupUnsuccess_RadioLink
SetupFailure(U38_0)
VS_RadioLinkSetupUnsuccess_NodeBOu
tOfOrder(U38_8)
Event
8000
VS_RadioLinkSetupUnsuccess_NodeBCE
MLackL1Rsrc(U38_4)
6000
VS_RadioLinkSetupUnsuccess_LackOfNo
deBUlProcessingResources(U2_5)
VS_RadioLinkSetupUnsuccess_LackOfNo
deBDlProcessingResources(U2_4)
4000
VS_RadioLinkSetupUnsuccess_LackCidO
rUdpPortIub(U38_5)
2000
VS_RadioLinkSetupUnsuccess_LackCidIu
b(U2_6)
VS_RadioLinkSetupUnsuccess_LackBwth
Iub(U38_6)
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
08
09
/0
1/
20
08
09
/0
3/
20
08
09
/0
5/
20
08
09
/0
7/
20
08
09
/0
9/
20
08
09
/1
1/
20
08
09
/1
3/
20
08
09
/1
5/
20
08
VS_RadioLinkSetupUnsuccess_IubLayerC
ongestion(U38_3)
VS_RadioLinkSetupUnsuccess_InodeRefu
sal(U38_7)
Figure 8-17: Display of View Radio_Link_Setup_Unsuccess_Per_Cause
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 81/275

Name
Radio_Link_Setup_Unsuccess_Per_Cause
Description
Number of unsuccessful radio link setup per cause
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_RadioLinkSetupUnsuccess_RadioLinkSetupFailure
(U38_0)
VS_RadioLinkSetupUnsuccess_TimeOut (U38_1)
VS_RadioLinkSetupUnsuccess_RrmRefusal (U38_2)
VS_RadioLinkSetupUnsuccess_IubLayerCongestion
(U38_3)
VS_RadioLinkSetupUnsuccess_NodeBCEMLackL1Rsrc
(U38_4)
VS_RadioLinkSetupUnsuccess_LackCidOrUdpPortIub
(U38_5)
VS_RadioLinkSetupUnsuccess_LackBwthIub (U38_6)
VS_RadioLinkSetupUnsuccess_InodeRefusal (U38_7)
VS_RadioLinkSetupUnsuccess_NodeBOutOfOrder
(U38_8)
VS_RadioLinkSetupUnsuccess_unused (U2_3)
VS_RadioLinkSetupUnsuccess_LackOfNodeBDlProcessin
gResources (U2_4)
VS_RadioLinkSetupUnsuccess_LackOfNodeBUlProcessin
gResources (U2_5)
VS_RadioLinkSetupUnsuccess_LackCidIub (U2_6)
Number of unsuccessful radio link setup

(Screening :
RADIO_LINK_SETUP_FAILURE ).
(Screening : Timeout). Presented on primary
axis.
(Screening : Rrm refusal). Presented on
primary axis.
(Screening : Iub Layer Congestion).
(Screening : NodeB (CEM) lack of L1
resources). Presented on primary axis
(Screening : Lack of Transport Identifier (CID
or UDP Port) on the Iub). Presented on
primary axis.
(Screening : Lack of bandwidth on the Iub).
(Screening : INode refusal). Presented on
primary axis.
(Screening : NodeB out of order (No
answer)). Presented on primary axis.
(Screening : Unused). Presented on primary
axis.
(Screening : Rrm refusal (DL NodeB
resource lack, or NodeB resource lack)).
Number of unsuccessfull radio link setup
(Screening : Rrm refusal (UL NodeB
resource lack)). Presented on primary axis.
Number of unsuccessfull radio link setup
(Screening : Lack of CID on the IubTrigger .
Table 8-14: Properties of Radio_Link_Setup_Unsuccess_Per_Cause
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 82/275

(*) screenings LackOfNodeBDlProcessingResources and LackOfNodeBUlProcessingResources
have been removed from counter U38 as they are not implemented and screening NodeB (CEM) lack
of L1 resources has been added in UA06. It gives the number of RL Setups that fail to be established
due to lack of CEM resources. The advantage of this screening is that it will enable to link the CEM
unavailability to the user perceived call blocking. This comment is also valid for
VS_RadioLinkFirstSetupFailure counter.
8.2.2.3.9 34668 - RRC Connection Request Counter Excluding UE Repetitions

With the counters available from UA05.x, metric RRC013 RRC Connection Success Rate (Users
Perception)
is
calculated
using
counters
#403
(RRC.SuccConnEstab)
and
#419(VS.FirstRrcConnectionRequest).
With:
Counter #403 provides the number of successfully established RRC Connections at cell level.
Counter #419 provides the number of first RRC Connection Requests messages received by a
given UE within the N300*T300 time window. If the UE performs cell reselection during the RRC
Establishment procedure the counter will be pegged again in the new cell, meaning that it can be
incremented multiple times for the same call attempt.
This feature introduced in UA6, implement new RNC counters (VS.RRC.AttConnEstab.LastperProc)

providing the number of RRC Connection Requests received by the UE but excluding the repetitions
when a RRC Connection Request is again attempted in the same cell or on another cell (following cell
reselection) during the N300xT300 time window beginning at the reception of the first request (as
described by TS25.331)
This feature show a clear benefit of KPI RRC021 which excludes repetitions compared to RRC003.
EH1
1.02
1
0.98
0.96
0.94
0.92
0.9
0.88
02/18/2010 02/21/2010 02/24/2010 02/27/2010 03/02/2010 03/05/2010 03/08/2010 03/11/2010 03/14/2010 03/17/2010
RRCConnectionSuccessRateExcRep_RRC021_CR(URRC021_CR) (%)
RRCConnectionSuccessRate_RRC003_CR(URRC003_CR) (%)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 83/275

8.2.2.4
Iu SCCP connection phase monitoring
Failures during Iu SCCP connection phase may be detected with checking of success rate KPIs for IuPS and Iu-CS SCCP connection.
The first Iu SCCP analysis should identify:
the affected domain (PS or CS or both)
the level of degradation in PS and/or CS domain (are all RNCs impacted or only a few RNCs
of a same Core Network).
the period of the degradation of the Iu SCCP success rate
When the period had been determined, HW Failures at SGSN, at MSC or at RNC should be checked
according to the impacted network elements. CTg and Iu traces could also be useful for investigations.
8.2.2.5
RAB establishment phase monitoring
An issue in RAB establishment phase is usually detected by a low RAB assignment success rate or by
a degradation compared to a reference. Once the RAB accessibility per requested RAB type has
been checked thanks to RABEstablishmentSuccessRatePerRequestedRAB_RAB011_R indicator
screenings
as
explained
above
in
section
8.2.1.1.4,
PS
screenings
of
VS_RabEstablishmentSuccessPerRequestedRabType
and
VS_RabEstablishmentRequestsPerRabType indicators can be used in case of a low RAB
establishment success rate for PS to determine if the issue is limited to a specific traffic class with low
or high DL rate or concerns all PS RABs with any DL rate.
The next step is to check the RB setup phase (failure rate and blocking rate) thanks to
Rb_Setup_Failure_Rnc view described below.
In case of high RB setup failure, screenings of VS_RadioBearerSetupUnsuccess should be

checked to find failure cause. Available views to check RB setup success rate par service
(CS, PS, HSDPA, HSUPA) at RNC level are listed at the end of section Error! Reference
source not found. in Table 8 21. The RL setup and reconfiguration procedures should be
also checked. Monitoring of RL reconfiguration procedure can be done thanks to the 2
following views described hereunder in section Error! Reference source not found.
(Radio_Link_Reconfiguration
and
Radio_Link_Reconfiguration_Prepare_Unsuccess_Per_Cause). In section Error! Reference
source not found., views showing the distribution per cause of unsuccessful RL
setup/addition procedure are also described.
In case of high blocking rate, screenings of VS_RadioBearerEstablishmentUnsuccess should

be checked to determine why the Radio Bearer establishment request has rejected by the
RNC
before
sending
RB
setup.
This
can
be
done
thanks
to
view
Radio_Bearer_Establishment_Unsuccess_Per_Cause
described
in
section
Error!
Reference source not found.. The analysis of reject causes will allow to determine if there is
a capacity issue and to start the study of resources shortage if needed. In case of PS RAB
accessibility issue due to CAC failure, Irm_Cac_Ps_Rejection allows to have information per
PS RAB type.
Note : In UA06 when the pre-emption feature (33222) is activated, after receiving a RL
Reconfiguration failure, the RNC sends a second RL reconfiguration prepare to the NodeB; if the
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 84/275

second RL Reconfiguration fails, 2 RL reconfiguration failures will be monitored. This RNC behaviour
could impact the RL reconfiguration success rate.
To check HSDPA accessibility, a detailed view Hsdpa_Accessibility is decribed in section 8.2.2.5.3 :
this view gives information on HSDPA RB setup success at Cell level and at RNC level.
In parallel the most affected networks elements should be determined as well as the most affected
periods of time. It is also needed to check if the degradation could not be linked to some specific
events occurred over the network.
8.2.2.5.1 RAB accessibility detailed views : CS and PS accessibility

The separation of CS domain services and PS domain services allow facilitating the analysis based on
the user behaviour.
The following views provides basic information on the CS, PS and Multi RAB traffic..
Name
CS_RAB_Accessibility
Description
Overview of CS_RAB Accessibility
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
CS_PS_MultiRab
CELL
DETAILED MONITORING
ACCESSIBILITY
CS_PS_MultiRab
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RABEstablishmentAttempts_RAB036_C_
CsStreaming
CS Streaming RAB establishment attempts - Cell

level
CsVideo
CS Video RAB establishment attempts - Cell level
CsVoice
CS Voice RAB establishment attempts - Cell level
RAB.SuccEstab.CS.SpeechConv
Successfully Completed CS RAB Establishments per

CS RAB Id. This counter does not take into account
RAB successfully established for incoming relocations
RAB.SuccEstab.CS.Conv64
(CsVideo)

RAB.SuccEstab.CS.Strm (CsVideo)

UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 85/275

Name
PS_RAB_Accessibility
Description
Overview of PS_RAB Accessibility
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
CS_PS_MultiRab
CELL
DETAILED MONITORING
ACCESSIBILITY
CS_PS_MultiRab
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
PSRABEstablishmentAttempts_RAB038_
C_DchDch
RAB Establishment Attempts for PS (UL DCH/DL

DCH) - Cell level
C_Hsdsch
RAB Establishment Attempts for PS (UL DCH/DL

HSDSCH and UL EDCH/DL HSDSCH) - Cell level
CR_EdchHsdsch
RAB Establishment Attempts for PS (UL EDCH/DL

HSDSCH)
TotalNumberPsCalls_Traffic041_C_Hsdp
a
Successfully completed PS RAB establishments (UL

DCH/DL HSDSCH and UL EDCH/DL HSDSCH) - Cell
level
TotalNumberPsCalls_Traffic041_C_R99
Successfully completed PS RAB establishments (UL

DCH/DL DCH) including fallback from HS - Cell level
TotalNumberPsCalls_Traffic041_CR_Edc
h
Successfully completed PS RAB establishments

CELL Level (UL EDCH/DL HSDSCH)
VS_RAB_SuccEstab_PS_ReqNotGranted
_EDCH_HSDSCH_GrantedDCH_DCH
Successful RAB Establishments for service type PS

data mapped on other UL and DL transport channel
combination than the initially requested.
_DCH_HSDSCH_GrantedDCH_DCH

_EDCH_HSDSCH_GrantedDCH_HSDSC
H

Name
Multi_RAB_Accessibility
Description
Overview of Multi_RAB Accessibility
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
CS_PS_MultiRab
CELL
DETAILED MONITORING
ACCESSIBILITY
CS_PS_MultiRab
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 86/275

RNC
OZ_RNC
NETWORK
Indicators
VS.RAB.AttEstabPS.Multiple
VS.RAB.SuccEstabPS.Multiple
Number of attempts to setup a PS "interactive" or

"background" RAB on top of an existing PS
"interactive" or "background" RAB for the same UE.
Number of successful attempts to setup a PS
"interactive" or "background" RAB on top of an
existing PS "interactive" or "background" RAB for the
same UE
Number of RAB Release Requests for PS RABs to be
released on top of an existing PS RAB
RAB.RelPS.Multiple
8.2.2.5.2 Multi Rab Accessibility

Release UA 7.1.1.3 introduces 3 new counters to monitor the multi RABs establishment and release.
Counter Name
Description
VS_RESERVED14 (Ref U2706)
The number of CS RAB establishment attempts

while a PS RAB is present
The number of PS RAB establishment attempts

while a CS RAB is present
The number of CS RABs dropped while a PS

RAB is present
The Below 3 figures highlight the possible use of the new UA7.1 Baseline Indicators URAB022_C_Ps,
URAB062_C_CS and URAB063_C_CS to provide the percentage of Multi Rab in networks.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 87/275
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 88/275
8.2.2.5.3 Hsdpa Accessibility

This view provides basic information on the HSDPA Radio bearer setup success at cell level and on
the HSDPA Radio bearer setup success and HSDPA RAB assignment success par granted RAB type
at RNC level.
Name
Hsdpa_Accessibility
Description
Overview of HSDPA RB setup success
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
HSDPA
CELL
DETAILED MONITORING
ACCESSIBILITY
HSDPA
RNC
Availability Domain
Hourly
UMT/IRC/INF/012027
07.02 /EN
Daily
Preliminary
Weekly
25/June/2010
Monthly
Page 89/275

CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RadioBearerToBeSetupSuccessRate_RB
007_C_HSDPA
Radio bearer to be setup success rate at cell level HSDPA. Presented on secondary axis.
RadioBearerSetupSuccess_RB011_C_H
SDPA
Number of RB setup successes (HSDPA) - Cell Level.

RadioBearerSetupSuccess_RB011_R_H
SDPA
Number of RB setup successes (HSDPA) - Rnc Level.

Table 8-15: Properties of View Hsdpa_Accessibility
In UA7.1, the indicator RAB022_R_HSDPA has been removed from the baseline dictionary
and from Hsdpa_Accessibility view as its using counters that are only supported in UA5.1
8.2.2.5.4 Radio Bearer Setup_Failure (Rnc)

This view is useful to have RNC level statistics on the failure rate and on the rejection rate due to RNC
during the Radio Bearer setup phase. A similar view is also available at Cell level
(Rb_Setup_Failure_Cell).
Rb_Setup_Failure_Rnc - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To 09/15/2008
RadioBearerToBeSetup_RB008_C(URB008_C)
7000
RadioBearerSetupFailureRate_RB012_R(URB012_R)
04,00%
RBBlockingRate_RB014_R(URB014_R)
03,50%
6000
03,00%
5000
02,50%
02,00%
Event
4000
3000
01,50%
2000
01,00%
00,50%
00,00%
08
/2
6/
08 2 00
/2
8
7
08 /2 0
/2 08
8/
08 2 00
/2
8
9/
08 2 00
/3
8
0
08 /2 0
0
/3
1/ 8
09 2 00
/0
8
1/
09 2 00
/0
8
2/
09 2 00
/0
8
3
09 /2 0
/0 08
4/
09 2 00
/0
8
5/
09 2 00
/0
8
6
09 /2 0
/0 08
7/
09 2 00
/0
8
8/
09 2 00
/0
8
9/
09 2 00
/1
8
0
09 /2 0
0
/1
1/ 8
09 2 00
/1
8
2/
09 2 00
/1
8
3
09 /2 0
/1 08
4/
09 2 00
/1
8
5/
20
08
1000
Figure 8-18: Display of View Rb_Setup_Failure_Rnc
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 90/275
Name
Rb_Setup_Failure_Rnc
Failure rate and RNC rejection rate during Radio Bearer setup
phase.
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
RadioBearerToBeSetup_RB008_C
RadioBearerSetupFailureRate_RB012_R
RBBlockingRate_RB014_R
Number of decisions to setup a radio bearer

(leading or nor to the sending of the Radio
Bearer message). Presented on primary axis.
Ratio of number of RB set-up unsuccess versus
the number of RB set-up attempts (message
sent). Presented on secondary axis.
Number of Radio Bearer establishment request
rejected (due to the RNC) before sending RB
setup versus the number of decisions to setup a
RB. Presented on secondary axis.
Table 8-16: Properties of View Rb_Setup_Failure_Rnc
8.2.2.5.5 Radio_Bearer_Establishment_Unsuccess_Per_Cause
This view is useful to find main causes of unsuccessful Radio Bearer Setup procedure with no radio
bearer setup message sent.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 91/275

VS_RadioBearerEstablishmentUnsuccess
_Unspecified(U1629_3)
Radio_Bearer_Establishment_Unsuccess_Per_Cause - RNC:
RNC2005 ( RNC2005
) - 08/26/2008 To 09/15/2008 (Working Zone: Global - Medium)
RNC2005
Event
_UnavailableDlPowerResources(U1629_2)
120
_UnavailableDlCodeResources(U1629_1)
100
_RlFailOrRlcErr(U1629_4)
80
_NodeBCEMLackofL1Resource(U1629_7)
60
_LackTransportIdIur(U1629_10)
40
_LackTransportIdIub(U1629_12)
20
_LackTransportIdIu(U1629_8)
_LackOfRncProcessingResources(U1629_
6)
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
08
09
/0
1/
20
08
09
/0
3/
20
08
09
/0
5/
20
08
09
/0
7/
20
08
09
/0
9/
20
08
09
/1
1/
20
08
09
/1
3/
20
08
09
/1
5/
20
08
_LackOfNodeBUlProcessingResources(U6
31_8)
Figure 8-19: Display of View Radio_Bearer_Establishment_Unsuccess_Per_Cause
Name
Radio_Bearer_Establishment_Unsuccess_Per_Cause
Description
Overview per cause of the number of Radio Bearer setup not

successfully established with no radio bearer setup message sent.
Preferred
Type
Display
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Counters
VS_RadioBearerEstablishmentUnsucce
ss_InvalidRabParametersValue
Number of radio bearer setup not

successfully established due to invalid RAB
parameters, with no radio bearer setup
message sent (based on procedure count,
not RBs). Presented on primary axis.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 92/275

ss_UnavailableDlCodeResources
ss_LackTransportIdIur
successfully established due to unavailable dl

code ressources, with no radio bearer setup
successfully established due to lack of
transport identifier on the Iur, with no radio
bearer setup message sent (based on
procedure count, not RBs). Presented on
primary axis.
ss_LackBwthIur
ss_LackTransportIdIub

bandwidth on the Iur, with no radio bearer
setup message sent (based on procedure
count, not RBs). Presented on primary axis.
transport identifier on the Iub, with no radio
primary axis.
ss_LackBwthIub

bandwidth on the Iub, with no radio bearer
ss_UnavailableDlPowerResources

successfully established due to unavailable dl
power resources, with no radio bearer setup
ss_Unspecified

successfully established due to with cause
unspecified, with no radio bearer setup
ss_RlFailOrRlcErr

successfully established due to RL failure or
RLC error, with no radio bearer setup
ss_5Unused

successfully established, with no radio bearer
count, not RBs). Screening : unused.
ss_LackOfRncProcessingResources

successfully established due to lack of RNC
Processing resources (CAC), with no radio
primary axis.
ss_LackOfRncProcessingResources
UMT/IRC/INF/012027
07.02 /EN

successfully established due to NodeB (CEM)
lack of L1 resources, with no radio bearer
Preliminary
25/June/2010
Page 93/275

ss_LackTransportIdIu

transport identifier on the Iu, with no radio
primary axis..
ss_LackBwthIu
ss_LackCidIur

bandwidth on the Iu, with no radio bearer
count, not RBs). Presented on primary axis..
successfully established due to lack of Cid on
the Iur, with no radio bearer setup message
sent (based on procedure count, not RBs).
Presented on primary axis..
ss_LackCidIub

the Iub, with no radio bearer setup message
ss_4Unused

successfully established, with no radio bearer
count, not RBs). Screening : unused .
ss_LackOfNodeBDlProcessingResourc
es

successfully established due to unavailable
DL NodeB processing resources or NodeB
processing resources if global capacity is
used, with no radio bearer setup message
ss_LackOfNodeBUlProcessingResourc
es

successfully established due to unavailable
UL NodeB processing resources, with no
radio bearer setup message sent (based on
ss_LackCidIu

the Iu, with no radio bearer setup message
primary axis..

Table 8-17: Properties of View Radio_Bearer_Establishment_Unsuccess_Per_Cause
8.2.2.5.6 Radio Bearer Performance

This view provides the main indicators of RB reconfiguration, giving an idea of the percentage of calls
for which the RB procedure was successful and detailing as well the two main causes for failures
(timeout and RadioBearerReconfigurationFailure). As a tabular information it is also possible to have
the RadioBearerReconfigurationAttempts_RB005.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 94/275
Name
Radio_Bearer_Performance
Description
Radio_Bearer_Performance setup at RNC level.
Graph
Families
DASHBOARD
TRAFFIC
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RadioBearerReconfigurationAttempts
_RB005_C(URB005_C)(Event)
Total number of Radio Bearer Reconfigurations

attempts - Cell level
RadioBearerReconfigurationSuccess
Rate_RB015_C(URB015_C)(%)
Radio Bearer Reconfiguration success rate
VS_RadioBearerReconfigurationUnsu
ccess_RadioBearerReconfigurationFa
ilure(U616_1)(Event) and
VS_RadioBearerReconfigurationUnsu
ccess_Timeout(U616_0)(Event)
Number of radio bearer reconfiguration not

successfully established
8.2.2.5.7 Radio_Link_Reconfiguration
This view is useful to have statistics on the Radio Link Reconfiguration procedure.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 95/275
Radio_Link_Reconfiguration - RNC: RNC2005 ( RNC2005 ) - 08/26/2008 To

09/15/2008 (Working Zone: Global - Medium)
RNC2005
16000
120,00%
14000
100,00%
12000
80,00%
8000
60,00%
RadioLinkReconfigurationPreparationAt
tempt_RL030_CR(URL030_CR)
Event
10000
RadioLinkReconfigurationSuccessRate
_RL035_CR(URL035_CR)
6000
40,00%
4000
20,00%
2000
0,00%
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
2
0
09
/0 08
1/
20
09
08
/0
3/
20
09
08
/0
5/
2
0
09
/0 08
7/
20
09
08
/0
9/
20
09
08
/1
1/
20
09
08
/1
3/
20
09
08
/1
5/
20
08
Figure 8-20: Display of View Radio_Link_Reconfiguration.
Name
Radio_Link_Reconfiguration
Radio link reconfiguration performance (number of
preparation attempts and success rate)
Description
Graph
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RadioLinkReconfigurationPreparationAttempt_RL030_CR
RadioLinkReconfigurationSuccessRate_RL035_CR
Attempts to reconfigure a RL (SRLR

preparation) - Global metric. Presented on
primary axis.
Number of RL reconfiguration commit versus
the number of attempts. Presented on
primary axis.
Table 8-18: Properties of Radio Link Reconfiguration
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 96/275

8.2.2.5.8 Radio_Link_Reconfiguration_Prepare_Unsuccess_Per_Cause
This view gives the number of unsuccessful Radio Link Reconfiguration Preparation per cause. The
unsuccessful
management
of
Radio
Link
Reconfiguration
Preparation
(RADIO_LINK_RECONFIGURATION_FAILURE or TIMEOUT or Rrrm_refusal) is counted per radio
link and not per message.
VS_RadioLinkReconfigurationPrepareUnsu
ccess_unused(U8_3)
Radio_Link_Reconfiguration_Prepare_Unsuccess_Per_Cause
- RNC: RNC2005 (
RNC2005 ) - 08/26/2008 To 09/15/2008 (Working Zone: Global - Medium)
RNC2005
ccess_TimeoutNbap(U40_1)
1800
ccess_RrmRefusal(U40_2)
1600
ccess_RadioLinkReconfigurationFailure(U4
0_0)
1400
ccess_NodeBOutOfOrder(U40_8)
Event
1200
1000
ccess_NodeBCEMLackL1Rsrc(U40_4)
800
ccess_LackOfNodeBUlProcessingResourc
es(U8_5)
600
ccess_LackOfNodeBDlProcessingResourc
es(U8_4)
400
200
ccess_LackCidOrUdpPortIub(U40_5)
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
08
09
/0
1/
20
08
09
/0
3/
20
08
09
/0
5/
20
08
09
/0
7/
20
08
09
/0
9/
20
08
09
/1
1/
20
08
09
/1
3/
20
08
09
/1
5/
20
08
0
ccess_LackCid(U8_6)
ccess_LackBwthIub(U40_6)
Figure 8-21: Display of View Radio_Link_Reconfiguration_Prepare_Unsuccess_Per_Cause
Radio_Link_Reconfiguration_Prepare_Unsuccess_
Per_Cause
Name
Number of unsuccessful Radio Link Reconfiguration

Preparation per cause
Graph
Description
Families
DETAILED MONITORING
ACCESSIBILITY
Global
CELL
DETAILED MONITORING
ACCESSIBILITY
Global
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 97/275

Indicators
VS_RadioLinkReconfigurationPrepareUnsuccess_RadioLi
nkReconfigurationFailure (U40_0)
VS_RadioLinkReconfigurationPrepareUnsuccess_Timeout
Nbap (U40_1)
VS_RadioLinkReconfigurationPrepareUnsuccess_RrmRef
usal (U40_2)
VS_RadioLinkReconfigurationPrepareUnsuccess_IubLaye
rCongestion (U40_3)
VS_RadioLinkReconfigurationPrepareUnsuccess_NodeBC
EMLackL1Rsrc (U40_4)
VS_RadioLinkReconfigurationPrepareUnsuccess_LackCid
OrUdpPortIub (U40_5)
VS_RadioLinkReconfigurationPrepareUnsuccess_LackBwt
hIub (U40_6)
VS_RadioLinkReconfigurationPrepareUnsuccess_InodeRe
fusal (U40_7)
Number of unsuccessful Radio Link

Reconfiguration Preparation (Screening :
RADIO_LINK_RECONFIGURATION_FAILU
RE ). Presented on primary axis.
Timeout nbap). Presented on primary axis.
Rrm refusal). Presented on primary axis.(*)
Reconfiguration Preparation (Screening : Iub
Layer Congestion). Presented on primary
axis.
NodeB (CEM) lack of L1 resources).
Presented on primary axis. (**) (***)
Lack of Transport Identifier (CID or UDP
Port) on the Iub). Presented on primary axis.
Lack of bandwidth on the Iub). Presented on
primary axis.
INode refusal). Presented on primary axis.
Table 8-19: Properties of Radio_Link_Reconfiguration_Prepare_Unsuccess_Per_Cause
(*) The RRM Refusal screening is mainly pegged in case of lack unavailable DL power resources. This
counter
can
be
correlated
with
VS.RadioBearerEstablishmentUnsuccess.
UnavailableDlPowerResources counter.
(**) screenings LackOfNodeBDlProcessingResources and LackOfNodeBUlProcessingResources
have been removed from counter U40 as they are not implemented and screening NodeB (CEM) lack
of L1 resources has been added in UA06. It gives the number of RL Reconfigurations that fail to be
established due to lack of CEM resources. The advantage of this screening is that it will enable to link
the CEM unavailability to the user perceived call blocking.
(***) UA6 Live monitoring shows this screening NodeBCEMLackL1Resource is not incremented in
case of UL radio resources not available. It will not take into account the RNC CAC failure. Assuming
that UL Radio Ressource Not Available cause corresponds mainly to UL CEM issues the
VS.RadioLinkReconfigurationPrepareUnsuccess.NodeBCEMLackL1Rsrc counter should be correlated
with VS.RadioBearerEstablishmentUnsuccess.NodeBCEMLackofL1Resource.
8.2.2.5.9 Some useful other RB accessibility views

Name
Availability
Description
Comment
Number_Of_Rb_Blocked
CELL,
RNC
Number of RB not successfully

established (Radio Bearer Setup
message not sent)
Volume information to
complete RB blocking rate
given by Rb_Setup_Failure
views
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 98/275

Rb_Setup_Success_Cs
CELL,
RNC
Radio_Bearer_To_Be_Set
up_Rnc
RNC
up_Ps_Rnc
RNC
up_Hsdpa_Rnc
RNC
up_Hsupa_Rnc
RNC
up_Cs_Rnc
RNC
Irm_Cac_Ps_Rejection
RNC
Overview of radio bearer setup

phase (success, failures and
success rate)
Number of decisions to setup a
radio bearer and success rate at
RNC level
PS radio bearer and success rate
at RNC level
HSDPA radio bearer and success
rate at RNC level
HSUPA radio bearer and success
rate at RNC level
CS radio bearer and success rate
at RNC level
Number of PS RABs rejected due
to CAC failure (per PS RAB type)
and HSDPA CAC failure ratio.
Similar view available at Cell

level
Useful to analyse the RB setup
phase per service. Similar
view available at Cell level
Useful to investigate on PS
RAB accessibility issue due to
CAC failure
Table 8-20: List of some other useful accessibility views
8.2.3
Accessibility troubleshooting
Once the issue has been characterized thanks to detailed monitoring, a deeper analysis can be done
based on an accessibility troubleshooting report which includes indicators for all the steps allowing
the user to access CS or PS service (see accessibility call flow presented in Figure 8-2).
This report will be executed on the most impacted network elements for one or a few days during the
affected period with hourly or quarterly values if needed.
Hereunder is given an example of counters/indicators type needed for accessibility troubleshooting
(and present in the report).
Type of counters/indicators used for Troubleshooting Report by family
First Rrc Connection Request
RRC Failed Connection Establish (with causes)
RRC Failed Connection Establish Congestion (by services)
First Radio Link Setup Request
RRC Connection
Radio Link Setup Unsuccess
Phase
RL Setup Response/Failure related to the first radio link of a call
Accessi
bility
RRC Connection Success
Troubles
RRC Connection Reject Congestion
hooting
Report SCCP Connection RrcConnectionRelease_UnspecifiedSccpReleaseCause
Phase
RAB Assignment Request
Radio Link Reconfiguration Prepare Request (by service)
RAB
establishment
Radio Link Reconfiguration Prepare Success (by service)
Phase
Radio Link Reconfiguration Prepare Unsuccess (by causes)
Radio Link Reconfiguration Commit (by service)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 99/275
Quality
Radio Bearer Establishment Unsuccess

Radio Bearer Setup Request (by service)
Radio Bearer Setup Success (by service)
Radio Bearer Setup Unsuccess
Number Of RB Blocked
RAB Assignment Success (PerGranted, Success Rate,
RAB Establishment Attempts (by services)
RAB assignment setup unsuccess
EcN0 Distribution
RSCP Distribution
Distribution of Propagation Delay per Range
UL RSSI Distribution
Uplink Cell Load (avg, min, max)
Uplink RSSI (avg, min, max)
Radio Tx Carrier Power
Average Tx Power
Percentage Power Used (Power001_B)
Table 8-21: Counters/indicators needed for accessibility troubleshooting.
As an example, see this practical case where a PS accessibility issue is detected:
Comments: Two period of degradation is observed on the CSSR PS.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 100/275
Comments: Some degradation of the First RRC Connection Success Rate during the same period.
Comments: By focusing on the RRC procedure, we can determine with the sub-family RRC Failed
Connection Establish (with causes) the RRC Failed Connection distribution.
An analysis of the distribution failure allows to highlight the main contributor of these RRC degradation.
It is RRC_FailConnEstab_TimeoutRepeat.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 101/275
Comments: No issue observed during the Iu SCCP procedure
Comments: High degradation of the RAB Establishment success rate.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 102/275
Comments: The RAB Establishment

RAB_FailEstab_PS_DLPwr.
Success
Rate
is
mainly
impacted
by
the
In this example, the CSSR PS has been degraded following a blocked context issue which lead to cell
outage. This cell outage was the cause of the increase of:
TimeOut : This is a typical radio failure case for RRC Connection setup.
o
8.2.4
8.2.4.1
Definition: Timeout for first or any repeated RRC Connection Requests in the
N300*T300 window, when the 'RRC Connection Request' is received on the same cell
as the preceding attempt.
DLPwr : This issue occurred in the RAB procedure due to the Insufficient downlink power
resources after the celll outage.
UA7 counter validation (accessibility part)

Radio Bearer vs RAB Counters Assessment
In UA6.0 an assessment was made to detect discrepancies in the values of some of the RB counters
and RAB counters which did show some differences in values of these counters, In UA7.1 again the
assessment was made to follow up on the issue, so by comparing the values reported from these
counters between UA6.0 and U7.1. The results were as follows.
8.2.4.1.1 PS RAB Request counters:

The comparison of counters (#2607 + #2608 -> RAB AttEstab PS Sum) with counters (#2612 + #2613
-> RAB AttEstab PS TrChn) shows a big differences between these counters, Counters 2612 and
2613 are NOK. Attention is needed when consolidating the below Indicators which use counters 2612
and 2613:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 103/275

o
UHSDPA044_CR_ONB
URAB038_C_DchDch, URAB038_I_DchDch
URAB038_C_Hsdsch, URAB038_I_Hsdsch
URAB038_CR_EdchHsdsch, URAB038_I_EdchHsdsch
8.2.4.1.2 PS RAB Success counters:

The comparison of counters (#2620 + #2621 -> RAB SuccEstab PS Sum) with counters (#2622 +
#2623 -> RAB SuccEstab PS) shows big differences between these counters, Counters 2622 and
2623 are NOK
8.2.4.1.3 PS RAB Failed counters:

The comparison of the number of failures tracked by counters #2631 and #2632 (RAB FailEstab PS)
to the number of RAB that failed to be established computed by ((#2607+#2608) (#2620+#2621))
shows big differences between these counters, Counters #2631 and #2632 are NOK ,they dont
seem to count all failures. Attention is needed when consolidating the below Indicators which use
counters 2631 and 2632 :
o
URAB039_C_PS, URAB039_I_PS
Utraffic039_CR, Utraffic039_R
UUu001_C, UUu001_R
8.2.4.1.4 EDCH counters

In UA6.0 The comparison of counter #2612.2 (RAB_AttEstab_PS_TrChn_EDCH_HSDSCH) with
counter #1652.16 (VS_RadioBearerSetupRequest_TgtCallHsdpaEdch) shows big differences
between these counters, counter 1652.16 is NOK.
Impact on metrics: Counter 1652.16 is used in the following baseline Indicators
o
URB008_C_Hsupa
URB008_C_PS
Ucell012_R
8.2.4.1.5 HSDPA counters

The comparison of counters for HSDPA RAB Attempts (#2612.1 + #2612.2 ->
RAB_AttEstab_PS_TrChn for HSDSCH) with counters for HSDPA RB Attempts (#1652.15 + #1652.16
-> VS_RadioBearerSetupRequest for Hsdpa) shows big differences between these counters,
Counter 1652.15 is NOK
Counter 1652.15 is used in following baseline Indicators
o
URB008_C_Hsdpa
URB008_C_PS
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 104/275

o
Ucell012_R
8.2.4.1.6 PS RAB vs. RB counters

The comparison of counters for PS RAB Attempts (#2607 + #2608 -> RAB_AttEstab_PS_Sum) with
counters for PS RB Attempts (#1652 + #1635 -> VS_RadioBearerSetupRequest) shows big
differences between these counters,Counter 1635 is NOK for PS screenings.
8.2.4.1.7 CS RAB counters

In UA6.0 The comparison of counters for CS RAB Failed (#2629 + #2630 -> RAB_FailEstab_CS) with
the number of CS RAB that failed to be allocated computed with the following formula ((#2605 +
#2606) - (#2618 + #2619) -> (RAB AttEstab CS - RAB SuccEstab CS)), shows slight differences
between these counters
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 105/275
8.3.
MOBILITY MONITORING AND TROUBLESHOOTING
The Mobility domain cover different type of mobility procedures such as Cell update, RRC Redirection,
HHO 3G2G, HHO 3G3G, HSPA Primary Cell Change, SHO and URA update as well as different
scenarios for Inter RNC mobility. Hereunder RRC Redirection and mobility in HHO will be described in
detail. Information on the monitoring of mobility procedures linked to specific mobility features can be
found in the corresponding FSM. For UA07 features, FSMs are stored at:
8.3.1
RRC Redirection mobility monitoring
On RRC establishment from idle mode UTRAN has capabilities and load information of the originating
and twin FDD cells and can get from the RRC Connection Request message the UE capability and the
establishment cause.
iMCRA allows redirecting UE to another FDD at RRC connection establishment, based on their
release and possibly on the Traffic Class sent to RNC in RRC Connection Request message and
redirecting different establishment causes based on service type to the preferred frequency allocation;
On CAC failure redirection to another frequency is possible, too.
3G2G Redirection based on cell load allows redirecting Originating Conversational call or
Emergency call to GSM when the cell load on the originating UMTS cell reaches a configurable
threshold.
The main metrics to check for FDD redirection are the RRC Redirection volume and the RRC Success
Rate for causes eligible for redirection. In UA7 configuration, the establishment causes eligible for
redirection are: Registration, OrigBgrdCall, OrigHighPrioSig, OrigIntactCall, OrigStrmCall,
OrigSubscCall, TermBgrdCall, TermIntactCall and TermStrmCall.
GSM redirections can be
RRC_Connection_ReAttempt.
based
on
RRC_FailConnEstab_3G2GRedirectEmergency
and
At the time of RRC establishment UTRAN has no information if the target cell (FDD or GSM) has
sufficient coverage at the UE location, no measurement information is available and the redirection is
performed in blind mode. Failures on redirection can happen due to:
Unexpected handling for RRC redirection failures;
Target cells having shorter coverage than originating cell (i.e. from U850 layer to U2100 layer);
Target cells having congestion (this could be induced on redirection cells by strategies based
on traffic segmentation and not on load balancing);
The expected management for the RRC redirection failures (to target FDD or target GSM) is the
following: if the UE can not synchronize on the new frequency, UE sends again RRC Connection
Request with same cause from originating cell within time rcCnxRepeatTime. When receiving this
second RRC connection request with the same cause, the RNC will not try to redirect the mobile again
and will setup the RRC connection in originating cell (The RNC will never redirect the following RRC
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 106/275

Connection Requests received in the same cell (within N300*T300)). The following figure details the
process:
UE
Node B
RNC
The RRC Connection Request message initiated

by the UE contains the establishment cause.
RRC/ RACH / RRC connection Request

(cause)
RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,
..)
SGSN
The UE is redirected to the other layer

The UE fails to synchronise on the target layer.
RRC/ RACH / RRC connection Request

(cause)
RRC/ FACH / RRC Connection Setup (DCCH, U-RNTI,
)
The RRC connection request is sent again in the

originating cell
The RNC does not try to redirect again and
proceeds on this cell
RRC/ RACH / RRC Connection Setup Complete
Figure 8-22: Management for the RRC redirection failures
8.3.1.1
Global RRC Redirection mobility views
RRC_Redirection_Volume_per_cause
This view provides an overview for the RRC Redirection volume per establishment cause. Please note
that with RRC Redirection the Accessibility view per cell will be not accurate due to RRC Connection
Request sent on Cell 1 and RRC Connection Setup Complete sent on Cell 2. Accessibility KPIs should
be retrieved at least for the entire group of collocated cells eligible for Redirection.
RRC_Redirect ion_Volume_per_cause
3000
2500
Event
2000
1500
1000
500
04
/0
5/
20
04
10
/0
6/
20
04
10
/0
7/
20
04
10
/0
8/
20
04
10
/0
9/
20
04
10
/1
0/
20
04
10
/1
1/
20
04
10
/1
2/
20
04
10
/1
3/
20
04
10
/1
4/
20
04
10
/1
5/
20
04
10
/1
6/
20
04
10
/1
7/
20
04
10
/1
8/
20
04
10
/1
9/
20
04
10
/2
0/
20
04
10
/2
1/
20
04
10
/2
2/
20
04
10
/2
3/
20
04
10
/2
4/
20
04
10
/2
5/
20
04
10
/2
6/
20
04
10
/2
7/
20
04
10
/2
8/
20
10
VS_RrcConnectAt tIncoming_CallReestab(U423_12)
VS_RrcConnectAt tIncoming_EmergCall(U423_15)
VS_RrcConnectAt tIncoming_OrigBgrdCall(U423_3)
VS_RrcConnectAt tIncoming_OrigConvCall(U423_0)
VS_RrcConnectAt tIncoming_OrigHighPrioSig(U423_10)
VS_RrcConnectAt tIncoming_OrigIntactCall(U423_2)
VS_RrcConnectAt tIncoming_OrigLowPrioSig(U423_11)
VS_RrcConnectAt tIncoming_OrigStrmCal(U423_1)
VS_RrcConnectAt tIncoming_OrigSubscCall(U423_4)
VS_RrcConnectAt tIncoming_Other(U423_16)
VS_RrcConnectAt tIncoming_Registrat ion(U423_9)
VS_RrcConnectAt tIncoming_TermBgrdCall(U423_8)
VS_RrcConnectAt tIncoming_TermConvCall(U423_5)
VS_RrcConnectAt tIncoming_TermHighPrioSig(U423_13)
VS_RrcConnectAt tIncoming_TermInt act Call(U423_7)
VS_RrcConnectAt tIncoming_TermLowPrioSig(U423_14)
VS_RrcConnectAt tIncoming_TermStrmCall(U423_6)
Figure 8-23: Display of View RRC_Redirection_Volume_per_cause
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 107/275
Name
RRC_Redirection_Volume_per_cause
Overview for the RRC Redirection volume per establishment
cause.
Graph
Description
Families
DASHBOARD
ACCESSIBILITY_GLOBAL
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_RrcConnectAttIncoming_(all screenings)
Number of times that RNC instructs

UE to setup a call on a different cell
with a different frequency from the
initial RACH;
Table 8-22: Properties of View RRC_Redirection_Volume_per_cause
RRC_SuccessRate_per EstablishmentCause
This view provides an overview for the RRC Redirection Success Rate per establishment cause.
Please note that with RRC Redirection the Accessibility view per cell will be not accurate due to RRC
Connection Request sent on Cell 1 and RRC Connection Setup Complete sent on Cell 2. Accessibility
KPIs should be retrieved at least for the entire group of collocated cells eligible for Redirection.
100,0%
99,5%
99,0%
98,5%
98,0%
97,5%
97,0%
96,5%
05
/0
4/
20
10
06
/0
4/
20
10
07
/0
4/
20
10
08
/0
4/
20
10
09
/0
4/
20
10
10
/0
4/
20
10
11
/0
4/
20
10
12
/0
4/
20
10
13
/0
4/
20
10
14
/0
4/
20
10
15
/0
4/
20
10
16
/0
4/
20
10
17
/0
4/
20
10
18
/0
4/
20
10
19
/0
4/
20
10
20
/0
4/
20
10
21
/0
4/
20
10
22
/0
4/
20
10
23
/0
4/
20
10
24
/0
4/
20
10
25
/0
4/
20
10
26
/0
4/
20
10
27
/0
4/
20
10
96,0%
RRCConnect ionSuccessRat e_RRC003_CR_OrigBgrdCall
RRCConnectionSuccessRat e_RRC003_CR_OrigConvCall
RRCConnect ionSuccessRat e_RRC003_CR_OrigHighPrioSig
RRCConnect ionSuccessRat e_RRC003_CR_OrigInt act Call
RRCConnectionSuccessRat e_RRC003_CR_OrigLowPrioSig
RRCConnect ionSuccessRat e_RRC003_CR_OrigSt rmCal
RRCConnect ionSuccessRat e_RRC003_CR_OrigSubscCall
RRCConnectionSuccessRat e_RRC003_CR_TermConvCall
RRCConnect ionSuccessRat e_RRC003_CR_TermInt act Call
RRCConnect ionSuccessRat e_RRC003_CR_TermLowPrioSig
RRCConnectionSuccessRat e_RRC003_CR_TermSt rmCall
RRCConnect ionSuccessRat e_RRC003_CR_Int erRAT
RRCConnect ionSuccessRat e_RRC003_CR_Regist rat ion
Figure 8-24: Display of View RRC_SuccessRate_per EstablishmentCause
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 108/275
Name
RRC_SuccessRate_per EstablishmentCause
Overview for the RRC Redirection Success Rate per
establishment cause.
Graph
Description
Families
DASHBOARD
ACCESSIBILITY_GLOBAL
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RRCConnectionSuccessRate_RRC003_CR_ (all screenings)
RRC_AttConnEstab_(all screenings)
Number of RRC connection success vs RRC

connection requests. This metric shows the
success rate of the first step of accessibility.
This metric takes into account the RRC
establishment repetitions that can be
transparent for the user.
Number of RRC connection request
received;
Table 8-23: Properties of View RRC_SuccessRate_per EstablishmentCause
In parallel several load indicators could be assessed (also valid for iMCTA). If iMCRA strategy is
based in a concept of Load Balancing (i.e. RRC Redirection triggered based on cell load), it may be
useful to check the main cause to trigger RRC Redirection. The following graphic provides the main
cause to trigger YELLOW or RED colour and thus RRC Redirection based on cell colour. It may be
useful to decide for fine tuning threshold parameters for each Load Criterion: green2Yellow;
yellow2Red; red2Yellowyellow2Green.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 109/275
Aggregate_Load_Color
100%
90%
80%
Event
70%
60%
50%
40%
30%
20%
10%
04
/0
5
04 /2 0
/0 10
6
04 /2 0
/0 10
7
04 /2 0
/0 10
8
04 /2 0
/0 10
9
04 /2 0
/1 10
0
04 /2 0
/1 10
1
04 /2 0
/1 10
2
04 /2 0
/1 10
3
04 /2 0
/1 10
4
04 /2 0
/1 10
5
04 /2 0
/1 10
6
04 /2 0
/1 10
7
04 /2 0
/1 10
8
04 /2 0
/1 10
9
04 /2 0
/2 10
0
04 /2 0
/2 10
1
04 /2 0
/2 10
2/
04 2 0
/2 10
3
04 /2 0
/2 10
4
04 /2 0
/2 10
5
04 /2 0
/2 10
6
04 /2 0
/2 10
7
04 /2 0
/2 10
8/
20
10
0%
VS_IrmTimeDlIubTransportColorRed_DlPsIbDch_Avg(U1182_0_Avg)
VS_IrmTimeDlIubTransportColorYellow _DlPsIbDch_Avg(U1183_0_Avg)
VS_IRMTimeULRadioLoadColorRed_Avg(U1194_Avg)
VS_IRMTimeULRadioLoadColorYellow _Avg(U1193_Avg)
VS_IRMTimeCellRadioColorRed_Avg(U1124_Avg)
VS_IRMTimeCellRadioColorYellow _Avg(U1125_Avg)
VS_QosDlCemLdClrRed_Avg(U1178_Avg)(%)
VS_QosDlCemLdClrYellow _Avg(U1177_Avg)(%)
VS_QosUlCemLdClrRed_Avg(U1181_Avg)(%)
VS_QosUlCemLdClrYellow _Avg(U1180_Avg)(%)
Figure 8-25: Display of View Aggregate_Load_Color
Some other interesting views can be built manually since they present information from different layers
in the same graphic (not possible to retrieve directly with NPO). In the mobility strategies it may be
helpful presenting for instance the DL/UL traffic profile across layers at Radio Bearer Setup and during
call to assess the traffic distribution. The following graphic provides the flux of RRC Redirections
between layers. It clearly shows the flux of RRC Redirections is mainly from FDD1 to FDD2. This
information can be used to ensure that a specific layer will be often more loaded.
VS_RrcConnectAttIncoming_ON_FDD1
VS_RrcConnectAttIncoming_ON_FDD2
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
05
/0
4/
06 2 01
0
/0
4/
07 2 01
0
/0
4/
08 2 01
0
/0
4/
09 2 01
0
/0
4/
10 2 01
0
/0
4/
11 2 01
0
/0
4/
12 2 01
0
/0
4/
13 2 01
/0
0
4/
14 2 01
0
/0
4/
15 2 01
0
/0
4/
16 2 01
0
/0
4/
17 2 01
0
/0
4/
18 2 01
0
/0
4/
19 2 01
0
/0
4/
20 2 01
/0
0
4/
21 2 01
0
/0
4/
22 2 01
0
/0
4/
23 2 01
0
/0
4/
24 2 01
0
/0
4/
25 2 01
0
/0
4/
26 2 01
0
/0
4/
27 2 01
0
/0
4/
20
10
0%
Figure 8-26: Example of flux of RRC Redirections between layers
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 110/275
8.3.2
3G3G mobility monitoring
Hard Handover 3G3G procedure can be analysed for different iMCTA triggering: Alarm, CAC and
Service. The following 3G3G hard handover procedures are supported in UA07 (details on message
flow can be consulted on UPUG Volume 13):
3G to 3G Inter-frequency Inter-RNC HHO (Handover over IuR or SRNS relocation UE

Involved);
3G to 3G Inter-frequency Intra-RNC HHO (normal handover with RB reconfiguration);
3G to 3G Intra-frequency Inter-RNC HHO (if IuR is not provisioned this SHO will be handled
like an HHO using SRNS relocation UE Involved);
iMCTA algorithm handles the decision for Inter-Frequency and Inter-RAT handovers.
To have a correct view on iMCTA configuration and performance it is also important to assess the
compressed mode profile and distribution to know if compressed mode activation is leading to HHO
detection.
Furthermore, it is problematic triggering Alarm to rescue calls between layers that have limited overlay
and different exit zones; it is always advised to rescue calls to continuous layers. For CAC and Service
it is recommended activating them in between FDD co localised cells and never in mono frequency
cells if GSM is set to PNA in priority tables.
Failures on Hard Handover 3G3G can happen due to:
Bad neighbouring relations;
Congestion on target cell (this can be avoided with proper mobility strategy);
Wrong strategy settings on compressed mode configuration like GSM and FDD patterns (this
can lead to some IOT issues with UEs and to late measurement reported from the UE thus
delaying HHO detection);
Wrong strategy settings on Priority Tables configuration (this can lead to ping-pong situations,
asymmetric traffic load balancing);
Wrong strategy settings on target cells for HHO (this can lead to consecutive compressed
mode reactivations without leading to detection; in such cases there is a risk of desynchronization with UE each time compressed mode is reactivated leading to Call drops);
Wrong strategy settings on reporting events thresholds (this can lead to huge amount of
reporting events and unneeded compressed mode activations leading to worst UL BLER or to
late compressed mode activation and consequent call drop);
The main metrics to check for Hard Handover 3G3G are:
Compressed Mode attempts and activation Success Rate;
Attempts and distribution for Event 2D reported;
Rate of CM Activation Leading To Detection;
Inter Frequency HHO attempts for iMCTA Alarm, CAC and Service;
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 111/275
Inter Frequency HHO attempts distribution for iMCTA Alarm, CAC and Service;
Inter Frequency HHO Success rate for iMCTA Alarm, CAC and Service;
8.3.2.1
Global 3G3G mobility views for compressed mode
Compressed_Mode_profile
This view provides an overview for compressed mode activation distribution and volume and well as in
compressed mode activation per hour; despite not being included, this profile can be completed with
number of compressed mode activations per Radio Bearer Setup. Objective is assessing if volume of
compressed mode in balanced in the network.
120000
10
100000
80000
nb
Event
140000
60000
4
40000
2
20000
05
/1
5/
20
10
05
/1
7/
20
10
05
/1
9/
20
10
05
/2
1/
20
10
05
/2
3/
20
10
05
/2
5/
20
10
05
/2
7/
20
10
05
/2
9/
20
10
05
/3
1/
20
10
06
/0
2/
20
10
06
/0
4/
20
10
06
/0
6/
20
10
06
/0
8/
20
10
06
/1
0/
20
10
06
/1
2/
20
10
06
/1
4/
20
10
VS_CmActivationSuccess_InterFrequency(U1004_1)
VS_CmActivationSuccess_GSMAndInterFrequency(U1004_2)
VS_CmActivationSuccess_GSM(U1004_0)
CompressedModeActivationPerHour_Meas004_R_InterFreq(UMeas004_R_InterFreq)
CompressedModeActivationPerHour_Meas004_R_GSMandInterFreq(UMeas004_R_GSMandInterFreq)
CompressedModeActivationPerHour_Meas004_R_GSM(UMeas004_R_GSM)
Figure 8-27: Display of View Compressed_Mode_profile
Name
Overview for compressed mode activation distribution and
volume and well as in compressed mode activation per hour.
Graph
Description
Families
MOBILITY_COMPRESSED
MODE
DASHBOARD
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 112/275

OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
CompressedModeActivationPerHour_Meas004_R_GSM
CompressedModeActivationPerHour_Meas004_R_GSMandInt
erFreq
CompressedModeActivationPerHour_Meas004_R_InterFreq
VS_CmActivationSuccess_GSM
VS_CmActivationSuccess_InterFrequency
VS_CmActivationSuccess_GSMAndInterFrequency
VS_CmActivationFailure_GSM
VS_CmActivationFailure_InterFrequency
VS_CmActivationFailure_GSMAndInterFrequency
Successful Compressed Mode activations

GSM per hour
Inter Frequency per hour
GSM and Inter Frequency per hour
Number of successful Compressed Mode
activations GSM
activations Inter Frequency
activations GSM and Inter Frequency
Number of failed Compressed Mode
activations GSM
activations Inter Frequency
activations GSM and Inter Frequency
Table 8-24: Properties of View Compressed_Mode_profile
Compressed_Mode_distribution
This view provides an overview for the attempts and distribution for Event 2D reported for iMCTA
Alarm as well as the overall Rate of CM Activation Leading to Detection (Alarm, CAC and Service).
Please note that the compressed mode can be also activated for iMCTA Service and CAC reason,
without 2d event, meaning no straight correlation between event 2d and Rate of CM Activation
Leading to Detection. However, only for iMCTA Alarm exist the possibility to reactivate the
compressed mode consecutively if no eligible cell is selected for HHO.
160000
76,49%
140000
Event
100000
56,49%
80000
66,49%
120000
46,49%
60000
40000
36,49%
20000
26,49%
05
/1
5/
20
10
05
/1
7/
20
10
05
/1
9/
20
10
05
/2
1/
20
10
05
/2
3/
20
10
05
/2
5/
20
10
05
/2
7/
20
10
05
/2
9/
20
10
05
/3
1/
20
10
06
/0
2/
20
10
06
/0
4/
20
10
06
/0
6/
20
10
06
/0
8/
20
10
06
/1
0/
20
10
06
/1
2/
20
10
06
/1
4/
20
10
VS_MeasEvent2DCell_CpichRscp(U1023_1)
VS_MeasEvent2DCell_CpichEcNo(U1023_0)
RateofInterFrequencyCMActivationLeadingToDetection_IMCTA026_R(UIMCTA026_R)
RateofCMActivationLeadingToDetection_HO3G2G025_R(UHO3G2G025_R)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 113/275

Figure 8-28: Display of View Compressed_Mode_distribution
Name
Overview for the attempts and distribution for Event 2D
reported for iMCTA Alarm as well as the overall Rate of CM
Activation Leading to Detection (Alarm, CAC and Service).
Graph
Description
Families
MOBILITY_COMPRESSED
MODE
DASHBOARD
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
VS_MeasEvent2DCell_CpichEcNo
VS_MeasEvent2DCell_CpichRscp
CompressedModeActivationPerHour_Meas004_R_InterFreq
RateofCMActivationLeadingToDetection_HO3G2G025_R
RateofInterFrequencyCMActivationLeadingToDetection_IMCT
A026_R
Number of Event 2D (used for Alarm

Measurement Criteria).Screening :
Triggering quantity is CPICH EcNo.
Number of Event 2D (used for Alarm
Measurement Criteria).Screening :
Triggering quantity is CPICH Rscp.
GSM and Inter Frequency per hour
Rate of Compressed Mode activation leading
to a detection of HHO 3G2G
Compressed mode activation success rate
(Inter-frequency measurements)
Table 8-25: Properties of View Compressed_Mode_distribution
8.3.2.2
Global 3G3G mobility views for Inter Frequency Intra RNC
Handover_3G3G_iMCTA_CAC
This view provides an overview for the 3G3G iMCTA CAC intra RNC performance.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 114/275
95,69%
1200
85,69%
1000
75,69%
800
65,69%
600
55,69%
400
45,69%
200
35,69%
25,69%
1400
04
/2
1/
20
04
10
/2
2/
20
04
10
/2
3/
20
04
10
/2
4/
20
04
10
/2
5/
20
04
10
/2
6/
20
04
10
/2
7/
20
04
10
/2
8/
20
04
10
/2
9/
20
04
10
/3
0/
20
05
10
/0
1/
20
05
10
/0
2/
20
05
10
/0
3/
20
05
10
/0
4/
20
05
10
/0
5/
20
05
10
/0
6/
20
05
10
/0
7/
20
05
10
/0
8/
20
05
10
/0
9/
20
05
10
/1
0/
20
05
10
/1
1/
20
10
Event
VS_IncomInterFreqHoAtt_NoRsrcAvailCacFailure(U176_2)
OutgoingInterFrequencyHHOSuccessrateforiMCTA_IMCTA014_CR_Cac(UIMCTA014_CR_Cac)
Figure 8-29: Display of View Handover_3G3G_iMCTA_CAC
Name
Description
Overview for the 3G3G iMCTA CAC intra RNC performance.
Graph
Families
DASHBOARD
MOBILITY_HHO 3G3G
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_IncomInterFreqHoAtt_NoRsrcAvailCacFailure
OutgoingInterFrequencyHHOSuccessrateforiMCTA_IMCTA01
4_CR_Cac
Number of Hard Handovers attempted to this

cell located on Serving RNC from another
cell on a different frequency from the same
RNC for CAC
Outgoing inter-frequency HHO success rate
for IMCTA Cac
Table 8-26: Properties of View Handover_3G3G_iMCTA_CAC
Handover_3G3G_iMCTA_ALARM
This view provides an overview for the 3G3G iMCTA ALARM intra RNC performance.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 115/275

96,33%
3000
91,33%
2500
86,33%
81,33%
%
Event
2000
1500
76,33%
1000
71,33%
500
66,33%
61,33%
04
/2
1/
20
10
04
/2
2/
20
04
10
/2
3/
20
04
10
/2
4/
20
10
04
/2
5/
20
04
10
/2
6/
20
04
10
/2
7/
20
10
04
/2
8/
20
04
10
/2
9/
20
04
10
/3
0/
20
10
05
/0
1/
20
05
10
/0
2/
20
05
10
/0
3/
20
10
05
/0
4/
20
05
10
/0
5/
20
05
10
/0
6/
20
10
05
/0
7/
20
05
10
/0
8/
20
05
10
/0
9/
20
10
05
/1
0/
20
05
10
/1
1/
20
10
VS_IncomInterFreqHoAtt_Rescue(U176_0)
OutgoingInterFrequencyHHOSuccessrateforiMCTA_IMCTA014_CR_Alarm(UIMCTA014_CR_Alarm)
Figure 8-30: Display of View Handover_3G3G_iMCTA_ALARM
Name
Overview for
performance.
Graph
Description
the
3G3G
iMCTA
ALARM
intra
RNC
Families
DASHBOARD
MOBILITY_HHO 3G3G
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_IncomInterFreqHoAtt_Rescue
4_CR_Alarm

RNC for Alarm
for IMCTA Alarm
Table 8-27: Properties of View Handover_3G3G_iMCTA_ALARM
Handover_3G3G_iMCTA_SERVICE
This view provides an overview for the 3G3G iMCTA SERVICE intra RNC performance.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 116/275
700
90,51%
600
85,51%
500
75,51%
Event
80,51%
400
300
70,51%
200
65,51%
100
60,51%
04
/2
1/
20
10
04
/2
2/
20
04
10
/2
3/
20
04
10
/2
4/
20
10
04
/2
5/
20
04
10
/2
6/
20
04
10
/2
7/
20
10
04
/2
8/
20
04
10
/2
9/
20
04
10
/3
0/
20
10
05
/0
1/
20
05
10
/0
2/
20
05
10
/0
3/
20
10
05
/0
4/
20
05
10
/0
5/
20
05
10
/0
6/
20
10
05
/0
7/
20
05
10
/0
8/
20
05
10
/0
9/
20
10
05
/1
0/
20
05
10
/1
1/
20
10
VS_IncomInterFreqHoAtt_Service(U176_1)
OutgoingInterFrequencyHHOSuccessrateforiMCTA_IMCTA014_CR_Service(UIMCTA014_CR_Service)
Figure 8-31: Display of View Handover_3G3G_iMCTA_SERVICE
Name
Overview for the 3G3G iMCTA SERVICE intra RNC
performance.
Graph
Description
Families
DASHBOARD
MOBILITY_HHO 3G3G
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_IncomInterFreqHoAtt_Service
4_CR_Service

RNC for SERVICE
for IMCTA Service
Table 8-28: Properties of View Handover_3G3G_iMCTA_SERVICE
Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Cause_Distribution
This view provides an overview for the Inter Frequency HHO attempts distribution for iMCTA Alarm,
CAC and Service.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 117/275

100,0%
90,0%
80,0%
70,0%
60,0%
50,0%
40,0%
30,0%
20,0%
10,0%
04
/2
1/
20
10
04
/2
2/
20
10
04
/2
3/
20
10
04
/2
4/
20
10
04
/2
5/
20
10
04
/2
6/
20
10
04
/2
7/
20
10
04
/2
8/
20
10
04
/2
9/
20
10
04
/3
0/
20
10
05
/0
1/
20
10
05
/0
2/
20
10
05
/0
3/
20
10
05
/0
4/
20
10
05
/0
5/
20
10
05
/0
6/
20
10
05
/0
7/
20
10
05
/0
8/
20
10
05
/0
9/
20
10
05
/1
0/
20
10
05
/1
1/
20
10
0,0%
OutgoingInterFrequencyHHOAttemptDistributionforiMCTA_IMCTA007_CR_Service(UIMCTA007_CR_Service)
OutgoingInterFrequencyHHOAttemptDistributionforiMCTA_IMCTA007_CR_Cac(UIMCTA007_CR_Cac)
OutgoingInterFrequencyHHOAttemptDistributionforiMCTA_IMCTA007_CR_Alarm(UIMCTA007_CR_Alarm)
Figure 8-32: Display of View Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Cause_Distribution
Name
Overview for the Inter Frequency HHO attempts distribution for
iMCTA Alarm, CAC and Service.
Graph
Description
Families
DASHBOARD
MOBILITY_HHO 3G3G
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
OutgoingInterFrequencyHHOAttemptDistributionforiMCTA_IM
CTA007_CR_Alarm
CTA007_CR_Cac
CTA007_CR_Service
Percentage of outgoing inter-frequency HHO

attempts triggered by IMCTA Alarm
attempts triggered by IMCTA Cac
attempts triggered by IMCTA Service
Table 8-29: Properties of View Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Cause_Distribution
8.3.2.3
Global 3G3G mobility views for Inter Frequency Inter RNC
SRNS_UE_Involved_Performance
In UA6, this view provides an overview for the Inter Frequency Inter RNC HHO performance with or
without IuR (if IuR not present it will also provide a view for Intra Frequency Inter RNC). In UA7 if
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 118/275

isInterFreqHandoverOverIurAllowed= TRUE (IuR provided) this view provides only an overview for
fallback in case of first failure in IuR procedure.
500
50,00%
400
40,00%
300
30,00%
200
20,00%
100
10,00%
0,00%
05
/1
5
05 /2 0
/1 10
6
05 /2 0
/1 10
7
05 /2 0
/1 10
8
05 /2 0
/1 10
9
05 /2 0
/2 10
0
05 /2 0
/2 10
1/
05 2 0
/2 10
2
05 /2 0
/2 10
3
05 /2 0
/2 10
4
05 /2 0
/2 10
5
05 /2 0
/2 10
6
05 /2 0
/2 10
7
05 /2 0
/2 10
8/
05 2 0
/2 10
9
05 /2 0
/3 10
0
05 /2 0
/3 10
1
06 /2 0
/0 10
1
06 /2 0
/0 10
2
06 /2 0
/0 10
3/
06 2 0
/0 10
4
06 /2 0
/0 10
5
06 /2 0
/0 10
6/
20
10
Event
SRNSRelocPrepAttemptsUEInvolv_HO3G3G026_C_Cs(UHO3G3G026_C_Cs)
SRNSRelocPrepAttemptsUEInvolv_HO3G3G026_C_Ps(UHO3G3G026_C_Ps)
SRNSRelocOverallSuccessRateUEInvolv_HO3G3G021_C(UHO3G3G021_C)
Figure 8-33: Display of View SRNS_UE_Involved_Performance
Name
Description
Overview for SRNS Relocation UE Involved.
Graph
Families
DASHBOARD
MOBILITY_RELOCATIONS
CELL/RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
SRNSRelocPrepAttemptsUEInvolv_HO3G3G026_C_Cs
SRNSRelocPrepAttemptsUEInvolv_HO3G3G026_C_Ps
SRNSRelocOverallSuccessRateUEInvolv_HO3G3G021_C
SRNSRelocSuccessUEInvolv_HO3G3G024_C_Cs
SRNSRelocSuccessUEInvolv_HO3G3G024_C_Ps
UMT/IRC/INF/012027
07.02 /EN
Attempted relocation preparations in context

UE involved SRNS relocation for CS domain
- Cell level
Attempted relocation preparations in context
UE involved SRNS relocation for PS domain
- Cell level
Overall SRNS Relocation (UE Involved)
Success Rate (KPI-40a)
Successful relocations with UE involved for
CS domain (cause: 'Successful Relocation' )
- Cell level
Successful relocations with UE involved for
PS domain (cause: 'Successful Relocation' )
- Cell level
Preliminary
25/June/2010
Page 119/275

Table 8-30: Properties of View SRNS_UE_Involved_Performance
InterFreq_InterRNC_HHO_overIuR
In UA7 if isInterFreqHandoverOverIurAllowed = TRUE UA7 system is able to use Iur to handle Inter
Frequency Inter RNC procedure and make use of the RNSAP protocol between RNCs (feature only
available in UA6 for US Market). The following view only applies for those cases where the source cell
is on a neighbouring RNC: handover within a DRNC; handover from one DRNC to another DRNC;
handover from DRNC back to SRNC. HHO_AttOutInterFreq should be used instead for Inter
Frequency Inter RNC HHO over IuR from SRNC to DRNC. However, this last counter includes also all
Inter Frequency Intra RNC HHO (new indicators will be soon available to isolate the Inter RNC HHO
from SRNC).
Name
InterFreq_InterRNC_HHO_overIuR
Description
Overview for Inter Frequency Inter RNC over Iur.
Graph
Families
DASHBOARD
MOBILITY_HHO 3G3G
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
HHO_AttOutInterFreq_NeighbRnc
InterFrequencyHHOInterRNCoverIurSuccessRate_UHO3G3G
036_R
HHO_AttOutInterFreq_RSCP_NeighbRnc
HHO_AttOutInterFreq_EcNo_NeighbRnc
HHO_SuccOutInterFreq_NeighbRnc
HHO_SuccOutInterFreq_RSCP_NeighbRnc
HHO_SuccOutInterFreq_EcNo_NeighbRnc
Total number of attempted outgoing interfrequency hard handovers.

Success Rate for outgoing inter-frequency
hard handovers. The PM is not counted
when the inter-frequency hard handover is
part of an SRNS relocation. Pegged on the
NeighbouringRnc.
Attempted outgoing inter-frequency hard
handovers due to insufficient RSCP quality
of the used frequency.
Attempted outgoing inter-frequency hard
handovers due to insufficient Ec/No quality of
the used frequency.
Total number of successful outgoing interfrequency hard handovers.
Successful outgoing inter-frequency hard
handovers due to insufficient RSCP quality
of the used frequency.
Successful outgoing inter-frequency hard
handovers due to insufficient Ec/No quality of
the used frequency.
Table 8-31: Properties of View InterFreq_InterRNC_HHO_overIuR
8.3.2.4
Global 3G3G mobility views for Radio Bearer Reconfiguration
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 120/275

Hard Handover 3G3G procedure includes radio bearer reconfiguration route as well as radio link setup.
To access the RNC resource management and check if congestion is detected during HHO procedure,
the following views can be consulted:
Radio_Bearer_Reconfiguration_Unsuccess_Per_Cause (provides an overview on RNC CAC

on TRB);
Radio_Bearer_Performance (provides and overview on Radio Bearer Reconfiguration success

and unsuccessful cause);
Radio_Link_SuccessRate_Performance (provides an overview for the radio link success for

setup, addition and reconfiguration;
Radio_Link_Setup_Unsuccess_Per_Cause (provides an overview on the route cause for

Radio Link Setup unsuccess);
8.3.3
High level of 3G2G mobility monitoring
Hard Handover 3G2G procedure should be analysed for PS and CS domain.

CS 3G2G HHO procedure is divided into two phases, preparation and execution. The preparation
phase starts with sending of Relocation Required message and ends with reception of Relocation
Command message. The execution phase starts with sending of Handover from Utran command
message and ends with reception of Iu release Command message (see UMTS to GSM HHO call
flow below). For PS domain, there is no relocation preparation phase.
The main metrics to check for HHO3G2G monitoring are the success rate for 3G2G HHO preparation
phase (CS domain only) and the success rate for 3G2G HHO execution. Views
Rnc_3G2G_Mobility_Overview_Cs and Rnc_3G2G_Mobility_Overview_Ps described below in
section 8.3.3.1 allow to check the preparation phase (for CS only) and execution phase of 3G2G HHO
(for CS and PS domain) at RNC level as well as the volume of HHO decisions due to radio conditions.
A sufficient volume of HHO decisions is needed to have reliable values for success rate and failure
rate KPIs. Similar 3G2G mobility views are also available for a first monitoring step at cell level. These
views are described in section 8.3.3.1.
The first step of monitoring should allow identifying
the period of time the issue occurred
the impacted domain (PS, CS or both)
the impacted phase (preparation, execution or both)
impacted RNCs (are all RNCs impacted or only a few RNCs ? ) with a list worst of RNCs
Once these elements have been determined, investigations will go on with detailed monitoring.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 121/275
source
SRNC
target BSS
UE
MSC
SGSN
Relocation Required (Classmark2,

1
Classmark 3)
Handover Request (Classmark2, Classmark 3)
Allocate
ressources
Handover Request Acknowledgement (Layer 3 Information)
Relocation Command (Layer 3

5
Information)
Handover from Utran Command (Layer 3 Information)
Handover from Utran Command

7
Complete
Handover Complete
Iu Release
SRNS Context Request

SRNS Context Response
Iu Release
Uu
10
11
12
Iu
Figure 8-34: UMTS to GSM hard handover call flow
8.3.3.1
Global 3G2G mobility views
This view provides an overview of the 3G to 2G hard handover triggered by alarm conditions at RNC
level, for Cs. The view shows the total number of RRM decisions for 3G to 2G HHO, carried out by the
RNC and the success rate for the execution phase. The 3G2G HHO preparation failure rate is also
presented, corresponding to the relocation preparation phase (reception by RNC of RELOCATION
COMMAND FAILURE message). The information obtained should be complemented by the results
retrieved from other mobility views and reports for 3G to 2G hard handover, present in the detailed
mobility monitoring section 8.3.4.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 122/275
Handover_3G2G_iMCTA_Cs
99,67%
10000
99,17%
8000
98,67%
97,67%
4000
Event
98,17%
6000
97,17%
96,67%
2000
96,17%
95,67%
04
/2
1
04 /2 0
/2 10
2
04 /2 0
/2 10
3
04 /2 0
/2 10
4
04 /2 0
/2 10
5
04 /2 0
/2 10
6
04 /2 0
/2 10
7
04 /2 0
/2 10
8
04 /2 0
/2 10
9
04 /2 0
/3 10
0
05 /2 0
/0 10
1
05 /2 0
/0 10
2
05 /2 0
/0 10
3
05 /2 0
/0 10
4
05 /2 0
/0 10
5
05 /2 0
/0 10
6
05 /2 0
/0 10
7
05 /2 0
/0 10
8
05 /2 0
/0 10
9
05 /2 0
/1 10
0
05 /2 0
/1 10
1/
20
10
VS_RrcHoFromUtranCmdTrigRnc_ServiceCs(U158_0)
VS_RrcHoFromUtranCmdTrigRnc_NoRsrcAvailCacFailure(U158_1)
VS_RrcHoFromUtranCmdTrigByUeTxPow erMax(U196)
VS_RrcHoFromUtranCmdTrigByRscp_RescueCs(U156_0)
VS_RrcHoFromUtranCmdTrigByEcNo_RescueCs(U154_0)
3G2GHHOExecutionSuccessRate_HO3G2G020_C_Cs(UHO3G2G020_C_Cs)
Figure 8-35: Display of View Rnc_3G2G_Mobility_Overview_Cs
Name
Description
Overview of 3G to 2G mobility procedure for Cs, at RNC level.
Graph
Families
DASHBOARD
MOBILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
3G2GHHOCSDetectionRadio_HO3G2G003_R_Cs
Number of RRM decisions to perform a

3G2G HHO due to radio conditions for
Cs, at RNC level. Presented on primary
axis.
3G2GHHOExecutionSuccessRate_HO3G2G020_R_Cs
Rate of successful 3G2G HHO

execution for Cs, at RNC level.
3G2GHHOPreparationFailureRate_HO3G2G018_R_Cs
Rate of failed 3G2G HHO preparations

for Cs, at RNC level. Corresponds to
the relocation preparation phase.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 123/275
VS_RrcHoFromUtranCmdTrigByEcNo_RescueCs(U15
4_0)(Event)
Number of Inter Rat handover from

utran command sent by RNC with a
reference cell for which the RNC is
serving and the handover has been
initiated because of Ec/No.
VS_RrcHoFromUtranCmdTrigByRscp_RescueCs(U156
_0)(Event)
Number of Inter-RAT handover from

Utran command sent by RNC with a
serving, and the handover has been
initiated because of RSCP criteria.
VS_RrcHoFromUtranCmdTrigByUeTxPowerMax(U196)
(Event)
Number of 3G 2G CS handovers with a

serving and the handover has been
initiated because of UE Tx Power Max
Alarm criterion
VS_RrcHoFromUtranCmdTrigRnc_NoRsrcAvailCacFail
ure(U158_1)(Event)

initiated because of CAC failure events
VS_RrcHoFromUtranCmdTrigRnc_ServiceCs(U158_0)(
Event)

initiated because of Service events
Table 8-32: Properties of View Rnc_3G2G_Mobility_Overview_Cs
This view shows the basic information related to 3G to 2G hard handover triggered by alarm
conditions at RNC level, for Ps (cell change order). The view shows the total number of RRM
decisions for 3G to 2G HHO, carried out by the RNC and the failure rate for the execution phase. In
contrast to the Cs domain, there is no relocation preparation phase as the hard handover from 3G is
seen as a new GPRS call, from the 2G network perspective. The information obtained should be
complemented by the results retrieved from other mobility views and reports for 3G to 2G HHO,
present in the present in the detailed mobility monitoring section 8.3.4.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 124/275
Handover_3G2G_iMCTA_Ps
300
381,52%
250
331,52%
150
231,52%
100
181,52%
50
131,52%
81,52%
281,52%
04
/2
1
04 /2 0
/2 10
2
04 /2 0
/2 10
3/
04 2 01
/2
0
4
04 /2 0
/2 10
5
04 /2 0
/2 10
6
04 /2 0
/2 10
7/
04 2 01
/2
0
8
04 /2 0
1
/2
9 0
04 /2 0
/3 10
0/
05 2 01
/0
0
1
05 /2 0
/0 10
2
05 /2 0
/0 10
3
05 /2 0
/0 10
4/
05 2 01
/0
0
5
05 /2 0
1
/0
6 0
05 /2 0
/0 10
7/
05 2 01
/0
0
8
05 /2 0
/0 10
9
05 /2 0
/1 10
0
05 /2 0
/1 10
1/
20
10
Event
200
3G2GHHOExecutionAttempts_HO3G2G001_C_ServicePs(UHO3G2G001_C_ServicePs)
3G2GHHOExecutionAttempts_HO3G2G001_C_CacPs(UHO3G2G001_C_CacPs)
3G2GHHOExecutionAttempts_HO3G2G001_C_AlarmPs(UHO3G2G001_C_AlarmPs)
3G2GHHOExecutionSuccessRate_HO3G2G020_C_Ps(UHO3G2G020_C_Ps)
Figure 8-36: Display of View Rnc_3G2G_Mobility_Overview_Ps
Name
Description
Overview of 3G to 2G mobility procedure for Ps, at RNC level.
Graph
Families
DASHBOARD
MOBILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
3G2GHHOCSDetectionRadio_HO3G2G003_R_Ps
Number of RRM decisions to

perform a 3G2G HHO due to radio
conditions for Ps, at RNC level.
3G2GHHOExecutionFailureRateOn2G_HO3G2G002_R_Ps
Rate of unsuccessful 3G2G HHO

execution for Ps, at RNC level.
Table 8-33: Properties of View Rnc_3G2G_Mobility_Overview_Ps
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 125/275

This view offers an overview of the 3G to 2G hard handover triggered by alarm conditions at cell level,
for Cs. The view shows the total number of RRM decisions for 3G to 2G HHO, carried out by the RNC
and the success rate for the execution phase. The information obtained should be complemented by
the results retrieved from other mobility views and reports for 3G to 2G hard handover, present in the
Detailed Monitoring chapter.
No Data Available
Figure 8-37: Display of View Cell_3G2G_Mobility_Overview_Cs
Name
Description
Overview of 3G to 2G mobility procedure for Cs, at cell level.
Graph
Families
DASHBOARD
MOBILITY
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
3G2GHHOCSDetectionRadio_HO3G2G003_C_Cs
Number of RRM decisions to perform a

3G2G HHO due to radio conditions for
Cs, at cell level. Presented on primary
axis.
3G2GHHOExecutionSuccessRate_HO3G2G020_C_Cs
Rate of successful 3G2G HHO

execution for Cs, at cell level. Presented
on secondary axis.
Table 8-34: Properties of View Cell_3G2G_Mobility_Overview
This view gives an overview of the 3G to 2G hard handover triggered by alarm conditions at cell level,
for Ps (cell change order). The view shows the total number of RRM decisions for 3G to 2G HHO,
carried out by the RNC and the failure rate for the execution phase. The information obtained should
be complemented by the results retrieved from other mobility views and reports for 3G to 2G HHO,
present in the Detailed Monitoring chapter.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 126/275
No Data Available
Figure 8-38: Display of View Cell_3G2G_Mobility_Overview_Ps
Name
Description
Overview of 3G to 2G mobility procedure for Ps, at cell level.
Graph
Families
DASHBOARD
MOBILITY
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
3G2GHHOCSDetectionRadio_HO3G2G003_C_Ps
Number of RRM decisions to

perform a 3G2G HHO due to radio
conditions for Ps, at cell level.
3G2GHHOExecutionFailureRateOn2G_HO3G2G002_C_Ps
Rate of unsuccessful 3G2G HHO

execution for Ps, at cell level.
Table 8-35: Properties of View Cell_3G2G_Mobility_Overview_Ps
8.3.4
Detailed mobility monitoring
Only detailed monitoring for 3G2G hard handover will be described in detail hereunder in section
8.3.4.1 but detailed monitoring views are also available for other types of mobility. These views allow
monitoring more common mobility scenario. Section 8.3.4.3 explains the decrease of cell update
success rate observed between UA05 and UA06 and lists the impacted views and indicators.
If a deeper analysis of mobility is needed, the mobility troubleshooting report will be used (see section
8.3.5).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 127/275
8.3.4.1
3G2G mobility detailed monitoring
For CS domain, the detailed monitoring consists in analyse phases with low success rate (preparation,
execution or both for the worst RNCs and then if needed the execution phase for the worst cells).
The preparation phase detailed analysis can used the basic indicator VS_IuRelocationCmdFailuresCs
screenings for 3G2G HHO to have the distribution of preparation relocation failures on Iu Cs interface
for worst RNCs.
In case of failures due to relocation timeout, the transmission network between 2G and 3G
should be checked.
In case of failures in target system, the 2G neighbouring cells capacity should be checked
In case of failures due to relocation unable to be established, the neighbouring cells definition
should be checked.
For other relocation failures, the 2G target network needs to be verified
This analysis can be completed with Ctg traces analysis.

For CS and PS domain, the execution phase analysis could be completed
thanks to the 2 views Handover_3G2G_Cs_Rnc and Handover_3G2G_Ps_Rnc described

in section 8.3.4.2 and which gives the number of attempts incremented when the RNC sends
the Handover from UTRAN command.
by checking 3G2GHHOExecutionFailureRateBecauseOf3GReason_HO3G2G022_R_Cs to
have CS 3G2G handover execution failure rate due to call lost. The worst cells can be found
by using 3G2GHHOExecutionFailureRateBecauseOf3GReason_HO3G2G022_C_Cs baseline
indicator and CS HHO parameters as well as RF condition of target 2G neighbouring cells
should be checked for these cells.
by looking for PS domain at the distribution of the number of Inter Rat Cell Change Order
failure received by the RNC obtained thanks to screenings of IRATHO_FailOutPSUTRAN.
by checking CTg traces in a worst cell selected for detailed investigations.
by checking if failures are not due to some mobiles synchronization issue.
8.3.4.2
Mobility detailed monitoring views
Detailed monitoring mobility subfamily contains many detailed views on network behaviour for 2G3G
mobility (2 examples of more commonly used views are described below) and also for other types of
mobility procedures (Cell update, HHO 3G3G, HSDPA, HSUPA, Primary Cell Change, SHO and URA
update). Main mobility views are listed in table below.
Handover_3G2G_Cs_Rnc
Name
Handover_3G2G_Cs_Rnc
Description
Number of 3G2G CS HHO attempts and success rate.
Graph
Families
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 128/275

DETAILED MONITORING
MOBILITY
HHO 3G2G
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
3G2GHHOExecutionAttempts_HO3G2G001_R_Cs
3G2GHHOExecutionSuccessRate_HO3G2G020_R
_Cs
Number of 3G to 2G HHO CS execution

attempt (incremented at sending of
Handover from Utran command)
Rate of successful execution HHO 3G2G
Cs.
Table 8-36: Properties of Handover_3G2G_Cs_Rnc
Handover_3G2G_Ps_Rnc
Name
Handover_3G2G_Ps_Rnc
Description
Number of 3G2G PS HHO attempts and success rate.
Graph
Families
DETAILED MONITORING
MOBILITY
HHO 3G2G
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
3G2GHHOExecutionAttempts_HO3G2G001_R_Ps
3G2GHHOExecutionSuccessRate_HO3G2G020_R
_Ps
Number of 3G to 2G PS HHO attempts.

Rate of successful execution HHO 3G2G
Ps.
Table 8-37: Properties of Handover_3G2G_Ps_Rnc
Main detailed mobility views

These views allow checking network behaviour and having detailed information in case some
investigations are needed for a specific mobility procedure.
Main RNC level mobility views available for detailed monitoring are listed in the table below. Some of
them for HHO 3G2G mobility have been described in details above.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 129/275

Mobility Subfamily
CELL UPDATE
HH0 3G2G
HH0 3G3G
HSDPA
HSUPA
PRIMARY CELL
CHANGE
SOFT HANDOVER
UMT/IRC/INF/012027
View name
Cell_Update_Success (*see section 8.3.4.3)
Cell_Update_Reject (*see section 8.3.4.3)
Handover_3G2G_Ps_Rnc (described in details above)
Handover_3G2G_Cs_Rnc (described in details above)
Handover_3G2G_Imcta_Type_Distribution_Cs_Rnc
Intra_Rnc_Incoming_3G3G_Hho_Imcta_Cac
Intra_Rnc_Incoming_3G3G_Hho_Imcta_Service
Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Alarm
Intra_Rnc_Incoming_3G3G_Hho_Imcta_Alarm
Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Cac
Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Service
Intra_Rnc_Incoming_3G3G_Hho_Imcta_Cause_Distribu
tion
Intra_Rnc_Outgoing_3G3G_Hho_Imcta_Cause_Distribu
tion
Inter_Rnc_Outgoing_3G3G_Hho_Preparation_Ps
Inter_Rnc_Outgoing_3G3G_Hho_Preparation_Cs
Inter_Rnc_Incoming_3G3G_Hho_Preparation_Ps
Inter_Rnc_Incoming_3G3G_Hho_Preparation_Cs
Inter_Rnc_Incoming_3G3G_Hho_Execution_Ps
Inter_Rnc_Outgoing_3G3G_Hho_Execution_Ps
Inter_Rnc_Incoming_3G3G_Hho_Execution_Cs
Inter_Rnc_Outgoing_3G3G_Hho_Execution_Cs
Hsdpa_To_Hsdpa_Mobility_Intra_Freq
Hsdpa_To_Non_Hsdpa_Mobility_Intra_Freq
Hsdpa_To_Non_Hsdpa_Mobility_Inter_Freq
Hsdpa_To_Hsdpa_Mobility_Global
Non_Hsdpa_To_Hsdpa_Mobility_Global
Non_Hsdpa_To_Hsdpa_Mobility_Inter_Freq
Non_Hsdpa_To_Hsdpa_Mobility_Intra_Freq
Hsdpa_To_Non_Hsdpa_Mobility_Global
Hsdpa_Mobility_All_Indicators
Hsdpa_To_Hsdpa_Mobility_Inter_Freq
Hsdpa_Traffic_On_Iur_Interface
Hsupa_To_Hsupa_Mobility_Intra_Freq
Hsupa_To_Hsupa_Mobility_Inter_Freq
Hsupa_To_Non_Hsupa_Mobility_Inter_Freq
Hsupa_To_Non_Hsupa_Mobility_Intra_Freq
Non_Hsupa_To_Hsupa_Mobility_Inter_Freq
Non_Hsupa_To_Hsupa_Mobility_Intra_Freq
Hsupa_To_Hsupa_Mobility_Global
Hsupa_To_Hsupa_Mobility_Intra_Freq_Tti
Hsupa_To_Non_Hsupa_Mobility_Global
Non_Hsupa_To_Hsupa_Mobility_Global
Hsupa_Mobility_All_Indicators
Outgoing_Primary_Cell_Change
Incoming_Primary_Cell_Change
Active_Set_Update_Per_Second (described in)
Soft_Handover_Radio_Links
Active_Set_Update_Global
Active_Set_Update_Unsuccess_Distribution
Soft_Handover_Inter_Rnc
07.02 /EN
Preliminary
25/June/2010
Page 130/275

URA UPDATE
Ura_Update_Reject
Ura_Update_Success
Table 8-38: Detailed monitoring RNC level mobility views
8.3.4.3
Decrease of cell update success rate between UA05 and UA06
The Cell Update Success Rate decreased after UA06 upgrade. It has been observed during FOA (see
Figure below)
This decrease is explained by the reduction of the number of cell updates for cell reselection due to a
new procedure introduced with 33565 Always-On evolutions in UA06. This procedure avoids to the
UE to send a cell update when it selects the target cell proposed by the RNC in RB reconfiguration
during Cell_DCH to Cell_FACH transitions (see call flow below)
UE
Node B
RNC
SGSN
Based on Always-On criteria,and after pre-CAC on the

primary cell, the mobile is moved to the CELL_FACH state
RRC/ DCH / RB Reconfiguration (
RRC state = CELL_FACH,
Frequency Info,
Prima ry CPICH Info)
If the UE re-selects a cell different from the one indicated
by the "Primary CPICH Info", the UE shall 1 st perform a
cell update in the new ce ll.
RRC/ RACH / Cell Update (cause cell re-selection)
RRC/ RACH / Cell Update Confirm
RRC/ RACH / RB Reconfiguration Complete
The old Radio Link is released at the NodeB
NBAP/ Radio Link Deletion Request
NBAP/ Ra dio Link Deletion Response
Figure 8-39: CELL_DCH to CELL_FACH transition with cell-reselection
In UA5.1, the RNC did not provide a target cell at Cell_DCH to CELL_FACH transition,
and the UE sent a Cell Update at each transition.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 131/275

In UA06, the RNC gives the target cell to the UE at the time of the RB reconfiguration
and the UE sends a Cell Update only if it reselects another cell than the one defined
by RNC. This enables to decrease the overall delay for the transition from CELL_DCH
to CELL_FACH in case the UE has not selected another cell.
Figure 8-40: Reduction of cell updates number in UA6.0
This change introduced in UA6.0 for Cell_DCH to CELL_FACH transition with cell reselection impacts
the following counters/indicators:
VS_NbrCellUpdates_CellReselection(U901_0)
CellUpdateSuccessRate_RL019_CR
NumberofCellUpdate_CellFACH002_CR
These indicators are used in the following views: Rrc_Reestablishment_Cs, Rrc_Reestablishment_Ps,

Cell_Update_Reject, and Cell_Update_Success.
8.3.5
Mobility troubleshooting
The mobility troubleshooting reports (Mobility_1 and Mobility_2) will define the ability of the network to
ensure UEs calls continuity.
This report will manage all the supported mobility on the ALU product.
Mobility in Soft Handover
Mobility in Hard Handover

o
3G to 3G Inter/Intra Frequency Inter-RNC Handover
3G to 3G Inter-Frequency Intra-RNC Handover
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 132/275

o
3G to 2G
SRNS Relocation UE not involved.
The last version of UA07 mobility troubleshooting report is included in the Troubleshooting dictionary
which is available on live link at the following location:
The Mobility troubleshooting will consist of:

In connection mode:
3G2G Mobility analysis.
The 3G2G Mobility analysis aims at evaluating the inter RAT (3G to 2G) HO performance
results and at indicating where are the failures in the 2G or in the 3G
3G3G Mobility analysis
SHO Mobility analysis. The SHO Mobility analysis estimate if the SHO is efficiently used
and so avoid that calls are dropped
Other feature monitoring, inter frequency 3g3g ho, call redirection, etc See Mobility
Feature
Monitoring
Guide
(https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=41149992&objAction=browse&sort=name&v
iewType=1)
In idle mode.
In this case the mobile traces are needed.
However, a troubleshooting based on counters will consist by study RRC counters/RRC transitions.
Its also necessary to divide into CS and PS domain.
8.3.5.1
3G-2G HHO troubleshooting
As explained in section 8.3.4.1, 3G 2G procedure is divided into two phases, preparation and
execution.
3G2G HO Global metric gives a global view of 3G2G HO procedure (E2E)
3G2G HO preparation success rate monitors of the preparation phase on the 2G side.
3G2G Ho execution success rate monitors the execution of the 3G2G HO (from "HO from
UTRAN Command" to the release of the IU interface after the success of the relocation).
o
3G2G Ho execution success rate (at 3G side) monitors the execution of the 3G2G HO
on the 3G side only (without taking into account the cases where the Mobile fails to
Synchronize on the 2G).
Here is a subset of metrics used in Mobility dictionary to monitor the 3G-2G execution phase:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 133/275
Metric
Network
element
Metric name
Legend
Indicator
RNC
UHO3G2G020_C_Cs
3G2GHHOExecutionSuccessRate_HO3G2G020_C_Cs(UHO
3G2G020_C_Cs)
Indicator
RNC
UHO3G2G020_C_Ps
3G2GHHOExecutionSuccessRate_HO3G2G020_C_Ps(UHO
3G2G020_C_Ps)
Indicator
RNC
UHO3G2G002_C_Ps
3G2GHHOExecutionFailureRateOn2G_HO3G2G002_C_Ps(
UHO3G2G002_C_Ps)
Indicator
RNC
UHO3G2G022_C_Cs
3G2GHHOExecutionFailureRateBecauseOf3GReason_HO3
G2G022_C_Cs(UHO3G2G022_C_Cs)
Indicator
RNC
UHO3G2G003_C_Ps
3G2GHHOPSDetectionRadio_HO3G2G003_C_Ps(UHO3G2
G003_C_Ps)
Indicator
RNC
UHO3G2G002_C_Ps
3G2GHHOExecutionFailureRateOn2G_HO3G2G002_C_Ps(
UHO3G2G002_C_Ps)
Table 8-39: Main indicators used for 3G-2G HHO troubleshooting
According the phase (preparation or execution) where the degradation will occur, the two following
analysis will need to be done (details given hereunder for CS case):
3G2G Preparation Analysis at RNC or Cell level

Preparation 3G2G CS HHO Analysis
RNC or Cluster level
High 3G2G HHO CS

preparation failure rate
UHO3G2G018_R_Cs
High CS 3G2G Rejection

Success rate
due to Time out

Success rate
due to unable to establish
Check Outage in Transmission

Network
Between 3G CN and 2G network
To determine the rejection causes

(Refer to 3GPP TS 25.413):
Perform a distribution of the
counters U558 Iu relocation
command failures CS

Success rate
due to Failure in Target
System
Preparation 3G2G HHO Failures

TOP N Cells
Check the Neighbouring cells

definition

Success rate
due to Other Reason

TOP N Cells

TOP N Cells
Check the 2G Neighbouring

Cells - capacity Analysis
Check the Outage in

the 2G target network identified
To determine the worst N cells with a representative

number of Preparation 3G2G HHO Failures:
the highest number of =
VS.3gto2gHoDetectionFromFddcell.RescueCs (VS.RrcHoFromUtranCmdTrigByRscp.RescueCs +
VS.RrcHoFromUtranCmdTrigByEcNo.RescueCs
Figure 8-41: CS 3G-2G HHO preparation phase troubleshooting
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 134/275
To determine the rejection cause which is the main contributor to the 3G2G HHO CS Preparation
failure, it is needed to have a graphic distribution of the following counters:
Counter Id
U558_6
U558_7
U558_9
U558_5
U558_8
Counter Name
VS_IuRelocationCmdFailuresCs_3Gto2GAlreadyInProgrUeInv(U558_6)
VS_IuRelocationCmdFailuresCs_3Gto2GFailTargetUeInv(U558_7)
VS_IuRelocationCmdFailuresCs_3Gto2GOtherUeInv(U558_9)
VS_IuRelocationCmdFailuresCs_3Gto2GRelocTimeoutUeInv(U558_5)
VS_IuRelocationCmdFailuresCs_3Gto2GUnableToEstabUeInv(U558_8)
3G2G Execution Analysis at RNC or Cell level

Execution 3G2G CS HHO Analysis
RNC or Cluster level
Low HHO 3G2G CS

execution success ratio
UHO3G2G020_C_Cs
To determine the worst N cells with
a representative number of HO
From UTRAN Failures:
the highest number of CS Calls
drop due to CS 3G2G HHO
To determine the worst N cells with a

representative number of HO From
UTRAN Failures:
the highest number of CS HO From
UTRAN Failure
3G-2G HHO CS execution
failure rate (3G side)
UHO3G2G022_R_Cs
3G-2G HHO CS execution

failure rate (2G side)
UHO3G2G002_R_Cs
3G-2G HHO CS execution failure

rate (2G side TOP N Cells
UHO3G2G002_C_Cs
3G-2G HHO CS execution failure

rate (3G side) TOP N Cells
UHO3G2G022_R_Cs
Target 2G neighboring cells

RF condition analysis
Check the setting

of 3G2G CS HHO
Algorithm Parameters
Figure 8-42: CS 3G-2G HHO execution phase troubleshooting
8.3.5.1.1 Action to improve the preparation phase

The 3G2G HHO Preparation Failure causes are the following ones:
Failure in 2G target cell (congestion, outage)
Wrong definition of 3G neighbouring identifiers (cells, LAC) in 2G network
Wrong definition of 2G neighbouring identifiers (cells, LAC) in 3G network
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 135/275

Timeout in the procedure (mainly on 2G side as 3G is just relaying messages)
Call dropped between Iu Relocation Required and HO from UTRAN Command
Any failure from the RNC and/or BTS during the procedure
When the 3G2G HHO Preparation Success rate is very low, it means that the failure causes are not
occasional ones:
Either wrong definition of 3G neighbouring identifiers (cells, LAC) in 2G network
Or wrong definition of 2G neighbouring identifiers (cells, LAC,) in 3G network
8.3.5.1.2 Action to improve the execution phase

The 3G2G HHO Execution Failure causes are the following ones:
Mobile synchronization issue with 2G target cell
Radio issue to access the 2G target cell
Call Dropped (3G side) after HO from UTRAN command
When the 3G2G HHO Execution Success rate is very low, it means that the failures are not due to
some mobiles but rather to a radio issue on the 2G target cell
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 136/275
8.4.
RETAINABILITY MONITORING AND TROUBLESHOOTING
8.4.1
First level of retainability monitoring
The first step of network retainability monitoring aims at evaluating the call drop rate trends at network
level and at RNC level based on views available in the dashboard dictionary:
Rnc_Retainability_Overview_Cs described in section 8.4.1.1 gives the number of

established RABs and the call drop rate for voice and video.
Rnc_Retainability_Overview_Ps described in section 8.4.1.1 gives the number of

established RABs and the call drop rate for PS.
The analysis of these views gives the global network or RNC retainability performance for PS and CS
calls. In case of a CDR issue for PS or CS calls, it will be necessary to define more precisely
the affected network elements : the issue may concern all the network or could be limited
to some network elements (search of the worst cells or KPIs observation per cells zone
(F1, F2, xCEM, iCEM) may help in investigations). Cell level views with similar
information as RNC level views are available in the dashboard dictionary. A description of
these views is given in section 8.4.1.1
the affected period of time : the degradation may be the same over all the observed
period or could be more huge for certain periods of time (observe daily KPI values over
several weeks and hourly values over several day may help to characterize the issue)
the events occurred on the network : the degradation may occur after some specific
events (upgrade, feature activation, parameters change, HW configuration change)
These details will facilitate the detailed monitoring and troubleshooting.
8.4.1.1
Global retainability views

Retainability monitoring based on KPI-11 and KPI-13
The UA7.1 global retainability views use the GM CDR KPIs (Iu006, Iu007) based on
IuAbnormalReleaseRequest_ counter. The retainability can be also monitored thanks to the
RAB drop rate indicators RAB027 (KPI-11) and RAB028 (KPI-13) based on VS_RAB_Drop_
and VS_RAB_SuccEstab_counters.
This view is helpful on a first stage of Cs dropped calls investigation at RNC level, providing
information on the total number of established RABs and the dropped call rate, defined as the ratio
between the number of Iu abnormal releases and the total number of Iu releases (abnormal + normal).
The analysis is done for voice and video. The information obtained should be complemented by the
results retrieved from other retainability views and reports for Cs, included in the Detailed Monitoring
section.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 137/275
Figure 8-43: Display of View Rnc_Retainability_Overview_Cs
Name
Description
Overview of retainability at RNC level for Cs (voice and video).
Graph
Families
DASHBOARD
RETAINABILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RABAssignmentSuccessPerGrantedRABType_
RAB022_R_CsVoice
Number of RAB assignment successes at RNC

level for Cs voice calls. Presented on primary
axis.
RAB022_R_CsVideo

level for Cs video calls. Presented on primary
axis.
CallDropRate_IU007_R_CsVoice
Number of Iu abnormal release request versus

the number of granted Cs voice RABs at RNC
level. Presented on secondary axis.
CallDropRate_IU007_R_CsVideo

the number of granted Cs video RABs at RNC
level. Presented on secondary axis.
Table 8-40: Properties of View Rnc_Retainability_Overview_Cs
This view gives a first indication of the Ps retainability at RNC level, using the number of established
Ps RABs and the Ps call drop rate (ratio between the number of Iu abnormal releases and the total
number of calls released) in this analysis. The total number of calls released is defined as the sum of
the Iu abnormal releases with the number of Ps radio bearer release successes and with the Always
On Step2 transitions to idle mode. The information obtained should be complemented by the results
retrieved from other retainability views and reports for Ps, included in the Detailed Monitoring section.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 138/275
Figure 8-44: Display of View Rnc_Retainability_Overview_Ps
Name
Description
Overview of retainability at RNC level, for Ps.
Graph
Families
DASHBOARD
RETAINABILITY
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RAB022_R_Ps

level for Ps calls. Presented on primary axis.
CallDropRate_IU007_R_Ps

the number of granted Ps RABs at RNC level.
Table 8-41: Properties of View Rnc_Retainability_Overview_Ps
This view is helpful on a first stage of Cs dropped calls investigation at cell level, providing information
on the total number of established RABs and the dropped call rate, defined as the ratio between the
number of Iu abnormal releases and the total number of Iu releases (abnormal + normal). The analysis
is done for voice and video. The information obtained should be complemented by the results
retrieved from other retainability views and reports for Cs, included in the Detailed Monitoring section.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 139/275
Figure 8-45: Display of View Cell_Retainability_Overview_Cs
Name
Description
Overview of retainability at cell level for Cs (voice and video).
Graph
Families
DASHBOARD
RETAINABILITY
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RAB022_C_CsVoice
Number of RAB assignment successes at cell

level for Cs voice calls. Presented on primary
axis.
RAB022_C_CsVideo

level for Cs video calls. Presented on primary
axis.
CallDropRate_IU006_C_CsVoice

the number of Iu releases (normal and
abnormal) at cell level for Cs voice calls.
CallDropRate_IU006_C_CsVideo

the number of Iu releases (normal and
abnormal) at cell level for Cs video calls.
Table 8-42: Properties of View Cell_Retainability_Overview_Cs
This view gives a first indication of the Ps retainability at cell level, using the number of established Ps
RABs and the Ps call drop rate (ratio between the number of Iu abnormal releases and the total
number of calls released) in this analysis. The total number of calls released is defined as the sum of
the Iu abnormal releases with the number of Ps radio bearer release successes and with the Always
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 140/275

On Step2 transitions to idle mode. The information obtained should be complemented by the results
retrieved from other retainability views and reports for Ps, included in the Detailed Monitoring section.
Name
Description
Overview of retainability at cell level for Ps.
Graph
Families
DASHBOARD
RETAINABILITY
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RAB022_C_Ps

level for Ps calls. Presented on primary axis.
CallDropRate_IU022_C_Ps

the number of calls released (normally or
abnormally) at cell level for Ps calls. Presented
on secondary axis.
Table 8-43: Properties of View Cell_Retainability_Overview_Ps
In previous release, the Cell_Retainability_Overview_Ps view used the indicator
CallDropRate_IU006_C_Ps (UIU006_C_Ps) (%) that does not always provide valid results.
This indicator has been removed from UA7.1 baseline dictionary and replaced by
UIU022_C_Ps (CallDropRate_IU022_C_Ps). The dashboard view will be updated
accordingly.
The HSDPA CallDropIndicator_HSDPA032_CR(UHSDPA032_CR) (%) has been removed
from UA7.1 because as in IU006_C_PS case, it does not always provide valid results but no
replacement exists. It is recommended to use UIU020_C_HSDPA instead
Recommendation for retainability monitoring

:The use of NumberOfDropsPerHourOfCalls_IU020 indicators is recommended for
retainability monitoring in parallel of call drop rate indicators
8.4.2
Retainability detailed monitoring
The aim of retainability detailed monitoring is to complete the CDR issue characterization by
determining the affected services and the failure causes. So the next step should be to check in
parallel:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 141/275
the distribution of the number of call drops per service to determine if the issue affects all
services or only certain services. This distribution can be obtained with the screenings of
baseline indicator UIU008_R.
the distribution of Iu release request per cause to find the main failure causes for CS calls and
for PS calls. This distribution is given by the 2 following detailed monitoring views
Iu_Release_Request_Cs and Iu_Release_Request_Ps described in section 8.4.2.1.
For PS retainability analysis, PS call management procedures and IRM Algorithms should be also
monitored. For CS domain, the number of CS calls dropped due to 3G2G should be checked.
If a deeper analysis of retainability is needed, PS CDR or CS CDR troubleshooting report will be used
(see section 8.4.3).
8.4.2.1
Retainability detailed monitoring views
Retainability subfamily of detailed monitoring dictionary contains detailed views on call drops and on
abnormal Iu release. All available retainability views are listed in the detailed monitoring report
definition document. Two views are described in detail below.
Iu_Release_Request_Ps
This view gives the number of Iu PS release request per cause (excluding user inactivity cause). A
detailed description of each counter screening used in this view is given in section 8.4.2.2
VS_IuReleaseReqPs_UtranPageFail(U599
_20)
Iu_Release_Request_Ps - RNC: RNC2005 ( RNC2005 ) - 08/26/2008
To 09/15/2008
(Working Zone: Global - Medium) VS_IuReleaseReqPs_UnspecifiedFailure(U
599_3)
RNC2005
VS_IuReleaseReqPs_UlRLCErrTRB(U599
_11)
1400
VS_IuReleaseReqPs_UlRLCErrSRB(U599
_9)
VS_IuReleaseReqPs_UeGeneratedSignalli
ngConnectionRelease(U599_5)
1200
VS_IuReleaseReqPs_T360Expiry(U599_1
2)
1000
VS_IuReleaseReqPs_T305Expiry(U599_1
8)
800
Event
VS_IuReleaseReqPs_RepeatedIntegrityCh
eckFailure(U599_4)
VS_IuReleaseReqPs_ReleaseDueToUtran
GeneratedReason(U599_14)
600
VS_IuReleaseReqPs_RadioCnxUeLost(U5
99_6)
400
VS_IuReleaseReqPs_PhyChnReestabFail(
U599_21)
VS_IuReleaseReqPs_OtherCause(U577_8
)
200
VS_IuReleaseReqPs_OamIntervention(U5
99_2)
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
08
09
/0
1/
20
08
09
/0
3/
20
08
09
/0
5/
20
08
09
/0
7/
20
08
09
/0
9/
20
08
09
/1
1/
20
08
09
/1
3/
20
08
09
/1
5/
20
08
VS_IuReleaseReqPs_NoResourceAvailabl
e(U599_17)
VS_IuReleaseReqPs_NoRemainingRAB(U
599_15)
Figure 8-46: Display of View Iu_Release_Request_PS
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 142/275
Name
Iu_Release_Request_PS
number of Iu PS release request per cause (excluding user
inactivity cause)
Graph
Description
Families
DETAILED MONITORING
RETAINABILITY
PS
CELL
DETAILED MONITORING
RETAINABILITY
PS
RNC
Weekly
Monthly
Availability Domain
Hourly
Daily
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_IuReleaseReqPs_OtherCause (U577_8)
VS_IuReleaseReqPs_IuUserPlaneFailure (U599_1)
VS_IuReleaseReqPs_DlRLCErrTRB (U599_10)
VS_IuReleaseReqPs_UlRLCErrTRB (U599_11)
VS_IuReleaseReqPs_T360Expiry (U599_12)
VS_IuReleaseReqPs_ConnectionWithNodeBLost
(U599_13)
VS_IuReleaseReqPs_ReleaseDueToUtranGeneratedRea
son (U599_14)
VS_IuReleaseReqPs_NoRemainingRAB (U599_15)
VS_IuReleaseReqPs_FailureInTheRadioInterfaceProcedu
re (U599_16)
VS_IuReleaseReqPs_NoResourceAvailable (U599_17)
VS_IuReleaseReqPs_T305Expiry (U599_18)
UMT/IRC/INF/012027
07.02 /EN
Number of RANAP/IU_RELEASE_REQUEST
sent by RNC to Core Network PS (Screening :
Other causes). Presented on primary axis.
IU User Plane Failure). Presented on primary
axis.
sent by RNC to CoreNetwork PS (Screening :
DL RLC error on TRB). Presented on primary
axis.
UL RLC error on TRB). Presented on primary
axis.
T360 Expiry). Presented on primary axis.
Connection with NodeB lost). Presented on
primary axis.
Release due to UTRAN Generated Reason).
No Remaining RAB). Presented on primary
axis.
Failure in the Radio Interface Procedure).
No Resource Available). Presented on primary
axis.
T305 Expiry). Presented on primary axis.
Preliminary
25/June/2010
Page 143/275
VS_IuReleaseReqPs_CellReselFail (U599_19)
VS_IuReleaseReqPs_OamIntervention (U599_2)
VS_IuReleaseReqPs_UtranPageFail (U599_20)
VS_IuReleaseReqPs_PhyChnReestabFail (U599_21)
VS_IuReleaseReqPs_UnspecifiedFailure (U599_3)
VS_IuReleaseReqPs_RepeatedIntegrityCheckFailure
(U599_4)
VS_IuReleaseReqPs_UeGeneratedSignallingConnection
Release (U599_5)
VS_IuReleaseReqPs_RadioCnxUeLost (U599_6)
VS_IuReleaseReqPs_AbnormalConditionTimerRelocExpi
ry (U599_7)
VS_IuReleaseReqPs_DlRLCErrSRB (U599_8)
VS_IuReleaseReqPs_UlRLCErrSRB (U599_9)
Cell Reselection failure). Presented on primary
axis.
OAM Intervention). Presented on primary axis.
UtranPagingFailure). Presented on primary
axis.
Physical Channel Re-establishment failure).
Unspecified Failure). Presented on primary
axis.
Repeated Integrity Check Failure). Presented
on primary axis.
UE generated signalling connection release).
Radio connection with UE lost). Presented on
primary axis.
Abnormal condition with cause TRelocOveral
expiry). Presented on primary axis.
DL RLC error on SRB). Presented on primary
axis.
UL RLC error on SRB). Presented on primary
axis.
Table 8-44: Properties of Iu_Release_Request_PS
Iu_Release_Request_Cs
This view gives the number of Iu CS release request per cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 144/275

VS_IuReleaseReqCs_UnspecifiedFailure(U
576_1)
Iu_Release_Request_Cs - RNC: RNC2005 ( RNC2005 ) - 08/26/2008
To 09/15/2008
(Working Zone: Global - Medium) VS_IuReleaseReqCs_UlRLCErrSRB(U576
_8)
RNC2005
VS_IuReleaseReqCs_UeGeneratedSignalli
ngConnectionRelease(U576_3)
2000
VS_IuReleaseReqCs_T360Expiry(U576_9)
1800
VS_IuReleaseReqCs_RepeatedIntegrityCh
eckFailure(U576_2)
1600
VS_IuReleaseReqCs_ReleaseDueToUtran
GeneratedReason(U576_11)
1400
VS_IuReleaseReqCs_RadioConnectionWit
hUeLost(U576_4)
1000
VS_IuReleaseReqCs_OtherCause(U576_6
)
800
VS_IuReleaseReqCs_OamIntervention(U5
76_0)
600
VS_IuReleaseReqCs_NoResourceAvailabl
e(U576_14)
400
VS_IuReleaseReqCs_NoRemainingRAB(U
576_12)
200
VS_IuReleaseReqCs_FailureInTheRadioInt
erfaceProcedure(U576_13)
VS_IuReleaseReqCs_DlRLCErrSRB(U576
_7)
08
/2
6/
20
08
08
/2
8/
20
08
08
/3
0/
20
08
09
/0
1/
20
08
09
/0
3/
20
08
09
/0
5/
20
08
09
/0
7/
20
08
09
/0
9/
20
08
09
/1
1/
20
08
09
/1
3/
20
08
09
/1
5/
20
08
Event
1200
VS_IuReleaseReqCs_ConnectionWithNod
eBLost(U576_10)
VS_IuReleaseReqCs_AbnormalConditionTi
merRelocExpiry(U576_5)
Figure 8-47: Display of View Iu_Release_Request_CS
Name
Iu_Release_Request_CS
Number of Iu CS release request per cause (excluding user
inactivity cause)
Graph
Description
Families
DETAILED MONITORING
RETAINABILITY
PS
CELL
DETAILED MONITORING
RETAINABILITY
PS
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_IuReleaseReqCs_OamIntervention (U576_0)
VS_IuReleaseReqCs_UnspecifiedFailure (U576_1)
UMT/IRC/INF/012027
07.02 /EN
sent by RNC to Core Network CS (Screening :
OAM Intervention). Presented on primary axis.
Unspecified Failure). Presented on primary
axis.
Preliminary
25/June/2010
Page 145/275
VS_IuReleaseReqCs_ConnectionWithNodeBLost
(U576_10)
VS_IuReleaseReqCs_ReleaseDueToUtranGeneratedRea
son (U576_11)
VS_IuReleaseReqCs_NoRemainingRAB (U576_12)
VS_IuReleaseReqCs_FailureInTheRadioInterfaceProced
ure (U576_13)
VS_IuReleaseReqCs_NoResourceAvailable (U576_14)
VS_IuReleaseReqCs_RepeatedIntegrityCheckFailure
(U576_2)
VS_IuReleaseReqCs_UeGeneratedSignallingConnection
Release (U576_3)
VS_IuReleaseReqCs_RadioConnectionWithUeLost
(U576_4)
VS_IuReleaseReqCs_AbnormalConditionTimerRelocExpi
ry (U576_5)
VS_IuReleaseReqCs_OtherCause (U576_6)
VS_IuReleaseReqCs_DlRLCErrSRB (U576_7)
VS_IuReleaseReqCs_UlRLCErrSRB (U576_8)
VS_IuReleaseReqCs_T360Expiry (U576_9)
Connection with NodeB lost). Presented on
primary axis.
Release due to UTRAN Generated Reason)
sent by RNC to Core Network CS (Screening:
No Remaining RAB). Presented on primary
axis.
Failure in the Radio Interface
Procedure) .Presented on primary axis.
No Resource Available). Presented on primary
axis.
Repeated Integrity Check Failure). Presented
on primary axis.
UE generated signalling connection release).
Radio cnx with UE lost). Presented on primary
axis.
Abnormal condition with cause TRelocOveral
expiry). Presented on primary axis.
Other causes). Presented on primary axis.
DL RLC error on SRB). Presented on primary
axis.
UL RLC error on SRB). Presented on primary
axis.
T360 Expiry ). Presented on primary axis.
Table 8-45: Properties of Iu_Release_Request_CS
Note : screenings #10 to #14 of VS_IuReleaseReqCs counter are new screenings introduced in UA06.
-screening #10 ConnectionWithNodeBLost (The new screening "Connection with NodeB lost"
is incremented in case of loss of AAL2, SSCOP, NBAP RESET, RSI other than those reasons
already covered by O&M intervention)
-screening #11 Release due to UTRAN Generated Reason
-screening #12 No Remaining RAB
-screening #13 Failure in the Radio Interface Procedure
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 146/275

-screening #14 No Resource Available
Between UA5.1 and UA06 the following changes have been observed up to now:
the screening OtherCause was wrongly pegged instead of DlRlcErrSrb or RadioCnxWithUeLost

in UA5.1. It may depend on the load as it was not observed on all networks.
the new screenings #11 to #14 (and more especially screening #13
FailureInTheRadioInterfaceProcedure ) are now counting what was counted in OtherCause
screening. Screening #12 No Remaining RAB seems to remain equal to 0.
8.4.2.2
Description of VS_IuReleaseReqPs counter screenings
This section describes the counters and respective screenings used for monitoring of the number of
abnormal Iu-Ps Releases and the associated causes for triggering the release procedure. When
necessary, the signalling flow is presented to illustrate the scenario (not exhaustively, meaning that
not every single message in each interface is shown).
8.4.2.2.1 Dropped Call

In a normal RAB release scenario, the Core Network initiates the call release by sending a
RANAP/IU_RELEASE_COMMAND message to the UTRAN.
A dropped call can be originated either by the UTRAN or by the Core Network. If the UTRAN has
caused the problem, the dropped call procedure will be started by the RNC sending a
RANAP/IU_RELEASE_REQUEST
message,
which
subsequently
triggers
a
RANAP/IU_RELEASE_COMMAND from the Core Network side.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 147/275
It is possible that the release causes in the RANAP/IU_RELEASE_REQUEST and the following
RANAP/IU_RELEASE_COMMAND messages are different. For instance, if the release request clearly
indicates a failure on the radio interface, the release command message may include Normal as the
cause, because this cause refers to the release of the RANAP dialogue only, and it is not related to
the release of the RABs (reason for the drop).
In general, a call drop can be generated by the following reasons:
Radio issues (interference, deficient coverage, BLER, UE measurement control failures, UL

measurement report failures)
Lack of resources (channelization codes, DL power, transport)
Mobility issues (missing neighbours, HHO failure, SHO problems, slow handovers, primary cell
change)
Defence mechanisms (board or interface reset)
Failure during the RRC procedure (systematic negative answer from the UE)
Operation and Maintenance (network operations)
Software problems
8.4.2.2.2 Counters and Screenings

In UA7.1, counter VS.IuReleaseReqPs (#0599) is used to monitor the causes for release requests
over the Iu-Ps interface. For most cases, the Information Element Cause in the
RANAP/IU_RELEASE_REQUEST_MESSAGE is used to increment the several screenings.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 148/275

Counter #0599 Screenings
0
UserInactivity
IuUserPlaneFailure
OamIntervention
UnspecifiedFailure
RepeatedIntegrityCheckFailure
UeGeneratedSignallingConnectionRelease
RadioCnxUeLost
AbnormalConditionTimerRelocExpiry
DlRLCErrSRB
UlRLCErrSRB
10
DlRLCErrTRB
11
UlRLCErrTRB
12
T360Expiry
13
ConnectionWithNodeBLost
14
ReleaseDueToUtranGeneratedReason
15
NoRemainingRAB
16
FailureInTheRadioInterfaceProcedure
17
NoResourceAvailable
18
T305Expiry
19
CellReselFail
20
UtranPageFail
21
PhyChnReestabFail
To get the number of Iu release requests sent to the Ps Core Network which are not covered by the
available screenings (i.e. due to other causes), counter VS.IuReleaseReq.PS.Sum (#0598) has been
introduced in UA06:
#0599.[OtherCause] = #0598 #0599.[Screening i].
User Inactivity (Screening #0)

This screening is incremented in case of inactivity of a Ps user with an Interactive or Background
service. It is not associated to an undesired or abnormal behaviour of the network, with a related
negative impact on customer perception, so it should not be interpreted as a dropped call.
A session is downgraded to idle mode if there has been no (or very little) user traffic for a certain
period of time. This state is also known as AO Step 3 and was previously referred to as Step 2. In this
state the session has released all its radio resources, but the PDP context is still maintained by the
core network.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 149/275

The RANAP cause used is User Inactivity (16), and this screening is systematically incremented
whenever the RNC sends a RANAP/IU_RELEASE_REQUEST message with this cause.
Iu User Plane Failure (Screening #1)

The Iu UP layer in Transparent Mode is present in the Iu user plane for transferring data transparently
over the Iu interface and it is intended for those RABs that do not require any particular feature from
the Iu UP protocol other than transfer of user data, such as Ps (the Iu UP protocol layer uses the
services of a GTP-U transport).
In opposition, the Support Mode of operation (used with AMR, for example) involves initialization, rate
control, time alignment and handling of error events. In case of Transparent Mode, the management of
the errors is performed by RANAP, which is the protocol responsible for the release of the resources
in case of failure in the Iu UP protocol, scenario for which this screening is incremented.
The RANAP cause used is Iu UP Failure (28), and this screening is systematically incremented
whenever the RNC sends a RANAP/IU_RELEASE_REQUEST message with this cause. This
screening is not used for Cs RABs.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 150/275
Oam Intervention (Screening #2)

This screening is incremented when an equipment or interface is locked, leading to the drop of the
RABs using these resources.
In case of Node B lock, feature 28584 Node B Soft Shutdown ensures a smooth shutdown of the
Node B for maintenance purposes through a gentle offload of the traffic, before the Node B is taken
out of service. Once a shutdown is triggered, the RNC bars corresponding cells to prevent new call
establishment and reduces their size by decreasing progressively the CPICH power and maximum
transmission power of each cell until the maximum transmission power reaches the minimum DL
power indicated by the Node B. This will cause existing calls to handover to an adjacent cell (when
possible) and prevents new calls from handing over to the cell.
The RANAP cause used is O&M Intervention (113), and this screening is systematically incremented
whenever the RNC sends a RANAP/IU_RELEASE_REQUEST message with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 151/275
Unspecified Failure (Screening #3)

In case of failures in the NBAP procedure during radio link setup or radio link reconfiguration (not
related to resource availability), this screening is incremented. Radio link setup failures were found
during Cell_FACH to Cell_DCH upsizing due to DL traffic resuming, when the Node B replies to the
NBAP/RADIO_LINK_SETUP message with a NBAP/RADIO_LINK_SETUP_FAILURE with cause
hardware failure or message not compatible with receiver state. The radio link reconfiguration
involves the reception of a NBAP/RADIO_LINK_RECONFIGURATION_FAILURE in the RNC with
cause hardware failure, which then triggers the Iu release request.
Other scenarios have also been identified, for which the screening is pegged when a failure occurs in
the following procedures: HSxPA mobility, iRM Scheduling and Bit Rate Adaptation (failure in the UE
side) and soft handover (during the active set update procedure). The Iu releases are triggered shortly
after reconfiguration of the radio links (including the synchronisation procedure between Node Bs and
RNC)
and
transmission
of
the
appropriate
RRC
message
(RRC/RADIO_BEARER_RECONFIGURATION or RRC/ACTIVE_SET_UPDATE).
The RANAP cause used for Iu release is Unspecified Failure (115), and this screenings is not
systematically incremented whenever the RNC sends a RANAP/IU_RELEASE_REQUEST message
with this cause (release cause for pegging of screening #12 is the same).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 152/275
Repeat Integrity Check Failure (Screening #4)

This screening is incremented in case of security mode integrity activation, when a number of integrity
checks fail for successive RRC connection oriented messages. The number of integrity failures that
lead to Iu Release is determined by static parameter nIntegrityCheckFail (set to 2) in the MIB of the
RNC.
Integrity protection is used to ensure that the content of a signalling message between the network
and the user has not been manipulated. It applies to RRC and NAS messages.
The RANAP cause used for Iu release is Repeated Integrity Check Failure (37), and this screening is
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 153/275
UE Generated Signalling Connection Release (Screening #5)

Large values for this screening have been recurrently observed in networks with large penetration of
Blackberry phones, which re-establish the connection to the network for short data transfer sessions
(approximately 3.5 seconds). When the data transfer is finalised, the UE sends the
RRC/SIGNALLING_CONNECTION_RELEASE_REQUEST message to the RNC. This occurs
periodically and should not be considered as a dropped call.
The RANAP cause used for Iu release is Release Due To UE Generated Signalling Connection
Release (40), and this screening is systematically incremented whenever the RNC sends a
RANAP/IU_RELEASE_REQUEST message with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 154/275
Radio Connection with UE Lost (Screening #6)

This scenario is related to dropped calls in areas with poor radio conditions. There are two main
events that can trigger an Iu Release Request with this cause: layer 3 timeouts or synchronisation loss
detected at Radio Link Layer, either in uplink or downlink, for the solely remaining radio link serving
the call.
For the dedicated channels, synchronisation primitives are used to indicate the synchronisation status
of the radio links. Layer 1 shall report in-sync/out-of-sync to layer 3, which in turn will evaluate the
synchronisation status and will signal a Radio Link Failure if necessary. Loss of synchronisation can
be detected in both UE and Node B.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 155/275

It is worth noting that UA6 feature 33821 RRC Connection Re-establishment allows the RNC, upon
detection of Radio Link Failure or RLC unrecoverable error (either from the Node B or the UE), to
release the old Node B resources and re-establish the call, following a Cell Update procedure
triggered by the UE.
The RANAP cause used for Iu release is Radio Connection With UE Lost (46). This screening is not
with this cause, as this RANAP cause is also used in case of radio drop detected at RLC layer (RLC
unrecoverable error with UE in Cell_DCH or Cell_FACH).
Abnormal Condition Timer Relocation Expiry (Screening #7)

The conditions for incrementing this screening concern an abnormal condition during the relocation
execution procedure, involved in 3G to 3G inter-frequency inter-RNC hard handover. After concluding
the relocation preparation phase, the RNC starts timer TRELOCOverall, defining a time interval during
which the RANAP/IU_RELEASE_COMMAND message with cause Successful Relocation must be
received, meaning that the handover has been completed. If the Iu release procedure is not initiated
towards the (source) RNC before timer expiration, the (source) RNC will trigger the abnormal Iu
release.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 156/275

The RANAP cause used for Iu release is TRELOCOverall Expiry (2), and this screening is
with this cause.
DL RLC Error SRB (Screening #8)

This screening is incremented when a loss of RLC acknowledgements leads to a RLC unrecoverable
error for the SRB in downlink, resulting in a call drop. This is a consequence of the RLC reset
procedure, initiated when the transmission of a RLC PDU does not succeed within a certain time limit,
to avoid RLC buffer overflow.
With RLC Acknowledge Mode, there must be an acknowledgment of the RLC PDU transmitted. This
mode of operation provides error correction through a retransmission mechanism. If there is no
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 157/275

answer to polling after a defined timer expires (pollingTimer), the PDU is retransmitted up to a
maximum number of times (defined by maxDat) before the SDU is discarded with a reset PDU. For
SRB3.4, maxDat is set to 40 and polling timer is equal to 100ms.
detection of Radio Link Failure or RLC unrecoverable error, to release the old Node B resources and
re-establish the call, following a Cell Update procedure triggered by the UE.
with this cause, as this RANAP cause is also used in case of radio drop detected at Radio Link layer
(Radio Link Failure) and the other cases of RLC unrecoverable error (UE in Cell_DCH or Cell_FACH).
UL RLC Error SRB (Screening #9)

This screening is equivalent to the previous one, although it is applicable when the RLC error is
detected for the SRB in uplink.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 158/275
detection of Radio Link Failure or RLC unrecoverable error, to release the old Node B resources and
re-establish the call, following a Cell Update procedure triggered by the UE.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 159/275
DL RLC Error TRB (Screening #10)

This screening is incremented when a loss of RLC acknowledgements leads to a RLC unrecoverable
error for the TRB in downlink (detected by the RNC), resulting in a call drop. This may happen when
the UE is in Cell_FACH state or Cell_DCH state.
As in the SRB case (2 previous screenings), UA6 feature 33821 RRC Connection Re-establishment
allows the RNC, upon detection of RLC unrecoverable error, to re-establish the call, following a Cell
Update procedure triggered by the UE. This is applicable when the RLC error occurs with the UE in
Cell_DCH state.
UL RLC Error TRB (Screening #11)

This screening is equivalent to the previous one, although it is applicable when the RLC error is
detected for the TRB in uplink.
As in the SRB case (screenings #8 and #9), UA6 feature 33821 RRC Connection Re-establishment
allows the RNC, upon detection of RLC unrecoverable error, to re-establish the call, following a Cell
Update procedure triggered by the UE. This is applicable when the RLC error occurs with the UE in
Cell_DCH state.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 160/275

T360 Expiry (Screening #12)

This screening is incremented if the RNC, after sending the RRC/RADIO_BEARER_RELEASE
message,
does
not
receive
the
RRC/RADIO_BEARER_RELEASE_COMPLETE
or
RRC/RADIO_BEARER_RELEASE_FAILURE before expiry of timer T360.
The RANAP cause used for Iu release is Unspecified Failure (115). This screening is not
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 161/275
Connection with Node B Lost (Screening #13)

This screening was introduced in UA6, and is intended to separate the losses in the radio part
(covered by radio link failure and RLC unrecoverable error scenarios) from the ones that occur due to
a break of communication with the Node B, in case of loss of AAL2, SSCOP, NBAP reset or RSI, other
than the cases covered by screening O&M Intervention.
The RANAP cause used is Radio Connection With UE Lost (46), and this screening is not
with this cause, as this screening is also used in case of radio link loss or RLC reset, as described in
some of the sections above.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 162/275
Release due to UTRAN Generated Reason (Screening #14)

This screening is incremented in case of breakdown during a RRC procedure, most notably failures
when reconfiguring a radio bearer RB Bit Rate Adaptation, Always-On Step 1 downsize, etc due to
timer T361 expiry (RNC does not receive RRC/RADIO_BEARER_RECONFIGURATION_COMPLETE
or
RRC/RADIO_BEARER_RECONFIGURATION_FAILURE
message
after
sending
RRC/RADIO_BEARER_RECONFIGURATION.
The RANAP cause used is Release Due To Utran Generated Reason (15), and this screening is
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 163/275
No Remaining RAB (Screening #15)

This screening is incremented following an Iu Release Request as a response to a
RANAP/RAB_ASSIGNMENT_REQUEST message with RAB to release. As such, it should not be
considered as a dropped call.
The RANAP cause used is No Remaining RAB (31), and this screening is systematically
incremented whenever the RNC sends a RANAP/IU_RELEASE_REQUEST message with this cause.
Failure in the Radio Interface Procedure (Screening #16)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 164/275

This screening is incremented whenever a procedure involving the core network is not successful due
to a failure in a UTRAN related process, most commonly during RAB establishment when the setup of
the
radio
bearer
fails
or
during
the
security
mode
procedure
in
case
a
RANAP/SECURITY_MODE_REJECT message is sent by the RNC.
The RANAP cause used is Failure In The Radio Interface Procedure (14), and this screening is
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 165/275
No Resource Available (Screening #17)

This screening is incremented in case of lack of resources that prevent a successful outcome of a
procedure (power, codes, CE). The most common case seen is for Always-On upsizing, following
traffic resuming in DL.
The RANAP cause used is No Resource Available (114), and this screening is systematically
incremented whenever the RNC sends a RANAP/IU_RELEASE_REQUEST message with this cause.
T305 Expiry (Screening #18)

This screening is incremented when the timerCellUpdateProcessingMargin in the RNC used to detect
users in Cell_FACH state which have lost coverage but whose resources are yet to be released.
While in Cell_FACH the UE must periodically signal its location to the network. The periodicity is
defined by timer T305, which starts when the UE enters Cell_FACH state at the reception of
RRC/CELL_UPDATE_CONFIRM message and stops after a transition to another RRC state.
At expiry of T305, the UE transmits a RRC/CELL_UPDATE (cause periodical cell update) if the UE
detects in service area and timer T307 is not activated. Otherwise, if UE detects out of service
area, T307 is started, if not active. At T307 expiry, the UE goes to idle mode and all resources are
released. The RNC will later release all the resources associated to this UE, as it wont receive a
periodic cell update after expiry of timerCellUpdateProcessingMarge (in the same way, these
resources will be equally released even if the UE sends the RRC/CELL_UPDATE message, but it
does not reach the RNC).
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 166/275
Cell Reselection Fail (Screening #19)

The pre-condition for incrementing this screening is the UE being in Cell_FACH state and sending a
RRC/CELL_UPDATE message to the RNC with cause cell reselection. The RNC has new cell
common channel resources available and sends a RRC/CELL_UPDATE_CONFIRM message.
The screening is incremented if, after a number of repetitions of the RRC/CELL_UPDATE message
(defined by N362), there is still no response from the UE.
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 167/275
UTRAN Page Fail (Screening #20)

This screening is incremented when the UE is in Cell_PCH state and the number of Paging Type 1
retries is decremented to zero.
with this cause.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 168/275

Physical Channel Reestablishment Fail (Screening #21)
The pre-condition for incrementing this screening is the UE being in URA_PCH state and sending a
RRC/CELL_UPDATE message to the RNC with cause uplink data transmission. The RNC has new
cell common channel resources available and sends a RRC/CELL_UPDATE_CONFIRM message to
the UE.
The screening is pegged if the UE sends a RRC/CELL_UPDATE message with cause radio link
failure in response to the RRC/CELL_UPDATE_CONFIRM message sent by the RNC.
with this cause.
8.4.3
Retainability troubleshooting
The call is no more active from the user perspective (CS) or degradation is perceived (PS):
When a CS RAB drops, the e2e CS call will also drop and this service loss is perceived by the
user.
When a PS RAB drops, the PS e2e session is not automatically lost. If the SGSN has
remaining data in its buffers for the user, the UE is automatically paged and a new PS RAB
may be established. Then, the e2e throughput decreases due to the RAB re-establishment but
there is no service (and data) loss at user level.
The retainability analysis is firstly perform by the detail monitoring report which evaluate the call drop
rate trends at RNC level and at Cell level.
The results should be provided per service (voice, video, PS) and per RNC (or cluster) to help the
troubleshooting.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 169/275

Issue characterization :
To define the prob lem , 2 paralel

analysis to correla te :
Distribution per Failure cases analysis :
which failure cause
Retainability Analysis
RNC level
Distribution per Service failure analysis

( which RB are affected ?)
High Call Drop Rate

at RNC level
SRB
Iu008, Iu007 SRB increases
Acc essibility Analysis

RNC level
Iu007>3%
(Threshold
according the
customer)
CS High Call drop rate at RNC level
Can it affect certain /all services (CS, PS,
SRB,etc )
Certain /all Network elements, Top N cells
Certain /all period of time, since when
Certain failure causes
After certain event ( upgrade, feature
activation , configuration changes)
PS High Call drop rate at RNC level
Iu007- CS >2%
(Threshold
according the
customer)
CS Retainability
RNC level
Iu007- PS >4%
(Threshold
according the
customer)
PS Retainability per RB
RNC level
Th reshold need to be ad apted to the

operator case, see thresho ld info
Figure 8-48: Retainability troubleshooting
In terms of troubleshooting investigation, the two following points are study:
Spatial elements : drop degradation is localized in specific cells or generalized on all the
network
Time when the degradation occurred: in order to link it with events that occur on the network
(software upgrade, patch application, )
Once the degradation has been identified (domain, period) and the distribution per failure cause has
be done thanks to the views described above in section 8.4.2.1, the retainability troubleshooting can
go on by following the procedure described in the chart hereunder with the help of Call drop
troubleshooting reports:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 170/275
Retainability Analysis
RNC level
Two Analysis
Valid for CS/PS
Distribution per failure

cause
CS High Call drop rate at RNC level
PS High Call drop rate at RNC level
Top N worst cells for the

causes that have more
weight in the distribution
OAM Intervention
Note: RLC erroron CS

calls is only possible for
SRB
Distribution of Iureleaserequest_CS/PS
(per causes)
UeGenerated
Signalling
RepeatedIntegrity ConnectionRelease
CheckFailure
IuUserPlaneFailure
Mobile issue?
CTg to check
Integrity
Analysis
CTg analisys
No action
Capacity Analysis
CPU PMC_RAB
AbnormalCondition
TimerRelocExpiry
RadioConnection
WithUeLost
DlRLCErrSRB
DlRLCErrTRB
UlRLCErrSRB
UlRLCErrTRB
3g 2g
mobility analysis
It can be correlated wtih

RL failure indication
DL/UL RF analysis
DL BLER analysis
Actions:
Check TX
links, HW, etc
Quality Analysis
T360 expiry
Abnormal resource
releases
To correlate with Abnormal
release counters
SRLR parameters
Capacity analysis
Stability Analysis
PCM, RNC
Node B
Alarm correlation?
Bad DL BLER?
RB reconfiguration
success rate decrease?
#0008 all
failures
SHO analysis
Failures in
radio link
reconfiguration?
SHO failure metric increase?

RL036, RL037
Figure 8-49: Analysis of Iu release request failures
The retainability troubleshooting report will manage the CS call drop and the PS call drop at Cell level
and at RNC level.
The last version of UA7.1 retainability troubleshooting report (Retainability_1) is included in the
Troubleshooting dictionary which is available on livelink at the following location:
8.5.
TRAFFIC MONITORING AND TROUBLESHOOTING
8.5.1
First level of traffic monitoring
The first step of network traffic monitoring consists in evaluating the evolution of DL and UL traffic
based on views available in the dashboard dictionary at RNC level and at Cell level and described in
section 8.5.2.1.1 and 8.5.1.2. The analysis of these views gives the traffic volume for PS and CS calls.
In case of a traffic issue observed in these views for PS or CS calls, it will be necessary to define more
precisely
UMT/IRC/INF/012027
07.02 /EN
Preliminary
Unspecified
Failure
25/June/2010
Page 171/275
the affected network elements
the affected period of time
the events occurred on the network
and to give details on
the affected type(s) of traffic
the type of issue
thanks to the detailed monitoring of KPIs and troubleshooting.
8.5.1.1
RNC dashboard traffic views
This view provides basic information on the traffic transmitted on the downlink for a RNC, measured in
terms of Kbytes of the payload for the transmitted RLC SDUs. Since it includes data for Cs and Ps, it
is possible to have an indication on the main service in terms of carried traffic, as well as which
fraction of Ps traffic is related to HSDPA. The information obtained should be complemented by the
results retrieved from other traffic views included in the Detailed Monitoring section.
Figure 8-50: Display of View Rnc_Dl_Traffic_Overview
Name
Description
Overview of DL RLC payload traffic at RNC level.
Graph
Families
DASHBOARD
TRAFFIC
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
TrafficDLSDUPayloadInKbytes_Traffic015
UMT/IRC/INF/012027
07.02 /EN
Total number of Kbytes of RLC SDU sent on
Preliminary
25/June/2010
Page 172/275

_R_CsVoice
_R_CsVideo
downlink on dedicated channels, for voice calls.

downlink on dedicated channels, for video calls.
_R_Ps

downlink on dedicated channels, for Ps calls.
_R_HSDPA

downlink on dedicated channels, for HSDPA calls.
Table 8-46: Properties of View Rnc_Dl_Traffic_Overview
This view provides basic information on the traffic transmitted on the uplink for a RNC, measured in
terms of Kbytes of the payload for the transmitted RLC SDUs. Since it includes data for Cs and Ps, it
is possible to have an indication on the main service in terms of carried traffic, as well as which
fraction of Ps traffic is related to HSUPA. The information obtained should be complemented by the
results retrieved from other traffic views included in the Detailed Monitoring section.
Figure 8-51: Display of View Rnc_Ul_Traffic_Overview
Name
Description
Overview of UL RLC payload traffic at RNC level.
Graph
Families
DASHBOARD
TRAFFIC
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
TrafficULSDUPayloadInKbytes_Traffic016
UMT/IRC/INF/012027
07.02 /EN
Total number of Kbytes of RLC SDU sent on uplink
Preliminary
25/June/2010
Page 173/275

_R_CsVoice
_R_CsVideo
on dedicated channels, for voice calls. Presented on

primary axis.
on dedicated channels, for video calls. Presented on
primary axis.
_R_Ps

on dedicated channels, for Ps calls. Presented on
primary axis.
_R_HSUPA

on dedicated channels, for HSUPA calls. Presented
on primary axis.
Table 8-47: Properties of View Rnc_Ul_Traffic_Overview
8.5.1.2
Cell dashboard traffic views
This view provides basic information on the traffic transmitted on the downlink on the dedicated
channels of a cell, measured in terms of Kbytes of the payload for the transmitted RLC SDUs. Since it
includes data for Cs and Ps, it is possible to have an indication on the main service in terms of carried
traffic, as well as which fraction of Ps traffic is related to HSDPA. The information obtained should be
complemented by the results retrieved from other traffic views included in the Detailed Monitoring
section.
Figure 8-52: Display of View Cell_Dl_Traffic_Overview
Name
Description
Overview of DL RLC payload traffic at cell level.
Graph
Families
DASHBOARD
TRAFFIC
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 174/275

OZ_RNC
NETWORK
Indicators
TrafficDLSDUPayloadInKbyte_Traffic017_
C_CsVoice
C_CsVideo

downlink on dedicated channels, for each cell of the
active set, for voice calls. Presented on primary axis.
active set, for video calls. Presented on primary axis.
C_Ps

active set, for PS calls. Presented on primary axis.
C_HSDPA

active set, for HSDPA calls. Presented on primary
axis.
Table 8-48: Properties of View Cell_Dl_Traffic_Overview
This view provides basic information on the traffic transmitted on the uplink dedicated channels of a
cell, measured in terms of Kbytes of the payload for the transmitted RLC SDUs. Since it includes data
for Cs and Ps, it is possible to have an indication on the main service in terms of carried traffic, as well
as which fraction of Ps traffic is related to HSUPA. The information obtained should be complemented
by the results retrieved from other traffic views included in the Detailed Monitoring section.
Figure 8-53: Display of View Cell_Ul_Traffic_Overview
Name
Description
Overview of UL RLC payload traffic at cell level.
Graph
Families
DASHBOARD
TRAFFIC
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 175/275

OZ_RNC
NETWORK
Indicators
TrafficULSDUPayloadInKbyte_Traffic018_
C_CsVoice
C_CsVideo

on dedicated channels, for each cell of the active set,
for voice calls. Presented on primary axis.
for video calls. Presented on primary axis.
C_Ps

for PS calls. Presented on primary axis.
C_HSUPA

for HSUPA calls. Presented on primary axis.
Table 8-49: Properties of View Cell_Ul_Traffic_Overview
8.5.2
Detailed traffic monitoring
Once a traffic issue has been identified thanks to the dashboard report, the detailed monitoring will
focus on the affected type of traffic (DL or UL, PS or CS calls, in case of PS (R99, HSxPA)). Main
RNC level traffic views available for detailed monitoring are listed in this section. Most of them are also
available at cell level.
The detailed monitoring traffic views are mainly reported
the number of Kbytes of transmitted RLC SDUs
the number of RB established
The HSDPA or EDCH throughput and usage penetration
The mean call duration and activity Rate
This will allow to understand the ratios of resources usage vs. efficiency of data transmission, these
indicators are essential to evaluate in case of any network modification evaluation (parameter tuning,
upgrade, traffic evolution or capacity evaluation)
If a deeper analysis of traffic is needed, the traffic troubleshooting report will be used (see section
8.5.3).
8.5.2.1
Gobal traffic monitoring
The main global traffic views of the detailed monitoring dictionary are presented below on table and
described in section 8.5.2.1.1 and 8.5.2.1.2.
Traffic
Subfamily
Level
View name
Global
RNC
Traffic_Dl_Rnc
RNC
Traffic_Dl_PS_Distr_Rnc
UMT/IRC/INF/012027
07.02 /EN
Comment
downlink per QoS traffic class (CS & PS)
downlink per QoS traffic class (PS distribution)
Preliminary
25/June/2010
Page 176/275
RNC
Traffic_Dl_BH_Rnc
RNC
Traffic_Dl_per_Tc_Rnc
RNC
Traffic_Ul_Rnc
RNC
Traffic_Ul_PS_Distr_Rnc
RNC
Traffic_Ul_BH_Rnc
RNC
Traffic_Ul_per_Tc_Rnc
RNC
Average_Number_Bearers
RNC
Average_Number_Bearers_BH
RNC
Traffic_Profile_at_Radio_Link_S
etup
RNC
RNC
RNC
RNC

downlink, at traffic busy hour, per QoS traffic class
(CS & PS)
downlink per QoS traffic class and transport channel
Total number of Kbytes of RLC SDU received on
Uplink per QoS traffic class (CS & PS)
uplink per QoS traffic class (PS distribution)
uplink, at traffic busy hour, per QoS traffic class (CS
& PS)
uplink per QoS traffic class and transport channel
Average_Number_Bearers per QoS traffic class
Average_Number_Bearers for the BH per PS
service
Traffic profile in terms of CS, PS and multi

RAB (CS+PS) radio links
Number of RB establishment attempts per QoS
Traffic_Profile_at_RAB_Attempt
traffic class
Number of RB setup success per QoS traffic
Traffic_Profile_at_RB_Setup
class
All screenings of VS.NumberOfRabEstablished
Traffic_Profile_During_Call
(U1666)
Traffic_Profile_During_Call_Distr Number of PS RABs in cell DCH per traffic
_PS
class split up per transport channel
Table 8-50: List of main Views at Global traffic views RNC
Traffic
Subfamily
Global
The same analysis can be detailed at Cell Level as well.

Level
View name
Comment
Cell
Traffic_Dl_Cell
Cell
Traffic_Dl_PS_Distr_Cell
Cell
Traffic_Ul_Cell
Cell
Traffic_Ul_PS_Distr_Cell
Cell
Cell
Cell
Traffic_Profile_at_Radio_Link_S
etup
Cell
Cell
Cell
Cell

downlink per QoS traffic class (CS & PS)
downlink per QoS traffic class (PS distribution)
Uplink per QoS traffic class (CS & PS)
uplink per QoS traffic class (PS distribution)
Average_Number_Bearers per QoS traffic class
Average_Number_Bearers for the BH per PS
service
Traffic profile in terms of CS, PS and multi

RAB (CS+PS) radio links
Number of RB establishment attempts per QoS
traffic class
Number of RB setup success per QoS traffic
Traffic_Profile_at_RAB_Setup
class
All screenings of VS.NumberOfRabEstablished
(U1666)
Traffic_Profile_During_Call_Distr Number of PS RABs in cell DCH per traffic
_PS
class split up per transport channel
Table 8-51: List of main Views at Global traffic views Cell
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 177/275

8.5.2.1.1 Global traffic views RNC
The following views described have the goal of providing a global view on the traffic evolution at RNC
Level.
8.5.2.1.1.1 Downlink traffic per QoS class

This section presents different useful views to monitor the downlink traffic per QoS service class.
Traffic_Dl_Rnc
terms of Kbytes of the payload for the transmitted RLC SDUs. Since it includes data for CS and PS it
is possible to have an indication on the main service in terms of carried traffic. The information
obtained should be complemented by the results retrieved from other traffic views included in the
Detailed Monitoring section.
Example:
The figure below displays the Traffic_Dl_Rnc view for Network_A, during a given period of time. After
a brief analysis it is clear that the main service in terms of carried traffic is PS. In order to check how
the DL traffic is distributed between the different PS services, the display of the Traffic_Dl_
PS_Distr_Rnc view is required.
Figure 8-54: Display of View Traffic_Dl_Rnc (Graphical/Tabular)
Name
Traffic_Dl_ Rnc
Description
Overview of DL RLC payload traffic at RNC level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Weekly
Monthly
Availability Domain
Hourly
Daily
CELL3G
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 178/275

OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
_R_CsVoice
_R_CsVideo
_R_Ps

downlink on dedicated channels, for voice calls.
downlink on dedicated channels, for video calls.
downlink on dedicated channels, for Ps calls.
Table 8-52: Properties of View Traffic_Dl_Rnc
Monitor the Split of Traffic between PS Services

The following view allows monitoring the split of traffic between PS services. This view gives an
indication of how the PS DL traffic is distributed between PS64, PS128, PS384 and HSDPA services.
Traffic_Dl_PS_Distr_Rnc
terms of Kbytes of the payload for the transmitted RLC SDUs for PS services. With this view it is
possible to have an indication on which fraction of PS traffic is related to PS64, PS128, PS384 and
HSDPA. The information obtained should be complemented by the results retrieved from other traffic
views included in the Detailed Monitoring section.
Example:
The figure below displays the Traffic_Dl_PS_Distr_Rnc view for Network_A, during a given period of
time. This view shows that HSDPA represents the main service regarding carried traffic. It is also
visible that PS64 and PS128 services present a lower usage when comparing with PS384 or HSDPA.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 179/275

Figure 8-55: Display of View Traffic_Dl_PS_Distr_Rnc (Graphical/Tabular)
Name
Traffic_Dl_PS_Distr_ Rnc
Overview of DL RLC payload traffic PS distribution at RNC
level.
Graph
Description
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
_R_PS64

downlink on dedicated channels, for Ps 64 calls.
_R_PS128

_R_PS384

_R_HSDPA

Table 8-53: Properties of View Traffic_Dl_PS_Distr_Rnc
Carried traffic at Traffic Busy-Hour for CS & PS services

The following view gives an indication of the carried traffic at traffic busy-hour per CS and PS services.
Traffic_Dl_BH_Rnc
terms of Kbytes of the payload for the transmitted RLC SDUs at traffic busy hour. With this view it is
possible to have an indication of the carried traffic at traffic busy-hour per CS and PS services.
Basically this view indicates the amount of traffic carried at traffic busy-hour for all the indicators of
both views of this section, i.e. Traffic_Dl_Rnc and Traffic_Dl _PS_Distr_Rnc.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 180/275

Example:
The figure below displays the Traffic_Dl_BH_Rnc view for Network_A, during a given period of time.
The graphical view gives an indication of which services carrier more traffic during the busy-hour. A
more detailed analysis requires the display of the tabular view.
Figure 8-56: Display of View Traffic_Dl_BH_Rnc (Graphical/Tabular)
Name
Traffic_Dl_ BH_Rnc
Description
Overview of DL RLC payload traffic for the BH at RNC level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
_R_CsVoice_atTrafficBusyHour

downlink, at traffic busy hour, on dedicated channels,
for voice calls.
_R_CsVideo_atTrafficBusyHour

for video calls.
_R_PS64_atTrafficBusyHour

for Ps 64 calls.

UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 181/275

for Ps 128 calls.

for Ps 384 calls.
_R_HSDPA_atTrafficBusyHour

Table 8-54: Properties of View Traffic_Dl_BH_Rnc
8.5.2.1.1.2 Downlink traffic per QoS class and transport channel

This section presents a useful view to monitor the DL traffic per PS interactive and PS background
services distributed over DCH (R99) and HS-DSCH (HSDPA) transport channels.
Traffic_Dl_per_Tc_Rnc
This view provides basic information on the downlink traffic transmitted on the dedicated channels for
QoS traffic class, measured in terms of Kbytes of the payload for the transmitted RLC SDUs. Since it
includes data for background and interactive, it is possible to have an indication on the main service in
terms of carried traffic as well as which fraction corresponds to DCH and HS-DSCH. The information
On the one hand, the indicators Traffic053_R_Bgrd_HsDsch and Intact_HsDsch allow to zoom in the
Traffic015_R_HSDPA indicator (from Traffic_Dl_PS_Distr_Rnc view), and check which fraction of
HSDPA traffic corresponds to interactive and background.
On the other hand, it is possible to have an indication of which fraction of PSxxx traffic corresponds to
interactive and background; that is, the sum of Traffic053_R_Bgrd_DCH and Intact_DCH is
approximately equal to the sum of the indicators Traffic015_R_64, _128 and _384 (from
Traffic_Dl_PS_Distr_Rnc view).
Example:
The figure below displays the Traffic_Dl_per_Tc_Rnc view for Network_A, during a given period of
time. This view gives the kbytes sent on downlink for PS interactive and PS background services for
R99 and HSDPA technologies. As shows the figure, the PS interactive on HSDPA presents as the
main service in terms of carried traffic.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 182/275
Figure 8-57: Display of View Traffic_Dl_per_Tc_Rnc (Graphical/Tabular)
Notice that this view is only available at RNC level.

Name
Traffic_Dl_per_Tc_ Rnc
Overview of DL RLC payload traffic per QoS traffic class and
transport channel at RNC level.
Graph
Description
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
TrafficDLSDUPayloadPerQos_traffic053_
R_Bgrd_DCH
Downlink volume in Kbytes of RLC payload on

dedicated channel, for QoS class background on
DCH transport channel.
R_Bgrd_HsDsch

dedicated channel, for QoS class background on HSDSCH transport channel.
R_Intact_DCH

dedicated channel, for QoS class interactive on DCH
transport channel.
R_Intact_HsDsch

dedicated channel, for QoS class interactive on HSDSCH transport channel.
Table 8-55: Properties of View Traffic_Dl_per_Tc_Rnc
8.5.2.1.1.3 Downlink traffic per QoS class when cell is reference vs. in the active set
This
section
intends
to
clarify
the
difference
between
the
basic
indicators
VS_DedicatedDownlinkKbytesRlcReferenceCell and VS_DedicatedDownlinkKbytesRlcActiveCells.
The description of these basic indicators is the following:
VS_DedicatedDownlinkKbytesRlcReferenceCell represents the number of kbytes transmitted

on downlink for the serving/reference cell.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 183/275
VS_DedicatedDownlinkKbytesRlcActiveCells represents the number of kbytes transmitted on

downlink for the cells on the active set.
Example:
The baseline indicator Traffic015_R_CsVoice (from Traffic_Dl_Rnc view) is defined directly by the
basic indicator VS_DedicatedDownlinkKbytesRlc_DlRabCsSpeech. On its turn, this basic indicator is
approximately equal to the VS_DedicatedDownlinkKbytesRlcReferenceCell_DlRabCsSpeech, as
presented on the figure below.
As expected, the VS_DedicatedDownlinkKbytesRlcActiveCells_DlRabCsSpeech shows a higher
number of kbytes carried. The ratio between xxRLCReferenceCell_DlRabCsSpeech and
xxRLCActiveCells_DlRabCsSpeech is given by Traffic019_C_CsVoice.
Figure 8-58: Baseline indicator Traffic015_R_CsVoice and basic indicators U1554_2 & U1556_2
The indicator PercentageOfDLTrafficWhenCellIsReference_Traffic019_C_CsVoice represents the

number of Kbytes transmitted on downlink when cell is reference versus the traffic carried when cell is
in the active set for CS Voice.
On the example below, at 06/15/2010, 86.5% of the traffic was carried when only one cell was in the
active set. On the other hand, the remains 13.5% corresponds to the SHO overhead.
Figure 8-59: Baseline indicator Traffic019_C_CsVoice
At RNC level this indicator gives the global SHO overhead. At Cell level it can be useful for
troubleshooting SHO problems, i.e. a cell with high percentage of SHO overhead means that the cell
is frequently reported but not frequently the serving cell (dominance area/coverage should be
checked).
Notice that indicator Traffic019_C is available for CsVoice, CsVideo, PS and PsStreaming.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 184/275

8.5.2.1.1.4 Uplink traffic per QoS class
This section presents different useful views to monitor the uplink traffic per QoS service class.
Traffic_Ul_Rnc
This view provides basic information on the traffic received on the uplink for a RNC, measured in
terms of Kbytes of the payload for the received RLC SDUs. Since it includes data for CS and PS, it is
possible to have an indication on the main service in terms of carried traffic. The information obtained
should be complemented by the results retrieved from other traffic views included in the Detailed
Monitoring section.
Example:
The figure below displays the Traffic_Ul_Rnc view for Network_A, during a given period of time. After
a brief analysis it is clear that the main service in terms of carried traffic is PS. In order to check how
the UL traffic is distributed between the different PS services, the display of the Traffic_Ul_
PS_Distr_Rnc view is required.
Figure 8-60 : Display of View Traffic_Ul_Rnc (Graphical/Tabular)
Name
Traffic_Ul_Rnc
Description
Overview of UL RLC payload traffic at RNC level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 185/275

_R_CsVoice
_R_CsVideo
_R_Ps
uplink on dedicated channels, for voice calls.

uplink on dedicated channels, for video calls.
uplink on dedicated channels, for Ps calls. Presented
on primary axis.
Table 8-56: Properties of View Traffic_Ul_Rnc

indication of how the PS UL traffic is distributed between PS64, PS128, PS384 and HSUPA services.
This view provides basic information on the traffic received on the uplink for a RNC, measured in
terms of Kbytes of the payload for the received RLC SDUs for PS services. With this view it is possible
to have an indication on which fraction of PS traffic is related to PS64, PS128, PS384 and HSUPA.
The information obtained should be complemented by the results retrieved from other traffic views
included in the Detailed Monitoring section.
Example:
The figure below displays the Traffic_Ul_PS_Distr_Rnc view for Network_A, during a given period of
time. This view shows that HSUPA represents the main service regarding carried traffic. It is also
visible that PS64 and PS128 services present a lower usage when comparing with PS384 or HSUPA.
Figure 8-61 : Display of View Traffic_Ul_PS_Distr_Rnc (Graphical/Tabular)
Name
Description
UMT/IRC/INF/012027
Overview of UL RLC payload traffic PS distribution at RNC
level.
Graph
07.02 /EN
Preliminary
25/June/2010
Page 186/275

Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
RNC
OZ_RNC
NETWORK
CELL3G
OZ_CELL3G
Indicators
_R_PS64

uplink on dedicated channels, for Ps 64 calls.
_R_PS128

_R_PS384

_R_HSUPA

uplink on dedicated channels, for HSUPA calls.
Table 8-57: Properties of View Traffic_Ul_PS_Distr_Rnc
Carried traffic at Traffic Busy-Hour for CS & PS services

The following view gives an indication of the carried traffic at traffic busy-hour per CS and PS services.
Traffic_Ul_BH_Rnc
This view provides basic information on the traffic transmitted on the uplink for a RNC, measured in
terms of Kbytes of the payload for the received RLC SDUs at traffic busy hour. With this view it is
possible to have an indication of the carried traffic at traffic busy-hour per CS and PS services.
Basically this view indicates the amount of traffic carried at traffic busy-hour for all the indicators of
both views of this section, i.e. Traffic_Ul_Rnc and Traffic_Ul _PS_Distr_Rnc.
Example:
The figure below displays the Traffic_Ul_BH_Rnc view for Network_A, during a given period of time.
The graphical view gives an indication of which services carrier more traffic during the busy-hour. A
more detailed analysis requires the display of the tabular view.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 187/275
Figure 8-62: Display of View Traffic_Ul_BH_Rnc (Graphical/Tabular)
Name
Traffic_Ul_BH_Rnc
Description
Overview of UL RLC payload traffic for the BH at RNC level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
_R_CsVoice_atTrafficBusyHour

uplink, at traffic busy hour, on dedicated channels, for
voice calls. Presented on primary axis.
_R_CsVideo_atTrafficBusyHour

uplink, at busy hour, on dedicated channels, for video
calls. Presented on primary axis.

Ps 64 calls. Presented on primary axis.


_R_HSUPA_atTrafficBusyHour

HSUPA calls. Presented on primary axis.
Table 8-58: Properties of View Traffic_Ul_BH_Rnc
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 188/275
8.5.2.1.1.5 Uplink traffic per QoS class and transport channel

This section presents a useful view to monitor the UL traffic per PS interactive and PS background
services distributed over DCH (R99) and EDCH (HSUPA) transport channels.
This view provides basic information on the uplink traffic received on the dedicated channels for QoS
traffic class, measured in terms of Kbytes of the payload for the received RLC SDUs. Since it includes
data for background and interactive, it is possible to have an indication on the main service in terms of
carried traffic as well as which fraction corresponds to DCH and EDCH. The information obtained
Monitoring section.
On the one hand, the basic indicators VS_DedicatedUplinkKbytesRlc_QoS_Bgrd_EDCH and Intact_EDCH
allow to zoom in the Traffic016_R_HSUPA indicator (from Traffic_Ul_PS_Distr_Rnc view), and
check which fraction of HSUPA traffic corresponds to interactive and background.
On the other hand, it is possible to have an indication of which fraction of PSxxx traffic corresponds to
interactive and background; that is, the sum of VS_DedicatedUplinkKbytesRlc_QoS_Bgrd_DCH and
Intact_DCH is approximately equal to the sum of the indicators Traffic016_R_64, _128 and _384 (from
Traffic_Ul_PS_Distr_Rnc view).
Notice that this view is only available at RNC level.
Name
Overview of UL RLC payload traffic per QoS traffic class and
transport channel at Rnc level.
Graph
Description
Families
DETAILED MONITORING
USER PLANE
DEDICATED TRAFFIC
TRAFFIC
RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_DedicatedUplinkKbytesRlc_QoS_Bgr
d_DCH
Uplink volume in Kbytes of RLC payload on

dedicated channel, for QoS class background on
DCH transport channel.
VS_DedicatedUplinkKbytesRlc_QoS_Bgr
d_EDCH

dedicated channel, for QoS class background on HSDSCH transport channel.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 189/275

VS_DedicatedUplinkKbytesRlc_QoS_Inta
ct_DCH

dedicated channel, for QoS class interactive on DCH
transport channel.
VS_DedicatedUplinkKbytesRlc_QoS_Inta
ct_EDCH

dedicated channel, for QoS class interactive on HSDSCH transport channel.
Table 8-59: Properties of View Traffic_Ul_per_Tc_Rnc
8.5.2.1.1.6 Uplink traffic per QoS class when cell is reference vs. in the active set
This
section
intends
to
clarify
the
difference
between
the
basic
indicators
VS_DedicatedUplinkKbytesRlcReferenceCell and VS_DedicatedUplinkKbytesRlcActiveCells.
The description of these basic indicators is the following:
VS_DedicatedUplinkKbytesRlcReferenceCell represents the number of kbytes received on

uplink for the serving/reference cell.
VS_DedicatedDownlinkKbytesRlcActiveCells represents the number of kbytes received on

uplink for the cells on the active set.
Example:
The baseline indicator Traffic016_R_CsVoice (from Traffic_Ul_Rnc view) is defined directly by the
basic indicator VS_DedicatedUplinkKbytesRlc_UlRabCsSpeech. On its turn, this basic indicator is
approximately equal to the VS_DedicatedUplinkKbytesRlcReferenceCell_UlRabCsSpeech, as
presented on the figure below.
As expected, the VS_DedicatedUplinkKbytesRlcActiveCells_UlRabCsSpeech shows a higher number
of
kbytes
carried.
The
ratio
between
xxRLCReferenceCell_UlRabCsSpeech
and
xxRLCActiveCells_UlRabCsSpeech is given by Traffic021_C_CsVoice.
Figure 8-63: Baseline indicator Traffic016_R_CsVoice and basic indicators U1555_2 & U1553_2
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 190/275

The indicator PercentageOfULTrafficWhenCellIsReference_Traffic021_C_CsVoice represents the
number of Kbytes received on uplink when cell is reference versus the traffic carried when cell is in the
active set for CS Voice.
On the example below, at 06/15/2010, 89.9% of the traffic was carried when only one cell was in the
active set. On the other hand, the remains 10.1% corresponds to the SHO overhead.
Figure 8-64: Baseline indicator Traffic021_C_CsVoice
At RNC level this indicator gives the global SHO overhead. At Cell level it can be useful for
troubleshooting SHO problems, i.e. a cell with high percentage of SHO overhead means that the cell
is frequently reported but not frequently the serving cell (dominance area/coverage should be
checked).
Notice that indicator Traffic021_C is available for CsVoice, CsVideo, PS and PsStreaming.
8.5.2.1.1.7 Radio Bearer usage per QoS class

This section presents a useful view to monitor the Radio Bearer usage per QoS service class
This view provides the main indicators with the average information related with the RB usage
comparing different services. It is useful to know the distribution of channel occupancy (erlang) PS
versus CS and as well detailing this information per transport channel type used in UL/DL for the
particular cases of HSUPA and HSDPA.
Example:
The figure below displays the Average_Number_Bearers view for Network_A, during a given period
of time. After a brief analysis it is clear that the main service in terms of channel occupancy is PS. On
its turn, HSDPA represents the major slice of PS channel occupancy.
Figure 8-65: Display of View Average_Number_Bearers (Graphical/Tabular)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 191/275
Name
Description
Average_Number_Bearers per QoS traffic class at RNC level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC/CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
AverageNumberOfDLBearersEstablis
hed_RB013_CR_CsVoice(URB013_
CR_DLCsVoice)(nb)
Average number of established Downlink Access

Stratum configuration in the RNS during a reporting
period. Cs Voice
hed_RB013_CR_HSDPA(URB013_C
R_HSDPA)(nb)

period. DL PS HSDPA
hed_RB013_CR_Ps(URB013_CR_D
LPs)(nb)

period. DL total PS
AverageNumberOfULBearersEstablis
hed_RB013_CR_HSUPA(URB013_C
R_ULHSUPA)(nb)

period. UL PS HSUPA
Table 8-60: Properties of View Average_Number_Bearers
Channel Occupancy at Traffic Busy-Hour for PS services

The following view gives an indication of the channel occupancy at traffic busy-hour detailed per PS
services.
Basically this view indicates the channel occupancy at traffic busy-hour for PS indicators of the view
Average_Number_Bearers.
Example:
The figure below displays the Average_Number_Bearers_BH view for Network_A, during a given
period of time. The graphical view gives an indication of the channel occupancy during the busy-hour.
A more detailed analysis requires the display of the tabular view.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 192/275
Figure 8-66: Display of View Average_Number_Bearers_BH (Graphical/Tabular)
Name
Average_Number_Bearers for the BH per PS service at RNC
level.
Graph
Description
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
RNC
Availability Domain
Hourly
Daily
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Weekly
Monthly
Indicators
hed_RB013_CR_HSDPA_atTrafficBu
syHour

Stratum configuration in the RNS during traffic busy
hour. DL PS HSDPA
hed_RB013_CR_Ps_atTrafficBusyHo
ur

hour. DL total PS
AverageNumberOfULBearersEstablis
hed_RB013_CR_HSUPA_atTrafficBu
syHour

hour. UL PS HSUPA
Table 8-61: Properties of View Average_Number_Bearers_BH
8.5.2.1.1.8 Traffic profile during Call session

This section presents different useful views to monitor the downlink traffic profile at Radio Link Setup
(CS, PS & CS+PS), at RAB Attempt (CS & PS), at RAB Setup (CS & PS) and during the call.
Traffic_Profile_at_Radio_Link_Setup
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 193/275

This view presents the number of CS radio links established per cell per traffic class, the number of
PS radio links established per cell per transport channel and the number of multi-RAB CS+PS radio
links
established
per
cell.
It
is
a
direct
translation
of
basic
indicator
VS_RadioLinkEstablishedPerCellxxx.
Besides the indication of the number of CS and PS radio links established per cell, this view gives the
ratio of multi-RAB CS+PS calls.
Figure 8-67: Display of View Traffic_Profile_at_Radio_Link_Setup (Graphical/Tabular)
Name
Traffic profile in terms of CS, PS and multi RAB (CS+PS) radio
Description
links at RNC/CELL level.
Graph
Families
DETAILED MONITORING
TRAFFIC
RADIO LINK SETUP
RNC/CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 194/275

VS_RadioLinkEstablishedPerCell_CsSp
eech_Cum
VS_RadioLinkEstablishedPerCell_CsD
ata_Cum
VS_RadioLinkEstablishedPerCell_CsSt
r_Cum
VS_RadioLinkEstablishedPerCell_PsDc
hDlDchUl_Cum
VS_RadioLinkEstablishedPerCell_PsHs
dpaDlEdchUl_Cum
VS_RadioLinkEstablishedPerCell_PsHs
dpaDchUl_Cum
CumulatedRadioLinksEstablished_RL0
50_CR_MultiRabCsPs
Average of the number of radio links established

per cell for CsSpeech, based on time average over
collection period.
per cell for CsData, based on time average over
collection period.
per cell for CsStreaming, based on time average
over collection period.
per cell for PS DCH DL / DCH UL, based on time
average over collection period.
per cell for PS HSDPA DL / E-DCH UL, based on
time average over collection period.
per cell for PS HSDPA DL / DCH UL, based on
time average over collection period.
Cumulative number of radio link established per
cell - Multi RAB Cs+Ps.
Table 8-62: Properties of View Traffic_Profile_at_Radio_Link_Setup
This view presents the profile of CS and PS services for which a procedure of RB establishment has
been attempted. The number of RB establishment attempt per services being monitored are the
CS_Speech, CS_Video, CS_Str and PS_Interactive, PS Background and PS Streaming for Low/High
rates.
Figure 8-68: Display of View Traffic_Profile_at_RAB_Attempt (Graphical/Tabular)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 195/275

Name
Number of RB establishment attempts per traffic class at

Description
RNC/Cell level.
Graph
Families
DETAILED MONITORING
TRAFFIC
RAB ATTEMPT
RNC/CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RAB_AttEstab_CS_SpeechConv
RAB_AttEstab_CS_Conv64
RAB_AttEstab_CS_Strm
RAB_AttEstab_PS_LowRateIntact
RAB_AttEstab_PS_LowRateBgrd
RAB_AttEstab_PS_LowRateStrm
RAB_AttEstab_PS_HighRateIntact
RAB_AttEstab_PS_HighRateBgrd
RAB_AttEstab_PS_HighRateStrm
Number of RB establishment attempts CS

Speech at Rnc/Cell Level
Number of RB establishment attempts CS video
at Rnc Level
Number of RB establishment attempts CS
Streaming at Rnc/Cell Level
Number of RB establishment attempts PS
Interactive (less than 384 kbps) at Rnc/Cell Level
Background (less than 384 kbps) at Rnc/Cell Level
Streaming (less than 384 kbps) at Rnc/Cell Level
Interactive (greater/equal 384 kbps) at Rnc/Cell
Level
Background (greater/equal 384 kbps) at Rnc/Cell
Level
Streaming (greater/equal 384 kbps) at Rnc/Cell
Level
Table 8-63: Properties of View Traffic_Profile_at_RAB_Attempt
This view presents the profile of services for which a procedure of RB setup has been concluded with
success. The number of RB setup with success per services being monitored are the CS (video,
streaming and voice), the DL_PS_128K, the DL_PS_384K, the DL_PS_64K, the DL_PS_HSDPA and
the UL_PS_HSUPA.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 196/275
Figure 8-69: Display of View Traffic_Profile_at_RB_Setup (Graphical/Tabular)
Name
Number of RB setup success per QoS service class at

Description
RNC level.
Graph
Families
DETAILED MONITORING
TRAFFIC
RB SETUP
RNC/CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RadioBearerSetupSuccess_RB011_R_
Cs(URB011_R_Cs)(Event)
Number of RB setup success - CS at Rnc Level
DL128(URB011_R_DL128)(Event)
Number of RB setup success - DL BitRate 128 at

Rnc Level

Rnc Level

Rnc Level
HSDPA(URB011_R_HSDPA)(Event)
Number of RB setup success DL PS HSDPA Rnc Level
HSUPA(URB011_R_HSUPA)(Event)
Number of RB setup success UL PS HSUPA- at

Rnc Level
Table 8-64: Properties of View Traffic_Profile_at_RB_Setup
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 197/275
This view presents the profile of DL user services occupying the network resources. It is a direct
translation of a basic indicator U1666 - VS.DlAsConfIdAvgNbrEstablished which is sampled each 100
ms interval adding up the number of RB established. This view is important in order to know the
reporting frequency of each RBs. It reports the following DLUserservices; CS_Voice, DL_PS_128K,
DL_PS_384K, DL_PS_64K, DL_PS_32K, DL_PS_HSDPA, DL_signalling and Cell_FACH state.
Figure 8-70: Display of View Traffic_Profile_During_Call (Graphical/Tabular)
Name
Number of DlAsConfIds established per traffic class at RNC
Description
level.
Graph
Families
DETAILED MONITORING
TRAFFIC
RAB TRAFFIC
RNC/CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 198/275

VS_DlAsConfIdAvgNbrEstablished_DlA
sCnfCsSpeechNbLrAmr_Cum(U1666_2
_Cum)(Event), Also DLPS32,DLPS64,
DLPS128,DLPS384, Cell Fach,
Siganling and HSDPA
Average of the number of DlAsConfIds established

per iRNC, based on time average over collection
period.
Table 8-65: Properties of View Traffic_Profile_During_Call
Traffic_Profile_During_Call_Distr_PS
This view provides basic information of the PS RABs in cell DCH per traffic class and split up per
transport channel format (UL/DL). Since it includes data for background, interactive and streaming, it
is possible to have an indication on the main service in terms RABs in cell DCH as well as which
fraction corresponds to DCH/DCH, DCH/HSDSCH, and EDCH/HSDSCH.
Figure 8-71: Display of View Traffic_Profile_During_Call_Distr_PS (Graphical/Tabular)
Name
Number of PS RABs in cell DCH per traffic class split up per
Description
transport channel at RNC/CELL level.
Graph
Families
DETAILED MONITORING
TRAFFIC
RAB TRAFFIC
RNC/CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 199/275

RNC
OZ_RNC
NETWORK
Indicators
VS_RAB_MeanCellDCH_PS_Intact_DC
H_DCH_Cum
VS_RAB_MeanCellDCH_PS_Intact_DC
H_HSDSCH_Cum
VS_RAB_MeanCellDCH_PS_Intact_ED
CH_HSDSCH_Cum
VS_RAB_MeanCellDCH_PS_Bgrd_DC
H_DCH_Cum
VS_RAB_MeanCellDCH_PS_Bgrd_DC
H_HSDSCH_Cum
VS_RAB_MeanCellDCH_PS_Bgrd_ED
CH_HSDSCH_Cum
VS_RAB_MeanCellDCH_PS_Strm_DC
H_DCH_Cum
VS_RAB_MeanCellDCH_PS_Strm_DC
H_HSDSCH_Cum
Mean number of PS RABs in cell DCH per traffic

class (Interactive) split up per transport channel
format (DCH in UL, DCH in DL).
format (DCH in UL, HSDSCH in DL).
format (EDCH in UL, HSDSCH in DL).
class (Background) split up per transport channel
format (EDCH in UL, HSDSCH in DL).
Table 8-66: Properties of View Traffic_Profile_During_Call_Distr_PS
8.5.2.1.2 Global traffic views Cell

The following views described have the goal of providing a global view on the traffic evolution at Cell
Level.
8.5.2.1.2.1 Downlink traffic per QoS class

This section presents different useful views to monitor the downlink traffic per QoS service class.
Traffic_Dl_Cell
This view provides basic information on the traffic transmitted on the downlink for a cell, measured in
terms of Kbytes of the payload for the transmitted RLC SDUs. Since it includes data for CS and PS, it
is possible to have an indication on the main service in terms of carried traffic. The information
Example:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 200/275

The figure below displays the Traffic_Dl_Cell view for a given cell of Network_A, during a given
period of time. After a brief analysis it is clear that the main service in terms of carried traffic is PS. In
order to check how the DL traffic is distributed between the different PS services, the display of the
Traffic_Dl_PS_Distr_Cell view is required.
Figure 8-72: Display of View Traffic_Dl_Cell (Graphical/Tabular)
Name
Traffic_Dl_Cell
Description
Overview of DL RLC payload traffic at cell level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
C_CsVoice
C_CsVideo
C_Ps

downlink on dedicated channels, on each cell of the
active set, for voice calls. Presented on primary axis.
active set, for video calls. Presented on primary axis.
active set, for PS calls. Presented on primary axis.
Table 8-67: Properties of View Traffic_Dl_Cell
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 201/275

indication of how the PS DL traffic is distributed between PS64, PS128, PS384 and HSDPA services.
This view provides basic information on the traffic transmitted on the downlink for a cell, measured in
terms of Kbytes of the payload for the transmitted RLC SDUs for PS services. With this view it is
possible to have an indication on which fraction of PS traffic is related to PS64, PS128, PS384 and
HSDPA. The information obtained should be complemented by the results retrieved from other traffic
views included in the Detailed Monitoring section.
Figure 8-73: Display of View Traffic_Dl_PS_Distr_Cell (Graphical/Tabular)
Name
Overview of DL RLC payload traffic PS distribution at cell
level.
Graph
Description
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
C_PS64

active set, for PS 64 calls. Presented on primary axis.
C_PS128

UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 202/275

active set, for PS 128 calls. Presented on primary
axis.
C_PS384

active set, for PS 384 calls. Presented on primary
axis.
C_HSDPA

active set, for HSDPA calls. Presented on primary
axis.
Table 8-68: Properties of View Traffic_Dl_PS_Distr_Cell
8.5.2.1.2.2 Downlink traffic per QoS class when cell is reference vs. in the active set
Please find the description on section 8.5.2.1.1.3.
8.5.2.1.2.3 Uplink traffic per QoS class

This section presents different useful views to monitor the uplink traffic per QoS service class.
Traffic_Ul_Cell
This view provides basic information on the traffic received on the uplink for a cell, measured in terms
of Kbytes of the payload for the received RLC SDUs. Since it includes data for CS and PS, it is
possible to have an indication on the main service in terms of carried traffic. The information obtained
Monitoring section.
Example:
The figure below displays the Traffic_Ul_Cell view for a given cell of Network_A, during a given
period of time. After a brief analysis it is clear that the main service in terms of carried traffic is PS. In
order to check how the UL traffic is distributed between the different PS services, the display of the
Traffic_Ul_ PS_Distr_Cell view is required.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 203/275

Figure 8-74 : Display of View Traffic_Ul_Cell (Graphical/Tabular)
Name
Traffic_Ul_Cell
Description
Overview of UL RLC payload traffic at cell level.
Graph
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
C_CsVoice
C_CsVideo
C_Ps

for voice calls. Presented on primary axis.
for video calls. Presented on primary axis.
for PS calls. Presented on primary axis.
Table 8-69: Properties of View Cell_Ul_Traffic_Overview

indication of how the PS UL traffic is distributed between PS64, PS128, PS384 and HSUPA services.
This view provides basic information on the traffic received on the uplink for a cell, measured in terms
of Kbytes of the payload for the received RLC SDUs for PS services. With this view it is possible to
have an indication on which fraction of PS traffic is related to PS64, PS128, PS384 and HSUPA. The
information obtained should be complemented by the results retrieved from other traffic views included
in the Detailed Monitoring section.
Example:
The figure below displays the Traffic_Dl_PS_Distr_Cell view for a given cell of Network_A, during a
given period of time. This view shows that HSUPA represents the main service regarding carried
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 204/275

traffic. It is also visible that PS64 and PS128 services present a lower usage when comparing with
PS384 or HSUPA.
Figure 8-75 : Display of View Traffic_Ul_PS_Distr_Cell (Graphical/Tabular)
Name
Overview of UL RLC payload traffic PS distribution at Cell
level.
Graph
Description
Families
DETAILED MONITORING
TRAFFIC
GLOBAL
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
C_PS64

on dedicated channels, on each cell of the active set,
for PS 64 calls. Presented on primary axis.
C_PS128

C_PS384

C_HSUPA

for HSUPA calls. Presented on primary axis.
Table 8-70: Properties of View Traffic_Ul_PS_Distr_Cell
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 205/275

8.5.2.1.2.4 Radio Bearer usage per QoS class
This section presents a useful view to monitor the Radio Bearer usage per QoS service class
This view provides the main indicators with the average information related with the RB usage
comparing different services. It is equivalent to the view presented on section 8.5.2.1.1.7.
Basically this view indicates the channel occupancy at traffic busy-hour for PS indicators of the view
Average_Number_Bearers. It is equivalent to the view presented on section 8.5.2.1.1.7.
8.5.2.1.2.5 Traffic profile during Call session

This section presents different useful views to monitor the downlink traffic profile at Radio Link Setup
(CS, PS & CS+PS), at RAB Attempt (CS & PS), at RAB Setup (CS & PS) and during the call.
This view presents the number of CS radio links established per cell per traffic class, the number of
PS radio links established per cell per transport channel and the number of multi-RAB CS+PS radio
links established per cell. It is equivalent to the view presented on section 8.5.2.1.1.8.
This view presents the profile of CS and PS services for which a procedure of RB establishment has
been attempted. It is equivalent to the view presented on section 8.5.2.1.1.8.
Traffic_Profile_at_RAB_Setup_Cell
This view presents the profile of services for which a procedure of RB setup has been concluded with
Success. It is equivalent to the view presented on section 8.5.2.1.1.8, although the indicators used
on this view are the correspondent ones to Cell view.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 206/275
Figure 8-76 : Display of View Traffic_Profile_at_RAB_Setup_Cell (Graphical/Tabular)
Traffic_Profile_at_Call_Setup_Cell
Name
Number of RB setup success per QoS traffic class at

Description
Cell level.
Graph
Families
DASHBOARD
TRAFFIC
CELL
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
RadioBearerSetupSuccess_RB011_C_
Cs(URB011_C_Cs)(Event)
Number of RB setup success CS at Cell Level
DL384(URB011_C_DL384)(Event)
Number of RB setup success DL BitRate 384 at

Cell Level
HSDPA(URB011_C_HSDPA)(Event)
Number of RB setup success DL PS HSDPA

at Cell Level
HSUPA(URB011_C_HSUPA)(Event)
Number of RB setup success UL PS HSUPA

at Cell Level
Table 8-71: Properties of View Traffic_Profile_at_RAB_Setup_Cell
This view presents the profile of DL user services occupying the network resources. It is equivalent to
the view presented on section 8.5.2.1.1.8.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 207/275

This view provides basic information of the PS RABs in cell DCH per traffic class and split up per
transport channel format (UL/DL). It is equivalent to the view presented on section 8.5.2.1.1.8.
8.5.2.2
CS and PS traffic monitoring
8.5.2.2.1 CS & PS Traffic views

These views available for detailed monitoring are listed in the table below. They are also available at
cell level and were already proposed in one view at Global Subfamily. The main goal of have them
repeated here is to observe individually the CS and PS occupancy in detail.
Traffic Subfamily
CS
View name
Cumulated_Number_Bea
rers_Cs
PS
Cumulated_Number_Bea
rers_Ps
Indicators
CumulatedNumberOfDLBearersEstablished_RB021
_CR_CsVideo(URB021_CR_CsVideo)(Event)
_CR_CsVoice(URB021_CR_CsVoice)(Event)
_CR_Ps(URB021_CR_Ps)(Event)
_CR_HSDPA(URB021_CR_HSDPA)(Event)
Table 8-72: Main detailed monitoring traffic views CS& PS (RNC & Cell level)
8.5.2.3
HSDPA traffic monitoring
These views available for plitdetailed monitoring are listed in the tables below. Most of them are also
available at cell level.
Hsdpa_Call_Profile
This View includes the average call duration measured in different ways for RNC and cell level (for cell
level it is considered as well the mobility calls) comparing it with the Activity factor of HSPDA calls
considering the usage of tti. These indicators combined can provide us a figure of HSDPA usage and
allow to monitor changing of profiles on the network due to migrations, parameter tuning or other
external traffic patterns modification.
View Name
Hsdpa_Call_Profile
Level
Cell
Cell
RNC
RNC
Indicators
HSDPAActivityRate_HSDPA027_CR(UHSDPA027_CR)(%)
HSDPAMeanCallDurationInSec_HSDPA040_C(UHSDPA040_C)(s)
MeanCallDuration_RAB021_R_HSDPA(URAB021_R_HSDPA)(s)
HSDPAActivityRate_HSDPA027_CR(UHSDPA027_CR)(%)
Table 8-73: Main detailed monitoring traffic views Hsdpa_Call_Profile (RNC & Cell level)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 208/275
Figure 8-77: Main detailed monitoring traffic views Hsdpa_Call_Profile (per cell)
Hsdpa_Other
This View includes the traffic volume observed at RLC level in Kbytes for HSDPA transport channel
type and provides also the ratio of HSDPA activity compared to overall PS traffic. Note that this is
more accurate than calculating only the ratio between AsConfIdAvgNbrEstablished as it is considering
the time that were really used with data transfer (ActivityTime). This view is important to compare the
real activity of HSDPA RBs in terms of traffic transported vs the RLC activity, and it becomes
mandatory to monitor in cases of optimizations of parameter tuning of resources or monitoring of traffic
profiles change.
View Name
Hsdpa_Other
Level
RNC
RNC
Indicators
TrafficDLSDUPayloadInKbytes_Traffic015_R_HSDPA(UTraffic015_R_
HSDPA)(kbyte)
HSDPATrafficPenetration_HSDPA051_CR(UHSDPA051_CR)(%)
Table 8-74: Main detailed monitoring traffic views Hsdpa_Other (RNC)
Figure 8-78: Main detailed monitoring traffic views Hsdpa_Other (RNC)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 209/275

Hsdpa_Traffic_1; Hsdpa_Traffic_2 & Hsdpa_Traffic_3
The following views provide several approaches on the calculation of Throughput allowing different
perspectives of this metric ate an RNC or cell level but also considering RB usage or traffic activity
approach. Also detail on HSDPA Erlangs and the cumulative Established RB Bearer. The throughput
per Cell or Overall RNC is always an important metric on any detail analysis as it measures the speed
of carrying traffic on a certain NE.
View Name
Hsdpa_Traffic_1
Level
Cell
Cell/RN
C
RNC
Indicators
TrafficDLThroughputInKbps_Traffic028_C_HSDPA(UTraffic028_C_HS
DPA)(nb)
TrafficDLActiveThroughputInKbps_Traffic030_CR_HSDPA(UTraffic030
_CR_HSDPA)(kbit/s)
TrafficDLThroughputInKbps_Traffic024_R_HSDPA(UTraffic024_R_HS
DPA)(nb)
Cell/RN
C
CumulatedNumberOfDLBearersEstablished_RB021_CR_HSDPA(URB
021_CR_HSDPA)(Event)
Cell/RN
C
AverageNumberOfDLBearersEstablished_RB013_CR_HSDPA(URB01
3_CR_HSDPA)(nb)
Hsdpa_Traffic_2
Hsdpa_Traffic_3
Table 8-75: Main detailed monitoring traffic views Hsdpa_Traffic 1,2 & 3(RNC & Cell level)
8.5.2.4
HSUPA traffic monitoring views
The following Views of HSUPA are similar to what was presented before for HSDPA. The Views
include the average call duration measured in different ways for RNC and cell level. These views
combined can provide figures of EDCH usage and allow to monitor changing of profiles on the network
due to migrations, parameter tuning or other external traffic patterns modification.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 210/275

View Name
Level
Hsupa_CallDuration RNC
_Rnc
RNC
RNC
Hsupa_CellTput_No RNC/Cell
deBcounters
RNC/Cell
RNC/Cell
Hsupa_CellTput_R
NCcounters
Hsupa_NbActiveUE
s
Hsupa_NbRBs
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
Hsupa_Penetration
Factor
RNC/Cell
RNC/Cell
RNC/Cell
Hsupa_TrafficVolum RNC/Cell
e
RNC/Cell
Hsupa_UserActivity
Factor -
Hsupa_UserTput_N
odeBcounters
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
RNC/Cell
Indicators
VS_UlAsConfIdAvgNbrEstablished_UlAsCnfHsupa_Cum(U1667_16_
Cum)(Event)
RadioBearerSetupSuccess_RB011_R_HSUPA(URB011_R_HSUPA)(
Event)
MeanCallDuration_RAB021_R_HSUPA(URAB021_R_HSUPA)(s)
VS_eDCHdataBitSentToRNC_Cum(U10902_Cum)(Kbit)
VS_eDCHdataBitRec_NbEvt(U10904_NbEvt)(Event)
E_DCHMAC_dCellThroughput_HSUPA015_CR(UHSUPA015_CR)(k
bit/s)
VS_eDCHdataBitRec_Cum(U10904_Cum)(Kbit)
VS_eDCHdataBitRec_Max(U10904_Max)(Kbit)
VS_DedicatedUplinkKbytesRlcReferenceCell_UlRabHsupa(U1555_1
4)(Kbytes)
VS_DedicatedUplinkActivityRlcRefCell_UlRabHsupa(U1567_14)(ms)
EdchActiveCellThpt_HSUPA022_CR(UHSUPA022_CR)(kbit/s)
VS_eDCHactiveUsers_10ms_users_Min(U10905_2_Min)(users)
VS_eDCHactiveUsers_10ms_users_Avg(U10905_2_Avg)(users)
VS_eDCHactiveUsers_10ms_users_Max(U10905_2_Max)(users)
VS_eDCHactiveUsers_2ms_users_Min(U10905_1_Min)(users)
VS_eDCHactiveUsers_2ms_users_Avg(U10905_1_Avg)(users)
VS_eDCHactiveUsers_2ms_users_Max(U10905_1_Max)(users)
VS_UlAsConfIdAvgNbrEstablished_UlAsCnfHsupa_Min(U1667_16_M
in)(Event)
VS_UlAsConfIdAvgNbrEstablished_UlAsCnfHsupa_Max(U1667_16_
Max)(Event)
Cum)(Event)
RABActivityTimeUL_Traffic034_CR_Ps(UTraffic034_CR_Ps)(ms)
EDCHPenetrationFactor_HSUPA011_CR(UHSUPA011_CR)(%)
VS_DedicatedUplinkKbytesRlcReferenceCell_UlRabHsupa(U1555_1
4)(Kbytes)
VS_DedicatedUplinkKbytesRlcActiveCells_UlRabHsupa(U1553_14)(
Kbytes)
eDCHActiveUsers_HSUPA008_CR(UHSUPA008_CR)(nb)
Cum)(Event)
EDCHActivityFactor_HSUPA010_CR(UHSUPA010_CR)(%)
VS_eDCHactiveUsers_10ms_users_Cum(U10905_2_Cum)(users)
VS_eDCHactiveUsers_2ms_users_Cum(U10905_1_Cum)(users)
VS_eDCHdataBitSentToRNC_Cum(U10902_Cum)(Kbit)
AvgULThroughputPerUser_HSUPA009_CR(UHSUPA009_CR)(nb)
Table 8-76: Main detailed monitoring traffic views Hsdpa_Call_Profile (RNC & Cell level)
Below two graph views are presented as example of detail traffic monitoring for HSUPA
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 211/275
Figure 8-79: Main detailed monitoring traffic Hsupa_PenetrationFactor (per RNC/cell)
Figure 8-80: Main detailed monitoring traffic Hsupa_CellTput_RNCcounters (per RNC/cell)
8.5.3
Traffic troubleshooting
The troubleshooting report, named Troubleshooting_Throughput in last version of UA06 traffic

troubleshooting report dictionary, can be also used for DL R99 PS traffic analysis in downlink even if
this report is focus mainly on HSDPA throughput.
Following the Detail Monitoring analysis if DL PS traffic degradation has been noted, this
troubleshooting report will help to find the root cause.
Some keys indicators will be analyzed:
Mean Call Duration (for HSDPA, HSUPA, PS R99)
Average Number of DL Bearer established
Average Number of UL Bearer established
Traffic DL SDU Payload In Kbytes
Traffic UL SDU Payload In Kbytes
Example of traffic issue:

After an upgrade to UA06 the Average Number of DL Bearer established and the Traffic DL SDU
Payload in Kbytes indicators were analysed. This analysis has shown that there was a considerable
decrease on downlink RLC payload on dedicated channels for PS64 and this reduction was not in line
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 212/275

with the average number of PS64 DL radio bearers established, which even shows an increase after
the upgrade. So, an investigation to derive the causes for this behaviour was started.
Figure 8-81: Average Number of DL Bearers vs. Traffic DL SDU Payload
The Traffic troubleshooting report will manage throughput issue at Cell level and at RNC level.
As the version of UA07 is still not available, the last version of UA06 troubleshooting report dictionary
is available on livelink at the following location:
The Proposed Troubleshooting methodology for UA7.1 is already available at:
8.6.
LOAD AND CAPACITY MONITORING AND

TROUBLESHOOTING
At the beginning, the UMTS networks were deployed focusing on service availability, at the expense of
capacity. With constantly growing traffic due to increased customer base and new services, some
operators start experiencing congestion in their network, leading to blocking of calls and degraded
performance.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 213/275
Traffic split - Manhattan 4 - Erlangs

3500
3000
Nb of Erlangs per day
2500
2000
1500
1000
500
Erlangs Speech per RNC
3/30/2010
3/27/2010
3/24/2010
3/21/2010
3/18/2010
3/15/2010
3/9/2010
3/12/2010
3/6/2010
3/3/2010
2/28/2010
2/25/2010
2/22/2010
2/19/2010
2/16/2010
2/13/2010
2/7/2010
Erlangs HSDPA per RNC
2/10/2010
2/4/2010
2/1/2010
1/29/2010
1/26/2010
1/23/2010
1/20/2010
1/17/2010
1/13/2010
1/10/2010
1/7/2010
1/4/2010
1/1/2010
Erlangs Signalling per RNC
Figure 8. 1 Traffic Evolution in Manhattan RNC During First Quarter of 2010
The objective of the load and capacity monitoring views is to evaluate radio and HW resources
consumption of the network and to detect any blocking issue on the network due to any capacity
related limitations. This chapter gives main guidelines to have an overview of the load and capacity of
a network as well as a list of available detailed monitoring views.
Load and Capacity can be monitored daily to have an overview of the evolution over several weeks or
hourly during a few days or only at busy hours.
The capacity troubleshooting on affected resources can be done based on load and blocking
counters/indicators. Details on capacity analysis are given in [R1] UMTS RF Troubleshooting
Guidelines available on livelink at the following location (https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=50739383&objAction=browse&sort=name&viewType=1)
8.6.1
Global Monitoring for Resource Usage
The (reactive) methodology for capacity analysis is mainly based on the following steps:
Bottleneck identification (which resources are lacking);
Detection and characterization (affected network elements, period of day, events and
operations);
Resolution by parameter tuning and/or resource addition.
The load and capacity analysis should be well coordinated with accessibility investigation, as blocking
situations usually trigger call establishment failures. It is a fact that CAC failures leading to blocking
dont affect only the call admission phase (measured by accessibility) they can also affect other
procedures like radio bearer reconfiguration and mobility but in most cases when call admission
blocking is solved, the congestion in other stages of the call will also be minimized as the same
bottlenecks will be involved.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 214/275

The most relevant monitoring to be done at UTRAN resources level encompasses the following areas:
BTS Channel Elements usage
Iub interface occupancy
DL power usage
OVSF codes utilization
RNC CPU utilization
UL load and RSSI
The DL and UL traffic volume can also provide an indication on the network load as well as the
detailed monitoring of RAB establishment procedure and the analysis of main failure causes of Radio
Bearer setup, Radio Link reconfiguration, setup or addition procedures (see views described in section
8.2.2.3.1).
Analysing the UTRAN bottlenecks for capacity reasons involves looking at two main areas: blocking
and load. Blocking of resources is done through the screenings of counter
VS.RadioBearerEstablishmentUnsuccess, although for BTS specific resources additional Node B
counters should be checked. Specific counters allow performing a detailed evaluation on the load, and
also allow a more preventive analysis.
8.6.1.1
BTS Channel Element Usage
Several levels of monitoring are possible for CEM usage, including the call admission blocking due to
lack of CEM resources, CEM board load (User Plane), CEM/CCM board load (Control Plane) and
CEM load in iRM. The following sections describe the main indicators and views to be used for all
these axis of investigation.
Call Admission Blocking due to Lack of CEM Resources
Call admission failures due to CEM resources shortage can be identified if any of the conditions below,
using cell level indicators is fulfilled for any cell of the Node B:
VS_RadioBearerEstablishmentUnsuccess_NodeBCEMLackofL1Resource > 0
VS_RadioLinkReconfigurationPrepareUnsuccess_NodeBCEMLackL1Rsrc > 0
The second condition is more sensitive as the previous one as it takes into account call
establishments and any type of iRM reconfigurations.
In addition, monitoring of indicators VS_RadioLinkFirstSetupFailure_NodeBCEMLackL1Rsrc (RRC
phase), VS_RadioLinkSetupUnsuccess_NodeBCEMLackL1Rsrc (RRC and SHO procedures) and
VS_RadioLinkAdditionUnsuccess_NodeBCEMLackL1Rsrc (softer handover procedure) may also
be useful for complementing the analysis.
View Cem_Blocking in NPO can be used for this purpose:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 215/275
Figure 8. 2 Display of View Cem_Blocking
Name
Cem_Blocking
Blocking due to CEM resources shortage for radio bearer
establishment and radio link reconfiguration (also includes iRM
reconfigurations, besides call setup).
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
CEM MONITORING
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_RadioBearerEstablishmentUnsuccess_Nod
eBCEMLackofL1Resource (U1629_7)
Number of radio bearer setup not successfully

established, with no
RADIO_BEARER_SETUP_REQUEST sent,
due to lack of CEM resources. Presented on
primary axis.
VS_RadioLinkAdditionUnsuccess_NodeBCEML
ackL1Rsrc (U39_4)
Number of unsuccessful radio link addition due

to lack of CEM resources. Presented on primary
axis.
VS_RadioLinkReconfigurationPrepareUnsucces
s_NodeBCEMLackL1Rsrc (U40_4)
Number of failures radio link reconfiguration

preparation due to lack of CEM resources.
VS_RadioLinkFirstSetupFailure_NodeBCEMLa
ckL1Rsrc (U41_4)
Number of failures of 0 to 1 radio link

establishment for a call due to lack of CEM
resources. Presented on primary axis.
VS_RadioLinkSetupUnsuccess_NodeBCEMLac
kL1Rsrc (U38_4)
Number of unsuccessful radio link setup due to

lack of CEM resources. Presented on primary
axis.
Table 8. 1 Properties of View Cem_Blocking
In addition to these indicators and once the CEM blocking has been detected it is recommended
verifying the behaviour of the following ones:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 216/275

-
VS_CEMAlloc (U10309) will indicate the number of times the allocation of CEM resources
has succeeded and failed, due to no CE available or capacity licensing blocking, for the
procedures of Radio Link Setup and Reconfiguration. This indicator is available per Local Cell
Group.
VS_CEMAllocSuccessUL
(U10311),
VS_CEMAllocSuccessDL
(U10312),
VS_CEMAllocFailedUL
(U10313),
VS_CEMAllocFailedDL
(U10314),
VS_CEMAllocFailedBothUL (U10315) and VS_CEMAllocFailedBothDL (U10316) provide
information about the spreading factor, UL or DL, impacted by blocking. These indicators are
available per Local Cell Group.
New basic indicator in UA7.1, VS_CEMAllocDCH (U10318), which counts the successful and
failed CEM allocations for the DCH part of the call. This indicator is available per cell.
Two NPO views have been defined using the indicators above: Cem_Allocation_LocalCellGroup
and Cem_Allocation_Cell.
Figure 8. 3 Display of View Cem_Allocation_Cell
Name
Cem_Allocation_Cell
Number of times allocation of CEM resources succeeded and
failed (due to no CEM resource available) for the DCH part of
the call.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
CEM MONITORING
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_CEMAllocDCH_AllocSuccessDCH
(U10318_0)
UMT/IRC/INF/012027
07.02 /EN
Number of times allocation of CEM resources

succeeded for DCH. Presented on primary axis.
Preliminary
25/June/2010
Page 217/275

VS_CEMAllocDCH_AllocSuccessHSDPA
(U10318_2)

succeeded for HSDPA. Presented on primary
axis.
VS_CEMAllocDCH_AllocSuccessEDCH
(U10318_4)

succeeded for eDCH. Presented on primary
axis.
VS_CEMAllocDCH_AllocFailDCH (U10318_1)

failed for DCH. Presented on secondary axis.
VS_CEMAllocDCH_AllocFailHSDPA
(U10318_3)

failed for HSDPA. Presented on secondary axis.
VS_CEMAllocDCH_AllocFailEDCH
(U10318_5)

failed for eDCH. Presented on secondary axis.
Table 8. 2 Properties of View Cem_Allocation_Cell
Figure 8. 4 Display of View Cem_Allocation_LocalCellGroup
Name
Cem_Allocation_LocalCellGroup
Monitoring of CEM resources allocation per Local Cell Group
(success and failure) including the analysis per UL/DL
spreading factor.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
CEM MONITORING
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
LOCALCELLGROUP
OZ_LOCALCELLGROPU
NODEB
OZ_NODEB
RNC
OZ_RNC
NETWORK
Indicators
VS_CEMAlloc_Success (U10309_0)
UMT/IRC/INF/012027
07.02 /EN

succeeded. Presented on primary axis.
Preliminary
25/June/2010
Page 218/275
VS_CEMAlloc_FailSetup (U10309_2)

failed due to lack of resources, during Radio
Link Setup. Presented on primary axis.
VS_CEMAlloc_FailReconf (U10309_3)

failed due to lack of resources, during Radio
Link Reconfiguration. Presented on primary
axis.
VS_CEMAlloc_FailSetupLock (U10309_4)

failed due to lack of resources (Capacity
Licensing), during Radio Link Setup. Presented
on primary axis.
VS_CEMAlloc_FailReconfLock (U10309_5)

failed due to lack of resources (Capacity
Licensing), during Radio Link Reconfiguration.
VS_CEMAllocSuccessUL (U10311) all screenings

succeeded, according to the SF on UL. Not
presented on chart.
VS_CEMAllocSuccessDL (U10312) all screenings

succeeded, according to the SF on DL. Not
presented on chart.
VS_CEMAllocFailedUL (U10313) all screenings

failed due to the Uplink (Downlink allocation
was successful), according to the SF in UL. Not
presented on chart.
VS_CEMAllocFailedDL (U10314) all screenings

failed due to the Downlink (Uplink allocation
was successful), according to the SF in DL. Not
presented on chart.
VS_CEMAllocFailedBothUL (U10315) all screenings

failed due to both Uplink and Downlink,
according to the SF in UL. Not presented on
chart.
VS_CEMAllocFailedBothDL (U10316) all screenings

failed due to both Uplink and Downlink,
according to the SF in DL. Not presented on
chart.
Table 8. 3 Properties of View Cem_Allocation_LocalCellGroup
CEM Board Load (User Plane)

CEM load for DCH traffic is measured by means of basic indicator VS_CEMUsedDCH (U10301). This
basic indicator is associated to a Node B load counter, so the several screenings will provide a
different kind of information:
MIN during low traffic periods it provides information on Common Channels CE

utilization;
AVG defines the average load, which is mainly useful for dimensioning purposes;
MAX allows determining the periods for which specific thresholds were exceeded, that
may lead to call admission blocking.
Note: Computation of VS_CEMUsedDCH and CEM board type
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 219/275

The formula used for computation of VS_CEMUsedDCH depends on the BTS CEM configuration and
the activation of Capacity Licensing:
-
If Capacity Licensing is not active and only iCEM is handling R99 traffic
(r99MaxNumberCeXcem = 0), it represents the percentage of CEM processing capacity used,
based on internal DSP processing usage. It is not linked to CE consumption.
If Capacity Licensing is active or in case of xCEM handling R99 traffic

(r99MaxNumberCeXcem 0), the counter will be based in the CE model (used versus
available channel elements).
View Cem_Load_Dch includes a graphical presentation of the aforementioned screenings.
Figure 8. 5 Display of View Cem_Load_Dch
Name
Cem_Load_Dch
Maximum, minimum and average of the ratio between the
CEM capacity used and the total CEM capacity that was
available at the BTS startup, restricted to DCH.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
CEM MONITORING
NODEB / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
NODEB
OZ_NODEB
RNC
OZ_RNC
NETWORK
Indicators
VS_CEMUsedDCH_Max (U10301_Max)
Maximum of the ratio between the CEM

capacity used and the total CEM capacity that
was available at the BTS startup, restricted to
DCH. Presented in primary axis.
VS_CEMUsedDCH_Avg (U10301_Avg)
Average of the ratio between the CEM capacity

used and the total CEM capacity that was
Presented in primary axis.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 220/275

Minimum of the ratio between the CEM capacity
used and the total CEM capacity that was
Presented in primary axis.
VS_CEMUsedDCH_Min (U10301_Min)
Table 8. 4 Properties of View Cem_Load_Dch
In addition, baseline indicators NumberOfBTSWithCEMUsedAbove60Percent_Board003_R and

PercentageOfBTSWithCEMUsedAbove60Percent_Board004_R are useful to verify if the high
usage of CEM resources is widespread in the RNC or just an issue in a number of Node Bs.
The method above is based on a percentage of usage of CEM resources. Sometimes it may be
interesting working with absolute values, in terms of number of channel elements. For that, basic
indicator VS_LocalCellGroupLoad is used, and view Cem_Usage has been defined using the
several screenings. It is important mentioning that the usage measured by this indicator is also
restricted to DCH.
Figure 8. 6 Display of View Cem_Usage
Name
Cem_Usage
Description
Percentage of Channel Element DCH usage.
Graph
Families
DETAILED MONITORING
LOAD AND CAPACITY
CEM MONITORING
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
LOCALCELLGROUP
OZ_LOCALCELLGROPU
NODEB
OZ_NODEB
RNC
OZ_RNC
NETWORK
Indicators
CEDCHUsage_Board002_B (UBoard002_B)
UMT/IRC/INF/012027
07.02 /EN
Percentage of channel elements usage.

Preliminary
25/June/2010
Page 221/275

VS_LocalCellGroupLoad_FreeDL_Avg
(U10310_2_Avg)
Number of DL channel elements not used for a

local cell group (restricted to DCH). Presented
on primary axis.
VS_LocalCellGroupLoad_FreeUL_Avg
(U10310_0_Avg)
Number of UL channel elements not used for a

on primary axis.
VS_LocalCellGroupLoad_UsedDL_Avg
(U10310_3_Avg)
Number of DL channel elements used for a

on primary axis.
VS_LocalCellGroupLoad_UsedUL_Avg
(U10310_1_Avg)
Number of UL channel elements used for a

on primary axis.
Table 8. 5 Properties of View Cem_Usage
Note: Monitoring of CEM usage for HSxPA

CEM load evaluation for HSDPA (in terms of number of users) can be performed using the following
basic indicators:
-
VS_HsdpaUEsPerHBBU (U10820), for iCEM only, which counts the number of UEs
configured in the HBBU, based on a 5 second sampling rate (setup, deletion or mobility of UE).
VS_HsdpaUEsPerLCG (U10821), for both iCEM and xCEM, which counts the number of UEs
configured in the Local Cell Group, based on a 5 second sampling rate (setup, deletion or
mobility of UE).
For HSUPA, the CEM monitoring, also based on the number of users is performed using the following
basic indicator:
-
VS_eDCHUEsPerLCG (U10921), applicable to both iCEM and xCEM, which works in the
same way as the HSDPA equivalent.
As the Local Cell Group counters are reported per LCG and the xCEM is capable of managing two
LCGs, the sum of these LCGs must be considered to obtain the overall xCEM result.
CEM/CCM board load (Control Plane)
Although User Plane is expected to be the CEM bottleneck (and CEM monitoring is mostly based on
User Plane information) it may also be important to investigate the counters and basic indicators to
evaluate the Control Plane (signalling) load. The CCM load is also included because it handles the
load balancing of CEM resources.
The analysis is based on VS_cpuLoad_CEM and VS_cpuLoad_CCM for which the maximum
should be considered. The BTS control plane was designed with a large capacity margin, so even in
case of high traffic, the values obtained should not normally exceed 20%-25%. These counters are
monitored per board, so in case of iCEM and xCEM mix, the counters will be available for each board
separately.
Monitoring of these indicators is recommended in case of special events (football matches, concerts,
festivals).
View Cem_Ccm_Control_Plane has been created to monitor the maximum instances of these basic
indicators.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 222/275
Figure 8. 7 Display of View Cem_Ccm_Control_Plane
Name
Cem_Ccm_Control_Plane
Description
Percentage of BTS CPU load for CEM and CCM processors.
Graph
Families
DETAILED MONITORING
LOAD AND CAPACITY
CEM MONITORING
BOARD / NODEB
Availability Domain
Hourly
Daily
Weekly
Monthly
BOARD
OZ_BOARD
NODEB
OZ_NODEB
RNC
OZ_RNC
NETWORK
Indicators
VS_cpuLoad_CCM_Max (U10403_CCM_Max)
Percentage of CPU load (Node B CCM

processor). Presented in primary axis.
VS_cpuLoad_CEM_Max (U10403_CEM_Max)
Percentage of CPU load (Node B CEM

processor). Presented in primary axis.
Table 8. 6 Properties of View Cem_Ccm_Control_Plane
8.6.1.2
Iub Interface Occupancy
Several levels of monitoring are possible for Iub occupancy, including the call admission blocking due
to lack of resources and resource load evaluation. The following sections describe the main indicators
and views to be used for these axes of investigation.
Call Admission Blocking due to Lack of Iub Resources

The Iub resources management is done at RNC level on a per Node B basis. The Iub Call Admission
Control mechanism, also named AAL2 CAC takes into consideration services for which EBR is
configured with a non-zero value, meaning that from UA6 onwards it will also consider HSDPA traffic.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 223/275

Call admission blocking due to Iub resources shortage can be detected through basic indicator
VS_RadioBearerEstablishmentUnsuccess (U1629), screenings LackBwIub (lack of Iub reserved
bandwidth) and LackTransportIdIub (lack of CID). If the Iub is well configured, this last condition
should never be a cause for blocking.
Additional indication about call admission blocking and iRM upgrade procedure failures due to lack of
Iub resources is provided by screenings IubLayerCongestion, LackCidOrUdpPortIub and
LackBwthIub but for basic indicator VS_RadioLinkReconfigurationPrepareUnsuccess (U40).
When mobility is affected by the lack of Iub resources, the same screenings of basic indicators
VS_RadioLinkSetupUnsuccess (U38) and VS_RadioLinkAdditionUnsuccess (U39) should be
used, although one must consider that the first one also includes failures during RRC connection
establishment.
View Iub_Blocking includes the indicators mentioned above.
Figure 8. 8 Display of View Iub_Blocking
Name
Iub_Blocking
Blocking due to Iub resources shortage due to radio bearer
establishment and radio link reconfiguration/addition/setup.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
IUB LOAD ATM
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_RadioBearerEstablishmentUnsuccess_Lac
kBwthIub(U1629_13)

due to lack of Iub bandwidth resources.
VS_RadioBearerEstablishmentUnsuccess_Lac
kTransportIdIub(U1629_12)

due to lack of CID on Iub (or Udp Port).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 224/275

VS_RadioLinkAdditionUnsuccess_IubLayerCon
gestion(U39_7)

to Iub layer congestion. Presented on primary
axis.
VS_RadioLinkAdditionUnsuccess_LackBwthIub
(U39_6)

to lack of Iub bandwidth. Presented on primary
axis.
VS_RadioLinkAdditionUnsuccess_LackCidOrU
dpPortIub(U39_5)

to lack of CID on Iub (or Udp Port). Presented
on primary axis.
s_IubLayerCongestion(U40_3)

preparation due to Iub layer congestion.
s_LackBwthIub(U40_6)

preparation due to lack of Iub bandwidth.
s_LackCidOrUdpPortIub(U40_5)

to lack of CID on Iub (or Udp Port). Presented
on primary axis.
VS_RadioLinkFirstSetupFailure_IubLayerCong
estion(U41_3)

establishment for a call due to Iub layer
congestion. Presented on primary axis.
VS_RadioLinkFirstSetupFailure_LackBwthIub(U
41_6)

lack of Iub bandwidth. Presented on primary
axis.
VS_RadioLinkFirstSetupFailure_LackCidOrUdp
PortIub(U41_5)

due to lack of CID on Iub (or Udp Port).
VS_RadioLinkSetupUnsuccess_IubLayerConge
stion(U38_3)

Iub layer congestion. Presented on primary
axis.
VS_RadioLinkSetupUnsuccess_LackBwthIub(U
38_6)

lack of Iub bandwidth. Presented on primary
axis.
VS_RadioLinkSetupUnsuccess_LackCidOrUdp
PortIub(U38_5)

lack of CID on Iub (or Udp Port). Presented on
primary axis.
Table 8. 7 Properties of View Iub_Blocking
Iub Interface Resource Load Evaluation

The Iub load is evaluated at two levels, and both should be considered in order to make a complete
monitoring of the resources and Iub configuration.
RNC level An estimation of the Iub load is based on the number of Radio Bearers and
their preconfigured costs (EBR). The result of this estimation is used for AAL2 CAC.
Node B level The real Iub load is based on the number of ATM cells transferred.
The RNC estimation of the Iub load can be monitored using the several screenings of basic indicator
VS_DistIubLoadAal2If (U1758), which provides information on the time spent within a certain range
of Iub load (AAL2 CAC algorithm view) for a given cell. Only EBR >0 traffic is considered.
Real Iub load can be retrieved from the following basic indicators, which derive from Node B counters:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 225/275

-
VS_PCMATMnbReceivedCell (U10015) counts the number of cells received in a PCM link,

based on a 1 second sampling rate. It counts all R99 and HSDPA cells.
VS_imaGroupNbReceivedCell (U10614) counts the number of cells for an IMA group, based
on a 1 second sampling rate. It counts all R99 and HSDPA cells. This indicator should only be
used in case of IMA.
The correspondence between the number of ATM cells received and Iub load is done by extended
indicators AverageIubLoad_Iub003_B_IMA (or PCM) and MaximumIubLoad_Iub004_B_IMA (or
PCM).
View Iub_Load_Atm includes all the relevant counters for Iub monitoring.
Figure 8. 9 Display of View Iub_load_Atm
Name
Iub_Load_Atm
Description
Iub load monitoring for ATM interfaces.
Graph
Families
DETAILED MONITORING
LOAD AND CAPACITY
IUB LOAD ATM
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
NODEB
OZ_NODEB
RNC
OZ_RNC
NETWORK
Indicators
AverageIubLoad_Iub003_B_IMA
(UIub003_B_IMA)
Average Iub load (number of ATM cells

received per IMA group). Presented on
secondary axis.
AverageIubLoad_Iub003_B_PCM
(UIub003_B_PCM)
Average Iub load (number of ATM cells

received per PCM link). Presented on
secondary axis.
MaximumIubLoad_Iub004_B_IMA
(UIub004_B_IMA)
Maximum Iub load (number of ATM cells

received per IMA group). Presented on
secondary axis.
MaximumIubLoad_Iub004_B_PCM
(UIub004_B_PCM)
Maximum Iub load (number of ATM cells

received per PCM link). Presented on
secondary axis.
VS_PCMATMnbReceivedCell (U10015) all

instances
The number of cells received for the PCM link.

Not presented on chart.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 226/275

VS_imaGroupNbReceivedCell (U10614) all
instances
The number of ATM cells received for the IMA

group. Not presented on chart.
VS_DistIubLoadAal2If_BandWidth0to20
(U1758_0)
Number of seconds per range of IuB load per

bandwidth pool based on real time traffic with
granularity of 10 second (0% to 20%).
(U1758_1)

(U1758_2)

(U1758_3)

(U1758_4)

Table 8. 8 Properties of View Iub_Load_Atm
Load Monitoring Threshold Recommendations

Load monitoring should be done for the busy hour.
For the Iub load estimated by the RNC, the monitoring is mostly done on screenings
BandWidth60to80 (Iub load estimated by the RNC is between 60% and 80%) and
BandWidth80to100 (Iub load estimated by the RNC is higher than 80%) for the busy hour. Since
U1758 is based on a cell counter, the same values should be observed for all cells served by the
same Iub.
Normally, it is desired having an Iub load used for AAL2 CAC below 80%, which can be translated into
VS_DistIubLoadAal2If_BandWidth80to100 = 0. This threshold could be re-evaluated to lower values
if conservative EBR settings are use and high bit rates are used for call admission.
Iub real load is also recommend not exceeding constantly 90%, for the maximum values, but the most
important is that the real load should be in line with the Iub estimated load. If the EBR configuration is
very conservative, the gap between Iub real load and the RNC estimated Iub load can be important
and the Iub blocking will occur even for low Iub real traffic. This mean EBR parameters tuning would
be needed.
In case the transport configuration does not allow EBR tuning, additional PCM resources should be
added.
8.6.1.3
DL Power Usage
Several levels of monitoring are possible for DL power usage, including the call admission blocking
due to lack of resources and resource load evaluation. The following sections describe the main
indicators and views to be used for these axes of investigation.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 227/275

Call Admission Blocking due to Lack of DL Power Resources
The DL Power management is done by the RNC on a per cell basis. The Call Admission Control (CAC)
mechanism takes into account the DL Power used for R99 and HSDPA traffic (when Fair Sharing of
resources is used).
Even in the case that HSDPA traffic is not considered by CAC based on DL Power (if Fair Sharing is
not used) a high R99 power load can negatively impact the HSDPA performance, namely the
throughput.
Call admission blocking due to DL Power resource shortage can be identified using basic indicator
VS_RadioBearerEstablishmentUnsuccess (U1629), screening UnavailableDlPowerResources.
Additional indication of call admission blocking and unsuccessful procedures for iRM upgrade, mobility
and RRC establishment due to lack of power is provided by screening RrmRefusal of basic indicators
VS_RadioLinkReconfigurationPrepareUnsuccess (U40), VS_RadioLinkSetupUnsuccess (U38)
and VS_RadioLinkAdditionUnsuccess (U39).
However, it is important to take into consideration that this screening also includes the case of lack of
OVSF codes.
View RrmResources_Blocking includes the indicators mentioned above.
Figure 8. 10 Display of View RrmResources_Blocking
Name
Rrm_Resources_Blocking
Blocking due to Rrm resoures (power and OVSF Codes)
shortage for radio bearer establishment and radio link
reconfiguration/addition/setup.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
POWER USAGE
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 228/275
VS_RadioBearerEstablishmentUnsuccess_Una
vailableDlPowerResources (U1629_2)

due to lack of DL Power resources. Presented
on primary axis.
VS_RadioBearerEstablishmentUnsuccess_Una
vailableDlCodeResources (U1629_1)

to lack of DL Code resources. Presented on
primary axis.
VS_RadioLinkAdditionUnsuccess_RrmRefusal
(U39_2)

preparation due to lack of RRM resources (code
and power). Presented on primary axis.
s_RrmRefusal (U40_2)

establishment for a call due to lack of RRM
resources (code and power). Presented on
primary axis.
VS_RadioLinkFirstSetupFailure_RrmRefusal
(U41_2)

lack of RRM resources (code and power).
VS_RadioLinkSetupUnsuccess_RrmRefusal
(U38_2)

due to lack of RRM resources (code and
power). Presented on primary axis.
Table 8. 9 Properties of View RrmResources_Blocking
DL Power Usage Resource Load Evaluation

The power load is mainly monitored by means of indicators defined using Node B counters.
For the total power usage in the cell (R99 and HSDPA, whether Fair Sharing is used or not) basic
indicator VS_RadioTxCarrierPwr (U10205) can be used. The counter on which it is based has two
screenings: Operational (reference power) and Used (power that is really used).
The following baseline indicators are built using this basic indicator:
-
PercentagePowerUsed_Power001_B_Avg (%) is the average power used, when compared

to the maximum total transmitted power per sector and per frequency.
PercentagePowerUsed_Power001_B_Max (%) is the maximum power used, when

compared to the maximum total transmitted power per sector and per frequency.
TotalRadioTxCarrierPwr_Power004_B_Avg (mW) is the maximum total transmitted power

per sector and per frequency, averaged on spatial and temporal domains. It is used as the
denominator in the definition of the two previous indicators.
These indicators can be complemented with the following basic indicators, derived from RNC counters:
VS_IrmcacPowerDist (U306), VS_DistDlTtlPwrRatio (U307) and VS_AvgTxPower (U1002). The
first one is based on the number of seconds per range of power considered by the CAC algorithm for
that cell (HSDPA reserved power is considered, in case of Fair Sharing of resources). U307 and
U1002 are based on NBAP common measurements, and provide the same information but they are
presented differently. U307 is given as a distribution and U1002 as an absolute value in mW (this last
one is based on a load counter, so maximum, minimum and average values are provided).
Specifically for HSDPA, basic indicators VS_HsdpaHSPDSCHTxPwr (U10801) and
VS_HsdpaHSSCCHTxPwr (U10803) can be used for monitoring the power used. These basic
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 229/275

indicators are defined based on Node B load counters and are used in the formula of the following
extended indicators:
-
AverageHSDPAPowerused_HSDPA010_CR (%) is the average HSDPA power used per cell

compared to maxTxPower.
AverageHSDPAPowerused_HSDPA011_CR (%) is the average HSDPA power used during

active TTI compared to maxTxPower.
AverageHSDPAPowerused_HSDPA014_CR (%) is the average HS-DSCH power used

during active TTI compared to maxTxPower.
AverageHSDPAPowerused_HSDPA015_CR (%) is the average HS-SCCH Power used

during active TTI compared to maxTxPower.
Another important indicator (also included in the extended dictionary) for monitoring of power
resources load is AverageNonHSDPAPowerused_HSDPA016_CR, which measures the average
power that is not used by HSDPA in the cell in each TTI.
For power overload monitoring, basic indicator VS_HsdpaPAOverload (U10817) should be used. It
counts the number of 100ms periods for which the total transmission power exceeded 90% of the
maximum cell power.
The views described below use the indicators described above for power monitoring (R99 and/or
HSDPA).
View Total_Power_Usage_NodeB_Counters is used for monitoring of total power usage (R99 and
HSDPA), using Node B counters.
Figure 8. 11 Display of View Total_Power_Usage_NodeB_Counters
Name
Total_Power_Usage_NodeB_Counters
Total power usage in the cell (R99 and HSDPA) based on
Node B counters.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
POWER USAGE
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 230/275

NETWORK
Indicators
PercentagePowerUsed_Power001_B_Avg
(UPower001_B_Avg)
Average power used. Presented on secondary

axis.
PercentagePowerUsed_Power001_B_Max
(UPower001_B_Max)
Maximum power used. Presented on secondary

axis.
TotalRadioTxCarrierPwr_Power004_B_Avg
(UPower004_B_Avg)
Maximum total transmitted power averaged on

spatial and temporal domains. Not presented on
chart.
VS_RadioTxCarrierPwr (U10205) all

screenings and instances
Minimum, maximum and linear average

(software filtered) of total transmitted power per
sector and per frequency at the Tx channelizer.
Not presented on chart.
Table 8. 10 Properties of View Total_Power_Usage_NodeB_Counters
The
power
usage
analysis
using
Total_Power_Usage_Rnc_Counters.
RNC
counters
can
be
done
using
view
Figure 8. 12 Display of View Total_Power_Usage_RNC_Counters
Name
Total_Power_Usage_Rnc_Counters
Total power usage in the cell (R99 and HSDPA) based on
RNC counters.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
POWER USAGE
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_DistDlTtlPwrRatio_PwrRt90To100pc
(U307_4)
UMT/IRC/INF/012027
07.02 /EN
Number of DL TX power ratio P/Pmax samples

received from NBAP common measurement per
cell in the 90%-100% interval. Presented on
primary axis.
Preliminary
25/June/2010
Page 231/275
(U307_3)

primary axis.
(U307_2)

primary axis.
(U307_1)

primary axis.
(U307_0)

primary axis.
VS_AvgTxPower_Avg (U1002_Avg)
Average of Tx Power measurements received

from NBAP measurements. Presented on
secondary axis.
VS_AvgTxPower_Cum (U1002_Cum)
Cumulative value of Tx Power measurements

received from NBAP measurements. Not
presented on chart.
VS_AvgTxPower_Max (U1002_Max)
Maximum of Tx Power measurements received

secondary axis.
VS_AvgTxPower_Min (U1002_Min)
Minimum of Tx Power measurements received

secondary axis.
VS_AvgTxPower_NbEvt (U1002_NbEvt)
Number of measurements for Tx Power

measurements received from NBAP
measurements. Not presented on chart.
Table 8. 11 Properties of View Total_Power_Usage_Rnc_Counters
The power distribution considered

Power_Distribution_Irm_Cac.
by
the
CAC
algorithm
is
presented
in
view
Figure 8. 13 Display of View Power_Distribution_Irm_Cac
Name
Description
Power_Distribution_Irm_Cac
Power distribution based on the number of seconds per range
of power considered by the CAC algorithm (HSDPA reserved
power is considered, in case of Fair Sharing of resources).
Graph
Families
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 232/275

DETAILED MONITORING
LOAD AND CAPACITY
POWER USAGE
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
VS_IrmcacPowerDist_Rng90to100pcTotPwr
(U306_4)
Number of seconds per range of power

considered by the CAC algorithm (90%-100%).
(U306_3)

(U306_2)

(U306_1)

(U306_0)

Table 8. 12 Properties of View Power_Distribution_Irm_Cac
View Average_Hsdpa_Power_Usage_2 is used for monitoring of HSDPA power (HS-DSCH and HSSCCH) and PA overload.
Figure 8. 14 Display of View Average_Hsdpa_Power_Usage_2
Name
Average_Hsdpa_Power_Usage_2
Average HSDPA power used per cell and used during active
TTI (in percentage, compared to maxTxPower).
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
POWER USAGE
CELL / RNC
Availability Domain
Hourly
UMT/IRC/INF/012027
07.02 /EN
Daily
Preliminary
Weekly
25/June/2010
Monthly
Page 233/275

CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
AverageHSDPAPowerused_HSDPA010_CR
(UHSDPA010_CR)
Average HSDPA power used. Presented on

primary axis.
AverageHSDPAPowerused_HSDPA011_CR
(UHSDPA011_CR)
Average HSDPA Power used during active TTI.

VS_HsdpaPAOverload (U10817)
Number of periods for which the total

transmitted power (measurement received from
PMM) exceeded 90% of the maximum cell
power configured (mean power during 100ms).
Table 8. 13 Properties of View Average_Hsdpa_Power_Usage_2
Tabular views Hsdpa_Power and Hsdpa_Power_2 are useful for complementing the analysis on
power usage, as they include a considerable list of indicators.

Load thresholds for power usage should be evaluated at the busy hour and the main outcome is
usually the addition of extra capacity layer on new carrier and PA.
As a general rule, the PA usage for R99 should not exceed 80%, which can be monitored by the
screenings Rng80to90pcTotPwr and Rng90to100pcTotPwr being equal to zero. However, when
considering Fair Sharing of Resources, the HSDPA reserved power will be included, so some flexibility
must be considered for this threshold.
It is desirable having the percentage of time spent in PA overload, due to HSDPA power need, below
20% during the busy hour. This can be calculated by dividing the number of intervals with PA overload
by the number of TTIs used, obviously taking into consideration the TTI duration
(VS_HsdpaPAOverload * 50 / VS_HsdpaTTIsUsed < 20%).
This value is subject to operators strategy. When DL power overload is reached, the HSDPA
scheduler is limited by power, so users wont have the maximum throughput they would expect. So, if
the operator wants to ensure maximum throughput this is an appropriate value, otherwise higher
values can be used. Combined monitoring of PA overload and throughput is recommended for these
cases.
8.6.1.4
OVSF Codes Utilization
Several levels of monitoring are possible for OVSF codes utilization, including the call admission
blocking due to lack of resources and resource load evaluation. The following sections describe the
main indicators and views to be used for these axes of investigation.
Call Admission Blocking due to Lack of OVSF Codes
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 234/275

As in the power case, call admission on OVSF codes is managed by the RNC, for R99 and HSDPA.
Feature Fair Sharing of Resources introduces HSDPA CAC at RNC level for power and codes, so HSPDSCH codes may be reserved for HSDPA users, to guarantee a specific QoS.
Even in the case that HSDPA traffic is not considered by CAC based on OVSF codes (if Fair Sharing
is not used) a high R99 power load can negatively impact the HSDPA performance, namely the
throughput.
Call admission blocking due to OVSF codes resource shortage can be identified using basic indicator
VS_RadioBearerEstablishmentUnsuccess (U1629), screening UnavailableDlCodeResources.
Additional indication of call admission blocking and unsuccessful procedures for iRM upgrade, mobility
and RRC establishment due to lack of codes is provided by screening RrmRefusal of basic indicators
VS_RadioLinkReconfigurationPrepareUnsuccess (U40), VS_RadioLinkSetupUnsuccess (U38)
and VS_RadioLinkAdditionUnsuccess (U39).
However, it is important to take into consideration that this screening also includes the case of lack of
DL Power, as described in the previous section.
View RrmResources_Blocking includes the indicators mentioned above.
OVSF Code Usage Resource Load Evaluation

The code load depends on the strategy used for OVSF codes reservation for HS-PDSCH channels,
which can be static or dynamic (Dynamic Code Tree Management or Fair Sharing).
With DCTM and Fair Sharing disabled, the reservation of the HS-PDSCH codes is static and the
number of HS-PDSCH codes is defined by the parameter numberOfHsPdschCodes. For this case,
the code usage may be monitored using extended indicator CodeLoad_DCTM005_CR, for which the
formula is derived from the weighted number of free codes (not used, reserved or blocked):
When DCTM is enabled (Fair Sharing of resources must be disabled), the reservation of HS-PDSCH
codes is dynamic and depends on the R99 traffic. The codes not used by R99 can be used for HSPDSCH channels, but some codes have to be kept free to anticipate the admission of a R99 call. A
minimum number of HS-PDSCH codes is guaranteed (meaning that they cant be used for R99 traffic).
This is defined by parameter minNumberOfHsPdschCodes, which will define the indicator that
should be used for code load monitoring (the number after CodeLoadMin is in line with this
parameter):
CodeLoadMin1_DCTM006_CR,
CodeLoadMin2_DCTM007_CR
or
CodeLoadMin5_DCTM008_CR. Indicator HspdschCodeUsageEfficiencyforDCTM_DCTM001_C,
specific to DCTM, is also important for monitoring the ratio between the codes used for HSDPA and
the available HS-PDSCH codes.
If Fair Sharing of resources is enabled (DCTM must be disabled), OVSF codes are managed by
NodeB autonomously that is to say that the NodeB knows in real time which codes are used or not
by R99 and then it is able to compute which block of consecutive SF16 codes are available for HSPDSCH. In this case, indicator CodeLoadFairSharing_HSDPA076_CR should be used.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 235/275

Specifically to HSDPA code usage, indicators NumberofHSDSCHcodesusedperTTI_HSDPA013_C
and PartOfRadioResourceShared_HSDPA041_CR are useful to complement the analysis.
Tabular views Hsdpa_Code_Load and Hsdpa_Codes should be used for monitoring the indicators
described above.

The investigation method for OVSF codes usage depends on the strategy used for OVSF codes
reservation for HS-PDSCH channels and, obviously, in the operator policy for code utilization.
This means that the maximum allowed code load will be determined by the acceptable blocking rate
for HS-PDSCH codes (in case of HSDPA) and/or for a specific SF (DL), corresponding to the R99
bearer used by the operator as reference.
8.6.1.5
RNC CPU Utilization
The strategy with TMU CPU utilization is to accept as much load into the processor as possible,
without causing an overload on the CPU. With the generalization of smart-phones in the current
networks, this has become a genuine concern from the operators, as the signalling load tends to
increase visibly.
Processor Load Evaluation and RNC Rejections

RNC capacity may be limited by the processing capacity of the PMC boards, and the type of PMC that
limits the RNC capacity depends on the characteristics of the call profile. This means that all types of
PMC should be monitored. The granularity of the analysis should be one hour, at the maximum
(counters needed for the analysis are available every 15 minutes).
OMU RAB RAB
PC
PC
PC
PC
RAB RAB
RAB
RAB
RAB RAB
RAB RAB
NI
NI
RAB RAB
RAB RAB TMU TMU RAB
PC
PC
OC-3
CP3
CP3
PC
OMU
OC-3
RAB RAB
PC
PC
PC
RAB
PC
PC
RAB RAB RAB RAB RAB
RAB
RAB RAB RAB RAB RAB
RAB
TMU TMU TMU TMU TMU TMU
TMU TMU TMU TMU TMU TMU
PMC PMC RAB
RAB RAB RAB RAB RAB
RAB
RAB RAB
RAB
9 10 11 12 13 14 15
Figure 8. 15 RNC Processors
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 236/275

Depending on the boards, the PMC load should be considered for PMC-M, PMC-NI, PMC-PC and
PMC-RAB. PMC-OMU are dedicated to OAM activity, so their load can be ignored for traffic capacity
analysis.
PMC are associated to Adjunct Processors and the load on each of them can be monitored by basic
indicator VS_ApCpuUtilizationAvg (U20202), which indicates the processor average CPU utilization
calculated using data sampled every 100 milliseconds.
To monitor the RNC rejections in case of overload, the following basic indicators should be used:
-
RRC_FailConnEstab_Overload (U404_6) is incremented when a RRC connection

establishment procedure is not successful.
VS_UnhandledPagingRequestsCs_OverloadControls (U810_4) counts the number of CS

paging request not sent to the I-Node to be broadcasted.
VS_UnhandledPagingRequestsPs_OverloadControls (U811_4) counts the number of PS

paging request not sent to the I-Node to be broadcasted.
VS_OvinCnAccLaDscrd (U1521) counts the messages discarded on PMC-RAB. All

screenings should be used.
VS_OvinNiDscrd_TtlTrshNnPgMsgs (U1522_1) and VS_OvinNiDscrd_TrshPgMsgsDscrd

(U1522_2) count the messages discarded on PMC-NI.
VS_OvinRabRrcConReqDscrd (U1523) counts the messages discarded due to Panic OVLD

on PMC-RAB.
Tabular view Rnc_Overload includes the basic indicators listed above. This is valid only for RNC, and
does not include U20202. For this indicator, results must be gathered at TRANSPORTNODE or AP
level.

The maximum RNC capacity while maintaining an optimal QoS is reached when the average load of
the most loaded PMC type is the maximum as possible and RNC rejections due to overload are kept
at the minimum.
The committed capacity levels for the RNC correspond to specific engineering margins, which are
presented below. This does not mean that above this CPU load value the RNC will enter in overload,
but it corresponds to a margin taken to ensure the RNC will be able to handle some variations
of traffic while keeping a good Quality Of Service (QOS) for the end users.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 237/275

8.6.1.6
UL Load and RSSI
UL RSSI is a fundamental indicator for UL load estimation, and it will affect the system performance,
mainly in terms of accessibility, retainability and Mac-e scheduler performance.
Call Admission Blocking due to High UL Load

Blocking at call establishment due to high UL load may be identified using basic indicator
RRC_FailConnEstab_RSSI (U404_4), which is incremented when the RRC procedure fails after
RACH reception in the RNC, with the reported RTWP above the maximum interference level tolerated.
In addition, basic indicator VS_FailedAdmissionDueToULload (U10213) can be used to account for
the total number of failed UL admission due to excessive load in the cell.
UL Load Evaluation
The following basic indicators should be used when monitoring UL load:
-
VS_CellULload (U10211) is based on a Node B load counter, and has three screenings in
UA7.1- total load (0), eDCH load (1) and non eDCH load (2).
VS_UplinkRssi (U303) is based on a RNC load counter, incremented with the information
received from NBAP common measurements. This indicator does not take into account the
eDCH load and it is calculated based on the RoT, relatively to OMC RTWP reference value
(default value = -106.1dBm).
VS_DistRssi (U1042) is based on a RNC counter, that details the number of NBAP common
measurements for RSSIaccording to their respective ranges.
Note: Screening 1 of counter #10211 provides abnormally low values in UA6. The values are correct
in UA7.1.
Some system indicators have been created using the counters above, which are useful to characterize
the UL RF environment in the network:
-
UplinkCellLoad_ULOAD001_CR (%) is a baseline indicator based on Node B counters

providing the UL cell load in percentage (average, maximum and minimum).
UplinkCellLoadHSUPA_ULOAD006_CR (%) is equivalent to the previous indicator, but it is

applicable to eDCH only.
UplinkRSSI_ULOAD002_CR (mW) is a baseline indicator based on RNC counters, providing

the average, maximum and minimum values for UL RSSI.
UplinkRSSI_ULOAD003_CR (%) is an extended indicator that provides the UL RTWP

distribution.
Views Ul_Rssi, Ul_Cell_Load and Hsupa_UlRtwpDistrib_Nbap are recommended for UL RSSI

monitoring.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 238/275
Figure 8. 16 Display of View Ul_Rssi
Name
Ul_Rssi
Uplink RTWP, including wide-band received power per sector,
per frequency, at the Rx main/diversity channelizer.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
RADIO
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UplinkRSSI_ULOAD002_CR_Avg
(UULOAD002_CR_Avg)
Average UL RTWP in dBm. Presented on

secondary axis.
VS_RadioWBandRxDivPwr_Avg
(U10202_Avg)
UL RTWP measured on the diversity reception

path in mW. Presented on primary axis.
VS_RadioWBandRxMainPwr_Avg
(U10201_Avg)
UL RTWP measured on the main reception

path in mW. Presented on primary axis.
Table 8. 14 Properties of View Ul_Rssi
Figure 8. 17 Display of View Ul_Cell_Load
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 239/275

Name
Ul_Cell_Load
Uplink cell load (total and eDCH) calculated using Node B
counters.
Graph
Description
Families
DETAILED MONITORING
LOAD AND CAPACITY
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UplinkCellLoad_ULOAD001_CR_Avg
(UULOAD001_CR_Avg)
Average uplink cell load in percentage.

UplinkCellLoadHSUPA_ULOAD006_CR_Avg
(UULOAD006_CR_Avg)
HSUPA uplink Cell load in percentage

Table 8. 15 Properties of View Ul_Cell_Load
Figure 8. 18 Display of View Hsupa_UlRtwpDistrib_Nbap
Name
Hsupa_UlRtwpDistrib_Nbap
Description
Distribution of UL RTWP values.
Graph
Families
DETAILED MONITORING
LOAD AND CAPACITY
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 240/275

VS_DistRssi_DistRssiN970LeMeas (U1042_0)
Number of NBAP common measurements for

UL RSSI, according to range (higher than 97dBm). Presented on primary axis.
VS_DistRssi_DistRssiN1000LeMeasLtN970
(U1042_1)

UL RSSI, according to range (between -100
and -97dBm). Presented on primary axis.
(U1042_2)

(U1042_3)

VS_DistRssi_DistRssiMeasLtN1050 (U1042_4)

UL RSSI, according to range (lower than 105dBm). Presented on primary axis.
Table 8. 16 Properties of View Ul_RtwpDistrib_Nbap
Normally, a good correlation may be found between the amount of traffic with the UL RSSI increase,
but a low UL RSSI value may also indicate HW issues. As such, when the minimum value for U303 is
very low (less than -107dBm) it may be important making an investigation on HW. In addition, the
RTWP received in the main and diversity branches should be compared, using extended indicator
DeltaRtwp_ULOAD009_CR_MainVsDiv.
View Hsupa_UlRtwp_NodeBCounter is useful for a graphical display of such difference.
Figure 8. 19 Display of View Hsupa_UlRtwp_NodeBcounters
Name
Hsupa_UlRtwp_NodeBcounters
Description
UL Rssi using Node B counters.
Graph
Families
DETAILED MONITORING
LOAD AND CAPACITY
POWER USAGE
CELL / RNC
Availability Domain
Hourly
Daily
Weekly
Monthly
CELL3G
OZ_CELL3G
RNC
OZ_RNC
NETWORK
Indicators
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 241/275

VS_RadioWBandRxMainPwr_Min
(U10201_Min)
Minimum UL RTWP measured on the main

reception path in mW. Not presented on chart.
VS_RadioWBandRxMainPwr_Avg
(U10201_Avg)
Average UL RTWP measured on the main

reception path in mW. Presented on secondary
axis.
VS_RadioWBandRxMainPwr_Max
(U10201_Max)
Maximum UL RTWP measured on the main

reception path in mW. Presented on primary
axis.
VS_RadioWBandRxDivPwr_Min (U10202_Min)
Minimum UL RTWP measured on the diversity

reception path in mW. Not presented on chart.
VS_RadioWBandRxDivPwr_Avg
(U10202_Avg)
Average UL RTWP measured on the diversity

reception path in mW. Presented on secondary
axis.
VS_RadioWBandRxDivPwr_Max
(U10202_Max)
Maximum UL RTWP measured on the diversity

reception path in mW. Presented on primary
axis.
Table 8. 17 Properties of View Hsupa_UlRtwp_NodeBcounters
8.6.2
Additional Load and Capacity detailed monitoring views
Additional Load and Capacity views available for detailed monitoring at RNC level are listed in the
table below. Most of them are also available at cell level.
Load and Capacity Subfamily
POWER USAGE
POWER USAGE
POWER USAGE
POWER USAGE
TRANSPNODE
TRANSPNODE
TRANSPNODE
NODEB-RNC
NODEB-RNC
RNC
RNC
RNC
RNC
RNC
RNC
View name
Average_Hsdpa_Power_Usage
Hsdpa_Power
Hsdpa_Power_2
Hsdpa_Power_Availability
Hsdpa_Processor_Stat
HSDPA_DL_IUB_CONGESTION_ATM
HSDPA_DL_IUB_CONGESTION_IP
HSDPA_DL_IUB_IMPAIRMENTS_ATM
HSDPA_DL_IUB_IMPAIRMENTS_IP
Hsupa_UlRtwp_NodeBcounters
Hsupa_RotTotal_NodeBcounters
Hsupa_IubBwLimitation_TnlInd
Hsupa_UlRtwp_Nbap
Ul_Cell_Load
Hsupa_EdchDlChannelsPower
Table 8. 18 Main detailed monitoring load and capacity views (RNC level)
8.7.
QUALITY MONITORING AND TROUBLESHOOTING
The objective of quality monitoring is to evaluate the ability of the network to provide a good service
level and to detect any issue that can affect the application or end-users experience.
This chapter gives key metrics to monitor the service offered to the end subscriber as well as a list of
available detailed monitoring quality views.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 242/275

Detailed information on QOS troubleshooting per service can be found also in [R1] UMTS RF
Troubleshooting Guidelines available on livelink at the following location (https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=50739383&objAction=browse&sort=name&viewType=1)
The network quality can be measured by metrics such as :
Latency (absolute delay),
Delay Variation (Jitter),
Throughput/Available Bandwidth,
Loss Rate e.g. Packets, Frames,
BER (Bit Error Rate)/BLER (Block Erasure Rate).
SIR, EcNo
Network availability (by mean of Accessibility & Retainability analysis) is also an other indicator of
network quality but this is covered in other sections
When a degradation of quality has been identified, the next step is to define more precisely
the affected service
the affected network elements or Cell zone (xCEM, iCEM, Frequency1, Frequency2,)
the affected period of time
the events occurred on the network (feature activation, parameters change, )
In case of a quality issue, it could be also useful to check in parallel
8.7.1
RF conditions (see section 8.6 for information on views available to monitor UL and/or DL
radio conditions)
IRM scheduling
Always-on
Quality detailed monitoring views
RNC level available detailed monitoring views listed below are mainly focused on throughput, BLER,
SIR and EcNo metrics for HSDPA and HSUPA services. Most of these views are also available at
Node B level or cell level.
quality Subfamily
HSDPA
HSUPA
UMT/IRC/INF/012027
Family
RNC, CELL
RNC, CELL
RNC, CELL
RNC, CELL
RNC, CELL
RNC, CELL
RNC, CELL
RNC, CELL
RNC, CELL
RNC
07.02 /EN
View name
Hsdpa_Cqi
Hsdpa_Cqi_2
Hsdpa_Throughput
Hsdpa_Throughput_2
Hsdpa_Quality
Hsdpa_Quality_2
Hsdpa_Throughput_Per_Ue_Cat
Hsdpa_Throughput_Per_Ue_Cat_2
Hsdpa_Ecno
Hsupa_MissingUlPduRlc_Rnc
Preliminary
25/June/2010
Page 243/275

RNC
RNC
RNC
RNC
RNC, NodeB
RNC, Cell
RNC, Cell
RNC, Cell
CS_SPEECH
CS_SPEECH
PS_R99
Hsupa_BlerRadio1stTx_RNCcounters
Hsupa_BlerRadioNbRtxDistrib_RNCcounters
Hsupa_BlerRadio_NodeBcounters
Hsupa_throughput
UlSirDistribPerSF_NodeB
Hsupa_BlerRadio1stTx_RNCcounters
Hsupa_BlerRadio_NbrRtxDistrib_RNCcounters
Hsupa_BlerRadio_NodeBcounters
Bler_CS_AMR_NB
Bler_CS_AMR_WB
Bler_PS_R99
Table 8-77: Main detailed monitoring quality views
- Hsdpa_Cqi_2 adds in tabular format the level of UE quality reception from cqi 0 to cqi 30.
- Hsdpa_Quality_2 adds the number of Harq retransmission information for acknowledged transport
blocks (avg, min, max, nbEvt values).
- Hsdpa_Throughput_2 adds the number of data bits scheduled each tti and the number of tti
containing at least one scheduled UE.
- Hsdpa_Throughput_Per_Ue_Cat_2 add the number of transmitted bits per UE category.
The view Bler_CS_AMR_NB mainly includes:
- CsVoiceUplinkBLER_BLER012_CR: Transport Block Error Rate indicator for CS
voice service AMR NB without multirate.
- UplinkBLER_BLER009_CR: Uplink Bler AMR NB including multirate.
- DownlinkBLER_BLER008_CR: Downlink Bler for AMR frames on Iu.
And also the IUB UL BLER indicators for each AMR subrate individually: 4,95 kbps,
5,9 kbps, .
The view Bler_CS_AMR_WB mainly includes:
- DownlinkAMRWBBLER_BLER010_CR: Indicator for Iu Downlink WB AMR BLER.
- UplinkAMRWBBLER_BLER011_R_12_65: Indicator for UL BLER 12,65 kbps rate.
- UplinkAMRWBBLER_BLER011_CR: Indicator for WB IUB UL Bler, includes all
subrates, 12,65 kbps, 8,85 kbps, and 6,60 kbps.
The view Bler_PS_R99 mainly includes:
o PsDataUplinkBler_BLER013_R: PS Data UL Transport Block Error Rate at RNC
level.
o Downlink Bler for main R99 PS Data services.
o Detailed number of bad PDU and total PDU uplink for main PS data services.
8.7.2
Quality troubleshooting
This is no specific quality troubleshooting report but Troubleshooting_Throughput report available in

last version of UA07 troubleshooting report dictionary report covers PS throughput topic and can be
used for PS throughput issue analysis at Cell level and at RNC level.
The last version of UA07 troubleshooting report dictionary is available on livelink at the following
location:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 244/275
8.8.
HSDPA MONITORING AND TROUBLESHOOTING
This aim of this section is to list the views and reports available in NPO dictionaries for the monitoring
of new UA07 HSDPA features. More information on the monitoring of new UA07 HSDPA features can
be found in the corresponding HSDPA UA07 FSM located at https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=55964393&objAction=browse&sort=name&viewType=1
This section does not cover the monitoring of global performance of HSDPA service with accessibility,
mobility, retainability and traffic information. These subjects are covered in the corresponding
monitoring domains.
8.8.1
HSDPA detailed monitoring views/reports

For a complete HSDPA assessment, the following views/reports were created since UA6 and
are constantly being updated in order to work as a helpful support for the elaboration of
detailed HSDPA global analysis:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 245/275
Table 8-78: HSDPA Global Metrics
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 246/275
For a specific HSDPA feature assessment, the following views/reports were created since
UA6 and are constantly being updated in order to work as a helpful support for the elaboration
of detailed HSDPA feature analysis:
Table 8-79: HSDPA Feature Specific Metrics
8.8.2
HSDPA indicators status
The objective of this section is to describe important warnings and restrictions found in some HSDPA
indicators.
8.8.2.1
HSDPA throughput
After the upgrade UA6 > UA7 the HSDPA throughput may increase. This is an issue that was solved
in UA6.0.5.1 with the implementation of a fix (tracked by the AR2314074). If an UA7 upgrade is
performed before the UA6.0.5.1 load, then this reaction can be seen.
Table 8-80: HSDPA throughput behaviour
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 247/275

Another issue observed during the upgrade UA6 >UA7, was the diminution of throughput per UE
category. This issue was tracked by the CRs (94815 / 54354). This is a counter issue. Before UA7,
retransmissions were also counted.
Table 8-81: HSDPA throughput per UE category behaviour
8.8.2.2
HSDPA Codes
The counter related to DCTM codes, when being pegged in networks with FairSharing activated,
doesnt give credible values (during UA6 has negative values and during UA7 the impact is even
worst). This metric must be ignored.
Table 8-82: HSDPA Code Load behaviour
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 248/275

Still concerning code usage, the metric, available codes, may show irregular values. For the case
present in the picture below, FairSharing is already activated before the upgrade UA6 > UA7 and this
indicator doesnt show the correct amount of codes. Only after the upgrade the value is updated and
normalised.
Table 8-83: HSDPA Code Load behaviour
This normalisation has nothing to do with the UA7 release, but with the resets performed during the
upgrade. It seems that in order to obtain the correct values from this counter, a reset is needed.
8.9.
HSUPA MONITORING AND TROUBLESHOOTING
This aim of this section is to list the views and reports available in NPO dictionaries for the monitoring
of UA06 HSUPA features and new UA07 HSUPA features. More information on the monitoring of
UA06 HSUPA features can be found in the corresponding HSUPA UA06 FSM located at
More information on the monitoring of new UA07 HSUPA features can be found in the corresponding
HSUPA UA07 FSM located at
This section covers mainly the monitoring for HSUPA service global performance concerning:
accessibility, mobility, retainability and traffic information. For further details, check also those
monitoring domains.
8.9.1
HSUPA detailed monitoring views/reports

For a complete HSUPA assessment, the following views/reports were created since UA6 and
are constantly being updated in order to work as a helpful support for the elaboration of
detailed HSUPA global analysis:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 249/275
Table 8-84 HSUPA Global Metrics
For a specific HSUPA feature assessment, the following views/reports were created since
UA6 and are constantly being updated in order to work as a helpful support for the elaboration
of detailed HSUPA feature analysis:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 250/275

HSUPA FeatureSpecific Metrics
Family_1
Family_2
Family_3
CELL
HSUPA
SRB ON EDCH
RNC
CELL
Mobility
HSUPA
RNC
View
Hsupa_SrbOnEdch_Attempts
Hsupa_SrbOnEdch_Volume
Hsupa_SrbOnEdch_Attempts
Hsupa_SrbOnEdch_Volume
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellAdd1A1C
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellAdd1J
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellAddAndDel1D
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellDel1B1C
Hsupa_Mobility_EdchMacroDiv_EdchAsu_EdchSetupAndRelease
Hsupa_Mobility_EdchMacroDiv_EdchServingRlDeletion
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellAdd1A1C
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellAdd1J
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellAddAndDel1D
Hsupa_Mobility_EdchMacroDiv_EdchAsu_CellDel1B1C
Hsupa_Mobility_EdchMacroDiv_EdchAsu_EdchSetupAndRelease
Hsupa_Mobility_EdchMacroDiv_EdchServingRlDeletion
Report
Hsupa_SrbOnEdch
Hsupa_SrbOnEdch
Hsupa_SrbOnEdch
Hsupa_SrbOnEdch
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_Mobility
Hsupa_LoadAndCapacity
Hsupa_LoadAndCapacity
Counter
Feature ID
33581
33581
33581
33581
32072
32072
32072
32072
32072
32072
32072
32072
32072
32072
32072
32072
VS_UEStateTransAtt_PCH_CellDCH_EDCH_HSDSCH_#2825
34018
34018
VS_UEStateTransFail_PCH_CellDCH_EDCH_HSDSCH_NoResource_#2827
VS_UEStateTransSucc_PCH_CellDCH_EDCH_HSDSCH_#2826
34018
33367
33367
UE State Transition
Load and Capacity
HSUPA
CELL
RNC
Table 8-85 HSUPA Feature Specific Metrics
8.9.2
HSUPA indicators status
This section gives warnings and restrictions - if any - dealing with HSUPA indicators and HSUPA
counters.
8.9.2.1
HSUPA counters
Restriction: VS_eDCHdataBitRec_NbEvt (#10904_NbEvt) erroneous in load < UA6.0.5.1

The iBTS counter VS_eDCHdataBitRec_NbEvt (#10904_NbEvt) is erroneous (largely underestimated) in the NodeB loads < UA6.0.5.1. It is corrected from the load UA6.0.5.1 onwards.
UA6 UA7 Delta: VS_eDCHdataBitRec_NbEvt modification

VS_eDCHdataBitRec_NbEvt (#10904_NbEvt) gives the Number of MACe TTIs with data received.
It is wrong in loads prior to 6.0.5.1, it is correct from load 6.0.5.1 onwards. All the indicators using
this counter show a significant change when moving from a load not containing the correction to a
load containing the correction.
The impacted indicators are :
eDCHCommonDLPower_HSUPA007_CR,
E_DCHActiveTti_HSUPA026_CR,
E_DCHMAC_dCellThroughput_HSUPA015_CR.
8.9.2.2
HSUPA retainability
The HSUPA Call Drop indicators have evolved from one UTRAN release to the other. The table below
illustrates the differences between releases.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 251/275

HSUPA Call Drop Indicators
Release
UA05
UA06
and
UA07
Name
Definition
UHSUPA014_CR
Number of HSUPA Radio drops per

minute of calls
UHSUPA014_CR(*)
Number of HSUPA Radio drops per

minute of calls
UIU007_R_HSUPA
Number of HSUPA drops versus number

of established HSUPA RAB.
UIU008_R_HSUPA UIU008_C_HSUPA
Number of HSUPA drops
Number of HSUPA drops per minute of

calls
Number of HSUPA drops per hour of calls
IU008_C_HSUPA/UTraffic018_C_HSUPA
Number of HSUPA drops per Volume of

HSUPA Traffic
Table 8-86 HSUPA Call Drop indicators

(*)
The counter VS.EdchCellDeletion (screening Radio Link Failure) used in the UHSUPA014 formula has
been corrected since UA6.0.5.1, counting exhaustively the EDCH Radio Link failure since then. So we
may observe an increase of this UHSUPA014 call drop rate indicator starting from UA6.0.5.1.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 252/275
8.9.2.3
HSUPA Load and Capacity
The views Hsupa_UlRtwp_Nbap and Hsupa_UlRtwpDistrib_Nbap, based on RNC counters, may

show an UL Load variation at RSEPS measurements activation (feature 33327). This does NOT
reveal a real UL Load variation. It simply reflects an RNC counters adjustments required at RSEPS
activation. The view Hsupa_UlRtwp_NodeBcounters, based on NodeB counters, may be used instead
to avoid any confusion.
Here below is an example of the artificial UL Load variation reported by the indicator UULOAD002
(based on RNC counters) at RSEPS measurements activation. The indicator UULOAD001, based on
NodeB counters, remains stable.
UL RTWP - Hsupa_UlRtwp_NodeBcounters versus Hsupa_UlRtwp_Nbap
Impact of RSEPS measurements activation (feature 33327)
View Hsupa_UlRtwp_NodeBcounters - RadioWBandRxPwr(dbm)
View Hsupa_UlRtwp_Nbap - UULOAD002(dBm)
-101.5
-102
RSEPS Deactivated
-102.5
-103
RadioWBandRxPwr is based on Nodeb counters #10201 and #10202

-103.5
-104
At RSEPS activation,
UULOAD002 is adjusted.
-104.5
-105
-105.5
RSEPS Activated
-106
UULOAD002 is based on RNC counter #303.

05/06/2009
03/06/2009
01/06/2009
30/05/2009
28/05/2009
26/05/2009
24/05/2009
22/05/2009
20/05/2009
18/05/2009
16/05/2009
14/05/2009
12/05/2009
10/05/2009
08/05/2009
06/05/2009
04/05/2009
02/05/2009
30/04/2009
28/04/2009
26/04/2009
24/04/2009
-106.5
Table 8-87 Counter #303 behaviour after RSEPS activation
8.9.2.4
HSUPA Quality
The HSUPA throughput monitoring result is not straight-forward to interpret. Currently in the Live
networks, the uplink traffic profile is more sporadic and with little volume of data, rather than intensive.
Consequently, the HSUPA throughput shows low values, not reflecting our product best
performances, and it is dependant on the volume of data. Here below is an illustration of the HSUPA
throughput variability depending on the volume of data.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 253/275
Table 8-88 HSUPA Throughput vs HSUPA Traffic Volume

The view Hsupa_throughput contains an indicator based on RNC counter (UHSUPA022) and an
indicator based on NodeB counter (UHSUPA015). UHSUPA015 was wrong in release prior to
UA06.0.5.1, largely over-estimating the HSUPA throughput. For this reason, it is recommended to use
UHSUAP022, especially if the monitoring period covers a release older than UA6.0.5.1.
8.10. FEATURES MONITORING

Features monitoring views and reports are used to display specific counters/indicators directly
associated to a feature. This family contains views for assessment of features included in UA7 FSM, in
UA6 FSM and on others specific features such as AlwaysOn, IRM CAC or RB bit rate adaptation for
which monitoring is often needed during analysis of main monitoring domain issues (accessibility or
retainabilty issue). If the indicators needed to monitor a feature are already available in other families
views such as accessibility views and/or traffic families, there is no need to create new views in
Feature Monitoring family: the feature will be simply monitored by using a report including the
necessary views.
8.10.1 Features monitoring views

Feature monitoring views are dispatched under the following subfamilies :
33331_ALARM_HHO_UeTX (New in UA7)
This subfamily provides views to monitor the UA7 feature Alarm HHO based on UE Tx power
(feature 33331). The corresponding FSM is located at https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=55600079&objAction=browse&sort=name&viewType
=1
34227_ST_TRANS_ENHANCEMENT (New in UA7)
This subfamily provides views to monitor the UA7 feature State Transition Enhancement (feature
https://wcdma-ll.app.alcatel34227).
The
corresponding
FSM
is
located
at
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 254/275

lucent.com/livelink/livelink.exe?func=ll&objId=55965122&objAction=browse&sort=name&viewType
=1
34231_SHO_ENHANCEMENTS (New in UA7.1)
This subfamily provides views to monitor the UA7 feature SHO Enhancement (feature 78326
globalization of feature 34231). The corresponding FSM is located at https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=53060752&objAction=browse&sort=name&viewType
=1
34246_POWER_CONTROL_ENHANCEMENTS (New in UA7.1)
This subfamily provides views to monitor the UA7 power control enhancements (feature 78328
globalization of feature 34246). The corresponding FSM is located at https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=56231867&objAction=browse&sort=name&viewType
=1
34480 3G2G Redirection based on Cell Load (New in UA7.1)
This subfamily provides views to monitor the UA7 feature 3G2G Redirection based on Cell Load
=1
Always On
AMR (New in UA7.1) is divided in 3 subfamilies AMR NB, AMR LR and AMR WB) and has
been introduced in UA7.1 to monitor AMR. It replaced the UA6 family AMR change rate
during the call which has been removed from the detailed monitoring dictionary.
Compressed mode HLS
This subfamily provides views to monitor the UA06 Compressed Mode by Higher Layer
Scheduling (HLS) (feature 28035). The corresponding FSM is located at https://wcdmall.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=41149992&objAction=browse&sort=name&viewType
=1
Defence mechanism for UEs not supporting CM with HSPA
This subfamily provides views to monitor the UA06 Defense mechanism for UEs not supporting
CM with HSPA (feature 34167). The corresponding FSM is located at https://wcdmall.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=41149992&objAction=browse&sort=name&viewType
=1
DISTRIBUTION COUNTERS FOR BLER (New in UA7.1)
DISTRIBUTION COUNTERS FOR RSCP AND ECNO (New in UA7.1)
This 2 subfamilies provide views to monitor the UA7 features Distribution counters for CPICH
RSCP, EcN0 and BLER (features 34694 and 34695). The corresponding FSM is located at
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=56026262&objAction=browse&sort=name&viewType
=1
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 255/275
IMCTA
IP SYNCHRONIZATION (New in UA7.1)
IRAT_ENH (New in UA7.1)
This subfamily provides views to monitor the UA7 IRAT Enhancements (feature 78331). The
corresponding
FSM
is
located
at
https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=54258626&objAction=browse&sort=name&viewType
=1
IRM CAC
IRM SCHEDULING
PS CORE NETWORK REQUESTED RAB MODIFICATION (New in UA7.1)
This subfamily provides views to monitor the UA7 feature PS CN requested RAB modification
=1
RB bit rate adaptation
RRC quick repeat
RRC QUICK REPEAT FACH POWER ADJ (New in UA7.1)
RRC re-establishment
This subfamily provides views to monitor the UA06 RRC connection re-establishment (feature
https://wcdma-ll.app.alcatel33821).
The
corresponding
FSM
is
located
at
lucent.com/livelink/livelink.exe?func=ll&objId=41151453&objAction=browse&sort=name&viewType
=1
SIM_CM
Single call cleanup
USER PERCEIVED THROUGHPUT COUNTERS
This subfamily provides views to monitor the UA7 feature User perceived throughput counters
=1
The list of all available views for features monitoring can be found by filtering the subfamily
FEATURES MONITORING in the ViewFamily excel sheet of the UA7.1 detailed monitoring
definition. For UA7.1, this file is available on Livelink at: https://wcdma-ll.app.alcatellucent.com/livelink/livelink.exe?func=ll&objId=56780279&objAction=browse&sort=name&viewType=1
Pre-emption
The Pre-emption feature will play a major role on several domains, so it requires a detailed
network analysis after its activation on the network (check main KPIs as usual).
The table below presents the specific views and indicators to monitor the Pre-emption feature
(33322).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 256/275
Table 8. 1: Specific views & indicators for Pre-emption feature.
The figure below displays the PreemptionTrigByCacFailure view for Network_A, during a given
period of time (Preemption feature was not activated).
Figure 8. 1: Display of view PreemptionTrigByCacFailure.

All the feature specific indicators may be observed at RNC level for global network monitoring or
at Cell level for troubleshooting or optimization.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 257/275
Always-On
The Always-On feature will play a major role on several domains, so it requires a detailed network
analysis after its activation on the network (check main KPIs as usual).
The table below presents the main views and indicators to monitor the Always-On feature.
Table 8. 2: Main views & indicators for Always-On feature.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 258/275
Figure 8.2: Display of view Always_On_Downsizing_Step1_Cell.
All the feature indicators may be observed at RNC level for global network monitoring or at Cell
level for troubleshooting or optimization.
Rate Adaptation
The Rate Adaptation feature will play a major role on several domains, so it requires a detailed
The table below presents the main views and indicators to monitor the Rate Adaptation feature.
Table 8. 3: Main views & indicators for Rate Adaptation feature.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 259/275
Figure 8.3: Display of view Rate_Adaptation_DL_Downsize_Attempts_Cell.
iRM Scheduling
The iRM Scheduling feature will play a major role on several domains, so it requires a detailed
The table below presents the main views and indicators to monitor the iRM Scheduling feature.
Table 8. 4: Main views & indicators for iRM Scheduling feature.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 260/275
Figure 8.4: Display of view Irm_Scheduling_Downgrade_Per_Bit_Rate_Rnc.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 261/275
9.
ADVANCED NPO MONITORING FEATURES
9.1.
NPO QOS ALERTER
This feature allows NPO users to be warned when some objects do not comply to user defined
quality criteria. By creating alarms that are triggered when some KPIs cross their predefined
thresholds, the alerter function can provide automatic detection of QOS problems to help monitor and
optimize the network configuration and efficiency.
Feature Benefits
Automatic detection of QOS problems
Non real time evaluation (not every 15 min GP).Minimum of 1 hour evaluation for hourly,
weekly and monthly periodicities.
Complement the OMC alerts that provide Real time evaluation (every 15 min GP).
Based only on indicators (not counters).
Three types of alerts (Standard , Variation, Complex).
Three possible severities (Critical , Major , Minor).
9.1.1
Definitions
Standard Alerter
Generates alert in case of threshold crossing, Only Indicators that have thresholds defined, can be
used in standard alerter,with a possibility to provide a manual threshold value.
The stability parameter permit to decide when the alert is to be generated , for example f the stability is
3,an alert will be generated only if the threshold was crossed during the last 3 periods. The sampling
flag adds another condition of alert generation to the threshold crossing ( used only when the indicator
has an associated sampling indicator).
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 262/275
Major
Alert
Indicator Value
Critical: Red
Major: Orange
Minor: Yellow
Variation Alerter
Generates alerts if the variation of the indicator value compared to a predefined base line, exceeds
the predefined thresholds. The variation is computed between 2 points of time (the last period and a
point in the past) and then compared to a defined variation value.
The variation alerter is defined by
Observation period: the time between the 2 points of measure, to have the variation with the
same hour last week, observation period is 1 week.
Smoothing period: provides a number of points (indicator values) around the two points of the
observation period, that will permit to smooth the indicator value. Smoothing period is always
less that observation period.
Algorithm: determines how values of the smoothing period are treated to have one value
(Average, max, Min, Sum).
Delta (in percentage): it will be compared to the computed variation to determine if an alert
must be generated or not.
Evolution (degradation or improvement): determines if the alerter evaluation shall point

degradation or an improvement of the variation.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 263/275
18
16
14
12
10
8
6
Q=3
4
2
P= 12
0
1
10
11
12
Q: Observation period
P: Smoothing periods
F: First value
L: Last value
S: is the result of the algorithm calculation.
X: the delta value given in alert creation
Direction
Upper/Lower is
fault
Evaluation Result
Alert
S>X
Raise
Lower
Raise
Upper
Fall
Lower
S<X
Alert generation
S>X
Alert generation
S<X
S<X
Fall
Upper
S>X
Alert generation
S<X
Alert generation
S>X
Complex Alerter
Generates alerts on case a formulae predicate is evaluated to true. This predicate is constructed with
a formula using multiple indicators ,simple arithmetical and logical operators ,there is no limit in the
number of indicators involved in the formula .The stability parameter is used as for standard alerts.
Example :
((I1 + I2 +I3)==0) && ((I1 + I2 + I4 + I5) > 5)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 264/275

Alert will be generated if the condition is fulfilled.
9.1.2
NPO alerts property (periodicity/validity)
Periodicity: Hour, Day, Week, Month

Period of validity: The period of validity is a time interval during the day or a list of days, in which the
alerter can be evaluated.
9.1.3
NPO Alerter Status
Active: the alerter is enabled and may raise or clear alarms.

Inactive: the alerter is disabled, No alarm on this alerter .the alerter is created in deactivated state and
can only be deleted in this state.
Failed: If a problem occurs during alerter evaluation, the alerter is deactivated and the state becomes
failed.
Create
Delete
Inactive
Activate
Deactivate
Active
Delete
Failed
Delete
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 265/275
9.1.4
NPO Alerter GUI

Alerter
Editor
Alerters
List
Indicator
Topology
List
NPO Alerter Editor

Create Standard Alerter
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 266/275
Create Variation Alert
Create Complex Alert
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 267/275
NPO Alerters List
NPO Alerts View
9.2.
DIAGNOSIS SCENARIOS
The diagnosis functionality in NPO is used to derive the probable root cause of a Qos performance
problem. The operator may launch a diagnosis in different contexts:
For a detected QoS degradation (typically when a QoS indicator has crossed a threshold)
For a network object (cell or RNC) the operator wants to investigate
For a set of network objects (usually a group of cells) the operator wants to investigate
Once executed, the diagnosis returns the results to the operator, who is then able to tune the
necessary radio parameters to correct the degradations and optimize the network behaviour.
NPO document [R8] and MUSE documents [R9] and [R10] may be useful when creating diagnosis
scenarios in NPO.
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 268/275
9.2.1
Description of Diagnosis Scenario
This section describes the method used for creating a specific diagnosis scenario in NPO for WCDMA
for RRC Connection Success Rate analysis.
The diagnosis scenario created (Rrc_Connection) aims at finding possible parameter settings that
when wrongly set may affect the overall RRC Connection Success Rate.
The investigation is ruled by the following procedure:
Low RRC Connection Success Rate (URRC003_CR < 95%) is identified in the RNC
Verification of settings of RRC timers and parameters on UE and RNC
Verification of settings for T351-N351 Based Repetition feature
Verification of settings for FACH Power Adjustment feature at RNC level
Verification of settings for FACH Power Adjustment feature at cell level
Verification of settings for RRC Connection Setup Quick Repetition feature at RNC level
Verification of settings for RRC Connection Setup Quick Repetition feature at cell level
Verification of settings for qQualMin Admission Control feature at RNC level
Verification of settings for qQualMin Admission Control feature at cell level
Verification of settings for UL Interference Call Admission Control on RACH
The following scenario tree is defined:
On each node (green) below the first node (orange) a set of checks is performed in terms of
parameters that may affect the RRC Connection Success Rate indicator. The links between the RNC
level nodes and the cell level nodes are links with iteration.
RRC Timers and Parameters on UE and RNC

The results of the node analysis are the following:
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 269/275

OK
NOK
UNKNOWN
T300 = ueTimerIdle2000MS
T300 ueTimerIdle2000MS
T300 =
and
or
or
N300 = 4
N300 4
N300 =
and
or
or
T352 = 3000
T352 3000
T352 =
RRC timers and/or

parameters are correctly set.
RRC timers and/or

parameters have an incorrect
value.
It is not possible to evaluate

if RRC timers and parameters
are correct.
(incorrect parameters are

identified)
T351-N351 Based Repetition

OK
NOK
UNKNOWN
T351 = 0
(i) T351 = 0
T351 =
and

feature is not active: T351
should not be set to 0.
or
N351 = 0
and
(ii) N351 = 0
T352 T351 * N351

feature is active and
associated parameters are
correctly set.

feature is not active: N351
should not be set to 0.
N351 =
if parameters for T351-N351
Based Repetition feature are
correct.
(iii) T352 < T351 * N351

feature is not active: T352
should be higher than T351 *
N351.
(iv) T51 700
or
N351 2
feature parameters have an
incorrect value.
identified)
FACH Power Adjustment (RNC)

UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 270/275

OK
NOK
UNKNOWN
isFachPowerAdjustmentEnable
d = true
(i)
d = false
fachPowerAdjustmentCpichEcN
o Threshold =
and
o Threshold = -8
and
InitialFachPowerAdjustment = 3
and
FachTransmitPowerLevelStep
=1
FACH Power Adjustment

feature is not active at RNC
level.
(ii)
o Threshold -8
or
InitialFachPowerAdjustment 3
or

correctly set.
or
InitialFachPowerAdjustment =
or
=
if parameters for FACH
Power Adjustment feature are
correct.
1
feature parameters have an
incorrect value.
identified)
RRC Connection Setup Quick Repetition (RNC)

OK
NOK
UNKNOWN
isQuickRepeatAllowed = true
(i) isQuickRepeatAllowed =
false
isQuickRepeatAllowed =
and
deltaCpichEcNoUsedQuickRep
eat = -2
and

Quick Repetition feature is
not active at RNC level.
(ii) deltaCpichEcNoUsedQuick
Repeat -2
numberOfQuickRepeat = 3
or
deltaCpichEcNoUsedQuickRepe
at =
or
numberOfQuickRepeat =
or
numberOfQuickRepeat 3
active and associated
parameters are correctly set.

Quick Repetition feature
parameters have an incorrect
value.
identified)

if parameters for RRC
Connection Setup Quick
Repetition feature are
correct.
qQualMin Admission Control on RACH (RNC)

UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 271/275

OK
NOK
UNKNOWN
rejectBelowQQualMinEnable =
true
(i) rejectBelowQQualMin
Enable = false
and
qQualMin Admission
Control feature is not active
at RNC level.
or
waitTimeRejectQQualMin = 10
qQualMin Admission
Control feature is active and
correctly set.
(ii) waitTimeRejectQQualMin
10
qQualMin Admission
Control feature parameters
have an incorrect value.
waitTimeRejectQQualMin =
if parameters for qQualMin
Admission Control feature
are correct.

identified)
UL Interference Call Admission Control on RACH

OK
NOK
UNKNOWN
maxULInterferenceLevel = -50
maxULInterferenceLevel -50
maxULInterferenceLevel =
and
or
or
waitTimeOnRrcConnection
Rejection = 5
Rejection -5
Rejection =
Parameters for UL
Interference Call Admission
Control on RACH feature are
correctly set.
Parameters for UL
not correctly set.

if parameters for UL
correct.

identified)
Note: Parameter maxULInterferenceLevel is checked for all CAC classes. If for one of the classes the
parameter has not the value -50, the diagnosis will return a NOK with the following comment:
Parameter maxULInterferenceLevel is not correctly set for all CAC configuration classes.
FACH Power Adjustment (Cell)

OK
NOK
UNKNOWN
d = true
(i) isFachPowerAdjustment
Enabled = false
isFachPowerAdjustmentActivate
d=
and

feature is not active at RNC
level. Cell level analysis is
irrelevant.
or
isFachPowerAdjustment
Activated = true
sccpchPowerRelativeToPcpich
=
and
or
maxFachPowerRelativeToPcpic
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 272/275

OK
NOK
UNKNOWN
= -1 (Mono-SCCPCH or BiSCCPCH)
(ii) isFachPowerAdjustment
Activated false
h=
= -3.5 (Tri-SCCPCH)
and

feature is not active at cell
level.
h=4
(iii) Mono-SCCPCH or BiSCCPCH:
and
-1
h
+ InitialFachPowerAdjustment +
N351 *
correctly set.

if parameters for FACH Power
Adjustment feature are
correct.
or
h4
or
h<
N351 *
feature is active at cell level
but associated parameters
identified)
(iv) Tri-SCCPCH:
-3.5
or
h4
or
h<
N351 *
feature is active at cell level
but associated parameters
identified)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 273/275

Note: In the cases of Bi-SCCPCH or Tri-SCCPCH configuration the user must be aware of the
structure of the SCCPCH and FACH and the order they are presented in the lists obtained when
navigating through the parameters tree.
The different SCCPCH configurations and their implementation in the RAN model are shown below:
Mono-SCCPCH
SCCPCH
Instance
Pointing to SCCPCH
Class
/0
/1
With FACH
Instances
Pointing to FACH
Class
/0
/0
/1
/1
Bi-SCCPCH
SCCPCH
Instance
Pointing to SCCPCH
Class
With FACH
Instances
Pointing to FACH
Class
/0
/2
No Instance
Not Applicable
/1
/3
/0
/2
/1
/3
Bi-SCCPCH
SCCPCH
Instance
Pointing to SCCPCH
Class
With FACH
Instances
Pointing to FACH
Class
/0
/2
No Instance
Not Applicable
/1
/5
/0
/6
/1
/7
/2
/4
/0
/5
/1
/4
According to the UE RRC state and SCCPCH configuration, different SCCPCH instances can be
used. For the specific case of the UE entering RRC connect mode (RRC Connection Setup):
SCCPCH Configuration at RNC
level
CBS Activated at cell

level
Mono-SCCPCH
Not possible
SCCPCH#0 for CCCH (signalling on

FACH)
Bi-SCCPCH
Not possible

FACH)
Active

FACH)
Not Active

FACH)
Tri-SCCPCH
SCCPCH used
When navigating through the parameters tree in NPO using the appropriate primitives included in the
N.py library, the elements in the lists are presented in the following order (the list elements used to
derive the parameters for the SCCPCH and FACH used when the UE is entering RRC connected
mode are marked in blue):
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 274/275

SCCPCH
Position in list (SCCPCH)
SCCPCH Configuration at RNC

level
Mono-SCCPCH
SCCPCH
Instance/0 (class
1)
Bi-SCCPCH
SCCPCH
Instance/1 (class
3)
SCCPCH
Instance/0 (class
2)
Tri-SCCPCH
SCCPCH
Instance/2 (class
4)
SCCPCH
Instance/1 (class
5)
SCCPCH
Instance/0 (class
2)
FACH
SCCPCH
Configuration at RNC
level
Position in list (FACH)

0
Mono-SCCPCH
FACH
Instance/1
(class 1)
FACH
Instance/0
(class 0)
Bi-SCCPCH
FACH
Instance/1
(class 3)
FACH
Instance/0
(class 2)
Tri-SCCPCH
FACH
Instance/1
(class 5)
FACH
Instance/0
(class 4)
FACH
Instance/1
(class 7)
FACH
Instance/0
(class 6)
RRC Connection Setup Quick Repetition (Cell)

OK
NOK
UNKNOWN
isQuickRepeatAllowed = true
(i) isQuickRepeatAllowed =
false
isQuickRepeatAllowed =
and
isQuickRepeatActivated = true
active at cell level.

not active at RNC level. Cell
level analysis is irrelevant.
(ii) isQuickRepeatActivated =
false
or
isQuickRepeatActivated =
if parameters for RRC
Connection Setup Quick
Repetition feature are
correct.

Quick Repetition not active at
cell level.
qQualMin Admission Control on RACH (Cell)
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 275/275

OK
NOK
UNKNOWN
true
(i) rejectBelowQQualMin
Enable = false
and
qQualMin Admission
Control feature is not active
at RNC level. Cell level
analysis is irrelevant.
or
qQualMin = -16
Parameter qQualMin is
correctly set.
(ii) qQualMin -16

Parameter qQualMin is not
correctly set.
qQualMin =
if parameters for qQualMin
Admission Control feature
are correct.
END OF DOCUMENT
UMT/IRC/INF/012027
07.02 /EN
Preliminary
25/June/2010
Page 276/276

UMT IRC INF 012027 Performance Monitoring Guidelines V07.02 Preliminary

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UMT IRC INF 012027 Performance Monitoring Guidelines V07.02 Preliminary

Încărcat de

Drepturi de autor:

Formate disponibile

UTRAN PERFORMANCE MONITORING GUIDELINES

Copyright 2008 Alcatel-Lucent, All Rights Reserved

UA7 Performance Monitoring Guidelines

UA7 Performance Monitoring Guidelines

UA7 Performance Monitoring Guidelines

UA7 Performance Monitoring Guidelines

Restructuring of performance report chapter to improve clearness

Thresholds updated based on UA4.2 assessment

Panel chart updates

5.0 call trace updates

Acronymous list added

Nortel references removed

Update in call profile according to 4.2 validation

Update in panel report after VO period to include and remove metrics

Update in post upgrade monitoring

Update in livelinks: ie, documentation, status after VO, etc

Update is monitoring panels to include links to feature monitoring guidelines

UA7 Performance Monitoring Guidelines

Update in troubleshooting panels & charts

Update in capacity monitoring methodology

Panel report Updates with 4.2 metrics

Troubleshooting chart updates

Update in threshold determination methodology.

Update in call profile calculation according to 4.1 execution.

Update in metric reports after VO period.

Troubleshooting example: CELL FACH issues

Table and Figure numbering

UA7 Performance Monitoring Guidelines

Metric thresholds for investigation

Several troubleshooting cases based on field experience.

New predefine reports for RF Audits and 3G 2G troubleshooting.

RNC panel, Capacity panel and Call Profile panel

Update from the cases opened.

UA7 Performance Monitoring Guidelines

AUDIENCE FOR THIS DOCUMENT ................................................................... 13

REFERENCE DOCUMENTS ............................................................................ 14

PERFORMANCE MONITORING OVERVIEW.................................................. 15

PERFORMANCE MONITORING OBJECTIVES .................................................... 15

MONITORING PROCESS ............................................................................... 15

AVAILABLE TOOLS ........................................................................................ 16

NPO BASICS .................................................................................................... 17

COUNTERS, INDICATORS AND DICTIONARIES .......................................... 24

Indicator Attributes ................................................................................ 31

INDICATORS CONSOLIDATION ..................................................................... 36

UA7 Performance Monitoring Guidelines

Synchronisation with Display Period ..................................................... 38

How to Create Busy Hour Indicators in NPO ....................................................................... 42

VIEWS AND REPORTS DICTIONARIES ......................................................... 45

MONITORING AND PERFORMANCE ANALYSIS .......................................... 51

GLOBAL PERFORMANCE MONITORING ............................................................ 51

Global accessibility views .................................................................................................... 53

Detailed accessibility monitoring ........................................................... 64

Accessibility troubleshooting ................................................................. 98

Radio Bearer vs RAB Counters Assessment ..................................................................... 102

Global 3G3G mobility views for compressed mode ........................................................... 111

High level of 3G2G mobility monitoring............................................... 120

Global RRC Redirection mobility views ............................................................................. 106

3G3G mobility monitoring ................................................................... 110

Global 3G2G mobility views ............................................................................................... 121

Detailed mobility monitoring ................................................................ 126

3G2G mobility detailed monitoring ..................................................................................... 127

UA7 Performance Monitoring Guidelines

Mobility troubleshooting ...................................................................... 131

3G-2G HHO troubleshooting.............................................................................................. 132