R99NPO TrainingCounters UA6

9300 WCDMA
UA06 R99 QoS Analysis and

Traffic Load Monitoring
TMO18046 D0 SG DENI3.0
STUDENT GUIDE
All Rights Reserved Alcatel-Lucent @@YEAR
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

UA06 R99 QoS Analysis and Traffic Load Monitoring - Page 1
Empty page
Switch to notes view!
9300 WCDMA
UA06 R99 QoS Analysis and Traffic Load Monitoring
This page is left blank intentionally

Terms of Use and Legal Notices

1. Safety
Warning
Switch
to 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-Lucents 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 AlcatelLucent.
3
9300 WCDMA
All rights
reserved Alcatel-Lucent @@YEAR
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.About
Radio Network
Performance Overview
This Course
Course
outline1
1. Module
4. Topic/Section is Positioned Here
Technical support
2. Monitor
the Radio Network Performance
Course objectives
1. Module 1
3.1.
Monitoring
and Troubleshooting
Topic/Section
is Positioned methods
Here
Xxx1. Module 1
Xxx
Xxx

4. Network Accessibility Monitoring

1. Module 1
5.2.
Call
Management Monitoring
Topic/Section
is Positioned Here
1. Module 1
Topic/Section
is Positioned Here
6.3.
Retainibility
Monitoring
1. Module 1
7. Mobility Monitoring
1. Module 1
8. Network Quality Monitoring
1. Module 1
9. Capacity Monitoring
5
1. Module 1
9300 WCDMA
UA06Traffic
R99 QoS Analysis
and Traffic Load Monitoring
10.
Monitoring
1. Module 1

Course Outline [cont.]

9300 WCDMA

Course Objectives
Welcome to UA06 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 view!
in this guide
Switch to notes
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.
9300 WCDMA
Where you can get further information

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

10
9300 WCDMA

Self-assessment of Objectives
Contract number :
At the end of each
Course title :
Please, return this
Client (Company, Center) :
Language Switch
:
section you will be asked to fill this questionnaire

sheet to the trainer at the end of the training
to notes view!
Number of trainees :
Dates from :
to :
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
Instructional objectives
1
Yes (or
globally
yes)
No (or
globally
no)
To be able to XXX
2
11
9300 WCDMA

Comments
Self-assessment of Objectives [cont.]

Instructional objectives
12
Yes (or
Globally
yes)
No (or
globally
no)
Comments
9300 WCDMA
Other comments
Thank you for your answers to this questionnaire

Do not delete this graphic elements in here:
Section 1
Radio Network Performance
Overview
Module 1
3JK10055AAAAWBZZA Edition 1
9300 WCDMA

Section 1 Pager 1
Blank Page
12
Radio Network Performance Overview

9300 WCDMA UA06 R99 QoS Analysis and Traffic Load Monitoring
Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition

Section 1 Pager 2
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
13


Section 1 Pager 3
Module Objectives [cont.]
14


Section 1 Pager 4
Table of Contents
Page

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


Section 1 Pager 5
Table of Contents [cont.]

16


Section 1 Pager 6
17


Section 1 Pager 7
What is End user QoS over UMTS ?

End user expectations concerning services usage over UMTS
Several
applications
simultaneaously
...
Quick data
transmission
(delay & bit rate)
More
interactivity
(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 !
18

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.

Section 1 Pager 8
What is end user QoS over UMTS ? [cont.]

But technology constraints

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

(from voice 12.2kbps up to 384 Kbps FDD)
Various connections (real time CS & non real time PS)
Scarce
& costly
radio
resources
Heterogeneous
terrestrial
resources
Asymmetric traffic patterns

Various QoS (blocking, delay, throughput, BLER)
Multi-services environment
19
Load optimisation over

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

Section 1 Pager 9
Mapping Teleservices to QoS
Conversational
Voice messaging
voice and video
Streaming audio
and video
Fax
Increasing
Error
Tolerance
Telnet,
Interactive games
E-commerce,
WWW browsing,
FTP, still image
Conversational
Interactive
Streaming
(delay <<1 sec) (delay approx.1 sec) (delay <10 sec)
Increasing
Delay Tolerance
1 10


Section 1 Pager 10
E-mail arrival
notification
Background
(delay >10 sec)
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

1 11

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

Section 1 Pager 11
Standard QoS Bearer
CN
Node
UTRAN
UE
CN
Gateway
UE
Teleservice
External Bearer
Service
UMTS Bearer Service

Radio Access Bearer Service
(RAB)
Radio Bearer
Service
Iu Bearer
Service
...
...
Radio Physical
Bearer Service
Uu
1 12
CN Bearer
Service
Backbone
Bearer Service
Physical
Bearer Service
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.

Section 1 Pager 12
What is QoS UTRAN in UMTS?
Border
Gateway
IPv4 / IPv6 Backbone

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

IP
PDP
GTP
IP
RADIO Bearer
IP
PDP
GTP tunnel UMTS

GTP bearer
GTP
IP
ATM PVC
1 13
IP
IP
GTP
IP
IP
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.

Section 1 Pager 13
What is QoS UTRAN in UMTS? [cont.]

A comprehensive set of mechanisms answering end users expectations
Quick data
transmission
(delay & bit rate)
Several
applications
simultaneously
...
Power control
(delay & jitter)
DiffServ within RNC

HSDPA/HSUPA channels
Multi RAB per user
More
interactivity
for HSxPA see 9300 W-CDMA

UA06 HSxPA QoS Analysis and
iRM/Always On transitions
DiffServ within RNC
RAB parameters mapping flexibility

1 14

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

Section 1 Pager 14

Please be reminded to fill in the form

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


Section 1 Pager 15
End of Module
Module 1
1 16


Section 1 Pager 16
Section 2
Monitor the Radio Network
Performance
Module 1
3JK10056AAAAWBZZA Edition 1.1
9300 WCDMA

Section 2 Pager 1
Blank Page
22
Monitor the Radio Network Performance

Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2009-03-18
Charneau, Jean-Noel
Correction of the name of the counter #303

VS.UplinkRssi

Section 2 Pager 2
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.
23


Section 2 Pager 3
24


Section 2 Pager 4
Table of Contents
1 QoS counters definition
Introduction
Counters: Definition
Collect performance data with ALU solution (1/2)
Counter file storage
NPO introduction to UTRAN monitoring
2 Counters properties and Analysis
Counter groups and families (1/2)
Counter types (1/6)
Counter types (2/6)
Counter types (3/6)
Counter types (4/6)
Counter types (5/6)
Counter types (6/6)
Load (or SI) Counter: example
RNC C-Node counter families
RNC and FDDCell object instances for C-Node counters
Reference FDDCell object instance for C-Node counters
Neighbouring RNC object instance for C-Node counters
BTS counter families and object instances
MSS counter families and object instances
25
Counter
Monitor the Radio Screenings
Network Performance
3 Metrics
properties and Analysis
Metrics Definitions
Metrics Generic Formulas
4 Generating Reports and Analysis
4.1 RNC Counter Volume Control
Indicator Aggregation
4.2 Report Definition
Generate a report on NPO
Key Performance Indicators
Network Key Performance Indicators
Counter based KPIs
Methodological precautions
KPI value
Network Element aggregation
With other indicators
With alarms
With parameters modification
5 Alcatel-Lucent Call Trace Solution Overview
Introduction
Call Trace Session Types (1/4)
Configuring a Call Trace Session
6 Alcatel-Lucent Performance Monitoring Tools
6.1 OAM Performance Management Portfolio
6.2 OAM Performance Management Portfolio Strategy
6.3 Post Processing Call Trace Data with RFO
6.4 Post Processing Call Trace Data with WQA
End of Module

Section 2 Pager 5
Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

26


Section 2 Pager 6
1 QoS counters definition
27


Section 2 Pager 7
1 Define properties of QoS counters
Introduction
Network
Planning
Network
Deployment
Pre-launch
Optimization
Network
Acceptance
Network
Supervision
Network
Densification
Network
Design
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
28

All these factors contribute to NW Management OPEX Reduction

Section 2 Pager 8
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)
BTS
Performance Server
RNC
29

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

Section 2 Pager 9

WMS
Observation files
Directory
OBS
Main
Server
OBS
WIRELINE BACKBONE
Every
15
minutes
OBS
Observation
file containing
counters
Every
60
minutes
RNC
The equipment resets
the counters and
starts incrementing
the counters
2 10
OBS
BTS

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.

Section 2 Pager 10

WMS
Observation files
Directory
Main
Server
OBS
OBS
LAN
NPO HMI
Server of Clients
NPO Server
Citrix Server
VPN / Internet
NPO Client
Citrix Client
2 11

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.

Section 2 Pager 11
Counter file storage

/opt/nortel/data/access/observation
XML DTD (Document Type

Definition) available
on WMS, compliant with
3GPP
32.104 -01.dtd
YYYYMMDD/<NE>
<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
A20010613.1815+0100 -1830+0100_ RNC-RNC14_CN
A20010613.1830+0100 -1845+0100_ RNC-RNC14_CN
A20010613.1845+0100 -1900+0100_ RNC-RNC14_CN
h20010613.1800+0100 -1900+0100_ RNC-RNC14_CN
d20010613.0000+0100 -0000+0100_ RNC-RNC14_CN
20020613/BTSEq -XXXX070
A20010613.1800+0100 -1900+0100_ BTSEq -XXXX070
RNC C-Node example,

quarter hour
observation files
RNC C-Node example,
hour and daily
observation files
BTS Counters example,
hourly observation files
h20010613.1800+0100 -1900+0100_ BTSEq -XXXX070

d20010613.0000+0100 -0000+0100_ BTSEq -XXXX070
2 12

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

Section 2 Pager 12
NPO introduction to UTRAN monitoring

W-NPO
MS-NPO
MS-Portal
client
(OAM06)
MS-OMC
Customer NMS
WMS
Integrated
W-NPO
into UTRAN program
Mono
ROC
Mono technology
2 13
MS-SUP
MS-NPO
2G OMC-R
WMS
Integrated
Multi
into MS-OMC
ROC
Multi Technology


Section 2 Pager 13
2 14


Section 2 Pager 14

Alcatel-Lucent groups the Access Network observation in 3 major
groups:
C-Node Application Counters
RNC counters
Node-B Counters
BTS counters
I-Node Platform Counters
MSS Counters
RNC C-Node counters To monitor the UMTS features & functionalities at the
RNC
BTS counters To monitor the UMTS functionalities and Node-B platform
RNC MSS counters To monitor the RNC platform and the ATM layer
2 15


Section 2 Pager 15

The counter groups are further divided into families according to a
given UMTS feature or to a Performance Management purpose
Radio Link Management

Handover
Power Management
RRC Connection
IU Connection
RAB and RB Management
Security
Paging
Mobility
Radio Measurement
QOS Performance
User Plane Common Traffic
IUR Interface
User Plane Dedicated Traffic
2 16
BTS counter families
PCM statistics
Radio counters
CallP counters
ATM statistics
EEC
IMA statistics
IP statistics
HSDPA statistics
HSUPA statistics
Radio statistics
RNC PASSPORT Platform counter

families
ATM port
Logical Processor Use
Adjunct Processor Stats
Account ATM Vcc
Account ATM Vpc
IP Stats


Section 2 Pager 16
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
GP
begins
E E
X1
X2 X3
X4
X5
X6
Xi
Granularity Period
Counter.Cum= GP Xi
2 17


Section 2 Pager 17
GP ends
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
GP
begins
E E
X1
X2 X3
X4
X5
X6
Xi
Granularity Period
Counter.Cum= GP Xi
2 18


Section 2 Pager 18
GP ends
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
2 19


Section 2 Pager 19
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
GP
begins
E E
X1
X2 X3
X4
X5
Xi
XN
Granularity Period
Counter.Cum = GP Xi
Counter.Min = MinGP(Xi)
Counter.Nbevt = N
Counter.Max = MaxGP(Xi)
Counter.Avg = Counter.Cum / Counter.Nbevt
2 20


Section 2 Pager 20
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
2 21


Section 2 Pager 21
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
GP
begins
Eb
X1
X2
Ea
X3
X4
Ea
Xi
Granularity Period
2 22

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

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

Section 2 Pager 22
Xn-1
Xn
GP ends
Load (or SI) Counter: example

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


Section 2 Pager 23

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
2 24


Section 2 Pager 24
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
connection.
Ex: VS.IuSccpCnxSuccess.CsReqByRNC providing the
number of successful SCCP connections requested
by the RNC on the Iu CS interface
Iu-CS
Serving
RNC
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
2 25


Section 2 Pager 25
Iu-CS
Iur
Drift
RNC
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
the connection when the event occurs.
Serving
RNC
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
2 26


Section 2 Pager 26
Iur
Drift
RNC
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
providing the number of successfully established
SCCP connections when a neighboring RNC serves
as a Drift.
Serving
RNC
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.
2 27


Section 2 Pager 27
Iur
Drift
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
2 28


Section 2 Pager 28
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
2 29


Section 2 Pager 29
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
2 30

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.

Section 2 Pager 30
3 Metrics properties and Analysis
2 31


Section 2 Pager 31
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
2 32

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)

Section 2 Pager 32
Metrics Generic Formulas

Legend
Request
PM Counter
Counter: Request
Calculated Indicator
Success
Failure
Counter: Success
Indicator: Request Success
Success Rate
Failure Rate
Indicator: Success/request
Indicator: Failure / request
2 33

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]

Section 2 Pager 33
2 34


Section 2 Pager 34

Measured
Object
Class
Cell
()
Name
RRC.AttConnEstab
()
Is Activated
Y
()
VS.IrmUpgradingCommand
Cell
()
()
()
VS.RadioBearerEstablishmentUnsuccess
VS.RadioBearerReconfigFailure
VS.RadioBearerReconfigurationSuccess
VS.RadioBearerReconfigurationUnsuccess
Cell
Cell
Cell
Cell
Y
Y
Y
Y
Operator A
Name
Measured Object
Class
RRC.AttConnEstab
Cell
()
()
Cell
()
()
Cell
Cell
Cell
Cell
Operator B
Is Activated
Name
Y
()
N
()
Y
N
N
N
2 35
Measured Object
Class
RRC.AttConnEstab
Cell
()
()
Cell
()
()
Cell
Cell
Cell
Cell
Is Activated
Y
()
N
()
Y
Y
Y
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.

Section 2 Pager 35
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
CV: Counter Value

See comments below
2 36

The following rules shall be followed for time aggregation.

Rtotal
is the rule applied to CC counters:
CV.cum
Rload
= CV1.cum + CV2.cum + + CVn.cum
/ 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)

Section 2 Pager 36
CV96

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
2 37

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

Section 2 Pager 37
Generate a report on NPO
Click
Drag and Drop
Drag and Drop
2 38


Section 2 Pager 38
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%
CDR
2,50%
weekly call drop rate
contractual call drop rate
quality CDR
2,00%
1,50%
1,00%
0,50%
45
41
37
33
29
25
21
17
13
0,00%
week number
2 39

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.

Section 2 Pager 39
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
2 40


Section 2 Pager 40
Counter based KPIs
Network
Mobility
Network
Retainability
Network
Accessibility
Network
Quality
Counter
based KPIs
Capacity/
RRM
Load
Call Profile
HSxPA
Network
Congestion
2 41
Network
Traffic

Will be developed in next chapters

Section 2 Pager 41
Methodological precautions
METHODOLOGICAL PRECAUTIONS
Avoid typical errors regarding indicators interpretation
2 42


Section 2 Pager 42
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
2 43


Section 2 Pager 43
Network Element aggregation
cell 1
cell 2
cell 3
cell 4
cell 5
cell 6
cell 7
cell 8
cell 9
cell 10
number of calls number of call drop call drop rate

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

total nb of drop/total number of calls
9,95%
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
2 44


Section 2 Pager 44
With other indicators

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

70,0%
60,0%
50,0%
% CS call drop
40,0%
% PS call drop
30,0%
20,0%
10,0%
2 45


Section 2 Pager 45
07-062005
06-062005
05-062005
04-062005
03-062005
02-062005
01-062005
31-052005
30-052005
29-052005
28-052005
27-052005
26-052005
25-052005
0,0%
With alarms
PRACH reception in Cell
90
80
4,5
70
4
3,5
60
50
2,5
40
30
20
10
2 46


Section 2 Pager 46
1,5
1
0,5
PRACH fail
PRACH succ
% PRACH fail
With parameters modification

QoS degradation after parameter change

Reference
New set
100%
60000
99%
50000
98%
40000
97%
30000
96%
20000
95%
10000
93%
0
5
6/
2
/1
07
07
/1
4/
2
00
00
00
5
/1
07
/1
07
2/
2
0/
2
8/
2
/0
AMR calls
2 47
00
00
00
07
07
/0
6/
2
4/
2
/0
07
5
00
00
2/
2
/0
07
06
/3
0/
2
00
94%
% CSSR


Section 2 Pager 47
5 Alcatel-Lucent Call Trace Solution

Overview
2 48


Section 2 Pager 48
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,)
2 49


Section 2 Pager 49

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

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

Section 2 Pager 50

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)
From UA06 traced calls can be filtered based on their IMEI (the remaining
will be wild cards). This will allow 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.
2 51

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).
In UA06, the user will allowed to configure the 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).

Section 2 Pager 51

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

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

Section 2 Pager 52

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


Section 2 Pager 53
Configuring a Call Trace Session
Cell, Geographical Sessions
Parameters
Session
Creation mode
Access Session
2 54

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.

Section 2 Pager 54
6 Alcatel-Lucent Performance
Monitoring Tools
2 55


Section 2 Pager 55
6.1 OAM Performance Management Portfolio

OPTIONAL PRODUCTS
BASE PRODUCT
Counters
Counters
NPO
CallTraces
WMS
RFO
Radio Frequency
Optimizer
UTRAN
CallTraces
CallTraces
Wireless Quality
Analyzer
Wireless Management
System
WQA
2 56

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
Network
Performance
Optimizer
Analyzer :
CallTrace Based
Mobility Optimization
Call Failure Optimization

Section 2 Pager 56
6.2 OAM Performance Management Portfolio Strategy

TA
DA
Complementarities of Tools :
Successive Reduction of Zone
of Investigation
Drive Test Reductions
T
EN
EM
N
FI
RE
NPO <-> WQA <-> RFO
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 !!!
2 57

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

Section 2 Pager 57
6.3 Post Processing Call Trace Data with RFO

Messages
exchanged
Functions Per Call

Trace analysis
Call Flow
Message decoding
(inc. ASN1)
Grid view
Time graphs
One Shot hexa
decoding
ASN1
Decoded Info
2 58

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

Section 2 Pager 58
6.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
available:
WQA
Wireless
Provisioning
System
(a.k.a. WPS)
Optimization
Cycle
Matrices Computation
(Cell 1 - Cell 2)
3,50%
100,00%
p ercen tage tot al

i nter fer ence
80,00%
2,50%
70,00%
60,00%
2,00%
50,00%
1,50%
40,00%
30,00%
1,00%
20,00%
0,50%
10,00%
0,00%
-35
0,00%
-25
-15
-5
15
C/I (dB )
type (Soft/Softer, HSxPA, InterFreq,

2G<->3G)
Includes HO failure analysis
25
35
45
55
cum ul ative d istr ib utio n
90,00%
3,00%
Per Neighbouring Relation & Per HO
Analysis of Ping Pong HO
Provides recommendations:
Adjacencies to be added/removed
Upload of
CTn
Traces for
analysis
W-NMS
CTn
Parameters
Changes
for Network
Tuning
Modification can be fed into WPS

and then applied on the Network
UTRAN
2 59

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

Section 2 Pager 59


for this module
2 60


Section 2 Pager 60
End of Module
Module 1
2 61


Section 2 Pager 61
Section 3
Monitoring and Troubleshooting
methods
Module 1
9300 WCDMA

Section 3 Pager 1
Blank Page
32
Monitoring and Troubleshooting methods

Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
02
2009-04-10
Charneau, Jean-Noel
Removal of RNC Panel and Cell Panel

Section 3 Pager 2
Module Objectives
Explain what is the QoS monitoring and troubleshooting process
Identify the performance reports
33


Section 3 Pager 3
34


Section 3 Pager 4
Table of Contents
Page

1 Monitoring and troubleshooting process
Monitoring & Troubleshooting Methods
Criteria Definition
Observation
Analysis
Correction
Validation
2 Define Performance Reports
High level reports
Troubleshooting reports
RNC panel
Cell panel
Recommendations
End of Module
35


Section 3 Pager 5
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

36


Section 3 Pager 6
1 Monitoring and troubleshooting

process
37


Section 3 Pager 7
Monitoring & Troubleshooting Methods
Data Retrieve
Definition
Engineering
Criteria Definition
Implementation
Counters
Metrics
Reports
Alarms
Hourly / Busy Hour, Daily, Weekly
Alarm detection
NEs (RNC, FddCell , SGSN, )
Tool implementation: NPO for instance
Post - processing solution: Excel, Access
Automatization
Observation
Monitoring Process
Monitoring Setup
The basic method for monitoring is based on a detection method
!
Analysis
O&M
Correction
O&M
Validation
38

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 doesnt fit the required
performances:
Performances not in accordance with the operators 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.

Section 3 Pager 8
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.
39


Section 3 Pager 9
Observation has to be achieved on a daily basis
Results
Monitoring Process
Observation
Observation
Analysis
O&M
Correction
O&M
Validation
must be compared every day
Monitoring has to be executed according to top to bottom approach
Customer complaints
3 10

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.

Section 3 Pager 10
The aim of KPIs analysis is to:
Detect possible network problems
Monitoring Process
Analysis
Observation
!
Analysis
O&M
Correction
O&M
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
3 11

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

Section 3 Pager 11
After Analysis solutions could be proposed
Monitoring Process
Correction
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 )
3 12

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.

Section 3 Pager 12
Validation occurs after corrective action implementation:

Monitoring must show that the problem has disappeared
Monitoring has to confirm that the other parts of the network
have not been degraded by the correction action: no side
effects
Monitoring Process
Validation
Observation
!
Analysis
O&M
Correction
O&M
Validation
It must be observed during several days

3 13

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.

Section 3 Pager 13
3 14


Section 3 Pager 14
High level reports

Type
Observation
Period
Granularities
Weekly Evolution
One Month
Network/per week
Report
Executive panel
Executive panel
Daily Evolution
One Week
Network / per day
RNC panel
Weekly Evolution
One Month
per RNC / per week
RNC panel
Daily Evolution
One Week
per RNC / per day
Comment
The objective of this report is to give an overview of the
networks performances over several weeks
The objective of this report is to get an overview of the
networks behaviour during the last week
The objective of this report is to give an overview of the RNCs
performances over several weeks
The objective of this report is to have a global view (RNC level).
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
Cell panel
Daily evolution
One Week
per FddCell/ one day
Warning: In case of Multi-Layer, some metric can only make

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

3 15

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.

Section 3 Pager 15
Troubleshooting reports
Report
Type
RRC
Daily evolution
RRC
Top N
RRC
Observation
Period
Granularities
one week
per RNC/ Day
one day
per FddCell/ one day
Daily evolution
one week
per FddCell / day
Iu SCCP
Daily evolution
one week
per RNC/ Day
Iu SCCP
Hourly evolution
one day
per RNC/ hour
Criteria (Top N/other)
Comment
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
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 RRC Connection
Establishment Failure rate
is the worst.
The objective of this report is to identify the FddCells that

would have potential RRC connections establishment issues.
Use the N FddCells that

were filtered by the
previous TOP N report.
The objective of this report is to verify that the potential RRC

connections establishment issues identified by the TOP N report
were real (and need deeper investigations) or not.
The objective of this report is to focus on SCCP connections and
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 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.
RAB Management
Daily evolution
one week
per RNC/ Day
The RAB Assignment Analysis aims at determining at RNC level:

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

attempted each time the RNC tries to allocate traffic resources
to a UE to perform a voice and/or data call, etc.
Radio Bearer
Top N
one week
per RNC/ Day
Radio Bearer
Daily evolution
one week
per FddCell / day
Top N
one week
per FddCell
Radio Bearer Blocking
fddcells Radio Bearer

Success rate is worst
This report helps to identify the fddcell to monitor with the

following report
This report help to know it the traffic radio bearer is ok
attempted each time the RNC tries to allocate traffic resources
to a UE to perform a voice and/or data call, etc for an specific
fddcee
fddcell
Top Blocking rate fddcells
Track of most Blocked cells
These reports are used for specific investigations

3 16


Section 3 Pager 16
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
3 17

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.

Section 3 Pager 17


for this module
3 18


Section 3 Pager 18
End of Module
Module 1
3 19


Section 3 Pager 19
Section 4
Network Accessibility Monitoring
Module 1
9300 WCDMA

Section 4 Pager 1
Blank Page
42

Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2009-03-18
Chatila, Rayan
Charneau, Jean-Noel
Corrections of counters and indicators numbers,

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

Section 4 Pager 2
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
43


Section 4 Pager 3
44


Section 4 Pager 4
Table of Contents
1 Accessibility analysis
Reminder Call Establishment (Cell-DCH case) Flow
Accessibility issues causes
2 RRC Connection Phase
RRC Connection
RRC Connection Success: call flow
RRC Connection Success: counters
RRC connection attempt during cell reselection
RRC Connection Preparation Failure
RRC Connection Execution Failure
RRC Connection : Counter Tree
RRC Connection Success Rate
3 RRC Troubleshooting
RRC Accessibility analysis
Example: RRC Failure Cause Analysis
RRC Connection / RF Conditions Analysis / DL Quality
RRC Connection / RF Conditions Analysis / DL Level
RRC Connection / RF Conditions Analysis / UL Radio Load
RRC Connection / RF Conditions Analysis / UL Cell Load
RRC Connection / RRM Capacity Analysis
Case Analysis
Case Analysis: Burst of RRC failures in an area of few cells
Case Analysis: Burst of RRC failures in
an area of few cells
45
CaseAccessibility
Analysis:
Network
Monitoring Burst of RRC failures in an area of few cells
RRC
Burst of failures (summary)
4 Radio Link Management
Reminder
4.1 VS.RadioLinkSetupUnsuccess
4.2 Radio Link Reconfiguration Prepare
5 RAB Establishment and Troubleshooting Analysis
RAB Assignment Flow: Exercise
RAB Assignment Success: counters (1/3)
VS.RadioBearerEstablishmentUnsuccess:
RAB Assignment Preparation Failure
RAB Assignment Execution Failure
RAB Assignment: RNC Counter Tree
RB Establishment: Cell Counter Tree
RAB Assignment Success Rate (RNC level)
RB To Be Setup Success Rate (Cell level)
RAB Analysis: Failure analysis
6 IuSCCP Troubleshooting Analysis
Exercise: Success Rates Initiated by the RNC
Exercise (contd): Success Rates Initiated by the RNC
SCCP Connection: Success Flow
SCCP Connection: Failure Flow
SCCP Connection : Counter Tree
Iu SCCP Analysis (success rates initiated by the RNC)
Iu SCCP analysis method
Case Study
Example (1/2): IuSCCP analysis
7 Security Mode Troubleshooting Analysis
Security Mode Success: Flow

Section 4 Pager 5
Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
23
24
25
26
27
28
29
30
31
32
33
34
35
36
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

Page

Security Mode Failure: RNC
Security Mode Failure: UE
Security Mode Command Success Ratio
Ciphering analysis
8 Call Setup Success Rate Troubleshooting Analysis
Exercise
Exercise
Call Set Up Success Rate
Accessibility Troubleshooting Chart
Case Study
Case Study : Accessibility Monitoring & Troubleshooting
End of Module
46


Section 4 Pager 6
65
66
67
68
69
70
71
72
73
74
75
76
77
47


Section 4 Pager 7
Reminder Call Establishment (Cell-DCH case) Flow

UE
Node B
RNC
CN
RRC Connection Request

Radio Link Setup Request
RRC Connection Phase
Radio Link Setup Response

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
RAB establishment Phase
Radio Bearer Setup

Radio Bearer Setup Complete
48
RAB Assignment Response


Section 4 Pager 8
Accessibility issues causes

Degradation of Accessibility KPIs

Radio problems
n methods
Investigatio
pters
in next cha
Capacity
HW problems
49
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.

Section 4 Pager 9
4 10


Section 4 Pager 10
RRC Connection
Logical
connection between UE and UTRAN.

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

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.

Section 4 Pager 11
RRC Connection Success: call flow

UE
Node B
RNC
CCCH / RACH / PRACH
RRC connection

CCCH / FACH /
SCCPCH

Measurement Control
DCCH / DCH /
DPDCH+DPCCH
4 12

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

Section 4 Pager 12
RRC Connection Success: counters

FDDCell counters
UE
Node B
RNC
RRC connection

#409
#419
First RRC Connection
Request

#416
Measurement Control
4 13
#403
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
Reserved
Alcatel-Lucent
@@YEAR
Note about UE RRC connection request: if All
thisRights
request
does not
reach the RNC
it is impossible to measure it.
Section 4 Pager 13
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
4 14

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

Section 4 Pager 14
RRC Connection Preparation Failure

FDDCell counter
UE
Node B
RNC
CAC failure
Or
RNC Overload
RRC Connection Reject (wait time)
RRC connection
#404 RRC Connection Reject

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

MO Conversational or Emergency call
a blind 2G neighbor cell is declared
4 15

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

Section 4 Pager 15
RRC Connection Execution Failure

FDDCell counter
UE
Node B
RNC
CAC success
RRC connection
#404 RRC Connection Failure

[screening 0 and 14]
4 16
T352 expiry

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)

Section 4 Pager 16
RRC Connection : Counter Tree

FDDCell counters
Request
#409 and #419
RRC.AttConnEstab
VS.FirstRrcConnectionRequest
Preparation failure
Setup
#404[all screenings except 0 & 14]
#416
VS.RrcConnectionSetup
RRC connection
RRC.FailConnEstab
Execution failure
Success
#404[0] + #404[14]
#403
RRC.FailConnEstab
4 17


Section 4 Pager 17
RRC.SuccConnEstab
RRC Connection Success Rate

FDDCell metrics
System view
URRC003_CR_Calls
#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]
User View
URRC013_CR_Calls
#403.[0,1,2,3,4,5,6,7,8,9,14,16,17,19]
RRC connection
RRC connection success rate =

(calls only)
4 18
#419.[0,1,2,3,4,5,6,7,8,9,14,16,17,19]

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

Section 4 Pager 18
4 19


Section 4 Pager 19
RRC Accessibility analysis

RRC Accessibility Analysis
RRC failure cases
RRC establishment
failure cases
First Radio Link
RRC Connection
failure causes
distribution
#404[cause]
RRC Connection
failure cases
distribution
per type of call
#409 - #403[call]
1st RL Setup
failure causes
distribution
#41[cause]
4 20
Cell Inactivity
RRC Sleepy Cell

Inactivity
#15

In case of RRC failures its not possible to differentiate simultaneously the failure cause and the service cause
Two parallel analysis are necessary to correlate failure cause with the failure service cause:

Failure cases analysis: Distribution of the failure causes screenings
Establishment failure analysis: which RRC establishment causes (Originating / Terminating Traffic Classes,
conversational, I / B) failed
Problem Detection: RRC CSR lower than a threshold

RRC accessibility troubleshooting:
RRC failure causes distribution
RRC establishment failure cases (per RRC request cause)
First Radio Link
Failure Establishment cause
RRC Cell inactivity
VS.RadioLinkFirstSetupFailure - #41
the number of failures on the first Radio-Link setup. This excludes Radio link setups for soft handover.
A set of subcounters screened on:
Sub-Counter #0 : RadioLinkSetupFailure Sub-Counter #1 : Timeout
Sub-Counter #2 : RRM refusal
Sub-Counter #3 : IubLayerCongestion
Sub-Counter #4 : NodeBCEMLackL1Rsrc
Sub-Counter #5 : LackCidOrUdpPortIub
Sub-Counter #6 : LackBwthIub
Sub-Counter #7 : InodeRefusal
Sub-Counter #8 : NodeBOutOfOrder
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.
Section 4 Pager 20
Example: RRC Failure Cause Analysis

RRC Connection success rate
RNC level
Refer to the RRC
Connection failures
counters (#404)
For one/several RNC
RRC CSR
URRC013 < Th
RRC failure cases
RRC establishment
failure cases
First Radio Link
Cell Inactivity
Top N Cells
RRC Connection Failure rate
Determine the worst period
during the day
High nb of
Failure Time out
High nb of
No answer
from the NodeB
High nb of
UE Ec/No lower
than qQualityMin
High nb of
UL RSSI
High nb of
Failure Dl Power
High nb of
Failure Dl Codes
DL RF condition
UL RF condition
RF tuning of
- RRC timers analysis
- Common power channel
- Cell Reselection parameters
RF Conditions Analysis
Cell level
4 21
RRM Capacity Analysis

Cell level

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)

Section 4 Pager 21
Example: RRC Failure Cause Analysis [cont.]

RNC level
Refer to the RRC
Connection failures
counters (#404)
For one/several RNC
RRC CSR
URRC013 < Th
RRC failure cases
RRC establishment
failure cases
First Radio Link
Cell Inactivity
Top N Cells
RRC Connection Failure rate
Determine the worst period
during the day
High nb of
Unavailable FACH
Resources
High nb of
CAC
High nb of
Unavailable RRC
oontext resources
High nb of
Lack of C-RNTI
High nb of
Failure Overload
Overload parameter
tuning. Correlation
with TMU load
Capacity Analysis
4 22
High nb of
3G to 2G Redirection
for Emergency Calls
High nb of
CELL FACH CAC
Feature 3G 2g
redirection speech
calls-RRC redirect
High nb of
Unspecified
Cell stability
analysis
Alarm correlation/
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

Section 4 Pager 22

FDDCell counter
CPICH Ec/N0
#1001.[0,1]
#1001.[0,1,2,3]
RNC
CPICH
[0]
VS.IrmcacDistributionEcN0 #1043
-24dB
[1]
-15dB
[2]
-13dB
[4]
[3]
-11dB
-7dB
0dB
UCell007_C_Min24tomin15
RRC connection
#1043.[0]
Distribution
=
Distributionof
ofEc/N0
Ec/N0[-24,-15[
[-24,-15[ =
4 23
#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

Section 4 Pager 23

Reference FDDCell counter
CPICH RSCP
#1001.[0,1]
#1001.[0,1,2,3]
RNC
CPICH
VS.IrmcacDistributionRscp #1158
[0]
-120dBm
[1]
-110dBm
[2]
-105dBm
[3]
-95dBm
[4]
-80dBm
-25dBm
RRC connection
#1158.[0]
Distribution
=
Distributionof
of RSCP
RSCP[-120,-110[
[-120,-110[ =
4 24
#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

Section 4 Pager 24

FDDCell counter
VS.RadioWBandRxMainPwr #10201
VS.RadioWBandRxDivPwr #10202
NBAP Common Measurement

UL RTWP
VS.UplinkRssi #303
RTWPmeas
(#10201 + #10202)
2
UL RSSI
Traffic
+ Interference
RTWPref
Noise Factor +
Thermal Noise
UULOAD002_CR_Avg
FDDCell metric
RRC connection
Average
AverageUL
ULRSSI
RSSI(in(indBm)
dBm)==-112
-112++10
10xxlog10(#303.Avg)
log10(#303.Avg)
Too
Toohigh
highUL
ULRSSI
RSSIifif>>-98
-98dBm
dBm
Too
low
UL
RSSI
if
<
-112
Too low UL RSSI if < -112dBm
dBm
4 25

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.

Section 4 Pager 25

RTWPmeas
Traffic
+ Interference
UL RSSI
cell load
RTWPref
Noise Factor +
Thermal Noise
UULOAD001_CR_x ; x = Min or Max or Avg
RRC connection
Minimum Uplink Cell Load
#10211.Min / 1000
Maximum Uplink Cell Load = #10211.Max / 1000

Average Uplink Cell Load
4 26
#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
Noise Rise (dB) = RoT
16
14
12
10
8
6
4
2
0
0.1
0.2
0.3
0.4
0.5
0.6
UL load (%)
0.7

Section 4 Pager 26
0.8
0.9
RRC Connection / RRM Capacity Analysis

FDDCell counter
Channelization Code shortage
VS.IRMTimeFreeDlCodesBySpreadingFactor #1126
[0]
[1]
[2]
[3]
[4]
SF4
SF8
SF16
SF32
[5]
[6]
SF64 SF128 SF256
Sub-counter #5 => SF = 128
RRC connection
SF128CodeUsage_Cell009_CR
NB
AMR
se
call ca
SF128
SF128Code
Codeusage
usage==
4 27
128 #1126.[5].Min
128

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

Section 4 Pager 27
Case Analysis

Analyse the charts given in next slides !

What could you say about RRC performances ?
4 28


Section 4 Pager 28

PS RRC Connection Success rate per RNC
105,00%
100,00%
GQ01
95,00%
GQ02
90,00%
85,00%
KQ01
80,00%
OQ01
75,00%
OQ02
70,00%
10 Oct 04
9 Oct 04
8 Oct 04
7 Oct 04
6 Oct 04
5 Oct 04
4 Oct 04
3 Oct 04
2 Oct 04
1 Oct 04
30-sept-04
29-sept-04
28-sept-04
27-sept-04
26-sept-04
25-sept-04
24-sept-04
23-sept-04
22-sept-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.
4 29


Section 4 Pager 29
PS RRC Connection Success rate in the RNC OQ02

300
120,00%
250
100,00%
100,00%
100,00%
96,97%
100,90%
100,00% 97,12%
99,43%
100,00%
100,00%
100,00%
95,70%
100,00%
80,95%
200
80,00%
64,98%
57,74%
51,09%
150
PS RRC
Connection
attempts
60,00%
51,29%
48,35%
44,55%
100
40,00%
PS RRC
50
20,00%
0,00%
Connection
success rate
5/10/04, 23:00
5/10/04, 22:00
5/10/04, 21:00
5/10/04, 20:00
5/10/04, 19:00
5/10/04, 18:00
5/10/04, 17:00
5/10/04, 16:00
5/10/04, 15:00
5/10/04, 14:00
5/10/04, 13:00
5/10/04, 12:00
5/10/04, 11:00
5/10/04, 10:00
5/10/04, 09:00
5/10/04, 08:00
5/10/04, 07:00
5/10/04, 06:00
5/10/04, 05:00
5/10/04, 04:00
5/10/04, 03:00
5/10/04, 02:00
5/10/04, 01:00
5/10/04, 00: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
4 30


Section 4 Pager 30

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, 23:00
5/10/04, 22:00
5/10/04, 21:00
5/10/04, 20:00
5/10/04, 19:00
5/10/04, 18:00
5/10/04, 17:00
5/10/04, 16:00
5/10/04, 15:00
5/10/04, 14:00
5/10/04, 13:00
5/10/04, 12:00
5/10/04, 11:00
5/10/04, 10:00
5/10/04, 09:00
5/10/04, 08:00
5/10/04, 07:00
5/10/04, 06:00
5/10/04, 05:00
5/10/04, 04:00
5/10/04, 02:00
5/10/04, 03:00
5/10/04, 01:00
5/10/04, 00: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
4 31


Section 4 Pager 31
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
its due only to one mobile)
Associate the PTMSI found with the IMSI, using the two files collected
4 32

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

Section 4 Pager 32
4 33


Section 4 Pager 33
Reminder
UE
Node B
#38
#39
#40
#41
RNC
VS.RadioLinkSetupUnsuccess
VS.RadioLinkAdditionUnsuccess
VS.RadioLinkReconfigurationPrepareUnsuccess
VS.RadioLinkFirstSetupFailure


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

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


Section 4 Pager 34
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
TimeOut
RrmRefusal
IubLayerCongestion
NodeBCEMLackL1Rsrc
LackCidOrUdpPortIub
LackBwthIub
InodeRefusal
NodeBOutOfOrder
Screenings correspond to failure causes
4 35

S8 is not implemented

Section 4 Pager 35
4.2 Radio Link Reconfiguration Prepare

For which user services ?
4 36


Section 4 Pager 36
4.2 Radio Link Reconfiguration Prepare [cont.]

screenings
Name
#0048 VS.RadioLinkSetupSuccess: Number of radio links successfully setup
#0049 VS.RadioLinkAdditionSuccess: Number of successful radio link addition
#0050
VS.RadioLinkReconfigurationPrepareSuccess: Number of successful

synchronized radio link reconfiguration preparation
VS.RadioLinkReconfigurationCommit: Number of radio link

#0051
reconfiguration commit
VS.RadioLinkEstablishedPerCell: Average of the number of radio link
#0052
established per cell
#0054
#0055
VS.RadioLinkSetupRequest: Number of internal events that would lead to

a radio link setup request
VS.RadioLinkAdditionReq: Number of internal events that would lead to
a radio link addition request
VS.RadioLinkReconfPrepReq: Number of internal events that would lead

#0056
to a radio link reconfiguration prepare
4 37


Section 4 Pager 37
Other
Sig
CsSpeech
CsSpeechPsDch
CsSpeechHsdpa
CsSpeechPsDchPsHsdpa
CsSpeechPsDchPsDch
CsData
CsDataPsDch
CsDataPsHsdpa
10
CsStr
11
PsDchDlDchUl
12
PsHsdpaDlEdchUl
13
PsHsdpaDchUl
14
PsHsdpaDlDchEdchUl
15
PsDchPsDch
16
PsDchPsHsdpa
4.2 Radio Link Reconfiguration Prepare [cont.]

Example
of AMR-WB for very high

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

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

Section 4 Pager 38
4
5
seconds
5 RAB Establishment and

Troubleshooting Analysis
4 39


Section 4 Pager 39
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
RAB
establsht
Internal RRM
decision to
assign resources
Radio Bearer Setup
#?
RAB assignment resp.
#?
4 40


Section 4 Pager 40

UE
Node B
RNC
#1656 Rab Establish. Requests Per RabType
CN
RAB assignment req.
RNC counter
#1652 RB to be setup
RAB
establsht
S.R.L.R. Procedure
Radio Bearer Setup
CAC success

#1657 RAB assignment success

per Requested RAB type
#1658 RAB assignment success
per Granted RAB type
#1650 RB setup success

RAB assignment resp.
RNC counters
4 41

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

Section 4 Pager 41

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,
4 42
Sub-Counter
#4: Dl is any low rate PS I/B, Ul
is any PS I/B, TC is Interative


Section 4 Pager 42

VS.RadioBearerSetupRequest
#1652: Number of Radio Bearer setup decisions (leading or not to a RB Setup,
Switch to note view
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
4 43

Sub-Counter
I/Band128
9300 WCDMA #12:
UA06 R99 PS
QoS Analysis

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.

Section 4 Pager 43
VS.RadioBearerEstablishmentUnsuccess:
Why could it fail ?
IMA = nE1
R99 over ATM
AAL2
AAL2
E1 Leased Lines
MSC
ATM Backbone
Node B
x
C
E
M
Ethernet
HSPA over IP
Low Cost
Backhaul
STM
UDP
GigE
SGSN
IP Backbone
UDP
Iur
AAL2
4 44


Section 4 Pager 44
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)
RAB establsht
RNC counter
4 45

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.
Section 4 Pager 45
RAB Assignment Execution Failure

UE
Node B
RNC
CN
RAB assignment request
Valid RAB parameters

and
CAC success
S.R.L.R. Procedure
#602[1] RB setup unsuccess
Radio Bearer Setup

Radio Bearer Setup Failure
#602
or No response from UE
#602[0] RB setup unsuccess
RAB establsht
#1662 RAB assignment setup

unsuccess
RAB assignment response

(RAB can not be established)
RNC counter
4 46

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

Section 4 Pager 46
RAB Assignment: RNC Counter Tree

RNC counters
Request
VS.RabEstablishmentRequestsPerRabType
#1656
Failure
Success
#1662
#1657
#1658
VS.RabEstablishmentSuccessPerRequestedRabType
VS.RabEstablishmentSuccessPerGrantedRabType
RAB establsht
VS.RabAssignmentSetupUnsuccess
4 47


Section 4 Pager 47
RB Establishment: Cell Counter Tree

Reference FDDCell counters
Request
VS.RadioBearerSetupRequest
#1652
Preparation Failure
Attempt
#1629
#1650 + #602
Invalid RAB params

#1629[0]
CAC failures
#1629[1-13]
Execution failure
Success
#602
#1650
VS.RadioBearerSetupUnsuccess
VS.RadioBearerSetupSuccess
RAB establsht
No answer from UE #602[0]

RB setup failure from UE #602[1]
Any other kind of failure UE #602[2]
4 48


Section 4 Pager 48
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]
RAB establsht
URAB011_R_Ps
PS
PSRAB
RABAssignment
Assignmentsuccess
successrate
rate ==#1657.[0,4-9]
#1657.[0,4-9]//#1656.[0,4-9]
#1656.[0,4-9]
4 49


Section 4 Pager 49
RB To Be Setup Success Rate (Cell level)

Reference FDDCell metrics
#1650.[1,2]
Voice
VoiceRB
RBto
tobe
besetup
setupsuccess
successrate
rate =
Video
VideoRB
RBto
tobe
besetup
setupsuccess
successrate
rate
#1652.[same screenings]
#1650.[3]
==
#1650.[0,5-16]
PS
PSRB
RBto
tobe
besetup
setupsuccess
successrate
rate==
RAB establsht
URB007_C
#1650.[all]
RB
RBto
tobe
besetup
setupsuccess
successrate
rate==
4 50
#1652.[same
URB007_C


Section 4 Pager 50
screenings]
RAB Analysis: Failure analysis

RAB assignment analysis
Network level
RAB panel RNC

level
RB panel Fddcell
level
Establishment
failure cause
RAB assignment SR
URAB011 < Th
Refer to the
distribution of
RB Establishment
Unsuccess causes
Mean RB Blocking rate

During BH > Th
e
terize th
Charac
issu
ns and
KPIs
RB blocked
due to Lack of
DL codes
RB blocked
due to Lack of
DL Power
RB blocked
due to Unspecified
reasons
Determine the RNC

with lack of DL codes
Determine the RNC

with lack of DL Power
Determine the RNC

with Unspecified reasons
PS or CS RAB
Rejected ?
PS or CS RAB
Rejected ?
PS or CS RAB
Rejected ?
PS/CS DL codes
Capacity analysis
RNC Level
PS/CS DL Power
Capacity analysis
RNC Level
PS/CS
HW Capacity analysis
RNC Level
RB blocked
due to Lack of
other resources
Iur & Iu capacity analysis

RNC Level
RAB establsht
atio
aggreg
L
IA
T
A
E, SP
e in TIM
Iub Capacity analysis

NodeB Level
4 51


Can it affect certain/all services (CS, PS, etc)?
Correlation between 2 parallel analysis

RB failure analysis per cause of failure (#0631 and #602)
RB failure analysis per type of call setup (# 0691 and #0687)
For troubleshooting.

RB blocking panel - it contains RB failure counters
Radio Bearer panel - it contains RB data per service+other metrics
Radio Link Management panel
List of counters described in the previous slides

Section 4 Pager 51
4 52


Section 4 Pager 52
Exercise: Success Rates Initiated by the RNC

1.
2.
Find the counters associated with the successful and failed SCCP connections requested
by RNC at Iu interface for CS services.
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
conn.
SCCP connection req.
4 53
SCCP connection confirm


Section 4 Pager 53
Exercise (contd): Success Rates Initiated by the RNC

With
the counters you identify at the previous step, define the following metrics:
Iu
Iu SCCP
SCCP success
successrate
rate ==
CS
CS Iu
Iu SCCP
SCCP success
success rate
rate ==
SCCP conn.
PS
PS Iu
Iu SCCP
SCCP success
success rate
rate ==
4 54


Section 4 Pager 54
SCCP Connection: Success Flow

RNC counter
UE
Node B
RNC
#548[0,1]:
successful SCCP connections
initiated by RNC at Iu interface
CN
SCCP connection request

Call
Setup
#548[2,3]:
successful SCCP connections
initiated by CN at Iu interface
SCCP conn.
4 55
2G->3G
or
3G->3G
Inter-Freq
HHO

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)

Section 4 Pager 55
SCCP Connection: Failure Flow

RNC counter
UE
Node B
RNC
#502[1,3]:
unsuccessful SCCP connections
initiated by RNC at Iu interface
CN

Call
Setup
SCCP connection refused
#502[0,2]:
unsuccessful SCCP connections
intiated by CN at Iu interface
SCCP conn.
SCCP connection refused
4 56
2G->3G
or
3G->3G
Inter-Freq
HHO

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

Section 4 Pager 56
SCCP Connection : Counter Tree

RNC counters
Request by RNC
VS.IuSccpCnxSuccess + VS.IuSccpCnxUnsuccess
SCCP conn.
#548[all] + #502[all]
Failure
Success
#502[all]
#548[all]
VS.IuSccpCnxUnsuccess
VS.IuSccpCnxSuccess
4 57


Section 4 Pager 57
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]
SCCP conn.
PS
PSIu
IuSCCP
SCCPsuccess
successrate
rate==
4 58
#548.[1,3] + #502.[2,3]


Section 4 Pager 58
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
identified as core
issue?
First RNC
in this UTRAN version release?
Yes
No investigation
needed
No
4 59
No
Yes
HW Stability Analysis
RNC MSC Interface/
RNC-SGSN Intefaces
CTg traces
Iu traces
Analysis of CR fixes
And evolution introduced
Configuration Audit
Configuration Audit
Parameter correlations
with other RNCs

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

Section 4 Pager 59
Case Study
Analyse metric graphs given bellow !

What could you say about IuSCCP performances ?

100.00%
98.00%
96.00%
94.00%
92.00%
90.00%
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
GQ02
99.00%
GQ03
98.00%
KQ02
97.00%
OQ01
96.00%
95.00%
29/09/2006
GQ01
100.00%
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
CS Iu SCCP success rate

PS Iu SCCP success rate
OQ03
OQ04
15/10/06
14/10/06
13/10/06
12/10/06
11/10/06
10/10/06
09/10/06
08/10/06
07/10/06
06/10/06
05/10/06
04/10/06
03/10/06
02/10/06
01/10/06
30/09/06
29/09/06
28/09/06
27/09/06
26/09/06
25/09/06
24/09/06
23/09/06
22/09/06
21/09/06
20/09/06
19/09/06
18/09/06
17/09/06
16/09/06
15/09/06
14/09/06
13/09/06
12/09/06
11/09/06
10/09/06
09/09/06
08/09/06
07/09/06
06/09/06
05/09/06
04/09/06
03/09/06
02/09/06
01/09/06
31/08/06
30/08/06
29/08/06
28/08/06
27/08/06
26/08/06
25/08/06
24/08/06
23/08/06
22/08/06
21/08/06

Section 4 Pager 60
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
4 60
100.00%
99.50%
99.00%
98.50%
98.00%
97.50%
97.00%
96.50%
96.00%
CS Call Setup Success Rate

PS Call Setup Success Rate

Iu SCCP PS success rate (IuSCCP006)
KQ01
OQ02
100.00%
98.00%
96.00%
94.00%
92.00%
90.00%
Iu CS or Iu PS issue? PS
Affecting all RNC/only specific RNC ?
Punctual degradation that disappear?Or degradation remains? Punctual 28/09/05
4 61


Section 4 Pager 61
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
100.00%
99.50%
99.00%
98.50%
98.00%
97.50%
97.00%
96.50%
96.00%
Iu SCCP PS success rate (IuSCCP006)
UA4.2 Operator example
100.00%
GQ01
GQ02
99.00%
GQ03
98.00%
KQ01
97.00%
KQ02
OQ01
96.00%
OQ02
95.00%
15/10/06
14/10/06
13/10/06
12/10/06
11/10/06
10/10/06
09/10/06
08/10/06
07/10/06
06/10/06
05/10/06
04/10/06
03/10/06
02/10/06
01/10/06
30/09/06
29/09/06
28/09/06
27/09/06
26/09/06
25/09/06
24/09/06
23/09/06
22/09/06
21/09/06
20/09/06
19/09/06
18/09/06
17/09/06
16/09/06
15/09/06
14/09/06
13/09/06
12/09/06
11/09/06
10/09/06
09/09/06
08/09/06
07/09/06
06/09/06
05/09/06
04/09/06
03/09/06
02/09/06
01/09/06
31/08/06
30/08/06
29/08/06
28/08/06
27/08/06
26/08/06
25/08/06
24/08/06
23/08/06
22/08/06
21/08/06
Iu CS or Iu PS issue? PS
Affecting all RNC/only specific RNCAll
RNCs
Punctual degradation that disappear?Or
degradation remains? Punctual 28/09/05
4 62
To correlate with O&M

tracking event:
Upgrades/outages/alarms
in PS Core Network


Section 4 Pager 62
OQ03
OQ04
7 Security Mode Troubleshooting

Analysis
4 63


Section 4 Pager 63
Security Mode Success: Flow

Node B
RNC
CN

Measurement Control
SCCP connection req.
SCCP
conn.
RRC connection
UE

Security mode command
Security
mode

Common id
Security mode complete
#701[0,1]
successful Security Mode procedures
4 64
Security mode complete

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

Section 4 Pager 64
Security Mode Failure: RNC

RNC counter
UE
Node B
RNC
CN

#702[0,1]
rejected Security Mode procedures
Security mode reject
Security mode
Cause =
"Requested Ciphering
and/or
Integrity Protection Algorithms
not Supported"
4 65

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

0 : SMC on Iu-CS
1 : SMC on Iu-PS

Section 4 Pager 65
Security Mode Failure: UE

UE
Node B
RNC
CN

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

2nd
case
No answer from UE
Security mode
#703[0,1]
failed Security Mode procedures
Cause =
"Failure in the Radio Interface Procedure
RNC counters
4 66

VS.FailedRrcSmc #703: This counter provides the number of failed RRC Security Mode Command procedures
screened by Core Network domain.
Screening:

0 : SMC on Iu-CS
1 : SMC on Iu-PS

Section 4 Pager 66
Security Mode Command Success Ratio

RNC metrics
USMC002_R_Cs
Core
CoreCS
CS
Security
SecurityMode
Mode
Cmd
success
Cmd successratio
ratio
#701.[0]
#701.[0] + #702.[0] + #703.[0]
USMC002_R_Ps
#701.[1]
#701.[1] + #702.[1] + #703.[1]
Security mode
Core
CorePS
PS
Security
SecurityMode
Mode
Cmd
success
Cmd successratio
ratio
4 67


Section 4 Pager 67
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 not 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.
4 68


Section 4 Pager 68
8 Call Setup Success Rate

Troubleshooting Analysis
4 69


Section 4 Pager 69
Exercise
Using the formerly defined metrics define the Call Setup Success
Rate formula !
Call
Call set
setup
up
success
success rate
rate
4 70


Section 4 Pager 70
Exercise
This page is intentionally left blank
4 71


Section 4 Pager 71
Call Set Up Success Rate
Call
Call set
setup
up
success
success rate
rate
CS
CS
RNC metrics
URRC013_CR_Cs
x UIuSCCP006_R_Cs
x URAB011_R_Cs
URRC013_CR_Cs = RRC connection success rate for CS calls only

UIuSCCP006_R_Cs = Iu SCCP success rate
URAB011_R_Cs = RAB establishment success rate per requested RAB
Security mode
SCCP conn.
RRC connection
UCSSR005_R_Cs
UCSSR005_R_Ps
RAB establsht
Call
Call set
setup
up
success
success rate
rate
PS
PS
4 72
URRC013_CR_Ps
x UIuSCCP006_R_Ps
x URAB011_R_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.

Section 4 Pager 72
Accessibility Troubleshooting Chart

Network Accessibility Analysis
RNC level
Call setup success rate

UCSSR005_R < Th
No
Yes
Low CSSR with Ciphering
Low
SMC success rate
SMC002
RRC Connection
Success rate
Iu SCCP Connection
Success rate
UIuSCCP006 < Th
URRC0013 < Th
Yes
RAB Assignment Success rate

URAB011 < Th
No
Top N Cells
CSSR
Ciphering Analysis
RNC level
Iu SCCP Analysis
RNC level
CTg Analysis
Cell level
RAB Assignment Analysis
RNC level
RRC Connection Analysis

RNC/ Cell level
4 73

1. Check the sub-metrics which CSSR is made to identify from which one is coming the decrease.

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, its 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 its 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
Section 4 Pager 73
Case Study

Analyse metric graphs given bellow !

What is your conclusion ?
100.00%
98.00%
96.00%
94.00%
92.00%
90.00%
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
100.00%
99.00%
98.00%
97.00%
96.00%
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
PS RRC Connection success rate
CS RRC Connection success rate
PS First RRC Connection success rate
CS First RRC Connection success rate
4 74

100.00%
99.00%
98.00%
97.00%
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
96.00%
PS RAB Establishments success rate RAB type

CS RAB Establishments success rate RAB type
100.00%
99.50%
99.00%
98.50%
98.00%
97.50%
97.00%
96.50%
96.00%
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006

Section 4 Pager 74
Case Study : Accessibility Monitoring & Troubleshooting
100.00%
98.00%
100.00%
96.00%
99.00%
PS RRC Connection success rate
CS RRC Connection success rate
PS First RRC Connection success rate
CS First RRC Connection success rate
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
100.00%
99.50%
99.00%
98.50%
98.00%
97.50%
97.00%
96.50%
96.00%
PS RAB Establishments success rate RAB type

CS RAB Establishments success rate RAB type

4 75
29/09/2006
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
97.00%
13/09/2006
98.00%
11/09/2006
99.00%
09/09/2006
29/09/2006
100.00%
96.00%
27/09/2006
25/09/2006
23/09/2006
21/09/2006
19/09/2006
17/09/2006
15/09/2006
13/09/2006
11/09/2006
09/09/2006
07/09/2006
05/09/2006
03/09/2006
01/09/2006
07/09/2006
96.00%
05/09/2006
97.00%
90.00%
03/09/2006
98.00%
92.00%
01/09/2006
94.00%


Section 4 Pager 75


for this module
4 76


Section 4 Pager 76
End of Module
Module 1
4 77


Section 4 Pager 77
Section 5
Call Management
Monitoring
Module 1
9300 WCDMA

Section 5 Pager 1
Blank Page
52
Call Management Monitoring

Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2009-03-18
Chatila, Rayan
New section to include counters and indicators

for the 2 new UA6 features:
- Preemption process for DCH and HSxPA
- RRC connection re-establishment
02
2009-04-10
Charneau, Jean-Noel
Replace CellFACH002 indicator by

VS.NbrCellUpdates counter in a formula

Section 5 Pager 2
Module Objectives
Describe the main UA06 counter and Indicators changes for the 2 new UA6
fdeatures:
Preemption process for DCH and HSDPA/HSUPA
RRC connection re-establishment
53


Section 5 Pager 3
54


Section 5 Pager 4
Table of Contents
Page
1 Pre-emption
1.1 Principles
1.2 New Counters
1.3 Set of New Indicators
2 RRC Connection Re-establishment
2.1 Example of re-establishment UL Flow in Cell_DCH
2.2 New Counters
2.3 New Indicators
Self-assessment on the Objectives
End of Module
55


Section 5 Pager 5
7
8
9
11
12
13
14
15
16
17

56


Section 5 Pager 6
1 Pre-emption
57


Section 5 Pager 7
1 Pre-emption
1.1 Principles
58


Section 5 Pager 8
1 Pre-emption
1.2 New Counters
59


Section 5 Pager 9
1 Pre-emption
1.2 New Counters [cont.]
5 10


Section 5 Pager 10
1 Pre-emption
1.3 Set of New 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]
5 11


Section 5 Pager 11
5 12


Section 5 Pager 12
2.1 Example of re-establishment UL Flow in Cell_DCH

UE
Node B
UL RL failure
detected
RNC
RL Failure Ind.
CS-CN
UL RLC Unrecoverable
Error detected
Radio Link Deletion Req

DL RL failure
or
RLC Unrecoverable
Error detected
PS-CN
Radio Link Deletion Resp
RNC suspends
RLC & MAC,
Starts Timer
ALCAP Release
Cell Update
RNC stops
Timer
radio link failure or RLC unrecoverable error
Radio Link Setup
RNC resumes
RLC, MAC
Radio Link Setup Resp

ALCAP & FP Sync.
Cell Update Confirm
Radio Bearer Reconfiguration Complete
5 13

Conditions and procedures for the feature application

Section 5 Pager 13
2.2 New Counters
Counters for RRC connection re-establishment Monitoring

Counter
Id
New
# 57
New
# 58
Counter name
Location
Description
Screening
Screening 0 : Other
Number of attempt of
Screening 1 : Uplink Radio Link Failure
Reference RRC Cell Update for Screening 2 : Downlink Radio Link Failure
RRC connection reVS. RrcReEstablishmentAttempt
Cell
Screening 3 : Uplink RLC Unrecoverable Error
establishment
Screening 4 : Downlink RLC Unrecoverable
procedure
Error
Screening 0 : Other
Number of successfull Screening 1 : Uplink Radio Link Failure

Reference RRC connection re- Screening 2 : Downlink Radio Link Failure
VS.RRCReestablishmentSuccess
establishment by RRC Screening 3 : Uplink RLC Unrecoverable Error
Cell
Cell Update
Screening 4 : Downlink RLC Unrecoverable
Error
5 14


Section 5 Pager 14
2.3 New Indicators

Indicators for RRC connection re-establishment Monitoring
Metrics
proposal
Metrics Definition
Location
Already exist ?
Iu-CS call drop

rate
VS.IuAbnormalReleaseRequestCs /
VS.IuReleaseCompleteCs
FDDCell
Yes
Iu-PS call drop

rate
VS.IuAbnormalReleaseRequestPs /
VS.IuAbnormalReleaseRequestPs +
VS.DownsizingStep2Success +
VS.RadioBearerReleaseSuccess
FDDCell
Yes
Cell Update
Failure
distribution
Definition: Number of Cell Update failure by cause

vs Total Cell Update failure
Formula: VS.NbrCellUpdates[Cell Update failure
cause i] / VS.NbrCellUpdates[all screenings]
Definition : This metrics shows the success rate of

the 33821 RRC Reestablishment feature
RRC
Reestablishmen Formula : VS.RRCReestablishmentSuccess [RRC
t Success rate Screenings] / VS. RrcReEstablishmentAttempt [RRC
Screenings]
Definition : This metrics shows the failure rate of
the 33821 RRC Reestablishment feature
RRC
Reestablishmen Formula : 1 ( VS.RRCReestablishmentSuccess [RRC
t Failure rate Screenings] / VS. RrcReEstablishmentAttempt [RRC
Screenings] )
5 15
FDDCell
New
No
New
FDDCell
No
New
FDDCell
No

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)

Section 5 Pager 15
Self-assessment on the Objectives


for this module
5 16


Section 5 Pager 16
End of Module
Module 1
5 17


Section 5 Pager 17
Section 6
Retainibility Monitoring
Module 1
9300 WCDMA
Edition 1.1

Section 6 Pager 1
Blank Page
62
Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2009-03-18
Chatila, Rayan
Corrections of counters and indicators

numbers, 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

Section 6 Pager 2
Module Objectives

Describe the retainability metric family

Analyze each metric
63

Section 6 Pager 3
64

Section 6 Pager 4
Table of Contents
1 Retainability analysis
Call Drop: Definition
Network Retainability Performance
Call Drop: RL Failure detected by RNC (1/2)
Call Drop: RLC Unrecoverable Error detected by UE on SRB
Call Drops due to UTRAN generated reasons
IuReleaseRequest causes (1/4)
Call Drop Rate: RNC level
CS Call Drop Rate: Reference FDDCell level
PS Call Drop Rate: Reference FDDCell level
Part of call drop: radio connection lost with UE
2 Retainability troubleshooting
Call Drop Rate Analysis
Retainibility issues causes
Retainability Troubleshooting
Example: Retainability Troubleshooting Chart: Failure Drop cause
Typical radio problems in a W-CDMA network
Detection of bad radio conditions
Missing neighbor - Impact
Missing neighbor Detection and solution
65
Isolated site - Impact
9300 WCDMA
UA06 R99 QoSsite
Analysis andDetection
Isolated
and solution
Radio pollution - Impact
Radio pollution - Detection and solution
End of Module

Section 6 Pager 5
Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

66

Section 6 Pager 6
67

Section 6 Pager 7
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
68
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).

Section 6 Pager 8
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
69

Section 6 Pager 9

UE
Node B
RNC
CN
FDDCell counter
Loss of UL synchro
detected on last RL
#53 Last Radio Link drops
Radio Link
Failure Indication
ueCallSpare3 timer
expiry
#576[4] Iu release request CS

#599[6] Iu release request PS
Iu Release Request
UTRAN generated reason
Iu Release Command

#595[x] Iu abnormal release request CS
#589[x] Iu abnormal release request PS
Radio Link
Deletion Req
Question:
What is the difference
between #576 & #595 ?
Radio Link
Deletion Resp
6 10
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 #7: Any PS

Section 6 Pager 10

VS.IuReleaseReqPs - #599
A set ofSwitch
subcounters
Release Request Cause PS
toscreened
notes on:
view!
Sub-Counter #0: User Inactivity
Sub-Counter #1: IU User Plane Failure
Sub-Counter #5: UE generated

signalling cnx release
Sub-Counter #7: Abnormal condition

with cause TRelocOveral expiry
Sub-Counter #10: DL RLC error on TRB
Sub-Counter #11: UL RLC error on TRB
Sub-Counter #13: Connection with

NodeB lost.
Sub-Counter #19: Cell Reselection

failure
Sub-Counter #20: UtranPagingFailure
Sub-Counter #21: Physical Channel

Re-establishment failure
VS.IuAbnormalReleaseRequestPs
- #589
6 11
Monitoring
This Retainibility
measurement
represents
the
Number
of
Iu
Release
Requests due to abnormal conditions sent towards the PS domain, when the
reference cell of these calls is located on the serving RNC.
A set of subcounters screened:
Sub-Counter #0: Other type of Call


Sub-Counter #7: TRB on cell FACH

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

Section 6 Pager 11
Call Drop: RLC Unrecoverable Error detected by UE on SRB

UE
Node B
RNC
CN
RLC failure
detected on SRB

Cell Update
RLC unrecoverable error, RLC_AM SRB
Iu Release Request
#576[8] Iu release request CS
#599[9] Iu release request PS
UTRAN generated reason
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
6 12
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 #7: Any PS

Section 6 Pager 12
Call Drops due to UTRAN generated reasons

Any Iu Release Request message sent, due to an abnormal or normal

cause, is counted in
VS.IuReleaseReqCs #576 for CS
Normal cause : screening #3 : UE generated signalling cnx release
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
6 13

Section 6 Pager 13

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
CheckFailure
In case of Ranap Security Mode integrity check activation, when

nIntegrityCheckFail (2) successive RRC connection oriented
messages decoding failed
UE generated
signalling cnx release
When the UE sends a RRC Signaling Connection Release

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

Section 6 Pager 14
Screenings
Conditions for pegging
RadioConnection
WithUeLost
In case of a single Radio Link established with the UE, when a

NBAP UL Radio Link Failure indication message is sent by the
NodeB to the RNC, because of the loss of UL synchronisation
DlRLCErrSRB
DlRLCErrTRB*
When the RNC is not receiving the UE RLC acknowledgments for

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
6 15
(*): PS cause only

Section 6 Pager 15

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

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
Timer Trelocoverall
Expiry
When a HHO fails due to RNC timer expiry (no answer from CN
nor from UE), call is drop during the HHO
No Remaining RAB
No Remaining RAB
Connection with
NodeB lost
loss of AAL2, SSCOP, NBAP RESET, RSI other than those reasons
already covered by "O&M intervention"
6 16
(*): PS cause only

Section 6 Pager 16

Screenings
Other causes
When
Release due to UTRAN

Generated Reason
Release due to UTRAN Generated Reason
Failure in the Radio

Interface Procedure
Failure in the Radio Interface Procedure
No Resource Available
Failure in Upgrading or Upsizing a RB which leads to a Call Drop
a problem occurs that is not within the described issues

nor an unspecified issue. It may happen:
During RAB Establishment phase
If no response after a HO From Utran Command message
6 17
(*): PS cause only

Section 6 Pager 17
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
= rate
CS call drop
at RNC level
UIU007_R_Cs
cell(#595[all]) + Nrc(#592[all])
#1658.[1-3]
RNC metric
UIU007_R_Ps
PS call drop rate

at RNC level
6 18
cell(#589[all]) + Nrc(#588[all])
#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 #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 #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 #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 #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
Section 6 Pager 18
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

at cell level
#595.[all]
#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
6 19

Section 6 Pager 19
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
UIU006_C_Ps
PS call drop rate
at cell level=
#589.[all]
#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)
6 20
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 #4: CS Streaming
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

Section 6 Pager 20
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
UIU022_C_Ps
PS call drop rate
at cell level=
#589.[all]
#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
6 21
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.

Section 6 Pager 21
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
Percentage of
CS calls dropped
due to RL failure
6 22
UIU012_C
#576.[4]
=
#576.[all]
A set of subcounters screened on: Reason to send Release Request CS Cause

Sub-Counter #3: UE generated signalling cnx release
Sub-Counter #5: Abnormal condition with cause TRelocOveral expiry
Sub-Counter #6: Other causes
Sub-Counter #10: Connection with NodeB lost.

Section 6 Pager 22
6 23

Section 6 Pager 23
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)

6 24

Section 6 Pager 24
Retainibility issues causes

Degradation of Retainability KPIs
DL/UL RF
Conditions
- Monitor Ec/No & RSCP

- Monitor UL RSSI
Mobility - Monitor SHO

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

-Monitor PS-FP counters
6 25

Section 6 Pager 25
Retainability Troubleshooting
Retainability Analysis
RNC level
Iu007> Th
High Call Drop Rate

at RNC levelSRB
SRB increases
CS High Call drop rate

at RNC level
UIU007_R_Cs >Th
CS Retainability
RNC level
Accessibility Analysis
RNC level
6 26
PS High Call drop rate

at RNC level
UIU007_R_Cs > Th
PS Retainability per RB
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)

Section 6 Pager 26
Example: Retainability Troubleshooting Chart: Failure Drop cause

Retainability Analysis
RNC level
CS High Call drop rate at RNC level

PS High Call drop rate at RNC level
OAM Intervention
UeGenerated
Signalling
ConnectionRelease
RepeatedIntegrity
CheckFailure
IuUserPlaneFailure
Blackberry issue?
CTg to check
Integrity
Analysis
CTg analisys
No action
Valid for C
S/PS
t CS/PS)
sereques
a
le
re
u
(I
*
9
#576*, 59
Counters:
AbnormalCondition
TimerRelocExpiry
RadioConnection
WithUeLost
DlRLCErrSRB
DlRLCErrTRB
UlRLCErrSRB
UlRLCErrTRB
3g 2g
mobility analysis
It can be correlated wtih

RL failure indication
Capacity Analysis
CPU PMCRAB
DL/UL RF analysis
DL BLER analysis
Actions:
Check TX
links, HW, etc
Quality Analysis
T360 expiry
Abnormal resource
releases
To correlate with Abnormal
release counters
SRLR parameters
Capacity analysis
Stability Analysis
PCM, RNC
Node B
Alarm correlation?
Bad DL BLER?
RB reconfiguration
success rate decrease?
#0008 all
failures
SHO analysis
6 27
Unspecified
Failure
Failures in
radio link
reconfiguration?
SHO failure metric increase?
Problem Investigation: Use the above chart as a guideline for CS or PS call drop troublesooting

Section 6 Pager 27
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.
Radio pollution
A
C
B
Missing neighbor
D
Isolated site
6 28

Section 6 Pager 28
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
6 29

Section 6 Pager 29
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
6 30

Section 6 Pager 30
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
6 31

Section 6 Pager 31
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.
A
B
6 32

Section 6 Pager 32
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.
6 33

Section 6 Pager 33
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
A
D
6 34

Section 6 Pager 34
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)
6 35

Section 6 Pager 35


for this module
6 36

Section 6 Pager 36
End of Module
Module 1
6 37

Section 6 Pager 37
Section 7
Mobility Monitoring
Module 1
9300 WCDMA

Section 7 Pager 1
Blank Page
72
Mobility Monitoring
Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2008-03-18
Chatila, Rayan
Charneau, Jean-Noel

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

Section 7 Pager 2
Module Objectives

Describe the mobility metric family

Analyze each metric
73
Mobility Monitoring

Section 7 Pager 3
74
Mobility Monitoring

Section 7 Pager 4
Table of Contents
1 Mobility Overview
Mobility overview
2 SHO Monitoring and Troubleshooting
SHO overview
SHO preparation Softer HO Cell Addition - Counters (1/2)
SHO preparation Softer HO Cell Addition - Metrics
SHO preparation Soft HO Cell Addition - Counters (1/2)
SHO preparation Soft HO Cell Addition - Metrics
SHO execution - Active Set Update - Counters
SHO execution - Metrics
SHO Analysis & Troubleshooting (1/2)
3 HHO 3G-2G Monitoring
3G-2G CS Handover Success - counters
3G-2G Global CS HHO Success Rate
3G-2G CS Handover Preparation Success - counters
3G-2G CS HO Preparation Success
3G-2G CS Handover Preparation Failure - counters
3G-2G CS HO Preparation Failure Rate
3G-2G CS Handover Execution Success - counters
3G-2G CS HO Execution Success Rate
3G-2G CS Handover Execution Failure - counters
75
3G-2G CS Handover: FDDCell Counter
Tree (Rescue case)
Mobility Monitoring
9300 WCDMA3G-2G
UA06 R99 QoS
CSAnalysis
HOandExecution
Failure Rate (reversion to 3G)
3G-2G CS HO Execution Failure Rate (call drop)
3G-3G HHO InterRNC no Iur Preparation Success - counters
3G-3G HHO InterRNC no Iur Preparation Failure - counters
3G-3G HHO InterRNC no Iur - Preparation Success Rate
3G-3G HHO InterRNC no Iur Execution Success - counters
3G-3G HHO InterRNC no Iur Execution Success Rate
3G-3G Inter-freq HHO IntraRNC+InterRNC with Iur - Success
3G-3G Inter-freq HHO IntraRNC+InterRNC with Iur - Rate
3G-3G Inter-frequency HHO - Intra-RNC Success - counters
3G-3G Inter-frequency HHO - Intra-RNC Failure - counters
3G-3G Inter-frequency HHO - Intra-RNC Failure Rate
5 HHO 3G-2G Analysis & Troubleshooting
CS 3G-2G Mobility Analysis & Troubleshooting
Summary
Action to improve the Preparation phase
Actions to improve the Execution phase
End of Module

Section 7 Pager 5
Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

76
Mobility Monitoring

Section 7 Pager 6
1 Mobility Overview
77
Mobility Monitoring

Section 7 Pager 7
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
78
Mobility Monitoring

Section 7 Pager 8
79
Mobility Monitoring

Section 7 Pager 9
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)
7 10
Mobility Monitoring

Section 7 Pager 10

UE
Node B
RNC
Measurement Report (Event 1a or 1c)
#55
Radio Link Addition
to be performed
CAC
OK
S
UCCES
Radio Link Addition Request

Radio Link Addition Response
#49
Radio Link Addition
success
FDDCell Counters
UE
Node B
RNC

CAC
NOK
RNC CAC Failure
7 11
FAILU
RE
#39.[2-7]
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 #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 #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 #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
All Rights
Reserved
Alcatel-Lucent
@@YEAR
Sub-Counter #8: NodeB out of order (No
answer)
(Screening
8 is not implemented,
is Always zero in V6.0.)
Section 7 Pager 11

UE
Node B
RNC
FAILU

CAC
OK

Radio Link Addition Failure
Node-B Failure
RE
#39.[0]
Radio Link Addition
unsuccess
FDDCell Counters
UE
Node B
RNC
CAC
OK
FAILU
RE

#39.[1]
Radio Link Addition
unsuccess
No answer
from Node-B
timer expiry
7 12
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)

Section 7 Pager 12
SHO preparation Softer HO Cell Addition - Metrics
FDDCell metric
URL027_CR
Radio
RadioLink
LinkAddition
Addition
Success
Rate
Success Rate
#49.[all]
=
#55.[all]
FDDCell metric
URL037_CR
Radio Link Addition

Blocking Rate
7 13
#39.[all except 1]
=
#55.[all]
Mobility Monitoring

Section 7 Pager 13

UE
Node B 1
Node B 2
RNC
#54
Radio Link Setup
to be performed
CAC
OK
#48
Radio Link Setup
success
SS
SUCCE
FDDCell Counters
UE
Node B 1
Node B 2
RNC
FAILU

CAC
NOK
RNC CAC Failure

7 14
RE
#38.[2-7]
Radio Link Setup
unsuccess
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 #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 #8: CS data + PS DCH
Sub-Counter #9: Cs Data + PS HSDPA
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.)
Section 7 Pager 14

UE
Node B 1
Node B 2
RNC
FAILU
RE
CAC
OK
#38.[0]
Radio Link Setup
unsuccess

Node-B Failure
Radio Link Setup Failure
FDDCell Counters
UE
Node B 1
Node B 2
RNC
FAILU
RE
CAC
OK

No answer
from Node-B
timer expiry
7 15
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)

Section 7 Pager 15
#38.[1]
Radio Link Setup
unsuccess
SHO preparation Soft HO Cell Addition - Metrics
FDDCell metric
Radio
RadioLink
LinkSetup
Setup
Success
Rate
Success Rate
URL005_CR
#48.[all]
=
#48.[all] + #38.[all]
FDDCell metric
Radio Link Setup

Blocking Rate
7 16
URL036_CR
#38.[all except 1]
=
#54.[all]
Mobility Monitoring

Section 7 Pager 16
SHO execution - Active Set Update - Counters

UE
Node B
RNC
Measurement Report (event)
SS
SUCCE
Active Set Update

Active Set Update Complete
#415
FDDCell Counters
UE
Node B
RNC
FAILU
RE

UE
Active Set Update
Node B
RNC
Active Set Update Failure

Active Set Update
No answer from UE
#402[0]
#402[1]
7 17
timer expiry
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

Section 7 Pager 17
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 ?
URL016_CR
Mean
Mean Sector
Sector #25.[0].Avg + 2x(#25.[1].Avg+#25.[2].Avg) + 3x(#25.[3].Avg+) +
==
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
7 18
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)

Section 7 Pager 18

SHO Mobility Analysis
RNC level
High SPU
RL016
Low SPU
RL016
SHO Analysis
RNC level
7 19
Check SHO Parameters settings

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

Section 7 Pager 19

SHO Analysis
RNC level
Top worst cells

Few cells?
Correlate with
Node B alarms
Top worst cells
RL Setup
Blocking Rate
URL036_CR > Th
Inter RNC SHO analysis
RL Addition
Blocking Rate
URL037_CR > Th
s
succes
itionUnuses]
d
d
A
L
R
ca
[failure
ccess
pUnsu es]
s
RL Setu
u
a
c
[failure

Cell level
CEM & Iub Capacity Analysis

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

Section 7 Pager 20
7 21
Mobility Monitoring

Section 7 Pager 21
3G-2G CS Handover Success - counters

Reference
FDDCell Counters
Decision for
3G->2G HHO
UE
Node B
RNC
CN
BSS
Measurement Report
#164[0] 3G to 2G HO detection
#1839 Iu relocation attempt
Relocation Required
Relocation Command
Handover from UTRAN Command

Handover Access
Physical information
Handover Complete
Iu Release Command
RL Deletion Reqt
successful 3G to 2G
RL Deletion Respe
relocation
#167[0]
successful 3G to 2G outgoing HO
7 22
preparation
execution
Iu Release Complete
Released
#1841[0] 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 #2: No resource available CS (CACSection
failure)
7 Pager 22
Sub-Counter #1: Service CS
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).
UHO3G2G019_C_Cs
CS
CS3G-2G
3G-2GHHO
HHO
Radio
Success
Radio SuccessRate
Rate
(Rescue)
(Rescue)
#167.[0]
#164.[0]
UHO3G2G019_R_Cs
RNC metric
CS
CS3G-2G
3G-2GHHO
HHO
Radio
Success
Radio SuccessRate
Rate =
(Rescue)
(Rescue)
7 23
cell(#167.[0]) + Nrnc(#168.[0])
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 #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)

Section 7 Pager 23
3G-2G CS Handover Preparation Success - counters

#164[0] 3G to 2G HO detection
#1839 Iu relocation attempt
UE
Node B
RNC
CN
BSS
Measurement Report
Relocation Required
RNC counter
#556[2] Iu relocation required
.
Relocation Command
#557[2] Iu relocation command
#154[0] #156[0]
HO from UTRAN command
7 24
RNC counter
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:
#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:
#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.
#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

Section 7 Pager 24
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.
7 25
Mobility Monitoring

Section 7 Pager 25
3G-2G CS Handover Preparation Failure - counters

EXERCISE: Find the two counters in the catalogue
Decision for HHO
UE
Node B
RNC
CN
BSS
Measurement Report
1st
case
Relocation Required
#???
#568[2] Relocation cancel
Relocation Cancel
TRELOCprep
expiry
No answer from CN to Relocation Required

Decision for HHO
2nd
case
Measurement Report
#558[6-9]
#???
#???
#1845[0-11]
Relocation preparation failure
Relocation Required
Relocation Preparation
Failure
CN answers NACK to Relocation Required

7 26
Mobility Monitoring
Handover failure
on the 2G side
TRELOCprep = Timer RELOcation preparation

Section 7 Pager 26
Handover
failure
3G-2G CS HO Preparation Failure Rate

UHO3G2G018_R_Cs
RNC metric
3G-2G
3G-2GCS
CSHO
HOPreparation
Preparationfailure
failurerate
rate
(Rescue+CAC
failure+Service)
(Rescue+CAC failure+Service)
#558.[5-9]
#556.[2]
FDDCell metric
3G-2G
3G-2GCS
CSHO
HOPreparation
Preparation
#164[all] (#154+#156+#158.[all])
=
failure
rate
failure rate
#164[all]
(Rescue+CAC
(Rescue+CACfailure+Service)
failure+Service)
FDDCell metric
3G-2G
3G-2GCS
CSHO
HOPreparation
Preparation
failure
rate
=
failure rate
(Rescue+CAC
(Rescue+CACfailure+Service)
failure+Service)
7 27
#1845.[all]
#1839
#1843
#1839
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
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

Section 7 Pager 27
3G-2G CS Handover Execution Success - counters

UE
Node B
RNC
CN
BSS
Relocation 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
Reference
RL Deletion Respe
relocation
FDDCell Counters
Iu Release Complete
Released
#167[x] , #168[x]
successful 3G to 2G outgoing handovers
7 28
Mobility Monitoring

Section 7 Pager 28
3G-2G CS HO Execution Success Rate

CS 3G-2G HHO
Execution Success Rate
UHO3G2G020_C_Cs
#167.[0,2,4]
=
#154[0] + #156 [0] + #158 [0,1]
RNC metric
CS 3G-2G HHO
Execution
=
Success Rate
UHO3G2G020_R_Cs
cell(#167.[0,2,4]) + Nrnc(#168.[0,2])
#154 + #155 + #156 + #157 + #158 + #159
7 29
Mobility Monitoring

Section 7 Pager 29
3G-2G CS Handover Execution Failure - counters

UE
Node B
RNC
1st
case
Relocation Command
BSS
HO Request Ack
Handover failure on the target system

Handover from UTRAN Failure
#160[x] ; #161[x]
HO From UTRAN Failure
Relocation Cancel
UE fails to connect to 2G and reverts to 3G
2nd
case
CN - CS
Relocation Command
TRelocOveral
UE fails to connect to 2G
and fails to reverts to 3G
expiry
Iu Release Request
HHO Drop
#576[5] HHO drop

7 30
HO Request Ack
Reference
FDDCell Counters
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
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

Section 7 Pager 30
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]
7 31
Mobility Monitoring

Section 7 Pager 31
3G-2G CS HO Execution Failure Rate (reversion to 3G)

UHO3G2G002_C_Cs
#160[0,1,2]
CS
CS3G-2G
3G-2GHO
HOExecution
ExecutionFailure
FailureRate
Rate =
#154[0] + #156[0] + #158[0,1]
RNC metric
CS
CS3G-2G
3G-2GHO
HO
Execution
Failure
Execution FailureRate
Rate
7 32
UHO3G2G002_R_Cs
cell(#160[0,1,2]) + Nrnc(#161[0,1])
#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)

Section 7 Pager 32
3G-2G CS HO Execution Failure Rate (call drop)
UHO3G2G024_C_Cs
Number of CS 3G2G
=
HHO drops
#154 + #156 + #158 - #160[all] - #505[1]
UHO3G2G022_C_Cs
CS 3G2G HHO
Execution Failure Rate
because of 3G Reason
#154 + #156 + #158 - #160[all] - #167[0,2,4]
=
#154 + #156 + #158 - #160[all]
3G-2G CS HO which leads

either to a Success or to a Drop
7 33
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.

Section 7 Pager 33
7 34
Mobility Monitoring

Section 7 Pager 34
3G-3G HHO InterRNC no Iur Preparation Success - counters

UE
Node B
RNC 1
CN
RNC 2
Measurement Report
#556[x]
Iu relocation required
Relocation Required
Relocation Request
RNC counter
#535[x]
Iu relocation request
FDDCell counter
Relocation Request Ack
#557[x]
Iu relocation command
Relocation Command
not counted
RNC counter
7 35
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

Section 7 Pager 35
3G-3G HHO InterRNC no Iur Preparation Failure - counters

UE
Node B
RNC 1
CN
RNC 2
Measurement Report
Relocation Required
Relocation Request
FDDCell counters
#536[x] for CS, #537[x] for PS
Iu relocation request failure
Relocation Preparation
Failure
#558[x]
Iu relocation
preparation failure
RNC counter
7 36
Relocation Request
Failure
Source side
Target side
Outgoing HHO
Incoming HHO
Mobility Monitoring
VS.IuRelocationCmdFailuresCs - #558
Number of relocation Preparation failures on CS Iu interface
A set of subcounters screened on: IU Relocation command failure causes
Sub-Counter #0 : 3G to 3G UE involved. Relocation timeout
Sub-Counter #1 : 3G to 3G UE involved. Relocation already in progress
Sub-Counter #2 : 3G to 3G UE involved. Relocation failure in target system
Sub-Counter #3 : 3G to 3G UE involved. Relocation unable to establish
Sub-Counter #4 : 3G to 3G UE involved. Other relocation failure
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 #8 : 3G-3G UE involved. 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.
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 @@YEAR
All Rights
Reserved
Alcatel-Lucent
1.1when CAC fails for then entering PS
Sub-Counter #4: 3G-3G UE involved. 3JK10061AAAAWBZZA
RRC Context CAC.Edition
Pegged
Section 7 Pager 36
reloc.
3G-3G HHO InterRNC no Iur - Preparation Success Rate

FDDCell metric
UHO3G3G002_CR_Cs
CS 3G-3G HHO
Incoming
=
Preparation
Success Rate
#535.[0,3] - #536.[0-3,8,10,12-15]
#535.[0,3]
FDDCell metric
PS 3G-3G HHO
Incoming
=
Preparation
Success Rate
RNC metric
UHO3G3G007_R_Cs
CS 3G-3G HHO
Outgoing
=
Preparation
Success Rate
#557.[0,3]
#556.[0,3]
7 37
UHO3G3G004_CR_Ps
#535.[1,4] - #537.[0-3,8,10,12-15]
#535.[1,4]
RNC metric
UHO3G3G007_R_Ps
PS 3G-3G HHO
Outgoing
=
Preparation
Success Rate
#557.[1,4]
#556.[1,4]
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.

Section 7 Pager 37
3G-3G HHO InterRNC no Iur Execution Success - counters

UE
Node B
RNC 1
CN
RNC 2
Measurement Report
Relocation Required
Relocation Request
Relocation Request Ack
Relocation Command
Radio Bearer Reconfiguration
Radio Bearer Reconfiguration Complete
Relocation Detect
#505[9] & #552[9] for CS

#506[9] & #553[9] for PS
Iu relocation command
Relocation Complete
FDDCell & Neighboring RNC

counters
RL Deln Reqt
RL
Deln
Iu Release Command
#569[x]
Iu relocation complete
Respe
Iu Release Complete
7 38
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.

Section 7 Pager 38
3G-3G HHO InterRNC no Iur Execution Success Rate

RNC metric
UHO3G3G003_R_Cs
CS
CS3G-3G
3G-3GHHO
HHOIncoming
Incoming =
Execution
ExecutionSuccess
SuccessRate
Rate
#569.[0]
cell(#0535.[0,3] - #536.[0-3,8,10,12-15])
RNC metric
UHO3G3G005_R_Ps
PS
PS3G-3G
3G-3GHHO
HHOIncoming
Incoming =
Execution
Success
Execution SuccessRate
Rate
# 569.[1]
cell(#535.[1,4] - #537.[0-3,8,10,12-15])
RNC metric
UHO3G3G003_R_Cs
CS
CS3G-3G
3G-3GHHO
HHOOutgoing
Outgoing =
Execution
Success
Rate
cell(#505.[9]) + Nrnc(#552.[9])
#557.[0,3]
RNC metric
UHO3G3G009_R_Ps
CS
CS3G-3G
3G-3GHHO
HHOOutgoing
Outgoing=
Execution
Success
Rate
7 39
cell(#506.[9]) + Nrnc(#553.[9])
#557.[1,4]
Mobility Monitoring

Section 7 Pager 39
3G-3G Inter-freq HHO IntraRNC+InterRNC with Iur - Success

Reference
FDDCell Counters
S
PS+C
UE
Target
Node B
Source
Node B
RNC
Measurement Report
RL Setup Request
RL Setup Response
RB Reconfiguration
Decision for
HHO
#174[x]
Outgoing inter-freq
HHO attempt
#176[x]
Incoming inter-freq
HHO attempt
RB Reconfiguration complete
RL Deletion Request
RL Setup Deletion Response
#175[x]
Outgoing inter-freq
HHO success
#177[x]
Incoming inter-freq
HHO success
7 40
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 interfrequency 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 interfrequency cell located either in the same RNC or in a neighbouring RNC (a Iur link is setup towards the
inter-frequency cell).

Section 7 Pager 40
3G-3G Inter-freq HHO IntraRNC+InterRNC with Iur - Rate

3G3G
3G3GInter-freq
Inter-freqHHO
HHO
Outgoing
Failure
Outgoing FailureRate
Rate
# 175.[all]
#174.[all]
3G3G
3G3GIntra-RNCHHO
Intra-RNCHHO
Incoming
IncomingFailure
FailureRate
Rate
7 41
#177.[all]
#176.[all]
Mobility Monitoring

Section 7 Pager 41
3G-3G Inter-frequency HHO - Intra-RNC Success - counters

S
PS+C
UE
Target
Node B
Source
Node B
RNC
Decision for
HHO
Measurement Report
RL Setup Request
RL Setup Response
#170[x]
Outgoing intraRNC
inter-freq HHO attempt
RB Reconfiguration
#172[x]
RB Reconfiguration complete
Incoming intraRNC
inter-freq HHO attempt
RL Deletion Request
RL Setup Deletion Response
Reference
FDDCell Counters
7 42
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.

Section 7 Pager 42
3G-3G Inter-frequency HHO - Intra-RNC Failure - counters

UE
Source
Node B
Target
Node B
RNC
Decision for
HHO
Measurement Report
RL Setup Request
RL Setup Failure
S
PS+C
UE
#171[x]
Outgoing intraRNC
inter-freq HHO failure
#173[x]
Source
Node B
Target
Node B
RNC
Incoming intraRNC
inter-freq HHO failure
Measurement Report
RL Setup Request
RL Setup Response
RB Reconfiguration
Reference
FDDCell Counters
RB Reconfiguration Failure
7 43
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.
Section 7 Pager 43
3G-3G Inter-frequency HHO - Intra-RNC Failure Rate

UHO3G3G012_CR
3G3G
3G3GIntra-RNC
Intra-RNCInter-freq
Inter-freq
HHO
Incoming
Failure
HHO Incoming FailureRate
Rate
#172.[1]
UHO3G3G011_CR
3G3G
3G3GIntra-RNC
Intra-RNCInter-freq
Inter-freq
HHO
Outgoing
Failure
HHO Outgoing FailureRate
Rate
7 44
# 173.[1-5]
#171.[1-5]
#170.[1]
Mobility Monitoring

Section 7 Pager 44
7 45
Mobility Monitoring

Section 7 Pager 45

CS 3G2G Mobility Analysis
Network level
Counters
Preparation part

RNC level
Counters

Network level
Low rate execution part 2G side

RNC level
Counters
3G 2G CS HHO Success Rate < Th
UHO3G2G019_R_Cs
HO3G2G003 and HO3G2G004
to monitor the detection.
CS 3G2GPreparation
Analysis Cell level
Counters
CTG Analysis
3G2G HHO CS preparation
failure rate
UHO3G2G018_R_Cs
CS 3G2GPreparation
Analysis Selected Cells
CTG Analysis
Determine the RNC with

High UHO3G2G018_R_Cs
CS 3G2G Preparation Analysis

RNC level
7 46
Mobility Monitoring

Section 7 Pager 46
3G-2G HHO CS execution

success rate
UHO3G2G020_R_Cs
Determine the RNC with

Low UHO3G2G020_R_Cs
CS 3G2G Execution Analysis

RNC level
3G-2G CS HHO Preparation Analysis & Troubleshooting

Preparation 3G2G CS HHO Analysis
RNC level
To determine the rejection causes
(Refer to 3GPP TS 25.413):
#0558 Iu relocation command
failures CS
High CS 3G2G Rejection

Success rate
3G2G HHO CS preparation

failure rate
UHO3G2G018_R_Cs

Success rate
due to unable to establish
due to Time out
Check Outage in Transmission Network

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

definition
Counter
Sub-c ounters

Success rate
due to Failure in Target System

TOP N Cells
Check the 2G Neighbouring

Cells capacity Analysis
Counter
To determine the worst N cells with a

representative number of Preparation
3G2G HHO Failures:
the highest number of #0109 -#0101
VS.3gto2gHoDetectionFromFddcell VS.RrcHoFromUtranCommand

Success rate
due to Other Reasons

TOP N Cells
Check the Outage in

the 2G target network identified
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
7 47
Mobility Monitoring

Section 7 Pager 47
3G-2G CS HHO Execution Analysis & Troubleshooting

3G2G CS HHO Execution Analysis
RNC level
To determine the
worst N cells with a
representative
number of HO From
UTRAN Failures:
the highest number
of CS HO From
UTRAN Failure
Low HHO 3G2G CS execution

success rate
UHO3G2G020_R_Cs
To determine the
worst N cells with a
representative
number of HO From
UTRAN Failures:
the highest number
of CS Calls drop
due to CS 3G2G
HHO
3G-2G HHO CS execution failure rate (reversion to 3G)

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

UHO3G2G022_R_Cs
3G-2G HHO CS execution failure rate (reversion to 3G)

TOP N Cells
UHO3G2G002_C_Cs
3G-2G HHO CS execution failure rate (call drop)

TOP N Cells
UHO3G2G022_C_Cs
Target 2G neighboring cells

RF condition analysis
7 48
Check the setting

of 3G2G CS HHO
Algorithm Parameters
Mobility Monitoring
The 1st step is to identify the days and the RNCs 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

Section 7 Pager 48
Summary
Could you list the main causes for HHO preparation/execution

failures ?
What actions could improve HHO preparation/execution
performances ?
7 49
Mobility Monitoring

Section 7 Pager 49
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
7 50
Mobility Monitoring

Section 7 Pager 50
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
7 51
Mobility Monitoring

Section 7 Pager 51


for this module
7 52
Mobility Monitoring

Section 7 Pager 52
End of Module
Module 1
7 53
Mobility Monitoring

Section 7 Pager 53
Section 8
Network Quality Monitoring
Module 1
9300 WCDMA

Section 8 Pager 1
Blank Page
82

Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2009-03-18
Chatila, Rayan
Charneau, Jean-Noel

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

Section 8 Pager 2
Module Objectives

Describe the quality metric family

Analyze each metric
83


Section
Section 87 Pager
Page 33
84


Section
Section 87 Pager
Page 44
Table of Contents
Page

1 Network Quality Overview
Quality Overview (1/2)
2 Network Quality Monitoring
Quality Monitoring & Troubleshooting
BLER metrics
Throughput metrics
3 RF Quality Analysis
RRC Connection / RF Conditions Analysis
DL RF analysis
UL RF analysis
End of Module
85
/
/
/
/
DL Quality
DL Level
UL Radio Load
UL Cell Load


Section 8 Pager 5
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Section
Section 87 Pager
Page 66
87


Section
Section 87 Pager
Page 77

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


Section
Section 87 Pager
Page 88

UTRAN:
Core Network parameters
RF Coverage ControlRF 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
algorithm
Actions to
improve
Quality KPIs
AO downsize
AO upsize
Server parameters
Network topology
89


Section
Section 87 Pager
Page 99
8 10


Section
Section 87 Pager
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
8 11


Section
Section 87 Pager
Page 11
11
BLER metrics
Propose
a formula for the three metrics below
Using the counters provided in the comment part

Downlink
Downlink BLER
BLERAMR
AMR
UBLER008_CR
# 1505.[1,2]
# 1505.[0,1,2]
Uplink
Uplink BLER
BLERAMR
AMR
UBLER009_CR
# 1507.[all]
# 1506.[all] + # 1507.[all]
UBLER006_CR_Ps
# 1559.[all]
Downlink
DownlinkBLER
BLERData
Data
8 12
# 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
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: 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
Sub-Counter #14: PS I/B 128kbps Sub-Counter #15: PS I/B 256kbps Sub-Counter #16: PS I/B 384kbps
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
Section 87 Pager
Page 12
12
Throughput metrics
Find
the unit of the four metrics below
Using the RNC counters catalogue

RNC metric
UTraffic024_R
Traffic
TrafficDL
DLRLC
RLCSDU
SDUThroughput
Throughput
over
RAB
allocation
over RAB allocationtime
time
80 * # 1544.[all]
cell(# 1666.cum.[all])
RNC metric
UTraffic025_R
Traffic
TrafficUL
ULRLC
RLCSDU
SDUThroughput
Throughput
over
RAB
allocation
time
over RAB allocation time
80 * # 1543.[all]
cell(# 1667.cum.[all])
UTraffic030_CR_CallType
Traffic
TrafficDL
DLRLC
RLCSDU
SDUThroughput
Throughput
=
over
RAB
activity
over RAB activitytime
timeper
perCall
CallType
Type
8000 * # 1556.[CallType]
# 1566.[CallType]
UTraffic031_CR_CallType
Traffic
TrafficUL
ULRLC
RLCSDU
SDUThroughput
Throughput
over
activity
time
over activity timeper
perCall
CallType
Type
8 13
8000 * # 1555.[CallType]
# 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
Section 87 Pager
Page 13
13
8 14


Section
Section 87 Pager
Page 14
14

CPICH Ec/N0
#1001.[0,1]
#1001.[0,1,2,3]
RNC
CPICH
[0]
VS.IrmcacDistributionEcNO #1043
-24dB
[1]
-15dB
[2]
-13dB
[4]
[3]
-11dB
-7dB
#1043.[0]
Distribution
=
Distributionof
ofEc/N0
Ec/N0[-24,-15[
[-24,-15[ =
8 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
Section 87 Pager
Page 15
15
0dB

CPICH RSCP
#1001.[0,1]
#1001.[0,1,2,3]
RNC
CPICH
[0]
VS.IrmcacDistributionRscp #1158
-120dBm
[1]
-110dBm
[2]
-105dBm
[3]
-95dBm
[4]
-80dBm
#1158.[0]
Distribution
=
Distributionof
of RSCP
RSCP[-120,-110[
[-120,-110[ =
8 16
#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
Section 87 Pager
Page 16
16
-25dBm

FDDCell counter
VS.RadioWBandRxMainPwr #10201
VS.RadioWBandRxDivPwr #10202
NBAP Common Measurement
UL RTWP
VS.UplinkRssi #303
RTWPmeas
(#10201 + #10202)
2
UL RSSI
Traffic
+ Interference
RTWPref
Noise Factor +
Thermal Noise
UULOAD002_CR_Avg
FDDCell metric
Average
AverageUL
ULRSSI
RSSI(in(indBm)
dBm)==-112
-112++10
10xxlog10(#303.Avg)
log10(#303.Avg)
Too
Toohigh
highUL
ULRSSI
RSSIifif>>-98
-98dBm
dBm
Too
low
UL
RSSI
if
<
-112
dBm
Too low UL RSSI if < -112 dBm
8 17


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
Section 87 Pager
Page 17
17

RTWPmeas
UL RSSI
Traffic
+ Interference
cell load
RTWPref
Noise Factor +
Thermal Noise
UULOAD001_CR_x ; x = Min or Max or Avg
RRC connection
Minimum Uplink Cell Load
#10211.Min / 1000
Maximum Uplink Cell Load = #10211.Max / 1000

Average Uplink Cell Load
8 18
#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
Then the UL Cell Load is UL Cell Load = 1
eDCH/HSUPA load
10-(RoT/10)
Noise Rise vs. UL load
20
18
Noise Rise (dB) = RoT
16
14
12
10
8
6
4
2
0
0.1
0.2
0.3
0.4
0.5
0.6
UL load (%)
0.7

Section
Section 87 Pager
Page 18
18
0.8
0.9
Cell level
Main and Diversity!

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

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

Deep RF study
Site Visit/Others

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
Section 87 Pager
Page 19
19
DL RF analysis
Cell level
Operator dependance
dependant
According to RF design
strategy for
forthe
thedifferent
services services
different
Top N worst cells
Correlation
with
DL indicators
Ie, higher Radio drops
High Percentage of
Bad RSCP
DL Coverage
issues
High Percentage of
Bad Ec/N0
Correlation with
High SPU (RL016)
High ASU/s (Rl020)
Also DL indicators
(see next slide)
DL Interference &/ or
DL Coverage
issues
RF control & optimization:

Tilts, Antenna Orientation,
RF parameter tuning
Avoid Pilot pollution, Slow handovers, Overshooting
Cell customization paramters for difference scenarios
(dense, rural, corner sites)
Ping-pong areas optimization
Power settings
3g2g strategy, 3g2g tuning, iRM strategy
Site densification
8 20
Note: be aware of if
FET is activated, radio
measurements can be
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
Section 87 Pager
Page 20
20
UL RF analysis
Cell level- UL RSSI
High UL RSSI
Low UL RSSI
Check correlation
RF Alarms?
Yes
No
Alarms
Yes Check correlation
RF Alarms
Apply High UL RSSI

procedures
No
Apply Low UL RSSI
procedure
Checking:
- Digital part: TRM,
CCM and CEM
- RF chain:
connectors, cables,
DDM
- Radiating system
Digital part issue?
Radiating system?
Interferences?
/jammers?
- Interferences
(jammers)
RF
chain?
connector
cables
- TMA LNA FAILED

- VSWR 1/2/3
- DDM LNA FAILED
- Any TRM/iTRM receiver
alarms such as RX
Channelizerfailures.
Checking:
- Digital part: TRM, CCM
and CEM
- RF chain: connectors,
cables, DDM
- Radiatingsystem
ACTIONS:
Replace cables,
CEM, etc
ACTIONS
8 21

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 20C) + 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
Section 87 Pager
Page 21
21


for this module
8 22


Section
Section 87 Pager
Page 22
22
End of Module
Module 1
8 23


Section
Section 87 Pager
Page 23
23
Section 9
Capacity Monitoring
Module 1
9300 WCDMA

Section 9 Pager 1
Blank Page
92
Capacity Monitoring
Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
First edition
01.1
2009-03-18
Chatila, Rayan

Charneau, Jean-Noel
Addition of new UA6 counters to better

monitor blocking and load of radio resources

Section 9 Pager 2
Module Objectives

Describe the capacity metric family

Analyze each metric
93
Capacity Monitoring

Section 98 Pager
Page 3
94
Capacity Monitoring

Section 98 Pager
Page 4
Table of Contents
1 Capacity Monitoring
UTRAN capacity analysis strategy
Reactive capacity planning
UTRAN congestion detection principles
Blocking Characterization
Capacity monitoring
Which resource can block ?
Find a counter to detect blocking of a given resource ?
2 Capacity Analysis
Capacity Analysis
Blocking and Load
3 Capacity Troubleshooting
DL Tx Power Load
DL Code Load
UL Radio Load
CEM Load
Iub Load
RNC Load
Bottleneck analysis : RB Allocation Procedure
Bottleneck analysis : Per type of call
Solve Capacity Issue
Case Study
4 Capacity Licensing Monitoring
NodeB capacity licensing
95
Capacity Monitoring
Capacity licensing counters
Capacity licensing counters screenings
CEM monitoring counter
End of Module

Section 9 Pager 5
Page
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
29
30
31
32
33
35
36
37
38
39
TableofContents[cont.]
Switchtonotesview!
96
AllRightsReservedAlcatel-Lucent@@YEAR
CapacityMonitoring
9300WCDMAUA06R99QoSAnalysisandTrafficLoadMonitoring

Section 98 Pager
Page 6
97
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
2 000 00 00 0
1 800 00 00 0
1 600 00 00 0
1 400 00 00 0
1 200 00 00 0
1 000 00 00 0
800 00 00 0
600 00 00 0
400 00 00 0
200 00 00 0
C S D L tra ffic K B y tes
8 Apr 06
15 Apr 06
1 Apr 06
25-mars-06
18-mars-06
11-mars-06
25 Feb 06
04-mars-06
18 Feb 06
4 Feb 06
P S D L Tra ffic K B y t es
11 Feb 06
28-janv-06
21-janv-06
14-janv-06
07-janv-06
31 Dec 05
24 Dec 05
17 Dec 05
3 Dec 05
10 Dec 05
26-nov-05
19-nov-05
12-nov-05
29-oct-05
05-nov-05
22-oct-05
15-oct-05
08-oct-05
01-oct-05
to tal P S + C S
Operators start to experience some congestion in their networks and foresee

further capacity issues
Two methodologies are possible

Pro-active capacity planning
98
Capacity Monitoring
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

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
99
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
Combination of blocking + load

indicators for a specific resource
Status Green
No action required
YES
3 states
Low
Load
No blocking No action
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
9 10
Capacity Monitoring

Section 98 Pager
Page 10
Status Yellow
Capacity analysis/tuning
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

setup
Call admission failure
Call
Reconfiguration
Lack of resources to
perform iRM transitions
(AON Upsize, iRM Sched
Upgrade)
Call is not reconfigured

(impact on user
throughput)
- RL Reconfiguration Unsuccess (iRM

Scheduling, RB Rate Adaptation)
- RL Setup Unsuccess (AON)
Mobility
No resources available
for additional RL
Additional RL not added

in the Active Set (risk of
call drop)
RL Setup Unsuccess
RL Addition Unsuccess
- RL & RB Reconfiguration Unssuccess
for HSDPA
9 11
Capacity Monitoring

Section 98 Pager
Page 11
RB Establishment Unsuccess
RL Reconfiguration Unsuccess
FDDCell metrics
Capacity monitoring
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
RL
RLReconfiguration
ReconfigurationBlocking
BlockingRate
Rate =
#40.[all except 1]
#56.[all]
URRC008_CR
RRC
RRCConnection
ConnectionReject
RejectRate
Rate
9 12
#404.[all except 0 ]
#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
9 13
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
Power
#1629 VS.RadioBearerEstablishmentUnsuccess.[1]
DL
Code
UL RSSI
( #404.4 RRC.FailConnEstab.RSSI, #10213 VS.FailedAdmissionDueToULload )
CEM processing
Iub Bandwidth
Iub AAL2 cid
RNC
processing
9 14
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 now counted in UA6 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
9 15
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
9 16
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)
9 17
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
9 18
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
#10216 VS.PAPowerCapacity.CumLicensing
#10216 VS.PAPowerCapacity.CumUsed
#307 VS.DistDlTtlPwrRatio
#308 VS.DlTtlTxPwrR99Only
9 19
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
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
Alcatel-Lucent
@@YEAR
Sub-Counter #2: Sum of Licensing values All Rights Reserved
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
9 20
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)
9 21
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
#1181 VS.QosUlCemLdClrRed
70 %
60 %
50 %
40 %
#1177 VS.QosDlCemLdClrYellow
#1180 VS.QosUlCemLdClrYellow
90 %
80 %
#1179 VS.QosDlCemLdCellPreemptClrCngstd
#10310 VS.LocalCellGroupLoad.FreeUL
#10310 VS.LocalCellGroupLoad.UsedUL
#10310 VS.LocalCellGroupLoad.FreeDL
#10310 VS.LocalCellGroupLoad.UsedDL
#10317 VS.R99CECapacity. AllocLicensingRefusal

#10317 VS.R99CECapacity. AllocHWfail
#10317 VS.R99CECapacity. AllocHWfail
9 22
#10301 VS.CEMUsedDCH (.Avg, .Max, Min)

#10403 VS.cpuLoad.CEM (.Avg, .Max, Min)
#10403 VS.cpuLoad.CCM (.Avg, .Max, Min)
#10317 VS.R99CECapacity.NbEvt
#10317 VS.R99CECapacity.CumHWcapacity
#10317 VS.R99CECapacity.CumLicensing
#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
9 23
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
5 Packet Server
6 Packet Server
7 Packet Server
2 Packet Server
3 Packet Server
4 Packet Server
A Not Used
0 CP3
1 CP3
13 Packet Server
14 Packet Server
15 Packet Server
10 Packet Server
11 Packet Server
B Not Used
8 OC-3/STM-1
9 OC-3/STM-1
12 Packet Server
PMC
PMC
PMC
Master
PC
TMU
PMC
PMC
PMC
RAB
RAB
RAB
Fabric
interface
Adjunct Processor
CPU load
Logical Processor
CPU load
#20103 VS.CpuUtilAvg
#20104 VS.CpuUtilAvgMin
#20105 VS.CpuUtilAvgMax
9 24
#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
Radio Link Reconfiguration Prepare
A
B
C
BTS CAC
Radio Link Reconfiguration Ready
UP / DL Synchronization
UP / UL Synchronization
AAL2 / ERQ
AAL2 / ECF
UP / Initialization
UP / Initialization Ack.
Radio Link Reconfiguration Commit
Radio Bearer Setup

8
9 25
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)
#1629.0 - VS.RadioBearerEstablishmentUnsuccess cause InvalidRabParametersValue

#1629 - VS.RadioBearerEstablishmentUnsuccess following screenings:
1 UnavailableDlCodeResources
2 UnavailableDlPowerResources
4 RlFailOrRlcErr
6 LackOfRncProcessingResources
9 LackTransportIdIu
10 LackBwthIu
11 LackTransportIdIur
12 LackBwthIur
13 LackTransportIdIur
14 LackBwthIub
4
#0056 VS.RadioLinkReconfPrepReq (set of Downlink Access Stratum)
#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 ...)
#1629.3 - VS.RadioBearerEstablishmentUnsuccess cause Unspecified
#0032 - VS.RadioLinkReconfigurationCommit (set of Downlink Access Stratum)

#0026 - VS.RadioLinkReconfigurationCancel
#0687 - VS.RadioBearerSetupSuccess (set of Downlink Access Stratum)

#0602 - VS.RadioBearerSetupUnsuccess (Failure cause)
9 26
Capacity Monitoring

Section 98 Pager
Page 26

A
#10309 CEMAlloc (enhanced in UA6.0) with following screenings:

screen id
Screen Name
Suffix 3GPP
Success
Allocation success (RL Setup or RL Reconf)
Allocation fail for RL SetUp due to lack of resources causes
FailSetup
Allocation fail for RL Reconf due to lack of resources causes
FailReconf
Allocation fail for RL SetUp, due to capacity licensing blocking
FailSetupLock
Allocation fail for RL Reconf, due to capacity licensing blocking
FailReconfLock
#10311 CEMAllocSuccessUL (new in UA6.0)

#10312 CEMAllocSuccessDL (new in UA6.0)
#10313 CEMAllocFailedUL (new in UA6.0)
#10314 CEMAllocFailedDL (new in UA6.0)
#10315 CEMAllocFailedBothUL (new in UA6.0)
#10315 CEMAllocFailedBothDL (new in UA6.0)
All these counters are pegged
screen id
on a per SF basis, indicating the
0
UL or DL SF that was rejected
1
due to lack of CEM resources :
2
9 27
Screen Name
For SF4
Suffix 3GPP
SF4
For SF8
SF8
For SF16
SF16
For SF32
SF32
For SF64
SF64
For SF128
SF128
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)
CEM Capacity Licensing counters (new in UA6.0):

#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) In restriction for iCEM in UA6.0
screen id
Screen Name
Number of events
Sum of HW installed values
Sum of Licensing values
Sum of used values
Number of successes
CumHWcapacity
CumLicensing
CumUsed
AllocSuccess
Number of refusals or restrictions due to the license
Number of refusals due to the hardware capacity
9 28
Suffix 3GPP
NbEvt
AllocLicensingRefusal
Capacity Monitoring

Section 98 Pager
Page 28
AllocHWfail
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.
9 29
Capacity Monitoring

Section 98 Pager
Page 29
Solve Capacity Issue

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

Add CEM HW resource
Transport

EBR
Add E1
RNC
PMC-TMU
No Tuning Available
Add PS-FP board

Add an RNC
Site verification
- Remove external interferer
- Repair cable, connector, TMA, TRM.
Solve UL radio pollution problem
Add a 2nd frequency
UL RSSI
9 30
Capacity Monitoring

Section 98 Pager
Page 30
Case Study
CEMUsedMax%
NodeB1_iCemUsedEvolution
CEMUsedMin%
CEMAllocFail
35
30
25
20
15
10
5
0
Day7 17:00
Day7 09:00
Day7 01:00
Day6 17:00
Day6 09:00
Day6 01:00
Day5 17:00
Day5 09:00
Day5 01:00
Day5 17:00
Day5 09:00
Day5 01:00
Day4 17:00
Day4 09:00
Day4 01:00
Day3 17:00
Day3 09:00
Day3 01:00
Day2 17:00
Day2 09:00
Day2 01:00
Day1 17:00
Day1 09:00
Day1 01:00
NodeB1
What isshows
the capacity
problem
that
canload
be reaches
observed
in
CEM blocking
whereas
iCEM
33%.
the chart above ?

hascause
3 CEMs
on the knowing
BTS but only
vcctransport
CCP is declared.
NodeB1
Find the
ofinserted
the problem
the1Iub
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
9 31
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
VCC DS traffic
VPi/VCi/PathId/QoSId
VCC NDS traffic
VCC HSDPA traffic

Section 98 Pager
Page 31
RNC
9 32
Capacity Monitoring

Section 3
9 Pager 32
NodeB capacity licensing

Node B
Per OMC capacity licenses
License keys
management
OMC
License keys
server
Spare capacity
capacity dispatched to the BTS
NodeBs capacity controlled via

licensing capacity parameters
R99 CE capacity
xTRM
xTRM
i or xCEM
Node B
Node B
MCPA
RRH
EDCH capacity
Node B
Node B
HSDPA capacity
Activation of second carrier

Remaining H/W Capacity
PA Power
RRH power
S/W allowed Capacity

9 33
Number of carriers
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 (intraOMC); 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
iCEM64
iCEM128 xCEM
H/W
H/W
H/W
+
+
+
minimum minimum minimum
CEM H/W capacity capacity capacity
Blocks of 16CE
R99 capacity
Blocks
of (8 HSDPA connections + 1.8 Mbit/s)
HSDPA
capacity
Blocks
of (8 HSUPA connections + 480 kbit/s)
HSUPA
capacity
iTRM
TRM HW iTRM
N/A
xTRM_Carriers
All RRH types

RRH H/W RRH (one carrier) + reduced power
#of additional RRH carrier
activation/NodeB (step:1)
RRH_Carriers
Blocks of 10W at RRH ouput
RRH_power
All PA types
xTRM
xTRM (one carrier)
#of second xTRM carrier
activation/NodeB (step:1)
PA + reduced power
PA H/W
Power (W) Blocks of 15W at PA output

Section 3
9 Pager 33
NodeB capacity licensing [cont.]

NodeB resources submitted to licensing
9 34
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
#10317
Name
Triggering Event
VS.R99CECapacity: R99 CE capacity installed,

licensed and used
Sampling event generated by the CCM CallP

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
9 35
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
CEM
NbEvt
Number of events
CumHWcapacity
Sum of HW installed values
CumLicensing
Sum of Licensing values
CumUsed
Sum of used values
AllocSuccess
Number of successes
AllocLicensingRefusal
Number of refusals or restrictions due to the license
AllocHWfail
Number of refusals due to the hardware capacity
PA/
RRH
Counters can be used as a ratio

between ScrX and Scr0
9 36
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
#10309
Modification
VS.CEMAlloc: Number of times allocation of CEM resources succeeded,

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

CEM resources allocation procedure
Success
Unused
FailSetup
FailReconf
FailSetupLock
FailReconfLock
Counters incremented when

CEM allocation Fails due to
licensing capacity limits
reached
9 37
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
9 38
Capacity Monitoring

Section 98 Pager
Page 38
End of Module
Module 1
9 39
Capacity Monitoring

Section 98 Pager
Page 39
10
Section 10
Traffic Monitoring
Module 1
3JK10064AAAAZZZZA Edition 1
9300 WCDMA
TMO18046 D0 SG DEN I3.0

Section 10 Pager 1
Blank Page
10 2
Traffic Monitoring
Document History
Edition
Date
Author
Remarks
01
2008-12-01
El Abed, Achrafe
Chatila, Rayan
First edition

Section 10 Pager 2
Module Objectives

Describe the traffic and call profile metric family

Analyze each metric
10 3
Traffic Monitoring

Section
Section10
9 Page
Pager33
10 4
Traffic Monitoring

Section
Section10
9 Page
Pager44
Table of Contents
Page
1 Traffic Monitoring
Network Traffic
Average Number of Calls per Day RNC metrics
Average Number of Calls per Day DL - Cell metrics
Average Number of Calls per Day UL - Cell metrics
Uplink/ Downlink PS Traffic per RNC
End of Module
10 5
Traffic Monitoring

Section 10 Pager 5
7
8
9
10
11
12
13
14
TableofContents[cont.]
Switchtonotesview!
106
AllRightsReservedAlcatel-Lucent@@YEAR
TrafficMonitoring
9300WCDMAUA06R99QoSAnalysisandTrafficLoadMonitoring

Section
Section10
9 Page
Pager66
10 7
Traffic Monitoring

Section
Section10
9 Page
Pager77
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.
10 8
Traffic Monitoring

Section
Section10
9 Page
Pager88
Average Number of Calls per Day RNC metrics

RNC metric
URAB012_R_CsVoice
Average
Averagenb
nbof
of
= #1660.[1].Avg
Voice
calls
Per
Voice calls Perday
day
RNC metric
URAB012_R_CsVideo
Average
Averagenb
nbof
of
= #1660.[2].Avg
Video
Videocalls
callsper
perday
day
RNC metric
URAB012_R_Ps
Average
Averagenb
nbof
of
= #1660.[0,4-10].Avg
Data
Datacalls
callsper
perday
day
10 9
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
Average Number of Calls per Day DL - Cell metrics

Average
Averagenb
nbof
ofDL
DL
Voice
calls
Per
Voice calls Perday
day
URB013_CR_DLCsVoice
= #1666.[2-3].Avg
Average
Averagenb
nbof
ofDL
DL
Video
Videocalls
callsper
perday
day
URB013_CR_DLCsVideo
= #1666.[4].Avg
Average
Averagenb
nbof
ofDL
DL
Data
Datacalls
callsper
perday
day
URB013_CR_DLPs
= #1666.[5-21].Avg
10 10
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
Average Number of Calls per Day UL - Cell metrics

Average
Averagenb
nbof
ofUL
UL
Voice
calls
Per
Voice calls Perday
day
URB013_CR_ULCsVoice
= #1667.[2].Avg
Average
Averagenb
nbof
ofUL
UL
Video
Videocalls
callsper
perday
day
URB013_CR_ULCsVideo
= #1667.[3].Avg
Average
Averagenb
nbof
ofUL
UL
Data
Datacalls
callsper
perday
day
URB013_CR_ULPs
= #1667.[4-16].Avg
10 11
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 #10 : PS I/B 8
Sub-Counter #15 : HSUPA
Sub-Counter #16 : TRB on cell RACH

Section
Section10
9 Page
Pager11
11
Uplink/ Downlink PS Traffic per RNC

RNC metric
UTraffic015_R_Ps
DL
DLPS
PSTraffic
Trafficper
perRNC
RNC==#1544
#1544.[6-16]
.[6-16]
RNC metric
UTraffic025_R_Ps
UL
ULPS
PSTraffic
Trafficper
perRNC
RNC==#1543
#1543.[6-16]
.[6-16]
UTraffic017_C_Ps
DL
DLPS
PSTraffic
Trafficper
perCell
Cell==#1554
#1554.[6-16]
.[6-16]
UTraffic018_C_Ps
UL
ULPS
PSTraffic
Trafficper
perCell
Cell==#1553
#1553.[6-16]
.[6-16]
10 12
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 #0: Other Dl
Sub-Counter #1: Any SRB
Sub-Counter #3: CS 64 conversational
Sub-Counter #6: PS Str 128

Sub-Counter #11: PS I/B 16kbps
Sub-Counter #9: PS Str Other
Sub-Counter #13: PS I/B 64kbps Sub-Counter #14: PS I/B 128kbps
Screenings for #1554 and #1553:

Sub-Counter #0: Other Dl
Sub-Counter #1: Any SRB
Sub-Counter #3: CS 64 conversational Sub-Counter #4: CS streaming
Sub-Counter #9: PS Str Other

Section
Section10
9 Page
Pager12
12


for this module
10 13
Traffic Monitoring

Section
Section10
9 Page
Pager13
13
End of Module
Module 1
10 14
Traffic Monitoring

Section
Section10
9 Page
Pager14
14

R99NPO TrainingCounters UA6

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

R99NPO TrainingCounters UA6

Hochgeladen von

Copyright:

Verfügbare Formate

9300 WCDMA

UA06 R99 QoS Analysis and

All Rights Reserved Alcatel-Lucent @@YEAR

All rights reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent @@YEAR

Terms of Use and Legal Notices

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent @@YEAR

4. Topic/Section is Positioned Here

5. Topic/Section is Positioned Here

6. Topic/Section is Positioned Here

4. Network Accessibility Monitoring

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

Course Outline [cont.]

All Rights Reserved Alcatel-Lucent @@YEAR

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent @@YEAR

Welcome to UA06 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

the call flow procedure

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

Course Objectives [cont.]

All Rights Reserved Alcatel-Lucent @@YEAR

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent @@YEAR

About this Student Guide

All Rights Reserved Alcatel-Lucent @@YEAR

Where you can get further information

All Rights Reserved Alcatel-Lucent @@YEAR

About this Student Guide [cont.]

Switch to notes view!

All Rights Reserved Alcatel-Lucent @@YEAR

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent @@YEAR

section you will be asked to fill this questionnaire

Surname, First name :

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

Self-assessment of Objectives [cont.]

All Rights Reserved Alcatel-Lucent @@YEAR

Thank you for your answers to this questionnaire

All Rights Reserved Alcatel-Lucent @@YEAR

Do not delete this graphic elements in here:

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

Radio Network Performance Overview

This page is left blank intentionally

All Rights Reserved Alcatel-Lucent @@YEAR

All Rights Reserved Alcatel-Lucent @@YEAR

Radio Network Performance Overview

All Rights Reserved Alcatel-Lucent @@YEAR

Module Objectives [cont.]

All Rights Reserved Alcatel-Lucent @@YEAR