TMO18268 UA7 R99 QoS Analysis and Traffic Load Monitoring

9300 WCDMA
TMO18268 9300 WCDMA UAO7 R99 QoS

Analysis and Traffic Load Monitoring
TMO18268 D0 SG DEN I2.0
STUDENT GUIDE
All Rights Reserved © Alcatel-Lucent 2010
All rights reserved © Alcatel-Lucent 2010

Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
TMO18268 9300 WCDMA

All Rights UAO7©R99
Reserved QoS Analysis
Alcatel-Lucent and Traffic Load
2010
Monitoring - Page 1
Empty page
Switch to notes view!
2 All Rights Reserved © Alcatel-Lucent 2010

9300 WCDMA
TMO18268 9300 WCDMA UAO7 R99 QoS Analysis and Traffic Load Monitoring
This page is left blank intentionally
TMO18268 9300 WCDMA

2010
Monitoring - Page 2
Terms of Use and Legal Notices
1. Safetyto
Switch Warning
notes view!
Both lethal and dangerous voltages may be present within the products used herein. The user is strongly advised not to
wear conductive jewelry while working on the products. Always observe all safety precautions and do not work on the
equipment alone.
The equipment used during this course may be electrostatic sensitive. Please observe correct anti-static precautions.
2. Trade Marks
Alcatel-Lucent and MainStreet are trademarks of Alcatel-Lucent.
All other trademarks, service marks and logos (“Marks”) are the property of their respective holders, including Alcatel-
Lucent. Users are not permitted to use these Marks without the prior consent of Alcatel-Lucent or such third party owning
the Mark. The absence of a Mark identifier is not a representation that a particular product or service name is not a Mark.
Alcatel-Lucent assumes no responsibility for the accuracy of the information presented herein, which may be subject to
change without notice.
3. Copyright
This document contains information that is proprietary to Alcatel-Lucent and may be used for training purposes only. No
other use or transmission of all or any part of this document is permitted without Alcatel-Lucent’s written permission, and
must include all copyright and other proprietary notices. No other use or transmission of all or any part of its contents may
be used, copied, disclosed or conveyed to any party in any manner whatsoever without prior written permission from
Alcatel-Lucent.
Use or transmission of all or any part of this document in violation of any applicable legislation is hereby expressly
prohibited.
User obtains no rights in the information or in any product, process, technology or trademark which it includes or
describes, and is expressly prohibited from modifying the information or creating derivative works without the express
3written consent of Alcatel-Lucent. All Rights Reserved © Alcatel-Lucent 2010
9300 WCDMA
4. Disclaimer
In no event will Alcatel-Lucent be liable for any direct, indirect, special, incidental or consequential damages, including
lost profits, lost business or lost data, resulting from the use of or reliance upon the information, whether or not Alcatel-
Lucent has been advised of the possibility of such damages.
Mention of non-Alcatel-Lucent products or services is for information purposes only and constitutes neither an
endorsement, nor a recommendation.
This course is intended to train the student about the overall look, feel, and use of Alcatel-Lucent products. The
information contained herein is representational only. In the interest of file size, simplicity, and compatibility and, in some
cases, due to contractual limitations, certain compromises have been made and therefore some features are not entirely
accurate.
Please refer to technical practices supplied by Alcatel-Lucent for current information concerning Alcatel-Lucent equipment
and its operation, or contact your nearest Alcatel-Lucent representative for more information.
The Alcatel-Lucent products described or used herein are presented for demonstration and training purposes only. Alcatel-
Lucent disclaims any warranties in connection with the products as used and described in the courses or the related
documentation, whether express, implied, or statutory. Alcatel-Lucent specifically disclaims all implied warranties,
including warranties of merchantability, non-infringement and fitness for a particular purpose, or arising from a course of
dealing, usage or trade practice.
Alcatel-Lucent is not responsible for any failures caused by: server errors, misdirected or redirected transmissions, failed
internet connections, interruptions, any computer virus or any other technical defect, whether human or technical in
nature
5. Governing Law
The products, documentation and information contained herein, as well as these Terms of Use and Legal Notices are
governed by the laws of France, excluding its conflict of law rules. If any provision of these Terms of Use and Legal
Notices, or the application thereof to any person or circumstances, is held invalid for any reason, unenforceable including,
but not limited to, the warranty disclaimers and liability limitations, then such provision shall be deemed superseded by a
valid, enforceable provision that matches, as closely as possible, the original provision, and the other provisions of these
Terms of Use and Legal Notices shall remain in full force and effect.
TMO18268 9300 WCDMA

2010
Monitoring - Page 3
Blank Page

9300 WCDMA
TMO18268 9300 WCDMA

2010
Monitoring - Page 4
Course Outline
Section
About This1.Course
Radio Network Performance Overview
4. Topic/Section is Positioned Here
Module 1. TMO18268
Course outline
Technical support the Radio Network Performance
Section 2. Monitor 5. Topic/Section is Positioned Here
Course objectives
Module 1. TMO18268
Section 3. Monitoring
1. Topic/Section and TroubleShooting
is Positioned Here Methods
Xxx Module 1. TMO18268
Xxx
Section 4. Network Accessibility Monitoring 7. Topic/Section is Positioned Here
Xxx
Module 1. TMO18268
Section 5. Retainability Monitoring
Module 1. TMO18268
Section 6. Mobility Monitoring
Module 1. TMO18268
Section 7. Network Quality Monitoring
Module 1. TMO18268
Section 8. Capacity Monitoring
Module 1. TMO18268
Section 9. Traffic Monitoring
Module 1. TMO18268
9300 WCDMA
TMO18268 9300 WCDMA

2010
Monitoring - Page 5
Course Outline [cont.]

9300 WCDMA
TMO18268 9300 WCDMA

2010
Monitoring - Page 6
Course Objectives
Welcome to TMO18268 9300 WCDMA UAO7 R99 QoS Analysis and Traffic Load
Monitoring
Upon completion of this course, you should be able to:
Gives the basics of UTRAN QoS and Traffic Load monitoring for R99 service thanks to main
ALU UTRAN PM Counters and Indicators

9300 WCDMA
TMO18268 9300 WCDMA

2010
Monitoring - Page 7
Course Objectives [cont.]

9300 WCDMA
TMO18268 9300 WCDMA

2010
Monitoring - Page 8
About this Student Guide

Conventions
Switch used
to notes in this guide
view!
Note
Provides you with additional information about the topic being discussed.
Although this information is not required knowledge, you might find it useful
or interesting.
Technical Reference
(1) 24.348.98 – Points you to the exact section of Alcatel-Lucent Technical
Practices where you can find more information on the topic being discussed.
Warning
Alerts you to instances where non-compliance could result in equipment
damage or personal injury.
Where you can get further information

9300 WCDMA
If you want further information you can refer to the following:

Technical Practices for the specific product
Technical support page on the Alcatel website: http://www.alcatel-lucent.com
TMO18268 9300 WCDMA

2010
Monitoring - Page 9
About this Student Guide [cont.]

9300 WCDMA
TMO18268 9300 WCDMA

2010
Monitoring - Page 10
Self-assessment of Objectives
Contract number :
At the end of each section you will be asked to fill this questionnaire
Course title :
Please, return this sheet to the trainer at the end of the training
Client (Company, Center) :
Language :
Switch to notes view! Dates from : to :
Number of trainees : Location :
Surname, First name :
Did you meet the following objectives ?

Tick the corresponding box
Please, return this sheet to the trainer at the end of the training
Yes (or No (or

Instructional objectives globally globally Comments
yes) no)
1 To be able to XXX
2
9300 WCDMA
TMO18268 9300 WCDMA

2010
Self-assessment of Objectives [cont.]
Yes (or No (or

Instructional objectives Globally globally Comments
yes) no)

9300 WCDMA
Other comments
Thank you for your answers to this questionnaire

TMO18268 9300 WCDMA

2010
Do not delete this graphic elements in here:
Section 1
11
Radio Network Performance
Overview
Module 1
9300 WCDMA

Section 1 Module 1 Page 1
Blank Page

9300 WCDMA TMO18268 9300 WCDMA UAO7 R99 QoS Analysis and Traffic Load Monitoring
Document History
Edition Date Author Remarks
01 2010-04-27 Nolan, Vincent First edition for UA07

Module Objectives
Upon completion of this module, you should be able to :
Explain what is UTRAN QoS and what are the main performance
optimization steps
Main steps:
Define the end-user QoS in UMTS and localize where the UTRAN QoS take
place.
Define the network optimization process


Module Objectives [cont.]


Table of Contents
Page
1 Define QoS inside the Network 7
What is End user QoS over UMTS ? 8
Mapping Teleservices to QoS 10
UMTS Traffic Classes 11
Standard QoS Bearer 12
What is QoS UTRAN in UMTS? 13
Self-Assessment on the Objectives 15
End of Module 16


Table of Contents [cont.]

Radio Network Performance Overview This page is left blank intentionally

1 Define QoS inside the Network


What is End user QoS over UMTS ?
End user expectations concerning services usage over UMTS
Quick data
Several transmission More
(delay & bit rate)
applications interactivity
simultaneaously (delay & jitter)
...
I want to download the new Formula One game while discussing with my daughters,
But I need a sufficient bit rate in order to download this famous game …
And I do not want to wait when I ask for a new web page !

Expectations of end-user regarding simultaneous access to different services, data transmission speed
(fast file transfer or fast display of web pages) led 3GPP to the define criteria and parameters for
managing UMTS resources in an effective way while providing the QoS the end-user expects.

What is end user QoS over UMTS ? [cont.]
But technology constraints…

leading to an efficient usage of resources over UMTS
• Various data rates Scarce

Heterogeneous
(from voice 12.2kbps up to 384 Kbps FDD)
& costly
terrestrial
radio
• Various connections (real time CS & non real time PS) resources
resources
• Asymmetric traffic patterns
• Various QoS (blocking, delay, throughput, BLER)
Load optimisation over

Multi-services environment a common transmission medium

UMTS networks have been designed to transmit packet and circuit switched applications on the same
medium (radio or terrestrial)
Information generated by independent sources must be efficiently multiplexed on the same
transmission medium
UMTS supports traffic with very different bandwidth and QoS requirements. For instance :
Traffic generated by data transfer services and Internet access is essentially bursty and
unpredictable
Data transmission between machines is sensitive to loss but usually not to end-to-end
delay or jitter
Speech (and, more generally, real-time applications) requires strict limits on the
transmission delay, but can cope with reasonable loss rates
The system must use the transmission resources efficiently (not only scarce radio spectrum, but also
terrestrial resources)
Especially the radio and access part (e.g. "Last Mile") must provide a cost-effective transfer
service while minimising investment and operating costs
Transmission links and the radio interface must be loaded as heavily as possible to achieve
statistical multiplexing gain while meeting the QoS requirements (but operator must make a
trade-off between subscribed QoS and radio constraints)
Therefore it is important to identify mechanisms that optimise the load

Mapping Teleservices to QoS
Conversational Streaming audio

Voice messaging Fax
voice and video and video
Increasing
Error
Tolerance
Telnet, E-commerce, FTP, still image E-mail arrival

Interactive games WWW browsing, notification
Conversational Interactive Streaming Background

(delay <<1 sec) (delay approx.1 sec) (delay <10 sec) (delay >10 sec)
Increasing
Delay Tolerance
1 1 10 All Rights Reserved © Alcatel-Lucent 2010


UMTS Traffic Classes
Four QoS Classes defined in 3GPP standards

Transfer Delay Transfer Delay Low bit Error Guatanteed bit
requirement variation rate rate
Conversational stringent stringent less constrained stringent
Streaming less constrained constrained less constrained constrained
Interactive constrained not constrained constrained not constrained
Example of Multimedia Applications with their QoS requirements

Conversational Real time services:VoIP, Video Call, Audio-conferencing
Streaming Broadcast services (audio, video), News, Sports
Interactive WEB browsing, Interactive Chat, Games, m-commerce
Background E-mail, SMS, database downloads, measurements transfer
Required QoS depends on the applications

Four QoS classes are defined in 3GPP standards.

Conversational Class: Preserve time relation (variation) between information entities of the stream,
Conversational pattern (stringent and low delay) e.g. voice
Streaming Class:
Preserve time relation (variation) between information entities of the stream, e.g. streaming video
Interactive Class:
Request Response pattern, Preserve Payload content, Web Browsing
Background Class:
Destination is not expecting the data within a certain time, Preserve payload content, Background
download of Emails.
Exercise:
Fill the table with the following:
Stringent
Constrained
Less constrained
Not constrained

Standard QoS Bearer
UE UTRAN CN CN UE
Node Gateway
Teleservice
UMTS Bearer Service External Bearer

Service
Radio Access Bearer Service CN Bearer
(RAB) Service
Radio Bearer Iu Bearer Backbone

Service Service Bearer Service
... ...
Radio Physical Physical

Bearer Service
Bearer Service
Uu Iu

The UMTS PLMN is responsible for providing transport of teleservice data across the UMTS network
according to the QoS required for each of the teleservices it is supporting. This means that both UTRAN
and UMTS Core Network domains must implement specific mechanisms to provide the required QoS.
From a UTRAN perspective, the RAB is the means by which data is transferred between UE and CN at
the required QoS. A RAB will be mapped on Radio Bearers and its Logical, Transport and Physical
Channels which will be defined with the parameters allowing to provide the required QoS of the RAB.

What is QoS UTRAN in UMTS?
IPv4 / IPv6 Backbone Border

NodeB Gateway
RNC
MT
RSP RSP
SGSN
GGSN
NodeB Media
Gateway
RNC
Multimedia or Data Application

IP PDP PDP
IP IP IP
GTP GTP tunnel UMTS
GTP bearer
GTP GTP
IP IP IP IP
RADIO Bearer ATM PVC MPLS Tunnel MPLS Tunnel

UTRAN QoS consists of a set of measurements providing the UMTS PLMN Operator with accurate
knowledge of the performance of the UTRAN sub-system. Of course the quality of service experienced
by the end-user, also called Quality of Experience (QoE), is not only the consequence of the UTRAN
QoS. Indeed the QoE is impacted by the UMTS Core Network QoS as well as the QoS of the PDN, the
application servers and user equipments in use for a specific teleservice.

What is QoS UTRAN in UMTS? [cont.]
A comprehensive set of mechanisms answering end users´ expectations
Quick data
transmission
(delay & bit rate)
Several More
applications ✓ Power control interactivity
(delay & jitter)
simultaneously
... ✓ DiffServ within RNC
✓ HSDPA/HSUPA channels
for HSxPA see 9300 W-CDMA ✓ iRM/Always On transitions
UA07 HSxPA QoS Analysis and ✓ DiffServ within RNC
✓ Multi RAB per user Traffic Load Monitoring
✓ RAB parameters mapping flexibility

To ensure simultaneous applications for a given user the network should:

Allow multi RAB per user
Provide a certain flexibility in the mapping of RAB parameters (at logical, transport and physical
layers)
Quick data transmission is directly impacted by:
Power control efficiency
The usage of the HSDPA/HSUPA channels (for HSxPA see 9300 W-CDMA UA07 HSxPA QoS Analysis and
Traffic Load Monitoring)
And the usage of DiffServ within the RNC over IuPS interface to insure higher priority for high bit rate
services
Many UTRAN imternal mechanisms are in place to provide priorities of data delivery to specific user
and/or applications in order to increase the data bit rate when needed.
More services interactivity is achieved by:
Appropriate iRM and AO states transitions
As well as the usage of DiffServ within the RNC to provide higher priority for interactive services

Self-Assessment on the Objectives
Please be reminded to fill in the form

for this module
The form can be found in the first part
of this course documentation


End of Module


Section 2
21
Monitor the Radio Network
Performance
Module 1
9300 WCDMA

Blank Page

Monitor the Radio Network Performance
Document History
02 2010-08-02 Charneau, Jean-Noel • change of RNC C-Node counter families

• change examples of Remote Cell counters

Module Objectives
Explain what are the available Alcatel-Lucent UTRAN performance

monitoring information sources
Main steps:
Define what are the characteristics of the QoS counters and the QoS
indicators.
Interpret QoS reports
Correlate a QoS problem with information coming from other sources.




Table of Contents
Page
1 QoS counters definition 7
1.1 Introduction 8
1.2 Counters: Definition 9
1.3 Collect performance data with ALU solution (1/2) 10
1.5 Counter file storage 12
1.6 NPO introduction to UTRAN monitoring 13
2 Counters properties and Analysis 14
2.1 Counter groups and families 15
2.1.1 RNC Counter families 16
2.1.2 NodeB and MSS Counter families 17
2.2 Cumulative Counter Type 18
2.2.1 Example 19
2.3 Value Counter Type 20
2.3.1 Example 21
2.4 Load Counter Type 22
2.4.1 Example 23
2.5 RNC C-Node counter object instances 25
2.6 RNC and “Any Cell” object instances for C-Node counters 26
2.6.1 Example: Any Cell counter of RNC acting as a DRNC 27
2.7 Reference Cell object instance for C-Node counters 28
2.7.1 Example – Reference Cell counter of RNC1 29
2.8 Neighbouring RNC object instance for C-Node counters 30
2.8.1 Example – Neighbouring RNC counter of RNC1 31
2.9 Remote Cell object instance for C-Node counters 32
215 2.9.1 Example – Remote Cell counter of RNC1
33
9300 WCDMA2.10 NPO
TMO18268 Aggregation
9300 WCDMA perandcouple
UAO7 R99 QoS Analysis (Remote Cell,RNC)
Traffic Load Monitoring 34
2.11 NPO Aggregation per Cell 35
2.12 NPO Aggregation per RNC 36
2.13 BTS counter object instances 37
2.14 MSS counter families and object instances 38
2.15 Counter Screenings 39
3 Metrics properties and Analysis 40
3.1 Metrics Definitions 41
3.2 Metrics Generic Formulas 42
4 Generating Reports and Analysis 43
4.1 RNC Counter Volume Control 44
4.2 Indicator Aggregation 45
4.3 Report Definition 46
4.3.1 Generate a report on NPO 47
4.3.2 Key Performance Indicators 48
4.3.3 Network Key Performance Indicators 49
4.3.4 Counter based KPIs 50
4.3.5 Methodological precautions 51
4.3.6 KPI value 52
4.3.7 Network Element aggregation 53
4.3.8 With other indicators 54
4.3.9 With alarms 55
4.3.10 With parameters modification 56
5 Real Time Counters 57
5.1 Overview 58
5.2 Real Time PM versus Legacy PM 59
5.3 Real time Performance Monitoring Application 60
5.4 Real Time Metrics 61
6 Alcatel-Lucent Call Trace Solution Overview 62
6.1 Introduction 63

Page
6.2 Call Trace Session Types : Trace a UE 64
6.3 Call Trace Session Types : Trace traffic in a group of cells 65
6.4 Call Trace Session Types : Trace Common NBAP, Mobility 66
6.5 Call Trace Session Types : Trace Iu interfaces 67
6.6 Configuring a Call Trace Session 68
6.7 Real time Call Trace Overview 69
6.8 Real time Call Trace Preparation 70
6.9 Real time Call Trace Monitoring 71
7 Alcatel-Lucent Performance Monitoring Tools 72
7.1 OAM Performance Management Portfolio 73
7.2 OAM Performance Management Portfolio Strategy 74
7.3 Post Processing Call Trace Data with RFO 75
7.4 Post Processing Call Trace Data with WQA 76
End of Module 78


1 QoS counters definition


1.1 Introduction
Network Network Network Pre-launch Network
Design Planning Deployment Optimization Acceptance
Supervision
Densification
Network
Network
Network
Optimization
The Alcatel-Lucent Performance Management Solution is based on:

Observation Counters
Call Trace
Counters and Call Trace allow to:
Implement an Accurate Performance Management Activity
Increase Control over Global Network Performance
Cover all aspects of QOS (Reliability, Accessibility, Retainbility, Quality, Traffic
and Capacity, …)
Provide Fast and Appropriate response to Performance Issues
Implement mechanisms allowing to identify, troubleshoot and solve network
issues and malfunctions in a timely manner
Provide invaluable data for network optimization, network evolution and
business planning

All these factors contribute to NW Management OPEX Reduction

1.2 Counters: Definition
• Counters measure a number of specific events (occurring in an entity of

the UTRAN), during a defined period
• Counter values are generated by

the Control Node part of the RNC equipment (CN or RNC counters)
the Interface Node part of the RNC equipment (IN or MSS counters)
the BTS equipment (NODE-B or BTS counters)
• Counter values are then stored in the WMS server
RNC & MSS counters

(every 15’) BTS counters
(every 15 or 60’)
Performance Server BTS
RNC

The wording “counter and “measurement” are often equally used in the documentation for
identifying the same concept.
Usually, Alcatel-Lucent prefers to use the term “counter” to distinguish a counter from a “(radio)
measurement” (3GPP concept). A counter is periodically elaborated on periods expressed in minutes
or hours, e.g. 30 min, while a measurement is elaborated on periods expressed in milliseconds, e.g.
500 ms.
Periods of counter
Granularity Period (GP)
It is the duration of the events counting in the selected entity of the network.
It corresponds to the minimum time granularity at which counters are provided.
It can be modified. The QoS monitoring daily and hourly periods are used. By default:
RNC counters and MSS are uploaded every 15 min.
BTS counters are uploaded every 15 min &/ or hour.
Observation Period (or Measurement Period)
It is the time period for which the counter will be used for metric computation and display on
operator request.
Busy hour corresponds to the hour of the day when the traffic is the highest. It allows to analyze
performances of the cells, when the traffic is higher. It is really important for congestion/capacity
analysis and also forecasting.
Daily period gives global information on the day. To compare busy hour and daily data, is
necessary to check the influence of the traffic.
Weekly period
Monthly period

1.3 Collect performance data with ALU solution (1/2)
WMS
Observation files
Directory
OBS OBS
Main
Server
Observation
file containing
OBS
counters
WIRELINE BACKBONE
Every
15 OBS
minutes Every
RNC 60
minutes
The equipment resets

the counters and BTS
starts incrementing
the counters

Observation counter binary files are transferred every 15 or 60 minutes period to the WMS Server where
they are converted into XML files and stored in a temporary directory.

1.3 Collect performance data with ALU solution [cont.]
WMS
Observation files
Directory
Main OBS OBS

Server
LAN
NPO HMI
Server of Clients
NPO Server
Citrix Server
VPN / Internet
NPO Client
Citrix Client

The NPO server looks permanently if some new observation counter files have been transferred into the
WMS sever. It then transfers these files and stores the new counter values into the NPO Oracle
database. It also computes the defined Stored Indicators and stores their values in the same database.
Any NPO user can display Stored and Calculated Indicators values from a NPO Client or a Citrix Client
accessing the NPO server through an intermediate HMI Server of Clients acting as a Citrix server too.

1.5 Counter file storage
/opt/nortel/data/access/observation
XML DTD (Document Type
32.104 -01.dtd
Definition) available
YYYYMMDD/<NE>
on WMS, compliant with
3GPP
<single -period obs file name>
<hourly aggregated o bs file name>

Tree Structure generic
example
<daily aggregated obs file name>
20020613/ RNC-RNC14_CN
A20010613.1800+0100 -1815+0100_ RNC-RNC14_CN

RNC C-Node example,
A20010613.1815+0100 -1830+0100_ RNC-RNC14_CN quarter hour
A20010613.1830+0100 -1845+0100_ RNC-RNC14_CN
observation files
A20010613.1845+0100 -1900+0100_ RNC-RNC14_CN

RNC C-Node example,
h20010613.1800+0100 -1900+0100_ RNC-RNC14_CN hour and daily
d20010613.0000+0100 -0000+0100_ RNC-RNC14_CN observation files
20020613/BTSEq -XXXX070
BTS Counters example,
A20010613.1800+0100 -1900+0100_ BTSEq -XXXX070
hourly observation files
h20010613.1800+0100 -1900+0100_ BTSEq -XXXX070
d20010613.0000+0100 -0000+0100_ BTSEq -XXXX070

The data is organised in the following Performance Server directories:

BTS Counters - /opt/nortel/data/access/observation/<YYYYMMDD>/BTSEq-<neName>
RNC C-Node Counters - /opt/nortel/data/access/observation/<YYYYMMDD>/<neName>_CN
Passport Platform Counters
RNC I-Node - /opt/nortel/data/access/observation/<YYYYMMDD>/<neName>_IN

1.6 NPO introduction to UTRAN monitoring
W-NPO MS-NPO MS-Portal

(OAM06) client
Customer NMS MS-OMC
MS-SUP MS-NPO
2G OMC-R WMS
WMS W-NPO
Integrated into UTRAN program Integrated into MS-OMC

Mono ROC Multi ROC
Mono technology Multi Technology


2 Counters properties and Analysis


2.1 Counter groups and families
Alcatel-Lucent groups the Access Network observation in 3 major

groups:
C-Node Application Counters RNC counters
Node-B Counters BTS counters

I-Node Platform Counters MSS Counters
•RNC C-Node counters – To monitor the UMTS features & functionalities at the
RNC
• BTS counters – To monitor the UMTS functionalities and Node-B platform
• RNC MSS counters – To monitor the RNC platform and the ATM layer


2.1 Counters groups and families
2.1.1 RNC Counter families
The counter groups are further divided into families according to a given UMTS feature or to a
Performance Management purpose
RNC C-Node counters families

Radio Measurement Primary Cell Change Reserved Counters Family
IRAT PS (Cell Change Order) RAB Release Abnormal Iu Connection Release
HSUPA - CAC RAB Release Normal Location Service
QOS Performance RAB Attempt SHO - RL Addition (UE side)
UE State Transition RAB Success Platform
User Plane Common Traffic RB Setup Power Management
HHO Inter Frequency Inc - without Iur RB Reconfiguration RRC Connection Release
IRAT LTE HO PS Inc (4G3G) MBMS UE Average per State
HHO Inter Frequency Out - Inter PLMN RB Release Handover Counters With Mixed
Radio Link Setup RAB Failure Screenings Family
Radio Link Addition RAB Modification PS RRC Connection Re-Establishment
Radio Link Deletion RAB Multiple Establishment / Release SABP
Radio Link Reconfiguration RAB Negotiation on Establishment Call Establishment Duration
HHO Inter Frequency Out - without Iur HHO Inter Frequency Out - Intra RNC (RL Setup) Security
SCCP HHO Inter Frequency Inc - Intra RNC Cell Unavailability
SRNS Relocation Out HHO Inter Frequency Out (RL Setup) Paging
SRNS Relocation Inc Transport Cell / URA Update
IRAT HO CS Out - WPS HHO Inter Frequency Inc HSDPA - CAC
User Plane Dedicated Traffic HHO Inter Frequency Out (RB Reconfiguration)
Cell Inactivity IRAT HO Emergency Call Out (ECIHO)
RRC Connection Establishment IRAT HO CS Inc (2g3g)
IRAT HO CS Out (3g2g) IRAT HO CS Out - Directed Retry
Data Rate Modification IRAT HO CS Out - Next Best Cell
Radio Link Failure Indication SHO - RL Average (SHO Overhead)
Transport Channel Format User Perceived Throughput
Reconfiguration RAB Cancel
RAB Modification / AMR Rate HSDPA / EDCH Cell (Change / Mobility)
RAB Traffic

2.1 Counters groups and families
2.1.2 NodeB and MSS Counter families
The counter groups are further divided into families according to a given UMTS feature or to a
Performance Management purpose
NodeB counters families MSS counters families

PCM statistics ACCOUNT ATM Vcc
ATM statistics ACCOUNT ATM Vpc
Radio statistics ATM port
CallP counters Logical Processor Use
EEC Adjunct Processor Stats
IMA statistics GigabitEthernet
IP statistics
HSDPA statistics
HSUPA statistics
(spares)
Synchronization statistics


2.2 Cumulative Counter Type
Cumulative Counter (CC)

• A cumulative counter provides raw counts of events.
• Is incremented each time the counted event occurs.
E = triggering Event
Xi = registered measurement sample
E E E E E E E
GP X1 X2 X3 X4 X5 X6 Xi GP ends
begins
Granularity Period
Counter.Cum= ∑GP Xi


2.2 Cumulative Counter Type
2.2.1 Example
Cumulative Counter Example

#403.0 RRC.SuccConnEstab.OrigConvCall provides the number of
successful RRC connection establishments when the establishment
cause is Originated Conversational Call
E = triggering Event = Reception by the RNC of a RRC CONNECTION

SETUP COMPLETE message

E E E E E E E
GP X1 X2 X3 X4 X5 X6 Xi GP ends
begins
Granularity Period
Counter.Cum= ∑GP Xi


2.3 Value Counter Type
Value Counter (DER - Discrete Event Registration)

• These counters provide the average values from raw counts base on
internal events.
• The time interval between two events is random and is not

accessible to users
•
• A value counter is incremented by a value attached to the event
itself.
• Each Value counter provides:

Cumulated value
Number of events
Minimum value
Maximum value
Averaged value - computed using the cumulated value divided by
the number of events


2.3 Value Counter Type
2.3.1 Example
DER counter example

#303 VS.UplinkRssi provides the uplink RSSI per cell during a reporting
period
E = triggering Event = The Uplink RSSI is updated on each reception on a NBAP
common measurement containing an uplink RSSI measurement
E E E E E E E
GP X1 X2 X3 X4 X5 Xi XN
begins
Granularity Period
Counter.Cum = ∑GP Xi Counter.Min = MinGP(Xi)
Counter.Nbevt = N Counter.Max = MaxGP(Xi)
Counter.Avg = Counter.Cum / Counter.Nbevt


2.4 Load Counter Type
Load Counter (SI – Status Inspection)

• These counters provide average values from raw counts obtained by internal
sampling
• The time interval between two events is constant and is not accessible to
users
• The counter is incremented by a sampled value on the sampling event
occurrence (every 100ms). Data related to the mean value is captured every
nth sampling, where n can be 1 or larger Start End
• Each counter provides:
Cumulated value
Number of events
Minimum value
Maximum value
Averaged value - computed using the
cumulated value divided by the number of events


2.4.1 Example
Load Counter (SI – Status Inspection) example

#52.2 VS.RadioLinkEstablishedPerCell.CsSpeech provides the average,
min and max number of NBAP Radio Links simultaneously established in
a cell
Event Ea = setup of radio link(s) Event Eb = addition of a radio link(s)
Event Ec = deletion of a radio link(s)
Xi = number of Radio Links simultaneously established
Ec T T Eb Ea Ea T
GP X1 X2 X3 X4 Xi Xn-1 Xn
begins GP ends
Granularity Period

Only VS.RadioLinkEstablishedPerCell .Avg, .Min, .Max

are meaningful but .Cum and .Nbevt are also computed for Aggregation of metrics

2.4.1 Example [cont.]
Counter #52.2 VS.RadioLinkEstablishedPerCell.CS speech

RL established (user service=Speech only)
RL addition (2RL) RL deletion (1RL)
RL setup (1RL)
6
4 T
Granularity Period
time
Xi = 3 4 4 4 6 6 6 6 6 5 5 5 5 5 5
#33.Nbevt = 15 #33.Min = 3
#33.Cumul = 75 #33.Max = 6
#33.Avg = #13.Cumul / #13.Nbevt = 75/15 = 5


2.5 RNC C-Node counter object instances
Any Cell
when controlled by this RNC
Reference Cell = Primary cell

when controlled by this RNC
Remote Cell = Primary cell

when controlled by another RNC


2.6 RNC and “Any Cell” object instances for C-Node counters
MSC
RNC counter
• A “RNC” counter is incremented at RNC
level when an event occurs on the Iu-CS Iu-CS
serving RNC of a connection.

Ex: VS.IuSccpCnxSuccess.CsReqByRNC providing the
Serving Drift
number of successful SCCP connections requested by RNC Iur RNC
the RNC on the Iu CS interface
Any Cell counter

• A “Any Cell” counter is incremented at
CELL level for each FddCell of the
serving RNC on which the mobile is
connected to, when the event occurs.
Ex:
VS.RadioLinkSetupUnsuccess.RadioLinkSetupFailure
providing the number of NBAP RL Setup that fail to
be established due to a Radio Link Setup Failure
message received from the Node-B

2.6 RNC and “Any Cell” object instances for C-Node counters
2.6.1 Example: Any Cell counter of RNC acting as a DRNC
Serving RNC RNSAP / RADIO LINK SETUP REQUEST Drift RNC
RNSAP / RADIO LINK SETUP FAILURE
RNSAP / RADIO LINK SETUP RESPONSE

Iur
RLM.AttRLSetupIur.CS - #64
RLM.FailRLSetupIur.CS.Resource - #1380
RLM.SuccRLSetupIur.CS - #1381
The call is handled by the serving RNC. When an UE attempts a voice call for example, some counters are
incremented on the FDDCell and the RNC layer. This already available in UA6.0.
You should notice here that these new counters are pegged on the reception / transmission of the RNSAP
messages on the DRIFT RNC.

2.7 Reference Cell object instance for C-Node counters
Reference Cell counter

• A “ Reference Cell” counter is
incremented at CELL level only for the
FddCell identified as the Primary Cell of Serving
Iur
Drift
RNC RNC
the connection when the event occurs.
• Such a counter is only incremented if this
Primary Cell belongs to the Serving RNC of
the connection which is the RNC pegging
this counter.
Ex: VS.RAB.Drop.PS.CsIratHo providing the number of
Dropped PS RAB connections due to successful CS IRAT
HO for a UE for which this cell is acting as the Primary
Cell and this cell is under the SRNC


2.7 Reference Cell object instance for C-Node counters
2.7.1 Example – Reference Cell counter of RNC1
RNC1 RNC2 = Neighbour RNC of RNC1
Iur
RNC1 does control Serving Drift

Primary Cell RNC RNC
FDDCell A1
VS.RAB.Drop.PS.CsIratHo - #2680

Reference Cell Counters
The Reference Cell counter is incremented only on the primary cell if this primary cell is under the
Serving RNC.
The counter is incremented only once even if the UE has more than one cell in its active set. Unlike the
Fddcell counter that will be incremented in all the cells in the active Set.
In the example above, #2680 is a reference cell counter. When the event occurred, only the counter #2680
of the left cell in the serving RNC was incremented.

2.8 Neighbouring RNC object instance for C-Node counters
Neighbouring RNC counter MSC
• A “Neighbouring RNC” counter is incremented

at NEIGHBOUR RNC when: Iu-CS
The event should be counted on a Drift-RNC

Ex: VS.IurSccpCnxSuccess.EstablishedAsDriftRnc
Serving Drift
providing the number of successfully established RNC
Iur
RNC
SCCP connections when a neighboring RNC serves
as a Drift.
The event should be counted on the
Reference Cell only and the Primary Cell of
the Active Set is controlled by a Drift-RNC
Ex: VS.RAB.Drop.PS.CsIratHo.NeighbRnc providing
Dropped PS RAB connections due to successful CS
IRAT HO for a UE having its Primary Cell under a Drift
RNC which is this Neighbor RNC of the Serving RNC
pegging this counter.


2.8 Neighbouring RNC object instance for C-Node counters
2.8.1 Example – Neighbouring RNC counter of RNC1
RNC3 = Neighbour RNC of RNC1 Serving
RNC
Iur
Iur
Drift
RNC
NeighbourRNC2
RNC1 does not control

Primary Cell
FDDCell B1
VS.RAB.Drop.PS.CsIratHo.NeighbRnc - #2681

Neighbouring RNC Counters
The Neighbouring RNC counter is incremented on the serving RNC only if the primary cell is under the Drift
RNC.
The counter is incremented only once even if the UE has more than one cell in its active set. Unlike the
Fddcell counter that will be incremented in all the cells in the active Set.
In the example above, #2680 is a reference cell counter, #2681 is a Neighbouring RNC counter. When the
event occurred, because the primary cell in under the Drift RNC, only the counter #2681 under the serving
RNC was incremented.
The same counter #2681 will be incremented regardless the cell of the DRNC.

2.9 Remote Cell object instance for C-Node counters
Remote Cell counter MSC
• A “Remote Cell” counter is

incremented at CELL level when: Iu-CS
The event is to be counted on the

Reference Cell only but the Primary
Serving Drift
Cell of the Active Set is controlled by a RNC
Iur
RNC
Drift-RNC
Ex: VS.RAB.Drop.PS.CsIratHo.RmtCell
providing the number of Dropped PS RAB
connections due to successful CS IRAT HO
for a UE having its Primary Cell under a Drift
RNC which is this Neighbor RNC of the
Serving RNC pegging this counter.


2.9 Remote Cell object instance for C-Node counters
2.9.1 Example – Remote Cell counter of RNC1
Serving RNC Drift RNC
Iur
RNC1 does peg NeighbourRNC2

Remote Cell counter
for Primary Cell B1
which it does not control
VS.RAB.Drop.PS.CsIratHo.RmtCell - #2557

This feature aims to have some of the Reference FddCell counters pegged when triggering events occur on
a RNC different than the controlling RNC.
In UA06, counters pegged at Reference FddCell level, always excludes the events that occur when a given
cell is the primary cell of the connection but the S-RNC is not the Controlling RNC (during SHO via Iur).
So in UA7.1 This feature introduces a new counter location that is pegged by the SRNC. The new location is
referred to as the Remote UTRAN Cell (or RemoteUtranCell) location. This new location is the equivalent of
the Reference Cell location but for the cell that is controlled by the DRNC.
FEATURE VALUE
Increased accuracy of the cell level metrics during SHO via Iur

2.10 NPO Aggregation per couple (Remote Cell, RNC)
The new aggregation path is equal to:

[ REMOTECELL3G , RNC] => [Cell 21 served by RNC1, all Cell 2x served by RNC1]
RNC RNC RNC

1 Iur 2 Iur 3
Cell Cell Cell Cell Cell Cell

11 12 21 22 31 32

34 | Presentation Performance
Title | Month 2009
There can be three types of possible indicator analysis using the new Drnc Cell Counters
Analysis per couple (RNC ⇔ remoteUtranCell)
The objective is to be able to monitor events that occurred on cell(s) located on another RNC for calls
served by the current RNC.
Example: events that occurred on cell 21 when calls were served by RNC 1.
The aggregation in this case can be done :

On all REMOTECELL3G cells of a given RNC , the aggregated value is available on the RNC .The new
aggregation path is equal to [ REMOTECELL3G , RNC]

2.11 NPO Aggregation per Cell

[ REMOTECELL3G , REMOTECELL3G_ECELL(target), CELL3G, RNC]
Cell 21 => Cell 21 as remote on any NRNC + Cell 21 as local on RNC2
RNC RNC RNC RNC

1 Iur 2 Iur 3 2
Cell Cell Cell Cell Cell Cell Cell Cell

11 12 21 22 31 32 21 22

Title | Month 2009
Analysis per cell

The objective is to be able to monitor events that occurred on a cell both for calls served by its parent RNC
(in that case the cell is a local cell) or for calls served by neighboring RNCs
Example: events that occurred on cell 21 when calls were served by neighboring RNCs 1 and 3 and when
calls were served by RNC 2.
Indicator(Cell 21) = ΣC1(any RNC, remoteUtranCell 21) + ΣC2(RNC 2, Cell 21)
The new aggregation path is equal to [ REMOTECELL3G , REMOTECELL3G_ECELL(target), CELL3G, RNC]

2.12 NPO Aggregation per RNC

[ REMOTECELL3G , REMOTECELL3G_ECELL(target), CELL3G, RNC]
RNC2 => Any cell under RNC2 as remote for NRNC + any local cell for RNC2
RNC RNC RNC RNC

1 Iur 2 Iur 3 2
Cell Cell Cell Cell Cell Cell Cell Cell

11 12 21 22 31 32 21 22

Title | Month 2009
Analysis per RNC (all the cells of the RNC)

The objective is to be able to monitor events that occurred on cells of a RNC for calls served by this RNC or
for calls served by neighboring RNCs
Example: events that occurred on cells of RNC 2 when calls were served by neighboring RNCs 1 and 3 and
when calls were served by RNC 2.
Indicator(RNC 2) = ΣC1(any RNC, any remoteUtranCell below RNC2) + ΣC2(RNC 2,any local Cell)
The new aggregation path is equal to [ REMOTECELL3G , REMOTECELL3G_ECELL(target), CELL3G, RNC]

2.13 BTS counter object instances


2.14 MSS counter families and object instances


2.15 Counter Screenings
Most of Alcatel-Lucent counters provide measurements at a very

detailed level
Counters are broken down into sub-counters (referred in Alcatel-Lucent
nomenclature as counter screenings)
Examples of counter screenings are:
Split per failure reason of counters providing number of failures (number of
drops, procedure failures, etc …)
Split per establishment cause (ex. RRC Connection Establishment counters)
Split per service type, DL bit rate, UL bit rate, HSDPA, RAB type, etc.
Split per domain (CS, PS)
Split per 3GPP cause value (provided in Information Elements of exchanged
signalling)
…
If screenings are defined for a counter, it is the sub-counters which are
produced by the RNC and reported in the observation files.
Most commonly used Screenings are provided in Tables in the RNC

Counter Catalogue

Main screenings:
1. Uplink Traffic Counter Screenings
2. Downlink Traffic Counter Screenings
3. DlRbSetId,UlRbSetId,TrafficClass derived screening per granted Rab
4. Target type of call for Radio Link Reconfiguration
5. Source Type of call release mapping
6. Derived AsConf Screening for PS DlAsConfId
7. Derived AsConf Screening for CS DlAsConfId
8. Derived AsConf Screening for DlAsConfId Avg Nbr Estab
9. Derived AsConf Screening for UlAsConfId Avg Nbr Estab
10. Type of call for dropped last radio link
11. Target Type of call setup mapping
12. Target type of call for Radio Bearer Reconfiguration
13. Traffic Class Combined UL and DL RbSetIds (COMB UL DL RBSET) .
The List of available screenings is given in the appendix.

3 Metrics properties and Analysis


3.1 Metrics Definitions
Metric = f (counter1, counter2, …)
A formula composed of one or several counters.

For instance: ∑ RRC.SuccConnEstab [RRC screenings]
• Metric definitions may include counter screening such as voice, video, or

data.
• Some counters screened by As Conf Id (DL or UL), or RRC establishment
causes.
• Other counters are provided with screening details.
In NPO a Metric is called an QoS Indicator

To interpret data coming from the counters, it is necessary to define some metrics.
A metric is composed of one or several counters.
These counters can be screened for some specific metrics:
Counters screened by As Conf Id (DL or UL), or RRC establishment causes.
The screening is detailed in the appendix.
Other counters with screening details.
The screening value used in the metric is directly set with the counter.
Note that if no screening details are given (no brackets), all screenings of the counter must be used
for the metric.
The screening is identified as followed:
Downlink As Conf Id = DL_AsConfId_Screenings (screened by SRB, CS, PS, Combined, PS 8, PS 32, PS
64, PS 128, PS 256, PS 384, CS 14.4, CS 57.6, CS 64, Voice)
Uplink As Conf Id = UL_AsConfId_Screenings
RRC release = RRC_Release_Screenings (specific screening for RRC Failures)
RRC establishment causes = RRC_Screenings (screened by Call, CS, PS, Identification)
RAB = RAB_Screenings (screened by CS, PS)

3.2 Metrics Generic Formulas
Legend
PM Counter Request Counter:
Request
Calculated Indicator
Success Failure
Counter: Indicator: Request – Success
Success
Success Rate Failure Rate
Indicator: Success/request Indicator: Failure / request

Number of requests = PM counter

Number of successes = PM counter
Success rate = Successes / Requests

Number of failures = Requests - Successes
Failure rate = Failures / Requests
Ratio for Sub-group X (e.g. a cause X among a set of causes [0..N])

Calculated as: Number of events with X / Number of events with [0..N]

4 Generating Reports and Analysis


4.1 RNC Counter Volume Control
Measured
Name Object Is Activated
From UA7 Class
the selection RRC.AttConnEstab Cell Y
is possible (…) (…) (…)
at SCREENING level VS.IrmUpgradingCommand Cell N
(…) (…) (…)
VS.RadioBearerEstablishmentUnsuccess Cell Y
VS.RadioBearerReconfigFailure Cell Y
VS.RadioBearerReconfigurationSuccess Cell Y
VS.RadioBearerReconfigurationUnsuccess Cell Y
Operator A Operator B
Measured Object Measured Object

Name Is Activated Name Is Activated
Class Class
RRC.AttConnEstab Cell Y RRC.AttConnEstab Cell Y

(…) (…) (…) (…) (…) (…)
VS.IrmUpgradingCommand Cell N VS.IrmUpgradingCommand Cell N
(…) (…) (…) (…) (…) (…)
VS.RadioBearerEstablishmentUnsuccess Cell Y VS.RadioBearerEstablishmentUnsuccess Cell Y
VS.RadioBearerReconfigFailure Cell N VS.RadioBearerReconfigFailure Cell Y
VS.RadioBearerReconfigurationSuccess Cell N VS.RadioBearerReconfigurationSuccess Cell Y
VS.RadioBearerReconfigurationUnsuccess Cell N VS.RadioBearerReconfigurationUnsuccess Cell Y

From UA06, the RNC starts to apply limits on the maximum number of configurable C-Node counters at
cell level.
The limit values are:
RNC w/ PSFP1/CP3 or DCPS/CP4 4.75 Million Cell Counters
RNC w/ DCPS/CP4 9.5 Million Cell Counters
This value corresponds to approximately 3958 PM counter screenings at cell level for an RNC configured
with the maximum supported number of cells.
Objectives of the feature:
Maintain the RNC counter volume under controlled limits
Allow the operator to customize the counter lists:
Non required counters can be turned OFF
Allow the introduction of new RNC counters in future releases
To control the volume of active counters the user can edit / modify the RNC counter list.
Counter List Management only applies for RNC C-Node families of counters
The Counter List modification can be applied “On-line” without impact on service.
The modification of the list is assumed by the RNC for the third collection period after the change is
applied
Maximum Volume of Counters Supported By the RNC
The RNC applies automatic defense mechanisms when the maximum supported volume of cell
counters is exceeded (only for C-Node families)
Note: In UA06 there are not enough RNC C-Node defined counters to make the limits to be exceeded.

4.2 Indicator Aggregation
Object aggregation is needed for:

• RNC level metric based on FDDCell counters
• Network level metric
Time aggregation is needed:
• when Observation Period of the metric is bigger than
the Granularity Period of the counters used
Observation Period = 1 day
GP = 15mn
Start CV1 CV2 CV3 CVi CV96
CV: Counter Value
See comments below

The following rules shall be followed for time aggregation.

Rtotal is the rule applied to CC counters:
CV.cum = CV1.cum + CV2.cum + …+ CVn.cum
Rload / Rval is the set of rules appled to SI and DER counters
CV.cum = CV1.cum + … + CVn.cum
CV.nbevt = CV1.nbevt + … + CVn.nbevt
CV.avg = (CV1.cum + .. + CVn.cum) / (CV1.nbevt + .. +CV2.nbevt)
CV.min = min (CV1.min, .., CVn.min)
CV.maCV = maCV (CV1.max, .., CVn.max)

4.3 Report Definition
A report is a set of metrics.

Report can be from high level to a low level to help investigate/analyze from
general to specific
e.g. network level report -> RNC level report -> FddCell level report
Some reports are pre-defined, others are created/customized by the user.
Types of reports:
Evolution report
Top N report
Warning reports
Alcatel-Lucent proposes pre-defined reports
In NPO a QoS Report is a set of QoS Views

each view contains a set of QoS Indicators

A report consists of a set of metrics going from a high level view to a low level (from a network view
to a network element view, i.e. Network -> RNC -> Fddcell):
Set of reports at executive level.
Detailed reports (evolution and top N reports).
Reports based on alarm generation.
The format of the report is a graph or a table.
In order to be efficient it’s recommendable to name the reports with prefixes that indicates what
level they are referring to (RNC, fddcell) followed by the report name.
Several types of reports can be used:

Evolution report: the objective of the evolution reports is to show and compare the statistics
related to a set of NEs, over a period of time.
Top N report: the objective of top N reports is to filter the N worst (or best) NEs according to a
specific criterion. Such reports are run over a set of NEs and for a single date.
Alarm detection report: every report can be complemented with reports coming from alarm
detection based on thresholds.

4.3.1 Generate a report on NPO
Click
Drag and Drop
Drag and Drop


4.3.2 Key Performance Indicators
ALU definition:
Provides a measurement of interest to the Top Management
Measures the performance at network or sub-network level
Weekly
Example: indicator Call Drop Rate.CDR “UMTS"
3,50%
3,00%
2,50%
weekly call drop rate
2,00%
CDR
contractual call drop rate

1,50%
quality CDR
1,00%
0,50%
0,00%
1
5
9
13
17
21
25
29
33
37
45
41
week number

Measure the performance of the complete network

Analyzed according their trend and values
Usually every day (week, month)
Compared with:
Competitor results if available
Contractual requirements
Internal quality requirements
The Call Drop rate at network level has to be compared to:

Contractual threshold: can be requested by the operator management to the operational radio team,
can be requested by the operator to the provider on swap or network installation
Quality threshold: fixed internally by radio team management.
Quality thresholds are usually more tight than contractual ones.

4.3.3 Network Key Performance Indicators
TRAINING EXERCISE: KPI OR NOT
INDICATOR DESCRIPTION KPI ?

average of call setup success rate for the network Yes
Percentage of calls lost due to radio problem on cell CI=14, LAC=234 No
call drop rate in your capital yes
call drop rate of the cell covering a specific building ?
% of users in Soft HO for the network yes

average rate of paging discarded for all the RNCs yes
% of Cell_DCH to cell_FACH transition in hot spot zone n
call success of 1 PLMN y
% of cells being congested today y/n


4.3.4 Counter based KPIs
Network Network
Mobility Retainability
Network Network
Accessibility Quality
Counter
based KPIs
RRM Capacity/
Load
HSxPA Call Profile
Network Network
Congestion Traffic
Will be developed in next chapters

4.3.5 Methodological precautions
METHODOLOGICAL PRECAUTIONS
Avoid typical errors regarding indicators interpretation


4.3.6 KPI value
A good value for a KPI indicator

⇓
All network components are OK regarding this indicator
Example
A global call drop rate of 1%
Can hide some cells with 10 % of call drop rate


4.3.7 Network Element aggregation
number of calls number of call drop call drop rate

cell 1 390 8 2,10%
cell 2 546 29 5,25%
cell 3 637 20 3,10%
cell 4 1029 12 1,14%
cell 5 536 3 0,50%
cell 6 2 1 50,00%
cell 7 3 1 33,00%
cell 8 210 4 2,11%
cell 9 432 5 1,20%
cell 10 321 4 1,11%
average of cell results 9,95%

total nb of drop/total number of calls 2,10%
THE AVERAGE VALUE OF AN INDICATOR FOR A NETWORK

IS NOT THE AVERAGE OF CELL RESULTS (or any sub-part of it)
BUT THE AVERAGE WEIGHTED BY THE TRAFFIC


4.3.8 With other indicators
Total Call Drop Rate
70, 0%
60, 0%
50, 0%
40, 0% % CS call drop
30, 0% % PS call drop
20, 0%
10, 0%
0, 0%
25-05-
26-05-
27-05-
28-05-
29-05-
30-05-
31-05-
01-06-
02-06-
03-06-
04-06-
05-06-
06-06-
07-06-
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
Percentage of calls dropped due to RL failure
70,0%
60,0%
50,0%
40,0% % CS call drop
% PS call drop
30,0%
20,0%
10,0%
0,0%
26-05-
27-05-
31-05-
04-06-
05-06-
25-05-
28-05-
29-05-
30-05-
01-06-
02-06-
03-06-
06-06-
07-06-
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005

4.3.9 With alarms
PRACH reception in Cell

90 5
80 4,5
70 4
3,5
60 PRACH fail
3
50 PRACH succ
2,5
40 % PRACH fail
2
30
1,5
?
20 1
10 0,5


4.3.10 With parameters modification
QoS degradation after parameter change
Reference New set

100% 60000
99% 50000
98%
40000
97%
30000
96%
20000
95%
94% 10000
93% 0
05
05
05
05
05
05
05
05
05
20
20
20
20
20
20
20
20
20
2/
4/
0/
6/
8/
0/
2/
4/
6/
/0
/0
/3
/0
/0
/1
/1
/1
/1
07
07
06
07
07
07
07
07
07
AMR calls % CSSR


5 Real Time Counters


5.1 Overview
Real Time Counters:

Real Time Monitoring of a part of the network
Real Time Monitoring for a given period of time

Title | Month 2009
This feature is used to enhance the operational effectiveness of the Access solution. It is
used in conjunction with GPO (permanent) counters to permit the troubleshooting and
real time monitoring of Part of the Network.
The main use cases that can be addressed by this feature are:
Follow system behavior over a sub-set of cells during special events (max 120
cells/RNC)
Verify performance after a parameter changes or a new site introduction.
Quickly verify RNC performance after a software/release upgrade.
This cannot be achieved through existing “permanent observation” counters.

5.2 Real Time PM versus Legacy PM
End-to- Spatial
Granularity Scope Counters/
End
Period metrics
Latency (cells)
General
Permanent 15-60min
~30min All Network All
Observation (default=15)
(GPO)
Real Time 1-5min Part of

Observation <2min Subset
(default=3) Network
(RTO)

Title | Month 2009
Granularity Period :
The readiness of the counter files on the Network element (RNC r NodeB). For GPOs it is
15 minutes (For the RNC & a part of the nodeB) or 60 minutes for some Nodeb counters.
For The RTO it is around 1-5 minutes. The RNC closes the counter files each 5 minutes.
End-to-End Latency :
The counters are then transferred to the Main server processed to generate an XML file.
For GPO, the FTP to the main server and the XML convertion needs 15 minutes then the
FTP to NPO plus the processing (Normalisation, …) needs 15 more minutes. This leads us
to 30 minutes.
For the RTO this takes few minutes.

5.3 Real time Performance Monitoring Application
Real Time Performance Monitoring

PM metrics variation monitoring in real
time
Pre-defined list of metrics:
On max 120 cells per RNC
on some NEs
Graphical User Interface

RT counters configuration
RT Counters activation
Results Monitoring
Monitoring Dashboard

Real Time Performance Monitoring Framework

Ability for user to visualize PM metrics variation in real time
User Selection:
Pre-defined list of metrics:
Call Attempts Total, CS & PS; Successful Call Setups Total, CS & PS
Call Setup Success Rate Total, CS & PS; Drop Calls Total, CS & PS
Drop Call Rate Total, CS & PS; Total Traffic, CS & PS (Erlang)
On max 120 cells per RNC
on some NEs
Granularity: 3 minutes
Display Latency: around 1 minute
Graphical User Interface

For configuration and activation
To display the collected results
Tabular Monitoring Dashboard
Graphical Display :
Time Graph/ Summary

5.4 Real Time Metrics
Metric Name Domain

Call Attempts CS,PS,CS+PS
Successful Call Setups CS,PS,CS+PS

Call Setup Success Rate CS,PS,CS+PS
Drop Calls CS,PS,CS+PS
Drop Call Rate CS,PS,CS+PS
Total Traffic CS,PS,CS+PS

Title | Month 2009
The list of metrics to be monitored in real time is predefined, i.e. pre-configured by

default in OAM/RTA and cannot be modified.

6 Alcatel-Lucent Call Trace Solution
Overview


6 Alcatel-Lucent Call Trace Solution Overview
6.1 Introduction
Call Trace is a very powerful feature that allows the collection of

very detailed information on:
One or more mobiles
One or more cells
Network Interfaces
Other network elements and internal procedures
Call Trace can be seen as a probe embedded inside the RNC and therefore is
not limited to the data that can be collected by network probes monitoring the
accessible external network interfaces (Iub, Iur, Iu-CS, Iu-PS,…)


6.2 Call Trace Session Types : Trace a UE
Call Trace Solution comprises several types of traces:
Core Network Invoked Call Trace - CTa

To trace one or several UE calls selected by the Core Network - UE call is traced in
a RNS if a RANAP CN_INVOKE_TRACE message is received on a SCCP connection
dedicated to the UE on Iu interface
To trace UE emergency calls - If a RRC connection request received in the RNC
with the cause “Emergency Call” will be traced by the RNC as a CTa session,
without waiting the Core Network trigger
Access Invoked Call Trace – CTb

A Call Trace B session provides data related to all calls initiated for a specified UE
during the session activation
The UE identity specified at the OMC-R when creating a CTb session may be one of
all choices of the “Initial UE identity” IE supported by the RRC protocol listed
below:
TMSI
P-TMSI
IMSI
IMEI
There is one and only one UE traced in a CTb session.

Possibility to run simultaneously all sessions types

Tracing sessions may have a very significant impact on RNC resources (CPU and occupied disk space).
Up to UA05/UA5.1 the following restrictions apply (per RNC):
CTg and CTn trace sessions are mutually exclusive
OT-Cell and CTn trace sessions are mutually exclusive
In UA06 these restrictions are dropped.
In order to limit the impact on RNC capacity and performance a new controlling mechanism is put in
place:
A weight is associated to each tracing session created on the RNC
For the CTg session, the weight depends on the configuration of the session (i.e. functions and sub-
functions associated and tracing mode chosen).
The RNC will be able to dynamically evaluate the total tracing weight value by summing the weights
of all the active sessions
The capacity limitations of the CTg session (number of simultaneously traced calls per TMU) will be
automatically adjusted depending on the total CT weight

6.3 Call Trace Session Types : Trace traffic in a group of cells
Geographic Call Trace – CTg

To trace the calls established within a geographical area in the UTRAN
(may be a cell, a set of cells or all the cells in the RNS)
From UA05 calls to be traced can be filtered based on the RRC
Establishment Cause (i.e., user can for instance decide to trace only the
mobile originated calls with RRC Establishment Cause “Originated
Background Call”)
Traced calls can be filtered based on their IMEI (the remaining will be wild
cards). This allows grouping traces based according to the UE type which
can be useful for troubleshooting purposes. Ie. when a certain UE model is
known to be introducing problems in the network.
CTg sessions can be configured with Call Failure (CTg Drop or Call drop in a
CTg covered area) Snapshots triggered by a predefined list of events that
can occur on the RNC leading to a call drop. The snapshots will provide
the description of this event together with other information associated
with the failed call.

Periodic RRC Measurements in CTg and CTb

With the introduction of event-triggered mode for reporting the UE RRC measurements, some RF
environment measurements (such as the Cpich Ec/N0, Cpich RSCP) are not periodically reported by the
UE in CELL_DCH to the RNC. This information is sometimes useful for Network Monitoring and Remote
Optimization purposes.
Since UA05, the user can already configure the CTb and CTg sessions to include periodic RRC quality
measurements (DL RLC BLER).
The user is allowed to configure calls being traced by CTb and CTg to include the following new RRC
periodic measurements:
Intra-Frequency (providing the “CPICH Ec/N0” and “CPICH RSCP”)
UE Internal (providing “UE Transmitted Power” and “UE Rx-Tx Time Difference”).
The reported Ec/N0 value for the detected cells is also logged to the Detected Cell records.
This information is used by WQA Neighbouring Tuning Module, allowing to filter out the cells for which
the reported Ec/N0 is below a specific threshold (non suitable for neighbour declaration).

6.4 Call Trace Session Types : Trace Common NBAP, Mobility
Object Trace on the cell object – OTCell

To trace data related to a cell or several cells (i.e. NBAP common)
As example, this trace session is useful to obtain detailed cell level
measurements on:
Transmitted Carrier Power
UL RSSI
Neighbouring Call Trace – CTn (from UA05)

To trace mobility specific events:
SRNC relocation
Incoming and outgoing HHO to 2G network
Radio link setup / addition, deletion
HO failed (with failure cause)
Relocation failed (with failure cause)
HSDPA mobility
Change of Primary Cell
Detected cells (missing neighbours)
…

Addition of a Ec/No for the Detected Cells in CTn Records

Prior to UA6.0, the detected cell ids were collected in a specific CTn data block:
“CTN_DECTECTED_CELL_REPORT”
This information is used by the WQA Neighbouring Tuning Module to identify possible missing
neighbours.
In UA06, the reported Ec/N0 value for the detected cells is also logged to the Detected Cell records.
This information is used by WQA Neighbouring Tuning Module, allowing to filter out the cells for which
the reported Ec/N0 is below a specific threshold (non suitable for neighbour declaration).

6.5 Call Trace Session Types : Trace Iu interfaces
Object Trace on IuCs object – OTIuCs

To trace common Iu CS data (i.e. not linked to a given call) - RANAP
messages on Iu Cs interface.
Object Trace on IuPs object – OTIuPs

To trace common Iu PS data (i.e. not linked to a given call) - RANAP
messages on Iu Ps interface.
Object Trace on IuR object – OTIuR (from UA05)

To trace common Iur data (i.e. not linked to a given call) - RNSAP
messages on Iur interface.
Object Trace on IuBC object – OTIuBC (from UA05)

To trace common (i.e. not linked to a given call) SABP messages on IuBC
interface.


6.6 Configuring a Call Trace Session
Cell, Geographical Sessions
Parameters
Session
Creation mode
Access Session

Data Collected in the Trace Sessions
The data provided by the Network Elements is organized into different traced Functions and Sub-
Functions.
Each traced Function / Sub-Function provides information on a particular aspect of the Call processing:
As example, the trace sub-function named “RRC dedicated traffic” covers the RRC signalling
messages exchanged between the UE and the network in dedicated mode.
NE collected records are presented according to three different “Trace modes”
Mode 1 - “Event only” (contains the traced function and sub-function, the event name, a time-
stamp, the related cell Id, the related RNC Id)
Mode 2 - “ASN.1” (contains a header and the full record information, coded in ASN.1 - applies only
to UTRAN protocols PDUs)
Mode 3 - “Ctx_full” (provides a specific set of additional data associated to the event)
To ease Call Trace configuration the traceable Function / Sub-Functions and associated Trace Modes are
organised in predefined “Session Templates” (user configurable). The user does not need to specify
exhaustibly the required information every time a session is created.

6.7 Real time Call Trace Overview
Real Time Call Trace Framework

Ability for user to visualize Call Trace
messages variation in real time from
WMS client application
Real Time CT Activation :
Real Time CTb : Activate on dedicated
UE_ID On max 2 simultaneous calls per
RNC
Exclusive with classical CTb session
Direct connection with RNC via IP/UDP
protocol
Display Latency: ~10/15 seconds
Graphical User Interface :

list of the cells active set
Call Message Flow
Failure message Identification - cell 1
Message Content Display - cell 2 list of the Established RAB
Call Active Set - cell 3 - CS
List Of Established RAB - PS
Off-Line replay mechanism - HSDPA
- EDCH …


6.8 Real time Call Trace Preparation

To start a real time call trace, you go to the NSP GUI and open the « Performance » Menu, Radio Access and
Call Trace Wizard for UMTS.
This is exactly the same procedure than the classical Call Trace session creation.
The Real Time Call Trace is performed only for Access session ie. CTb traces.

6.9 Real time Call Trace Monitoring

To monitor the RT call Trace, a new function is addes into NSP in OAM7.0. Through the Performance menu,
and Radio Access, you click on Real Time Call Trace to monitor the call traced.
Only 2 CTb session can be monitored.

7 Alcatel-Lucent Performance
Monitoring Tools


7 Alcatel-Lucent Performance Monitoring Tools
7.1 OAM Performance Management Portfolio
BASE PRODUCT OPTIONAL PRODUCTS
Counters Network
Counters
Performance
NPO Optimizer
WMS CallTraces
RFO
UTRAN Radio Frequency
Optimizer
CallTraces
CallTraces
Wireless Quality
Wireless Management Analyzer
System
WQA

System :
Activation
Data collection
Data mediation
Network Performance Optimizer :
Counter Based
Performance Reporting
Added value modules
Radio Frequency Optimizer :
CallTrace Based
Per Call Analysis
Graphs / KPI
Wireless Quality Analyzer :
CallTrace Based
Mobility Optimization
Call Failure Optimization

7.2 OAM Performance Management Portfolio Strategy
DA
Complementarities of Tools :
TA
NPO <-> WQA <-> RFO
RE
FI
NE
Successive Reduction of Zone
M
of Investigation
EN
T
Drive Test Reductions
Zone Of Interest
Overall strategy of products / data sources and

methods of investigation makes drive tests obsolete.
Every UE provides the information for QoS
optimization !!!

Complementarities of Tools :
NPO <-> WQA <-> RFO
Different size of zone of interest
Different level of Investigation
Different level of data applicability
Successive Reduction of Zone of Investigation

Focus on specific problems.
Use accurate tools depending of the problem
Traces Mechanism transform subscriber into drive testers
Drive Test Reductions

Focus on specific problems controled environment for dedicated investigation
RFO CTb can be used to ease the investigation

7.3 Post Processing Call Trace Data with RFO
Messages
exchanged
Functions – Per Call
Trace analysis
Call Flow
Message decoding
(inc. ASN1)
Grid view
Time graphs
One Shot hexa
decoding
ASN1
Decoded Info

Post process
Inputs : Call traces ( from RNC

Control Node & Interface Node (xml)
CTa, CTb, CTg, OTCell
Detail Views : for one mobile (several calls in one file)
All the views are synchronized :

Message view
Graph view
Grid view
System Tools : for a set of mobiles (several calls in several files)
Statistics Tool

7.4 Post Processing Call Trace Data with WQA
CTn Session Type and WQA – Wireless Quality Analyser
WQA is a Tool introduced to post-process CTn log files.
Several Reports (matrices) are WQA Wireless

available: Matrices Computation 3,50%
3,00%
(Cell 1 - Cell 2)
100,00%
90,00%
Provisioning
80,00%
cu m u lati ve d is tr ibu ti on
2,50% 70,00%
p erc en tag e t ota l

int er fer en ce
2,00% 60,00%
50,00%
Per Neighbouring Relation & Per HO

1,50% 40,00%
System
1,00% 30,00%
20,00%
0,50%
10,00%
0,00% 0,00%
-35 -25 -15 -5 5 15 25 35 45 55
C/I (dB)
type (Soft/Softer, HSxPA, InterFreq, (a.k.a. WPS)

2G<->3G)
Optimization
Includes HO failure analysis Cycle
Analysis of Ping Pong HO
W-NMS
Upload of Parameters
Provides recommendations: CTn
CTn Changes
Traces for for Network
Adjacencies to be added/removed
analysis Tuning
Modification can be fed into WPS
and then applied on the Network
UTRAN

A CTn Call Trace session only logs the events associated to (SHO/HHO) mobility and is fully
dedicated to the neighboring tuning activities.
Updated neighbouring lists (inter/intra frequencies, inter-system) are crucial to deliver the desired
end2end user QoS:
Neighbouring tuning can represent 80% of optimisation activity
WQA is a Tool introduced to post-process CTn log files.
Several Reports (matrices) are available:
Per Neighbouring Relation & Per HO type (Soft/Softer, HSxPA, InterFreq, 2G<->3G)
Includes HO failure analysis
Analysis of Ping Pong HO
Provides recommendations:
Cells to be added in the neighbouring list
Cells to be removed from the neighbouring list
Modification can be fed into WPS and then applied on the Network


for this module


End of Module


Section 3
31
Monitoring and TroubleShooting
Methods
Module 1
9300 WCDMA

Blank Page

Monitoring and TroubleShooting Methods
Document History
01 2010-04-27 Nolan, Vincent First version for UA07
02 2010-08-02 Charneau, Jean-Noel Replacement of old ProOptima QoS Panels list

by NPO Views list

Module Objectives
Explain what is the QoS monitoring and troubleshooting process

Identify the performance reports




Table of Contents
Page
1 Monitoring and troubleshooting process 7
1.1 Monitoring & Troubleshooting Methods 8
1.2 Criteria Definition 9
1.3 Observation 10
1.4 Analysis 11
1.5 Correction 12
1.6 Validation 13
2 Define Performance Reports 14
2.1 High level : RNC and CELL Dashboards 15
2.2 Low level : Detailed Monitoring and Troubleshooting 16
2.3 Recommendations 18
End of Module 20



Monitoring and TroubleShooting Methods This page is left blank intentionally

1 Monitoring and troubleshooting
process


1 Monitoring and troubleshooting process
1.1 Monitoring & Troubleshooting Methods
The basic method for monitoring is based on a detection method

• Counters
Data Retrieve
Monitoring Setup
• Metrics
Definition • Reports
• Alarms
• Hourly / Busy Hour, Daily, Weekly

Engineering Criteria Definition • Alarm detection
• NEs (RNC, FddCell, SGSN, …)
Tool implementation: NPO for instance

Implementation Post - processing solution: Excel, Access
Automatization
Observation
Monitoring Process
!
Analysis O&M
Correction O&M
Validation

The basic method for monitoring is based on a detection method :

A problem or a need of improvement will be detected when, part of the network doesn’t fit the «required
performances»:
- Performances not in accordance with the operator’s needs or expectations.
- Difference of performances with the rest of the network
- Sudden degradation of performances
Performances could be defined as rates of operations completion or usage of the resources.

1.2 Criteria Definition
The granularity for reporting must be also selected in terms of time

(hourly, daily, weekly…)
The output of this step comes with a set of deliverable reports to use
for monitoring activities:
Weekly Performance Monitoring reports based mainly on RNC Panel
Daily Performance Monitoring reports based on worst cell lists
Investigation reports based on troubleshooting metrics.


1.3 Observation
Monitoring Process
Observation
Observation has to be achieved on a daily basis !

Analysis O&M
Correction O&M
Validation
Results must be compared every day
Monitoring has to be executed according to top to bottom approach
Customer complaints

To quickly react to any degradation of the quality of service and keep the satisfaction of the subscribers, it is really
important to detect any trouble as soon as it occurs.
For this purpose, observation has to be achieved on a daily basis.
In order to have relevant monitoring, the results must be compared every day. The behavior of a network appears
generally different 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.
Data have to be reliable. It means that enough data are accumulated before taking assumptions on the network
behavior, so, a serious background of network pictures is required (depending on the traffic, one month data could
be needed to be sure of the network behavior and performances).
Monitoring has to be executed first at a global level, then at RNC levels and then at the fddcell level with help of the
top N and the alarm reports.
Customer complaints, network daily tracking (that contains any network configuration change –software, hardware,
parameter changes…) and network stability status can help to find and solve any bad performances of the network.
Figures have to be captured also at the times the network is the most demanded: data for busy hour are needed every
day.

1.4 Analysis
Monitoring Process
Observation
The aim of KPIs analysis is to: Analysis O&M

Correction O&M
Detect possible network problems Validation
Shape global network view

If first analysis is not enough or some hypothesis has to be confirmed, further
investigation is necessary:
System check
Verify operation and maintenance reporting.
Iub, Iu, Iur Interface traces and mobile traces

To analyze a problem, many data are available. They have to be correlated together and also with the network
configuration.
The aim of this task is to detect the different problems, analyzing and correlating with the rest of statistics to have a
global network view at the same time that problems are detected and different steps can be followed in order to fix
them.
If a first analysis is not enough or some hypothesis has to be confirmed further investigation is necessary:
- System check
- Verify operation and maintenance reporting.
- Iub Iu Iur Interface traces and mobile traces

1.5 Correction
After Analysis solutions could be proposed
Monitoring Process
Observation
Analysis O&M
Correction O&M
Validation
Design Fine Tuning :

Antenna system configuration
(Height, Azimuth, Tilt … )
Radio Fine Tuning :

Radio parameters values setting
(Power, CAC, iRM, AO… )

After analysis, some solutions are proposed. A report describing the problem, its analysis and the corrective actions
has to be written, to keep a trace in the network history and helping in the new issues.
A solution can be a parameters fine tuning for a process and/or in a part of the network. New setting of the parameters
can be loaded
To correct radio problems, actions on the radio designed are proposed: tilting antennas, modifying the output power,
parameter changes...
Modifying the network configuration may be necessary.

1.6 Validation
Monitoring Process
Observation
Validation occurs after corrective action implementation: !
Analysis O&M
Monitoring must show that the problem has disappeared Correction O&M
Monitoring has to confirm that the other parts of the network Validation
have not been degraded by the correction action: no side

effects
It must be observed during several days

When the corrective action has been implemented, it has to be validated.

Monitoring must show that the problem has disappeared, on a long term period (one week). No more alarms, or
absence of the top 30, or evolution in a good trend.
Monitoring has to confirm that the other parts of the network have not been degraded by the correction action: no side
effects. It must be observed during several days.

2 Define Performance Reports


2.1 High level : RNC and CELL Dashboards
These reports are used in “from Top to Bottom approach”

The RNC and CELL dashboard reports contain global views.

They can be used for a regular monitoring of main KPIs to have a high level overview of the network
performance. All views of these two Global Reports called Dashboards 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.
The indicators provided in these Dashboards are related to :
- RRC connections set-up
- IU SCCP connections set-up
- Radio Access Bearers establishment
- Call Drops
- Mobility efficiency
- Congestion detection
- Quality
- Traffic
The RNC dashboard report reflects the overall actual quality of network, and they it lead to deeper
investigations at CELL level and using additional indicators.
This depper analyzis will use both Detailed Monitoring reports and Troubleshooting reports.

2.2 Low level : Detailed Monitoring and Troubleshooting
These reports are used for detailed monitoring

The Detailed Monitoring reprts contain a lot of detailed views of indicators commonly used for detailed
performance analysis per monitoring domain like for a specific feature monitoring. These reports are
often used during UTRAN Release upgrades.

2.2 Detailed Monitoring [cont.]

The Detailed Monitoring reprts contain a lot of detailed views of indicators commonly used for detailed
performance analysis per monitoring domain like for a specific feature monitoring. These reports are
often used during UTRAN Release upgrades.

2.3 Recommendations
Before starting any investigation on a bad metric:

Check the reliability of the indicator value if provided
Check if the required number of samples associated to the
indicator is reached
Example: Indicator = call_drop_rate_CS = 20% for a specific cell

Check if the reliability of the call_drop_rate indicator is 100%
Check if the number of call established is greater than 100

The Sampling Indicator defined for call_drop_rate_CS indicator is the Number of CS calls established which
is computed from the counting of the number of Iu Release Complete messages sent by the RNC to the
CN-CS.


for this module


End of Module


41
Section 4
Network Accessibility Monitoring
Module 1
9300 WCDMA

Blank Page

Document History
01 2010-04-27 Nolan, Vincent First version for UA07
02 2010-08-02 Charneau, Jean-Noel • addition of new RRC connection success rate

indicators using the #433 counter excluding UE
repetitions
• addition of RAB assignment related counters
but implemented at Reference cell level
• addition of UCSSR006 and UCSSR007
indicators providing better CSSR values
• addition of counter/indicator to monitor
distribution of traffic based on UE distance
• removal of two chapters : Preemption and
RRC Connection Re-establishment

Module Objectives
Describe the accessibility metric family

Illustrate the call flows associated with the metric family
Identify counters and locate them in the call flow procedure
Define metrics and recognize its key counters
Analyze each metric




Table of Contents
Page
1 Accessibility analysis 7
1.1 Reminder Call Establishment (Cell-DCH case) Flow 8
1.2 Accessibility issues causes 9
2 RRC Connection Phase 10
2.1 RRC Connection 11
2.2RRC Connection Success: call flow 12
2.3RRC Connection Success: counters 13
2.4RRC Connection Preparation Failure 14
2.5RRC Connection Execution Failure 15
2.6RRC Connection : Counter Tree 16
2.7 RRC Connection Success Rate 17
2.8RRC connection attempt during cell reselection 18
2.9RRC Connection Success Rate excluding UE repetitions 19
3 RRC Troubleshooting 20
3.1RRC Accessibility analysis 21
3.2Example: RRC Failure Cause Analysis 22
3.3RRC Connection / RF Conditions Analysis / DL Quality 24
3.4RRC Connection / RF Conditions Analysis / DL Level 25
3.5RRC Connection / RF Conditions Analysis / UE distance 26
3.6RRC Connection / RF Conditions Analysis / UL Radio Load 27
3.7RRC Connection / RF Conditions Analysis / UL Cell Load 28
3.8RRC Connection / RRM Capacity Analysis 29
3.9 Case Analysis 30
3.9.1 Burst of RRC failures in a RNC 31
415 3.9.2.1 Burst of RRC failures atAll Busy Hours
Rights Reserved © Alcatel-Lucent 2010
32
3.9.39300
9300 WCDMA TMO18268 Burst of RRC
WCDMA UAO7 failures
R99 QoS Analysis inLoad
and Traffic a Monitoring
few cells 33
3.9.4 RRC Burst of failures (summary) 34
4 Radio Link Management 35
4.1 Reminder 36
4.2 VS.RadioLinkSetupUnsuccess 37
4.3 Radio Link Reconfiguration Prepare 38
5 RAB Establishment and Troubleshooting Analysis 41
5.1 RAB Assignment Flow: Exercise 42
5.2 RAB Assignment Success: counters 43
5.3 VS.RadioBearerEstablishmentUnsuccess 46
5.4 RAB Assignment Preparation Failure 47
5.5 RAB Assignment Execution Failure 48
5.6 RAB Assignment: RNC Counter Tree 49
5.7 RB Establishment: Cell Counter Tree 50
5.8 RAB Assignment Success Rate (RNC level) 51
5.9 RB To Be Setup Success Rate (CELL level) 52
5.10 RAB Analysis: Failure analysis 53
6 IuSCCP Troubleshooting Analysis 54
6.1 Exercise: Iu SCCP Connection procedure 55
6.2 SCCP Connection: Success Flow 57
6.3 SCCP Connection: Failure Flow 58
6.4 SCCP Connection : Counter Tree 59
6.5 Iu SCCP Analysis (success rates initiated by the RNC) 60
6.6 Iu SCCP analysis method 61
6.7 Case Study 62
6.7.1 Compare CS and PS Iu SCCP efficiency 63
6.7.2 Compare RNCs 64
7 Security Mode Troubleshooting Analysis 65
7.1 Security Mode Success: Flow 66
7.2 Security Mode Failure: RNC 67

Page
7.3 Security Mode Failure: UE 68
7.4 Security Mode Command Success Ratio 69
7.5 Ciphering analysis 70
8 Call Setup Success Rate Troubleshooting Analysis 71
8.1 Exercise 72
8.2 Call Set Up Success Rate 74
8.3 Accessibility Troubleshooting Chart 75
8.4 Case Study 76
8.5 Other formula for Call Set Up Success Rate CS 78
8.6 Other formula for Call Set Up Success Rate PS 79
End of Module 81


1 Accessibility analysis


1.1 Reminder Call Establishment (Cell-DCH case) Flow
UE Node B RNC CN
RRC Connection Request RACH CAC (RNC)

Radio Link Setup Request
CAC Radio Link Setup Response RRC Connection Phase
NB USERS NODE bRRC Connection Setup
RRC CONNECTION PHASE (RACH)
RRC Connection Complete
Measurement Control
Init Direct Transfer
SCCP Connection Request (Initial UE Message)

SCCP Connection Confirm SCCP Connection Phase
Authentication Procedure
SERVICE REQUEST
Ciphering Procedure
RAB Assignment Request
S.R.L.R. Procedure
DCH CAC
SUNCHRO RECONFIGURE RAB establishment Phase
Radio Bearer Setup
Radio Bearer Setup Complete
RAB Assignment Response


1.2 Accessibility issues causes
Degradation of Accessibility KPIs ✁❁❚❅❒✟▼❃❙◆❉
❐✟▲❄❒✁❆✟ ❊
▲❄❆✁✟ ❏❋❇❑❈
Radio problems
n methods
Investigatio
pters
in next cha
Capacity
HW problems
SW problems

Metrics and reports will be selected, going from a high level with the executive reports to a deeper level with
the detailed reports. This is a strategy from the top to the bottom. The format of the reports will be graph or
table.
The granularity for reporting must be also selected in terms of time (hourly, daily, weekly…) and the network
elements for each reports.
The output of this step is coming with a set of deliverable reports to use for monitoring activities.
The following shows an example of deliverable reports for a network on the UTRAN side:
- Weekly Performance Monitoring reports based mainly on RNC Panel
- Daily Performance Monitoring reports based on worst cell lists
- Investigation reports based on troubleshooting metrics.

2 RRC Connection Phase


2.1 RRC Connection
Logical connection between UE and UTRAN.

It carries control plane information between UE and UTRAN.
Each UE can have only one RRC connection at any time with the UTRAN.
UE Node B RNC
Circuit Domain
Physical channel AAL2 bearer SIG/AAL5 Core Network

if ATM
RRC (logical channel) SCCP Packet Domain

RRC connection

RRC connection is a logical connection between UE and UTRAN. It carries control plane information
between UE and UTRAN.
Before anything can be done in UMTS, the RRC connection must be established.
RRC Connection is one of functions of RRC Layer (Layer 3). All messages sent over this connection are
part of the RRC protocol.
The establishment of an RRC connection includes cell reselection, admission control and layer2
signaling link establishment.
Each UE can have only one RRC connection at any time with the UTRAN. It is used by the UTRAN to
track both the location and state of the user during the life of a call or packet data session.
The release of an RRC connection can be triggered by request from upper layer or by the RRC layer
itself in case of connection failure.
At the first NAS message from UE which needs to be sent to the CN, the UTRAN will setup an SCCP
connection with the CN in order to forward this NAS message either to the MSC or the SGSN according
to the service to be setup.

2.2RRC Connection Success: call flow
RRC Connection Phase

UE Node B RNC logical/trans/
physical
RRC Connection Request CCCH / RACH / PRACH
RRC connection
Radio Link Setup Response

RRC Connection Setup CCCH / FACH /
SCCPCH
Measurement Control DCCH / DCH /

DPDCH+DPCCH

This scenario is applied in case of RRC connection establishment in cell_DCH state (for CS calls setup
for instance).

2.3RRC Connection Success: counters
FDDCell counters
UE Node B RNC
RRC Connection Request #409

RRC Connection Request
Radio Link Setup Request #419
First RRC Connection
RRC connection
Radio Link Setup Response Request
RRC Connection Setup

#416
RRC Connection Complete RRC Connection Setup
Measurement Control
#403
Init Direct Transfer RRC Connection Success

RRC.AttConnEstab #409 : This measurement provides the number of RRC connection requests screened by
establishment cause.
Screening (below): see RRC connection establishment causes:
0 --> Originating Conversational call 1 ---> Originating Streaming call
2 --> Originating Interactive call 3 ---> Originating Background call
4 --> Originating Subscribed Traffic call (PS call) 5 ---> Terminating Conversational call
6 --> Terminating Streaming call 7 ---> Terminating Interactive call
8 --> Terminating Background call 9 ---> Emergency call
10 ---> Intersystem cell re-selection (2G to 3G cell-reselection for CS and PS performed by mobile on its own in idle
mode ; used for Location Area Update/Routing Area Update NAS transactions )
11 ---> Intersystem cell change order (2G to 3G handover for PS when triggered by BSS, using a Cell Change Order
command: Network Controlled Cell Reselection Mode 2: used to open the RRC connection in order to resume data
transfer)
12 --> Registration 13 --> Detach
14 --> Originating High priority signaling 15 --> Originating Low priority signaling
16 --> Call re-establishment 17 --> Terminating High priority signaling
18 --> Terminating Low priority signaling 19 --> Terminating: Cause unknown
20-31 --> Spare causes (not used: provisioned for future use) as defined in TS25.331
VS.FirstRrcConnectionRequest #419 : while #0409 counter counts all requests and thus repetition, the #0419 counts
only the first one and provides more accurate measures.
RRC.SuccConnEstab #403 : This measurement provides the number of successful RRC connection establishments
screened by establishment cause.
VS.RrcConnectionSetup #416 : This measurement provides the number of RRC Connection Setup messages sent
to the UE in response of an RRC Connection Request. Only the initial Setup message and the first repetition at
T351 expiry are counted. Quick repetition are not counted.
Screened by cause for sending the RRC Connection Setup.
0 : Initial RRC Cnx Setup without quick repeat
1 : Initial RRC Cnx Setup with quick repeat
2 : first repetition of RRC Cnx Setup without quick repeat
3 : first repetition of RRC Cnx Setup with quick repeat
Note about UE RRC connection request: if this request does not reach the RNC it is impossible to measure it.
2.4RRC Connection Preparation Failure
FDDCell counter
UE Node B RNC
rach cac the first one
RRC Connection Request CAC failure

Or
RNC Overload
RRC Connection Reject (wait time)
#404 RRC Connection Reject

[all screenings except 0
and 13]
With Redirection to GSM if:

• MO Conversational or Emergency call
RRC connection
• a blind 2G neighbor cell is declared

RRC.FailConnEstab #404: This measurement provides the number of RRC connection establishment failures screened
by establishment failure cause.
Screening:
• Sub-Counter #1 : unavailable dl code resources
• Sub-Counter #2 : unavailable dl power resources
• Sub-Counter #3 : RSSI
• Sub-Counter #4 : Cell Fach Unspecified CAC (excluding lack of context)
• Sub-Counter #5 : Overload
• Sub-Counter #6 : 3G to 2G Redirection for Emergency Calls
• Sub-Counter #7 : RRC context CAC, pegged when CAC fails (excluding FACH Ues)
• Sub-Counter #8 : Unavailable RRC context resource, pegged when the number of RRC contexts is exhausted
• Sub-Counter #9 : Unavailable FACH context resource, pegged when the number of FACH contexts in RNC_CALL is
exhausted.
• Sub-Counter #10 : No answer from the NodeB
• Sub-Counter #11 : Lack of C-RNTI
• Sub-Counter #12 : UE Ec/No lower than qQualityMiN
• Sub-Counter #13 : Repeated 'RRC Connection Request' received in a different cell from the preceding attempt
(during the N300*T300 window). To be pegged in the cell where the 'RRC Connection Request' prior to reselection
was received.
• Sub-Counter #14: In case the Manual Overload Control at NodeB granularity feature is activated, if the number of
RLS in the NodeB is exceeded the thresholdEventA,RNC starts to reject 'RRC Connection Request'until the number
of RLS in the NodeB is less than thresholdEventB
• Sub-Counter #15 : SRNC receives a "Radio Link Setup Failure" message causing RRC Connection Reject to be sent
• Sub-Counter #16 : 3G to 2G Redirection based on cell load
Notes:
Screening #5 corresponds to an RNC OVERLOAD problem
Screening #8 corresponds to a CAC failure due to RRC context resource shortage in the RNC
Screening #9 corresponds to the CAC failure on FACH when the maximum number of users on FACH has been
reached.

2.5RRC Connection Execution Failure
FDDCell counter
UE Node B RNC

CAC success
#404 RRC Connection Failure T352 expiry

[screening 0 and 13]
RRC connection

RRC.FailConnEstab #404: This measurement provides the number of RRC connection establishment
failures screened by establishment failure cause.
Timeout screeners:
Sub-counter#0 : TimeoutRepeat
Incremented when the RNC does not receive a RRC Connection Setup Complete before T352
expires (timeout)
Incremented when the RNC receives a new RRC Connection Request from the same UE within
N300xT300 in the same cell as the previous request
Sub-counter #13 : Reselect

Incremented when the RNC receives a new RRC Connection Request from the same UE within
N300xT300 in a different cell then the previous request (incremented on the cell where the
original RRC Connection request was received – before cell re-selection)

2.6RRC Connection : Counter Tree
FDDCell counters
Request RRC.AttConnEstab
VS.FirstRrcConnectionRequest
#409 and #419
Preparation failure Setup VS.RrcConnectionSetup

#404[all screenings except 0 & 13] #416
#436
RRC.FailConnEstab
RRC.FailConnEstab.Unspecified.Sum
Execution failure Success

#404[0] + #404[13] #403
RRC.FailConnEstab RRC.SuccConnEstab
RRC connection

In UA7 release, RRC.FailConnEstab.Unspecified (#404.3) is replaced by a dedicated counter

RRC.FailConnEstab.Unspecified.Sum - #436.

2.7 RRC Connection Success Rate
FDDCell metrics
URRC013_CR_Cs User View
#403.[0,5,9] + #404[6,16] - #439[0,1]

First RRC connection
=
success rate (CS calls) #419.[0,5,9] + #404[6,16]
URRC013_CR_Ps User View
#403.[1,2,3,4,6,7,8,14,16,17,19]
First RRC connection =
success rate (PS calls) #419.[1,2,3,4,6,7,8,14,16,17,19]
RRC connection

RRC Connection success rate can be monitored at FDD Cell level.

It is proposed to select the RRC causes which are taken by the calls:
Screening from 0 to 9: Originating / Terminating Traffic Classes and Emergency call
Screening 14, Originating High Priority Signaling:
3GPP: this screening is used for Supplementary Services in CS, and to Modify/Deactivate a PDP Context in PS
Alcatel-Lucent comment: Qualcomm UE systematically uses this cause to establish PS call
Screening 16, Call re-establishment:
3GPP: this screening is used for CS Call re-establishment, or Routing Area Update – for the case of ‘Directed
Signaling Connection Re-Establishment‘
Alcatel-Lucent comment: it may be also used to re-establish PS call after an Always-On Step 2 downsize (always-on
…)
Screening 17, Terminating High Priority Signaling:
Is also used to establish PS calls
Screening 19, Terminating – cause unknown:
3GPP: This cause is used by the UE whenever it responds to a paging message in which the paging cause has not been
set (the "paging cause" information element is an optional field of the paging message)
RRC.FailConnEstab - #404
Failed RRC Connection Establishments by Cause
Sub-Counter #6: 3G to 2G Redirection for Emergency Calls
Sub-Counter #16: 3G to 2G Redirection based on cell load
VS.RRC.ConnectionReAttempt - #439
With counter 0404 it gives a view of the failure and success rate of the 3G2G redirection at RRC establishment request. If no GSM
cell verifies the selection criteria, the UE will re-attempt a new RACH after the "wait time" timer (UE timer) elapses. On this new
attempt the RNC does not redirect the call to the 2G and attempts to establish the call on the FDD cell if the Rach comes before
the timer rrcCnxRepeatTime elapses.
The counter is incremented when the RNC does not redirect this new attempt. Repeated "RRC Connection Request" in the context
T300 and N300 from the same UE (same UE Id and format)on the same RNC shall be excluded. Note: rrcCnxRepeatTime is
renamed from emergencyCallRepeatTime
Sub-Counter #0: Emergency call redirection feature
Sub-Counter #1: Redirection based on cell load feature

2.8RRC connection attempt during cell reselection
UE moves and reselects several cells during RRC Establishment Phase

RRC Connection Request can be repeated several times within T300xN300
Cell 1 Cell 2 Cell 3
VS.RRC.AttConnEstab.LastperProc (#433) & VS.RRC.AttConnEstab.LastperProc.Sum (#428)

are just incremented once – excludes all UE repetitions for the same call attempt
Counters are pegged at the last cell where the procedure finally succeeds or fails
Metric [Sum (#403) / #428] provides the RRC Connection Setup Success Rate according to User Perception

Featured Counters:
VS.RRC.AttConnEstab.LastperProc.Sum (#428)
VS.RRC.AttConnEstab.LastperProc (#433)
Feature Value:
Total number of RRC connection establishment attempts. Repeated attempts from the same UE on the same or a
different cell - due to cell reselection - are excluded.
Align Observed Call Setup Success Rate KPIs with User Perception.
Triggering Event
Incremented on the last 'RRC Connection Request' message for the same RRC Connection Establishment
procedure being received from the UE on the RNC.
The last 'RRC Connection Request' message is identified either
on emission of 'RRC Connection Complete' (successful case) or
on T300xN300 window expiry (unsuccessful case)
in case of repetitions: including the same UE Id and same establishment cause as previously received 'RRC
Connection Request' messages within the T300xN300 window on the same RNC. The establishment cause for
repeated attempts will remain unchanged.
Repeated RRC Connection Requests received on different cells - due to cell reselection - will be considered.
Pegged against the cell, where RRC connection establishment succeeds or finally fails within the T300xN300
window (last cell)
Screenings of both counters are the same than for #403 and #419 counters.
The new counters are to be used in conjunction with existing counter RRC.SuccConnEstab (#403) - Number of RRC
successful connection establishments (incremented at the reception of a RRC Connection Setup Complete from the
UE)
Metric [Sum (#403) / #428] provides the RRC Connection Setup Success Rate according to User Perception

2.9RRC Connection Success Rate excluding UE repetitions
FDDCell metrics
URRC021_CR_Cs User View
RRC connection success rate - CS #403.[0,5,9] + #404[6,16] - #439[0,1]

=
(excluding UE repetitions) #433.[0,5,9]
URRC021_CR_Ps User View
RRC connection success rate - PS #403.[1,2,3,4,6,7,8,14,17]

=
(excluding UE repetitions) #433.[1,2,3,4,6,7,8,14,17]
RRC connection

RRC.SuccConnEstab - #403
Number of rrc connection successful
Sub-Counter #0: Originating Conversational call • Sub-Counter #1: Originating Streaming Call
Sub-Counter #2: Originating Interactive Call • Sub-Counter #3: Originating Background Call
Sub-Counter #4: Originating Subscribed Traffic Call • Sub-Counter #5: Terminating Conversational call
Sub-Counter #6: Terminating Streaming Call • Sub-Counter #7: Terminating Interactive Call
Sub-Counter #8: Terminating Background Call • Sub-Counter #9: Emergency Call
Sub-Counter #14: Originating High Priority Signalling • Sub-Counter #17: Terminating High Priority Signalling
Failed RRC Connection Establishments by Cause
Sub-Counter #6: 3G to 2G Redirection for Emergency Calls
Sub-Counter #16: 3G to 2G Redirection based on cell load
VS.RRC.ConnectionReAttempt - #439
With counter 0404 it gives a view of the failure and success rate of the 3G2G redirection at RRC establishment
request. If no GSM cell verifies the selection criteria, the UE will re-attempt a new RACH after the "wait time"
timer (UE timer) elapses. On this new attempt the RNC does not redirect the call to the 2G and attempts to
establish the call on the FDD cell if the Rach comes before the timer rrcCnxRepeatTime elapses.
The counter is incremented when the RNC does not redirect this new attempt. Repeated "RRC Connection Request"
in the context T300 and N300 from the same UE (same UE Id and format)on the same RNC shall be excluded. Note:
rrcCnxRepeatTime is renamed from emergencyCallRepeatTime
Sub-Counter #0: Emergency call redirection feature
Sub-Counter #1: Redirection based on cell load feature

3 RRC Troubleshooting


3.1RRC Accessibility analysis
RRC Accessibility Analysis
RRC establishment
RRC failure cases First Radio Link Cell Inactivity
failure cases
RRC Connection RRC Connection RRC Sleepy Cell

1st RL Setup
failure causes failure cases Inactivity
failure causes
distribution distribution #15
distribution
#404[cause] per type of call
#41[cause]
#409 - #403[call]

In case of RRC failures it’s not possible to differentiate simultaneously the failure cause and the service
cause Two parallel analysis are necessary to correlate failure cause with the failure service cause:
Failure cases analysis: Distribution of the failure causes screenings
Establishment failure analysis: which RRC establishment causes (Originating / Terminating Traffic
Classes, conversational, I / B…) failed
Problem Detection: RRC CSR lower than a threshold
RRC accessibility troubleshooting:
RRC failure causes distribution
RRC establishment failure cases (per RRC request cause)
First Radio Link
Failure Establishment cause
RRC Cell inactivity
VS.RadioLinkFirstSetupFailure - #41
the number of failures on the first Radio-Link setup. This excludes Radio link setups for soft handover.
A set of subcounters screened on:
• Sub-Counter #0 : RadioLinkSetupFailure • Sub-Counter #1 : Timeout • Sub-Counter #2 : RRM refusal
• Sub-Counter #3 : IubLayerCongestion • Sub-Counter #4 : NodeBCEMLackL1Rsrc
• Sub-Counter #5 : LackCidOrUdpPortIub • Sub-Counter #6 : LackBwthIub
• Sub-Counter #7 : InodeRefusal • Sub-Counter #8: Multi-cell Operation Not Available
• Sub-Counter #9: TMU internal resources exhausted, e.g. context pool, timer pool, etc. exhausted
VS.RrcSleepyCellInactivity - #15
This measurement represents the number of minutes since last RRC activity was detected for this cell. The
number of minutes is rounded down to the nearest multiple of minutes in a reporting period.

3.2Example: RRC Failure Cause Analysis
RRC Connection success rate RRC Accessibility Analysis
RNC level
Refer to the RRC

For one/several RNC
Connection failures
counters (#404) RRC CSR RRC establishment
failure cases
URRC013 < Th
Top N Cells
RRC Connection Failure rate
Determine the worst period

during the day
High nb of High nb of
High nb of High nb of High nb of High nb of
No answer UE Ec/No lower
Failure Time out UL RSSI Failure Dl Power Failure Dl Codes
from the NodeB than qQualityMin
DL RF condition
UL RF condition
RF tuning of
- RRC timers analysis RF Conditions Analysis RRM Capacity Analysis
- Common power channel Cell level Cell level
- Cell Reselection parameters

Issue characterization:
Can it affect certain/all services (CS, PS, 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)

3.2Example: RRC Failure Cause Analysis [cont.]
RRC Connection success rate RRC Accessibility Analysis
RNC level
Refer to the RRC

For one/several RNC
Connection failures
counters (#404) RRC CSR RRC establishment
URRC013 < Th failure cases
Top N Cells
RRC Connection Failure rate
Determine the worst period

during the day
High nb of
High nb of High nb of High nb of
Unavailable FACH
CAC CELL FACH CAC 3G to 2G Redirection #436
Resources
for Emergency Calls
High nb of
High nb of High nb of Unspecified
High nb of Failure Overload
Unavailable RRC
Lack of C-RNTI
oontext resources
Cell stability
Overload parameter Feature 3G 2g analysis
Capacity Analysis tuning. Correlation redirection speech Alarm correlation/
with TMU load calls-RRC redirect CTg Analysis

The analysis is based on the screenings of the counter RRC.FailConnEstab - #404:

• Sub-Counter #0 : timeout
• Sub-Counter #1 : unavailable dl code resources
• Sub-Counter #2 : unavailable dl power resources
• Sub-Counter #3 : Unspecified
• Sub-Counter #4 : RSSI
• Sub-Counter #5 : Cell Fach Unspecified CAC
• Sub-Counter #6 : Overload
• Sub-Counter #7 : 3G to 2G Redirection for Emergency Calls
• Sub-Counter #8 : RRC context CAC, pegged when CAC fails for the current RRC connection request.
• Sub-Counter #9 : Unavailable RRC context resource: when the number of RRC contexts is exhausted
• Sub-Counter #10 : Unavailable FACH context resource: when the number of FACH contexts in RNC_CALL
is exhausted.
• Sub-Counter #11 : No answer from the NodeB
• Sub-Counter #12 : Lack of C-RNTI
• Sub-Counter #13 : UE Ec/No lower than qQualityMin
• Sub-Counter #14 : Repeated 'RRC Connection Request' received in a different cell from the preceding
attempt (during the N300*T300 window). To be pegged in the cell where the 'RRC Connection Request'
prior to reselection was received.
• Sub-Counter #15 : In case the Manual Overload Control at NodeB granularity feature is activated,if the
number of RLS in the NodeB is exceeded the thresholdEventA,RNC starts to reject 'RRC Connection
Request'until the number of RLS in the NodeB is less than thresholdEventB
• Sub-Counter #16 : SRNC receives a "Radio Link Setup Failure" message causing RRC Connection Reject
to be sent
• Sub-Counter #17 : 3G to 2G Redirection based on cell load
3.3RRC Connection / RF Conditions Analysis / DL Quality
FDDCell counter
CPICH Ec/N0
RNC
CPICH
[0] [1] [2] [3] [4]

VS.IrmcacDistributionEcN0 #1043
-24dB -15dB -13dB -11dB -7dB 0dB
UCell007_C_Min24tomin15
#1043.[0]
Distribution
Distributionof
ofEc/N0
Ec/N0[-24,-15[ =
[-24,-15[ =
RRC connection
#1043.[0,1,2,3,4]

VS.IrmcacDistributionEcN0 - #1043: This counter provides the distribution of Ec/N0 measurements

received per range from UEs with that reference cell.
CPICH Ec/N0 are RRC measurements sent by UE to RNC.
Screening:
Sub-Counter #0 : -24 dB <= Measurement < -15 dB
Sub-Counter #4 : -7 dB <= Measurement < 0 dB

3.4RRC Connection / RF Conditions Analysis / DL Level
Reference FDDCell counter
CPICH RSCP
RNC
CPICH
[0] [1] [2] [3] [4]

VS.IrmcacDistributionRscp #1158
-120dBm -110dBm -105dBm -95dBm -80dBm -25dBm
UCell008_C_Min120tomin110
#1158.[0]
Distribution
Distributionof
of RSCP =
RRC connection
RSCP[-120,-110[
[-120,-110[ =
#1158.[0,1,2,3,4]

VS.IrmcacDistributionRscp #1158: This counter provides the distribution of RSCP measurements

received per range from UEs with that reference.
CPICH RSCP are RRC measurements sent by UE to RNC.
A set of subcounters screened on: Measurement Report power range
• Sub-Counter #0 : -120 dBm <= Measurement < -110 dBm
• Sub-Counter #4 : -80 dBm <= Measurement <= -25 dBm

3.5RRC Connection / RF Conditions Analysis / UE distance
AICH RNC
In Band (Propagation Delay)
PRACH
RL Setup request (Propagation Delay)
[0] [1] [2] [x] [7]

VS. DistPropDelayPerRange #1041
0m 468m 702m 1171m 10072m
Percentage of UE access beyond 10km

#1041.[7]
Distribution
Distributionof
of UE
UEdistance
distance==
RRC connection
>>10072m
10072m #1041.[0,1,2,3,4,5,6,7]

VS.DistPropDelayPerRange - #1041: Distribution of propagation delays, as expressed in the 3GPP25.433

Nbap RL Setup Request (when Propagation Delay IE is present)
A set of subcounters screened on: Propagation Delay in terms of chips
• Sub-Counter #0: IE in [0..1] (Cell size < 468m)
• Sub-Counter #1: IE in [2] (468m<= Cell size < 702m)
• Sub-Counter #2: IE in [3..4] (702m <= Cell size < 1171m)
• Sub-Counter #3: IE in [5] (1171m <= Cell size < 1405m)
• Sub-Counter #7: IE in [43..255] (Cell size equal to or above 10072m)

3.6RRC Connection / RF Conditions Analysis / UL Radio Load
VS.RadioWBandRxMainPwr #10201 FDDCell counter

VS.RadioWBandRxDivPwr #10202
NBAP Common Measurement
UL RTWP
VS.UplinkRssi #303
RTWPmeas
(#10201 + #10202)
2 Traffic
UL RSSI
+ Interference
RTWPref
Noise Factor +
Thermal Noise
FDDCell metric UULOAD002_CR_Avg
Average
AverageUL
ULRSSI dBm)==-112
RSSI(in(indBm) -112++10
10xxlog10(#303.Avg)
log10(#303.Avg)
RRC connection
Too
Toohigh
highUL
ULRSSI
RSSIifif>>-98
-98dBm
dBm
Too low UL RSSI if < -112 dBm
VS.RadioWBandRxMainPwr (#10201):
min/ max/ linear average wide-band received power per sector, per frequency, at the Rx main
channelizer (sampled every 100 ms)
min/ max/ linear average wide-band received power per sector, per frequency, at the Rx diversity
The Node-B estimates the total UL Radio Load as the linear average between the UL RX Signal Level
measure at bit Main and Diversity antennae. Then this UL Radio Load is sent to the RNC through a NBAP
Common Measurement Report message (UL RTWP value). This value is available thanks to #303 RNC
counter.
VS.UplinkRssi - #303
min/ max/ average wide-band received power per sector (UL RTWP), per frequency,
According to typical values of Thermal Noise and Noise Factor of the Node-B and Rx aerials chain, this
indicator should be not less that –112dBm; typical minimum value should be between –106dBm and –
105dBm.
As the maximum allowed Rot is driven by a parameter lower than 8dB, the maximum value of UL RSSI
should not be over –98dBm = -106dBm + 8dB
The value of this metric should be between -109 dBm and -102 dBm typically.
Max and Min values can also be considered for radio problem investigation.
Delta between Main and Div UL RSSI measurement are also to be considered.

3.7RRC Connection / RF Conditions Analysis / UL Cell Load
RTWPmeas
Traffic cell load

UL RSSI
+ Interference
RTWPref
Noise Factor +
UULOAD001_CR_x ; x = Min or Max or Avg Thermal Noise
Minimum Uplink Cell Load = #10211.Min / 1000

Maximum Uplink Cell Load = #10211.Max / 1000
RRC connection
Average Uplink Cell Load = #10211.Avg / 1000

New UA5.0 NodeB Counter used:

VS.CellULLoad (#10211)
The Node-B computes this indicator from the estimation of the RoT which is equal to the difference
between the total UL RSSI and the RTWPref.
Then the UL Cell Load is UL Cell Load = 1 – 10-(RoT/10)
Noise Rise vs. UL load

20
18
16
14
Noise Rise (dB) = RoT
12
10
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
UL load (%)

3.8RRC Connection / RRM Capacity Analysis
FDDCell counter
Channelization Code shortage
VS.IRMTimeFreeDlCodesBySpreadingFactor #1126
[0] [1] [2] [3] [4] [5] [6]
SF4 SF8 SF16 SF32 SF64 SF128 SF256
Sub-counter #5 => SF = 128

SF128CodeUsage_Cell009_CR
NB 128 – #1126.[5].Min
AMR e SF128
SF128Code
Codeusage
usage==
s
call ca 128
RRC connection

VS.IRMTimeFreeDlCodesBySpreadingFactor #1126: This SI counter provides the average number of free

downlink channelization codes per spreading factor. It also provides the minimum and maximum value.
Screening:
0 ---> Spreading factor = 4
5 ----> Spreading factor = 128 (voice call, PS always on)
SF128 is used for:
Voice call at 12.2K
Always on: DL at 8kbps

3.9 Case Analysis
Analyse the charts given in next slides !

What could you say about RRC performances ?


3.9 Case Analysis
3.9.1 Burst of RRC failures in a RNC
PS RRC Connection Success rate per RNC
105,00%
100,00%
GQ01
95,00%
GQ02
90,00%
KQ01
85,00%
80,00% OQ01
75,00% OQ02
70,00%
22-sept-04
23-sept-04
24-sept-04
25-sept-04
26-sept-04
27-sept-04
28-sept-04
29-sept-04
30-sept-04
1 Oct 04
2 Oct 04
3 Oct 04
4 Oct 04
5 Oct 04
6 Oct 04
7 Oct 04
8 Oct 04
9 Oct 04
10 Oct 04
The decrease of the RRC Connection success rate, the 5th and the 6th
of October, is due to a drop of the PS RRC Connection success rate in
the RNC OQ02.


3.9.2 Burst of RRC failures in a RNC
3.9.2.1 Burst of RRC failures at Busy Hours
PS RRC Connection Success rate in the RNC OQ02
300 120,00%
PS RRC
250 100,00%
100,00% 100,00% 100,00% 100,90%
100,00% 97,12% 99,43%
100,00% 100,00%
100,00%
96,97% 95,70% Connection
200 80,95% 80,00% attempts
64,98%
150 57,74% 60,00%
51,09% 51,29%
48,35%
44,55%
100 40,00%
PS RRC
50 20,00% Connection
success rate
0 0,00%
5/10/04, 00:00
5/10/04, 01:00
5/10/04, 02:00
5/10/04, 03:00
5/10/04, 04:00
5/10/04, 05:00
5/10/04, 06:00
5/10/04, 07:00
5/10/04, 08:00
5/10/04, 09:00
5/10/04, 10:00
5/10/04, 11:00
5/10/04, 12:00
5/10/04, 13:00
5/10/04, 14:00
5/10/04, 15:00
5/10/04, 16:00
5/10/04, 17:00
5/10/04, 18:00
5/10/04, 19:00
5/10/04, 20:00
5/10/04, 21:00
5/10/04, 22:00
5/10/04, 23:00
The PS RRC Connection success rate falls from 10:00 am to 13:00 pm
and from 14:00 pm to 17:00 pm, when the number of attempts is the
highest. This phenomenon occurs during the 5th and 6th of October


3.9 Case Analysis
3.9.3 Burst of RRC failures in a few cells
PS RRC Connection Failures RNC OQ02 Vs (N889/U1 & N889/U2)
250
200
PS RRC Connection
150
failures in the RNC
OQ02
100
50
0 PS RRC Connection
5/10/04, 00:00
5/10/04, 02:00
5/10/04, 03:00
5/10/04, 05:00
5/10/04, 06:00
5/10/04, 07:00
5/10/04, 08:00
5/10/04, 09:00
5/10/04, 11:00
5/10/04, 12:00
5/10/04, 14:00
5/10/04, 15:00
5/10/04, 16:00
5/10/04, 17:00
5/10/04, 18:00
5/10/04, 19:00
5/10/04, 20:00
5/10/04, 21:00
5/10/04, 23:00
5/10/04, 01:00
5/10/04, 04:00
5/10/04, 10:00
5/10/04, 13:00
5/10/04, 22:00
failures in the N889/U1
& N889/U2
Investigations at cell level indicate that main of the PS RRC Connection Failure
during these two periods are concentrating two cells: N889/U1 and N889/U3.
Based on the RL Setup phase, most of these requests in those two cells are in fact
request for Signaling (Attach, Registration, …) instead of Background, Interactive or
Streaming.
Complementary study could be to take traces on Iub interface/CT of the N889 site in
order to identify the call flow and the type of mobile


3.9.4 RRC Burst of failures (summary)
Problem description
Burst of PS Failures for Originating Interactive Calls.
Consider the following counter related to Originating Interactive Call:
Number of RRC connection failures = RRC.AttConnEstab.OrigIntactCall – RRC.SuccConnEstab.OrigIntactCall
The cell is almost randomly every time, so this suggests a UE issue.
Sometimes this problem cause a lot of failures (>100 in a 15 minutes period) on the cells X, but also is
present, with less percentage, in the neighbours of cell X.
Detection
Activate an alarm with quarter of hour granularity:
RRC.Fail.OrigIntactCall + RRC.Fail.OrigHighPrioSig > 100 [FddCell, Quarter of Hour]=> ALARM!
Investigation
As soon as the alarm appears on the Alarm Monitoring, the following is a needed:
Activate an OTCell Trace in the cell identified by the alarm (1 hour)
Possibility also to activate Iub trace in this cell to find the IMSI
Process the OTCell Trace in order to find the PTMSI of the mobile causing the problem (assuming that
it’s due only to one mobile)
Associate the PTMSI found with the IMSI, using the two files collected

RRC.AttConnEstab - #409
RRC.SuccConnEstab - #403:
A set of subcounters screened on: Cause for rrc establishement, from 3GPP TS 25.331
Sub-Counter #0 : Originating Conversational call
Sub-Counter #1 : Originating Streaming Call
Sub-Counter #2 : Originating Interactive Call
Sub-Counter #3 : Originating Background Call
Sub-Counter #4 : Originating Subscribed Traffic Call
Sub-Counter #5 : Terminating Conversational call
Sub-Counter #6 : Terminating Streaming Call
Sub-Counter #7 : Terminating Interactive Call
Sub-Counter #8 : Terminating Background Call
Sub-Counter #9 : Emergency Call
Sub-Counter #10 : Inter-RAT cell re-selection
Sub-Counter #11 : Inter-RAT cell change order
Sub-Counter #12 : registration
Sub-Counter #13 : Detach
Sub-Counter #14 : Originating High Priority Signalling
Sub-Counter #15 : Originating Low Priority Signalling
Sub-Counter #16 : Call re-establishment
Sub-Counter #17 : Terminating High Priority Signalling
Sub-Counter #18 : Terminating Low Priority Signalling
Sub-Counter #19 : Terminating- cause unknown
Sub-Counter #20 : Spare 12

4 Radio Link Management


4.1 Reminder
UE Node B RNC #38 VS.RadioLinkSetupUnsuccess

#39 VS.RadioLinkAdditionUnsuccess
#40 VS.RadioLinkReconfigurationPrepareUnsuccess
#41 VS.RadioLinkFirstSetupFailure
Radio Link Setup Response RRC Connection Phase

What are the reasons why we could meet RL failure or unsuccess ?
IMA = nE1 R99 over ATM

E1 Leased Lines
x HSPA over IP
C Low Cost STM
Node B E Ethernet
Backhaul
M
GigE


4.2 VS.RadioLinkSetupUnsuccess
Counters Name
#38 VS.RadioLinkSetupUnsuccess: Number of unsuccessful radio link setup
#41 VS.RadioLinkFirstSetupFailure : Number of failures on the first Radio-Link setup
Screenings:
0 RadioLinkSetupFailure
1 TimeOut
2 RrmRefusal
3 IubLayerCongestion
4 NodeBCEMLackL1Rsrc
5 LackCidOrUdpPortIub
6 LackBwthIub
7 INode refusal
8 Multi-cell Operation Not Available
TMU internal resources exhausted,

9 e.g. context pool, timer pool, etc.
exhausted
Screenings correspond to failure causes

S8 is not implemented

4.3 Radio Link Reconfiguration Prepare
For which user services ?


4.3 Radio Link Reconfiguration Prepare [cont.]
Name screenings
0 Other
#0048 VS.RadioLinkSetupSuccess: Number of radio links successfully setup
1 Sig
#0049 VS.RadioLinkAdditionSuccess: Number of successful radio link addition 2 CsSpeech
3 CsSpeechPsDch
VS.RadioLinkReconfigurationPrepareSuccess: Number of successful
#0050 4 CsSpeechHsdpa
synchronized radio link reconfiguration preparation
5 CsSpeechPsDchPsHsdpa
VS.RadioLinkReconfigurationCommit: Number of radio link
#0051 6 CsSpeechPsDchPsDch
reconfiguration commit
7 CsData
VS.RadioLinkEstablishedPerCell: Average of the number of radio link 8 CsDataPsDch
#0052
established per cell 9 CsDataPsHsdpa
10 CsStr
VS.RadioLinkSetupRequest: Number of internal events that would lead to
#0054
a radio link setup request 11 PsDchDlDchUl
12 PsHsdpaDlEdchUl
VS.RadioLinkAdditionReq: Number of internal events that would lead to
#0055 13 PsHsdpaDchUl
a radio link addition request
14 PsHsdpaDlDchEdchUl
VS.RadioLinkReconfPrepReq: Number of internal events that would lead 15 PsDchPsDch
#0056
to a radio link reconfiguration prepare
16 PsDchPsHsdpa


4.3 Radio Link Reconfiguration Prepare [cont.]
Example of AMR-WB for very high

speech Quality
Narrow Band
Name
8000
VS.RadioLinkDroppedLastRadioLink: Number of
frequency (Hz)
6000
#53 radio links dropped which force the connection to
drop 4000
2000
UA06 screenings
0
0 DlAsCnfOther 0 1 2 3 4 5 6 7 8
seconds
1 DlAsCnfSig
2 DlAsCnfCsSpeechNbLrAmr Wide Band
3 DlAsCnfCsSpeechWbAmr
8000
4 DlAsCnfCsData
frequency (Hz)
6000
5 DlAsCnfCsStr
6 DlAsCnfPsIbPsStr 4000
7 DlAsCnfHsdpaDch 2000
8 DlAsCnfHsdpaEdch 0
0 1 2 3 4 5 6 7 8
seconds

DESCRIPTION
Speech on a wider band (50Hz-7kHz) than the classical telephony band (0.3kHz – 3.4kHz)
First address Mobile to Mobile communications
Can be used for Mobile to IP Phone
VALUE
Speech much more natural than classical telephony
Differentiator with Fix & GSM Networks & competition
AMR12.2 Radio engineering reusable for a WB-AMR12.65
DEPENDENCIES
Iu User Plane Frame Protocol v2 is necessary on IuCs
TFO/TrFO must be supported by the Core Network

5 RAB Establishment and
Troubleshooting Analysis


5 RAB Establishment and Troubleshooting Analysis
5.1 RAB Assignment Flow: Exercise
In which family of counters (number range?) will you find the counters related to the RAB assignment?
See previous section ☺
Find the counters shown below on the message flow relating to RAB assignment.
UE Node B RNC CN
RAB assignment req.

#?
S.R.L.R. Procedure
Internal RRM
decision to
establsht
Radio Bearer Setup

assign resources
RAB

#?
RAB assignment resp.

#?


5.2 RAB Assignment Success: counters
UE Node B RNC CN
Rab Establish. Requests Per RabType

#1656 RNC counter RAB assignment req.
#1620 Reference FDDCell counter
#1652 RB to be setup
Reference FDDCell counters

S.R.L.R. Procedure
CAC success
establsht
RAB
Radio Bearer Setup
RAB assignment success per Requested RAB type #1650 RB setup success
#1657 RNC counter
RAB assignment success per Granted RAB type RAB assignment resp.
#1658 RNC counter

VS.RabEstablishmentRequestsPerRabType #1656
RANAP/RAB assignment request message to setup a new RAB
• Sub-Counter #0: Other Dl, Ul, Traffic Class combinations

• Sub-Counter #1: Dl and Ul are CS Speech, TC is Conversational
• Sub-Counter #2: Dl and Ul are CSD 64, TC is Conversational
• Sub-Counter #3: Dl and Ul are CS, TC is Streaming
• Sub-Counter #4: Dl is any low rate PS I/B, Ul is any PS I/B, TC is Interative
• Sub-Counter #5: Dl is any low rate PS I/B, Ul is any PS I/B, TC is Background
• Sub-Counter #6: Dl is any high rate PS I/B, Ul is any PS I/B, TC is Interative
• Sub-Counter #7: Dl is any high rate PS I/B, Ul is any PS I/B, TC is Background
• Sub-Counter #8: Dl is any low rate Ps Str and Ul is any PS Str, TC is Streaming
• Sub-Counter #9: Dl is any high rate Ps Str and Ul is any PS Str, TC is Streaming
#1620 VS.RabEstabPerReqRabTypeRefCell is the same counter but at Reference cell level.

5.2 RAB Assignment Success: counters [cont.]
VS.RabEstablishmentSuccessPerRequestedRabType #1657: Number of successful RAB establishment

Switch to note view
per requested RAB type (to map the successes with
the requests) (per Rabid and not per procedure). This counter should also be pegged for RAB
successfully allocated for incoming relocations.
Screening: per requested RAB type (requested should be understood to be after RAB matching). The
screening is the same as for counter #1656.
#1665 VS.RabEstabSuccPerReqRabTypRefCell is the same counter but at Reference cell level.
VS.RabEstablishmentSuccessPerGrantedRabType #1658: Number of successful RAB establishment per

granted RAB type (per Rabid and not per procedure).
This counter should also be pegged for RAB successfully allocated for incoming relocations
Screening: per granted RAB type (granted should be understood to be after iRM Table matching).
A set of subcounters screened on: DlRbSetId,UlRbSetId,TrafficClass derived screening per granted Rab,

• Sub-Counter
4 1 44 #3: Dl and Ul are CS, TC is Streaming
#1621 VS.RabEstabSuccPerGrantedRabTypeRefCell is the same counter but at Reference cell level.

5.2 RAB Assignment Success: counters [cont.]
VS.RadioBearerSetupRequest #1652: Number of Radio Bearer setup decisions (leading or not to a RB

Switch to note view
Setup, ie. Incremented even if CAC rejects the setup). The counter should be pegged multiple times for
multiple RB to be setup in the same procedure. Incremented based on reference cell.
A set of subcounters screened on: Target Type of call setup mapping
• Sub-Counter #0: Other combinations

• Sub-Counter #1: CS Speech NB or LR AMR
• Sub-Counter #2: CS Speech WB AMR
• Sub-Counter #3: CS Data
• Sub-Counter #4: CS Streaming
• Sub-Counter #5: PS Streaming < 64
• Sub-Counter #6: PS Streaming 64
• Sub-Counter #10: PS I/B < 64
• Sub-Counter #11: PS I/B 64
• Sub-Counter #13:
9300 WCDMA TMO18268 9300 WCDMAPSUAO7
I/BR99256
QoS Analysis and Traffic Load Monitoring

• Sub-Counter #15: HSDPA/R99
• Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH
VS.RadioBearerSetupSuccess #1650: Number of Radio Bearer setup successfully. The counter should be
pegged multiple times for multiple RB successfully setup in the same procedure. Incremented on the
Reference cell of the call.
The screening is the same as for counter #1652.

5.3 VS.RadioBearerEstablishmentUnsuccess
Why could it fail ?
IMA = nE1 R99 over ATM

AAL2
AAL2
E1 Leased Lines
ATM Backbone MSC
x HSPA over IP
C Low Cost STM
Node B E Ethernet
Backhaul
M
UDP GigE IP Backbone SGSN
UDP
Iur
AAL2


5.4 RAB Assignment Preparation Failure
UE Node B RNC CN
RAB assignment request

RAB assignment req.
Invalid RAB parameters
or
CAC failure
#1629 RB establishment
unsuccess
#1662 RAB assignment setup unsuccess RAB assignment response

(RAB can not be established)
RNC counter
RAB establsht

VS.RadioBearerEstablishmentUnsuccess #1629: Number of radio bearer setup not successfully

established, with no RADIO_
BEARER_SETUP_REQUEST sent.(based on procedure count, not RBs). Incremented based on reference
cell. It mainly corresponds to CAC failure cases.
Screening: A set of detailed sub-counters is provided for troubleshooting purpose:
Sub-Counter #0: invalid RAB parameters value

Sub-Counter #1: unavailable dl code resources
Sub-Counter #2: unavailable dl power resources
Sub-Counter #3: Unspecified
Sub-Counter #4: RL failure or RLC error
Sub-Counter #5: Unused
Sub-Counter #6: CAC RNC Processing resources
Sub-Counter #7: NodeB (CEM) lack of L1 resources
Sub-Counter #8: Lack of transport identifier on the Iu
Sub-Counter #9: Lack of bandwidth on the Iu
Sub-Counter #10: Lack of transport identifier on the Iur
Sub-Counter #11: Lack of bandwidth on the Iur
Sub-Counter #12: Lack of transport identifier on the Iub
Sub-Counter #13: Lack of bandwidth on the IuB
VS.RabAssignmentSetupUnsuccess #1662: Number of RAB assignment unsuccessfully setup (per RAB Id,
and not per message). This
counter should also be pegged when a RAB fails to be allocated for an incoming relocation.

5.5 RAB Assignment Execution Failure
UE Node B RNC CN
RAB assignment request

Valid RAB parameters
and
CAC success
S.R.L.R. Procedure
Radio Bearer Setup #602[1] RB setup unsuccess
Radio Bearer Setup Failure Reference FDDCell counter

#602
or No response from UE
#602[0] RB setup unsuccess
RAB assignment response

(RAB can not be established)
#1662 RAB assignment setup
RAB establsht
unsuccess
RNC counter

VS.RadioBearerSetupUnsuccess #602: Number of failed Radio-bearer Establishments per cell. This measurement
provides the number of RB establishment procedures failures, screened by establishment failure cause, for each cell
controlled by the RNC which is the primary cell.
During such a procedure, the measurement attached to a given cell is incremented if the cell is in the primary cell of
the active set of the involved UE.
Screening:
#0 ---> Time-out expired without reception of a RADIO BEARER SETUP COMPLETE message or a RADIO BEARER
SETUP FAILURE message.
#1 ---> Reception of a RRC RADIO BEARER SETUP FAILURE message.
#2 ---> Any other failure causing a RB setup procedure to be unsuccessful.
VS.RabAssignmentSetupUnsuccess #1662: Number of RAB assignment unsuccessfully setup (per Rabid, and not per
message). This
counter should also be pegged when a RAB fails to be allocated for an incoming relocation.
DlRbSetId,UlRbSetId,TrafficClass derived screening per requested Rab


5.6 RAB Assignment: RNC Counter Tree
RNC counters
Request VS.RabEstablishmentRequestsPerRabType
#1656
Failure Success
#1662 #1657
#1658
VS.RabAssignmentSetupUnsuccess
VS.RabEstablishmentSuccessPerRequestedRabType
VS.RabEstablishmentSuccessPerGrantedRabType
RAB establsht


5.7 RB Establishment: Cell Counter Tree
Request VS.RadioBearerSetupRequest
#1652
Preparation Failure Attempt

#1629 #1650 + #602
VS.RadioBearerEstablishmentUnsuccess
Invalid RAB params

#1629[0] Execution failure Success
#602 #1650
CAC failures
VS.RadioBearerSetupUnsuccess VS.RadioBearerSetupSuccess
#1629[1-13]
No answer from UE #602[0]
RAB establsht
RB setup failure from UE #602[1]
Any other kind of failure UE #602[2]


5.8 RAB Assignment Success Rate (RNC level)
RNC metrics
URAB011_R_CsSpeech
Voice
VoiceRAB
RABAssignment
Assignmentsuccess
successrate
rate == #1657.[1]
#1657.[1]//#1656.[1]
#1656.[1]
URAB011_R_CsVideo
Video
VideoRAB
RABAssignment
Assignmentsuccess
successrate
rate == #1657.[2]
#1657.[2]//#1656.[2]
#1656.[2]
URAB011_R_Cs
Video
VideoRAB
RABAssignment
Assignmentsuccess
successrate
rate == #1657.[1-3]
#1657.[1-3]//#1656.[1-3]
#1656.[1-3]
URAB011_R_Ps
RAB establsht
PS
PSRAB
RABAssignment
Assignmentsuccess
successrate
rate ==#1657.[0,4-9]
#1657.[0,4-9]//#1656.[0,4-9]
#1656.[0,4-9]


5.9 RB To Be Setup Success Rate (CELL level)
Reference FDDCell metrics
#1650.[1,2]
Voice
VoiceRB
RBto
tobe
besetup
setupsuccess
successrate
rate =
#1652.[same screenings]
#1650.[3]
Video
VideoRB
RBto
tobe
besetup
setupsuccess
successrate
rate ==
URB007_C_Ps
#1650.[0,5-16]
PS
PSRB
RBto
tobe
besetup
setupsuccess
successrate
rate==
URB007_C
#1650.[all]
RAB establsht
RB
RBto
tobe
besetup
setupsuccess
successrate
rate==
#1652.[same
URB007_C screenings]

5.10 RAB Analysis: Failure analysis
RAB assignment analysis
Network level RAB panel RNC
level
RB panel Fddcell
level
RAB assignment SR Establishment
URAB011 < Th failure cause
Refer to the
distribution of
RB Establishment
Unsuccess causes Mean RB Blocking rate Is
During BH > Th
ons and KP
IAL a ggregati
, SPAT
e in TIME
he issu RB blocked
terize t
Charac
RB blocked RB blocked
due to Lack of due to Lack of due to Unspecified
RB blocked DL codes DL Power reasons
due to Lack of
other resources
Determine the RNC Determine the RNC Determine the RNC
with lack of DL codes with lack of DL Power with Unspecified reasons
PS or CS RAB PS or CS RAB PS or CS RAB

Iur & Iu capacity analysis Rejected ? Rejected ? Rejected ?
RNC Level
PS/CS DL codes PS/CS DL Power PS/CS

Iub Capacity analysis
Capacity analysis Capacity analysis HW Capacity analysis
NodeB Level
RNC Level RNC Level RNC Level
RAB establsht

Can it affect certain/all services (CS, PS, etc)?
Correlation between 2 parallel analysis
RB failure analysis per cause of failure (#0631 and #602)
RB failure analysis per type of call setup (# 0691 and #0687)
For troubleshooting.
RB blocking panel - it contains RB failure counters
Radio Bearer panel - it contains RB data per service+other metrics
Radio Link Management panel
List of counters described in the previous slides

6 IuSCCP Troubleshooting Analysis


6.1 Exercise: Iu SCCP Connection procedure
1. Find the counters associated with the successful and failed SCCP connections requested
by RNC at Iu interface for CS services.
2. Locate them on the chart
Help/reference:
UMTS access counter list (look at the “SCCP” RNC counter family)
UE Node B RNC CN
(…)
SCCP connection req.

SCCP
conn.
SCCP connection confirm


6.1 Exercise: Iu SCCP Connection procedure [cont.]
With the counters you identify at the previous step, define the following metrics:
Iu
IuSCCP
SCCPsuccess
successrate
rate ==
CS
CS Iu
IuSCCP
SCCPsuccess
successrate
rate ==
PS
PSIu
IuSCCP
SCCPsuccess
successrate
rate ==
SCCP conn.


6.2 SCCP Connection: Success Flow
RNC counter
UE Node B RNC CN
#548[0,1]:
successful SCCP connections
initiated by RNC at Iu interface SCCP connection request
Call
Setup
2G->3G
#548[2,3]: or
successful SCCP connections SCCP connection request
3G->3G
initiated by CN at Iu interface Inter-Freq
HHO
SCCP conn.

VS.IuSccpCnxSuccess #548: This counter provides the number of successful SCCP connections at Iu
interface, screened by CN domain and by peer entity having refused the connection.
Screening:
• Sub-Counter #0 : With CS core network (connection requested by RNC)
• Sub-Counter #1 : With PS core network (connection requested by RNC)
• Sub-Counter #2 : With CS core network (connection requested by core network)
• Sub-Counter #3 : With PS core network (connection requested by core network)

6.3 SCCP Connection: Failure Flow
RNC counter
UE Node B RNC CN
#502[1,3]:
unsuccessful SCCP connections SCCP connection request
initiated by RNC at Iu interface Call
Setup
SCCP connection refused
#502[0,2]: 2G->3G
unsuccessful SCCP connections or
SCCP connection request
intiated by CN at Iu interface 3G->3G
Inter-Freq
HHO
SCCP connection refused
SCCP conn.

VS.IuSccpCnxUnsuccess #502: This counter provides the number of failed SCCP connections at Iu
interface, screened by CN domain and by peer entity having refused the connection.
Screening:
• Sub-Counter #0 : Fail Iu-cs connection req by Rnc
• Sub-Counter #1 : Fail Iu-cs connection req by Core Network CS
• Sub-Counter #2 : Fail Iu-ps connection req by Rnc
• Sub-Counter #3 : Fail Iu-ps connection req by Core Network PS

6.4 SCCP Connection : Counter Tree
RNC counters
Request by RNC VS.IuSccpCnxSuccess + VS.IuSccpCnxUnsuccess

#548[all] + #502[all]
Failure Success
#502[all] #548[all]
VS.IuSccpCnxUnsuccess VS.IuSccpCnxSuccess
SCCP conn.


6.5 Iu SCCP Analysis (success rates initiated by the RNC)
RNC metrics
#548.[0,1]
UIuSCCP006_R_Cs
#548.[0,1] + #502.[0,2]
#548.[0,2]
CS
CSIu
IuSCCP
SCCPsuccess
successrate
rate==
#548.[0,2] + #502.[0,1]
UIuSCCP006_R_Ps
#548.[1,3]
PS
PSIu
IuSCCP
SCCPsuccess
successrate
rate==
#548.[1,3] + #502.[2,3]
SCCP conn.


6.6 Iu SCCP analysis method
Iu SCCP Analysis –
RNC level
Low CS/PS Iu SCCP Connection success rate

UIuSCCP006 in all RNCs
of the same core network?
Yes No
Core outage
(upgrade, failure or
issue clearly First RNC
identified as core in this UTRAN version release?
issue?
Yes No
Yes No
No investigation •HW Stability Analysis –
needed RNC – MSC Interface/ Analysis of CR fixes •Configuration Audit
RNC-SGSN Intefaces And evolution introduced •Parameter correlations
•CTg traces Configuration Audit with other RNCs
•Iu traces

Problem description.
Failures in Iu SCCP connection phase. It can lead to accessibility failures.
Detection
Iu SCCP Connection Success rate is less than 99%.
• Iu CS or Iu PS issue?
• Affecting all RNC/only specific RNC
• Punctual degradation that disappear? Or degradation remains?
• Certain/all period of time, since when
The Iu SCCP analysis aims at identifying the period of the degradation of the Iu SCCP success rate and the
level of degradation: in all the RNC in PS and CS domain
When the period and the network element level has been determined correlation with alarms:
- HW Failures at SGSN
- HW Failures at MSC
- HW Failures at RNC
Main limitation of the SCCP connection metrics is that signaling is also considered
Action
For RNC stability analysis refer to Stability Monitoring module

GQ01
GQ02
GQ03
OQ01
OQ02
OQ03
OQ04
KQ01
KQ02
29/09/2006
CS Iu SCCP success rate
27/09/2006
25/09/2006
23/09/2006
21/09/2006 15/10/06
14/10/06
19/09/2006 13/10/06
17/09/2006 12/10/06
11/10/06
15/09/2006 10/10/06
PS Iu SCCP success rate
09/10/06
13/09/2006 08/10/06
07/10/06
11/09/2006
06/10/06
09/09/2006 05/10/06
04/10/06
Iu SCCP PS success rate (IuSCCP006)

07/09/2006 03/10/06
02/10/06
What could you say about IuSCCP performances ?
05/09/2006 01/10/06

30/09/06
03/09/2006
29/09/06

01/09/2006 28/09/06
27/09/06

100.00%
99.50%
99.00%
98.50%
98.00%
97.50%
97.00%
96.50%
96.00%
26/09/06

25/09/06
24/09/06
23/09/06
29/09/2006 22/09/06
21/09/06
CS Call Setup Success Rate
Analyse metric graphs given bellow !
27/09/2006 20/09/06
19/09/06
25/09/2006 18/09/06
17/09/06
23/09/2006 16/09/06
15/09/06
21/09/2006 14/09/06
13/09/06
19/09/2006 12/09/06
11/09/06
17/09/2006 10/09/06
09/09/06
08/09/06
15/09/2006 07/09/06
06/09/06
13/09/2006 05/09/06
PS Call Setup Success Rate

04/09/06
11/09/2006 03/09/06
02/09/06
6.7 Case Study
09/09/2006 01/09/06
31/08/06
07/09/2006 30/08/06
29/08/06
05/09/2006 28/08/06

27/08/06
03/09/2006 26/08/06
25/08/06
24/08/06
01/09/2006
23/08/06
22/08/06
100.00%
98.00%
96.00%
94.00%
92.00%
90.00%
21/08/06
4 1 62
100.00%
99.00%
98.00%
97.00%
96.00%
95.00%

6.7 Case Study
6.7.1 Compare CS and PS Iu SCCP efficiency
100.00%
100.00%
98.00%
99.50%
96.00% 99.00%
98.50%
94.00% 98.00%
97.50%
92.00% 97.00%
96.50%
90.00%
96.00%
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
PS Call Setup Success Rate CS Call Setup Success Rate PS Iu SCCP success rate CS Iu SCCP success rate
Iu CS or Iu PS issue? PS
Affecting all RNC/only specific RNC ?
Punctual degradation that disappear?Or degradation remains? Punctual 28/09/05


6.7 Case Study
6.7.2 Compare RNCs
Iu SCCP PS success rate (IuSCCP006) UA4.2 Operator example

100.00%
GQ01
99.00% GQ02
GQ03
98.00%
KQ01
97.00% KQ02
96.00%
OQ01
OQ02
95.00%
OQ03
21/08/06
22/08/06
23/08/06
24/08/06
25/08/06
26/08/06
27/08/06
28/08/06
29/08/06
30/08/06
31/08/06
01/09/06
02/09/06
03/09/06
04/09/06
05/09/06
06/09/06
07/09/06
08/09/06
09/09/06
10/09/06
11/09/06
12/09/06
13/09/06
14/09/06
15/09/06
16/09/06
17/09/06
18/09/06
19/09/06
20/09/06
21/09/06
22/09/06
23/09/06
24/09/06
25/09/06
26/09/06
27/09/06
28/09/06
29/09/06
30/09/06
01/10/06
02/10/06
03/10/06
04/10/06
05/10/06
06/10/06
07/10/06
08/10/06
09/10/06
10/10/06
11/10/06
12/10/06
13/10/06
14/10/06
15/10/06
OQ04
Iu CS or Iu PS issue? PS To correlate with O&M
Affecting all RNC/only specific RNCAll tracking event:
RNCs Upgrades/outages/alarms
Punctual degradation that disappear?Or in PS Core Network
degradation remains? Punctual 28/09/05


7 Security Mode Troubleshooting
Analysis


7 Security Mode Troubleshooting Analysis
7.1 Security Mode Success: Flow
UE Node B RNC CN
RRC connection
Radio Link Setup Response

Measurement Control
SCCP connection req.
SCCP
conn.
Security mode command

Security
mode
Common id
Security mode complete
Security mode complete

#701[0,1]
successful Security Mode procedures

VS.SmcSuccess #701: This counter provides the number of successful RANAP Security Mode Command
procedures screened by Core Network domain.
Screening:
0 : SMC on Iu-CS
1 : SMC on Iu-PS

7.2 Security Mode Failure: RNC
RNC counter
UE Node B RNC CN
#702[0,1] Security mode reject

rejected Security Mode procedures
Cause =
"Requested Ciphering
and/or
Integrity Protection Algorithms
not Supported"
Security mode

VS.RejectedSmc #702: This counter provides the number of failed RANAP Security Mode Command
procedures (before sending the RRC SMC) screened by Core Network domain.
Screening:
0 : SMC on Iu-CS
1 : SMC on Iu-PS

7.3 Security Mode Failure: UE
UE Node B RNC CN
Security mode failure

1s t Security mode reject
c as e #703[0,1] Cause =
failed Security Mode procedures same as in previous page

2n d No answer from UE
Security mode reject
c as e
#703[0,1] Cause =
Security mode
failed Security Mode procedures "Failure in the Radio Interface Procedure”
RNC counters
VS.FailedRrcSmc #703: This counter provides the number of failed RRC Security Mode Command
procedures screened by Core Network domain.
Screening:
0 : SMC on Iu-CS
1 : SMC on Iu-PS

7.4 Security Mode Command Success Ratio
RNC metrics
USMC002_R_Cs
Core
CoreCSCS #701.[0]
Security
SecurityMode
Mode =
Cmd
Cmd successratio
success ratio #701.[0] + #702.[0] + #703.[0]
USMC002_R_Ps
Core
CorePSPS #701.[1]
Security
SecurityMode
Mode =
Cmd
Cmdsuccess
successratio
ratio #701.[1] + #702.[1] + #703.[1]
Security mode


7.5 Ciphering analysis
If the SMC Failure rate is high, it means that the accessibility performance
results are weak due to Ciphering phase.
SMC failures can affect to signaling procedures (LAU, RAU…) but also calls.
There is no way to split the failures in traffic/signaling, so some signaling
failures could mask the call success rate,
If the RNC receives a certain number of consecutive RRC messages with wrong
integrity data, it requests to release the call by sending a RANAP Iu Release
Request with cause Repeated Integrity Protection Check Failure to the Core.
As for SCCP Connection problems, SMC Failures are investigated thanks to Call
Trace post-processing.


8 Call Setup Success Rate
Troubleshooting Analysis


8 Call Setup Success Rate Troubleshooting Analysis
8.1 Exercise
Using the formerly defined metrics define the Call Setup Success
Rate formula !
Call
Callset
setup
up
success
=
successrate
rate


8.1 Exercise [cont.]
This page is intentionally left blank


8.2 Call Set Up Success Rate
UCSSR005_R_Cs RNC metrics

Call
Callset
setup
up URRC013_CR_Cs
success rate = x UIuSCCP006_R_Cs
successrate
RRC connection
CS x URAB011_R_Cs
CS
URRC013_CR_Cs = RRC connection success rate for CS calls only
SCCP conn.
UIuSCCP006_R_Cs = Iu SCCP success rate

URAB011_R_Cs = RAB establishment success rate per requested RAB
Security mode
UCSSR005_R_Ps
Call
Callset
setup
up URRC013_CR_Ps
success rate = x UIuSCCP006_R_Ps
successrate
RAB establsht
PS x URAB011_R_Ps
PS

The call set up success rate at RNC indicates the rate of successful call establishment vs. call
establishment attempts.
Product of RRC success rate (calls only) * Iu SCCP success rate * RAB establishment success rate * SMC
success rate should be the complete formula but NPO considers the performance of the Security
Mode Command procedure apart.

8.3 Accessibility Troubleshooting Chart
Network Accessibility Analysis –
RNC level
Call setup success rate No

UCSSR005_R < Th
Yes Low CSSR with Ciphering
Low No
SMC success rate
SMC002
Top N Cells
RRC Connection Iu SCCP Connection Yes CSSR
RAB Assignment Success rate
Success rate Success rate
URAB011 < Th
URRC0013 < Th UIuSCCP006 < Th
Ciphering Analysis –
RNC level
Iu SCCP Analysis –
RNC level CTg Analysis –
Cell level
RAB Assignment Analysis –
RRC Connection Analysis – RNC level
RNC/ Cell level

1. Check the sub-metrics which CSSR is made to identify from which one is coming the decrease.
RRC Connection success rate
Global RAB assignment success ratio
Iu SCCP Success rate
In case of accessibility issues during SMC procedure, look into SMC metrics
Split the metric into PS/CS
2. One the metric that has the problem identified, it’s time to go in a detail level.
The RNC where is coming the problem is identified.
Is the problem coming from some specific fddcells or is homogenous? In this case if the degradation of
performance is produced randomly may be produced by one specific UE. To detect the kind the mobile
is causing this (IMSI, IMEI…) is recommendable to put a CTg, The time to put to CTg will depend on
the trigger of an alarm based on fddcell RRC thresholds.
In this step it’s also identified the specific time where the degradation is occurring.
3. Use specific troubleshooting reports per fddcell depending on which step is coming the problem
4. Check the radio part and the capacity or blocking depending on with of the phases the problem come.
5. Check the radio part and the capacity or blocking depending on with of the phases the problem come.
The following subjects are defining in the next chapters.
RF Audit – fddcell
BTS RF Power
OVSF Codes
BTS Channel elements
Iub Interface
RNC-TMU

8.4 Case Study
Analyse metric graphs given below !
What is your conclusion ?
100.00%
98.00%
96.00%
94.00%
92.00%
90.00%
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
PS Call Setup Success Rate CS Call Setup Success Rate
100.00%
99.00%
98.00%
97.00%
96.00%
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
PS RRC Connection success rate CS RRC Connection success rate
PS First RRC Connection success rate CS First RRC Connection success rate


8.4 Case Study [cont.]
100.00%
98.00%
100.00%
96.00%
99.00%
94.00% 98.00%
92.00% 97.00%
90.00% 96.00%
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
PS RRC Connection success rate CS RRC Connection success rate
PS First RRC Connection success rate CS First RRC Connection success rate
PS Call Setup Success Rate CS Call Setup Success Rate
100.00% 100.00%
99.50%
99.00% 99.00%
98.50%
98.00% 98.00%
97.00% 97.50%
97.00%
96.00% 96.50%
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
96.00%
01/09/2006
03/09/2006
05/09/2006
07/09/2006
09/09/2006
11/09/2006
13/09/2006
15/09/2006
17/09/2006
19/09/2006
21/09/2006
23/09/2006
25/09/2006
27/09/2006
29/09/2006
PS RAB Establishments success rate RAB type
CS RAB Establishments success rate RAB type
PS Iu SCCP success rate CS Iu SCCP success rate


8.5 Other formula for Call Set Up Success Rate CS
UCSSR006_CS_DR_AllCell RefCell + RemoteCell
Call URRC021_CR_Cs
Callset
setup
up
success rate = x (1- URB017_CR_Cs)
RRC connection
success rate x URAB042_AllCell

CS
CS
URRC021_CR_Cs =
SCCP conn.
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
(1- URB017_CR_Cs) = Signalling Radio Bearer Retainability =
Security mode
Probability of maintaining the RRC connection after it has been

established
URAB042_AllCell =
RAB establishment success rate per requested RAB including Directed
RAB establsht
Retry success to 2G and taking into account RAB establishment Cancels

from MSC


8.6 Other formula for Call Set Up Success Rate PS
UCSSR007_AllCell RefCell + RemoteCell
Call URRC021_CR_Ps
Callset
setup
up
success rate = x (1- URB017_CR_Ps)
RRC connection
success rate x URAB017_AllCell

PS
PS
URRC021_CR_Ps =
SCCP conn.
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
(1- URB017_CR_Ps) = Signalling Radio Bearer Retainability =
Security mode
Probability of maintaining the RRC connection after it has been

established
URAB017_AllCell =
RAB establishment success rate per requested RAB taking into account
RAB establsht
RAB establishment Cancels from MSC



for this module


End of Module


51
Section 5
Retainability Monitoring
Module 1
9300 WCDMA

Blank Page

Document History
02 Charneau, Jean-Noel • update of screenings of some counters

• removal of indicator UIU006_C_Ps
• modification of UIU022_C_Ps
• addition of explanation of missing screenings
of Iu release request counters

Module Objectives
Describe the retainability metric family

Analyze each metric




Table of Contents
Page
1 Retainability analysis 7
1.1 Call Drop: Definition 8
1.2 Network Retainability Performance 9
1.3 Call Drop: RL Failure detected by RNC 10
1.4 Call Drop: RLC Unrecoverable Error detected by UE 12
1.5 Call Drops due to UTRAN generated reasons 13
1.6 IuReleaseRequest causes 14
1.7 Call Drop Rate: RNC level 19
1.8 CS Call Drop Rate: Reference FDDCell level 20
1.9 PS Call Drop Rate: Reference FDDCell level 21
1.10 Part of call drop: radio connection lost with UE 23
2 Retainability troubleshooting 24
2.1 Call Drop Rate Analysis 25
2.2 Retainibility issues causes 26
2.3 Compare Cs, PS and SRB drop rates 27
2.4 Compare Drop cause 28
2.5 Typical radio problems in a W-CDMA network 29
2.5.1 Detection of bad radio conditions 30
2.5.2 Missing neighbor - Impact 31
2.5.3 Missing neighbor – Detection and solution 32
2.5.4 Isolated site - Impact 33
2.5.6 Isolated site - Detection and solution 34
2.5.7 Radio pollution - Impact 35
2.5.8 Radio pollution - Detection and solution 36
515 Self-Assessment on the Objectives All Rights Reserved © Alcatel-Lucent 2010
37
End9300ofWCDMA
9300 WCDMA TMO18268 Module
UAO7 R99 QoS Analysis and Traffic Load Monitoring 38


Retainability Monitoring This page is left blank intentionally

1 Retainability analysis


1.1 Call Drop: Definition
User view
call drop is seen as a service interruption
mainly perceived for CS calls (voice, video calls)
data service almost never broke off (throughput degradation only)
UTRAN system view
call drop is seen as an abnormal RAB release initiated by the RNC
affects CS and PS services as well
data service is often resumed by UE or CN after a PS drop
CN system view
closer to User view than UTRAN system view

When a RAB or a list of RABs must be reset for any reason, i.e: normal release or abnormal release, a
RANAP Release procedure has to be triggered almost every time.
In UMTS standard, there are different ways at RANAP protocol level, to release a RAB, or a list of RABs
related to a particular UE:
• RAB Release request: triggered by the RNC, requesting the CN to release a particular RAB or a set of
RABs for a specific UE. RRC connection may still active.
The Core network may trigger or a RAB Assignment procedure or an Iu Release procedure.
• Iu Release request: triggered by the RNC, requesting the CN to release the Iu connection related to a
specific UE. This will release all the RABs (PS+CS) related to that UE. RRC connection is also released.
The CN could respond with Iu Release command.
• RAB Assignment request: triggered by the CN (or response to the RAB release request) and asking the
RNC to release one or a list of RABs.
• Iu Release command: Triggered by the CN (or response to the RAB release request or Iu release
request) and asking the RNC to release all the resources (RRC + RBs) of a UE.
Call drop counters are be counted on the messages described above per Reference FDDCell and per
DlAsConfId or at least per CN domain (CS,PS).

1.2 Network Retainability Performance
The objective of the retainability metrics is to evaluate the ability of

the network to provide reliable service to the end user.
If and only if a call is dropped, the RNC sends the RANAP Iu Release
Request message with the field abnormal reasons.
Most of the call drops are due to Radio Problems between UE and
UTRAN


1.3 Call Drop: RL Failure detected by RNC
UE Node B RNC CN
Loss of UL synchro
FDDCell counter
detected on last RL #53 Last Radio Link drops
Radio Link
Failure Indication
rrcReestPSMaxAllowedTimer
rrcReestCSMaxAllowedTimer
expiry
Iu Release Request
#576[4] Iu release request CS “UTRAN generated reason”
#599[6] Iu release request PS
Reference FDDCell counters Iu Release Command
#595[x] Iu abnormal release request CS

#589[x] Iu abnormal release request PS
Radio Link Reference FDDCell counters

Question: Deletion Req
What is the difference
Radio Link
between #576 & #595 ? Deletion Resp Iu Release Complete
VS.IuReleaseReqCs - #576
Number of RANAP/IU_RELEASE_REQUEST sent by RNC to CoreNetwork CS
A set of subcounters screened on: Reason to send Release Request CS Cause
• Sub-Counter #0: OAM Intervention • Sub-Counter #1: Unspecified Failure
• Sub-Counter #2: Repeated Integrity Check Failure • Sub-Counter #3: UE generated signalling cnx
release
• Sub-Counter #4: Radio cnx with UE lost • Sub-Counter #5: Abnormal condition with cause
TRelocOveral expiry
• Sub-Counter #6: Other causes • Sub-Counter #7: DL RLC error on SRB
• Sub-Counter #8: UL RLC error on SRB • Sub-Counter #9: T360 Expiry
• Sub-Counter #10: Connection with NodeB lost. • Sub-Counter #11: Release due to UTRAN
Generated Reason
• Sub-Counter #12: No Remaining RAB • Sub-Counter #13: Failure in the Radio Interface
Procedure
• Sub-Counter #14: No Resource Available
VS.IuAbnormalReleaseRequestCs - #595
This measurement represents the number of Iu CS release requests due to abnormal conditions.
A set of subcounters screened on: Derived AsConf Screening for CS DlAsConfId:
• Sub-Counter #1: Signalling Only • Sub-Counter #2: CS speech NB or LR AMR

• Sub-Counter #3: CS speech WB AMR • Sub-Counter #4: CS data
• Sub-Counter #5: CS Streaming 57.6 • Sub-Counter #6: CS Streaming 14.4
• Sub-Counter #7: Any PS

1.3 Call Drop: RL Failure detected by RNC [cont.]
VS.IuReleaseReqPs - #599
Switch
A set of to notes
subcounters view!
screened on: Release Request Cause PS
• Sub-Counter #0: User Inactivity • Sub-Counter #1: IU User Plane Failure
• Sub-Counter #2: OAM Intervention • Sub-Counter #3: Unspecified Failure
• Sub-Counter #4: Repeated Integrity Check Failure • Sub-Counter #5: UE generated
signalling cnx release
• Sub-Counter #6: Radio cnx with UE lost • Sub-Counter #7: Abnormal condition
with cause TRelocOveral expiry
• Sub-Counter #8: DL RLC error on SRB • Sub-Counter #9: UL RLC error on SRB
• Sub-Counter #10: DL RLC error on TRB • Sub-Counter #11: UL RLC error on TRB
• Sub-Counter #12: T360 Expiry • Sub-Counter #13: Connection with
NodeB lost.
• Sub-Counter #14: Release due to UTRAN Generated Reason • Sub-Counter #15: No Remaining RAB
• Sub-Counter #16: Failure in the Radio Interface Procedure • Sub-Counter #17: No Resource Available
• Sub-Counter #18: Whenever timer T_305_PERIOD._UPDATE expires. Pegged on the cell the UE is in
Cell_FACH
• Sub-Counter #19: Cell Reselection failure pegged whenever the number of cell update retries is
decremented to zero - on the cell the Cell Update message was received
• Sub-Counter #20: UTRAN Paging Failure pegged whenever the number of paging retries reaches zero -
on the FDDcell MO
• Sub-Counter
5 1 11 #21: Physical Channel Re-establishment
failure pegged on Cell Update cause Radio Link
failure in response to a Cell Update confirm message - on the cell the Cell Update message was received
VS.IuAbnormalReleaseRequestPs - #589
This measurement represents the Number of Iu Release Requests due to abnormal conditions sent
towards the PS domain, when the reference cell of these calls is located on the serving RNC.
A set of subcounters screened:
• Sub-Counter #0: Other type of Call • Sub-Counter #1: Signalling Only
• Sub-Counter #2: PS Streaming < 64 • Sub-Counter #3: PS Streaming 64
• Sub-Counter #4: PS Streaming 128 • Sub-Counter #5: PS Streaming 256
• Sub-Counter #6: PS Streaming 384 • Sub-Counter #7: TRB on cell FACH
• Sub-Counter #8: PS I/B < 64 • Sub-Counter #9: PS I/B 64
• Sub-Counter #10: PS I/B 128 • Sub-Counter #11: PS I/B 256
• Sub-Counter #12: PS I/B 384 • Sub-Counter #13: HSDPA
• Sub-Counter #14: xPCH • Sub-Counter #15: Any CS
VS.RadioLinkDroppedLastRadioLink - #53
Number of dropped calls (on last radio-link release), for each cell controlled by the RNC.
A set of subcounters screened on: Type of call for dropped last radio link
• Sub-Counter #0: Other Type of Call • Sub-Counter #1: SRB (DCH or cell FACH)
• Sub-Counter #2: CS speech NB or LR AMR • Sub-Counter #3: CS speech WB AMR
• Sub-Counter #4: CS data • Sub-Counter #5: Any CS Streaming
• Sub-Counter #6: Any PS I/B or PS Streaming • Sub-Counter #7: HSDPA DL/DCH UL
• Sub-Counter #8: PS I/B or PS Str HSDPA DL/E-DCH UL

1.4 Call Drop: RLC Unrecoverable Error detected by UE
UE Node B RNC CN
RLC failure
detected on SRB Reference FDDCell counters
Cell Update
“RLC unrecoverable error, RLC_AM SRB”
Iu Release Request
#576[8] Iu release request CS “UTRAN generated reason”
#599[9] Iu release request PS
Iu Release Command
#595[x] Iu abnormal release request CS
#589[x] Iu abnormal release request PS
Radio Link
Deletion Req
Radio Link
Deletion Resp Iu Release Complete
#594 Iu release complete CS

VS.IuReleaseCompleteCs #594: Number of times the RNC sends an Iu release complete on Iu-CS
interface to MSC. It corresponds to all cases of Iu release scenario, normal and abnormal.
• Sub-Counter #0: Other

• Sub-Counter #1: Signalling Only
• Sub-Counter #2: CS speech NB or LR AMR
• Sub-Counter #3: CS speech WB AMR
• Sub-Counter #4: CS data
• Sub-Counter #5: CS Streaming 57.6

1.5 Call Drops due to UTRAN generated reasons
Any Iu Release Request message sent, due to an abnormal or normal
cause, is counted in
VS.IuReleaseReqCs #576 for CS
Normal cause : screening
#3 : UE generated signalling cnx release
#12: No Remaining RAB
Abnormal cause: any other screening
VS.IuReleaseReqPs #599 for PS

Normal cause screenings:
#0: User inactivity (Always-On to PMM-Idle)
#5: UE generated signalling cnx release
#15: No Remaining RAB
Abnormal cause screenings: any other
All call drops generated by UTRAN are counted each time an Iu Release
Request message is sent due to an abnormal cause
VS.IuAbnormRelReqCs #595 for CS VS.IuAbnormRelReqPs #589 for PS
Each RAB dropped leads to peg a sub-counter
The normal cases are :

- Release due to UE generated signalling connection release
- User inactivity (in case of always on)
- Last Remaining RAB
All Other cases are considered as abnormal.

The abnormal cases currently covered are the following ones :
- O&M intervention
- Repeated integrity check failure
- Radio connection lost
- Relocation timeout (corresponding to timeout of TrelocoverallExpiry and TrelocCompleteExpiry)
- Unspecified failure

1.6 IuReleaseRequest causes
Screenings Condition for pegging
OamIntervention When an equipment or interface is locked, leading to the drop

of the RABs using this resource
UnspecifiedFailure In case of failure in Radio Procedure (RL Setup failure, RL

Reconf failure, RB Reconf failure, Active Set Update failure), or
internal RNC or BTS product defect
RepeatedIntegrity In case of Ranap Security Mode integrity check activation, when

CheckFailure nIntegrityCheckFail (2) successive RRC connection oriented
messages decoding failed
UE generated When the UE sends a RRC “Signalling Connection Release

signalling cnx release indication” to the RNC, due to:
Network authentication check failure during call setup
PS inactivity (pseudo Always-On managed by specific UEs)


1.6 IuReleaseRequest causes [cont.]
Screenings Conditions for pegging
RadioConnection In case of a single Radio Link established with the UE, when a
WithUeLost NBAP “UL Radio Link Failure indication” message is sent by the
NodeB to the RNC, because of the loss of UL synchronisation
DlRLCErrSRB When the RNC is not receiving the UE RLC acknowledgments for
DlRLCErrTRB* the DL PDUs sent, the iNode indicates a loss of RLC.
Note: this can be caused by bad DL radio conditions (the PDU is
corrupted and not acknowledged by the UE) or bad UL radio
conditions (the PDU is acknowledged by the UE but this
acknowledgement is not received by the RNC).
* DlRLCErrTRB is used in RLC AM mode only
T360 Expiry RB Release Complete or RB Release Failure not received from

UE before T360 Expiry

(*): PS cause only

UlRLCErrSRB when the UE is not able to sent packets RLC in acknowledged

UlRLCErrTRB* mode, it sends a “Cell Update” message (UM) with the cause
“RLC Unrecoverable Error”. In that case, the UL RLC Error
screening is incremented and the communication is released
* UlRLCErrTRB is used in RLC AM mode only
AbnormalCondition When a HHO fails due to RNC timer expiry (no answer from CN
Timer Trelocoverall nor from UE), call is drop during the HHO
Expiry
No Remaining RAB When a Iu Release Request follows the Normal Release of the
last RAB established with the UE
T305 Expiry When a the RNC does not receive a Periodical Cell Update from
the UE before T305 expiry

(*): PS cause only

Connection with loss of AAL2, SSCOP, NBAP RESET, RSI other than those reasons
NodeB lost already covered by "O&M intervention"
Release due to UTRAN RB Reconfiguration Complete or RB Reconfiguration Failure not

Generated Reason received from UE before T361 Expiry
Failure in the Radio RB Setup Failure received from UE during RAB establishment or
Interface Procedure Security Mode Command failure after RRC Connection is
setup
No Resource Available Failure in Upgrading or Upsizing a RB because of a lack of Radio

Resource (code, power, transport, CEM processing)

(*): PS cause only

Cell Reselection Fail No answer from UE in Cell_FACH state during a Cell Reselection
procedure after Cell Update Confirm has been sent to UE up to
1+ N362 times
UTRAN Page Fail When the UE in Cell_PCH state has not answered to the last
repetition of the same Paging Type 1 message
Physical Channel When the UE in URA_PCH state is responding by a Cell Update

Reestablishment Fail “Radio Link Failure” to the Cell Update Confirm sent by RNC
in case of a Cell Update “Uplink Data Transmission” from UE
User Inactivity In case of no traffic inactivity during a defined time period for a
PS Interactive or Background call

(*): PS cause only

1.7 Call Drop Rate: RNC level
Metric definition: call drop rate at RNC level
Number of Iu abnormal release request
Number of granted RAB

RNC metric UIU007_R_Cs
= rate
CS call drop Σcell(#595[0,2-6]) + ΣNrc(#592[0,2-6])
=
at RNC level #1658.[1-3]
RNC metric UIU007_R_Ps
PS call drop rate Σcell(#589[0,2-14]) + ΣNrc(#588[0,2-14])

=
at RNC level
#1658.[0,4-9]

For CS domain: CS call drop rate can be computed for Voice and Video services specifically
For PS domain: PS call drop rate is sensitive to the duration used before PS RAB is released to maintain the PS RAB when traffic activity
tops. Therefore PS call drop rate highly depends on Always-On algorithm parameters setting.
VS.IuAbnormRelReqCsNrnc - #592
Number of Iu CS release requests due to abnormal conditions, when the reference FddCell of these calls is located on the drift RNC.
• Sub-Counter #0: Other • Sub-Counter #1: Signalling Only • Sub-Counter #2: CS speech NB or LR AMR
• Sub-Counter #3: CS speech WB AMR • Sub-Counter #4: CS data • Sub-Counter #5: CS Streaming 57.6
• Sub-Counter #6: CS Streaming 14.4 • Sub-Counter #7: Any PS
VS.IuAbnormRelReqPsNrnc - #588
Number of Iu PS release requests due to abnormal conditions, when the reference FddCell of these calls is located on the drift RNC.
• Sub-Counter #1: Signalling Only • Sub-Counter #2: PS Streaming < 64 • Sub-Counter #3: PS Streaming 64
• Sub-Counter #4: PS Streaming 128 • Sub-Counter #5: PS Streaming 256 • Sub-Counter #6: PS Streaming 384
• Sub-Counter #7: TRB on cell FACH • Sub-Counter #8: PS I/B < 64 • Sub-Counter #9: PS I/B 64
• Sub-Counter #10: PS I/B 128 • Sub-Counter #11: PS I/B 256 • Sub-Counter #12: PS I/B 384
• Sub-Counter #13: HSDPA • Sub-Counter #14: xPCH • Sub-Counter #15: Any CS
• Sub-Counter #0: Other type of Call
VS.RabEstablishmentSuccessPerGrantedRabType - #1658
Number of successful RAB establishment per granted RAB type (per Rabid and not per procedure).
This counter should also be pegged for RAB successfully allocated for incoming relocations.
DlRbSetId,UlRbSetId,TrafficClass derived screening per granted Rab

1.8 CS Call Drop Rate: Reference FDDCell level
Metric definition: CS call drop rate at cell level
Number of Iu abnormal release request on Iu-CS
Number of CS RAB released

Reference FDDCell metric UIU006_C_Cs
CS call drop rate #595.[0,2-6]

at cell level
= #594.[0,2-6]
Iu-CS connection released each time CS RAB is released

For normal and abnormal reasons
Nb of RAB released used instead of Nb of RAB established

VS.IuReleaseCompleteCs - #594
Number of RANAP Iu Release Complete sent by RNC to CN on the Iu interface on CS domain
Derived AsConf Screening for CS DlAsConfId
• Sub-Counter #0: Other
• Sub-Counter #1: Signalling Only
• Sub-Counter #2: CS speech NB or LR AMR
• Sub-Counter #3: CS speech WB AMR
• Sub-Counter #4: CS data

1.9 PS Call Drop Rate: Reference FDDCell level
Metric definition: PS call drop rate at cell level
Number of Iu abnormal release request on Iu-PS
Number of PS RAB released

Reference FDDCell metric UIU006_C_Ps
PS call drop rate #589.[all]

=
at cell level= #589.[all] + #1647.[0,5-15] + #1163.[all]
Number of PS RAB released = (Abnormal + Normal) release

Abnormal release = Iu Release Request sent by RNC on Iu-PS
Normal release = Radio Bearer Release Complete received by RNC
Normal release = RRC Connection Release Complete after user inactivity is
detected (AO step2 success)

VS.RadioBearerReleaseSuccess - #1647
Number of successful radio bearer releases for each cell controlled by the RNC which is the primary cell.
Reception by the RNC of a RRC RADIO BEARER RELEASE COMPLETE message following the emission of a
RRC RADIO BEARER RELEASE message.

• Sub-Counter #0: Other combinations • Sub-Counter #1: CS Speech NB or LR AMR
• Sub-Counter #2: CS Speech WB AMR • Sub-Counter #3: CS Data
• Sub-Counter #4: CS Streaming • Sub-Counter #5: PS Streaming < 64
VS.DownsizingStep2Success - #1163
Number of successful implementation of an "Always On" algorithm decision to release an UE call due to the UE inactivity.
It is started on reception of a RRC RRC RELEASE COMPLETE message for "User inactivity" reason.
A set of subcounters screened on: Downsizing step 2 Rate Mapping

• Sub-Counter #0: Other AsConfId
• Sub-Counter #1: Cell FACH
• Sub-Counter #2: Dch PS I/B 8
• Sub-Counter #3: Dch PS I/B 0

1.9 PS Call Drop Rate: Reference FDDCell level [cont.]
Metric definition: PS call drop rate at cell level
Number of Iu abnormal release request on Iu-PS
Number of PS RAB released

Reference FDDCell metric UIU022_C_Ps
PS call drop rate #589.[0,2-14]

=
at cell level= #1647.[0,5-17] + #2703
Number of PS RAB released = (Normal+Abnormal) release

Normal release = Radio Bearer Release Complete received by RNC
Abnormal release = Iu Release Command received from CN while some RAB
remain established with the UE

VS.RadioBearerReleaseSuccess - #1647
Number of Radio Bearer released successfully
Source Type of call release mapping
• Sub-Counter #0: Other combinations • Sub-Counter #1: CS Speech NB or LR AMR
• Sub-Counter #2: CS Speech WB AMR • Sub-Counter #3: CS Data
• Sub-Counter #4: CS Streaming • Sub-Counter #5: PS Streaming < 64
• Sub-Counter #12: PS I/B 128 • Sub-Counter #13: PS I/B 256
• Sub-Counter #14: PS I/B 384 • Sub-Counter #15: HSDPA/R99
• Sub-Counter #16: PS I/B or PS Str HSDPA/E-DCH • Sub-Counter #17: TRB on cell FACH
VS.IuReleaseCommandPSWithRAB - #2703
Nb of RANAP Iu Release Command messages received by RNC from PS CN, while at least one PS RAB is still
established for the user. Note: This deals with the fact that some CN implementations do not send a
RANAP RAB Assignment Request (No Remaining Rab) following a Pdp Context Deactivation and send
directly a Iu Release Command. This situation is not incrementing the counters we use in the PS Drop
Rate metrics.

1.10 Part of call drop: radio connection lost with UE
Use some metrics to discriminate CS call drops due to

RF Conditions
UTRAN system problems
Metric definition: % of CS calls dropped due to RL failure
Number of Iu-CS release request due to RF problem
Total number of Iu-CS release request
Reference FDDCell metric UIU012_C
Percentage of #576.[4]
CS calls dropped =
due to RL failure = #576.[all]

A set of subcounters screened on: Reason to send Release Request CS Cause
• Sub-Counter #0: OAM Intervention

• Sub-Counter #1: Unspecified Failure
• Sub-Counter #2: Repeated Integrity Check Failure
• Sub-Counter #3: UE generated signalling cnx release
• Sub-Counter #4: Radio cnx with UE lost
• Sub-Counter #5: Abnormal condition with cause TRelocOveral expiry
• Sub-Counter #6: Other causes
• Sub-Counter #7: DL RLC error on SRB
• Sub-Counter #8: UL RLC error on SRB
• Sub-Counter #9: T360 Expiry
• Sub-Counter #10: Connection with NodeB lost.
• Sub-Counter #11: Release due to UTRAN Generated Reason
• Sub-Counter #12: No Remaining RAB
• Sub-Counter #13: Failure in the Radio Interface Procedure
• Sub-Counter #14: No Resource Available

2 Retainability troubleshooting


2.1 Call Drop Rate Analysis
Study and correlate two analyses :

Call drop distribution per cause of drop : which failure cause
Call drop distribution per type of call (which RB are affected?)
Can it affect certain/all services (CS, PS, SRB,etc)


2.2 Retainibility issues causes
Degradation of Retainability KPIs
DL/UL RF - Monitor Ec/No & RSCP

Conditions - Monitor UL RSSI
- Monitor UE Distance
Mobility - Monitor SHO

Issues - Monitor HHO
NodeB Instability - Monitor PCM Counters
RNC Instability -Monitor CPU Counters

-Monitor PS-FP counters


2.3 Compare Cs, PS and SRB drop rates
Retainability Analysis
RNC level
Iu007> Th
High Call Drop Rate CS High Call drop rate PS High Call drop rate
at RNC levelSRB at RNC level at RNC level
SRB increases UIU007_R_Cs >Th UIU007_R_Cs > Th
Accessibility Analysis CS Retainability PS Retainability per RB

RNC level RNC level RNC level

Problem Description
The call is not more active from the user perspective (CS) or degradation is perceived (PS), see the next
clarification between UTRAN and User perception of call drops:
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 Network Retainability analysis aims at evaluating the call drop rate trends at network level and at
RNC level based on the RNC PANEL report
The results should be provided per service (voice, video, PS) and per RNC to facilitate the
troubleshooting
Problem Detection
CS Call Drop Rate is higher than pre-defined QoS Threshold
PS Call Drop Rate is higher than pre-defined QoS Threshold
Note that for each specific operator threshold need to be adjusted according to the threshold
determination methodology or other methods statistically meaningful.
Note that the CDR is expected to be lower for networks having short voice call duration (less risk of
dropping). For network comparison or different user profile in different areas of the same operator, it
can be interesting to introduce the metric “Number of drops per hour of Voice calls”. For example one
network can have the best Video Telephony call drop rate but the worst Video Telephony drops per
hour of call
For PS retainability the classical drop call metric can be somehow masked by PS call management
procedures and IRM Algorithms (AO, due to the transitions go into the denominator, to avoid this
problem another retainability metrics can be used:
Number of drops per minute.
PS DL Transfer before drop (Mbytes)
2.4 Compare Drop cause
Retainability Analysis – S/PS
RNC level Valid for C
CS High Call drop rate at RNC level CS/PS)

PS High Call drop rate at RNC level (I u re leas erequest
6*, 599*
Cou nters: #57
UeGenerated AbnormalCondition
Signalling
ConnectionRelease RadioConnection TimerRelocExpiry Unspecified
OAM Intervention RepeatedIntegrity WithUeLost Failure
CheckFailure DlRLCErrSRB
IuUserPlaneFailure DlRLCErrTRB
Blackberry issue? UlRLCErrSRB
UlRLCErrTRB 3g 2g
CTg to check
Integrity mobility analysis
No action Analysis It can be correlated wtih
CTg analisys RL failure indication
Actions: Stability Analysis
PCM, RNC
Check TX Node B
Capacity Analysis
DL/UL RF analysis links, HW, etc Alarm correlation?
CPU PMCRAB
DL BLER analysis
Bad DL BLER?
Quality Analysis RB reconfiguration
success rate decrease?
Abnormal resource
releases SRLR parameters #0008 – all Failures in
T360 expiry Capacity analysis failures radio link
To correlate with Abnormal reconfiguration?
release counters
SHO analysis SHO failure metric increase?

Problem Investigation: Use the above chart as a guideline for CS or PS call drop troublesooting

2.5 Typical radio problems in a W-CDMA network
Experience shown that more than 80% of drops are due to bad radio
conditions. These radio drops are mainly caused by these scenarios.
B
C
Radio pollution A
A
B
C
B
A
Missing neighbor C
D
Isolated site

2.5 Typical radio problems in a W-CDMA network
2.5.1 Detection of bad radio conditions
Among the indicators provided by the cell profiling, the bad radio
conditions are confirmed by:
High ratio of 3g2g HHO attempts
Low performance of RRC Procedure
High number of 2D events per call
High DL BLER PS
UL RSSI lower than -110 or greater than -100
Short call duration


2.5.2 Missing neighbor - Impact
When the UE is at the cell edge, the cell B is detected by the UE but it
does not enter the Active Set because it has not been declared as a 3g
intra-frequency neighbor.
The call will drop in cell A because of bad radio conditions if the call is
not handed off to the 2g layer (after the UE has reported event 2D).
B
C


2.5.3 Missing neighbor – Detection and solution
This scenario is highlighted by the following indicators:

SPU value is low (< 1.2)
There is a high ratio of 2D events for EcNo cause
The possible actions are:

Set the parameter isDetectedSetCellsAllowed to true, at RNC level
Perform a neighboring analysis with CTg, CTn or Iu probes
Check the network planning and add the missing neighbors


2.5.4 Isolated site - Impact
There is no possible call continuity on the 3G layer when the UE leaves

cell A, where the call will drop.
Based on the cartography, the only way to preserve the call is to hand
it over to the 2G layer.


2.5.6 Isolated site - Detection and solution
This scenario is highlighted by the following indicators:

SPU value is low (< 1.2)
High ratio of 2D events for Rscp cause. The UE triggers event 2D because of
lack of coverage. The number of 2D per calls can be correlated with the ratio
of 3g2g HHO attempts per call
High ratio of RL Drops last RL. Lot of the drops occur because of RL Failure
when there is only 1 leg in the ActiveSet
To add a new site
To secure the 3g2g HHO with a HoConfClass using very aggressive thresholds
(especially for Rscp because the interference level can remain low, even far
from the site). This HoConfClass can be used for all the cells of the RNC at
the border of the UMTS coverage.


2.5.7 Radio pollution - Impact
In this scenario, the cell A has a high call drop rate because of bad
radio conditions due to radio pollution.
This occurs because either the cell A is a missing neighbor of cell B
or because the Active Set is Full.
When the call is moving from cell B to cell D and is close to BTS A, the
UE is not in soft handover. There is no innerloop to adjust the UE TX
power. The other call ongoing in cell A will drop because of the
temporary huge RSSI increase at the BTS.
B
C


2.5.8 Radio pollution - Detection and solution
If the pollution is permanent (pilot pollution or local radio interferer), then

the minimum Uplink RSSI value will be unexpectedly high.
If the pollution is temporary (due to UE moving close from the antenna, as
described in the previous slide), then there is a high delta between the
average and the maximum Uplink RSSI values. The detection of this category
of radio issues is easier at quarter hour level.

To fix the neighbor issues
To rework the network planning (e.g. downtilt a neighboring cell which has
a too large coverage)



for this module


End of Module


61
Section 6
Mobility Monitoring
Module 1
9300 WCDMA

Blank Page

Mobility Monitoring
Document History
01 2010-04-27 Vincent Nolan First version for UA07
02 2010-08-02 Charneau, Jean-Noel • correction of screenings

Module Objectives
Describe the mobility metric family

Analyze each metric

Mobility Monitoring


Mobility Monitoring

Table of Contents
Page
1 Mobility Overview 7
1.1 What to monitor ? 8
2 SHO Monitoring and Troubleshooting 9
2.1 SHO overview 10
2.2 SHO preparation: Softer HO-RL Addition-Counters 11
2.3 SHO preparation: Softer HO–RL Addition-Metrics 13
2.4 SHO preparation: Soft HO–RL Addition-Counters 14
2.5 SHO preparation: Soft HO–RL Addition-Metrics 16
2.6 SHO execution: Active Set Update-Counters 17
2.7 SHO execution: Metrics 18
2.8 Monitor SPU metric 19
2.9 Correlate with other metrics 20
3 HHO 3G-2G Monitoring 21
3.1 3G-2G CS Handover Success: counters 22
3.2 3G-2G Global CS HHO Success Rate 23
3.3 3G-2G CS Handover Preparation Success: counters 24
3.4 3G-2G CS HO Preparation Success 25
3.5 3G-2G CS Handover Preparation Failure: counters 26
3.6 3G-2G CS HO Preparation Failure Rate 27
3.7 3G-2G CS Handover Execution Success: counters 28
3.8 3G-2G CS HO Execution Success Rate 29
3.9 3G-2G CS Handover Execution Failure: counters 30
3.10 3G-2G CS Handover: Cell Counter Tree (Rescue case) 31
3.11 3G-2G CS HO Execution Failure Rate (reversion to 3G) 32
6 1 5 3.12 3G-2G CS HO Execution Failure Rate (call drop)
33
Mobility Monitoring
4 HHO
9300 WCDMA 3G-3G
TMO18268 Monitoring
9300 WCDMA UAO7 R99 QoS Analysis and Traffic Load Monitoring 34
4.1 3G-3G HHO: InterRNC no Iur–Preparation Success-counters 35
4.2 3G-3G HHO: InterRNC no Iur–Preparation Failure-counters 36
4.3 3G-3G HHO: InterRNC no Iur - Preparation Success Rate 37
4.4 3G-3G HHO: InterRNC no Iur–Execution Success-counters 38
4.5 3G-3G HHO: InterRNC no Iur – Execution Success Rate 39
4.6 3G-3G Inter-freq HHO: Intra+Inter RNC with Iur-Success 40
4.7 3G-3G Inter-freq HHO: Intra+Inter RNC with Iur - Rate 41
4.8 3G-3G Inter-frequency HHO: IntraRNC–Success-counters 42
4.9 3G-3G Inter-frequency HHO: IntraRNC–Failure-counters 43
4.10 3G-3G Inter-frequency HHO - IntraRNC – Failure Rate 44
5 HHO 3G-2G Analysis & Troubleshooting 45
5.1 CS 3G-2G Mobility Analysis & Troubleshooting 46
5.2 3G-2G CS HHO Preparation 47
5.3 3G-2G CS HHO Execution 48
5.4 Summary 49
5.6 Actions to improve the Preparation phase 50
5.7 Actions to improve the Execution phase 51
End of Module 53


Mobility Monitoring This page is left blank intentionally

1 Mobility Overview

Mobility Monitoring

1 Mobility Overview
1.1 What to monitor ?
The Network Mobility analysis consists of:

In connection mode:
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:
Intra-freq mobility (SHO) analysis: estimates the trade-off between quality (reduce
interference and call drops) and capacity (avoid congestion)
Inter frequency mobility: for Traffic Management (segmentation or load balancing)
In idle mode:
Mobile traces
Study RRC counters/RRC transitions (RRC panel)
To be distinguished between CS and PS domain

Mobility Monitoring

2 SHO Monitoring and Troubleshooting

Mobility Monitoring

2.1 SHO overview
SHO management Active Set management
Different SHO procedures

Adding a new cell into the Active Set
In the same Node-B Softer HO
In different Node-Bs Soft HO
Withdrawing a cell out of the Active Set
As most of the telecom procedure between UE and UTRAN, a Soft or Softer

Handover Cell Addition can be split between
SHO preparation phase
Allocation of the necessary radio resources in the cell to be added in the AS
CAC internal to the RNC
Establishment of the new RL
Involving RNC and Node-B
SHO execution phase
Active Set Update procedure
Involving RNC and UE (Node-B acting as a relay)

Mobility Monitoring

2.2 SHO preparation: Softer HO-RL Addition-Counters
UE Node B RNC #55

Measurement Report (Event 1a or 1c) Radio Link Addition
to be performed
CAC
OK
Radio Link Addition Request #49

S
UCCES
Radio Link Addition
S Radio Link Addition Response success
FDDCell Counters
UE Node B RNC FAILU

RE
Measurement Report (Event 1a or 1c)
CAC #39.[2-3,5-6]
NOK
RNC Failure Radio Link Addition
unsuccess

Mobility Monitoring
VS.RadioLinkAdditionRequest - #55
Number of internal events that would lead to a radio link addition request.
A set of subcounters screened on: Target type of call for Radio Link Reconfiguration
• Sub-Counter #0: Other • Sub-Counter #1: Signalling Only
• Sub-Counter #2: CS speech • Sub-Counter #3: CS Speech + PS DCH
• Sub-Counter #4: CS Speech + HSDPA • Sub-Counter #5: CS Speech + PS DCH + PS HSDPA
• Sub-Counter #6: CS Speech + PS DCH + PS DCH • Sub-Counter #7: CS Data
• Sub-Counter #8: CS data + PS DCH • Sub-Counter #9: Cs Data + PS HSDPA
• Sub-Counter #10: CS streaming • Sub-Counter #11: PS DCH DL / DCH UL
• Sub-Counter #12: PS HSDPA DL / E-DCH UL • Sub-Counter #13: PS HSDPA DL / DCH UL
• Sub-Counter #14: PS HSDPA DL / DCH UL + E-DCH UL • Sub-Counter #15: PS DCH + PS DCH
• Sub-Counter #16: PS DCH + PS HSDPA
VS.RadioLinkAdditionSuccess - #49
Number of radio-links successfully added on a NBAP point of view, screened by Downlink Access Stratum
configuration.
Screening: same as for #55
VS.RadioLinkAdditionUnsuccess - #39
Number of failures radio link reconfiguration preparation
• Sub-Counter #0: RADIO_LINK_ADDITION_FAILURE (any other causes than the ones of screenings #4 & #7)
• Sub-Counter #1: Timeout
• Sub-Counter #2: Rrm refusal
• Sub-Counter #3: INode refusal
• Sub-Counter #4: NodeB (CEM) lack of L1 resources
• Sub-Counter #5: Lack of Transport Identifier (CID or UDP Port) on the Iub
• Sub-Counter #6: Lack of bandwidth on the Iub
• Sub-Counter #7: Iub Layer Congestion
2.2 SHO preparation: Softer HO-RL Addition-Counters [cont.]
UE Node B RNC
Measurement Report (Event 1a or 1c) FAILU
RE
CAC
OK
#39.[0,4,7]
Radio Link Addition Request Radio Link Addition
unsuccess
Node-B Failure Radio Link Addition Failure
FDDCell Counters
UE Node B RNC
FAILU
CAC
RE
OK
Radio Link Addition Request
#39.[1]
No answer Radio Link Addition
from Node-B unsuccess
timer expiry

Mobility Monitoring
VS.RadioLinkAdditionUnsuccess #39
Number of unsuccessfull radio link setup

• Sub-Counter #0: RADIO_LINK_ADDITION_FAILURE (any other causes than the ones of screenings #4 & #7)
• Sub-Counter #1: Timeout
• Sub-Counter #2: RRM refusal
• Sub-Counter #3: INode refusal
• Sub-Counter #4: NodeB (CEM) lack of L1 resources
• Sub-Counter #5: Lack of Transport Identifier (CID or UDP Port) on the Iub
• Sub-Counter #6: Lack of bandwidth on the Iub
• Sub-Counter #7: Iub Layer Congestion

2.3 SHO preparation: Softer HO–RL Addition-Metrics
FDDCell metric URL027_CR

#49.[all]
Radio
RadioLink
LinkAddition
Addition =
Success
SuccessRate
Rate #55.[all]

#39.[all except 1]
Radio Link Addition
Blocking Rate =
#55.[all]

Mobility Monitoring

2.4 SHO preparation: Soft HO–RL Addition-Counters
UE Node B 1 Node B 2 RNC #54

Measurement Report (Event 1a or 1c) Radio Link Setup
to be performed
CAC
OK
Radio Link Setup Request #48

SS
SUCCE
Radio Link Setup
Radio Link Setup Response success
FDDCell Counters
UE Node B 1 Node B 2 RNC FAILU

Measurement Report (Event 1a or 1c)
RE
CAC
NOK #38.[2,5-9]
Radio Link Setup
unsuccess
RNC Failure

Mobility Monitoring
VS.RadioLinkSetupRequest - #54
Number of internal events that would lead to a radio link setup request
A set of subcounters screened on: Target type of call for Radio Link Reconfiguration
• Sub-Counter #0: Other • Sub-Counter #1: Signalling Only • Sub-Counter #2: CS speech
• Sub-Counter #3: CS Speech + PS DCH • Sub-Counter #4: CS Speech + HSDPA
• Sub-Counter #5: CS Speech + PS DCH + PS HSDPA • Sub-Counter #6: CS Speech + PS DCH + PS DCH
• Sub-Counter #7: CS Data • Sub-Counter #8: CS data + PS DCH
• Sub-Counter #9: Cs Data + PS HSDPA • Sub-Counter #10: CS streaming
• Sub-Counter #11: PS DCH DL / DCH UL • Sub-Counter #12: PS HSDPA DL / E-DCH UL
• Sub-Counter #13: PS HSDPA DL / DCH UL • Sub-Counter #14: PS HSDPA DL / DCH UL + E-DCH UL
• Sub-Counter #15: PS DCH + PS DCH • Sub-Counter #16: PS DCH + PS HSDPA
VS.RadioLinkSetupSuccess - #48
Number of radio-links successfully setup on a NBAP point of view, screened by Downlink Access Stratum
configuration. Screening: same as for #54
VS.RadioLinkSetupUnsuccess - #38
Number of unsuccessful radio link setup
• Sub-Counter #0: RADIO_LINK_SETUP_FAILURE • Sub-Counter #1: Timeout
• Sub-Counter #2: Rrm refusal • Sub-Counter #3: Iub Layer Congestion
• Sub-Counter #4: NodeB (CEM) lack of L1 resources • Sub-Counter #5: Lack of Transport
Identifier (CID or UDP Port) on the Iub
• Sub-Counter #6: Lack of bandwidth on the Iub • Sub-Counter #7: INode refusal
• Sub-Counter #8: Multi-cell Operation Not Available

2.4 SHO preparation: Soft HO–RL Addition–Counters [cont.]
UE Node B 1 Node B 2 RNC
RE
CAC
OK
Radio Link Setup Request #38.[0,3-4]

Radio Link Setup
Node-B Failure Radio Link Setup Failure unsuccess
FDDCell Counters
UE Node B 1 Node B 2 RNC

RE
CAC
OK
Radio Link Addition Request #38.[1]
Radio Link Setup
No answer unsuccess
from Node-B
timer expiry
Mobility Monitoring
• Sub-Counter #0: RADIO_LINK_SETUP_FAILURE • Sub-Counter #1: Timeout
• Sub-Counter #2: Rrm refusal • Sub-Counter #3: Iub Layer Congestion
• Sub-Counter #4: NodeB (CEM) lack of L1 resources • Sub-Counter #5: Lack of Transport
Identifier (CID or UDP Port) on the Iub
• Sub-Counter #6: Lack of bandwidth on the Iub • Sub-Counter #7: INode refusal
• Sub-Counter #8: Multi-cell Operation Not Available

2.5 SHO preparation: Soft HO–RL Addition-Metrics

#48.[all]
Radio
RadioLink
LinkSetup
Setup =
Success
SuccessRate
Rate #48.[all] + #38.[all]
Radio Link Setup #38.[all except 1]

Blocking Rate =
#54.[all]

Mobility Monitoring

2.6 SHO execution: Active Set Update-Counters
UE Node B RNC
SS
Measurement Report (event) SUCCE
Active Set Update
Active Set Update Complete #415
FDDCell Counters
UE Node B RNC FAILU

RE
Measurement Report (event)
UE Node B RNC
Active Set Update Measurement Report (event)
Active Set Update Failure
Active Set Update
No answer from UE
#402[0]
timer expiry
#402[1]

Mobility Monitoring
VS.RrcActiveSetUpdateCompleteProcedure #415
This measurement provides the number of successful RRC Active Set Update procedures, for which the
cell is the in the list of the active set before or after the Active Set Update execution (even if it is
added or removed due to this procedure). It is incremented once per procedure, whatever the number
of cells.
VS.RrcActiveSetUpdateUnsuccess #402
This measurement provides the number of failed RRC ACTIVE SET UPDATE procedures managed by a RNC,
for each cell controlled by the RNC. The measurement attached to a given cell is incremented for a
failed addition or removal of this cell from the active set.
Screenings:
0 : RRC ACTIVE SET UPDATE FAILURE reception
1 : Time-out

2.7 SHO execution: Metrics
FDDCell metric USHO007_CR
#402.[all]
SHO
SHOFailure
FailureRate
Rate =
#402.[all] + #415
What is, for any UE, the Average number of its RLs or its Average Active Set size
when this cell is the Primary cell for this UE ?
Reference FDDCell metric URL016_CR
Mean Sector #25.[0].Avg + 2x(#25.[1].Avg+#25.[2].Avg) + 3x(#25.[3].Avg+…) + …

Mean Sector
per
per User
User ==
#25.[all screenings].Avg
Average number of Radio Links in the AS of UEs having this cell as their Primary
Average number of UEs having this cell as their Primary

Mobility Monitoring
VS.UeWithNRadioLinksEstCellsBts - #25
Distribution of the number of mobiles having N Radio-Links in their Active Set
A set of subcounters screened on: Number of radio links
• Sub-Counter #0 : 1 Radio Link
• Sub-Counter #1 : 2 RL (Reference Cell + 1 RL on the same BTS)
• Sub-Counter #2 : 2 RL (Reference Cell + 1 RL on another BTS)
• Sub-Counter #3 : 3 RL (Reference Cell + 2 RL on the same BTS)
• Sub-Counter #4 : 3 RL (Reference Cell + 1 RL on the same BTS + 1 RL on another BTS)
• Sub-Counter #12 : 6 RL or more (Reference Cell + 2 RL on the same BTS + 3 or more RL on another
BTS)
• Sub-Counter #13 : 6 RL or more (Reference Cell + 1 RL on the same BTS + 4 or more RL on another
BTS)
• Sub-Counter #14 : 6 RL or more (Reference Cell + 5 or more RL on another BTS)

2.8 Monitor SPU metric
SHO Mobility Analysis

RNC level
High SPU
Low SPU RL016
RL016
SHO Analysis Check SHO Parameters settings

RNC level Check Radio Design

Mobility Monitoring
Can it affect certain/all services (CS, PS,etc)
After certain event (upgrade, feature activation, configuration changes in Iur, reparentings?
(*) New counters

2.9 Correlate with other metrics
SHO Analysis
RNC level
•Top worst cells •Top worst cells
Few cells? RL Setup RL Addition

Blocking Rate Blocking Rate
URL036_CR > Th Inter RNC SHO analysis URL037_CR > Th
Correlate with s
cces s succes
pUnsu es] itionUn
Node B alarms
RL Setu ca us RL Addilure causes]
[failure [fa
RRM Capacity Analysis

CEM & Iub Capacity Analysis Cell level
Node B level
RRM Capacity Analysis
Cell level
High Iur Radio link failures No
(setup/addition)
All cells? Or set of cells
Yes
Check configuration for the set of cells
Correlate with events that affect Iur:
i.e configuration changes like reparenting Capacity analysis cell level

Mobility Monitoring

3 HHO 3G-2G Monitoring

Mobility Monitoring

3.1 3G-2G CS Handover Success: counters
Reference
Decision for FDDCell Counters
3G->2G HHO
UE Node B RNC CN BSS
Measurement Report
#164[0] 3G to 2G HO detection Relocation Required
#1839 Iu relocation attempt …. preparation
Relocation Command
Handover from UTRAN Command
Handover Access
Physical information execution
Handover Complete
Iu Release Command
RL Deletion Reqt “successful 3G to 2G
RL Deletion Respe relocation”
Iu Release Complete
Released
#167[0] #1841[0] successful 3G to 2G outgoing HO
successful 3G to 2G outgoing HO #505[1] successful 3G to 2G outgoing HO

Mobility Monitoring
VS.3gto2gHoDetectionFromFddcell #164:
This measurement provides the number of RRM decisions for a 3G TO 2G handover performed by a RNC,
screened by reference cell from which the UEs have left the 3G Network, when these cells are controlled by the
considered RNC. This measurement considers both CS and PS handovers.
0 --> Rescue CS 2 --> Service
1 --> Rescue PS 3 --> No resource available (CAC failure)
VS.3gto2gOutHoSuccess #167:
This measurement provides the number of successful 3G to 2G outgoing Handovers. It is incremented at the
reception of an Iu_Release_Command with cause « Successful 3G to 2G Relocation »
Screening:
• Sub-Counter #0 : rescue CS • Sub-Counter #1 : rescue PS
• Sub-Counter #2 : service CS • Sub-Counter #3 : Service PS
• Sub-Counter #4 : No resource available CS (CAC) • Sub-Counter #5 : No resource available PS (CAC)
VS.IuReleaseCommandCs - #505: This measurement provides the total number of Iu Release Command CS
received by the RNC. It is incremented at the reception of an Iu_Release_Command for some cause values.
Screening: per Iu Release Command cause
0 : Normal end of communication (3GPP RANAP cause 83)
1 : Successful relocation
2 : UTRAN generated reason (3GPP RANAP cause 15 or Iu_Release_Request sent by RNC)
3 : Other cause (all other 3GPP RANAP causes) 4 : Relocation Cancelled (3GPP RANAP cause
10)
5 : O&M Intervention (3GPP RANAP cause 113) 6 : Unspecified Failure (3GPP RANAP cause
115)
7 : User Inactivity (3GPP RANAP cause 16) 8 : No Remaining RAB (3GPP RANAP cause 31)
9 : Successful 3G/3G relocation (3GPP RANAP cause 11)
IRATHO.SuccOutCS - #1841
Successful outgoing CS 3G to 2G handover (CS Inter-RAT handover).
• Sub-Counter #0: Rescue CS
• Sub-Counter #1: Service CS
• Sub-Counter #2: No resource available CS (CAC failure)

3.2 3G-2G Global CS HHO Success Rate
The 3G2G Global CS HHO success rate evaluates success rate of the
overall 3G2G CS HHO procedure by considering all the cases of failures
(3G or 2G failures).
Reference FDDCell metric UHO3G2G019_C_Cs
CS
CS3G-2G
3G-2GHHO
HHO #167.[0]
Radio
Radio SuccessRate
Success Rate =
(Rescue) #164.[0]
(Rescue)
RNC metric UHO3G2G019_R_Cs
CS
CS3G-2G
3G-2GHHO
HHO ∑cell(#167.[0]) + ∑Nrnc(#168.[0])
Radio
Radio SuccessRate
Success Rate =
(Rescue)
(Rescue) ∑cell(#164.[0]) + ∑Nrnc(#165.[0])

Mobility Monitoring
VS.3gto2gOutHoSuccessNrnc - #168
Number of successful outgoing Hard Handovers from 3G to 2G when reference cell is on drift
RNC
A set of subcounters screened on: HO reason for which a 3G to 2G Relocation was initiated.
• Sub-Counter #0 : rescue CS
• Sub-Counter #1 : rescue PS
• Sub-Counter #2 : No resource available CS (CAC failure)
• Sub-Counter #3 : No resource available PS (CAC failure)
VS.3gto2gHoDetectionFromFddcellNeighbRnc - #165
Number of RRM decisions for a 3G TO 2G handover performed by a RNC, screened by
neighboring RNC grouping reference cells from which the UEs have left the 3G Network. This
measurement considers both CS and PS handovers.
A set of subcounters screened on: Reason for initiating the 3G to 2G HO
• Sub-Counter #0 : Rescue CS
• Sub-Counter #1 : Rescue PS
• Sub-Counter #2 : No resource available (CAC failure)

3.3 3G-2G CS Handover Preparation Success: counters
#164[0] 3G to 2G HO detection
#1839 Iu relocation attempt

Measurement Report
RNC counter Relocation Required
#556[2] Iu relocation required

….
Relocation Command
#557[2] Iu relocation command
RNC counter
#154[0] #156[0]
HO from UTRAN command

Mobility Monitoring
#154 VS.RrcHoFromUtranCmdTrigByEcNo
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:
Sub-Counter #0 : rescue CS
#156 VS.RrcHoFromUtranCmdTrigByRscp
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 RSCP criteria:
Sub-Counter #0 : rescue CS
#158 VS.RrcHoFromUtranCmdTrigRnc
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 CAC failure events or Service events, NOT
because of Alarm radio condition.
• Sub-Counter #0 : service CS • Sub-Counter #1 : No resource available (CAC failure)
#556 VS.IuRelocationRequired
A set of subcounters screened on: Per type of core and type of relocation
• Sub-Counter #0 : 3G-3G CS, UE involved • Sub-Counter #1 : 3G-3G PS, UE involved
• Sub-Counter #2 : 3G-2G CS • Sub-Counter #3 : 3G-3G CS, UE not involved
• Sub-Counter #4 : 3G-3G PS, UE not involved
#557 VS.IuRelocationCommands
Same screenings as for #556

3.4 3G-2G CS HO Preparation Success
The main metrics used to monitor the CS HHO 3G to 2G

preparation phase on the target side are:
Failures from the target network when allocating the resources for
the mobile (Relocation Preparation Failure)
Failures from 2G due to wrong neighboring definition of 2G in 3G &

opposite
Call dropped after Relocation Required & before HO from UTRAN

Command.

Mobility Monitoring

3.5 3G-2G CS Handover Preparation Failure: counters
EXERCISE: Find the two counters in the catalogue
Decision for HHO
Measurement Report
#??? Relocation Required TRELOCprep

1s t #568[2] Relocation cancel expiry
Relocation Cancel
c as e
No answer from CN to Relocation Required
Decision for HHO

Handover failure
Measurement Report on the 2G side
2n d Relocation Required
c as e
#558[6-9]
#???
#???
Handover
#1845[0-11]
Relocation Preparation failure
Relocation preparation failure
Failure
CN answers NACK to Relocation Required

Mobility Monitoring
TRELOCprep = Timer RELOcation preparation

3.6 3G-2G CS HO Preparation Failure Rate
3G-2G #558.[4-7]
3G-2GCS
CSHO
HOPreparation
Preparationfailure
failurerate
rate =
(Rescue+CAC failure+Service)
(Rescue+CAC failure+Service) #556.[2]
FDDCell metric
3G-2G
3G-2GCS CSHOHOPreparation
Preparation #164[all] – (#154+#156+#158.[all])
failure rate
failure rate =
(Rescue+CAC #164[all]
(Rescue+CACfailure+Service)
failure+Service)
FDDCell metric
3G-2G
3G-2GCS CSHOHOPreparation
Preparation #1845.[all] #1843
failure rate
failure rate = =
(Rescue+CAC #1839 #1839
(Rescue+CACfailure+Service)
failure+Service)
Mobility Monitoring
VS.IuRelocationCmdFailuresCs - #558 is a RNC counter

Number of relocation Preparation failures on CS Iu interface
A set of subcounters screened on: IU Relocation command failure causes
• Sub-Counter #4: 3G to 2G UE involved. Relocation timeout. 'Trelocallocexpiry' (3GPP 25.413)
• Sub-Counter #5: 3G to 2G UE involved. Relocation failure or relocation not supported in target system
• Sub-Counter #6: 3G to 2G UE involved. 'Unable to Establish During Relocation' (3GPP 25.413)
• Sub-Counter #7: 3G to 2G UE involved. Other relocation failure
IRATHO.FailRelocPrepOutCS - #1845 : is a Reference Cell counter

Failed relocation preparations for UMTS to GSM handover on the reference cell from network point of view per failure cause
• Sub-Counter #0: Relocation Cancelled (10)
• Sub-Counter #1: Requested Ciphering and/or Integrity Protection Algorithms not Supported (12)
• Sub-Counter #2: Relocation Failure in Target CN/RNC or Target system (29)
• Sub-Counter #3: Relocation not supported in Target RNC or Target System (44)
• Sub-Counter #4: Relocation Target not allowed (50)
• Sub-Counter #5: No Radio Resources Available in Target Cell (53)
• Sub-Counter #6: Traffic Load in The Target Cell Higher Than in the Source Cell (57)
• Sub-Counter #7: Abstract Syntax Error (Reject) (100)
• Sub-Counter #8: O&M Intervention (113)
• Sub-Counter #9: No Resource Available (114)
• Sub-Counter #10: Unspecified Failure (115)
• Sub-Counter #11: Expiry of the timer TRELOCprep
IRATHO.AttRelocPrepOutCS - #1839 : is a Reference Cell counter

Attempted relocation preparations for CS UMTS to GSM handover (CS inter-RAT Handover Attempt)
IRATHO.FailRelocPrepOutCS.Sum - #1843 : is a Reference Cell counter

Sum of all kinds of Failed relocation preparations for UMTS to GSM handover on the reference cell from network point of view.

3.7 3G-2G CS Handover Execution Success: counters
Relocation Command
Handover from UTRAN Command #154[0] … #159[0]

HO from UTRAN command
Handover Access
Physical information
Handover Complete
Iu Release Command
RL Deletion Reqt “successful 3G to 2G
RL Deletion Respe relocation” Reference
FDDCell Counters
Iu Release Complete
Released
#167[x] , #168[x]
successful 3G to 2G outgoing handovers

Mobility Monitoring

3.8 3G-2G CS HO Execution Success Rate
CS 3G-2G HHO #167.[0,2,4]

Execution Success Rate =
#154[0] + #156 [0] + #158 [0,1]
CS 3G-2G HHO Σcell(#167.[0,2,4]) + ΣNrnc(#168.[0,2])

Execution =
Success Rate Σ#154 + Σ#155 + Σ#156 + Σ#157 + Σ#158 + Σ#159

Mobility Monitoring

3.9 3G-2G CS Handover Execution Failure: counters
UE Node B RNC CN - CS BSS
Relocation Command HO Request Ack

Handover failure on the target system

1s t Handover from UTRAN Failure
c as e Relocation Cancel
#160[x] ; #161[x]
HO From UTRAN Failure
UE fails to connect to 2G and reverts to 3G
Relocation Command HO Request Ack

2n d TRelocOveral
UE fails to connect to 2G
c as e and fails to reverts to 3G
expiry Iu Release Request
Reference
HHO Drop FDDCell Counters
#576[5] HHO drop

Mobility Monitoring
VS.RrcHoFromUtranFailure - #160
Number of RRC HANDOVER FROM UTRAN FAILURE messages (3G to 2G handover for
CS or CS+PS) received by an RNC, acting as serving RNC, for each cell controlled by this
RNC.
A set of subcounters screened on: HO reason for which the RRC / HANDOVER_
FROM_UTRAN_COMMAND message is sent
• Sub-Counter #1 : service CS
VS.RrcHoFromUtranFailureNeighbRnc - #161
Number of RRC HANDOVER FROM UTRAN FAILURE (3G to 2G handover for CS or
CS+PS) messages received by an RNC acting as serving, for each neighboring RNC.
A set of subcounters screened on: HO reason for which the RRC / HANDOVER_
FROM_UTRAN_COMMAND message is sent
• Sub-Counter #5 : Abnormal condition with cause TRelocOveral expiry

3.10 3G-2G CS Handover: Cell Counter Tree (Rescue case)
Request VS.3gto2gHoDetectionFromFddcell
#164[0]
VS.RrcHoFromUtranCommand
Preparation failure Attempt

#164[0] – Σ[#154+#156] Σ[#154+#156]
Execution failure Success

Σ[#154+#156] – #167[0] #167[0]
VS.RadioBearerSetupUnsuccess
HO from UTRAN Failure

#160[0]
HHO drop
Σ[#154+#156]- #167[0] - #160[0]

Mobility Monitoring

3.11 3G-2G CS HO Execution Failure Rate (reversion to 3G)
#160[0,1,2]
CS
CS3G-2G
3G-2GHO
HOExecution
ExecutionFailure
FailureRate
Rate =
#154[0] + #156[0] + #158[0,1]
Σcell(#160[0,1,2]) + ΣNrnc(#161[0,1])
CS
CS3G-2G
3G-2GHO HO =
Execution
Execution FailureRate
Failure Rate #154 + #155 + #156 + #157 + #158 + #159

Mobility Monitoring
2G Synchronization failure and reversion to 3G:

If the UE can not synchronize with the 2G target network during the 3G2G HHO execution phase, the UE
sends the HO from UTRAN Failure message to the RNC to come back on the 3G network.
The CS 3G2G HHO Execution Failure Rate metric is proposed to evaluate the 2G target cell
synchronization failure.
Notes:
Reference FDDCell metric:
CS 3G-2G HO Execution Failure Rate (2G synchronization failure) = ΣVS.RrcHoFromUtranFailure /
(ΣVS.RrcHoFromUtranCmdTrigByEcNo +
ΣVS.RrcHoFromUtranCmdTrigByRscp +
ΣVS.RrcHoFromUtranCmdTrigRnc)
RNC Metric:
CS 3G-2G HO Execution Failure Rate (2G synchronization failure) =
(ΣVS.RrcHoFromUtranFailure + ΣVS.RrcHoFromUtranFailureNeighbRnc ) /
(ΣVS.RrcHoFromUtranCmdTrigByEcNo + ΣVS.RrcHoFromUtranCmdTrigByEcNoNrnc +
ΣVS.RrcHoFromUtranCmdTrigByRscp + Σ VS.RrcHoFromUtranCmdTrigByRscpNrnc +
ΣVS.RrcHoFromUtranCmdTrigRnc + ΣVS.RrcHoFromUtranCmdTrigRncNrnc)

3.12 3G-2G CS HO Execution Failure Rate (call drop)
Number of CS 3G2G
HHO drops = #154 + #156 + #158 - #160[all] - #505[1]
CS 3G2G HHO #154 + #156 + #158 - #160[all] - #167[0,2,4]

Execution Failure Rate =
because of 3G Reason #154 + #156 + #158 - #160[all]
3G-2G CS HO which leads

either to a Success or to a Drop
Mobility Monitoring
1. The number of calls lost during a 3G-2G HO is:

Number of HO From UTRAN Command sent to UE
– Number of HO From UTRAN Failure received from UE
– Number of HO success to 2G
2. CS 3g-2G HO Execution Failure rate (call lost):
The HO Failures to 2G with UE successfully reverting to 3G are not taken into account.
Call lost:
If the RNC does not receive the HO from UTRAN Failure RRC message from the UE or the Iu release
command with the cause “successful 3g2g relocation” from the CN, there is failure at 3G side (the
call is dropped during the 3G2G HHO).
The CS 3G2G HHO Execution Failure Rate because of 3G Reason metric is proposed to evaluate the calls
dropped during the 3G2G CS HHO.


Mobility Monitoring

4.1 3G-3G HHO: InterRNC no Iur–Preparation Success-counters
UE Node B RNC 1 CN RNC 2

Measurement Report
#556[x] Relocation Required

Iu relocation required
RNC counter Relocation Request
#535[x]
Iu relocation request
FDDCell counter
Relocation Request Ack

#557[x] Relocation Command
Iu relocation command not counted
RNC counter
Source side Target side
Outgoing HHO Incoming HHO

Mobility Monitoring
#556 VS.IuRelocationRequired
A set of subcounters screened on: Per type of core and type of relocation
• Sub-Counter #0 : 3G-3G CS, UE involved
• Sub-Counter #1 : 3G-3G PS, UE involved
• Sub-Counter #2 : 3G-2G CS
• Sub-Counter #3 : 3G-3G CS, UE not involved
• Sub-Counter #4 : 3G-3G PS, UE not involved
#557 VS.IuRelocationCommands
VS.IuRelocationRequests - #535
Number of relocation request at Iu interface
A set of subcounters screened on: Per type of relocation and CN Domain
• Sub-Counter #0 : CS 3G-3G Relocation
• Sub-Counter #1 : PS 3G-3G Relocation
• Sub-Counter #2 : CS 2G-3G Relocation
• Sub-Counter #3 : CS 3G-3G Relocation, UE not involved
• Sub-Counter #4 : PS 3G-3G Relocation, UE not involved
• Sub-Counter #5: PS 4G-3G Relocation, UE involved

4.2 3G-3G HHO: InterRNC no Iur–Preparation Failure-counters

Measurement Report
Relocation Required
Relocation Request
FDDCell counters
#536[x] for CS, #537[x] for PS
Iu relocation request failure
Relocation Request
Relocation Preparation Failure
Failure
#558[x]
Iu relocation Source side Target side
preparation failure
Outgoing HHO Incoming HHO
RNC counter

Mobility Monitoring
VS.IuRelocationCmdFailuresCs - #558
Number of relocation Preparation failures on CS Iu interface
A set of subcounters screened on: IU Relocation command failure causes
• Sub-Counter #0 : 3G to 3G UE involved. Relocation timeout
• Sub-Counter #1 : 3G to 3G UE involved. Relocation failure in target system
• Sub-Counter #2 : 3G to 3G UE involved. Relocation unable to establish
• Sub-Counter #3 : 3G to 3G UE involved. Other relocation failure
• Sub-Counter #4 : 3G to 2G UE involved. Relocation timeout. 'Trelocallocexpiry' (3GPP 25.413)
• Sub-Counter #5 :3G to 2G UE involved. Relocation failure or relocation not supported in target system
• Sub-Counter #6 :3G to 2G UE involved. 'Unable to Establish During Relocation' (3GPP 25.413)
• Sub-Counter #7 :3G to 2G UE involved. Other relocation failure
• Sub-Counter #8 :3G to 3G UE not involved. Relocation timeout
• Sub-Counter #9 :3G to 3G UE not involved. Other relocation failure
IuRelocationRequestFailuresPs - #537
Number of relocation requests failures on PS Iu interface
• Sub-Counter #0: 3G-3G UE involved. Relocation time out
• Sub-Counter #1: 3G-3G UE involved. Relocation failure in target system
• Sub-Counter #2: 3G-3G UE involved. Relocation unable to establish
• Sub-Counter #3: 3G-3G UE involved. Other relocation failure
• Sub-Counter #4: 3G-3G UE involved. RRC Context CAC. Pegged when CAC fails for then entering PS reloc.
• Sub-Counter #5: 3G-3G UE involved. Unavailable IU CNX context resources. Pegged when the IU connexion contexts are
exhausted for the entering PS reloc.
• Sub-Counter #6: 3G-3G UE not involved. Relocation timeout (TRelocAlloc).
• Sub-Counter #7: 3G-3G UE not involved. Relocation failure in target system.
• Sub-Counter #8: 3G-3G UE not involved. Unavailable IU CNX context resources. Pegged when the IU connexion contexts are
exhausted for the entering PS reloc.
• Sub-Counter #9: 3G-3G UE not involved. Other relocation failure
• Sub-Counter #10: 4G-3G UE involved. Relocation failure in target system
• Sub-Counter #11: 4G-3G UE involved. Relocation unable to establish
• Sub-Counter #12: 4G-3G UE involved. RAB matching failure
• Sub-Counter #13: 4G-3G UE involved. Other relocation failure

4.3 3G-3G HHO: InterRNC no Iur - Preparation Success Rate
FDDCell metric UHO3G3G002_CR_Cs
CS 3G-3G HHO
Incoming #535.[0,3] - #536.[0-3,8,10,12-14]
=
Preparation #535.[0,3]
Success Rate
FDDCell metric UHO3G3G004_CR_Ps

PS 3G-3G HHO
Incoming #535.[1,4] - #537.[0-9]
=
Preparation #535.[1,4]
Success Rate
RNC metric UHO3G3G007_R_Cs RNC metric UHO3G3G007_R_Ps

CS 3G-3G HHO PS 3G-3G HHO
Outgoing #557.[0,3] Outgoing #557.[1,4]
= =
Preparation #556.[0,3] Preparation #556.[1,4]
Success Rate Success Rate
Mobility Monitoring
Due to the counters implementation, the 3G3G HHO Preparation success rate is available at RNC level only for
Source side and at Cell level for Target side.
VS.IuRelocationRequestFailuresCs - #536
Number of relocation requests failures on CS Iu interface
• Sub-Counter #0 : 3G-3G UE involved. Relocation timeout
• Sub-Counter #1 : 3G-3G UE involved. Relocation failure in target system
• Sub-Counter #2 : 3G-3G UE involved. Relocation unable to establish
• Sub-Counter #3 : 3G-3G UE involved. Other relocation failure
• Sub-Counter #4 : 2G-3G Relocation timeout
• Sub-Counter #5 : 2G-3G Relocation failure in target system
• Sub-Counter #6 : 2G-3G Relocation unable to establish
• Sub-Counter #7 : 2G-3G Other relocation failure
• Sub-Counter #8 :3G-3G UE involved. RRC Context CAC. Pegged when CAC fails for the entering CS
reloc.
• Sub-Counter #9 : 2G-3G RRC Context CAC. Pegged when CAC fails for the entering CS reloc.
• Sub-Counter #10 :3G-3G UE involved. Unavailable IU CNX context resources. Pegged when the IU
connexion contexts are exhausted for the entering CS reloc.
• Sub-Counter #11 : 2G-3G Unavailable IU CNX context resources. Pegged when the IU connexion
contexts are exhausted for the entering CS reloc.
• Sub-Counter #12 : 3G-3G UE not involved. Relocation timeout (TRelocAlloc).
• Sub-Counter #13 : 3G-3G UE not involved. Relocation failure in target system.
• Sub-Counter #14 : 3G-3G UE not involved. Other relocation failure.

4.4 3G-3G HHO: InterRNC no Iur–Execution Success-counters

Measurement Report
Relocation Required
Relocation Request
Relocation Request Ack

Relocation Command
Radio Bearer Reconfiguration
Radio Bearer Reconfiguration Complete

Relocation Detect
#505[9] & #552[9] for CS
#506[9] & #553[9] for PS Relocation Complete
Iu relocation command
Iu Release Command
FDDCell & Neighboring RNC
counters RL Deln Reqt #569[x]
RL Deln Respe Iu relocation complete
Iu Release Complete RNC counter

Mobility Monitoring
VS.IuRelocationCompletes - #569
Number of relocation completes at Iu interface
A set of subcounters screened on: Per type of relocation and CN domain
• Sub-Counter #1 : 3G-3G PS
• Sub-Counter #3 : 4G-3G PS
VS.IuReleaseCommandCs - #505
Number of RANAP/IU_RELEASE_COMMAND messages received by RNC from CS domain.
• Sub-Counter #9: Successful 3G3G relocation
VS.IuReleaseCommandPsNRnc - #553
Number of RANAP/IU_RELEASE_COMMAND messages received by RNC on the IU-PS interface when the reference
cell is located on a Drift RNC.
VS.IuReleaseCommandPs - #506
Number of RANAP/IU_RELEASE_COMMAND messages received by RNC from PS domain.
VS.IuReleaseCommandCsNRnc - #552
Number of RANAP/IU_RELEASE_COMMAND messages received by RNC on the IU-CS interface when the reference
cell is located on a Drift RNC.

4.5 3G-3G HHO: InterRNC no Iur – Execution Success Rate
CS #569.[0]
CS3G-3G
3G-3GHHOHHOIncoming
Incoming =
Execution
Execution SuccessRate
Success Rate Σcell(#0535.[0,3] - #536.[0-3,8,10,12-14])
RNC metric UHO3G3G005_R_Ps
PS # 569.[1]
PS3G-3G
3G-3GHHOHHOIncoming
Incoming =
Execution
Success Rate Σcell(#535.[1,4] - #537.[0-3,8,10,12-15])
CS Σcell(#505.[9]) + ΣNrnc(#552.[9])
CS3G-3G
3G-3GHHO
HHOOutgoing
Outgoing =
Execution
ExecutionSuccess
SuccessRate
Rate #557.[0,3]
RNC metric UHO3G3G009_R_Ps
PS Σcell(#506.[9]) + ΣNrnc(#553.[9])
PS3G-3G
3G-3GHHOHHOOutgoing
Outgoing=
Execution
Success Rate #557.[1,4]
Mobility Monitoring

4.6 3G-3G Inter-freq HHO: Intra+Inter RNC with Iur-Success
S Reference
PS+C FDDCell Counters
Decision for
UE Source Target RNC HHO
Node B Node B
Measurement Report
#174[x]
Outgoing inter-freq
RL Setup Request HHO attempt
#176[x]
RL Setup Response Incoming inter-freq
RB Reconfiguration HHO attempt
RB Reconfiguration complete
RL Deletion Request #175[x]

Outgoing inter-freq
HHO success
RL Setup Deletion Response
#177[x]
Incoming inter-freq
HHO success

Mobility Monitoring
VS.OutGoInterFreqHoAtt - #174
Number of hard handovers attempted from this cell to another inter-frequency cell located either in the
same RNC or in a neighbouring RNC (a Iur link is setup towards the inter-frequency cell).
• Sub-Counter #0: Rescue
• Sub-Counter #1: Service
• Sub-Counter #2: No resource available (CAC failure)
VS. IncomInterFreqHoAtt - #176

Number of hard handovers attempted to this cell from another inter-frequency cell located in the same
RNC (a Iur link is setup towards the inter-frequency cell).
same screenings as #174
VS.OutGoInterFreqHoSuc - #175
Number of successful hard handovers from this cell located on the serving RNC to another inter-
frequency cell located either in the same RNC or in a neighbouring RNC (a Iur link is setup towards the
inter-frequency cell).
VS.IncomInterFreqHoSuc - #177
Number of successful hard handovers to this cell located on the serving RNC from another inter-
frequency cell located in the same RNC (a Iur link is setup towards the inter-frequency cell).

4.7 3G-3G Inter-freq HHO: Intra+Inter RNC with Iur - Rate
Reference FDDCell metric UIMCTA014_CR
3G3G # 175.[all]
3G3GInter-freq
Inter-freqHHO
HHO =
Outgoing
OutgoingFailure
FailureRate
Rate #174.[all]
And per iMCTA cause :

• UIMCTA014_CR_Alarm
• UIMCTA014_CR_Cac
• UIMCTA014_CR_Service
Reference FDDCell metric UIMCTA016_CR
3G3G #177.[all]
3G3GIntra-freq
Intra-freqHHO
HHO =
Incoming
Incoming FailureRate
Failure Rate #176.[all]
And per iMCTA cause :

• UIMCTA016_CR_Alarm
• UIMCTA016_CR_Cac
• UIMCTA016_CR_Service
Mobility Monitoring

4.8 3G-3G Inter-frequency HHO: IntraRNC–Success-counters
S
PS+C
Decision for
UE Source Target RNC HHO
Node B Node B
Measurement Report
RL Setup Request #170[x]

Outgoing intraRNC
RL Setup Response inter-freq HHO attempt
RB Reconfiguration #172[x]
Incoming intraRNC
RB Reconfiguration complete inter-freq HHO attempt
RL Deletion Request
RL Setup Deletion Response

Reference
FDDCell Counters

Mobility Monitoring
VS.IntraRncOutInterFreqHoAttempt - #170
Number of Intra RNC outgoing Hard Handovers attempted from this cell to another cell using another
frequency in the same RNC
A set of subcounters screened on: Reason for initiating the Intra RNC HHO
• Sub-Counter #0 : HO without CM measurements
• Sub-Counter #1 : HO with CM measurements
• Sub-Counter #2 : HSDPA capable mobile to HSDPA layer
• Sub-Counter #3 : HSDPA capable mobile to non-HSDPA layer
• Sub-Counter #4 : Non-HSDPA capable mobile to non-HSDPA layer
VS.IntraRncIncInterFreqHoAttempt - #172
Number of Intra RNC Hard Handovers attempted to this cell from another cell in the same RNC on a
different frequency.
A set of subcounters screened on: Reason for initiating the Intra RNC HHO
• Sub-Counter #0 : HO with CM measurements Inter-Band
• Sub-Counter #1 : HO with CM measurements
• Sub-Counter #2 : HSDPA capable mobile to HSDPA layer
• Sub-Counter #3 : HSDPA capable mobile to non-HSDPA layer
• Sub-Counter #4 : Non-HSDPA capable mobile to non-HSDPA layer
Inter-freq inter-Band HHO are counted in sub-counters s0, intra-band in sub-counters s1.
Sub-counters s2, s3 and s4 are pegged when RRC Traffic Segmentation is performed.
Incremented for both CS and PS cases.

4.9 3G-3G Inter-frequency HHO: IntraRNC–Failure-counters
UE Source Target RNC
Decision for
Node B Node B
HHO
Measurement Report
RL Setup Request
RL Setup Failure #171[x]
Outgoing intraRNC
S inter-freq HHO failure
PS+C #173[x]
Incoming intraRNC
UE Source Target RNC inter-freq HHO failure
Node B Node B
Measurement Report
RL Setup Request
RL Setup Response
Reference
RB Reconfiguration FDDCell Counters
RB Reconfiguration Failure

Mobility Monitoring
VS.IntraRncOutInterFreqHoFail - #171
Number of Intra RNC Hard Handovers attempted from this cell to another cell using another frequency in
the same RNC that failed to complete succesfully.
A set of subcounters screened on: Failure reason for Intra RNC HHO
• Sub-Counter #0 : HO with CM measurement Inter-Band
• Sub-Counter #1 : HO with measurements NodeB failure
• Sub-Counter #2 : HO with measurements Failure on RRC
• Sub-Counter #3 : HO with CM measurement Not enough resources
• Sub-Counter #4 : HO with CM measurement NodeB failure
• Sub-Counter #5 : HO with CM measurement Failure on RRC
VS.IntraRncIncInterFreqHoFail - #173
Number of Intra RNC Hard Handovers attempted to this cell from another using another frequency
in the same RNC that failed to complete succesfully.
A set of subcounters screened on: Failure reason for Intra RNC HHO
• Sub-Counter #0 : HO with CM measurement Inter-Band
• Sub-Counter #1 : HO with measurements NodeB failure
• Sub-Counter #2 : HO with measurements Failure on RRC
• Sub-Counter #3 : HO with CM measurement Not enough resources
• Sub-Counter #4 : HO with CM measurement NodeB failure
• Sub-Counter #5 : HO with CM measurement Failure on RRC
Sub-counters s1 and s2 are always equal to zero.

Inter-freq intra-Band HHO failures are counted in sub-counters s3, s4 and s5.
Inter-freq inter-Band HHO failures are all counted in sub-counters s0.
4.10 3G-3G Inter-frequency HHO - IntraRNC – Failure Rate
Reference FDDCell metric UHO3G3G012_CR
3G3G # 173.[1-5]
3G3GIntra-RNC
Intra-RNCInter-freq
Inter-freq =
HHO
HHO Incoming FailureRate
Incoming Failure Rate #172.[1]
Reference FDDCell metric UHO3G3G011_CR
3G3G #171.[1-5]
3G3GIntra-RNC
Intra-RNCInter-freq
Inter-freq =
HHO
HHO Outgoing FailureRate
Outgoing Failure Rate #170.[1]

Mobility Monitoring

5 HHO 3G-2G Analysis & Troubleshooting

Mobility Monitoring

5.1 CS 3G-2G Mobility Analysis & Troubleshooting
CS 3G2G Mobility Analysis –

Network level CS 3G2G Mobility Analysis –
Counters Network level
Preparation part Low rate execution part 2G side
CS 3G2G Mobility Analysis – CS 3G2G Mobility Analysis –

3G 2G CS HHO Success Rate < Th
RNC level RNC level
UHO3G2G019_R_Cs
Counters Counters
•HO3G2G003 and HO3G2G004

to monitor the detection.
CS 3G2GPreparation
Analysis – Cell level CTG Analysis
Counters 3G-2G HHO CS execution
3G2G HHO CS preparation
success rate
failure rate
UHO3G2G018_R_Cs UHO3G2G020_R_Cs
CS 3G2GPreparation
Analysis – Selected Cells
CTG Analysis Determine the RNC with Determine the RNC with
High UHO3G2G018_R_Cs Low UHO3G2G020_R_Cs
CS 3G2G Preparation Analysis – CS 3G2G Execution Analysis –

RNC level RNC level

Mobility Monitoring

5.2 3G-2G CS HHO Preparation
To determine the worst N cells with a

representative number of Preparation
Preparation 3G2G CS HHO Analysis – 3G2G HHO Failures:
RNC level the highest number of #0109 -#0101
VS.3gto2gHoDetectionFromFddcell -
To determine the rejection causes
3G2G HHO CS preparation VS.RrcHoFromUtranCommand
(Refer to 3GPP TS 25.413):
failure rate
#0558 Iu relocation command
UHO3G2G018_R_Cs
failures CS
High CS 3G2G Rejection

Success rate High CS 3G2G Rejection High CS 3G2G Rejection High CS 3G2G Rejection
Success rate Success rate Success rate
due to Time out due to Other Reasons
due to unable to establish due to Failure in Target System
Check Outage in Transmission Network

Between 3G CN and 2G network Preparation 3G2G HHO Failures Preparation 3G2G HHO Failures Preparation 3G2G HHO Failures
TOP N Cells TOP N Cells TOP N Cells
Check the 2G Neighbouring Check the Outage in

Check the Neighbouring cells Cells capacity Analysis the 2G target network identified
definition
Counter Sub-c ounters Counter Sub-c ounters
558 VS.I uRelocationCmdFailuresCs.3Gto2GRelocTimeoutUeInv 1845 IRATHO.FailRelocPrepOutCS.TRELOCprep_exp

558 VS.I uRelocationCmdFailuresCs.3Gto2GAlreadyInProgrUeInv 1845 IRATHO.FailRelocPrepOutCS.TrLdHighTarCell
558 VS.I uRelocationCmdFailuresCs.3Gto2GFailTargetUeInv 1845 IRATHO.FailRelocPrepOutCS.FailTarSys
558 VS.I uRelocationCmdFailuresCs.3Gto2GUnableToEstabUeInv 1845 IRATHO.FailRelocPrepOutCS.NoResAvr
558 VS.I uRelocationCmdFailuresCs.3Gto2GOtherUeInv 1845 IRATHO.FailRelocPrepOutCS.NoRRTarCell
full list in notes page full list in notes page

Mobility Monitoring
#558
VS.IuRelocationCmdFailuresCs
• Sub-Counter #0 : 3G to 3G UE involved. Relocation timeout
• Sub-Counter #1 : 3G to 3G UE involved. Relocation failure in target system
• Sub-Counter #2 : 3G to 3G UE involved. Relocation unable to establish
• Sub-Counter #4 : 3G to 2G UE involved. Relocation timeout. 'Trelocallocexpiry' (3GPP 25.413)
• Sub-Counter #5 : 3G to 2G UE involved. Relocation failure or relocation not supported in target system
• Sub-Counter #6 : 3G to 2G UE involved. 'Unable to Establish During Relocation' (3GPP 25.413)
• Sub-Counter #8 : 3G to 3G UE not involved. Relocation timeout
• Sub-Counter #9 : 3G to 3G UE not involved. Other relocation failure
#1845
IRATHO.FailRelocPrepOutCS
• Sub-Counter #0 : Relocation Cancelled (10)
• Sub-Counter #1 : Requested Ciphering and/or Integrity Protection Algorithms not Supported (12)
• Sub-Counter #2 : Relocation Failure in Target CN/RNC or Target system (29)
• Sub-Counter #3 : Relocation not supported in Target RNC or Target System (44)
• Sub-Counter #4 : Relocation Target not allowed (50)
• Sub-Counter #5 : No Radio Resources Available in Target Cell (53)
• Sub-Counter #6 : Traffic Load in The Target Cell Higher Than in the Source Cell (57)
• Sub-Counter #7 : Abstract Syntax Error (Reject) (100)
• Sub-Counter #8 : O&M Intervention (113)
• Sub-Counter #9 : No Resource Available (114)
• Sub-Counter #10 : Unspecified Failure (115)
• Sub-Counter #11 : Expiry of the timer TRELOCprep

5.3 3G-2G CS HHO Execution
3G2G CS HHO Execution Analysis –

RNC level To determine the
worst N cells with a
representative
To determine the number of HO From
worst N cells with a UTRAN Failures:
Low HHO 3G2G CS execution
representative success rate the highest number
number of HO From UHO3G2G020_R_Cs of CS Calls drop
UTRAN Failures: due to CS 3G2G
the highest number HHO
of CS HO From
UTRAN Failure
3G-2G HHO CS execution failure rate (reversion to 3G) 3G-2G HHO CS execution failure rate (call drop)
UHO3G2G002_R_Cs UHO3G2G022_R_Cs
3G-2G HHO CS execution failure rate (reversion to 3G) 3G-2G HHO CS execution failure rate (call drop)
TOP N Cells TOP N Cells
UHO3G2G002_C_Cs UHO3G2G022_C_Cs
Check the setting

Target 2G neighboring cells
of 3G2G CS HHO
RF condition analysis
Algorithm Parameters

Mobility Monitoring
The 1st step is to identify the days and the RNC’s with too bad Global CS 3G2G HHO performances
This analysis can be completed with CTg in the cell that are selected for investigation through counter metrics and
can be trigger for further investigations

5.4 Summary
• Could you list the main causes for HHO preparation/execution

failures ?
• What actions could improve HHO preparation/execution

performances ?

Mobility Monitoring

5.6 Actions 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
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 neighboring identifiers (cells, LAC…) in 2G network
Or wrong definition of 2G neighboring identifiers (cells, LAC,…) in 3G network

Mobility Monitoring

5.7 Actions 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

Mobility Monitoring


for this module

Mobility Monitoring

End of Module

Mobility Monitoring

71
Section 7
Network Quality Monitoring
Module 1
9300 WCDMA

Blank Page

Document History
02 2010-08-02 Charneau, Jean-Noel • addition of UL BLER metric for PS

• addition of UE distance distribution metric
• correction of Throughput metrics formula

Module Objectives
Describe the quality metric family

Analyze each metric




Table of Contents
Page
1 Network Quality Overview 7
1.1 What to monitor ? 8
2 Network Quality Monitoring 10
2.1 Quality Monitoring & Troubleshooting 11
2.2 BLER metrics 12
2.2.1 Uplink BLER per PS RB Bit Rate 13
2.3 Throughput metrics 14
3 RF Quality Analysis 15
3.1 DL Quality 16
3.2 DL Level 17
3.3 UE distance 18
3.4 UL RSSI 19
3.5 UL Cell Load 20
3.6 RF Conditions Analysis 21
3.6.1 DL RF Analysis 22
3.6.2 UL RF Analysis 23
End of Module 25



Network Quality Monitoring This page is left blank intentionally

1 Network Quality Overview


1.1 What to monitor ?
Defines the ability of the network to provide quality transmission of the

user requested services
The main focus will be to monitor

Throughput
BLER
Network availability (by mean of Accessibility & Retainability analysis)


1.1 What to monitor ? [cont.]
UTRAN:
Core Network parameters
RF Coverage ControlRF Quality
RLC parameters
RRM Algorithms Fine tuning, mainly
RB Adaptation
iRM Scheduling / DlTxCodePwr
iRM Preemption
Preemtion for DCH and HSxPA
Always-ON
Actions to
improve
Quality KPIs
Server parameters
Network topology


2 Network Quality Monitoring


2.1 Quality Monitoring & Troubleshooting
BLER and Throughput Monitoring & Troubleshooting

Bad RF Quality
In DL: Focus on RF measurements: bad Ec/No, bad RSCP, too high UE
distance, too high or too low SPU, too many ASU/sec, too many CM
activation/sec, too many Primary cell change (impact on HSPA)
In UL: Mainly focus on RSSI
Lack of Resources
Degrading Call reconfiguration
Lots of RRM transitions failures: during AO Upsize, Irm Scheduling
Upgrade, RB Rate Adaptation Upsize
Radio link reconfiguration Unsuccess (iRM reconfiguration)
Radio link setup unsucess (AON)
SHO failures
Radio link addition failures
Radio link setup failures


2.2 BLER metrics
Propose a formula for the three metrics below

Using the counters provided in the comment part
Reference FDDCell metric UBLER008_CR
# 1505.[1,2]
Downlink
Downlink BLER
BLER––AMR
AMR =
# 1505.[0,1,2]
Reference FDDCell metric UBLER009_CR
# 1507.[all]
Uplink
Uplink BLER
BLER––AMR
AMR =
# 1506.[all] + # 1507.[all]
Reference FDDCell metric UBLER006_CR_Ps
# 1559.[all]
Downlink
DownlinkBLER
BLER––Data
Data =
# 1558.[all]

VS.IuDlAmrFrmFqc - #1505
Number of AMR frames received on Iu by FQC
• Sub-Counter #0 : Frame good
• Sub-Counter #1 : Frame bad
• Sub-Counter #2 : Frame bad due to radio
VS.DdUlAmrABtGoodFrm - #1506
Number of AMR frames with Class A bits Transport Block received with CRCi = 0
• Sub-Counter #0 : 12.2 • Sub-Counter #1 : 10.2 • Sub-Counter #2 : 7.95
• Sub-Counter #3 : 7.4 • Sub-Counter #4 : 6.7 • Sub-Counter #5 : 5.9
• Sub-Counter #6 : 5.15 • Sub-Counter #7 : 4.75
VS.DdUlAmrABtBadFrm - #1507
Number of AMR frames with Class A bits Transport Block received with CRCi = 1
Same screening as for #1506
VS.DedicatedDownlinkPdusRlcReferenceCell - #1558
Number of RLC PDUs sent on downlink for the reference cell
• Sub-Counter #0: Other Dl • Sub-Counter #1: Any SRB • Sub-Counter #2: CS speech
• Sub-Counter #3: CS 64 conversational • Sub-Counter #4: CS streaming
• Sub-Counter #5: PS HSDPA • Sub-Counter #6: PS Str 128 • Sub-Counter #7: PS Str 256
• Sub-Counter #8: PS Str 384 • Sub-Counter #9: PS Str Other • Sub-Counter #10: PS I/B 8kbps
• Sub-Counter #11: PS I/B 16kbps • Sub-Counter #12: PS I/B 32kbps • Sub-Counter #13: PS I/B 64kbps
VS.DedicatedDownlinkRetransmittedPdusRlcReferenceCell - #1559
Number of downlink RLC PDU retransmitted on dedicated channels on the reference cell. This counter is
only pegged for RLC AM bearer (so only for PS). This is incremented for the Current RAB and any RLC
PDU (Q01371476). Same screening as for #1558 but s1, s2, s3 and s4 are always zero because RLC TM
mode is used.

2.2 BLER metrics
2.2.1 Uplink BLER per PS RB Bit Rate
UE Node B RNC
#1557 ++
0
Uplink RLC PDU
CRCI ?
1
# 1542 ++
Reference FDDCell metric UBLER004_CR_PsBRx
# 1542.[x]
Uplink
UplinkBLER
BLER––Data
Data--BRx
BRx =
# 1542.[x] + # 1557[x]

VS.DedicatedUplinkBadPdusRlcRefCell - #1542
Number of bad PDUs sent on Dedicated uplink for the reference cell.
Uplink Traffic Counter Screenings
• Sub-Counter #0: Other Ul
• Sub-Counter #1: Any SRB
• Sub-Counter #2: CS speech
• Sub-Counter #3: CS 64 conversational
• Sub-Counter #4: CS streaming
• Sub-Counter #5: PS Str 16
• Sub-Counter #6: PS Str 64
• Sub-Counter #7: PS Str Other
• Sub-Counter #8: PS I/B 8kbps
• Sub-Counter #14: PS I/B HSUPA
• Sub-Counter #15: PS Str HSUPA
VS.DedicatedUplinkPdusRlcReferenceCell - #1557
Number of RLC PDUs sent on uplink for the reference cell.
Reception by the RNC of a RLC PDU with correct CRCI on an uplink dedicated channel

2.3 Throughput metrics
Find the unit of the four metrics below

Using the RNC counters catalogue
RNC metric UTraffic024_R
Traffic 1.024 * 80 * # 1544.[all]

TrafficDL
DLRLC
RLCSDU
SDUThroughput
Throughput =
over RAB allocation time
over RAB allocation time Σcell(# 1666.cum.[all])
RNC metric UTraffic025_R
Traffic
TrafficUL
ULRLC
RLCSDU
SDUThroughput
Throughput 1.024 * 80 * # 1543.[all]
over RAB allocation time =
over RAB allocation time Σcell(# 1667.cum.[all])
Reference FDDCell metric UTraffic030_CR_CallType
Traffic
TrafficDL
DLRLC SDUThroughput
RLCSDU Throughput 1.024 * 8000 * # 1556.[CallType]
over =
over RAB activity timeper
RAB activity time perCall
CallType
Type # 1566.[CallType]
Reference FDDCell metric UTraffic031_CR_CallType
Traffic
TrafficUL
ULRLC SDUThroughput
RLCSDU Throughput 1.024 * 8000 * # 1555.[CallType]
over =
over activity time perCall
activity time per CallType
Type # 1567.[CallType]
VS.DedicatedDownlinkKbytesRlc - #1544
Number of Kbytes of SDU payload sent on dedicated downlink RLCs (from RLC counter:
DCH_DL_SDU_TRAFFIC)
VS.DlAsConfIdAvgNbrEstablished - #1666
indicates an average of the number of DlAsConfIds established per iRNC, based on time average
over collection period
VS.DedicatedUplinkKbytesRlc - #1543 Similar to #1544 but for the Uplink
VS.UlAsConfIdAvgNbrEstablished - #1667 Similar to #1666 but for the Uplink
VS.DedicatedDownlinkKbytesRlcReferenceCell - #1556
Number of Kbytes of SDU sent on downlink for the reference cell
VS.DedicatedDownlinkActivityRlcRefCell - #1566
Time that RAB is actively transmitting data in the downlink
VS.DedicatedUplinkKbytesRlcReferenceCell - #1555 Similar to #1556 but for the Uplink
VS.DedicatedUplinkActivityRlcRefCell - #1567 Similar to #1526 but for the Uplink

3 RF Quality Analysis


3.1 DL Quality
CPICH Ec/N0
#1001.[0,1]
∑ #1001.[0,1,2,3] RNC
CPICH
[0] [1] [2] [3] [4]

VS.IrmcacDistributionEcNO #1043
-24dB -15dB -13dB -11dB -7dB 0dB
Reference FDDCell metric UCell007_C_Min24tomin15
#1043.[0]
Distribution
Distributionof
ofEc/N0
Ec/N0[-24,-15[ =
[-24,-15[ =
#1043.[0,1,2,3,4]

VS.IrmcacDistributionEcNO - #1043: This counter provides the distribution of Ec/N0 measurements

received per range from UEs with that reference cell.
CPICH Ec/N0 are RRC measurements sent by UE to RNC.
Screening:
Sub-Counter #4 : -7 dB <= Measurement < 0 dB

3.2 DL Level
CPICH RSCP
#1001.[0,1]
∑ #1001.[0,1,2,3] RNC
CPICH
[0] [1] [2] [3] [4]

VS.IrmcacDistributionRscp #1158
-120dBm -110dBm -105dBm -95dBm -80dBm -25dBm
Reference FDDCell metric UCell008_C_Min120tomin110
#1158.[0]
Distribution
Distributionof
of RSCP
RSCP[-120,-110[ =
[-120,-110[ =
#1158.[0,1,2,3,4]

VS.IrmcacDistributionRscp #1158: This counter provides the distribution of RSCP measurements

received per range from UEs with that reference.
CPICH RSCP are RRC measurements sent by UE to RNC.
A set of subcounters screened on: Measurement Report power range
• Sub-Counter #4 : -80 dBm <= Measurement <= -25 dBm

3.3 UE distance
AICH RNC
In Band (Propagation Delay)
PRACH
RL Setup request (Propagation Delay)
[0] [1] [2] [x] [7]

VS. DistPropDelayPerRange #1041
0m 468m 702m 1171m 10072m
Percentage of UE access beyond 10km

#1041.[7]
Distribution
Distributionof
of UE
UEdistance
distance==
>>10072m
10072m #1041.[0,1,2,3,4,5,6,7]

VS.DistPropDelayPerRange - #1041: Distribution of propagation delays, as expressed in the 3GPP25.433

Nbap RL Setup Request (when Propagation Delay IE is present)
A set of subcounters screened on: Propagation Delay in terms of chips
• Sub-Counter #0: IE in [0..1] (Cell size < 468m)
• Sub-Counter #1: IE in [2] (468m<= Cell size < 702m)
• Sub-Counter #3: IE in [5] (1171m <= Cell size < 1405m)
• Sub-Counter #7: IE in [43..255] (Cell size equal to or above 10072m)

3.4 UL RSSI
VS.RadioWBandRxMainPwr #10201 FDDCell counter

VS.RadioWBandRxDivPwr #10202
NBAP Common Measurement
UL RTWP
VS.UplinkRssi #303
RTWPmeas
(#10201 + #10202)
2 Traffic
UL RSSI
+ Interference
RTWPref
Noise Factor +
Thermal Noise
FDDCell metric UULOAD002_CR_Avg
Average
AverageUL
ULRSSI dBm)==-112
RSSI(in(indBm) -112++10
10xxlog10(#303.Avg)
log10(#303.Avg)
Too
Toohigh
highUL
ULRSSI
RSSIifif>>-98
-98dBm
dBm
min/ max/ linear average wide-band received power per sector, per frequency, at the Rx main
min/ max/ linear average wide-band received power per sector, per frequency, at the Rx diversity
The Node-B estimates the total UL Radio Load as the linear average between the UL RX Signal Level
measure at bit Main and Diversity antennae.
According to typical values of Thermal Noise and Noise Factor of the Node-B and Rx aerials chain, this
indicator should be not less that –112dBm; typical minimum value should be between –106dBm and –
105dBm.
As the maximum allowed Rot is driven by a parameter lower than 8dB, the maximum value of UL RSSI
should not be over –98dBm = -106dBm + 8dB
The value of this metric should be between -109 dBm and -102 dBm typically.
Max and Min values can also be considered for radio problem investigation.
Delta between Main and Div UL RSSI measurement are also to be considered.

3.5 UL Cell Load
RTWPmeas
Traffic cell load

UL RSSI
+ Interference
RTWPref
Noise Factor +
UULOAD001_CR_x ; x = Min or Max or Avg Thermal Noise
Minimum Uplink Cell Load = #10211.Min / 1000

Maximum Uplink Cell Load = #10211.Max / 1000
RRC connection
Average Uplink Cell Load = #10211.Avg / 1000

• VS.CellULLoad (#10211)
The Node-B computes this indicator from the estimation of the RoT which is equal to the difference
between the total UL RSSI and the RTWPref. .
distribution according to load type: • Total load • eDCH/HSUPA load
Then the UL Cell Load is UL Cell Load = 1 – 10-(RoT/10)
Noise Rise vs. UL load

20
18
16
14
Noise Rise (dB) = RoT
12
10
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
UL load (%)

3.6 RF Conditions Analysis
RF Conditions Analysis –
Cell level
Main and Diversity!
High Percentage of High Percentage of

Low UL RSSI
Bad RSCP Bad Ec/N0 High UL RSSI
DL Interference &/ or
DL Coverage
DL Coverage UL Interference issues UL Interference issues
issues
issues
RF control & optimization:

•Tilts, Antena Orientation,
• RF parameter tuning Call Trace Verification
•Avoid Pilot pollution, Slow handovers, Overshooting Site Visit/Others
Deep RF study
•Cell customization paramters for difference scenarios
(dense, rural, corner sites)
•Power settings
•3g2g strategy, 3g2g tuning, iRM strategy
•Site densification

To evaluate the radio conditions when the calls are established, the following indicators could be
correlated:
RRC Connection Success Rate = RRC.SuccConnEstab[RRCcause]/RRC.AttConnEstab[RRCcause]
The RRC performance of Terminating calls can be better than Originating since Paging decoding has been
performed before hand.
Ratio of RRC Connection Setup repetitions = VS.RrcConnectionSetup/RRC.AttConnEstab

If there is a high repetition rate, it means that the call is being setup in bad radio conditions (lack or
coverage or interfered area)
Ratio of RRC Quick Repeat usage = (VS.RrcConnectionSetup.InitialWithQuickRepeat +
VS.RrcConnectionSetup.FirstRepetitionWithQuickRepeat) / VS.RrcConnectionSetup
If Quick Repeat sub-counter is pegged it means that the call is being setup at bad Ec/Io.

3.6.1 DL RF Analysis
Operator dependance
dependant
RF Conditions Analysis – According to RF design
strategy for
forthe
thedifferent
Cell level services services
different
•Top N worst cells
Correlation with
Correlation
High SPU (RL016)
with High Percentage of High Percentage of
High ASU/s (Rl020)
DL indicators Bad RSCP Bad Ec/N0
Also DL indicators
Ie, higher Radio drops
(see next slide)
DL Interference &/ or
DL Coverage
DL Coverage
issues
issues
RF control & optimization:

•Tilts, Antenna Orientation,
RF parameter tuning
•Avoid Pilot pollution, Slow handovers, Overshooting
•Cell customization paramters for difference scenarios
(dense, rural, corner sites)
•Ping-pong areas optimization
•Note: be aware of if
•Power settings
FET is activated, radio
•3g2g strategy, 3g2g tuning, iRM strategy measurements can be
•Site densification not representative
statically
Two metrics have been tested in order to detect cells with DL radio issues. These metrics can be used
combined with accessibility or call drop ratio.
Percentage of bad Ec/No
Percentage of bad RSCP
These metrics provide with good indications of potential "bad" area. Call drops and even call-setup
failures have been correlated with bad RSCP or Ec/No levels.
These new metrics are strongly recommended for troubleshooting of call drop and accessibility. The
limitation is that if FET is activated samples can not be enough to get meaningful statistics, but those
metrics can be correlated with accessibility metrics that give an idea of radio issues: ie metrics related
to RRC phase like:
RRC Connection Success Rate (by RRC cause)
Ratio of RRC Connection Setup repetitions
Ratio of RRC Quick Repeat usage

3.6.2 UL RF Analysis
RF Conditions Analysis–
Cell level- UL RSSI
High UL RSSI Low UL RSSI
Check correlation Yes

Alarms
RF Alarms?
- TMA LNA FAILED
No Yes Check correlation - VSWR 1/2/3
RF Alarms
Apply High UL RSSI - DDM LNA FAILED
procedures - Any TRM/iTRM receiver
No alarms such as RX
Channelizerfailures.
Checking:
Apply Low UL RSSI Checking:
procedure
- Digital part: TRM, - Digital part: TRM, CCM
CCM and CEM Digital part issue? and CEM
Radiating system?
- RF chain: Interferences? - RF chain: connectors,
connectors, cables, /jammers? cables, DDM
DDM RF
chain?
- Radiatingsystem
- Radiating system connector ACTIONS:
cables
- Interferences Replace cables,
(jammers) CEM, etc
ACTIONS

Threshold Low RSSI

If the RSSI measurement is low, the NodeB assumes that there is a low level of noise (global signal
received, noise + other users) and then the power in uplink requested to the mobile will be very low,
and this can lead to the mobile to never be able to reach the network.
All cells that are seen with a RSSI value constantly below -112dBm are to be considered as suspect and
will require site visit.
According to 3GPP NBAP spec., the minimum value that can be reported by Node-B to RNC on is -112dBm.
Threshold high RSSI:

when there is no call on the cell, the high threshold is at -73dBm, which corresponds to the dynamic
range requirement for the receiver (defined in 3GPP spec 25.104, section 7.3.1, Wide area BS). Above
that level, there is no guarantee that the BTS is able to demodulate an uplink signal (even if received
with a high Eb/N0).
However this threshold is too high. The following is choosen:
RTWP = -108.2 dBm (Thermal Noise at 20°C) + 3.3dB (Noise Factor) + 7dB (80% uplink load) = -98dBm
Assuming RTWP main = RTWP div if RTWP = -98dBm => RTWP main= RTWP div = -98dBm
5dB (NF max. 3GPP)
3.3dB NF (ALU BTS Rx Chain Noise Factor)
Corrective action:
The problem could come from the reception chain of the BTS (RF reception: antenna connectors, cabling,
DDM) or the radiating system (feeder, antenna or external interference).
The other possibility would be the problem is a hardware problem in the BTS digital part (TRM. CCM or
CEM).


for this module


End of Module


81
Section 8
Capacity Monitoring
Module 1
9300 WCDMA

Blank Page

Capacity Monitoring
Document History
02 2010-08-02 Charneau, Jean-Noel • addition of new UA7.1 counter #10318

Module Objectives
Describe the capacity metric family

Analyze each metric

Capacity Monitoring


Capacity Monitoring

Table of Contents
Page
1 Capacity Monitoring 7
1.1 UTRAN capacity analysis strategy 8
1.2 Reactive capacity planning 9
1.3 UTRAN congestion detection principles 10
1.4 Blocking Characterization 11
1.5 Capacity monitoring 12
1.6 Which resource can block ? 13
1.7 Find a counter to detect blocking of a given resource ? 14
2 Capacity Analysis 15
2.1 Principles 16
2.2 Blocking and Load 17
3 Capacity Troubleshooting 18
3.1 DL Tx Power Load 19
3.2 DL Code Load 20
3.3 UL Radio Load 21
3.4 CEM Load 22
3.5 Iub Load 23
3.6 RNC Load 24
3.7 Bottleneck analysis : RB Allocation Procedure 25
3.8 Bottleneck analysis : Per type of call 29
3.9 Solve Capacity Issue 30
3.10 Case Study 31
4 Capacity Licensing Monitoring 32
4.1 NodeB capacity licensing principles 33
8 1 5 4.2 NodeB capacity licensing Tokens All Rights Reserved © Alcatel-Lucent 2010
34
Capacity Monitoring
9300 WCDMA4.3 Capacity
TMO18268 9300 WCDMAlicensing counters
UAO7 R99 QoS Analysis : Example
and Traffic Load Monitoring 35
4.4 Capacity licensing counters screenings 36
4.5 CEM monitoring counter 37
End of Module 39


Capacity Monitoring This page is left blank intentionally

1 Capacity Monitoring

Capacity Monitoring

1.1 UTRAN capacity analysis strategy
Networks have been deployed focusing on the service availability at the
expense of capacity
Traffic is growing constantly
T ra ffic e v o lu tio n d u rin g la s t 6 m o n th s
2 00 0 0 00 0 0
1 80 0 0 00 0 0
1 60 0 0 00 0 0
1 40 0 0 00 0 0
1 20 0 0 00 0 0
1 00 0 0 00 0 0
80 0 0 00 0 0
60 0 0 00 0 0
40 0 0 00 0 0
20 0 0 00 0 0
0
05-nov-05
12-nov-05
19-nov-05
26-nov-05
07-janv-06
14-janv-06
21-janv-06
28-janv-06
01-oct-05
08-oct-05
15-oct-05
22-oct-05
29-oct-05
3 Dec 05
10 Dec 05
17 Dec 05
24 Dec 05
31 Dec 05
4 Feb 06
11 Feb 06
18 Feb 06
25 Feb 06
04-mars-06
11-mars-06
18-mars-06
25-mars-06
1 Apr 06
8 Apr 06
15 Apr 06
C S D L traffic K B y t e s P S D L Tra ffic K B y te s t ot al P S + C S
Operators start to experience some congestion in their networks and foresee

further capacity issues
Two methodologies are possible
Reactive capacity planning
Pro-active capacity planning

Capacity Monitoring
Reactive capacity planning

Bottleneck identification
Detection and characterization
Resolution by RF parameter or RF design tuning or by resource addition
Pro-active capacity planning

Analysis is triggered by disruptive scenarios in order to anticipate their impact:
• New Software release and major feature activation (ie. Cell FACH Step4)
• New service introduction, new subscriber growth rate, new coverage, H/W densification.
• Typically 4-6 times a year.
Capacity planning at UTRAN level taking into account detail node constraint in order to add the right
component at the right place
Pre-sales dimensioning is mainly based on UTRAN Dimension but post sales capacity planning needs to be
synchronized based on actual and accurate capacity assets, deviation must be calculated.
In the following, the training is referring to Reactive Capacity Planning.

1.2 Reactive capacity planning
Done on a regular basis (daily to weekly) in order to react

to observed issues
Load and Blocking are monitored and actions are taken
accordingly
First reaction is based on «system optimization» in order to get the
best of the actual system by means of parameter fine tuning.
Second is to add small H/W component: CEM, E1,..
The methodology for reactive capacity analysis

Bottleneck identification
Detection and characterization
Resolution by tuning or resource addition

Capacity Monitoring
Metrics will have to be monitored on the cells/clusters or RNC. It is recommended to observe the trend
of the daily values at least during one week.
Period with abnormal events like holidays, special events, etc, are from high interest regarding capacity
aspects and should be monitored as well.
Granularity and period of time have to be defined for monitoring reports, but Busy Hours are the critical
periods to study.

1.3 UTRAN congestion detection principles
Principle of congestion
detection Blocking?
NO Status Green
No action required
Combination of blocking + load
indicators for a specific resource
YES
3 states Low Status Yellow

No blocking No action Load
Capacity analysis/tuning
Blocking, low load Capacity
analysis and tuning required High
Blocking + High load Capacity
analysis and tuning required Status Red
and/or resource addition Capacity analysis/tuning
and/or
Resources addition

Capacity Monitoring

1.4 Blocking Characterization
Blocking situation definition

each time the UE requests an UTRAN resource and is not getting it
because the resource is not available
Call Phase Blocking Cause Effect Monitoring detection method
Call Admission Lack of resources at call Call admission failure - RB Establishment Unsuccess
setup - RL Reconfiguration Unsuccess
Call Lack of resources to Call is not reconfigured - RL Reconfiguration Unsuccess (iRM

Reconfiguration perform iRM transitions (impact on user Scheduling, RB Rate Adaptation)
(AON Upsize, iRM Sched throughput) - RL Setup Unsuccess (AON)
Upgrade)
Mobility No resources available Additional RL not added - RL Setup Unsuccess
for additional RL in the Active Set (risk of - RL Addition Unsuccess
call drop) - RL & RB Reconfiguration Unssuccess
for HSDPA

Capacity Monitoring

1.5 Capacity monitoring FDDCell metrics
URB014_C
# 1629.[all except 0]
RB
RBBlocking
BlockingRate
Rate =
# 1652.[all]
URL036_CR
#38.[all except 1]
RL
RLSet-up
Set-upBlocking
BlockingRate
Rate =
#54.[all]
URL037_CR
#39.[all except 1]
RL
RLAddition
AdditionBlocking
BlockingRate
Rate =
#55.[all]
URL038_CR
#40.[all except 1]
RL
RLReconfiguration
ReconfigurationBlocking
BlockingRate
Rate =
#56.[all]
URRC008_CR
Σ #404.[all except 0 ]
RRC
RRCConnection
ConnectionReject
RejectRate
Rate =
Σ #409.[all]
Capacity Monitoring
#1629 VS.RadioBearerEstablishmentUnsuccess:
Number of radio bearer setup not successfully established, with no RADIO_BEARER_SETUP_REQUEST sent.(based on
procedure count, not RBs). Incremented based on reference cell
#1652 VS.RadioBearerSetupRequest:
Number of Radio Bearer setup decisions (leading or not to a RB Setup, ie. Incremented even if CAC rejects the
setup). The counter should be pegged multiple times for multiple RB to be setup in the same procedure.
Incremented based on reference cell.
VS.RadioLinkSetupRequest - #54
Number of internal events that would lead to a radio link setup request
VS.RadioLinkAdditionUnsuccess - #39
Number of unsuccessful radio link addition
VS.RadioLinkAdditionRequest - #55
Number of internal events that would lead to a radio link addition request.
VS.RadioLinkReconfigurationPrepareUnsuccess - #40
Number of failures radio link reconfiguration preparation
VS.RadioLinkReconfPrepReq - #56
Number of internal event that would lead a radio link reconfiguration prepare.
Failed RRC Connection Establishments by Cause.
RRC.SuccConnEstab - #403
Number of rrc connection successful

1.6 Which resource can block ?
UL Radio Load
CEM processing
DL Code
RNC processing
Iub (Bandwidth, AAL2 cid)

DL Tx Power

Capacity Monitoring
Lp = Logical Processor (each CPU board of the RNC is monitored)

Ap = Adjunct Processor (each PMC CPU of each PS FP board of the RNC is monitored)

1.7 Find a counter to detect blocking of a given resource ?
Resource Blocking counters

DL Tx
#1629 VS.RadioBearerEstablishmentUnsuccess.[2]
Power
DL
Code
UL RSSI
( #404.3 RRC.FailConnEstab.RSSI, #10213 VS.FailedAdmissionDueToULload )
CEM processing #1629 VS.RadioBearerEstablishmentUnsuccess.[7]
Iub Bandwidth #1629 VS.RadioBearerEstablishmentUnsuccess.[13]
Iub Transport Id #1629 VS.RadioBearerEstablishmentUnsuccess.[12]
RNC
processing
Capacity Monitoring
The counter providing the number of radio bearer setup not successfully established can be used for
finding out the missing radio resource:
DL Tx Power: VS.RadioBearerEstablishmentUnsuccess.UnavailableDlPowerResources
DL Code: VS.RadioBearerEstablishmentUnsuccess.UnavailableDlCodeResources
UL RSSI: VS.RadioBearerEstablishmentUnsuccess.Unspecified
CEM processing: VS.RadioBearerEstablishmentUnsuccess.NodeBCEMLackofL1Resource
Iub Bandwidth: VS.RadioBearerEstablishmentUnsuccess.LackTransportIdIub
Iub cid: VS.RadioBearerEstablishmentUnsuccess.LackBwthIub
RNC processing: VS.RadioBearerEstablishmentUnsuccess.LackOfRncProcessingResources
As the UL RSSI capacity problem is counted in the global Unspecified sub-counter of RB Setup Unsuccess
it is recommended to check:
the sub-counter #404 RRC.FailConnEstab. RSSI providing the number of RRC Connection
Setup Failures due to UL CAC on RSSI too high
The sub-counter #10213 VS.FailedAdmissionDueToULload.Cum providing the number of
times the RNC rejects an UL admission (SRB or TRB) for too high UL Load reason
As the CEM capacity problem is counted in the dedicated sub-counter NodeBCEMLackofL1Resource of

RB Setup Unsuccess it is no more needed to check the counters iving the Number of times a CEM
Allocation fails.

2 Capacity Analysis

Capacity Monitoring

2 Capacity Analysis
2.1 Principles
Two strategies are used for capacity analysis

General network view (top to bottom approach).
Monitoring the distribution of the congestion & load of the different
network elements for the different resources at network level
Spatial view/Time view
Then a threshold for troubleshooting is set to focus on the worst cases per
resources
Top N most congested network element (Bottom up approach)
According to one metric, network element are ordered
Thresholds for troubleshooting are also set with this methodology

Capacity Monitoring

2 Capacity Analysis
2.2 Blocking and Load
Congestion evaluation through Blocking Rate distribution per cell

Blocking Rate per cell = RB Blocking at BH / RB Setup Request at BH
BH = most loaded Hour of the day in terms of RB Setup Request
Load is analyzed by bottleneck type at the BH of each Cell

UL RSSI - through Max and Average UL RTWP at Main and Div Antenna
CEM Load – through Max and Average of CEs in use per cell at BH
Iub Load – through Max and Average of Iub Load DL metric calculated
per day
DL Power Load – through Max and Average % of Tx Carrier Power in use
at BH
Codes load – through Min and Average of Free codes SF128 at BH
PMC(TMU & RAB) load – through Average PMC Load supporting TMU &
RAB functions for the entire period (for each RNC)
Capacity Monitoring
Congestion at network level is evaluated through Blocking Rate distribution per cell.
Blocking Rate per cell is computed as a ratio between the RB Blocking at BH and RB Setup
Request at BH for the entire observation period.
The BH is based on the most loaded Hour of the day in terms of Radio Bearer Setup Request and
it is calculated for each cell, each day. It can be different for each cell, each day.
Load is analyzed by bottleneck type at the BH of each Cell:
CEM Load – through Max of CEMUsed.Avg & Max per cell at BH.
Iub Load – through Max of Iub Load DL metric calculated per day
DL Power Load – trough Tx Carrier Power Avg & Max at BH divided by PA Power
available@ref_point (calculated)
Codes load – through Average of Free codes SF128 Min at BH metric
PMC(TMU) load – through Average and Maximum PMC Load supporting TMU function for the entire
period (for each RNC)
VS.CEMUsedDCH - #10301 (replaced the couter VS.CEMUsed - #10301)
min/max/avg of the ratio between the CEM capacity used and the total CEM capacity that was available
at the BTS startup, restricted to DCH.
a sampling event generated by the CCM CallP every 5 seconds that gets the current percentage
of CEM used (restricted to DCH : HSxPA are excluded)
VS.ApCpuUtilizationAvg - #20202
This attribute indicates the processor average CPU utilization over the collection interval. This
is calculated using data sampled every 100 milliseconds.

3 Capacity Troubleshooting

Capacity Monitoring

3.1 DL Tx Power Load
DL Power Load
#1124 VS.IRMTimeCellRadioColorRed
70 %
60 %
50 %
40 %
#1125 VS.IRMTimeCellRadioColorYellow
#1126 VS.RMTimeFreeDlCodesBySpreadingFactor
90 %
80 % #1138
VS.IrmPreemptionTimeCellColorCongestedBecauseOfPower
#1701.4 VS.PreemptNbPerCacFail..RNCDLPowerRsrcNotAvail
#1002 VS.AvgTxPower (.Avg, .Max ) #10205 VS.RadioTxCarrierPwr (.Oper, .Used)
#306 VS.IrmcacPowerDist #10216 VS.PAPowerCapacity.NbEvt

#10216 VS.PAPowerCapacity.CumHWcapacity
#307 VS.DistDlTtlPwrRatio
#10216 VS.PAPowerCapacity.CumLicensing
#308 VS.DlTtlTxPwrR99Only #10216 VS.PAPowerCapacity.CumUsed

Capacity Monitoring
VS.IRMTimeCellRadioColorRed - #1124 (per Cell): Load counter that tracks the percentage of time during a collection period that
a particular cell is considered red by iRM
VS.IRMTimeCellRadioColorYellow - #1125 (per Cell): Load counter that tracks the percentage of time during a collection period
that a particular cell is considered yellow by iRM
VS.IRMTimeFreeDlCodesBySpreadingFactor - #1126 (per Cell): Load counter that tracks the average number of free DL codes for
each spreading factor:
IrmPreemptionTimeCellColorCongestedBecauseOfPower - #1138 (per Cell): Load counter that tracks the percentage of time
during a collection period that a particular cell is considered congested by iRM because of Power shortage
VS.PreemptNbPerCacFail - #1701 (per Cell): Number of times (per CAC failure) the preemption resource deallocation procedure is
required
• Sub-Counter #4: RNC DL power resources not available
VS.AvgTxPower - #1002 (per Cell): Average of Tx Power measurements received from that cell
VS.IrmcacPowerDist - #306 (per Cell): Number of seconds per range of power considered by the CAC algorithm for that cell. The
percentage is calculated as PowerReserved divided by MaxTxPower.
• Sub-Counter #0: 0 to 40 percent of total power • Sub-Counter #1: 40 to 70 percent of total power
• Sub-Counter #2: 70 to 80 percent of total power • Sub-Counter #3: 80 to 90 percent of total power
• Sub-Counter #4: 90 to 100 percent of total power
VS.DistDlTtlPwrRatio - #307 (per cell): DL TX power ratio P/Pmax received from NBAP common measurement per cell. It details
the number of common measurements, according to their respective ranges and during the reporting period
VS.DlTtlTxPwrR99Only - #308 (per Cell): DL TX power (of all codes not used for HS transmission) ratio P/Pmax received from NBAP
common measurement per cell.
• Sub-Counter #0: ratio greater or equal zero and less than 20 • Sub-Counter #1: ratio greater or equal to 20 and less than 40
• Sub-Counter #2: ratio greater or equal to 40 and less than 60 • Sub-Counter #3: ratio greater or equal to 60 and less than 80
• Sub-Counter #4: ratio greater or equal to 80 and less or equal to 100
VS.RadioTxCarrierPwr - #10205 (per BTSCell): min/max/linear average (software filtered) total transmitted power per sector and
per frequency at the Tx channelizer
• Sub-Counter #0: Operational Max Power • Sub-Counter #1: • Power used
VS.PAPowerCapacity - #10216 (per BTSEquipment): PA power capacity installed, licencied and used
• Sub-Counter #0: Number of events • Sub-Counter #1: Sum of HW installed values
• Sub-Counter #2: Sum of Licensing values • Sub-Counter #3: Sum of used values

3.2 DL Code Load
DL Code Load
#1124 VS.IRMTimeCellRadioColorRed
70 %
60 %
50 %
40 %
#1125 VS.IRMTimeCellRadioColorYellow
#1126 VS.RMTimeFreeDlCodesBySpreadingFactor
90 %
80 % #1137
VS.IrmPreemptionTimeCellColorCongestedBecauseOfOvsfCodes
#1701.3 VS.PreemptNbPerCacFail.RNCDLCodeRsrcNotAvail

Capacity Monitoring
VS.IRMTimeCellRadioColorRed - #1124 (per Cell): Load counter that tracks the percentage of time
during a collection period that a particular cell is considered red by Irm
VS.IRMTimeCellRadioColorYellow - #1125 (per Cell): Load counter that tracks the percentage of time
during a collection period that a particular cell is considered yellow by iRM
VS.IRMTimeFreeDlCodesBySpreadingFactor - #1126 (per Cell): Load counter that tracks the average
number of free DL codes for each spreading factor:
VS.IrmPreemptionTimeCellColorCongestedBecauseOfOvsfCodes - #1137 (per Cell): Load counter that

tracks the percentage of time during a collection period that a particular cell is considered congested
by iRM because of Code shortage
VS.PreemptNbPerCacFail - #1701 (per Cell): Number of times (per CAC failure) the preemption
resource deallocation procedure is required
• Sub-Counter #3: RNC DL code resources not available

3.3 UL Radio Load
UL Radio Load
#1194 VS.IRMTimeULRadioLoadColorRed
70 %
60 %
50 %
40 %
#1193 VS.IRMTimeULRadioLoadColorYellow
#303 VS.UplinkRssi (.Avg, .Max, .Min) #10211 VS.CellULload.Total

#1042 VS.DistRssi
#10213 VS.FailedAdmissionDueToULload (Avg., .Max, .Min)

Capacity Monitoring
VS.IRMTimeULRadioLoadColorYellow - #1193 (per Cell): Percentage of time during a collection period

that the UL Radio Load color is yellow for the relating cell.
VS.IRMTimeULRadioLoadColorRed - #1194 (per Cell): Percentage of time during a collection period that
the UL Radio Load color is red for the relating cell.
VS.UplinkRssi - #303 (per Cell): Uplink RSSI received from NBAP common measurement per cell
VS.DistRssi - #1042 (per Cell): Uplink RSSI received from NBAP common measurement per cell. It details
the number of common measurements (here, UL RSSI level) according to their respective ranges and
during the reporting period.
• Sub-Counter #0: -97.0dBm <= Measurement
• Sub-Counter #1: -100.0dBm <= Measurement < -97.0dBm
• Sub-Counter #4: Measurement < -105dBm
VS.CellULload - #10211 (per BTSCell): The mean UL Load value

• Total load
• eDCH/HSUPA load
VS.FailedAdmissionDueToULload (BTSCell) - #10213: Total number of failed UL admission due to excessive load in the cell

3.4 CEM Load
CEM Load
#1178 VS.QosDlCemLdClrRed
70 % #1181 VS.QosUlCemLdClrRed
60 %
50 %
40 %
#1177 VS.QosDlCemLdClrYellow
#1180 VS.QosUlCemLdClrYellow
90 %
80 % #1179 VS.QosDlCemLdCellPreemptClrCngstd
#10310 VS.LocalCellGroupLoad.FreeUL #10301 VS.CEMUsedDCH (.Avg, .Max, Min)

#10310 VS.LocalCellGroupLoad.UsedUL
#10403 VS.cpuLoad.CEM (.Avg, .Max, Min)
#10310 VS.LocalCellGroupLoad.FreeDL
#10403 VS.cpuLoad.CCM (.Avg, .Max, Min)
#10310 VS.LocalCellGroupLoad.UsedDL
#10317 VS.R99CECapacity.NbEvt
#10317 VS.R99CECapacity. AllocSuccess #10317 VS.R99CECapacity.CumHWcapacity
#10317 VS.R99CECapacity. AllocLicensingRefusal #10317 VS.R99CECapacity.CumLicensing
#10317 VS.R99CECapacity. AllocHWfail #10317 VS.R99CECapacity.CumUsed

Capacity Monitoring
VS.QosDlCemLdClrRed - #1178 (per Cell): Load counter that tracks the percentage of time during a collection
period that a particular cell is considered red by CEM load because of CEM radio resource shortage in downlink
VS.QosUlCemLdClrRed - #1181 (per Cell): Load counter that tracks the percentage of time during a collection
period that a particular cell is considered red by CEM load because of CEM radio resource shortage in uplink
VS.QosDlCemLdClrYellow - #1177 (per Cell): Load counter that tracks the percentage of time during a collection
period that a particular cell is considered yellow by CEM load because of CEM radio resource shortage in downlink
VS.QosUlCemLdClrYellow - #1180 (per Cell): Load counter that tracks the percentage of time during a collection
period that a particular cell is considered yellow by CEM load because of CEM radio resource shortage in uplink
VS.QosDlCemLdCellPreemptClrCngstd - #1179 (per Cell): Load counter that tracks the percentage of time during a
collection period that a particular cell is considered congested by iRM because CEM shortage in downlink
VS.LocalCellGroupLoad - #10310 (per LocalCellGroup): number of CE (channel elements) used for a local cell group
(restricted to DCH)
• Free UL capacity • Used UL capacity
• Free DL capacity • Used DL capacity
VS.R99CECapacity - #10317 (BTSEquipment): R99 CE capacity installed, licencied and used

• Sub-Counter #0: Number of events
• Sub-Counter #1: Sum of HW installed values
• Sub-Counter #2: Sum of Licensing values
• Sub-Counter #3: Sum of used values
• Sub-Counter #4: Number of successes
• Sub-Counter #5: Number of refusals or restrictions due to the license
• Sub-Counter #6: Number of refusals due to the hardware capacity
VS.CEMUsedDCH - #10301 (BTSEquipment): min/max/avg of the ratio between the CEM capacity used and the total
CEM capacity that was available at the BTS startup, restricted to DCH.
Note: Formula used for CEMUsedDCH computation is changing according to BTS CEM configuration and capacity licensing feature activation:
If Capacity Licensing is not active and only iCEM is handling R99 Traffic (r99MaxNumberCeXcem = 0), it represents the % of CEM processing
capacity used. Based on internal DSP processing usage, it is not linked to CE consumption (same formula as in previous releases).
If Capacity Licensing is active or in case of xCEM handling R99 Traffic (r99MaxNumberCeXcem ≠ 0), the CEMUsedDch will be based on CE model
(used vs. available CEs)

3.5 Iub Load
CEM Load
#1182 VS.IrmTimeDlIubTransportColorRed
70 %
60 %
50 %
40 %
#1183 VS.IrmTimeDlIubTransportColorYellow
90 %
80 % #1156 VS.IrmPreemptionTimeDlIubTransportCongested
#1758 VS.DistIubLoadAal2If
#1765 VS.DistIubLoadIpIf

Capacity Monitoring
VS.IrmTimeDlIubTransportColorRed - #1182 (per Cell): Load counter that tracks the percentage of time
during a collection period that a particular cell is considered red by iRM because of Downlink Iub
transport resource shortage
VS.IrmTimeDlIubTransportColorYellow - #1183 (per Cell): Load counter that tracks the percentage of
time during a collection period that a particular cell is considered yellow by iRM because of Downlink
Iub transport resource shortage
VS.IrmPreemptionTimeDlIubTransportCongested - #1156 (per Cell): Load counter that tracks the time
during a collection period that a particular cell is considered Congested by iRM Preemption because of
Downlink Iub transport shortage.
VS.DistIubLoadAal2If - #1758 (per Iub AAL2If BP): Number of seconds per range of IuB load per
bandwidth pool based on real time traffic with granularity of 10 second.
• Sub-Counter #0: 0-20% of total Bandwidth
VS.DistIbuLoadIpIf - #1765 (per Iub IpIf BP): Number of seconds per range of IuB load per bandwidth
pool based on real time traffic with granularity of 10 second.

3.6 RNC Load
Packet Server FP #01
PMC PMC PMC

Master PC TMU
7 Packet Server
6 Packet Server
5 Packet Server
4 Packet Server
3 Packet Server
2 Packet Server
1 CP3
0 CP3
A Not Used
PMC PMC PMC

15 Packet Server RAB RAB RAB
14 Packet Server
13 Packet Server
12 Packet Server
11 Packet Server
10 Packet Server
9 OC-3/STM-1
8 OC-3/STM-1
B Not Used
Adjunct Processor
Fabric CPU load
interface
Logical Processor
CPU load
#20103 VS.CpuUtilAvg
#20104 VS.CpuUtilAvgMin
#20105 VS.CpuUtilAvgMax #20202 VS.ApCpuUtilizationAvg
#20201 VS.ApCpuUtilizationHistogram

Capacity Monitoring
VS.CpuUtilAvg - #20103 (per Lp): This attribute indicates an average processor utilization level over the
specified time period, timeInterval. This average is calculated based on one minute CPU utilization
averages.
VS.CpuUtilAvgMin - #20104 (per Lp): This attribute indicates the minimum processor utilization level
over a specified time period, timeInterval. This is based on one minute CPU utilization averages.
VS.CpuUtilAvgMax - #20105 (per Lp): This attribute indicates the maximum processor utilization level
over a specified time period, timeInterval. This is based on one minute CPU utilization averages.
VS.ApCpuUtilizationHistogram - #20201 (per Ap): This attribute indicates a histogram of Adjunct

Processor's CPU utilization. Every 100 milliseconds, the average CPU utilization for the previous 100
millisecond interval is used to select a bin from the vector and the bin is incremented.
• Sub-Counter #0: less than 50%
• Sub-Counter #1: greater or equal than 50% and less than 60%
• Sub-Counter #8: equal to 100 %
VS.ApCpuUtilizationAvg - #20202 (per Ap): This attribute indicates the processor average CPU
utilization over the collection interval. This is calculated using data sampled every 100 milliseconds.

3.7 Bottleneck analysis : RB Allocation Procedure
UE Node B RNC CN - CS
RAB Assignment Request
1
2
RNC CAC 3
Radio Link Reconfiguration Prepare

4
A
B BTS CAC
C Radio Link Reconfiguration Ready
5
UP / DL Synchronization
UP / UL Synchronization
AAL2 / ERQ
6
AAL2 / ECF
UP / Initialization
UP / Initialization Ack.
Radio Link Reconfiguration Commit

7
Radio Bearer Setup

8
RAB Assignment Response

Capacity Monitoring

3.7 Bottleneck analysis : RB Allocation Procedure [cont.]
1 #1652 - VS.RadioBearerSetupRequest (based on the requested Downlink AsConfID)
2 #1629.0 - VS.RadioBearerEstablishmentUnsuccess cause “InvalidRabParametersValue”
3 #1629 - VS.RadioBearerEstablishmentUnsuccess following screenings:
1 – “UnavailableDlCodeResources”
2 – “UnavailableDlPowerResources”
4 – “RlFailOrRlcErr”
6 – “LackOfRncProcessingResources”
9 – “LackTransportIdIu”
10 – “LackBwthIu”
11 – “LackTransportIdIur”
12 – “LackBwthIur”
13 – “LackTransportIdIub”
14 – “LackBwthIub”
4 #0056 – VS.RadioLinkReconfPrepReq (set of Downlink Access Stratum)
5 #0050 - VS.RadioLinkReconfigurationPrepareSuccess (set of Downlink Access Stratum)

#1629.7 - VS.RadioBearerEstablishmentUnsuccess cause “NodeBCEMLackofL1Resource”
#0040 - VS.RadioLinkReconfigurationPrepareUnsuccess with following screenings:
0 – “RadioLinkReconfigurationFailure” (Reception of RL Reconfiguration Failure msg)
1 – “TimeoutNbap”
4 – “NodeBCEMLackL1Rsrc”
5 – “LackCidOrUdpPortIub” (Lack of CID on the Iub)
6 – “LackBwthIub” (Lack of bandwidth on the Iub)
7 – “INodeRefusal” (other I-Node resource not available ...)
6 #1629.3 - VS.RadioBearerEstablishmentUnsuccess cause “Unspecified”
7 #0051 - VS.RadioLinkReconfigurationCommit (set of Downlink Access Stratum)
#0026 - VS.RadioLinkReconfigurationCancel
8 #1650 - VS.RadioBearerSetupSuccess (set of Downlink Access Stratum)
#0602 - VS.RadioBearerSetupUnsuccess (Failure cause)
Capacity Monitoring

A #10309 CEMAlloc with following screenings:
screen id Screen Name Suffix 3GPP
0 Allocation success (RL Setup or RL Reconf) Success
2 Allocation fail for RL SetUp due to lack of resources causes FailSetup
3 Allocation fail for RL Reconf due to lack of resources causes FailReconf
4 Allocation fail for RL SetUp, due to capacity licensing blocking FailSetupLock
5 Allocation fail for RL Reconf, due to capacity licensing blocking FailReconfLock
#10311 CEMAllocSuccessUL LocalCellGroup counters

#10312 CEMAllocSuccessDL
#10313 CEMAllocFailedUL screen id Screen Name Suffix 3GPP
#10314 CEMAllocFailedDL
#10315 CEMAllocFailedBothUL
#10315 CEMAllocFailedBothDL
0 For SF4 SF4
All these counters are pegged
1 For SF8 SF8
on a per SF basis, indicating the
UL or DL SF that was rejected 2 For SF16 SF16
due to lack of CEM resources : 3 For SF32 SF32
4 For SF64 SF64
#10318 VS.CEMAllocDCH 5 For SF128 SF128

• Sub-Counter #0: Allocation successes for DCH 6 For SF256 SF256
• Sub-Counter #1: Allocation fails for DCH
BTSCell counter
Capacity Monitoring
New counter in UA7.1 to be able to monitor CEM load at Cell level and not anymore at
LocalCellGroup level only.
VS.CEMAllocDCH - #10318
Number of times allocation of CEM resources succeeded, and failed (due to no CEM resource
available)
Success and fail of CEM allocations, DCH part
• Sub-Counter #0: Allocation successes for DCH
• Sub-Counter #1: Allocation fails for DCH
• Sub-Counter #2: Allocation successes for HSDPA, DCH part
• Sub-Counter #3: Allocation fails for HSDPA, DCH part
• Sub-Counter #4: Allocation successes for eDCH, DCH part
• Sub-Counter #5: Allocation fails for eDCH, DCH part

B #10213 FailedAdmissionDueToULload
It counts all UL allocation resources events (RL Setup, RL Addition, RL Reconfiguration)
C CEM Capacity Licensing counters:

#10317 R99CECapacity (screening table below)
#10835 HsdpaUsersCapacity (screening table below)
#10836 HsdpaThroughputCapacity (screening table below)
#10909 eDCHUsersCapacity (screening table below)
#10910 eDCHThroughputCapacity (screening table below)
screen id Screen Name Suffix 3GPP
0 Number of events NbEvt
1 Sum of HW installed values CumHWcapacity
2 Sum of Licensing values CumLicensing
3 Sum of used values CumUsed
4 Number of successes AllocSuccess
5 Number of refusals or restrictions due to the license AllocLicensingRefusal
6 Number of refusals due to the hardware capacity AllocHWfail

Capacity Monitoring

3.8 Bottleneck analysis : Per type of call
Studying capacity problems per type of call allows

to verify that CS services are less degraded than PS services
to provide more information for capacity blocking troubleshooting
VS.RadioBearerSetupSuccess. TargetTypeofCall.callType
VS.RadioBearerSetupRequest.TargetTypeofCall.callType
This will show what kind of services is blocking and indicate which
actions is to be taken
If CS is blocked, there is not too much tuning to perform – resources addition
is needed.
If PS is blocked there is still iRM tuning to foresee before deciding to add
resources.

Capacity Monitoring

3.9 Solve Capacity Issue
SOLUTION
Bottleneck Parameter Tuning Resource Addition
Add a 2nd frequency (add MCPA HW)
DL RF Add MCPA SW resource (token)
Power Change for a higher power MCPA
iRM CAC PS call management Site Densification
OVSF
Add a 2nd frequency
Codes
Channel Add CEM SW resource (token)

iRM CAC PS call management
Elements Add CEM HW resource
iRM CAC PS call management

Transport Add E1
EBR
RNC Add PS-FP board

No Tuning Available
PMC-TMU Add an RNC
Site verification
- Remove external interferer
UL RSSI iRM CAC PS call management - Repair cable, connector, TMA, TRM….
Solve UL radio pollution problem
Add a 2nd frequency
Capacity Monitoring

3.10 Case Study
CEMUsedMax%
NodeB1_iCemUsedEvolution CEMUsedMin%
CEMAllocFail
35 2
30
25
20
1
15
10
5
0 0
Day1 01:00
Day1 09:00
Day1 17:00
Day2 01:00
Day2 09:00
Day2 17:00
Day3 01:00
Day3 09:00
Day3 17:00
Day4 01:00
Day4 09:00
Day4 17:00
Day5 01:00
Day5 09:00
Day5 17:00
Day5 01:00
Day5 09:00
Day5 17:00
Day6 01:00
Day6 09:00
Day6 17:00
Day7 01:00
Day7 09:00
Day7 17:00
What isshows
NodeB1 the capacity problem
CEM blocking that
whereas canload
iCEM be reaches
observed in
33%. the chart above ?
NodeB1 hascause
Find the 3 CEMs
ofinserted on the knowing
the problem BTS but only
the1Iub
vcctransport
CCP is declared.
configuration of site
Therefore 2 CEMs are installed on the BTS but are not carrying traffic because they
do not have CCP VCC provisioned.
This explains CEM resource blocking even if 100% of CEM HW capacity is not
reached
Capacity Monitoring
The NodeB has 3 CEM equipped in the BTSEquipment cabinet.

The Iub Transport configuration of this NodeB is shown below:
INVccGroup
VCC OAM VPi/VCi
VCC NodeBCP VPi/VCi
VCC CCP VPi/VCi RNC
VCC DS traffic VPi/VCi/PathId/QoSId

VCC NDS traffic VPi/VCi/PathId/QoSId
VCC HSDPA traffic VPi/VCi/PathId/QoSId

4 Capacity Licensing Monitoring

Capacity Monitoring

4.1 NodeB capacity licensing principles
Node B
Per OMC capacity licenses
License keys OMC

server Spare capacity
License keys
capacity dispatched to the BTS
management
NodeBs capacity controlled via
licensing capacity parameters
R’99 CE capacity
xTRM
xTRM
Node B
i or xCEM HSDPA capacity
Node B MCPA RRH
Node B EDCH capacity
Node B
Activation of second carrier

PA Power
Remaining H/W Capacity
RRH power Number of carriers
S/W allowed Capacity

Capacity Monitoring
This feature provides the technical base for ‘Pay-as-you-grow’ commercial schemes. With a licensing
scheme in place, the operator can order HW with a reduced capacity and subsequently purchase
licenses for additional capacity
NodeB capacity licenses are per OMC; the operator can distribute capacity between controlled BTSs via
licensing parameters
The following NodeB capacity aspects are managed in UA06 via this feature: CEM R99 capacity,CEM HSDPA
capacity, CEM HSUPA capacity, xTRM capacity, RRH capacity, PA power & RRH power
Additional capacity licence is OMC wide and can be distributed between the controlled BTSs (intra-OMC);
there is no exchange of licenses between OMCs
License file: it is a file describing the total capacity (temporary or permanent) allocated for all BTSs of a given
OMC. This file is protected by a digital signature.
HW Capacities: Customer can purchase independently HW and capacities (note that the following table
is provided as an example and not as an ALU commitment on the list of purchaseable items or
“packs”):
iCEM xCEM All RRH types

iCEM64 iCEM128 xCEM
RRH H/W RRH (one carrier) + reduced power
H/W H/W H/W
+ + + #of additional RRH carrier
minimum minimum minimum activation/NodeB (step:1)
RRH_Carriers
CEM H/W capacity capacity capacity RRH_powerBlocks of 10W at RRH ouput
R99 capacity Blocks of 16CE
Blocks
HSDPA of (8 HSDPA connections + 1.8 Mbit/s)
capacity
Blocks
HSUPA of (8 HSUPA connections + 480 kbit/s)
capacity
All PA types
iTRM xTRM
TRM HW iTRM xTRM (one carrier)
PA H/W PA + reduced power
#of second xTRM carrier
Power (W) Blocks of 15W at PA output
N/A
xTRM_Carriers activation/NodeB (step:1)

4.2 NodeB capacity licensing Tokens
NodeB resources submitted to licensing

Capacity Monitoring
The table above shows how the BTS resources are managed by Capacity Licensing parameters and
summarizes the units and capacity increase steps for each area.
For Capacity Licensing purpose, new configuration parameters were introduced in UA6.0 for each of the
above mentioned resources (under a new object : Capacity).
Most of UA4.2 & UA5.x capacity parameters become obsolete face to the new capacity licensing feature
(see „Parameters and Algorithm“ Training for details).

4.3 Capacity licensing counters : Example
UA05 UA06 Name Triggering Event

VS.R99CECapacity: R99 CE capacity installed, Sampling event generated by the CCM CallP
#10317
licensed and used every 5 seconds
Other Counter related to capacity licensing:
CEM Counters PA/RRH Counters

#10835 HsdpaUsersCapacity – unit: Nb. of users #10214 TRMSecondCarriersCapacity – unit: Nb. of carriers
#10836 HsdpaThroughputCapacity – unit: kbits/s #10215 RRHSecondCarriersCapacity – unit: Nb. of carriers
#10909 eDCHUsersCapacity – unit: Nb. of users #10216 PAPowerCapacity – unit: Watt
#10910 eDCHThroughputCapacity – unit: kbits/s #10217 RRHPowerCapacity – unit: Watt

Capacity Monitoring
Capacity Licensing brings a new set of capacity counters allowing monitoring CEM blocking and usage in
parallel with the existing counters. These counters are per Node B (covering all resources of a given
type).
CEM Counters
#10317 R99CECapacity – unit: Nb. of CEs
#10835 HsdpaUsersCapacity – unit: Nb. of users
#10836 HsdpaThroughputCapacity – unit: kbits/s
#10909 eDCHUsersCapacity – unit: Nb. of users
#10910 eDCHThroughputCapacity – unit: kbits/s
PA/RRH Counters
#10214 TRMSecondCarriersCapacity – unit: Nb. of carriers
#10215 RRHSecondCarriersCapacity – unit: Nb. of carriers
#10216 PAPowerCapacity – unit: Watt
#10217 RRHPowerCapacity – unit: Watt

4.4 Capacity licensing counters screenings
UA06 screenings
0 NbEvt Number of events
PA/
1 CumHWcapacity Sum of HW installed values RRH
2 CumLicensing Sum of Licensing values
CEM 3 CumUsed Sum of used values
4 AllocSuccess Number of successes
5 AllocLicensingRefusal Number of refusals or restrictions due to the license
6 AllocHWfail Number of refusals due to the hardware capacity
Counters can be used as a ratio

between ScrX and Scr0

Capacity Monitoring
Screenings 1, 2 and 3 correspond to HW capacity (installed, licensed and used)

Screenings 4, 5 and 6 refer to the outcome of the CEM allocation procedure
Screening 0 used for calculation of average values
These counters can be used as a ratio between ScrX and Scr0 in order to get relevant information per
observation period.
Example: Number of HW Installed R99 CEs during observation period will be equal to:
R99CECapacity.scr1 / R99CECapacity.scr0 (this should be constant if no new HW is added or removed – same
for scr2/scr0)
In case of throughput counters, the number of rejected CEM resource requests (Scr5 & Scr6) will be in fact
the number of active TTI (2ms for HSD and 10 ms for HSU) during which the scheduler restricted the
throughput because the license or HW throughput limit was reached.

4.5 CEM monitoring counter
Name Modification
VS.CEMAlloc: Number of times allocation of CEM resources succeeded, Screenings

#10309
and failed (due to no CEM resource available) added/removed
0 Success Screenings correspond to outcome of

CEM resources allocation procedure
1 Unused
2 FailSetup
3 FailReconf
4 FailSetupLock
5 FailReconfLock
Counters incremented when

CEM allocation Fails due to
licensing capacity limits
reached

Capacity Monitoring
Call Admission Blocking due to Lack of CEM resources (User plane). Counters were enhanced in UA6.0:
Per FddCell => VS.RadioBearerEstablishmentUnsuccess.NodeBCEMLackofL1Resource
new screening of existing counter providing direct information on CEM blocking
Other CEM resources allocation counters enhanced in UA6.0:
Per LocalCellGroup => CEMAlloc enhanced with following screenings:
UA05 screening Fail is replaced in UA06 by screenings:

FailSetup (resources availability)
FailReconf (resources availability)
FailSetupLock (licensing)
FailReconfLock (licensing)


for this module

Capacity Monitoring

End of Module

Capacity Monitoring

91
Section 9
Traffic Monitoring
Module 1
9300 WCDMA

Blank Page

Traffic Monitoring
Document History
02 2010-08-02 Charneau, Jean-Noel • addition of Traffic (kbytes) indicators for

CsSpeech and CsVideo
• addition of Traffic (kbytes) indicators for
Background and Interactive RABs on DCH
• modification of Avg Nb of Calls indicators

Module Objectives
Describe the traffic and call profile metric family

Analyze each metric

Traffic Monitoring


Traffic Monitoring

Table of Contents
Page
1 Traffic Monitoring 7
1.1 Network Traffic 8
1.2 Average Number of Calls per Day – RNC metrics 9
1.3 Average Number of Calls per Day –DL- Cell metrics 10
1.4 Average Number of Calls per Day –UL- Cell metrics 11
1.5 Uplink/ Downlink CS Traffic 12
1.6 Uplink/ Downlink PS Traffic 13
1.7 Uplink / Downlink PS Traffic per QoS 14
2 User-Perceived Throughput Counters 15
2.1 Goal 16
2.2 Principles 17
2.3 Characteristics 18
2.4 Algorithm for DL Throughput Calculation 19
2.5 New Counters for R99 Throughput 21
2.6 Screenings Ps R99 23
End of Module 25

Traffic Monitoring


Traffic Monitoring This page is left blank intentionally

1 Traffic Monitoring

Traffic Monitoring

1.1 Network Traffic
The objective of the Traffic metrics is to evaluate the traffic volume

seen on the network in downlink and in uplink.
Therefore the metric results are helpful to define the overall call model
in the network (e.g. what is the main service used: PS, voice, video…).
These inputs are also very useful complementary information to better

understand the other performance results: accessibility, retainability,
mobility & congestion.

Traffic Monitoring

1.2 Average Number of Calls per Day – RNC metrics
RNC metric URAB012_R_CsVoice
Average
Averagenbnbof
of #1660.[1].Cum
=
Voice
Voicecalls
callsPer
Perday
day #1660.[1].NbEvt
RNC metric URAB012_R_CsVideo

Average
Averagenbnbof
of #1660.[2].Cum
=
Video
Videocalls
callsper
perday
day #1660.[2].NbEvt
RNC metric URAB012_R_Ps

Average
Averagenbnbof
of #1660.[0,4-9].Cum
= x7
Data
Datacalls
callsper
perday
day #1660.[0,4-9].NbEvt

Traffic Monitoring
VS.NumberOfRabEstablished - #1660
Average number of RABs established of the "granted RAB type" in the RNS during a reporting period.
Hence, the counter does not peg when an Always On Downsize occurs. Minimum and maximum number of RABs over
the period are also provided.
RAB granted should be understood as RAB effectively established (iRM can modify the characteristics of a RAB, either
at call admission or during the call for PS : iRM Scheduling downgrade, upgrade, Always ON).
A set of subcounters screened on: DlRbSetId,UlRbSetId,TrafficClass derived screening per granted Rab
0 Other Dl, Ul, Traffic Class combinations
1 Dl and Ul are CS Speech, TC is Conversational
2 Dl and Ul are CSD 64, TC is Conversational
3 Dl and Ul are CS, TC is Streaming
4 Dl is any low rate PS I/B, Ul is any PS I/B, TC is Interative
5 Dl is any low rate PS I/B, Ul is any PS I/B, TC is Background
6 Dl is any high rate PS I/B, Ul is any PS I/B, TC is Interative
7 Dl is any high rate PS I/B, Ul is any PS I/B, TC is Background
8 Dl is any low rate Ps Str and Ul is any PS Str, TC is Streaming
9 Dl is any high rate Ps Str and Ul is any PS Str, TC is Streaming

1.3 Average Number of Calls per Day –DL- Cell metrics
Reference FDDCell metric URB013_CR_DLCsVoice
Average
Averagenbnbof
of DL
DL #1666.[2-3].Cum
= x2
Voice
Voicecalls
callsPer
Perday
day #1666.[2-3].NbEvt
Reference FDDCell metric URB013_CR_DLCsVideo

Average
Averagenbnbof
of DL
DL #1666.[4].Cum
=
Video
Videocalls
callsper
perday
day #1666.[4].NbEvt
Reference FDDCell metric URB013_CR_DLPs

Average
Averagenbnbof
of DL
DL #1666.[0,7-21].Cum
= x 16
Data
Datacalls
callsper
perday
day #1666.[0,7-21].NbEvt

Traffic Monitoring
VS.DlAsConfIdAvgNbrEstablished - #1666
indicates an average of the number of DlAsConfIds established per iRNC, based on time average
A set of subcounters screened on: Derived AsConf Screening for DlAsConfId Avg Nbr Estab:
0 Other
1 Signalling Only
2 CS speech NB or LR AMR
3 CS speech WB AMR
4 CS data
5 CS Streaming 14.4
6 CS Streaming 57.6
7 PS Streaming 16
8 PS Streaming 64
9 PS Streaming 128
10 PS Streaming 256
11 PS Streaming 384
12 PS I/B 0
13 PS I/B 8
14 PS I/B 16
15 PS I/B 32
16 PS I/B 64
17 PS I/B 128
18 PS I/B 256
19 PS I/B 384
20 HSDPA
21 TRB on cell FACH
1.4 Average Number of Calls per Day –UL- Cell metrics
Reference FDDCell metric URB013_CR_ULCsVoice
Average
Averagenbnbof
of UL
UL #1667.[2].Cum
=
Voice
Voicecalls
callsPer
Perday
day #1667.[2].NbEvt
Reference FDDCell metric URB013_CR_ULCsVideo

Average
Averagenbnbof
of UL
UL #1667.[4].Cum
=
Video
Videocalls
callsper
perday
day #1667.[4].NbEvt
Reference FDDCell metric URB013_CR_ULPs

Average
Averagenbnbof
of UL
UL #1667.[0,6-17].Cum
= x 13
Data
Datacalls
callsper
perday
day #1667.[0,6-17].NbEvt

Traffic Monitoring
VS.UlAsConfIdAvgNbrEstablished - #1667
indicates an average of the number of UlAsConfIds established per iRNC, based on time average
A set of subcounters screened on: Derived AsConf Screening for UlAsConfId Avg Nbr Estab ,
• Sub-Counter #0 : Other
• Sub-Counter #1 : Signalling Only • Sub-Counter #2: CS speech • Sub-Counter #3 : CS data
• Sub-Counter #4 : CS Str 57.6 • Sub-Counter #5 : CS Str 14.4 • Sub-Counter #6 : PS Str 16
• Sub-Counter #7 : PS Str 32 • Sub-Counter #8 : PS Str 64 • Sub-Counter #9 : PS Str 128
• Sub-Counter #10 : PS I/B 8 • Sub-Counter #11 : PS I/B 16 • Sub-Counter #12 : PS I/B 32
• Sub-Counter #13 : PS I/B 64 • Sub-Counter #14 : PS I/B 128 • Sub-Counter #15 : PS I/B 384
• Sub-Counter #16 : PS I/B or PS Str HSUPA • Sub-Counter #17 : TRB on cell RACH

1.5 Uplink/ Downlink CS Traffic
RNC metric UTraffic015_R_CsVoice
DL
DLPS
PSTraffic (kbytes) per
Traffic (kbytes) perRNC
RNC==#1544
#1544.[2]
.[2]
RNC metric UTraffic016_R_CsVideo
UL
ULPS
Traffic(kbytes) perRNC
RNC==#1543
#1543.[3]
.[3]
FDDCell metric UTraffic017_C_CsVoice
DL
DLPS
Traffic(kbytes) perCell
Cell==#1554
#1554.[2]
.[2]
FDDCell metric UTraffic018_C_CsVideo
UL
ULPS
Cell==#1553
#1553.[2]
.[2]

Traffic Monitoring
RNC level:
Total count of RLC payload on dedicated channels containing Packet Switched data (in Kbytes):
VS.DedicatedDownlinkKbytesRlc #1544 for DL VS.DedicatedUplinkKbytesRlc #1543 for UL
Cell level:
VS.DedicatedDownlinkKbytesRlcActiveCells #1554 for DL
VS.DedicatedUplinkKbytesRlcActiveCells #1553 for UL
Screenings for #1544 and #1554:

• Sub-Counter #3: CS 64 conversational • Sub-Counter #4: CS streaming • Sub-Counter #5: PS HSDPA
• Sub-Counter #6: PS Str 128 • Sub-Counter #7: PS Str 256 • Sub-Counter #8: PS Str 384
• Sub-Counter #9: PS Str Other • Sub-Counter #10: PS I/B 8kbps • Sub-Counter #11: PS I/B 16kbps
• Sub-Counter #15: PS I/B 256kbps • Sub-Counter #16: PS I/B 384kbps

• Sub-Counter #0: Other Ul • Sub-Counter #1: Any SRB • Sub-Counter #2: CS speech
• Sub-Counter #3: CS 64 conversational • Sub-Counter #4: CS streaming • Sub-Counter #5: PS Str 16
• Sub-Counter #12: PS I/B 128kbps • Sub-Counter #13: PS I/B 384kbps • Sub-Counter #14: PS I/B HSUPA

1.6 Uplink/ Downlink PS Traffic
RNC metric UTraffic015_R_Ps
DL
DLPS
Traffic (kbytes) perRNC
RNC==#1544
#1544.[0,5-16]
.[0,5-16]
RNC metric UTraffic016_R_Ps
UL
ULPS
Traffic(kbytes) perRNC
RNC==#1543
#1543.[0,5-15]
.[0,5-15]
FDDCell metric UTraffic017_C_Ps
DL
DLPS
Cell==#1554
#1554.[0,5-16]
.[0,5-16]
FDDCell metric UTraffic018_C_Ps
UL
ULPS
Cell==#1553
#1553.[0,5-15]
.[0,5-15]

Traffic Monitoring
RNC level:
VS.DedicatedDownlinkKbytesRlc #1544 for DL VS.DedicatedUplinkKbytesRlc #1543 for UL
Cell level:
VS.DedicatedDownlinkKbytesRlcActiveCells #1554 for DL
VS.DedicatedUplinkKbytesRlcActiveCells #1553 for UL

• Sub-Counter #3: CS 64 conversational • Sub-Counter #4: CS streaming • Sub-Counter #5: PS HSDPA
• Sub-Counter #6: PS Str 128 • Sub-Counter #7: PS Str 256 • Sub-Counter #8: PS Str 384
• Sub-Counter #9: PS Str Other • Sub-Counter #10: PS I/B 8kbps • Sub-Counter #11: PS I/B 16kbps
• Sub-Counter #15: PS I/B 256kbps • Sub-Counter #16: PS I/B 384kbps

• Sub-Counter #0: Other Ul • Sub-Counter #1: Any SRB • Sub-Counter #2: CS speech
• Sub-Counter #3: CS 64 conversational • Sub-Counter #4: CS streaming • Sub-Counter #5: PS Str 16
• Sub-Counter #12: PS I/B 128kbps • Sub-Counter #13: PS I/B 384kbps • Sub-Counter #14: PS I/B HSUPA

1.7 Uplink / Downlink PS Traffic per QoS
RNC metric Utraffic053_R_Int_DCH
DL
DLPSPSTraffic (kbytes)ffor
Traffic (kbytes) or
Interactive
InteractiveRAB
RABon on DCH
DCH ==#2225
#2225.[0]
.[0]
RNC metric Utraffic053_R_Bgrd_DCH
DL
DLPS
PSTraffic (kbytes) for
Traffic(kbytes) for
Background
Background RAB on DCH ==#2225
RAB on DCH #2225.[1]
.[1]
RNC metric
UL
ULPSPSTraffic (kbytes) for
Traffic(kbytes) for
Interactive
InteractiveRAB
RABon on DCH
DCH ==#2226
#2226.[0]
.[0]
RNC metric
UL
ULPS
PSTraffic (kbytes) for
Traffic(kbytes) for
Background
BackgroundRABRAB onon DCH
DCH ==#2226
#2226.[1]
.[1]
Traffic Monitoring
VS.DedicatedDownlinkKbytesRlc.QoS - #2225
Downlink volume based on SDU payload in Kbytes sent on dedicated downlink RLCs
QoS per Transport Channel Format in DL
• Sub-Counter #0: QoS class interactive on DCH
• Sub-Counter #1: QoS class background on DCH
• Sub-Counter #2: QoS class interactive on HSDSCH
• Sub-Counter #3: QoS class background on HSDSCH
VS.DedicatedUplinkKbytesRlc.QoS - #2226
Uplink data volume based on SDU payload in Kbytes received on dedicated uplink RLCs
QoS per Transport Channel Format in UL
• Sub-Counter #0: QoS class interactive on DCH
• Sub-Counter #1: QoS class background on DCH
• Sub-Counter #2: QoS class interactive on EDCH
• Sub-Counter #3: QoS class background on EDCH
The above counters are new in UA7.1

new
2 User-Perceived Throughput Counters

Traffic Monitoring

2.1 Goal
new
I downloaded 15 Mega bytes
in the last 15 minutes…
User Throughput
= 15M/900 sec
= 16.7 KBps !

Traffic Monitoring
This feature allows the operator to monitor the Ps data throughput for interactive/background services on
a 24/7 basis as it is experienced by the end-user
This information is useful to compare cell performance or to quantify performance degradation caused by
congestion situations in the network
The performance counters provide guidance for network optimization activities which should lead to a
better quality of service for the end-users

2.2 Principles
Start of first UL transfer Start of second UL transfer
User requests a page RNC triggers

calculation of UL
User requests
another page
and DL throughput
End of first UL transfer End of second UL transfer
UL
Idle period
time
Download of Idle Download of
DL requested page peri the new page
od
Start of first DL transfer End of second DL transfer
Start of second DL transfer

End of first DL transfer

Traffic Monitoring
User Perceived Throughput Counters feature introduces distribution counters for uplink and downlink
throughput for PS data transfers.
The calculation of the user perceived throughput requires that the RNC keeps track of the duration of data
transfers and the amount of acknowledged RLC SDU data transferred (transfer rate is computed by
dividing the data volume by transfer duration).
While a PS connection is active there can be multiple packet data bursts. The idle periods between
separate data transfers are excluded when determining the duration of the transfer to increase the
accuracy of the provided information.

2.3 Characteristics
Separate counters for R99 DCH and HSDPA / R99 DCH and EDCH
Counter pegging at service termination, and at radio link
reconfiguration
Ranges of rate distributions
Reference cell counters
User perceived throughput

RLC header is excluded from throughput calculation
Counters only for the interactive/background traffic class

Traffic Monitoring
The feature introduces separate counters for R99 DCH and HSDPA (downlink) and R99 DCH and EDCH
(uplink)
The support of separate counters for HSPDA and EDCH requires that the throughput calculation and counter
pegging is done not only at service termination, but also when there is a radio configuration change
where the UE gets HSDPA or EDCH resources newly assigned or when the RNC releases HDSPA or EDCH
resources for the UE
Only traffic for the interactive/background QoS class is taken into account for these counters
RLC header is excluded from throughput calculation
The ranges of the distributions are user configurable through parameters (10 bins for R99 counters and 20
bins for HSDPA/EDCH counters)
Counters are pegged against the UE’s reference cell when the reference cell is controlled by the SRNC

2.4 Algorithm for DL Throughput Calculation
t1_DL t2_DL
ACK ACK ACK ACK

PDU PDU PDU PDU
RNC
UE
PDU
PDU PDU
PDU PDU PDU
PDU PDU PDU PDU

Traffic Monitoring
The RNC has the ability to accumulate the amount of acknowledged RLC SDU data (variable Payload_DL)
and the duration of RLC activity (variable Duration_DL) from several data transfers while the UE is in
Cell_DCH state
The duration of a single PS data transfer is defined by t1_DL and t2_DL
t1_DL can be the instant:
When the first RLC PDU is sent to a UE in Cell_DCH state
When another RLC PDU is sent to a UE in Cell_DCH state after the data from a previous data transfer
has been added to Duration_DL and Payload_DL
t2_DL can be the instant:
When the last remaining PDU has been acknowledged and there are no further RLC PDUs to be sent to
the UE
When the RNC decides to peg the user perceived throughput counters while there is a still ongoing DL
data transfer

2.4 Algorithm for DL Throughput Calculation [cont.]
t1_DL t2_DL
ACK ACK ACK ACK

PDU PDU PDU PDU
RNC
UE
PDU
PDU PDU
PDU PDU PDU
PDU PDU PDU PDU
If t2_DL – t1_DL ≥ minDuration:

Payload_DL(new) = Payload_DL(old) + 4 * PDU Size
Duration_DL(new) = Duration_DL(old) + t2_DL – t1_DL
If t2_DL – t1_DL < minDuration:
Payload_DL(new) = Payload_DL(old)
Duration_DL(new) = Duration_DL(old)

Traffic Monitoring
At t2_DL, the RNC checks whether duration of the transfer (t2_DL – t1_DL) was longer than the minimum
duration of a data transfer to be taken into account for the user perceived throughput calculation,
defined by parameter minDuration
If larger, the RNC adds this amount of acknowledged RLC SDU data to the variable Payload_DL and the
time difference to the variable Duration_DL
If shorter the information related to this data transfer is not taken into account
This check ensures that the inability to exactly measure the transfer time affects the accuracy of the
metric
When another RLC PDU is sent to the UE after t2_DL the RNC re-initializes t1_DL and handles the new data
transfer separately
Triggers to calculate the user perceived throughput using the expression Payload_DL/Duration_DL and peg
counters VS.UserTP.R99DL and VS.UserTP.HSDPA are:
RLC layer for the UE is torn down (RLC drop or release)
UE with an I/B RAB leaves Cell_DCH state
RNC reconfigures an I/B RAB from HSDPA to R99 or vice-versa
RNC starts an intra-RNC inter-frequency handover or an inter-RAT handover for an UE which has an I/B
RAB

2.5 New Counters for R99 Throughput
#2500 VS.UserTP.R99DL :
Distribution of the user perceived throughput for interactive / background
traffic in a UMTS cell when using R99 DL traffic channels in CELL_DCH
The data rate threshold of the screenings can be defined by the RNC parameter
PmUserTpConfig.dlR99Thd
#2501 VS.UserTP.R99UL :
Distribution of the user perceived throughput for interactive / background
traffic in a UMTS cell when using R99 UL traffic channels in CELL_DCH
PmUserTpConfig.dlR99Thd

Traffic Monitoring
COUNTER ID 2500
Name NT_User_tp_r99_dl_rlc_refcell
3GPP Name VS.UserTP.R99DL
Location Cell (Reference)
Unit event
Range 31 Bits
Type CUM
Scanner Type GPO
Family User Perceived Throughput
Distribution of the user perceived throughput for interactive/background traffic in a
Meaning,
UMTS cell when using R99 DL traffic channels in CELL_DCH. The data rate threshold of
Description
the screenings can be defined by the CM attribute PmUserTpConfig.dlR99Thd.
Pegged against the reference cell. For the calculation the RNC accumulates the RLC
payload data which has been acknowledged by the UE while the UE has been in
CELL_DCH state using a R99 DL DCH and the duration of the data transfer. This
counter is pegged when: 1) a UE with an I/B RAB mapped to R99 DCH in DL is leaving
Triggering Event CELL_DCH state 2) the UE with a I/B RAB mapped to R99 DL DCH is reconfigured to
another frequency layer 3) there is a reconfiguration of the DL transport channel from
R99 DCH to HSDPA. 4) The RNC triggers: - an intra-RNC inter-frequency handover - an
inter-RAT handover or - a cell change order procedure for a UE which has an I/B RAB
mapped to R99 DCH in DL.
Screening Criteria Data range R99 DL

2.5 New Counters for R99 Throughput [cont.]
COUNTER ID 2501
Name NT_User_tp_r99_ul_rlc_refcell
3GPP#2500
Name VS.UserTP.R99DL
VS.UserTP.R99UL :
Distribution
Location ofCell
the(Reference)
user perceived throughput for interactive / background
Unit traffic in a UMTS
eventcell when using R99 DL traffic channels in CELL_DCH
Range 31 Bits
Type PmUserTpConfig.dlR99Thd
CUM
Scanner Type GPO
Family User Perceived Throughput
#2501 VS.UserTP.R99UL :
Distribution ofDistribution
Meaning, the user of the user perceived throughput for interactive/background traffic in a
perceived throughput for interactive / background
UMTS cell when using R99 UL traffic channels in CELL_DCH. The data rate threshold
Description
traffic in a UMTS cell when using R99 UL by
traffic
of the screenings can be defined the CMchannels in CELL_DCH
attribute PmUserTpConfig.ulR99Thd.
The data rate Pegged

threshold ofthe
against thereference
screenings
cell. can becalculation
For the defined by thethe
RNC RNC parameter
accumulates the RLC
payload
PmUserTpConfig.dlR99Thddata which has been acknowledged by the UE while the UE has been in
CELL_DCH state using a R99 UL DCH and the duration of the data transfer. This
counter is pegged when: 1) a UE with an I/B RAB mapped to R99 DCH in UL is leaving
Triggering Event CELL_DCH state 2) the UE with a I/B RAB mapped to R99 UL DCH is reconfigured to
another frequency layer 3) there is a reconfiguration of the UL transport channel
9 1 22 from R99 DCH to EDCH. 4) The RNC triggers: - an intra-RNC inter-frequency handover
Traffic Monitoring
9300 WCDMA TMO18268 9300 WCDMA - an inter-RAT handover or - a cell change order procedure for a UE which has an I/B
UAO7 R99 QoS Analysis and Traffic Load Monitoring
RAB mapped to R99 DCH in UL.

Screening Criteria Data Rate Range R99 UL

2.6 Screenings Ps R99
VS.UserTP.R99DL VS.UserTP.R99UL
#2500 #2501
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9]
Thd0 Thd1 Thd2 Thd3 Thd4 Thd5 Thd6 Thd7 Thd8
Example:
{Thd0= 96kbps, 128, 160, 192, 224, 256, 288, 320, Thd8= 352kbps}

Traffic Monitoring
Screening Data Rate Range DL R99 Data Rate Range UL R99
0 rate <= dlR99Thd[0] rate <= dlR99Thd[0]
1 dlR99Thd[0] < rate ≤ dlR99Thd[1] ulR99Thd[0] < rate ≤ ulR99Thd[1]
9 dlR99Thd[8] < rate ulR99Thd[8] < rate


for this module

Traffic Monitoring

End of Module

Traffic Monitoring

Last But One Page
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME
All Rights Reserved © Alcatel-Lucent @@YEAR

@@COURSENAME - Page 1
Passing on and copying of this document, use and communication of its
contents not permitted without written authorization from Alcatel-Lucent
All Rights Reserved © Alcatel-Lucent @@YEAR
@@COURSENAME - Page 2

TMO18268 UA7 R99 QoS Analysis and Traffic Load Monitoring

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TMO18268 UA7 R99 QoS Analysis and Traffic Load Monitoring

Uploaded by

Copyright:

Available Formats

9300 WCDMA

TMO18268 9300 WCDMA UAO7 R99 QoS

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

Switch to notes view!

2 All Rights Reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

All rights reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

Switch to notes view!

4 All Rights Reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

TMO18268 9300 WCDMA

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

Switch to notes view!

Upon completion of this course, you should be able to:

7 All Rights Reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

9 All Rights Reserved © Alcatel-Lucent 2010

Where you can get further information

If you want further information you can refer to the following:

TMO18268 9300 WCDMA

Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2010

TMO18268 9300 WCDMA

Did you meet the following objectives ?

Yes (or No (or

TMO18268 9300 WCDMA

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

TMO18268 9300 WCDMA

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

112 All Rights Reserved © Alcatel-Lucent 2010

Edition Date Author Remarks

01 2010-04-27 Nolan, Vincent First edition for UA07

All Rights Reserved © Alcatel-Lucent 2010

Upon completion of this module, you should be able to :

113 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

114 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

115 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

116 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

117 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

End user expectations concerning services usage over UMTS

118 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

But technology constraints…

• Various data rates Scarce

Load optimisation over

119 All Rights Reserved © Alcatel-Lucent 2010

112 All Rights Reserved © Alcatel-Lucent 2010

113 All Rights Reserved © Alcatel-Lucent 2010

114 All Rights Reserved © Alcatel-Lucent 2010

115 All Rights Reserved © Alcatel-Lucent 2010

116 All Rights Reserved © Alcatel-Lucent 2010

117 All Rights Reserved © Alcatel-Lucent 2010

118 All Rights Reserved © Alcatel-Lucent 2010

119 All Rights Reserved © Alcatel-Lucent 2010

1 1 10 All Rights Reserved © Alcatel-Lucent 2010

1 1 12 All Rights Reserved © Alcatel-Lucent 2010

1 1 13 All Rights Reserved © Alcatel-Lucent 2010

1 1 14 All Rights Reserved © Alcatel-Lucent 2010

1 1 15 All Rights Reserved © Alcatel-Lucent 2010

1 1 16 All Rights Reserved © Alcatel-Lucent 2010

212 All Rights Reserved © Alcatel-Lucent 2010

213 All Rights Reserved © Alcatel-Lucent 2010

214 All Rights Reserved © Alcatel-Lucent 2010

216 All Rights Reserved © Alcatel-Lucent 2010

217 All Rights Reserved © Alcatel-Lucent 2010

218 All Rights Reserved © Alcatel-Lucent 2010

219 All Rights Reserved © Alcatel-Lucent 2010

2 1 10 All Rights Reserved © Alcatel-Lucent 2010

2 1 11 All Rights Reserved © Alcatel-Lucent 2010