W-CDMA UA07 R99 Qos Analysis and Traffic Load Monitoing - EC - 1 - TMO18268 - FrontMatte

9300 WCDMA
UA07 R99 QoS Analysis and

Traffic Load Monitoring
TMO18268-D0-SG-DENI1.0
Issue 1.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

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

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

Terms of Use and Legal Notices
1. Safety to
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 written consent of
Alcatel-Lucent.
All
3 rights reserved © Alcatel-Lucent 2010 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.

Blank Page

9300 WCDMA

Course Outline
1. Radio
About ThisNetwork
CoursePerformance Overview 4. Topic/Section is Positioned Here
Course 1. Module 1
outline
Technical support
2. Monitor the Radio Network Performance
Course 1.
objectives
5. Topic/Section is Positioned Here
Module 1
3. Monitoring and Troubleshooting methods
1. Topic/Section is Positioned Here 6. Topic/Section is Positioned Here
Xxx 1. Module 1
4.Xxx
Network Accessibility Monitoring 7. Topic/Section is Positioned Here
Xxx 1. Module 1
5. Retainibility Monitoring
2. Topic/Section is 1Positioned Here
1. Module
6. Mobility Monitoring
3. Topic/Section is 1Positioned Here
1. Module
7. Network Quality Monitoring
1. Module 1
8. Capacity Monitoring
1. Module 1
9. Traffic Monitoring
1. Module 1

9300 WCDMA

Course Outline [cont.]

9300 WCDMA

Course Objectives
Welcome to UA07 R99 QoS Analysis and Traffic Load Monitoring
Upon completion of this course, you should be able to:
 identify why, when, and how to make performance management

 define counters, metrics, and explain how to use metrics, describe the metrics families
 illustrate the call flows associated with each metric family, identify the counters and locate
them in the call flow procedure
 monitor Capacity and traffic load with KPI.

9300 WCDMA

Course Objectives [cont.]

9300 WCDMA

About this Student Guide

Conventions used
Switch 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.
9 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

About this Student Guide [cont.]
 Switch to notes view!

9300 WCDMA

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

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



Do not delete this graphic elements in here:
Section 1
1
Radio Network Performance
Overview
Module 1
3JK10055AAAAWBZZA Edition 1
9300 WCDMA
TMO18268 D0 SG DENI1.0
Edition 1.0

Section 1 · Pager 1
Blank Page
1·2 All Rights Reserved © Alcatel-Lucent 2010

Radio Network Performance Overview
9300 WCDMA · UA07 R99 QoS Analysis and Traffic Load Monitoring
Document History
Edition Date Author Remarks
01 2008-12-01 El Abed, Achrafe First edition

Module Objectives
Upon completion of this module, you should be able to:
 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.]

Radio Network Performance Overview This page is left blank intentionally

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.]
1·6 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 · 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
Module 1


Section 2
2
Monitor the Radio Network
Performance
Module 1
3JK10056AAAAWBZZA Edition 2.0
9300 WCDMA
Edition 1.0

Blank Page

Monitor the Radio Network Performance
Document History
01.1 2009-03-18 Charneau, Jean-Noel Correction of the name of the counter #303
VS.UplinkRssi
02 2010-04-27 Nolan, Vincent UA07

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.



Monitor the Radio Network Performance This page is left blank intentionally

Table of Contents
Page
1 QoS counters definition 7
Introduction 8
Counters: Definition 9
Collect performance data with ALU solution (1/2) 10
Collect performance data with ALU solution (2/2) 11
Counter file storage 12
NPO introduction to UTRAN monitoring 13
2 Counters properties and Analysis 14
Counter groups and families (1/2) 15
Counter groups and families (2/2) 16
Counter types (1/6) 17
Load (or SI) Counter: example 23
RNC C-Node counter families 24
RNC and FDDCell object instances for C-Node counters 25
Reference FDDCell object instance for C-Node counters 26
Neighbouring RNC object instance for C-Node counters 27
Principles – Reference Cell Counters 28
Principles – Neighbouring RNC counters 29
Principle 30
2·5 Principles – DRNC Cells counters All Rights Reserved © Alcatel-Lucent 2010 31
Counter/Indicator
Monitor the Radio Network Performance Aggregation by NPO (1/3)
32
Counter/Indicator Aggregation by NPO (2/3) 33
Counter/Indicator Aggregation by NPO (3/3) 34
BTS counter families and object instances 35
MSS counter families and object instances 36
Counter Screenings 37
3 Metrics properties and Analysis 38
Metrics Definitions 39
Metrics Generic Formulas 40
4 Generating Reports and Analysis 41
4.1 RNC Counter Volume Control 42
Indicator Aggregation 43
4.2 Report Definition 44
Generate a report on NPO 45
Key Performance Indicators 46
Network Key Performance Indicators 47
Counter based KPIs 48
Methodological precautions 49
KPI value 50
Network Element aggregation 51
With other indicators 52
With alarms 53
With parameters modification 54
5 Real Time Counters 55
Overview 56
Overview 57
Real time Performance Monitoring Application 58
Real Time Metrics 59
6 Alcatel-Lucent Call Trace Solution Overview 60
Introduction 61

Page
Call Trace Session Types (1/4) 62
Configuring a Call Trace Session 66
Real time Call Trace Overview 67
Real time Call Trace Preparation 68
Real time Call Trace Monitoring 69
7 Alcatel-Lucent Performance Monitoring Tools 70
7.1 OAM Performance Management Portfolio 71
7.2 OAM Performance Management Portfolio Strategy 72
7.3 Post Processing Call Trace Data with RFO 73
7.4 Post Processing Call Trace Data with WQA 74
End of Module 76


1 QoS counters definition


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

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

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.

Collect performance data with ALU solution (2/2)
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.

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

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


Counter groups and families (1/2)
 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


Counter groups and families (2/2)
The counter groups are further divided into families according to a

given UMTS feature or to a Performance Management purpose
RNC C-Node counter families BTS counter families
• Radio Link Management • PCM statistics
• Handover • Radio counters
• Power Management • CallP counters
• RRC Connection • ATM statistics
• IU Connection • EEC
• RAB and RB Management • IMA statistics
• Security • IP statistics
• Paging • HSDPA statistics
• Mobility • HSUPA statistics
• Radio Measurement • Radio statistics
• QOS Performance
• User Plane Common Traffic
• IUR Interface RNC PASSPORT Platform counter
• User Plane Dedicated Traffic families
• ATM port
• Logical Processor Use
• Adjunct Processor Stats
• Account ATM Vcc
• Account ATM Vpc
• IP Stats


Counter types (1/6)
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


Counter types (2/6)
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


Counter types (3/6)
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


Counter types (4/6)
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


Counter types (5/6)
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


Counter types (6/6)
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

Load (or SI) Counter: example
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


RNC C-Node counter families
There are 19 RNC counter families
Radio Link Management Mobility

Handover Radio Measurement
Soft Handover QOS Performance
Power Management User Plane Common Traffic
RRC Connection IUR Interface
IU Connection User Plane Dedicated Traffic
RAB and RB Management Statistic Counter
Security CDMA Handover
Paging Platform
Synthetic


RNC and FDDCell object instances for C-Node counters
MSC
RNC counter
• A “RNC” counter is incremented when
an event occurs on the serving RNC of a Iu-CS Iu-CS
connection.
Ex: VS.IuSccpCnxSuccess.CsReqByRNC providing the
Serving Drift
number of successful SCCP connections requested RNC Iur RNC
by the RNC on the Iu CS interface
FddCell counter
• A “FddCell” counter is incremented for
each FddCell of the serving RNC on
which the mobile is connected to, when
the event occurs.
Ex:
VS.RadioLinkSetupUnsuccess.RadioLinkSetupFailur
e 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

Reference FDDCell object instance for C-Node counters
Reference FddCell counter

• A “ Reference FddCell” counter is
incremented only for the FddCell
identified as the Primary FddCell of Serving
Iur
Drift
RNC RNC
the connection when the event occurs.
• Such a counter is only incremented if
the reference FddCell belongs to the
serving RNC on the connection.
Otherwise “Neighbouring RNC” object
is used.
Ex: VS.RadioBearerSetupSuccess.TgtCallCsSpeech
providing the number of successful RRC Radio
Bearer Setup when the target DL Radio Bearer is
Speech for a UE for which this cell is acting as the
Primary


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

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.RadioBearerSetupSuccessNeighbRnc.CS Speech
providing the number of RRC Radio Bearer
successfully setup when the target DL Radio Bearer is
Speech for a UE having its Primary cell under this
Drift RNC, Neighbor RNC of the Serving RNC.


Principles – Reference Cell Counters
Serving RNC Drift RNC
Iur

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, #2618 is a refernce cell counter. When the event occurred, only the counter #2618 of
the left cell in the serving RNC was incremented.

Principles – Neighbouring RNC counters
Iur
Iur

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, #2618 is a reference cell counter, #2606 is a Neighbouring RNC counter. When the
event occurred, because the primary cell in under the Drift RNC, only the counter #2618 under the serving
RNC was incremented.
The same counter #2618 will be incremented regardless the cell of the DRNC.

Principle
Serving RNC RNSAP / RADIO LINK SETUP REQUEST Drift RNC
RNSAP / RADIO LINK SETUP FAILURE

RNSAP / RADIO LINK SETUP RESPONSE
Iur

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.

Principles – DRNC Cells counters
RemoteCell B1
Iur

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

Counter/Indicator Aggregation by NPO (1/3)
The new aggregation path is equal to:

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

1 Iur 2 Iur 3
Cell Cell Cell Cell Cell Cell

11 12 21 22 31 32

Monitor
32 | Presentation
the Radio Network
Title | Month
Performance
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]


[ 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

Monitor
33 | Presentation
the Radio Network
Title | Month
Performance
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]


[ 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

Monitor
34 | Presentation
the Radio Network
Title | Month
Performance
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]

BTS counter families and object instances
There are 10 BTS counter families
PCM statistics
ATM statistics
Radio counters
Radio statistics
CallP counters
EEC
IMA statistics
IP statistics
HSDPA statistics
HSUPA statistics


MSS counter families and object instances
There are 5 MSS counter families
ATM port
Logical Processor Use
Adjunct Processor Stats
ACCOUNT ATM Vcc
ACCOUNT ATM Vpc


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


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)

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
Class
RRC.AttConnEstab Cell Y
(…) (…) (…)
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.1 RNC Counter Volume Control
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.2 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.

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


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%
17
21
37
45
1
5
9
13
25
29
33
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.

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
call drop rate of the cell covering a specific building
% of users in Soft HO for the network
average rate of paging discarded for all the RNCs

% of Cell_DCH to cell_FACH transition in hot spot zone
call success of 1 PLMN
% of cells being congested today


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

Methodological precautions
METHODOLOGICAL PRECAUTIONS
 Avoid typical errors regarding indicators interpretation


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


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


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-
27-05-
28-05-
29-05-
30-05-
31-05-
01-06-
02-06-
03-06-
04-06-
05-06-
06-06-
07-06-
26-05-
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%
25-05-
26-05-
27-05-
07-06-
28-05-
29-05-
30-05-
31-05-
01-06-
02-06-
03-06-
04-06-
05-06-
06-06-
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005
2005

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


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
5
05
05
5
5
5
00
00
00
00
00
00
00
0
0
/2
/2
/2
/2
/2
/2
/2
/2
8/
4
2
0
6
4
/0
/0
/0
/3
/0
/1
/1
/1
/1
07
06
07
07
07
07
07
07
07
AMR calls % CSSR


5 Real Time Counters


Overview
Real Time Counters:

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

Monitor
56 | Presentation
the Radio Network
Title | Month
Performance
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.

Overview
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)

Monitor
57 | Presentation
the Radio Network
Title | Month
Performance
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.

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

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

Monitor
59 | Presentation
the Radio Network
Title | Month
Performance
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
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,…)


Call Trace Session Types (1/4)
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

 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).

 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).

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


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.

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 …

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.

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
Functions – Per Call exchanged

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, 0%
(Cell 1 -Cell 2)
100, 00%
90, 00%
Provisioning
80, 00%
ive distribu tion

2, 50% 70, 00%
percen tag etotal

interferenc e
2, 0% 60, 00%
50, 00%
Per Neighbouring Relation & Per HO

1, 50% 40, 00%
c umulat
System
1, 0% 30, 00%
20, 00%
0, 50%
10, 00%
0, 0% 0,00%
-3 5 -2 5 -1 5 -5 5 15 25 35 45 5
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
Module 1


Section 3
3
Monitoring and Troubleshooting
methods
Module 1
9300 WCDMA
Edition 1.0
All Rights Reserved © Alcatel-Lucent @@YEAR

Blank Page
3·2 All Rights Reserved © Alcatel-Lucent @@YEAR

Monitoring and Troubleshooting methods
Document History
02 2009-04-10 Charneau, Jean-Noel Removal of RNC Panel and Cell Panel

Module Objectives
 Explain what is the QoS monitoring and troubleshooting process

 Identify the performance reports



Monitoring and Troubleshooting methods This page is left blank intentionally

Table of Contents
Page
1 Monitoring and troubleshooting process 7
Monitoring & Troubleshooting Methods 8
Criteria Definition 9
Observation 10
Analysis 11
Correction 12
Validation 13
2 Define Performance Reports 14
High level reports 15
Troubleshooting reports 16
RNC panel 17
Cell panel 18
Recommendations 19
End of Module 21




1 Monitoring and troubleshooting
process


1 Monitoring and troubleshooting process
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.

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.


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
3 · 10 All Rights Reserved © Alcatel-Lucent @@YEAR

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.

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

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.

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


High level reports
Observation
Report Type Granularities Comment
Period
The objective of this report is to give an overview of the
Executive panel Weekly Evolution One Month Network/per week
network’s performances over several weeks
The objective of this report is to get an overview of the

Executive panel Daily Evolution One Week Network / per day
network’s behaviour during the last week
The objective of this report is to give an overview of the RNC’s

RNC panel Weekly Evolution One Month per RNC / per week
performances over several weeks
The objective of this report is to have a global view (RNC level).

RNC panel Daily Evolution One Week per RNC / per day It will lead to more detailed investigation in case of issues in
some of its metrics
Valid to monitor a cluster of fddcell or Node Bs performance, to

support the monitoring when activating new features in a
limited area or cluster of cells
Warning: In case of Multi-Layer, some metric can only make
Cell panel Daily evolution One Week per FddCell/ one day
sense at Node B level.
It's necessary to have statistic meaningful attempts or traffic to
assess the performance per cell otherwise degradations of the
metrics can be linked to the lack of traffic
These reports are used in “from Top to Bottom approach”

This report, named RNC Panel gives a global view of the network. It highlights roughly the main results in
terms of accesibility, mobility achievement, traffic indicators, etc
The metrics are associated to the main phases of a call:

RRC connections set-up
IU SCCP connections set-up
Radio Access Bearers establishment
Call Drops
Mobility efficiency
Congestion detection
Quality
Traffic
This report has to be used at RNC level.
It reflects the quality of actual network, and it will Lead to deeper investigations with additional metrics: the
troubleshooting investigations.

Troubleshooting reports
Observation
Report Type Granularities Criteria (Top N/other) Comment
Period
The objective of this report is to have a global view (RNC level)

of RRC connections over a one-week period. The results of this
RRC Daily evolution one week per RNC/ Day
report could be compared with the results processed at FddCell
level (report below).
Use the daily evolution of

the executive report and
select the date for which The objective of this report is to identify the FddCells that
RRC Top N one day per FddCell/ one day
the “RRC Connection would have potential RRC connections establishment issues.
Establishment Failure rate”
is the worst.
Use the N FddCells that The objective of this report is to verify that the potential RRC
RRC Daily evolution one week per FddCell / day were filtered by the connections establishment issues identified by the TOP N report
previous TOP N report. were real (and need deeper investigations) or not.
The objective of this report is to focus on SCCP connections and
Iu SCCP Daily evolution one week per RNC/ Day
identify potential issues.
Use the date for which the

“Iu CS SCCP Failure rate” or The objective of this report is to check whether the bad SCCP
Iu SCCP Hourly evolution one day per RNC/ hour “Iu CS SCCP Failure rate” is connection statistics are related to specific periods of time or
the worst in the previous not in order to correlate later with alarms or even tracking
report.
The RAB Assignment Analysis aims at determining at RNC level:

RAB Management Daily evolution one week per RNC/ Day the service degradation and the reasons (congestion reasons or
other)
This report helps to know it the traffic radio bearer is ok

Radio Bearer Daily evolution one week per RNC/ Day attempted each time the RNC tries to allocate traffic resources
to a UE to perform a voice and/or data call, etc.
fddcells “Radio Bearer This report helps to identify the fddcell to monitor with the
Radio Bearer Top N one week per RNC/ Day
Success rate” is worst following report
This report help to know it the traffic radio bearer is ok

attempted each time the RNC tries to allocate traffic resources
Radio Bearer Daily evolution one week per FddCell / day
to a UE to perform a voice and/or data call, etc for an specific
fddcee
fddcell
Radio Bearer Blocking Top N one week per FddCell Top Blocking rate fddcells Track of most Blocked cells
These reports are used for specific investigations


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
Module 1


4
Section 4
Network Accessibility Monitoring
Module 1
9300 WCDMA
Edition 1.0

Blank Page

Document History
01.1 2009-03-18 Chatila, Rayan Corrections of counters and indicators numbers,

Charneau, Jean-Noel names and formulae
Change of the UL RSSI indicator formula, going
back to the UA4.2 one using counter #303
02 2009-04-10 Charneau, Jean-Noel Add screening 15 of #404 in RRC Connection

preparation failure list

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



Network Accessibility Monitoring This page is left blank intentionally

Table of Contents
Page
1 Accessibility analysis 7
Reminder Call Establishment (Cell-DCH case) Flow 8
Accessibility issues causes 9
2 RRC Connection Phase 10
RRC Connection 11
RRC Connection Success: call flow 12
RRC Connection Success: counters 13
RRC connection attempt during cell reselection 14
RRC Connection Preparation Failure 15
RRC Connection Execution Failure 16
RRC Connection : Counter Tree 17
RRC Connection Success Rate 18
3 RRC Troubleshooting 19
RRC Accessibility analysis 20
Example: RRC Failure Cause Analysis 21
RRC Connection / RF Conditions Analysis / DL Quality 23
RRC Connection / RF Conditions Analysis / DL Level 24
RRC Connection / RF Conditions Analysis / UL Radio Load 25
RRC Connection / RF Conditions Analysis / UL Cell Load 26
RRC Connection / RRM Capacity Analysis 27
Case Analysis 28
Case Analysis: Burst of RRC failures in an area of few cells 29
4 · 5 RRC Burst of failures (summary) All Rights Reserved © Alcatel-Lucent 2010 32
4 Accessibility
Network Radio Monitoring
Link Management
33
Reminder 34
4.1 VS.RadioLinkSetupUnsuccess 35
4.2 Radio Link Reconfiguration Prepare 36
5 RAB Establishment and Troubleshooting Analysis 39
RAB Assignment Flow: Exercise 40
RAB Assignment Success: counters (1/3) 41
VS.RadioBearerEstablishmentUnsuccess: 44
RAB Assignment Preparation Failure 45
RAB Assignment Execution Failure 46
RAB Assignment: RNC Counter Tree 47
RB Establishment: Cell Counter Tree 48
RAB Assignment Success Rate (RNC level) 49
RB To Be Setup Success Rate (Cell level) 50
RAB Analysis: Failure analysis 51
6 IuSCCP Troubleshooting Analysis 52
Exercise: Success Rates Initiated by the RNC 53
Exercise (cont’d): Success Rates Initiated by the RNC 54
SCCP Connection: Success Flow 55
SCCP Connection: Failure Flow 56
SCCP Connection : Counter Tree 57
Iu SCCP Analysis (success rates initiated by the RNC) 58
Iu SCCP analysis method 59
Case Study 60
Example (1/2): IuSCCP analysis 61
Example (2/2): IuSCCP analysis 62
7 Security Mode Troubleshooting Analysis 63
Security Mode Success: Flow 64

Page
Security Mode Failure: RNC 65
Security Mode Failure: UE 66
Security Mode Command Success Ratio 67
Ciphering analysis 68
8 Call Setup Success Rate Troubleshooting Analysis 69
Exercise 70
Exercise 71
Call Set Up Success Rate 72
Accessibility Troubleshooting Chart 73
Case Study 74
Case Study : Accessibility Monitoring & Troubleshooting 75
9 Pre-emption 76
9.1 Principles 77
9.2 Counters 78
9.3 Set of Indicators 80
10 RRC Connection Re-establishment 81
10.1 Example of re-establishment UL Flow in Cell_DCH 82
10.2 Counters 83
10.3 Indicators 84
End of Module 86


1 Accessibility analysis


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

Radio Link Setup Request
Radio Link Setup Response RRC Connection Phase
RRC Connection Setup
RRC Connection Complete
Measurement Control
Init Direct Transfer
SCCP Connection Request (Initial UE Message)

SCCP Connection Confirm SCCP Connection Phase
Authentication Procedure
Ciphering Procedure
RAB Assignment Request
S.R.L.R. Procedure
Radio Bearer Setup RAB establishment Phase
Radio Bearer Setup Complete
RAB Assignment Response


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


RRC Connection
Logical connection between UE and UTRAN.

Itcarries 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
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.

RRC Connection Success: call flow
RRC Connection Phase

UE Node B RNC
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).

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

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

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

RRC 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.Sum (#428) is just incremented once – excludes

all UE repetitions for the same call attempt
 Counter is 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)
Counter Location: FddCell
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

RRC Connection Preparation Failure
FDDCell counter
UE Node B RNC
RRC Connection Request CAC failure

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

[all screenings except 0
and 14]
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 : 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, pegged when the number of RRC contexts is exhausted
• Sub-Counter #10 : Unavailable FACH context resource, pegged 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 #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
Notes:
Screening #5 corresponds to an RNC internal problem
Screening #9 corresponds to a CAC failure due to RRC context resource shortage in the RNC
Screening #10 corresponds to the CAC failure on FACH when the maximum number of users on FACH has been reached.

RRC Connection Execution Failure
FDDCell counter
UE Node B RNC

CAC success
#404 RRC Connection Failure T352 expiry

[screening 0 and 14]
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 #14 : 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)

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

#404[all screenings except 0 & 14] #416
RRC.FailConnEstab
Execution failure Success

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


RRC Connection Success Rate
FDDCell metrics
URRC003_CR_Calls System view
#403.[0,1,2,3,4,5,6,7,8,9,14,16,17,19]
RRC connection success rate =
(calls only) #409.[0,1,2,3,4,5,6,7,8,9,14,16,17,19]
URRC013_CR_Calls User View
#403.[0,1,2,3,4,5,6,7,8,9,14,16,17,19]
RRC connection success rate =
(calls only) #419.[0,1,2,3,4,5,6,7,8,9,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)
The first phase of a call establishment (speech or data) is the RRC connection. One RRC connection can lead to
 Several Iu SCCP connections ( multi service CS+PS, simultaneous CS + PS attach/detach, CS location update
during a PS call),
 No RAB in case of signaling connections,
 1 (or several RAB) in case of one call (multi service).
We can also have:
CS RRC Connection success rate= (∑#403.[0,5,9]) / (∑#409.[0,5,9])
PS RRC Connection success rate= (∑#403[1,2,3,4,6,7,8,14,16,17,19]) / (∑#409[1,2,3,4,6,7, 8,14,16,17,19])

3 RRC Troubleshooting


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

Example: 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 est ablish ment
RRC failure cases First Radio L ink Cell Inactiv ity
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)

Example: 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 est ablish ment
RRC failure cases First Radio L ink Cell Inactiv ity
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
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
RRC Connection / RF Conditions Analysis / DL Quality
FDDCell counter
CPICH Ec/N0
#1001.[0,1]
∑ #1001.[0,1,2,3] 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

RRC Connection / RF Conditions Analysis / DL Level
Reference FDDCell counter
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
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

RRC 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)
Too
Toohigh
highUL
ULRSSI
RSSIifif>>-98
-98dBm
RRC connection
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.

RRC 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 (%)

RRC 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 SF128
SF128Code
Codeusage
usage==
se
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

Case Analysis
 Analyse the charts given in next slides !

 What could you say about RRC performances ?


Case Analysis: Burst of RRC failures in an area of few
cells
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.


cells
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


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, 06:00
5/10/04, 08:00
5/10/04, 21:00
5/10/04, 23: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, 07: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, 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


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.FailConnEstab - #404
 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


Reminder
UE Node B RNC #38 VS.RadioLinkSetupUnsuccess

#39 VS.RadioLinkAdditionUnsuccess
#40 VS.RadioLinkReconfigurationPrepareUnsuccess
RRC Connection Request #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.1 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 InodeRefusal
8 NodeBOutOfOrder
Screenings correspond to failure causes

S8 is not implemented

4.2 Radio Link Reconfiguration Prepare
For which user services ?


4.2 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.2 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
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.

#?


RAB Assignment Success: counters (1/3)
UE Node B RNC CN
#1656 Rab Establish. Requests Per RabType

RAB assignment req.
RNC counter
#1652 RB to be setup
S.R.L.R. Procedure
establsht
RAB
Radio Bearer Setup CAC success

#1657 RAB assignment success #1650 RB setup success

per Requested RAB type
#1658 RAB assignment success
per Granted RAB type RAB assignment resp.
RNC counters

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

VS.RabEstablishmentSuccessPerRequestedRabType #1657: Number of successful RAB establishment per

 Switch to note view
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.
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 · 42 #5: Dl is any low rate PS I/B, AllUlRights
isReserved
any PS I/B, TC
© Alcatel-Lucent 2010 is Background


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 #15: HSDPA/R99
• Sub-Counter #16: 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.

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


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

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


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


RB Establishment: Cell Counter Tree
Reference FDDCell counters
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]


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]


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 ==
#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]

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
ons
During BH > Th a nd KP
IAL a g gregati
PAT
su e in TIME, S
he is 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)?
 After certain event (upgrade, feature activation, configuration changes)
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


Exercise: Success Rates Initiated by the RNC
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 “IU Connection” RNC counter family)
UE Node B RNC CN
(…)
SCCP connection req.

SCCP
conn.
SCCP connection confirm


Exercise (cont’d): Success Rates Initiated by the RNC
With the counters you identify at the previous step, define the following metrics:
Iu
IuSCCP
SCCPsuccess
success rate
rate==
CS
CS Iu
IuSCCP
SCCPsuccess
success rate
rate==
PS
PS Iu
IuSCCP
SCCPsuccess
success rate
rate==
SCCP conn.


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)

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

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.


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.


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
15/09/2006
08/09/06
07/09/06
06/09/06
13/09/2006
PS Call Setup Success Rate

05/09/06
04/09/06
11/09/2006 03/09/06
02/09/06
09/09/2006 01/09/06
31/08/06
Case Study
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
01/09/2006 24/08/06
23/08/06
22/08/06
100.00%
98.00%
96.00%
94.00%
92.00%
90.00%
21/08/06
4 · 60
99.00%
98.00%
97.00%
96.00%
95.00%
100.00%


Example (1/2): IuSCCP analysis
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
 Issue characterization:
 Iu CS or Iu PS issue?  PS
 Affecting all RNC/only specific RNC ?
 Punctual degradation that disappear?Or degradation remains? Punctual 28/09/05


Example (2/2): IuSCCP analysis
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 RNCAll 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
Security Mode Success: Flow
UE Node B RNC CN
RRC connection

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

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:

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

1st Security mode reject
ca se #703[0,1] Cause =
failed Security Mode procedures same as in previous page

2nd No answer from UE

Security mode reject
ca se
#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:

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
Cmd successratio
success ratio #701.[1] + #702.[1] + #703.[1]
Security mode


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
Exercise
 Using the formerly defined metrics define the Call Setup Success
Rate formula !
Call
Callset
setup
up
success
=
success rate
rate


Exercise
This page is intentionally left blank


Call Set Up Success Rate
UCSSR005_R_Cs RNC metrics

Call
Callset
setup
up URRC013_CR_Cs
success
success rate
rate = x UIuSCCP006_R_Cs
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
success rate
rate = x UIuSCCP006_R_Ps
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.

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

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 succ ess rate CS First RRC Connection success rate


Case Study : Accessibility Monitoring &
Troubleshooting
100.00%
98.00%
100.00%
96.00%
99.00%
94.00% 98.00%
92.00% 97.00%
96.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
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 succ ess rate CS RRC Connection succ ess 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


9 Pre-emption


9 Pre-emption
9.1 Principles


9 Pre-emption
9.2 Counters


9 Pre-emption
9.2 Counters [cont.]


9 Pre-emption
9.3 Set of Indicators
 Ratio of queued services which have been served

 Globally :
VS.PreemptQueuedServServed[all Services] /
(VS.PreemptQueuedServServed[all] + VS.PreemptQueuedServNotServed[all])
 Per service type :

VS.PreemptQueuedServServed[Service] /
(VS.PreemptQueuedServServed[Service]+VS.PreemptQueuedServNotServed[Service])
 Ratio of preemption procedures by CAC failure cause:

VS.PreemptNbTrgPerRrcEstabCause[Cause] / VS.PreemptNbTrgPerRrcEstabCause[all]
 Ratio of preemption procedures per service type

VS.PreemptNbTrgPerServType[Service] / VS.PreemptNbTrgPerServType[all]


10 RRC Connection Re-establishment


10.1 Example of re-establishment UL Flow in Cell_DCH
UE Node B RNC CS-CN PS-CN
UL RL failure UL RLC Unrecoverable

detected RL Failure Ind. Error detected
Radio Link Deletion Req
RNC suspends
RLC & MAC,
DL RL failure Radio Link Deletion Resp Starts Timer
or
RLC Unrecoverable ALCAP Release
Error detected
Cell Update RNC stops
“radio link failure” or “RLC unrecoverable error” Timer
Radio Link Setup RNC resumes

RLC, MAC
Radio Link Setup Resp
ALCAP & FP Sync.

Cell Update Confirm
Radio Bearer Reconfiguration Complete

Conditions and procedures for the feature application

10.2 Counters
Counters for RRC connection re-establishment Monitoring
Counter
Counter name Location Description Screening
Id
Screening 0 : PS Other
Screening 1 : PS Uplink Radio Link Failure
Screening 2 : PS Downlink Radio Link Failure
Number of attempt of Screening

Error
3 : PS Uplink RLC Unrecoverable
RRC Cell Update for Screening 4 : PS Downlink RLC Unrecoverable
Reference
# 57 VS. RrcReEstablishmentAttempt RRC connection re- Error
Cell establishment Screening 5 : PS Invalid Configuration Failure
procedure Screening 5 : CS Other
Screening 6 : CS Uplink Radio Link Failure
Screening 7 : CS Downlink Radio Link Failure
Screening 0 : PS Other
Screening 1 : PS Uplink Radio Link Failure
Screening 2 : PS Downlink Radio Link Failure
Number of successfull Screening
Error
3 : PS Uplink RLC Unrecoverable
Reference RRC connection re- Screening 4 : PS Downlink RLC Unrecoverable
# 58 VS.RRCReestablishmentSuccess
Cell establishment by RRC Error
Cell Update Screening 5 : PS Invalid Configuration Failure
Screening 5 : CS Other
Screening 6 : CS Uplink Radio Link Failure
Screening 7 : CS Downlink Radio Link Failure


10.3 Indicators
Indicators for RRC connection re-establishment Monitoring
Metrics
Metrics Definition Location
proposal
Iu-CS call VS.IuAbnormalReleaseRequestCs /
FDDCell
drop rate VS.IuReleaseCompleteCs
VS.IuAbnormalReleaseRequestPs /
Iu-PS call drop VS.IuAbnormalReleaseRequestPs +
FDDCell
rate VS.DownsizingStep2Success +
VS.RadioBearerReleaseSuccess
Definition: Number of Cell Update failure by cause
Cell Update vs Total Cell Update failure
Failure FDDCell
distribution Formula: VS.NbrCellUpdates[Cell Update failure
cause i] / VS.NbrCellUpdates[all screenings]
Definition : This metrics shows the success rate of
RRC the 33821 RRC Reestablishment feature
Reestablishmen Formula : VS.RRCReestablishmentSuccess [RRC FDDCell
t Success rate Screenings] / VS. RrcReEstablishmentAttempt [RRC
Screenings]
Definition : This metrics shows the failure rate of

RRC the 33821 RRC Reestablishment feature
Reestablishmen Formula : 1 – ( VS.RRCReestablishmentSuccess FDDCell
t Failure rate [RRC Screenings] / VS. RrcReEstablishmentAttempt
[RRC Screenings] )

VS.NbrCellUpdates - #901: Number of cell update messages received

• Sub-Counter #0: Cell Reselection
• Sub-Counter #1: Periodic Cell Update
• Sub-Counter #2: Uplink Data Transmission
• Sub-Counter #3: Paging Response
• Sub-Counter #4: Re-entered Service Area
• Sub-Counter #5: Radio Link Failure
• Sub-Counter #6: RLC Unrecoverable Error
Sub-counter 5 and 6 correspond to the Cell Update procedure following a radio link drop (RL Failure or RLC
unrecoverable error)


for this module


End of Module
Module 1


5
Section 5
Retainability Monitoring
Module 1
9300 WCDMA
Edition 1.0

Blank Page

Retainibility Monitoring
Document History

names and formulae
02 2009-04-10 Charneau, Jean-Noel Add the indicator UIU022_C_Ps to replace

UIU022_C_Ps which is not taking into account
all RAB release scenario

Module Objectives
 Describe the retainability metric family




Retainibility Monitoring This page is left blank intentionally

Table of Contents
Page
1 Retainability analysis 7
Call Drop: Definition 8
Network Retainability Performance 9
Call Drop: RL Failure detected by RNC (1/2) 10
Call Drop: RL Failure detected by RNC (2/2) 11
Call Drop: RLC Unrecoverable Error detected by UE on SRB 12
Call Drops due to UTRAN generated reasons 13
IuReleaseRequest causes (1/4) 14
Call Drop Rate: RNC level 18
CS Call Drop Rate: Reference FDDCell level 19
PS Call Drop Rate: Reference FDDCell level 20
Part of call drop: radio connection lost with UE 22
2 Retainability troubleshooting 23
Call Drop Rate Analysis 24
Retainibility issues causes 25
Retainability Troubleshooting 26
Example: Retainability Troubleshooting Chart: Failure Drop cause 27
Typical radio problems in a W-CDMA network 28
Detection of bad radio conditions 29
Missing neighbor - Impact 30
Missing neighbor – Detection and solution 31
6·5 Isolated site - Impact All Rights Reserved © Alcatel-Lucent 2010 32
Isolated
Retainibility Monitoring site - Detection and solution
33
Radio pollution - Impact 34
Radio pollution - Detection and solution 35
End of Module 37



1 Retainability analysis


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

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


Call Drop: RL Failure detected by RNC (1/2)
UE Node B RNC CN
Loss of UL synchro
FDDCell counter
detected on last RL #53 Last Radio Link drops
Radio Link
Failure Indication
ueCallSpare3 timer
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

Call Drop: RL Failure detected by RNC (2/2)
VS.IuReleaseReqPs - #599
A set ofSwitch
subcounters
toscreened
noteson:view!
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
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
6 · 11 #0: Other type of Call •AllSub-Counter #1: Signalling
Rights Reserved © Alcatel-Lucent 2010 Only
• Sub-Counter #2: 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
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: HSDPA DL/E-DCH UL

Call Drop: RLC Unrecoverable Error detected by UE on SRB
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
• Sub-Counter #6: CS Streaming 14.4
• Sub-Counter #7: Any PS

Call Drops due to UTRAN generated reasons
Reference FDDCell counters
 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
 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
 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


IuReleaseRequest causes (1/4)
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 (RB Reconf failure, etc),

T360 expiry (no answer to RB release) or internal 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 “Signaling 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)


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 CELL_FACH
T360 Expiry 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
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 No Remaining RAB

(*): 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 Release due to UTRAN Generated Reason

Generated Reason
Failure in the Radio Failure in the Radio Interface Procedure

Interface Procedure
No Resource Available Failure in Upgrading or Upsizing a RB which leads to a Call Drop

(*): PS cause only

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[all]) + ΣNrc(#592[all])
=
at RNC level #1658.[1-3]
RNC metric UIU007_R_Ps
PS call drop rate Σcell(#589[all]) + ΣNrc(#588[all])

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

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

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.[all]

at cell level
= #594.[all]
 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


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
• Sub-Counter #10: PS I/B < 64 • Sub-Counter #11: PS I/B 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

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.[all]

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

 Normal release = Radio Bearer Release Complete received by RNC
 Abnormal release = Iu Release Request sent by RNC for RAB still established

VS.RESERVED11 - #2703
The definition for the new counter would be VS.IuReleaseCommandPSWithRAB.
Description: Nb of RANAP Iu Release Command messages received by RNC from PS CN, while t least one PS RAB
is still established for the user.
The counter is incremented for each PS RAB being established, in the reference cell.

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


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)
 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)


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

Conditions - Monitor UL RSSI
Mobility - Monitor SHO

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

-Monitor PS-FP counters


Retainability Troubleshooting
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)

Example: Retainability Troubleshooting Chart: Failure Drop cause
Retainability Analysis – S/PS

RNC level Valid for C
S/PS)
request C
CS High Call drop rate at RNC level
PS High Call drop rate at RNC level (Iure lea se
9*
#576*, 59
Counters:
UeGenerated AbnormalCondition
Signalling
RadioConnection TimerRelocExpiry Unspecified
OAM Intervention RepeatedIntegrity ConnectionRelease 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

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

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


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


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


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.


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.


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


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
Module 1


6
Section 6
Mobility Monitoring
Module 1
9300 WCDMA
Edition 1.0

Blank Page

Mobility Monitoring
Document History

Addition of new UA6 counters allowing to
monitor the CS Inter-RAT HHO preparation
success rate per Cell
Addition of Inter-Freq IntraRNC+InterRNC with
Iur counters
02 2010-04-27 Vincent Nolan UA07

Module Objectives
 Describe the mobility metric family


Mobility Monitoring


Mobility Monitoring This page is left blank intentionally

Table of Contents
Page
1 Mobility Overview 7
Mobility overview 8
2 SHO Monitoring and Troubleshooting 9
SHO overview 10
SHO preparation – Softer HO – Cell Addition - Counters (1/2) 11
SHO preparation – Softer HO – Cell Addition - Counters (2/2) 12
SHO preparation – Softer HO – Cell Addition - Metrics 13
SHO preparation – Soft HO – Cell Addition - Counters (1/2) 14
SHO preparation – Soft HO – Cell Addition - Counters (2/2) 15
SHO preparation – Soft HO – Cell Addition - Metrics 16
SHO execution - Active Set Update - Counters 17
SHO execution - Metrics 18
SHO Analysis & Troubleshooting (1/2) 19
SHO Analysis & Troubleshooting (1/2) 20
3 HHO 3G-2G Monitoring 21
3G-2G CS Handover Success - counters 22
3G-2G Global CS HHO Success Rate 23
3G-2G CS Handover Preparation Success - counters 24
3G-2G CS HO Preparation Success 25
3G-2G CS Handover Preparation Failure - counters 26
3G-2G CS HO Preparation Failure Rate 27
3G-2G CS Handover Execution Success - counters 28
3G-2G CS HO Execution Success Rate 29
3G-2G CS Handover Execution Failure - counters 30
7·5 3G-2G CS Handover: FDDCell Counter Tree
All Rights (Rescue
Reserved case)
© Alcatel-Lucent 2010 31
3G-2G CS HO Execution Failure Rate (reversion to 3G)
Mobility Monitoring
32
3G-2G CS HO Execution Failure Rate (call drop) 33
4 HHO 3G-3G Monitoring 34
3G-3G HHO – InterRNC no Iur – Preparation Success - counters 35
3G-3G HHO – InterRNC no Iur – Preparation Failure - counters 36
3G-3G HHO – InterRNC no Iur - Preparation Success Rate 37
3G-3G HHO – InterRNC no Iur – Execution Success - counters 38
3G-3G HHO – InterRNC no Iur – Execution Success Rate 39
3G-3G Inter-freq HHO – IntraRNC+InterRNC with Iur - Success 40
3G-3G Inter-freq HHO – IntraRNC+InterRNC with Iur - Rate 41
3G-3G Inter-frequency HHO - Intra-RNC – Success - counters 42
3G-3G Inter-frequency HHO - Intra-RNC – Failure - counters 43
3G-3G Inter-frequency HHO - Intra-RNC – Failure Rate 44
5 HHO 3G-2G Analysis & Troubleshooting 45
CS 3G-2G Mobility Analysis & Troubleshooting 46
Summary 49
Action to improve the Preparation phase 50
Actions to improve the Execution phase 51
End of Module 53


Mobility Monitoring

1 Mobility Overview

Mobility Monitoring

1 Mobility Overview
Mobility overview
 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

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

SHO preparation – Softer HO – Cell Addition - Counters
(1/2)
UE Node B RNC #55

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

SS
SUCCE
Radio Link Addition
Radio Link Addition Response success
FDDCell Counters
UE Node B RNC FAILU

RE
Measurement Report (Event 1a or 1c)
CAC #39.[2-7]
NOK
RNC CAC 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
• 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
• Sub-Counter #8: NodeB out of order (No answer) (Screening 8 is not implemented, is Always zero in V6.0.)
SHO preparation – Softer HO – Cell Addition - Counters
(2/2)
UE Node B RNC
Measurement Report (Event 1a or 1c) FAILU
RE
CAC
OK
#39.[0]
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
• Sub-Counter #2: RRM refusal
• Sub-Counter #8: NodeB out of order (No answer)

SHO preparation – Softer HO – Cell 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

SHO preparation – Soft HO – Cell Addition - Counters
(1/2)
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
success
FDDCell Counters
UE Node B 1 Node B 2 RNC FAILU

Measurement Report (Event 1a or 1c)
RE
CAC
NOK #38.[2-7]
Radio Link Setup
unsuccess
RNC CAC 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_RECONFIGURATION_FAILURE
• Sub-Counter #1: Timeout nbap
• Sub-Counter #8: NodeB out of order (No answer) (Screening 8 is not implemented, is Always zero in V6.0.)

SHO preparation – Soft HO – Cell Addition - Counters
(2/2)
UE Node B 1 Node B 2 RNC
RE
CAC
OK
Radio Link Setup Request #38.[0]

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
Number of radio links failed in setup on a NBAP point of view.
screened by detecting event:

• Sub-Counter #0: RADIO_LINK_SETUP_FAILURE
• Sub-Counter #8: NodeB out of order (No answer)

SHO preparation – Soft HO – Cell 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

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

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)

SHO Analysis & Troubleshooting (1/2)
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

SHO Analysis & Troubleshooting (1/2)
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
cc ess succes
pUnsu itionUn
Node B alarms
RL Seture c auses] RL Addilu re c auses]
[failu [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

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)
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)

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

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

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

1st #568[2] Relocation cancel expiry
Relocation Cancel
ca se
No answer from CN to Relocation Required
Decision for HHO

Handover failure
Measurement Report on the 2G side
2nd Relocation Required
ca se
#???
#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

3G-2G CS HO Preparation Failure Rate
3G-2G #558.[5-9]
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
Number of relocation Preparation failures on CS Iu interface
A set of subcounters screened on: IU Relocation command failure causes
• Sub-Counter #5 : 3G to 2G UE involved. Relocation timeout
• Sub-Counter #6 : 3G to 2G UE involved. Relocation already in progress
• Sub-Counter #7 : 3G to 2G UE involved. Relocation failure in target system
• Sub-Counter #8 : 3G to 2G UE involved. Relocation unable to establish
• Sub-Counter #9 : 3G to 2G UE involved. Other relocation failure
VS.IuRelocationRequired - #556
Number of relocation required at Iu interface
• Sub-Counter #2 : 3G-2G CS
IRATHO.FailRelocPrepOutCS - #1845
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

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

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

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

1st Handover from UTRAN Failure
ca se 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

2nd TRelocOveral
UE fails to connect to 2G
ca se 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

3G-2G CS Handover: FDDCell 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

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)

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

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
• Sub-Counter #0 : 3G-3G CS, UE involved
• Sub-Counter #1 : 3G-3G PS, UE involved
• 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

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

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-15]
=
Preparation #535.[0,3]
Success Rate
FDDCell metric UHO3G3G004_CR_Ps

PS 3G-3G HHO
Incoming #535.[1,4] - #537.[0-3,8,10,12-15]
=
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.

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
#505[9] & #552[9] for CS Relocation Detect

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

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-15])
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-3GHHOHHOOutgoing
Outgoing =
Execution
Success Rate #557.[0,3]
RNC metric UHO3G3G009_R_Ps
CS Σcell(#506.[9]) + ΣNrnc (#553.[9])

CS3G-3G
3G-3GHHOHHOOutgoing
Outgoing=
Execution
Success Rate #557.[1,4]
Mobility Monitoring

3G-3G Inter-freq HHO – IntraRNC+InterRNC with Iur -
Success
Reference
S
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 either in the
same RNC or in a neighbouring 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 either in the same RNC or in a neighbouring RNC (a Iur link is setup towards the inter-
frequency cell).

3G-3G Inter-freq HHO – IntraRNC+InterRNC with Iur -
Rate
Reference FDDCell metric
3G3G # 175.[all]
3G3GInter-freq
Inter-freqHHO
HHO =
Outgoing
Outgoing FailureRate
Failure Rate #174.[all]
Reference FDDCell metric
3G3G #177.[all]
3G3GIntra-RNCHHO
Intra-RNCHHO =
Incoming
IncomingFailure
FailureRate
Rate #176.[all]

Mobility Monitoring

3G-3G Inter-frequency HHO - Intra-RNC – 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.

3G-3G Inter-frequency HHO - Intra-RNC – 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.

3G-3G Inter-frequency HHO - Intra-RNC – 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

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

3G-2G CS HHO Preparation Analysis & Troubleshooting
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.IuRelocationCmdFailuresCs.3Gto2GRelocTimeoutUeInv 1845 IRATHO.FailRelocPrepOutCS.TRELOCprep_exp

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

Mobility Monitoring
#558
VS.IuRelocationCmdFailuresCs
• 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

3G-2G CS HHO Execution Analysis & Troubleshooting
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

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

failures ?
• What actions could improve HHO preparation/execution

performances ?

Mobility Monitoring

Action to improve the Preparation phase
 The 3G2G HHO Preparation Failure causes are the following ones:
 Failure in 2G target cell (congestion, outage)
 Wrong definition of 3G neighbouring identifiers (cells, LAC…) in 2G network
 Wrong definition of 2G neighbouring identifiers (cells, LAC…) in 3G network
 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

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
Module 1

Mobility Monitoring

7
Section 7
Network Quality Monitoring
Module 1
9300 WCDMA
Edition 1.0

Blank Page

Document History

Change of the UL RSSI indicator formula, going
back to the UA4.2 one using counter #303
02 2009-04-10 Charneau, Jean-Noel Correction of UBLER006_CR_Ps formula

Module Objectives
 Describe the quality metric family



Section
Section 87 ·· Pager
Page 33

Network Quality Monitoring This page is left blank intentionally

Section
Page 44
Table of Contents
Page
1 Network Quality Overview 7
Quality Overview (1/2) 8
Quality Overview (2/2) 9
2 Network Quality Monitoring 10
Quality Monitoring & Troubleshooting 11
BLER metrics 12
Throughput metrics 13
3 RF Quality Analysis 14
RRC Connection / RF Conditions Analysis / DL Quality 15
RRC Connection / RF Conditions Analysis / DL Level 16
RRC Connection / RF Conditions Analysis / UL Radio Load 17
RRC Connection / RF Conditions Analysis / UL Cell Load 18
RF Conditions Analysis 19
DL RF analysis 20
UL RF analysis 21
End of Module 23



Section
Page 66
1 Network Quality Overview


Section
Page 77
Quality Overview (1/2)
 Defines the ability of the network to provide quality transmission of the

user requested services
 The main focus will be to maximize

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


Section
Page 88
Quality Overview (2/2)
UTRAN:
Core Network parameters
RF Coverage ControlRF Quality
RLC parameters
RRM Algorithms Fine tuning, mainly
RB Adaptation downsize
RB Adaptation upsize
iRM Sched downgrade / DlTxPwr
iRM Power Preemption
iRM Sched upgrading based on TxCP
Actions to algorithm
improve AO downsize
Quality KPIs
AO upsize
Server parameters
Network topology


Section
Page 99
2 Network Quality Monitoring


Section
Page 10
10
Quality Monitoring & Troubleshooting
 BLER and Throughput Monitoring & Troubleshooting
 Bad RF Quality
 In DL: Focus on RF measurements: bad Ec/No, bad RSCP, too high or
too low SPU,ASU/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


Section
Page 11
11
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.

Section
Page 12
12
Throughput metrics
 Find the unit of the four metrics below

 Using the RNC counters catalogue
RNC metric UTraffic024_R
Traffic 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 80 * # 1543.[all]
over =
over RAB allocationtime
RAB allocation time Σcell(# 1667.cum.[all])
Reference FDDCell metric UTraffic030_CR_CallType
Traffic
TrafficDL
DLRLC SDUThroughput
RLCSDU Throughput 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 8000 * # 1555.[CallType]
over =
over activity timeper
activity time perCall
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

Section
Page 13
13
3 RF Quality Analysis


Section
Page 14
14
RRC Connection / RF Conditions Analysis / 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

Section
Page 15
15
RRC Connection / RF Conditions Analysis / 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

Section
Page 16
16
RRC 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)
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.

Section
Page 17
17
RRC 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

• 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 (%)

Section
Page 18
18
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.

Section
Page 19
19
DL RF analysis
Operator dependance
dependant
RF Conditions Analysis – According to RF design
Cell level strategy for
forthe
thedifferent
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) •Note: be aware of if
•Ping-pong areas optimization
•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

Section
Page 20
20
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
Channelizer failures.
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
- Radiatingsystem 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).

Section
Page 21
21

for this module


Section
Page 22
22
End of Module
Module 1


Section
Page 23
23
8
Section 8
Capacity Monitoring
Module 1
9300 WCDMA
Edition 1.0

Blank Page

Capacity Monitoring
Document History

names and formulae
Charneau, Jean-Noel Addition of new UA6 counters to better monitor

blocking and load of radio resources

Module Objectives
 Describe the capacity metric family


Capacity Monitoring

Section 98 · Pager
Page 3

Capacity Monitoring This page is left blank intentionally

Section 98 · Pager
Page 4
Table of Contents
Page
1 Capacity Monitoring 7
UTRAN capacity analysis strategy 8
Reactive capacity planning 9
UTRAN congestion detection principles 10
Blocking Characterization 11
Capacity monitoring 12
Which resource can block ? 13
Find a counter to detect blocking of a given resource ? 14
2 Capacity Analysis 15
Capacity Analysis 16
Blocking and Load 17
3 Capacity Troubleshooting 18
DL Tx Power Load 19
DL Code Load 20
UL Radio Load 21
CEM Load 22
Iub Load 23
RNC Load 24
Bottleneck analysis : RB Allocation Procedure 25
Bottleneck analysis : Per type of call 29
Solve Capacity Issue 30
Case Study 31
4 Capacity Licensing Monitoring 32
NodeB capacity licensing 33
9·5 Capacity licensing counters All Rights Reserved © Alcatel-Lucent 2010 35
Capacity licensing counters screenings
Capacity Monitoring
36
CEM monitoring counter 37
End of Module 39

Contents [cont.]
notes view!
lysis and Traffic Load Monitoring

Section 98 · Pager
Page 6
1 Capacity Monitoring

Capacity Monitoring

Section 98 · Pager
Page 7
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
200000000
180000000
160000000
140000000
120000000
100000000
80000000
60000000
40000000
20000000
0
07-janv-06
14-janv-06
21-janv-06
28-janv-06
05-nov-05
12-nov-05
19-nov-05
26-nov-05
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
11 Feb 06
18 Feb 06
25 Feb 06
04-mars-06
11-mars-06
18-mars-06
25-mars-06
4 Feb 06
1 Apr 06
8 Apr 06
15 Apr 06
C S D L tra ffic K B y te s P S D L Tra ffic K B y te s t o ta l 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.

Section 98 · Pager
Page 8
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.

Section 98 · Pager
Page 9
UTRAN congestion detection principles
 Principle of congestion
detection Blocking?
NO Status Green
 Combination of blocking + load No action required
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

Section 98 · Pager
Page 10
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

Section 98 · Pager
Page 11
Capacity monitoring FDDCell metrics
URB014_C
# 1629.[all except 0,4]

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]
URL037_CR
#40.[all except 1]
RL
RLReconfiguration
ReconfigurationBlocking Rate =
BlockingRate
#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.
Number of unsuccessful radio link setup
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.
RRC.FailConnEstab - #404
Failed RRC Connection Establishments by Cause.
RRC.SuccConnEstab - #403
Number of rrc connection successful

Section 98 · Pager
Page 12
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)

Section 98 · Pager
Page 13
Find a counter to detect blocking of a given resource ?
Resource Blocking counters

DL Tx
#1629 VS.RadioBearerEstablishmentUnsuccess.[1]
Power
DL
Code
UL RSSI
( #404.4 RRC.FailConnEstab.RSSI, #10213 VS.FailedAdmissionDueToULload )
CEM processing #1629 VS.RadioBearerEstablishmentUnsuccess.[7]
Iub Bandwidth #1629 VS.RadioBearerEstablishmentUnsuccess.[13]
Iub AAL2 cid #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.

Section 98 · Pager
Page 14
2 Capacity Analysis

Capacity Monitoring

Section 98 · Pager
Page 15
2 Capacity Analysis
Capacity Analysis
 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

Section 98 · Pager
Page 16
2 Capacity Analysis
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.

Section 98 · Pager
Page 17
3 Capacity Troubleshooting

Capacity Monitoring

Section 98 · Pager
Page 18
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

Section 98 · Pager
Page 19
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

Section 98 · Pager
Page 20
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

Section 98 · Pager
Page 21
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. AllocLicensingRefusal #10317 VS.R99CECapacity.CumHWcapacity
#10317 VS.R99CECapacity. AllocHWfail #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)

Section 98 · Pager
Page 22
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.

Section 98 · Pager
Page 23
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.

Section 98 · Pager
Page 24
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

Section 98 · Pager
Page 25
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

Section 98 · Pager
Page 26
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
#10312 CEMAllocSuccessDL
#10313 CEMAllocFailedUL
#10314 CEMAllocFailedDL
#10315 CEMAllocFailedBothUL
#10315 CEMAllocFailedBothDL
All these counters are pegged screen id Screen Name Suffix 3GPP
on a per SF basis, indicating the 0 For SF4 SF4
UL or DL SF that was rejected 1 For SF8 SF8
due to lack of CEM resources : 2 For SF16 SF16
3 For SF32 SF32
4 For SF64 SF64
5 For SF128 SF128
6 For SF256 SF256

Capacity Monitoring

Section 98 · Pager
Page 27
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

Section 98 · Pager
Page 28
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

Section 98 · Pager
Page 29
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

Section 98 · Pager
Page 30
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

Section 98 · Pager
Page 31
4 Capacity Licensing Monitoring

Capacity Monitoring

Section 3
9 · Pager 32
NodeB capacity licensing
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)

Section 3
9 · Pager 33
NodeB capacity licensing [cont.]
 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).

Section 3
9 · Pager 34
Capacity licensing counters
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

Section 3
9 · Pager 35
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.

Section 3
9 · Pager 36
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)

Section 3
9 · Pager 37
for this module

Capacity Monitoring

Section 98 · Pager
Page 38
End of Module
Module 1

Capacity Monitoring

Section 98 · Pager
Page 39
9
Section 9
Traffic Monitoring
Module 1
3JK10064AAAAZZZZA Edition 2.0
9300 WCDMA
Edition 1.0

3JK10064AAAAZZZZA Edition 2
Blank Page

Traffic Monitoring
Document History

Chatila, Rayan Corrections of counters and indicators numbers,
names and formulae

Module Objectives
 Describe the traffic and call profile metric family


Traffic Monitoring

Section
Section10
9 · Page
Pager33

Traffic Monitoring This page is left blank intentionally

Section
Section10
9 · Page
Pager44
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 PS Traffic per RNC 12
2 User-Perceived Throughput Counters 13
2.1 Overview (1/3) 14
2.2 Overview (2/3) 15
2.3 Overview (3/3) 16
2.4 Algorithm for DL Throughput Calculation (1/2) 17
2.5 Algorithm for DL Throughput Calculation (2/2) 18
2.6 New Counters for R99 Throughput 19
2.7 New Counters for R99 Throughput 20
2.8 Screenings Ps R99 21
End of Module 23

Traffic Monitoring

Contents [cont.]
notes view!
ysis and Traffic Load Monitoring

Section
Section10
9 · Page
Pager66
1 Traffic Monitoring

Traffic Monitoring

Section
Section10
9 · Page
Pager77
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

Section
Section10
9 · Page
Pager88
1.2 Average Number of Calls per Day – RNC metrics
RNC metric URAB012_R_CsVoice
Average
Averagenb nbof
of = #1660.[1].Avg
Voice calls Per day
Voice calls Per day
RNC metric URAB012_R_CsVideo

Average
Averagenb nbof
of = #1660.[2].Avg
Video
Video calls perday
calls per day
RNC metric URAB012_R_Ps

Average
Averagenb nbof
of
Data = #1660.[0,4-10].Avg
Data calls perday
calls per day

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
1 Other Dl, Ul, Traffic Class combinations
2 Dl and Ul are CS Speech, TC is Conversational
3 Dl and Ul are CSD 64, TC is Conversational
4 Dl and Ul are CS, TC is Streaming
5 Dl is any low rate PS I/B, Ul is any PS I/B, TC is Interative
6 Dl is any low rate PS I/B, Ul is any PS I/B, TC is Background
7 Dl is any high rate PS I/B, Ul is any PS I/B, TC is Interative
8 Dl is any high rate PS I/B, Ul is any PS I/B, TC is Background
9 Dl is any low rate Ps Str and Ul is any PS Str, TC is Streaming
10 Dl is any high rate Ps Str and Ul is any PS Str, TC is Streaming

Section
Section10
9 · Page
Pager99
1.3 Average Number of Calls per Day – DL - Cell
metrics
Reference FDDCell metric URB013_CR_DLCsVoice
Average
Averagenb nbof
of DL
DL = #1666.[2-3].Avg
Voice
Voice calls
calls Per
Per day
day
Reference FDDCell metric URB013_CR_DLCsVideo

Average
Averagenb nbof
of DL
DL = #1666.[4].Avg
Video
Video calls perday
calls per day
Reference FDDCell metric URB013_CR_DLPs

Average
Averagenbnbofof DL
DL = #1666.[5-21].Avg
Data
Datacalls
calls per
perday
day

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
1Signalling Only
2CS speech NB or LR AMR
3CS 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
Section
Section10
9 · Page
Pager10
10
1.4 Average Number of Calls per Day – UL - Cell
metrics
Reference FDDCell metric URB013_CR_ULCsVoice
Average
Averagenb nbof
of UL
UL = #1667.[2].Avg
Voice
Voice calls
calls Per
Per day
day
Reference FDDCell metric URB013_CR_ULCsVideo

Average
Averagenb nbof
of UL
UL = #1667.[3].Avg
Video
Video calls perday
calls per day
Reference FDDCell metric URB013_CR_ULPs

Average
Averagenbnbofof UL
UL = #1667.[4-16].Avg
Data
Datacalls
calls per
perday
day

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 #15 : PS I/B or PS Str HSUPA • Sub-Counter #16 : TRB on cell RACH

Section
Section10
9 · Page
Pager11
11
1.5 Uplink/ Downlink PS Traffic per RNC
RNC metric UTraffic015_R_Ps
DL
DL PS
PSTraffic
Traffic per
per RNC
RNC == #1544
#1544.[6-16]
.[6-16]
RNC metric UTraffic025_R_Ps
UL
ULPS
PSTraffic
Traffic per
per RNC
RNC == #1543
#1543.[6-16]
.[6-16]
Reference FDDCell metric UTraffic017_C_Ps
DL
DLPS
PSTraffic
Traffic per
per Cell
Cell== #1554
#1554.[6-16]
.[6-16]
Reference FDDCell metric UTraffic018_C_Ps
UL
ULPS
PSTraffic
Traffic per
per Cell
Cell== #1553
#1553.[6-16]
.[6-16]

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:
 Total count of RLC payload on dedicated channels containing Packet Switched data (in Kbytes):
VS.DedicatedDownlinkKbytesRlcActiveCells #1554 for DL
VS.DedicatedUplinkKbytesRlcActiveCells #1553 for UL
Screenings for #1544 and #1543:

• 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
Screenings for #1554 and #1553:

• 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

Section
Section10
9 · Page
Pager12
12
new
2 User-Perceived Throughput Counters

Traffic Monitoring

Section
Section10
9 · Page
Pager13
13
2.1 Overview (1/3)
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 Overview (2/3)
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 Overview (3/3)
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 (1/2)
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.5 Algorithm for DL Throughput Calculation (2/2)
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 All

HSDPA
Rightsto R99 or© vice-versa
Reserved Alcatel-Lucent 2010
 RNC starts an intra-RNC inter-frequency handover or an inter-RAT handover for an UE which has an I/B
2.6 New Counters for R99 Throughput
UC2500:
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 CM attribute
PmUserTpConfig.dlR99Thd.
UC2501:
Distribution of the user perceived throughput for interactive / background
traffic in a UMTS cell when using R99 UL traffic channels in CELL_DCH. The data

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 CELL_DCH
Triggering Event 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.7 New Counters for R99 Throughput
COUNTER ID 2501
Name NT_User_tp_r99_ul_rlc_refcell
3GPP UC2500:
Name VS.UserTP.R99UL
Distribution
Location ofCell
the user perceived throughput for interactive / background
(Reference)
traffic in a UMTS cell when using R99 DL traffic channels in CELL_DCH. The data
Unit event
Range 31 Bits
Type CUM
Scanner Type GPO
Family User Perceived Throughput
UC2501:
Distribution ofDistribution
Meaning, the user of the user perceived
perceived throughput
throughput for interactive/background
for interactive / background traffic in a
UMTS cell when using R99 UL traffic channels in CELL_DCH. The data rate threshold of
traffic in a UMTS
Description cell when using R99 UL traffic channels in CELL_DCH. The data
the screenings can be defined by the CM attribute PmUserTpConfig.ulR99Thd.
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 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 CELL_DCH
Triggering Event 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 from R99 DCH
10 · 20 to EDCH. 4) The RNC triggers: All Rights Reserved-©an intra-RNC
Alcatel-Lucent 2010 inter-frequency handover - an inter-RAT
Traffic Monitoring
handover
9300 WCDMA · UA07 R99 QoS Analysis and or - a cell change order procedure for a UE which has an I/B RAB mapped to
Traffic Load Monitoring
R99 DCH in UL.

Screening Criteria Data Rate Range R99 UL

2.8 Screenings Ps R99
VS.UserTP.R99DL #2500
[0] [1] [2] [3] [4] [5] [6] [7] [8] [9]
Thd0 Thd1 Thd2 Thd3 Thd4 Thd5 Thd6 Thd7 Thd8 Thd9
VS.UserTP.R99UL #2501

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]


for this module

Traffic Monitoring

Section
Section10
9 · Page
Pager22
22
End of Module
Module 1

Traffic Monitoring

Section
Section10
9 · Page
Pager23
23
Last But One Page
1 All Rights Reserved © Alcatel-Lucent @@YEAR

@@PRODUCT
@@COURSENAME

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

W-CDMA UA07 R99 Qos Analysis and Traffic Load Monitoing - EC - 1 - TMO18268 - FrontMatte

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

W-CDMA UA07 R99 Qos Analysis and Traffic Load Monitoing - EC - 1 - TMO18268 - FrontMatte

Загружено:

Авторское право:

Доступные форматы

9300 WCDMA

UA07 R99 QoS Analysis and

All Rights Reserved © Alcatel-Lucent 2010

All rights reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

2 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

4 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

5 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

6 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Welcome to UA07 R99 QoS Analysis and Traffic Load Monitoring

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

 identify why, when, and how to make performance management

7 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

8 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

9 Where you can get further information

UA07 R99 QoS Analysis and Traffic Load Monitoring

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

All Rights Reserved © Alcatel-Lucent 2010

 Switch to notes view!

10 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Did you meet the following objectives ?

Yes (or No (or

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

Yes (or No (or

12 All Rights Reserved © Alcatel-Lucent 2010

Thank you for your answers to this questionnaire

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

1·2 All Rights Reserved © Alcatel-Lucent 2010

Edition Date Author Remarks

01 2008-12-01 El Abed, Achrafe First edition

All Rights Reserved © Alcatel-Lucent 2010

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

1·3 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

1·4 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

1·5 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

Switch to notes view!

1·6 This page is left blank intentionally

All Rights Reserved © Alcatel-Lucent 2010

1·7 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

 End user expectations concerning services usage over UMTS

1·8 All Rights Reserved © Alcatel-Lucent 2010

All Rights Reserved © Alcatel-Lucent 2010

 But technology constraints…