Beruflich Dokumente
Kultur Dokumente
Instructor Guide
UM4801-IG.en.A4
Issue a
October 2005
This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced,
distributed, or altered in any fashion by any entity (either internal or external to Lucent Technologies), except in accordance with applicable
agreements, contracts or licensing, without the express written consent of Lucent Technologies and the business management owner of the
material.
Trademarks
All trademarks and service marks specified herein are owned by their respective companies.
Contents
........................................................................................................................................................................................................
.............................................................................................................................................
xiii
.......................................................................................................................................................................................
xiii
............................................................................................................................................................................
xiii
............................................................................................................................................................................................
xiv
Related documentation
Related training
xiii
.....................................................................................................................................................................................
xiii
How to comment
xiv
........................................................................................................................................................................................
.................................................................................................................................................................................
xv
Introduction to optimization
Overview
.........................................................................................................................................................................................................
What is optimization?
..............................................................................................................................................................................
...................................................................................................................................................................
1-2
1-4
..........................................................................................................................................................
1-6
..........................................................................................................................................................................................................
1-8
1-1
.........................................................................................................................................................................................................
2-1
Gathering information
Overview
.........................................................................................................................................................................................................
................................................................................................................................................................
2-2
2-3
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
iii
Issue a, October 2005
See notice on first page
Contents
Drive test
.........................................................................................................................................................................................................
................................................................................................................................................................................
2-6
................................................................................................................................................................................................
2-7
Customer complaints
OMC-U tools
2-4
Analyzing information
Overview
.........................................................................................................................................................................................................
............................................................................................................................................................................
......................................................................................................................................................................................................
2-9
2-12
.........................................................................................................................................................................................................
RF coverage problem
..............................................................................................................................................................................
3-1
3-2
...........................................................................................................................................................................
3-4
...........................................................................................................................................................................
3-6
.......................................................................................................................................................................................
3-8
Near-far problem
Around-the-corner problem
Handover problem
Exercises
..................................................................................................................................................................
..................................................................................................................................................................................
3-9
3-10
...............................................................................................................................................................
3-11
.......................................................................................................................................................................................................
3-13
2-8
UTRAN Signaling
Overview
.........................................................................................................................................................................................................
4-1
.........................................................................................................................................................................................................
...............................................................................................................................................................
4-3
.............................................................................................................................................
4-5
...............................................................................................................................................................................
4-7
4-2
.......................................................................................................................................................................................................
..........................................................................................................................
4-11
........................................................................................................................................................................
4-12
4-10
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
iv
Contents
...............................................................................................................................................................
4-15
......................................................................................................................................................................................................
4-18
Optimization process
Overview
.........................................................................................................................................................................................................
5-1
Lifecycle
..........................................................................................................................................................................................................
5-2
...............................................................................................................................................................
.........................................................................................................................................................
...................................................................................................................................
..........................................................................................................................................................................
5-4
5-7
5-9
5-11
............................................................................................................................................................
5-13
..............................................................................................................................................................
5-16
...........................................................................................................................................................................
5-18
..............................................................................................................................................................................
5-19
.......................................................................................................................................................................................................
5-20
Information gathering
Information analysis
Exercises
.........................................................................................................................................................................................................
6-1
Call availability
Overview
.........................................................................................................................................................................................................
Call availability
...........................................................................................................................................................................................
6-3
6-4
........................................................................................................................................
6-6
.........................................................................................................................................................................................................
6-7
Introduction
....................................................................................................................................................................................................
..................................................................................................................................................
..............................................................................................................................................................................................
.....................................................................................................................................................................
6-8
6-9
6-10
6-12
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
v
Issue a, October 2005
See notice on first page
Contents
...................................................................................................................................................
6-14
.......................................................................................................................................................................................................
....................................................................................................................
6-18
.......................................................................................................................................................
6-20
.......................................................................................................................................................................
6-21
..........................................................................................................................................................
6-23
...........................................................................................................................................................................................
6-26
6-17
.......................................................................................................................................................................................................
Introduction
.................................................................................................................................................................................................
6-29
6-32
...............................................................................................................................................
6-33
.............................................................................................................................................
6-34
..............................................................................................................................................................................
6-35
.........................................................................................................................................................................................
6-36
......................................................................................................................................................................................................
6-37
No answer from UE
Code starvation
Exercises
7
.....................................................................................................................................................
6-28
Call reliability
Overview
.........................................................................................................................................................................................................
..........................................................................................................................................................................
7-5
..............................................................................................................................
7-6
.......................................................................................................................
7-8
.........................................................................................................................................................
7-9
7-2
..............................................................................................
7-1
.............................................................................................................................................................
.....................................................................................
7-11
................................................................................................................................
7-12
7-10
........................................................................................................
7-13
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
vi
Contents
Failures on RLC
.......................................................................................................................................................................................
.................................................................................................................................................................
7-18
.......................................................................................................................................................................................................
7-19
.........................................................................................................................................................................................................
...............................................................................................................................................................
....................................................................................................................................................
8-1
8-2
8-4
.............................................................................................................................................
8-6
.......................................................................................................................................................................
8-8
7-16
...................................................................................................................................................
7-14
.......................................................................................................................................................................................................
8-11
.........................................................................................................................................................................................................
9-1
Soft/Softer Handover
Overview
.........................................................................................................................................................................................................
................................................................................................................................
Poor RF conditions
9-5
................................................................................................................
9-8
.................................................................................................................................................................................
......................................................................................................................................................................
9-10
9-11
................................................................................................................................................................
9-12
...........................................................................................................................................................................................
9-13
.......................................................................................................................................................................................................
9-14
9-4
......................................................................................................
9-3
.....................................................................................................................................................................
...................................................................................................................................
........................................................................................
9-17
9-18
.........................................................................
9-20
.......................................................................................
9-21
9-16
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
vii
Issue a, October 2005
See notice on first page
Contents
.......................................................................................................................................................................................................
..............................................................................................................................
9-23
..................................................................................................................................................................................
9-25
9-22
............................................................................................................................................................
9-26
.................................................................................................................................................................
9-30
9-31
........................................................................................................................................................................
9-32
..........................................................................................................................................................................
9-34
......................................................................................................................................................................................................
9-36
Exercises
10
.......................................................................................................................................................................................................
.......................................................................................................................................................................................................
10-1
.......................................................................................................................................................................................................
10-3
KPI for Mobile-originated end-to-end call setup in the Circuit Switched domain
........................................
10-4
KPI for Mobile-terminated end-to-end call setup in the Circuit Switched domain
.......................................
10-9
...............................................................................
10-14
....................................................................................................................................................................................................
10-18
KPI for Mobile-originated end-to-end call setup in the Packet Switched domain
......................................
10-19
KPI for Mobile-terminated end-to-end call setup in the Packet Switched domain
.....................................
10-24
...............................................................................
10-30
....................................................................................................................................................................................................
10-35
.......................................................................................
10-36
........................................................................................
10-38
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
viii
Contents
Exercises
....................................................................................................................................................................................................
10-40
Index
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
ix
Issue a, October 2005
See notice on first page
List of figures
10-5
......................................................................................................................................................
10-5
10-1
10-2
MM and authentication
10-3
10-4
10-5
MM and authentication
10-6
10-7
10-8
10-9
10-10
...................................................................................................................................................
10-10
...........................................................................................................................
10-11
.........................................
10-15
........................................................................................................
10-16
.................................................................................................
10-16
..................................................................................................................................
10-20
...........................................................................................................................................................................
10-20
................................................................................................
10-21
........................................................................................................
10-25
...........................................................................................................................................................................
10-25
10-6
..................................................................................................................................
..............................................................................................................................
...................................................................................................
........................................
10-32
........................................................................................................
10-32
10-26
..................................................................................................
10-33
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
xi
Issue a, October 2005
See notice on first page
Objectives
This document is designed as a reference for the participants of the training course
UM4801.
This course is designed to enable the student to:
Use this course documentation in combination with the latest user documentation.
Conventions used
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
xiii
Issue a, October 2005
See notice on first page
,
Related training
How to comment
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
,
xiv
Course
plan prologue
.................................................................................................................................................................................................................................
Intended audience
This course is designed for personnel involved in the performance evaluation and the
optimization of UMTS Terrestrial Radio Access Networks (UTRAN).
Delivery method
Course duration
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
xv
Issue a, October 2005
See notice on first page
,
Training environment
Each day, the instructor should be mindful of the appearance of the room. At the end
of the day, the instructor should remind students to discard any trash.
On the last day of class, the instructor should return the learning environment to its
original orderliness, if possible.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
,
xvi
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Lesson 1, Introduction to optimization
1-1
2-1
3-1
4-1
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
I-1
Issue a, October 2005
See notice on first page
I ntroduction to optimization
1
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
What is optimization?
1-2
1-4
1-6
Exercises
1-8
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
1-1
Issue a, October 2005
See notice on first page
Introduction to optimization
What
is optimization?
.................................................................................................................................................................................................................................
Definition
For a UMTS network, optimization means getting the entire UMTS network to operate
according to the requirements of an operator.
Optimizing a UMTS network consist of optimizing:
RF network
Transmission network.
Most of the optimization takes place in the RF network. The transmission network
does not have many parameters or variables that can be changed to increase the
effectiveness of the network.
Requirements
By optimizing a network, an operator tries to find the best configuration and use of the
network. This strongly depends on the requirements that an operator has and the
priorities an operator assigns to these requirements.
Requirements can relate to:
Quality of service
Traffic expectations and predictions
Coverage area
Capacity
Current and future business strategies (network expansion, market shares,
profitability levels).
An operator weighs the requirements against the costs that are involved to meet the
requirements and the priorities of the requirements. An operator could probably meet
many requirements, but the costs involved would be very large.
Therefore the financial cost is a very important issue to decide:
Finding compromises
Requirements for a network often contradict each other. Improving a network to meet
one requirement can introduce a problem for another requirement. Optimization
therefore usually involves finding a compromise (or trade-off) between different
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
1-2
Introduction to optimization
What is optimization?
An operator wants:
Increasing transmit power increases RF coverage but at the same time increases
interference. An operator must decide what is more important and implement a solution
that reflects that decision.
What is not optimization
Optimization does not include all actions that make a network work better. Fault
management actions, such as replacing a circuit pack, is not network optimization.
Fault management only ensures the network operates as it is supposed to operate.
The starting point for optimization is a network that does not have errors. Before
starting the optimization of a network or trying to solve an optimization problem, an
engineer must ensure that a problem is not caused by an error or fault.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
1-3
Issue a, October 2005
See notice on first page
Introduction to optimization
Why
optimize a network ?
.................................................................................................................................................................................................................................
Goal of optimization
Example
Changes in environment
Most of these reasons can not be prevented or can only be prevented partially. Good
models (for example for traffic behavior and forecasts) can help predict changes and
thus help in designing and optimizing networks.
Consequences of not optimizing
Not optimizing a network means the goals of optimization are not met and the network
does not meet the requirements of an operator, in the most efficient way.
Of course a network must meet the requirements of an operator, but not meeting these
requirements in the most efficient way costs an operator money. By optimizing the
network, the same requirements could be met with fewer resources.
Not optimizing the network will cost money, related to:
Subscribers
Blocked calls
Dropped calls
Smaller RF coverage area
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
1-4
Introduction to optimization
Blocked calls are a direct loss of revenue for an operator. Poor network quality can
be a reason for existing subscribers changing to another operator and for potential
customers subscribing to competitors.
Operational costs
A network that is not optimized is more expensive to operate. The equipment is not
used effectively, so more equipment is needed. The extra equipment increases
maintenance and operational costs.
Also more errors and problems can be expected in a network that is not optimized.
This increases the costs of fault management.
Result of optimization
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
1-5
Issue a, October 2005
See notice on first page
Introduction to optimization
When
to optimize a network ?
.................................................................................................................................................................................................................................
Phases when optimization takes place
Network design
Planning
Optimization
Implementation
Acceptance
criteria met?
Y
Network design
& implementation
Live network
In service
optimization
Optimization is performed:
The environment in which a network operates is always changing, so the network itself
must always change too, adapting to the changes that take place. There are always
reasons for optimization, therefore optimization in a live network never stops.
Optimization is always needed because there are always:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
1-6
Introduction to optimization
Changes in environment.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
1-7
Issue a, October 2005
See notice on first page
Introduction to optimization
Exercises
.................................................................................................................................................................................................................................
Exercise
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
1-8
Overview
.................................................................................................................................................................................................................................
Objectives
Describe the different information sources that can be used to detect optimization
problems
Identify the tools and methods to gather optimization information
Describe the role of tools to analyze information.
Contents
Gathering information
2-2
2-3
Drive test
2-4
Customer complaints
2-6
OMC-U tools
2-7
Analyzing information
2-8
2-9
Exercises
2-12
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
2-1
Issue a, October 2005
See notice on first page
Gathering information
Overview
.................................................................................................................................................................................................................................
Objectives
Describe the different tools and information sources that can be used to detect
optimization problems.
Identify the tools and methods to gather optimization information.
There are several tools and information sources that are used to gather information that
is used as input for optimization.
These include:
Other tools
Protocol analyzers can also be used to gather performance data. Protocol analyzers can
be used to monitor and count messages on interfaces in the network. Protocol analyzers
are available from many different vendors.
Contents
Key Performance Indicators
2-3
Drive test
2-4
Customer complaints
2-6
OMC-U tools
2-7
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
2-2
Key
Performance Indicators
.................................................................................................................................................................................................................................
Use of KPIs
Key Performance Indicators (KPIs) are calculated using measurements that are
gathered by the OMC-U. The KPIs are used to determine if the network complies to
the levels of performance that are needed.
Key Performance Indicators play an important role in detecting (optimization)
problems. Changes in values of the key performance indicators, especially reaching
thresholds, are often the first indication of an optimization problem.
A KPI value can change suddenly, or gradually, but both types of change can be an
indication that optimization is needed.
Available KPIs
For detailed information on all the available KPIs, refer to UMTS Performance
measurements definitions manual, 401-382-803R0301.
KPIs that can be an indication of a performance problem that needs optimization are:
Detected problems
KPIs can be useful in detecting all the problems that were mentioned, such as:
RF coverage gaps
Cell breathing
Pilot pollution
Near-far problems
Around-the-corner problems
Hand over problems (failures or ping-ponging)
Missing neighbor cells in the neighboring cell list.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
2-3
Issue a, October 2005
See notice on first page
Drive
test
.................................................................................................................................................................................................................................
Purpose
When to perform
Drive tests are performed during network deployment and in a live network. During
network deployment, drive tests are used to check basic cell operation and to ensure
clusters and the network meets customer requirements.
During optimization in a live network, drive tests recheck cell performance. During
these tests, neighboring cells must be operational, so cell selection, interference
measurements and handovers can be performed and tested.
After implementing a solution to correct an (optimization) problem, a drive test can be
performed to check if the problem has been solved.
Regular drive tests are also a method for preventive maintenance to detect areas where
services are degrading.
Components
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
2-4
Drive test
UMTS scanner/receiver
UMTS antenna
PC with software for logging the data
UMTS terminal
Vehicle with location/positioning equipment (for example GPS).
Detecting problems
RF coverage gaps
Cell breathing
Pilot pollution
Near-far problems
Around-the-corner problems
Hand over problems (failures or ping-ponging)
Missing neighbors in a neighboring cell list.
Data that is gathered during a drive test can be displayed in real time or stored on the
PC for off-line analysis.
The information must be analyzed to check for performance problems, that can be
solved by network optimization.
Automated tools are needed because a large volume of information is collected.
Automated tools help to sort out the information and draw conclusions from the
information.
Analysis tools can project the collected data on a map that includes characteristics of
the terrain. On the map, details are shown such as coverage strength, and locations
where handovers, cell reselections or dropped calls occur.
This information is used to identify problems and the locations where the problems
occur.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
2-5
Issue a, October 2005
See notice on first page
Customer
complaints
.................................................................................................................................................................................................................................
Use of customer complaints
Customer complaints are typically documented as trouble tickets. The form of trouble
tickets (electronic, paper) and the way trouble tickets are stored and handled differs
between operators.
Trouble ticket information
Example
Customers complain regularly about dropped calls in a certain location. Dropped calls
can be an indication of an RF coverage gap or a neighboring cell list problem. So
further investigation of the problem is needed.
Further investigation can determine that the dropped calls always occur when there is a
lot of traffic in the cell. The problem can be the result of an RF coverage gap because
of cell breathing.
Detected problems
Although customer complaints are often not very specific, they can be helpful to detect
all optimization problems.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
2-6
OMC-U
tools
.................................................................................................................................................................................................................................
OMC-U tools
The OMC-U offers the following tools that can be used in gathering information for
optimization:
RF call trace
OCNS.
RF call trace
RF call trace gathers radio related information associated to one or more cells. RF call
trace collects signaling messages on the Uu, Iub and Iu interfaces.
When an RF call trace is activated for a UE, information about calls established by
that UE is collected, as long as the UE is connected to the tracing RNC. The
information is composed of measurements performed at the UE, the NodeB and the
RNC. All measurements are stored at the RNC until the OMC-U requests a transfer to
the OMC-U.
Use of RF call trace
OCNS
Orthogonal Channel Noise Simulator (OCNS) is a tool that simulates traffic on the
downlink. OCNS is activated on the OMC-U and generates downlink interference to
simulate traffic.
The OMC-U administrator can define characteristics of the simulated traffic such as
mode of operation (voice or data), number of users and average power of users.
Use of OCNS
OCNS is a tool that is normally used in a network without traffic. OCNS simulates
traffic during testing before a network is live.
OCNS can also be used to generate additional traffic in a live cell, simulating heavier
traffic loads.
Detected problems
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
2-7
Issue a, October 2005
See notice on first page
Analyzing information
Overview
.................................................................................................................................................................................................................................
Objectives
This section provides information about tools that can be used during optimization.
After completing this section, you will be able to:
Contents
Data analysis software
2-9
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
2-8
Data
analysis software
.................................................................................................................................................................................................................................
Need for data analysis software
Data analysis software is needed to process data because a large volume of information
is collected. The software helps to sort out the information, present it to an engineer
and helps the engineer to draw conclusions.
The software also allows an operator to show the consequences of changes that are
made to the network.
Data analysis software is used in:
Data analysis tools can project the collected data on a map that includes characteristics
of the terrain. On the map, details are shown such as coverage strength, and locations
where handovers, cell reselections or dropped calls occur.
To show and analyze information, inputs are needed such as:
Optimization software predicts the effects of changes (for example in power level or
antenna tilt). An engineer can easily try different options. This helps an engineer to
determine what is the best solution to correct an optimization problem.
Output of analysis tools
Data analysis tools can provide output on performance in different forms, but most
commonly used are outputs in tables and graphical outputs. Especially graphical output
clearly shows problem areas in a network.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
2-9
Issue a, October 2005
See notice on first page
Typical output from data analysis software and illustrates a network before and after
optimization:
Before optimization
Optimizated design
The dark lines indicate areas that have no coverage. Changes in the shade of the
antennas indicate changes in antenna tilt.
Analysis tool availability
Many tools are available for analyzing information. The main input for many
commercially available analysis software tools is drive test data. But also other sources
of input can be used.
Besides commercially available software tools, also many proprietary tools are
available.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
2-10
Key capabilities
To be able to handle the large volumes of data from many sources with different
formats, data analysis tools must support key capabilities such as:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
2-11
Issue a, October 2005
See notice on first page
Exercises
.................................................................................................................................................................................................................................
Exercises
Around-the-corner problem
Cell breathing
Missing neighbors
Pilot pollution
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
2-12
Overview
.................................................................................................................................................................................................................................
Objectives
This lesson describes typical problem areas that can be addressed by optimization and
provides possible solutions for the problem.
After completing this lesson, you will be able to:
Since optimization usually is a trade-off, keep in mind that the possible solutions that
are given may solve that particular problem, but at the same time may introduce a
problem elsewhere.
Contents
RF coverage problem
3-2
3-4
3-6
Near-far problem
3-8
Around-the-corner problem
3-9
Handover problem
3-10
3-11
Exercises
3-13
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-1
Issue a, October 2005
See notice on first page
RF
coverage problem
.................................................................................................................................................................................................................................
Definition
The RF coverage area is the area where two conditions are met:
Pathloss and Ec/Io depend on the services and quality that is defined for a network and
can be checked using drive tests. The user equipment receive power is not an accurate
measure of pathloss for spread spectrum technologies. The user equipment may have
strong receive power due to many overlapping sectors, but no pilot fulfills the
above-mentioned coverage conditions. Therefore, the Ec/Io ratio and the Ec signal
strength (connected to the pathloss) of the Primary Common Pilot Channel are used as
accurate measures for RF coverage.
Optimization goal
There are several ways in which RF coverage problems show themselves in the
network.
These include:
Dropped calls
Failed handovers.
Information sources
Drive test
Key performance indicators
Customer complaints.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
3-2
RF coverage problem
Possible solutions
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-3
Issue a, October 2005
See notice on first page
Cell
breathing problem
.................................................................................................................................................................................................................................
Definition
Cell breathing is the growing and shrinking of an RF coverage area, depending on the
network load.
An increase of the network load increases network interference. Higher interference
lowers the quality of service especially at the initial cell coverage border, thus the
coverage area shrinks. To remain connected, power levels must increase. When power
can not be increased further, a handover is needed.
A low network load leads to low network interference, which increases cell coverage.
This can result in neighboring cells not being used because the mobiles stay connected
to the original cell and no handovers occur.
Cell breathing:
Cell at 30 % capacity
Cell at 60 % capacity
The goal is to ensure that high load situations do not lead to RF coverage gaps. At the
same time, low load situations should not create large overlaps in cell coverage, which
may lead to pilot pollution or unwanted handover behavior.
In both high and low load situations, the network must have sufficient coverage and
the network must be used efficiently.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
3-4
There are several ways in which cell breathing problems are manifest in the network.
These include:
Dropped calls
Poor quality, especially at cell edges (during high traffic loads)
Appearance of RF coverage gaps (during high traffic loads)
Failed handovers
No handover to neighboring cells (during low traffic loads)
Excessive or unexpected handovers (during high traffic loads)
Pilot pollution (during low traffic loads).
Information sources
The following information sources are used to detect cell breathing problems:
Drive tests
Key performance indicators
Customer complaints.
Possible solutions
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-5
Issue a, October 2005
See notice on first page
Pilot
pollution problem
.................................................................................................................................................................................................................................
Definition
An optimization engineer needs to determine whether the Ec/Io ratio is poor due to
excessive pathloss or pilot pollution.
Pilot pollution is also considered if the number of present pilots is greater than the
actual active set size of the user equipment. Present pilots which cannot be added into
the active set cause interference.
Another aspect of interference is multipath reception. Each received pilot is
accompanied by 2-3 strong multipaths. The user equipment uses a rake receiver to
exploit multipath reception. Since the rake receiver has a limited number of fingers,
unused multipaths act as interference. Consequently, a six-finger rake receiver is fully
occupied when receiving three pilots (each with 2 multipaths). Any additional pilots
and multipaths are interference. Common trouble spots are bridges, upper floors in
buildings, elevated highways, street intersections, and large bodies of water.
Optimization goal
The goal is to minimize pilot pollution. Coverage of the dominant pilot must be
increased and coverage of the weaker pilots (which cause interference) must be
decreased. At the same time, continuous coverage through the soft handover must be
ensured.
Detection of the problem
There are several ways in which pilot pollution problems show themselves in the
network.
These include:
Dropped calls
Handover failures
Increased interference
Decreased capacity.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
3-6
Information sources
The following information sources are used to detect pilot pollution problems:
Drive tests.
Possible solutions
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-7
Issue a, October 2005
See notice on first page
Near-far
problem
.................................................................................................................................................................................................................................
Definition
Near-far problems occur when user equipment near the cell site transmits on high
power. This creates excessive interference for user equipment that is located far away
from the cell site.
Optimization goal
The goal of the cell site is to receive all user equipment at equal signal strengths.
Therefore, power control must be tightly controlled. Fast closed loop power control is
needed to direct mobiles to power up or power down very quickly. The optimization
goal is to ensure that all power control algorithms are working properly. Power control
parameters are tuned only when there are obvious power control failures.
Detection of the problem
There are several ways in which near-far problems show themselves in the network.
These include:
High interference
Node B always transmits on full power despite satisfying block error rates
User equipment always transmits on full power despite satisfying block error rates.
Information sources
Drive test
Key performance indicators
Customer complaints.
Possible solutions
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
3-8
Around-the-corner
problem
.................................................................................................................................................................................................................................
Definition
There are several ways in which around-the-corner problems show themselves in the
network.
These include:
High interference
Unusual handover behavior.
Information sources
Drive tests
Key performance indicators.
Possible solutions
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-9
Issue a, October 2005
See notice on first page
Handover
problem
.................................................................................................................................................................................................................................
Definition
There are several ways in which handover problems show themselves in the network.
These include:
Information sources
Drive test
Key performance indicators.
Possible solutions
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
3-10
Missing
neighbors problem
.................................................................................................................................................................................................................................
Definition
A neighboring cell list contains the cell identifiers to which a handover is allowed. The
list is kept in the RNC and is transmitted to the UE. The UE measures signals only
from the neighboring cell list and uses these measurement for power control and
handovers. A handover can therefore only occur to a cell that is in the neighboring cell
list of a UE, so setting up proper neighboring cell lists is very important.
Missing neighbors are pilots that are not in the neighboring cell list. When pilots are
received that are not in the neighboring cell list, these pilots cannot be added to the
active set and thus these pilots will cause interference. It is important that all received
UMTS sectors are either eliminated or declared in the neighboring cell list.
Optimization goal
The goal is to optimize the neighboring cell lists. Received pilots must either be
eliminated or declared in the neighboring cell list. They must not be ignored.
Detection of the problem
There are several ways in which missing neighbor problems show themselves in the
network.
These include:
Dropped calls (when neighboring cell list is too short and UE can not handover to
another cell)
High interference levels (UE transmits at high power levels to serving cell, because
it can not handover to another cell)
Unusual handover behavior (no handovers are performed from one cell to another
cell).
Uneven traffic distribution (UEs stay with a cell and are not handed over to a
neighboring cell).
Information sources
The following information sources are used to detect missing neighbors problem:
Drive test
Key performance indicators
Customer complaints.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-11
Issue a, October 2005
See notice on first page
Possible solutions
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
3-12
Exercises
.................................................................................................................................................................................................................................
Exercises
UEs near the cell site transmit on high power, creating excessive interference
b
2
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
3-13
Issue a, October 2005
See notice on first page
U TRAN Signaling
4
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Protocol architecture of the air interface
4-2
4-3
4-5
4-7
4-10
4-11
4-12
4-15
Exercises
4-18
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-1
Issue a, October 2005
See notice on first page
UTRAN Signaling
Contents
Protocols of the air interface
4-3
4-5
4-7
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-2
UTRAN Signaling
Protocols
of the air interface
.................................................................................................................................................................................................................................
Logical structure of the air or Uu interface (PS example)
The following illustration shows the UTRAN protocol architecture (for DCH) with the
protocols of the Uu highlighted.
IP
SM
SM
PMM
PMM
PDCP RRC
RRC
RLC
PDCPGTP-U
RLC
MAC
MAC
Phy -up
ALCAP
ALCAP
STC.2 NBAP
FP
PHY
PHY
SSCF-UNI
SSCOP
SSCOP
AAL5
AAL5
AAL2
Phy-up
NBAP STC.2
SSCF
-UNI
UDP
FP
IP
GTP-U
RANAP RANAP
SCCP
SCCP
MTP3-b
MTP3-b
SSCF
-N
SSCF
-N
UDP
IP
SSCOP SSCOP
AAL2
AAL5
AAL5
ATM
ATM
ATM
E1/ STM
-1
-1
STM
STM-1
Control plane
User plane
UE
Uu
Node B
Iub
RNC
Iu-ps
SGSN
Description
The following table lists the protocols of the Uu and introduces the functions each
performs.
Part
Description
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-3
Issue a, October 2005
See notice on first page
UTRAN Signaling
Part
Description
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-4
UTRAN Signaling
Radio
interface protocol architecture
.................................................................................................................................................................................................................................
A layered architecture
The top layer (layer 3) is the network layer and includes the RRC and the user
traffic
below that is layer 2 or the data link layer,
Layer 2 is split into the following sub-layers:
Medium-Access Control (MAC)
Radio Link Control (RLC)
Packet Data Convergence Protocol (PDCP)
Broadcast/Multicast Control (BMC).
the bottom layer is the physical layer (layer 1).
Layer 3 and the RLC are divided into Control (C) and User (U) planes. The PDCP and
the BMC exist in the U plane only.
In the C plane, Layer 3 is partitioned into sub-layers where the lowest sub-layer which
is called the Radio-Resource Control (RRC), interfaces with Layer 2 and terminates in
the UTRAN.
Higher-layer signaling, such as Session Management (SM)Mobility Management (MM)
and Call Control (CC), belongs to the non-access stratum, is not terminated in the
UTRAN and thus not discussed in this topic.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-5
Issue a, October 2005
See notice on first page
UTRAN Signaling
The following figure illustrates the logical structure of the radio protocol architecture:
C-plane signaling
GC Nt DC
U-plane information
control
Layer 3
PDCP
L2/PDCP
DCP
BMC
RLC RLC
RLC
RLC
RLC RLC
RLC
L2/BMC
RLC
L2/RLC
Logical
Channels
L2/MAC
Transport
Channels
L1
Physical
Channels
Each block in the previous figure represents an instance of the respective protocol.
Service Access Points (SAP) for peer-to-peer communication are marked with ovals at
the interface between sub-layers. The SAP between the MAC and the physical layer
provides the transport channels. The SAPs between the RLC and the MAC sub-layer
provide the logical channels. In the C-plane, the interface from RRC to higher layers
(CC, MM) is defined by the General Control (GC), Notification (Nt) and Dedicated
Control (DC) SAPs.
The connections between the RRC and the MAC as well as the RRC and L1 provide
local inter-layer control services.
Equivalent control interfaces exist between:
These interfaces allow the RRC to control the configuration of the lower layers. For
this purpose separate Control SAPs are defined between the RRC and each lower layer
(PDCP, RLC, MAC and L1).
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-6
UTRAN Signaling
Service
access points
.................................................................................................................................................................................................................................
Service access points
The layers provide services to the layer above, and use the services of the layer below.
These services are provided through Service Access Points, which provide different
kinds of channels for communications. The channels are divided into four broad
categories, depending on which layer interface provides them. These categories are:
The SAPs and their position between the layers are illustrated in the following figure.
L
a
y
e
r
M
a
n
a
g
e
m
e
n
t
Radio Resource
Control (RRC)
L3
SAPs
SAPs
The logical channel service contains the type of information that is transferred over
the radio link. For example, the DTCH carries the actual user data; the BCCH
provides system information to all users in a cell.
The transport channel service defines how and with what characteristics (with
which QoS) data is transferred over the radio link. Every transport channel has a
transport format assigned to it which contains information such as channel coding,
interleaving and rate matching.
The physical channel service provides the means by which the UE is radio-linked
with the Node B.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-7
Issue a, October 2005
See notice on first page
UTRAN Signaling
Channel mapping
For each of the channel categories, there is a number of types, each with different
characteristics. The Radio Bearers map directly to the Logical Channels; the Logical
Channels map to the Transport Channels; and the Transport Channels map to the
Physical Channels.
The following illustration shows the relationships between channels linking different
protocol layers.
Physical channels
Downlink
Uplink
P-SCH
S-SCH
Birirectional
P-CPICH
Logical channels
Transport channels
S-CPICH
BCCH
BCH
P-CCPCH
PCCH
PCH
PICH
CCCH
FACH
S-CCPCH
CTCH
RACH
PRACH
DCCH
DTCH
AICH
DCH
DPDCH
DPCH
DPCCH
DSCH
PDSCH
CPCH
PCPCH
Transport channels are mapped to physical channels as shown in the illustration above.
There are many physical channels which do not carry higher-layer traffic; some are
associated with traffic-carrying channels, while others are necessary for cell discovery
by the UE and channel estimation.
Multiple transport channels can be multiplexed onto a single physical channel, or
conversely, one transport channel can be transferred over multiple physical channels
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-8
UTRAN Signaling
(multicode). PCH and FACH can be multiplexed onto the same S-CCPCH or can each
be transferred over separate S-CCPCHs.
Associated channels are used as follows:
PICH indicates in an efficient manner that information for a mobile will shortly be
transferred on the PCH transport channel
AICH indicates that an access preamble has been received, and that the UE can
stop ramping up its power, or (for PCPCH) that a collision detect preamble has
been received and resolved
DPCCH carries power control information for associated channels as well as TFC
indication for DPDCH and PDSCH, and pilot and feedback information. The
shared channels are power controlled, so a UE which uses them must also have a
dedicated channel set up and associated with them. This DCH can be of very low
bandwidth compared to the shared channel, and may well carry the DCCH.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-9
Issue a, October 2005
See notice on first page
UTRAN Signaling
Contents
RRC Connection and Signaling Connection
4-11
4-12
4-15
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-10
UTRAN Signaling
RRC
Connection and Signaling Connection
.................................................................................................................................................................................................................................
Definitions
RRC Connection
Relay
RRC
UE
RRC
Uu
Node B
Iub
RNC
RANAP
RANAP
Iu
SGSN\MSC
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-11
Issue a, October 2005
See notice on first page
UTRAN Signaling
Signaling
radio bearers
.................................................................................................................................................................................................................................
Definitions
Signaling radio bearer The radio bearers available for transmission of RRC messages
are defined as signalling radio bearers.
Signaling connection An acknowledged-mode link between the UE and the CN to
transfer higher layer information between the entities in the non-access stratum (via
RRC and RANAP).
RRC connection establishment in DCH state
This example shows the steps taken during the establishment of an RRC connection in
DCH state.
Node B
Serving RNS
UE
Serving RNC
5. Downlink Synchronization
6. Uplink Synchronization
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-12
UTRAN Signaling
After performing Call Admission Control (CAC), the SRNC decides to use a DCH for
this RRC connection, allocates RNTI and radio resources for the RRC connection.
When a DCH is to be set-up, an NBAP message Radio Link Setup Request is sent to
the Node B.
.................................................................................................................................................................................................
The Node B allocates resources, starts PHY reception, and responses with the NBAP
message Radio Link Setup Response.
.................................................................................................................................................................................................
The SRNC initiates the set-up of an Iub data transport bearer using the ALCAP
protocol. The request for the set-up of an Iub data transport bearer is acknowledged by
the Node B.
.................................................................................................................................................................................................
The Node B and the SRNC establish synchronism for the Iub and Iur data transport
bearer by means of exchange of the appropriate DCH frame protocol frames downlink
synchronization.
.................................................................................................................................................................................................
The Node B and the SRNC establish synchronism for the Iub and Iur data transport
bearer by means of exchange of the appropriate DCH frame protocol frames uplink
synchronization. Then the Node B starts downlink transmission.
.................................................................................................................................................................................................
The message RRC connection setup is sent on a CCCH from the SRNC to the UE.
.................................................................................................................................................................................................
The Message RRC connection setup complete is sent on a DCCH from the UE to the
SRNC.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-13
Issue a, October 2005
See notice on first page
UTRAN Signaling
The RRC on the UE side configures L1 and MAC and creates the new RLC entities
with the parameters given by the network-side RRC.
The following illustration shows the newly created signaling radio bearers after the
creation of the RRC connection.
C-plane signaling
U-plane information
control
control
control
control
Signaling
Radio
Bearers
New RLC
entities
RLC
RLC
RLC
RLC
MAC
parameters
Medium Access Control (MAC)
L1
Parameters
Physical Layer (PHY)
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-14
UTRAN Signaling
Radio
bearer establishment
.................................................................................................................................................................................................................................
Definitions
Radio bearer A service provided by the RLC layer for transfer of user data between
UE and SRNC.
Radio access bearer The service that the access stratum provides to the non-access
stratum for transfer of user data between UE and CN. Consists of radio bearer
service and Iu bearer service. Known by RAB identifier (RAB ID).
Radio Access Bearer establishment
This example shows the steps involved in the establishment of a Radio Access Bearer.
UE
Node B
RNC
MSC
RANAP
RAB Assignment Request
ALCAP
ERQ (Establish Request)
ALCAP
NBAP
RL Reconfigure Prepare
NBAP
RL Reconfigure Ready
ALCAP
ERQ (Establish Request)
ALCAP
ECF (Establish Confirm)
FP DL Synchron.
FP UL Synchron.
NBAP
RL Reconfigure Commit
RRC RB Setup Request
DCCH
RRC RB Setup Complete
DCCH
RANAP
RAB Assignment Response
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-15
Issue a, October 2005
See notice on first page
UTRAN Signaling
The SGSN initiates the process by sending a RAB assignment request to the RNC
indicating the RAB configuration and also passing the UL GTP tunnel Paramaters.
.................................................................................................................................................................................................
The UE already has a Radio Link setup, this procedure requires that a DTCH be added
to the configuration, therefore the RNC sends a RL reconfigure request to the Node B.
The Node B confirms with RL Reconfigure Ready, but does not implement the changes
yet.
.................................................................................................................................................................................................
Once the RL has been reconfigured in the Node B, the RNC sets up the AAL2 bearer
to carry it. This is done via ALCAP Establish procedures and is followed by FP
synchronisation.
.................................................................................................................................................................................................
When the AAL2 connection is ready, the RNC instructs the Node B to commit the
changes it had prepared in the reconfiguration. The Commit message indicates the
Frame number at which the change should occur.
.................................................................................................................................................................................................
The UTRAN has been configured for the new DTCH, so the UE can now be instructed
to set up the Radio Bearer. The RNC does this via an RRC RB set-up request. This
includes the same CFN as indicated to the Node B.
.................................................................................................................................................................................................
Once the UE has configured the RB, it returns a confirmation message in the form of
an RRC RB set-up Complete.
.................................................................................................................................................................................................
Reception of the set-up complete message by the RNC indicates that RAB assignment
procedure is complete, it indicates this back to the SGSN via a RANAP RAB
assignment response, that also includes the DL addressing for the GTP-U connection.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-16
UTRAN Signaling
The following illustration shows the newly created radio bearer after the creation of the
Radio Access Bearer.
C-plane signaling
U-plane information
New Radio
Bearer
control
control
BMC
RLC
RLC
RLC
RLC
RLC
New RLC
entity
MAC
parameters
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
4-17
Issue a, October 2005
See notice on first page
UTRAN Signaling
Exercises
.................................................................................................................................................................................................................................
Exercises
UE and Node B
UE and RNC
b
2
Physical
Transport
Logical
Bearer
b
3
P-CPICH
PRACH
P-CCPCH
AICH
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
4-18
Overview
.................................................................................................................................................................................................................................
Objectives
Describe when optimization is performed during a network lifecycle and the phases
of the optimization process
Describe what site readiness entails
Describe the optimization planning phase
Describe the RF optimization execution phase.
Contents
Lesson 5, Optimization process
5-1
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
II-1
Issue a, October 2005
See notice on first page
O ptimization process
5
Overview
.................................................................................................................................................................................................................................
Objectives
Describe when optimization is performed during a network lifecycle and the phases
of the optimization process
Describe what site readiness entails
Describe the optimization planning phase
Describe the RF optimization execution phase.
Contents
Lifecycle
5-2
5-4
5-7
5-9
Optimization planning
5-11
5-13
5-16
Information gathering
5-18
Information analysis
5-19
Exercises
5-20
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-1
Issue a, October 2005
See notice on first page
Optimization process
Lifecycle
.................................................................................................................................................................................................................................
Network lifecycle
Network design
Planning
Optimization
Implementation
Acceptance
criteria met?
Y
Network design
& implementation
Live network
In service
optimization
This shows the stages in the lifecycle of a network and the place of optimization in the
lifecycle:
.................................................................................................................................................................................................
.................................................................................................................................................................................................
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-2
Optimization process
Lifecycle
This translates the design into the real environment. This can mean that there are
differences between the design and the planned site.
The data from the planned site is used as input for optimization.
.................................................................................................................................................................................................
When a site is completed, drive tests are usually started, to test basic operation. Data
from the drive tests, together with installation and parameter data from the site, is used
as input for optimization.
Refer to Drive test optimization process
.................................................................................................................................................................................................
When all sites are completed and tested, final (drive) tests are performed to check if
the network complies to the customers requirements.
If the customer accepts the network, the network goes live and commercial use can
begin.
.................................................................................................................................................................................................
In the live network, the continuous process of in-service optimization now begins.
In-service optimization can result in the need to update the network design to include
new cells, thus restarting this process.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-3
Issue a, October 2005
See notice on first page
Optimization process
Optimization
process phases
.................................................................................................................................................................................................................................
Objectives
This topic shows the stages of the optimization process in a live network.
Site readiness checks must have been performed before optimization starts.
Optimization process flow
Gather information
Analyze information
Optimization
problem?
Sufficient
information?
Identify reason
Determine solution
Implement solution
Problem
solved?
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-4
Optimization process
Collect information.
Result: Main information sources are:
Drive tests
Customer complaints
Performance measurements and KPIs.
.................................................................................................................................................................................................
Capacity
RF Coverage
Cell breathing.
.................................................................................................................................................................................................
Cost of implementation
Easy of implementation
Chance of success.
.................................................................................................................................................................................................
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-5
Issue a, October 2005
See notice on first page
Optimization process
When ...
then ...
go to Stage 1.
Continuous optimization
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-6
Optimization process
Drive
test optimization process
.................................................................................................................................................................................................................................
Objectives
Before a network takes on live traffic, optimization using drive tests is usually
performed. These drive tests are performed to correct problems and to prove that the
network meets customer requirements.
Stages
The following is the optimization process that is performed prior to a network being
commercially deployed:
.................................................................................................................................................................................................
Spectrum clearance,
to ensure no external interferences are present and sufficient guard band are obeyed
Antenna checks,
to ensure that the antenna system is properly installed (tilt, azimuth, cabling)
Sector verification,
to ensure basic functionality of a sector (call processing, hand overs).
.................................................................................................................................................................................................
Plan optimization.
Ensure the system and tools are ready and available for drive test optimization.
This includes:
.................................................................................................................................................................................................
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-7
Issue a, October 2005
See notice on first page
Optimization process
.................................................................................................................................................................................................
The network is now ready for live traffic testing which leads into commercial service.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-8
Optimization process
Planning
and preparation (site readiness)
.................................................................................................................................................................................................................................
Introduction
Spectrum clearance
Antenna check
Sector verification.
Spectrum clearance
Type of antenna
Height of antenna
Tilt and azimuth of the antenna
Cabling.
Sector verification
Sector verification ensures the basic functionality of a sector. This includes basic call
processing and handovers. Measurements are made on UMTS signal levels to verify
that each sector is transmitting with the appropriate power levels and the correct
scrambling code. The sector verification tests are used to detect hardware, software,
configuration and parameter errors.
The sector tests are performed using measurement software including a UMTS test
terminal. Once all data from the sector tests have beencollected, the measurement data
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-9
Issue a, October 2005
See notice on first page
Optimization process
can be post-processed. If sector problems do occur, they need to be remedied and the
tests repeated until they are successful.
Baseline existing system
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-10
Optimization process
Optimization
planning
.................................................................................................................................................................................................................................
Introduction
The optimization planning phase ensures system and tool readiness for RF optimization
before beginning the actual drive testing.
Perform RF parameter audit
The drive test and post-processing tools need to be prepared for optimization.
Define clusters
Approximately 15-19 cell sites should be combined into one cluster. The actual number
used is based on network expansion as well as on the topographical environment. The
clusters are selected to provide a center cell site with two rings of surrounding cell
sites as shown in the figure below.
It may be worthwhile to utilize natural barriers such as hills and water bodies for
cluster separation to minimize overlap and influence between the clusters. A little cell
site overlap should remain between each cluster to ensure continuity across the
boundaries.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-11
Issue a, October 2005
See notice on first page
Optimization process
Optimization planning
B
1
2
A
9
3
4
5
11
10
8
7
6
Sector Verification
Cluster Optimization
System Verification.
Each cell site is driven approximately around the entire cell site. The selected drive
route should maintain a distance equal to 1/2 of the cell site radius. Sector drive routes
usually do not require customer approval.
Planning drive routes for Cluster Optimization
The routes for Cluster Optimization should consist of major roads, highways and
hotspots. Total time to drive all routes in a typical cluster should be approximately 6 to
8 hours.
One control route per cluster is chosen to verify system performance. A control route is
a subset of the optimization route and should be limited to about 1 to 2 hours.
Additional border routes are chosen to verify system performance on overlapping
cluster regions. A border route is chosen by the way it crosses the cluster borders
without going into the cluster areas.
Planning drive routes for System Verification.
The System Verification drive routes are used to collect the metrics for the Exit
Criteria. The routes are a combination of the cluster control routes and routes between
the individual clusters.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-12
Optimization process
Perform
cluster optimization
.................................................................................................................................................................................................................................
Introduction
Cluster optimization should be performed for network sections that are fully deployed.
This avoids a re-testing of already optimized clusters in case cell sites are later
integrated. All cell sites in the network (or a network section) are switched on. Each
cluster is tested under unloaded and loaded conditions. If live traffic exists, cells in the
tested clusters must be barred for all users except for the test users (optimization team).
It is recommended to finish the unloaded cluster tests for all clusters within the
network or network sections before continuing with the loaded cluster tests. After a
small set of adjacent clusters pass the exit criteria, a border exit drive must be
performed. The border exit drive is performed under loaded conditions in order to
verify and confirm the exit criteria at the borders of the clusters.
Multiple cluster testing
During multiple cluster testing the optimization teams working on neighbor clusters
must coordinate activities especially regarding neighbor relations, loading conditions or
possible overshooting sites.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-13
Issue a, October 2005
See notice on first page
Optimization process
The required data collection, processing and analysis tools for cluster optimization are
a phone-based data collection tool kit including CAIT3G, a UMTS terminal, WINDS
as well as the post-processing tool LDAT3G. In addition to the phone-based tool kit,
the scanner-based tool Agilent can be used during cluster optimization. The Agilent
scanner is an important tool due to its multiple pilot measurement capability, which is
especially useful for more in depth coverage analysis (e.g. pilot pollution) in
challenging RF environments (e.g. large water-bodies, bridges, un-even terrain, etc.)
3 phases of cluster optimization
During the first cluster optimization phase, a measurement drive is performed under
unloaded network conditions using the optimization route. Once the data from the first
phase is collected, problem spots are identified and optimized. The unloaded drive test
identifies coverage holes, handover regions and multiple pilot coverage areas. It also
spots possible overshooting sites (where interference is minimal) from areas belonging
to neighbor clusters.
The first pass might lead to correction of neighbor lists and adjustments of the
fundamental RF parameters such as transmit powers and/or antenna azimuths and
antenna tilts. The drive test information highlights fundamental flaws in the RF design
under best-case conditions.
Loaded cluster optimization
The second cluster optimization phase is performed under loaded conditions. The drive
routes for the loaded cluster optimization are exactly the same routes as those used for
the unloaded measurement drives.
Loaded testing produces a rise in the noise floor, which has the effect of shrinking the
coverage area (cell breathing). This causes an increase of negative Ec/Io values,
identify potential coverage holes, results in higher BLER, results in lower mobility
throughput, and more dropped calls.
The objective is to fix the problems observed by the field teams. This involves the
fine-tuning of RF parameters such as the transmit power or handover parameters.
Antenna re-adjustments (e.g. down-tilts, azimuths, patterns/types or heights) are also
occasionally performed.
Problem areas may be re-driven after implementing changes. It is not recommended to
drive a problem area more than three times. If the problem cannot be solved after three
test drives, either a root cause analysis is performed or cluster optimization proceeds
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-14
Optimization process
In the third phase, the cluster performance is measured against the cluster exit criteria.
The exit drives purpose is to verify and to confirm specific exit criteria demanded by
the customer.
The final statistics from the cluster exit drive are presented to the customer for
approval. These statistics contain plots as well as data in tabular form. The approval to
exit the cluster is based on the terms of the contract. Approval with exceptions allows
the cluster to be exited under the condition that any problems will be resolved during
system wide optimization. If the cluster is not approved, loaded cluster optimization
must be continued until the troubles are resolved. A report specifying the reasons why
the exit drive did not pass the exit criteria is required.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-15
Issue a, October 2005
See notice on first page
Optimization process
Perform
system verification
.................................................................................................................................................................................................................................
The final phase
System verification is the final phase of the RF Drive Test Based Optimization activity
and it focuses specifically on collecting overall performance statistics. System
verification begins after all clusters in the UMTS network have been tested. It is
performed under loaded conditions with all cells activated. System verification involves
fusion of the previously optimized clusters and once again is required to demonstrate
that Exit Criteria are met system-wide.
A comprehensive drive test
System verification is a comprehensive drive test covering the major highways and
primary roads in the defined coverage area. There is a focus on the problem areas
identified during the Cluster Optimization (system verification driving routes). The
procedures and analysis are identical to those used in Cluster Performance Verification.
Performance data will be collected and statistics will be made to characterize coverage
and performance over the entire network.
The system drive routes should not be used for optimization. System drives do not
allow changing parameters due to side effects. Optimizing a system route can result in
very good performance on the system verification driving routes but poor performance
elsewhere. System optimization is a continuation of Cluster Performance Verification.
The main difference is the larger contiguous area of coverage.
Problem areas
The final statistics from the system verification phase are presented for approval. The
same tools that were used for Cluster Optimization are used for the system verification
phase. At the end of the system-wide drive test phase, the RF Optimization procedure
is considered complete. The UMTS network is ready for live traffic testing leading into
commercial service. Once significant loading with live traffic is present on the
network, additional tuning of system parameters will be required to accommodate
uneven traffic conditions (e.g. traffic hot spots) and other dynamic effects which cannot
be modeled with simulated traffic loading.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-16
Optimization process
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-17
Issue a, October 2005
See notice on first page
Optimization process
Information
gathering
.................................................................................................................................................................................................................................
Information is needed to determine:
Information sources
Information from one of these sources, can trigger further investigation. During the
more detailed investigation information from other sources is gathered.
Key performance indicators
Key performance indicators (KPI) are used to determine if the network complies to the
levels of performance that are needed.
KPIs are calculated using measurements that are gathered by the OMC-U.
Changes in values of the key performance indicators, especially reaching thresholds are
often the first indication of an optimization problem.
Drive tests
Drive tests can be used to gather information in the network. A drive test can be
performed to gather information about a specific problem or problem area. Drive tests
can also be performed to gather general information about the network performance.
Customer complaints
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-18
Optimization process
Information
analysis
.................................................................................................................................................................................................................................
After information is collected, analysis of the information determines:
1.
2.
3.
4.
Role of an engineer
Because of the scale and complexity of a network, engineers are not able to handle the
large volumes of detailed information that is available. Engineers can use software
tools to handle the information and determine if there are problems.
Software tools can also be used to determine the consequences of implementing a
solution in the network. Using models, software can simulate the impact on the
network of implementing a solution.
Commercially available and proprietary tools are available to analyze information and
determine impacts.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
5-19
Issue a, October 2005
See notice on first page
Optimization process
Exercises
.................................................................................................................................................................................................................................
Exercises
b
2
Non-optimized RF parameters
a
3
If, after loaded tests, a problem cannot be solved after three test drives, what
should be done?
a
Further drive tests and optimization until the problem has been solved
a, c
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
5-20
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Lesson 6, Call availability and optimization
6-1
7-1
8-1
9-1
10-1
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
III-1
Issue a, October 2005
See notice on first page
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Call availability
6-3
Call availability
6-4
6-6
6-7
Introduction
6-8
6-9
Cell selection
6-10
6-12
6-14
6-17
6-18
6-20
6-21
6-23
Paging failures
6-26
6-28
Introduction
6-29
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-1
Issue a, October 2005
See notice on first page
Overview
6-32
6-33
6-34
No answer from UE
6-35
Code starvation
6-36
Exercises
6-37
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-2
Call availability
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Call availability
6-4
6-6
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-3
Issue a, October 2005
See notice on first page
Call
availability
.................................................................................................................................................................................................................................
Introduction
Call availability is defined as the first main factor that identifies the user perception,
from a UMTS point of view, of the UMTS network in successfully setting up a call.
Via the call set-up process, the UE executes the transition from Idle state to Cell_DCH
state, requests and acknowledges the resources setup; the UTRAN and the Core
Network allocate all the requested resources.
Call setup process
The call setup process consists of different procedures depending on what kind of
session/service type is required (for example CS or PS). RRC Connection
Establishment and RAB Establishment procedure are the main procedures on the
UTRAN side.
With the RRC Connection Establishment procedure, the UE requests resources from
the UTRAN and executes the transition from Idle to CELL_DCH state, entering the
UTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radio
links.
With the RAB Establishment procedure, all the requested resources are allocated by the
Core Network and by the UTRAN in terms of Radio Access Bearers (RABs) while the
UE stays in Cell_DCH state and acknowledges the resources setup.
The call is successfully set-up only if both procedures are successfully completed.
Related transition states
In order to allow the user to successfully originate or receive a call, the UE must pass
the following states:
Call setup failures can occur during the Network Attach procedures when the UE
executes the transition from the power off to the Idle state. These failures impact Call
Availability as the user needs to get the UE to the Idle state before attempting call
setup.
Network level access phase
During the network level access phase, the UE has to successfully perform the cell
(re)selection process as well as to gain network access using the Random Access
procedure.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-4
Call availability
During the RRC Connection Establishment phase, the UE requests resources from the
UTRAN and executes the transition from Idle to Cell_DCH state and enters the
UTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radio
links.
RAB establishment phase
During the RAB Establishment phase, the requested resources are allocated by the
Core Network and by the UTRAN in terms of Radio Access Bearers (RABs) while the
UE stays in Cell_DCH state and acknowledges the resources setup.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-5
Issue a, October 2005
See notice on first page
Determination
of accessibility problem
.................................................................................................................................................................................................................................
Introduction
In order to quickly determine whether there are severe problems in the UMTS network,
it is possible to analyze the general satisfaction level, from a network point of view, of
the UMTS mobile subscriber about the network accessibility.
Related PMs / KPIs
Each of the KPIs above is derived from multiplying the service type specific RAB
Establishment Success Rate with the Successful RRC Connection Establishment Rate.
Abnormal accessibility rate values
When one of the Accessibility rate values is very low, this can be caused by many
different issues. Therefore, it is advised to localize the issue by analyzing the
performance measurements and KPIs separated over the accessibility call phases:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-6
Contents
Introduction
6-8
6-9
Cell selection
6-10
6-12
6-14
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-7
Issue a, October 2005
See notice on first page
Introduction
.................................................................................................................................................................................................................................
Preliminary procedures failures
In general any call-related procedure initiated via RRC messages sent by the UE to the
UTRAN is preceded by two preliminary procedures such as cell selection/re-selection
and Random Access Detection.
Successful completion of both procedures is a basic prerequisite to succeed in any call
procedure.
Not visible for performance management
Both the cell selection/re-selection and Random Access Detection procedures are not
visible to the network before successful reception of RRC messages relevant for the
specific call procedure. Therefore, failures occurring during both procedures will not
affect the value of any RRC connection performance indicators.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-8
Cell
Search & RRC SIB decoding
.................................................................................................................................................................................................................................
Introduction
Cell Search and RRC System Information Broadcast (SIB) messages decoding precede
cell selection and re-selection procedures.
Both procedures directly affect cell selection and re-selection, thus some more details
on this are provided here.
Process
Generally the process of cell search can be divided into three stages:
The behavior of the cell search algorithms is largely impacted by the power settings of
the three physical channels involved in this process: the P-SCH, the S-SCH and the
P-CPICH.
If problems during the cell search procedure occur in areas of good coverage, the
power settings of the channels involved, defined by corresponding UTRAN parameters,
should be examined. This could be done using drive test equipment allowing the
supervising of the three different stages of cell search, which helps to identify the
causes of unsuccessful cell search operation.
P-CCPCH power setting
Once the UE has successfully synchronized to the P-CPICH scrambling code of the
NodeB, it starts to decode the RRC SIB messages on the Broadcast Channel (BCH).
The power setting for the P-CCPCH, which carries the BCH information, may affect
the SIB decoding success rate.
If this power is too low the UE may not be able to properly decode the SIB and can
therefore not read the parameters related to several UE procedures such as cell
selection and re-selection, RACH access, and handover. SIB decoding issues should be
examined using UE drive test equipment by recording and evaluating the SIB detection
error rate.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-9
Issue a, October 2005
See notice on first page
Cell
selection
.................................................................................................................................................................................................................................
Introduction
Once the UE has successfully completed Cell Search and SIB Decoding, it performs
cell selection. During this procedure the UE tries to find a cell of a suitable Public
Land Mobile Network (PLMN) which satisfies the cell selection criteria.
Two thresholds for quality and level of the received pilot are used within the cell
selection criteria. Current UE measurements must exceed both thresholds before the
UE tries to access this cell.
Both thresholds are defined as UTRAN parameters:
sIB3QqualMin
sIB3QRXLevMin
If the cell selection criteria are not fulfilled, the UE will not access the network on the
RACH and is therefore not visible to the network. This can be caused by incorrect
parameters settings or by bad coverage.
Failure Symptoms
If the selection criteria are not fulfilled, the UE will not try to attach to the network,
i.e. it will not send an RRC Connection Request message on the RACH set to
Registration. Therefore, this failure is not visible from the network. On the UE side,
the UE stays on Searching state that is visualized in the display.
If the UE enters the Limited Service state, Cell Selection was successful but the UE
has either camped on a cell belonging to a different PLMN or failures occurred during
the Registration procedure on the initially selected PLMN (e.g. due to Core Network
issues).
All problems with cell selection can only be verified either using UE traces or
observing that traffic is lower than expected and users are complaining about problems
during attach.
Improvement suggestions
If problems with the cell selection criteria within the RF-design coverage area are
suspected:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-10
Cell selection
Measuring the current values of pilot Ec and Ec/Io in this location allows you to
judge whether the cell selection criteria should be fulfilled in this area.
Under certain circumstances, it may be indicated to lower both quality and level
thresholds even further to allow the UE to attach. Care must also be taken to
ensure that the calls may be maintained at an acceptable quality with these lowered
thresholds. Otherwise, UEs will be allowed to get onto the network, but will be
unable to sustain sufficient quality, and may result in more dropped calls and
unhappy customers.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-11
Issue a, October 2005
See notice on first page
Cell
re-selection failures
.................................................................................................................................................................................................................................
Overview
Once the UE is able to select a cell and attach to the network, it should continuously
perform the cell re-selection process.
If the parameters for cell re-selection have too much hysteresis, the UE will possibly
access a cell which is not the optimal choice in terms of interference. On the other
hand, lower re-selection hysteresis values will make the effect of ping-pong
re-selections more likely.
If the UE selects a cell within a different URA, the UE will start the URA update
procedure, pegging the PM counter NumUraUpdateRequest.UraChange.
Two important parameters (sIB3Qhyst2 and sIB3Treselection) broadcast on the RRC
SIB 3 message define the hysteresis of the measurement value Ec/Io and the hysteresis
time.
Failure symptoms
If the hysteresis values are too high, this might cause call setup failures. Detailed root
cause analysis of cell reselection problems can only be performed via UE tracing.
However, an increased number of RRC Connection Establishment failures in
combination with high hysteresis values for cell reselection can indicate cell reselection
problems causing this behavior. The parameters should be changed according to the
recommendations to rectify this issue.
Another performance measurement related to cell reselection is the number of Cell
Update requests due to reselection. Only if reselection appears at the LA or RA
boundaries will a Cell Update be performed. Nevertheless, this value should increase
for hysteresis values that are set too low in cells at an LA / RA boundary when
compared to a properly set cell with similar traffic.
Improvement suggestions
Before starting the investigation, it should be checked whether all reselection settings
are compliant with the recommendations.
If an increased number of Cell Update requests are observed at an LA/ RA boundary,
and it is verified in a drive test that the reselection hysteresis is too small, then the
hysteresis parameters must be raised.
After changing the reselection parameters, it can be verified in another drive test that
the reselection hysteresis is high enough and that ping-pong reselections are extremely
unlikely.
Reselection issues that result in lower call setup success rates may indicate a hysteresis
setting that is set too high. This should again be verified in a drive test and then
checked whether it has improved after a parameter adjustment.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-12
NumCellUpdateRequest.CellReselect
NumUraUpdateRequest.UraChange.
If the UE selects a cell within a different URA, the UE will start the URA update
procedure, pegging the PM counter NumUraUpdateRequest.UraChange. The number of
Cell Update requests due to reselection is pegged by
NumCellUpdateRequest.CellReselect.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-13
Issue a, October 2005
See notice on first page
RACH
access procedure failures
.................................................................................................................................................................................................................................
Overview
When
When
When
When
The RACH procedure has been successfully performed when the RRC Connection
Request message is received by the RNC upon successful decoding at the Node B.
RACH procedure
Uu
Node B
Iub
RNC
RACH Preamble
RACH Preamble
RACH Preamble
Access indication
(AICH)
RRC
RACH message
(RRC Connection Request)
RRC
NumBadRACHTransBlock
NumGoodRACHTransBlock
Timer settings
Guard timer T300 (determined by UTRAN parameter t300) and N300 (determined by
UTRAN parameter n300) supervises the transmission of the RRC Connection Request
message on the UE side.
Poor settings of timer n300 may result in insufficient retransmission of the RACH
message and poor settings for timer t300 may result in RACH messages being
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-14
retransmitted too early or too late and thus affecting the procedures that initiated the
RACH access (for example call setup).
Upon reception of the RRC Connection Request message at the RNC, PM counter
NumRRCConnAtt is incremented by one. When the UE is not able to either
successfully attach to the network or successfully perform a Location Update, the Cell
Selection/Reselection procedures fails and the UE enters a limited service state.
Failure symptoms
There are four PM counters that may help to identify RACH Access problems:
NumRRCConnAtt, NumBadRACHTransBlock, NumGoodRACHTransBlock and
ChannelOccupRateRACH
Improvement suggestions
The fixes for improvement depend on the detected reason for the failure:
NodeB does not decode the RACH Preamble
Possible reasons:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-15
Issue a, October 2005
See notice on first page
The RACH coverage of the best server is too poor in terms of low Ec/Io that might
be caused by:
Possible reasons:
The UE receives a NACK on the AICH if the NodeB detects the RACH Preamble, but
does not have enough resources to process the RACH Message Part.
NodeB does not decode the RACH Message
Possible reasons:
The maximum allowed power on the RACH is set too low. In this case, the settings
of the two UTRAN parameters sIB3MaxAllowedULTxPower and
sIB4MaxAllowedULTxPower have to be optimized
The power settings configuring the DPCCH relative power of the RACH Message
Part is set too low. In this case, the power settings of physicalRACHpreambleThreshold and PowerOffsetPpm have to be optimized.
The power settings configuring the DPDCH relative power of the RACH Message
Part is set too low. In this case, the power settings of gainFactorBc and
gainFactorBd have to be optimized.
Unsuccessful retransmission of the RACH Message Part. Possible reason is not
optimal UTRAN parameter settings of t300 and n300.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-16
Contents
Introduction to RRC connection establishment
6-18
6-20
6-21
6-23
Paging failures
6-26
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-17
Issue a, October 2005
See notice on first page
Introduction
to RRC connection establishment
.................................................................................................................................................................................................................................
RRC Connection establishment procedure
RRC Connection Establishment starts with the successful receipt at the RNC of the
RRC Connection Request message. This means that cell selection/re-selection as well
as Random Access Detection procedures have been successfully completed.
Call setup stages
In case of a mobile originated call setup, the RRC Connection Establishment procedure
may be categorized into the following basic stages:
1. Call Admission Control (CAC) at the RNC
2. Node B Application Part (NBAP) Radio Link Setup (including transport bearer and
synchronization)
3. RRC Connection Setup.
Note: For a mobile terminating call the paging procedure proceeds the random access
procedure.
An example of a mobile originated call flow:
UE
Uu
Node B
Iub
RRC Connection Req
(RACH)
RRC
RNC
RRC
CAC
NBAP
RL Setup Request
1
NumRRCConRej
NBAP
2
NBAP
RRC
RL Setup Response
NBAP
RRC
3
RRC
NumRRCConEstFail
RRC
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-18
NumRRCConnEstFail
NumRRCConnRej
Successful RRC connections establishment rate.
The RRC Connection Establishment Failures may occur due to following reasons:
Most of these failure causes are normally associated with poor RF conditions.
Low values of KPI RRC Connections Establishment Rate may also be due to RRC
Connections Failures occurring during other procedures such as Network Attach, SMS
and Location Update.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-19
Issue a, October 2005
See notice on first page
Call
admission control failures
.................................................................................................................................................................................................................................
Introduction
Call admission control (CAC) is used to prevent overload of the system. Load
conditions for the downlink are based on the total transmit power of the cell. The
uplink load measure is the measured RSSI value relative to the typical noise floor that
was estimated using long term measurements.
If the defined load thresholds for CAC are exceeded the RRC connection establishment
request is denied and a RRC Connection Reject message with cause Congestion is sent
by the RNC to the UE.
Related PMs / KPIs
NumRRCConnRej
Average transmitted carrier power
Forward power overload duration
Maximum transmitted carrier power
Maximum received signal strength indicator.
Other counters related to system load such as Forward Power Overload Duration,
Average Transmitted Carrier Power, Maximum Transmitted Carrier Power and
Maximum Received Signal Strength Indicator may be used to verify that the load in the
cell is fairly high, which would increase the probability for call setup failures.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-20
Radio
link setup failure
.................................................................................................................................................................................................................................
Introduction
Once the RNC has verified that the requested resources have passed the Call
Admission Control check, the RNC requests the Node B to allocate these resources
through the NBAP Radio Link Setup procedure. In general at least one radio link has
to be set up; in case of soft/softer handover at call set-up more than one radio link has
to be set-up.
This procedure may fail due to different reasons such as:
In all failure cases the RNC sends back to the UE an RRC Connection Reject
message with cause unspecified.
No Traffic Channel Resources available
In order to allocate the requested resources, the RNC sends the Radio Link Setup
Request message to the relevant Node B. Upon reception of the Radio Link Setup
Request message, the Node B reserves the necessary resources and sends back the
Radio Link Setup Response message to the RNC.
If the establishment of at least one radio link fails, the Node B sends back the Radio
Link Setup Failure message to the RNC.
Typical failure causes can be classified as following:
Failure symptoms
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-21
Issue a, October 2005
See notice on first page
Improvement suggestions
Assuming that no faults have been detected at NodeB via alarm analysis, the most
likely failure cause is the one related to the unavailability of NodeB traffic resources.
In order to limit the occurrence of this failure cause, it is also recommended to
carefully review the link dimensioning plan according to the link allocation strategies.
As the Radio Link Setup Request is transferred over NBAP on Iub, the availability of
transport and transmission resources is critical for success.
Traffic analysis focused on the critical Node Bs should be done by looking also at
RAB sessions active and soft/softer traffic. RAB assignment is handled by Radio
Access Network Application Part (RANAP) on Iu links, so particular RANAP
resources on transport/transmission layer impacts the radio link setup success. Actual
impacts could be caused by ATM QoS profile settings in the UTRAN and the transport
network.
NodeB traffic card faulty
Besides the RX-related problems, radio link setup failures may be caused by a faulty
Channel Unit in the UCU card. Open an Alarm entity of the RNC to which the NodeB
is connected and check whether alarms for UCU cards are displayed.
Iub links down
On Service Specific Connection Oriented Protocol (SSCOP) POLL and STAT Protocol
Data Units (PDUs) are sent regularly in uplink and downlink in order to check the link
status. The POLL PDU is used to request, across an SSCOP connection, status
information about the peer SSCOP entity. The STAT PDU is used to respond to this
status request (POLL PDU) received from a peer SSCOP entity. Check with a protocol
analyzer connected to Iub whether these PDUs are being sent. If the PDUs cannot be
seen, the Iub link must be checked.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-22
RRC
connection setup failure
.................................................................................................................................................................................................................................
Introduction
Once the NBAP radio link setup procedure has been successfully completed and the
transport bearer has been established and synchronized, the UTRAN initiates the RRC
connection setup procedure to complete the RRC connection establishment.
The performance measurement NumRRCConnEstFail is used to record failures
occurred during the RRC Connection Setup procedure.
Before starting this procedure the Serving RNC (SRNC) assigns a Radio Network
Temporary Identity (RNTI) to the UE. If the RNTI pool in an RNC runs out of range,
the RRC Connection Setup is not possible. This could be the case if the RNTI pool
size is below the number of mobiles requiring RNTIs at the same time.
The process
At this stage the RNC sends the RRC Connection Setup message, resets counter
V30001 and starts its internal guard timer T30001 (determined by UTRAN parameter
uERRCConnSetupGuardTimer). When the RNC receives the RRC Connection Setup
Complete message sent on the Dedicated Control Channel (DCCH) before T30001
expires, the RNC stops T30001 and the UE is in CELL DCH mode.
If the RNC does not receive the RRC Connection Setup Complete message before
T30001 expires, the RNC may start again sending the RRC Connection Setup
message on the Forward Access Channel (FACH) depending on the status of counter
V30001:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-23
Issue a, October 2005
See notice on first page
The following figure shows the call flow of the unsuccessful case.
NumRRCConnEstFail.
The RRC Connection Setup message is not successfully decoded due to poor
FACH coverage
The RNC cannot successfully decode the RRC Connection Setup Complete
message.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-24
Failure symptoms
RRC Connection Reject message is sent from the RNC to the UE with cause
unspecified upon maximum number of RRC Connection Setup message
retransmissions being reached.
RRC Connection Requestmessage is received at the RNC with value of the IE
Protocol error indicator set to True. This indicates that the RRC Connection
Setup message received at the UE was either invalid or requesting an unsupported
configuration.
Improvement suggestions
The suggested fixes will depend on the root cause. Below are the possible root causes
and their possible solutions:
The UTRAN parameter uERRCConnSetupGuardTimer and maxRRCConnSetupRetries are not optimally set. In this case, it might be useful to increase one or both
parameters according to the dependencies and recommended settings provided in
UMTS ParCat.
The RRC Connection Setup message is not successfully decoded due to poor
FACH coverage.
The reasons might be:
Pilot pollution: In case of pilot pollution the RF environment has to be
optimized by e.g. antenna tilting, variation of the power settings of single
NodeBs etc.
The power of the FACH determined by UTRAN parameter fACH.maxPower is
not sufficient.
The RNC cannot decode the RRC Connection Setup Complete message
successfully. In this case, increasing the power (defined by parameter
DPCCH_power_offset) to be used at radio link set-up on the UL DCH by the UE
may help to increase the probability of successful decoding. Note that increasing
the UL DCH power may increase UL interference.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-25
Issue a, October 2005
See notice on first page
Paging
failures
.................................................................................................................................................................................................................................
Paging procedure
In case of an MT call the UE in Idle state has to be paged before sending the RRC
Connection Request message. The RRC paging type 1 message is sent on the Paging
Channel (PCH) by the core network (this means 3G-MSC for circuit-switched calls or
SGSN for packet-switched calls) to all the UEs belonging to the same Location Area
(LA) (in case of a CS MT call) or to the same Routing Area (RA) (in case of a PS MT
call).
In a successful case the UE receives and correctly decodes the paging message and
sends back the RRC Connection Request message with the relevant cause to the
UTRAN (this means Terminating High Priority Signaling for PS calls and Terminating
Conversational Call for Voice calls).
However it may occur that the UE either does not receive or does not correctly decode
the Paging message.
PMs / KPIs indications
The failure causes can be identified via UTRAN counter NumPageAttDiscard, PCH
Traffic can be evaluated via counter ChannelOccupRatePCH.
Note: Paging related PMs and KPIs are typically derived from the CN.
Related PMs / KPIs
NumPageAttDiscard
ChannelOccupRatePCH.
Note: Paging related PMs and KPIs are typically derived from the core network.
Possible failure causes
In general the possible failure causes are Paging Channel (PCH) congestion or poor
PCH coverage.
Also issues on transport network may impact the Paging procedure as:
Transport
messages
Transport
Transport
Transport
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-26
Paging failures
Improvement suggestions
If the identified cause is poor PCH coverage, the power of the PCH should be
increased via parameter pCHPower. To increase the UEs probability of successfully
decoding the PCH, the pilot and Transport Format Combination Index (TFCI) bits
within the S-CCPCH frames may be transmitted at a higher power by power offsets
defined via parameters secondaryCCPCH.powerOffset1 and secondaryCCPCH.powerOffset2 respectively. .
If this failure occurs in the network due to PCH congestion, actions have to be taken to
improve the Location Area and the Routing Area plan. The Paging Channel (PCH) is
normally dimensioned such that it meets the needs for the expected normal paging
traffic and the performance requirements of MT calls. Over dimensioning the PCH
leads to a waste of resources.
Furthermore, the implementation within UTRAN of UTRAN mobility states allows a
further reduction of the use of the PCH as paging can be done on a cell basis or URA
(UTRAN registration Area) basis rather than in all UTRAN cells of a particular RA or
LA.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-27
Issue a, October 2005
See notice on first page
Contents
Introduction
6-29
6-32
6-33
6-34
No answer from UE
6-35
Code starvation
6-36
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-28
Introduction
.................................................................................................................................................................................................................................
RAB establishment procedure
As soon as the RRC connection establishment procedure has been completed, the call
setup procedure is finalized via the RAB Establishment procedure.
The RAB Establishment procedure is executed in case of call setup with:
The RAB Establishment procedure is initiated by the core network, this means SGSN
for PS calls or 3G-MSC for CS calls, upon receipt of an RRC/RANAP Uplink Direct
Transfer message from the UE requesting either a Packet Data Protocol (PDP) Context
Activation (PS call) or a Call Setup (CS call). This procedure is successfully completed
upon receipt of RANAP RAB Assignment Response message at the core network.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-29
Issue a, October 2005
See notice on first page
Introduction
Node B
Uu
SRNC
Iu-ps
Iub
RRC UL Direct Transfer
(PS: PDP Context Request
CS: Call Setup Request)
CN
RANAP RAB
assignment request
2
ALCAP Iu transport bearer establishment
DBC
NumRABEstFail.Load
NumRLReconfigFail.sum
NumRABEstFail.RBSetupFail
NumRABEstFail.T3
The RAB Establishment procedure for both PS and CS calls may be categorized into
the following basic stages:
1.
2.
3.
4.
5.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-30
Introduction
When RAB Establishment Failures occur then KPI Total RAB Establishment Success
Rate is affected due to total number of RAB establishment failures that incorporates all
the RAB Establishment Failure causes. Some of the failure causes listed above can be
identified via specific PM counters as depicted in the signaling flow.
The Total RAB Establishment Success Rate is the percentage of calls for all supported
service types that successful established a RAB, against the number of valid calls
requested. Since the only part of the UMTS network considered here is the UTRAN,
the call is identified as a Radio Access Bearer (RAB).
Related PMs / KPIs
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-31
Issue a, October 2005
See notice on first page
Dynamic
bearer control failures
.................................................................................................................................................................................................................................
Introduction
During RAB establishment the Dynamic Bearer Control (DBC) procedure is triggered.
(See RAB establishment call flow (p. 6-30)). DBC failure will result in assignment
of a lower data rate. In case even the lowest data rate can not be assigned, the RAB
establishment is rejected incrementing NumRABEstFail.Load. If the value of this
counter indicates that an overload situation has occurred, then the root cause of this
overload situation should be investigated.
Average Transmitted Carrier Power, Maximum Transmitted Carrier Power and
Maximum Received Signal Strength Indicator may be used to verify that the load in the
cell is fairly high.
Related PMs / KPIs
NumRABEstFail.Load
Forward Power Overload Duration
Average transmitted carrier power
Maximum transmitted carrier power
Maximum received signal strength indicator.
If the value of this counter indicates that an overload situation has occurred, then the
root cause of this overload situation should be investigated.
Other system load counters
Other counters related to system load such as Forward Power Overload Duration,
Average Transmitted Carrier Power, Maximum Transmitted Carrier Power and
Maximum Received Signal Strength Indicator may be used to verify that the load in the
cell is fairly high.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-32
Radio
link reconfiguration failures
.................................................................................................................................................................................................................................
Introduction
The NBAP radio link reconfiguration procedure is responsible for preparing a new
configuration of all existing radio links related to one RRC connection within a Node
B. (See RAB establishment call flow (p. 6-30)).
Radio link reconfiguration procedure
The radio link reconfiguration procedure is initiated by the RNC on sending the NBAP
Radio Link Reconfiguration Prepare message to the Node B. Upon reception, the Node
B reserves necessary resources for the new configuration of the existing Radio Link(s)
accordingly and sends back the NBAP Radio Link Reconfiguration Ready message to
the RNC.
Radio link reconfiguration failure
If the Node B cannot reserve the necessary resources then the procedure fails and an
NBAP Radio Link Reconfiguration Failure message is sent back to the RNC instead of
an NBAP Radio Link Reconfiguration Ready message.
PMs / KPIs indications
NumRLReconfigAtt
NumRLReconfigFail.sum.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-33
Issue a, October 2005
See notice on first page
Radio
bearer establishment failures
.................................................................................................................................................................................................................................
Introduction
Once the required resources have been successfully reconfigured in the Node B, the
RRC Radio Bearer Establishment procedure is executed in order to set up a new Radio
Bearer at the UE.
Radio bearer establishment procedure
The RNC sends the Radio Bearer Setup message to the UE that sends back the Radio
Bearer Setup Complete message to the RNC upon successfully allocating resources for
the new Radio Bearer.
Radio bearer establishment failures from UE
Upon receiving the Radio Bearer Setup message the UE may not successfully allocate
the required resources to set-up the new Radio Bearer. In this case the UE sends back
the Radio Bearer Setup Failure message to the RNC and the Radio Bearer
Establishment procedure fails.
Possible reasons for Radio Bearer establishment failures are:
NumRABEstFail.RBSetupFailure
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-34
No
answer from UE
.................................................................................................................................................................................................................................
Introduction
Upon sending the RRC Radio Bearer Setup message to the UE, a guard timer is started
on the RNC in order to supervise the reception of the RRC Radio Bearer Setup
Complete message from the UE. The guard timer is configured by UTRAN parameter
uERadioBearerSetupResponseTimer. If the guard timer expires and no message is
received from the UE, then the Radio Bearer Establishment procedure fails and all the
allocated UTRAN resources are released.
No answer from UE failures
Normal reason for this failure scenario is due to poor RF conditions, which could
result because of poor coverage or high interference.
In addition, too low a setting of timer uERadioBearerSetupResponseTimer with respect
to the UE response time may be the failure cause.
PMs / KPIs indications
This failure causes degradation of KPI RAB Establishment Success Rate. The specific
UTRAN PM counter NumRABEstFail.T3 is triggered when the guard timer expires.
Related PMs / KPIs
NumRABEstFail.T3.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-35
Issue a, October 2005
See notice on first page
Code
starvation
.................................................................................................................................................................................................................................
Introduction
The number of times there is no channelization code available is counted using the PM
counter NumRABEstFail.CodeStarv. If this happens quite often it can contribute to an
increased number of failed RAB establishments. Chat applications are considered the
most important cause of code starvation issues.
Related PMs / KPIs
NumRABEstFail.CodeStarv.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-36
Exercises
.................................................................................................................................................................................................................................
Exercises
The fault in which card of the Node B could lead to a Radio link setup failure?
a
MCR
CTU
IOU
UCU
d
2
Which of the following KPIs indicates RRC SIB message decoding failure?
a
NumRRCConRej
NumRRCConnEstFail
NumBadRACHTransBlock
d
3
Paging
c
4
Give a possible reason for a poor success rate of RRC Setup Establishment? Select all that apply.
a
a, b, c
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
6-37
Issue a, October 2005
See notice on first page
Exercises
1
6
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
6-38
C all reliability
7
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Dropped calls analysis
7-2
7-5
7-6
7-8
7-9
7-10
7-11
7-12
7-13
Failures on RLC
7-14
7-16
7-18
Exercises
7-19
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-1
Issue a, October 2005
See notice on first page
Call reliability
Dropped
calls analysis
.................................................................................................................................................................................................................................
Introduction
As soon as the call is successfully set up, the second factor influencing UMTS user
perception is the probability of maintaining the call, as opposed to the probability of
dropping the call.
A call drop is defined as an abnormal termination of a voice/data session due to any
reason causing the user to re-initiate the session. Where a drop on a PS session will
still result in PDP context preservation, and the end user will be able to re-establish
seamlessly (with some delay). PS drops are generally not as severe for end users as CS
drops.
On the UTRAN side, KPI RAB Dropping Rate, defined as the percentage of dropped
RAB due to any reason against the total number of established RABs for all services,
can be calculated.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-2
Call reliability
Signaling flow
Uu
Node B
Iub
RNC
Iu-ps
SGSN
RRC
RRC
RANAP
NumRABDrop.sum
Iu release command
(UTRAN generated reason)
RANAP
RANAP
On the UTRAN call handling procedures the dropped RABs are identified by either a
RANAP Iu Release Request message or RANAP Reset Resource message sent by the
RNC to the core network. When a Release Request message is sent, the resources on
the UTRAN and core network are released.
Note: For PS calls the PDP context will not be released.
Possible failing reasons
The major components that constitute RAB Drops may be classified as follows:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-3
Issue a, October 2005
See notice on first page
Call reliability
pilot pollution
DL power overload.
Operator interaction (for example lock action)
Inter-RAT handover due to supervision timer expiry (UMTS to GSM)
URA_PCH time-out (due to the UE not performing a periodical URA update)
Iu, Iub and Iur link failure
RRC Signal Connection Release Indication sent by the UE.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-4
Call reliability
Radio
link failures analysis due to synchronization issues
.................................................................................................................................................................................................................................
Introduction
Radio Link Failures (RLF) due to synchronization issues can take place in both the
downlink and uplink. The physical layer in the Node B and UE checks the
synchronization status of every radio frame.
Radio link states
RL Restore
Initial
state
RL Failure
Out-of-sync
state
In-sync
state
RL Restore
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-5
Issue a, October 2005
See notice on first page
Call reliability
RLF
and Radio Link Restore in the Uplink
.................................................................................................................................................................................................................................
Introduction
The RLF and Radio Link Restore procedures in the uplink are supervised in the Node
B by the NBAP protocol. As each UE may have more than one uplink radio link
allocated (e.g. in soft/softer handover status), the Node B needs to monitor the
complete radio link sets to trigger RLF and Radio Link Restore procedures.
Triggering the RLF procedure
When the radio link set is in the in-sync state and the NodeB is receiving
N_OUTSYNC_IND consecutive out-of-sync indications, Node B starts timer
T_RLFAILURE (T_RLFAILURE is determined by UTRAN parameter tRLFailure,
N_OUTSYNC_IND by UTRAN parameter noOutSyncInd).
The Node B stops and resets timer T_RLFAILURE upon receiving successive
N_INSYNC_IND in-sync indications (determined by UTRAN parameter noInSyncInd).
If T_RLFAILURE expires, the NodeB triggers the RLF procedure and indicates which
radio link set is out-of-sync. When the RLF procedure is triggered, the state of the
radio link set changes to the out-of-sync state. In this case, the Node B indicates the
RLF to the RNC by sending a Radio Link Failure Indication on NBAP with the cause
Synchronisation Failure.
RNC and the RLF indication
Upon reception of the Radio Link Failure Indication with cause Synchronisation
Failure the RNC starts timer T_RL_RESYNCH (determined by UTRAN parameter
radioLinkFailureResynchronisationResponseTimer).
If the RNC receives from the NodeB the NBAP Radio Link Restore Indication
message, timer T_RL_RESYNCH is stopped and no further action is taken. The Radio
Link Restore Indication is sent in case the radio link set is previously in the
out-of-sync state and N_INSYNC_IND successive in-sync indications are received. The
NodeB indicates which radio link set has re-established synchronization. When the
Radio Link Restore procedure is triggered, the state of the radio link set changes to the
in-sync state.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-6
Call reliability
Upon expiry of timer T_RL_RESYNCH, the RNC removes the particular radio link in
the NodeB via the NBAP Radio Link Deletion procedure. The following two cases
have to be distinguished:
The UE has more than one Radio Link either to several cells or in case of a
multiple link scenario to one or several cells. In this case, the RNC starts the RRC
Active Set Update procedure (which will not lead to a dropped call).
If the dropped radio link is the last one the UE is connected to, the call is dropped
and the RNC sends the RANAP Iu Release Requestmessage with specified cause
Release due to UTRAN generated reason to the CN. When a UE loses the radio
connection in CELL DCH, the UE may initiate a new cell selection by transitioning
to CELL_FACH state/idle mode.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-7
Issue a, October 2005
See notice on first page
Call reliability
RLF
and Radio Link Restore in the Downlink
.................................................................................................................................................................................................................................
Introduction
In the CELL DCH State, the UE starts timer T313 after receiving N313 consecutive
out-of-sync indications for the established DPCCH physical channel.
The UE stops and resets timer T313 upon receiving successive N315 in-sync
indications. If T313 expires, the UE considers that the radio condition is terminated
with an RLF.
1 or more radio links
The UE has more than one Radio Link either to several cells or in case of a
multiple link scenario to one or several cells. In this case, the RNC starts the RRC
Active Set Update procedure (which will not lead to a dropped call).
If the dropped radio link is the last one the UE is connected to, the call is dropped.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-8
Call reliability
RLF
failure: Poor RF coverage
.................................................................................................................................................................................................................................
Introduction
Uplink or downlink synchronization may be lost due to poor RF coverage. Note that
because of the cell breathing effect, the area where drop calls could occur may change
with the cell load.
Failure symptoms
Poor coverage can be detected with RF Call Trace enabled (for UL measurements) and
UE tracing (for the DL measurements). Low Ec and Ec/Io values are expected in either
UL and/or DL.
Furthermore, high transmit power in the UL and/or DL direction is expected. A
protocol analyzer can discover RLF due to synchronization problems by identifying
RLF messages.
Cell breathing can be detected by changes in the measured Ec/Io on the same drive test
route. Note that the received Ec values are constant whereas the Io values changes with
the cell load.
Improvement suggestions
Poor RF coverage may be caused by faulty hardware (e.g. broken RF cable or faulty
antenna). Other reasons may be a non-optimized RF environment or simply coverage
holes in the network.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-9
Issue a, October 2005
See notice on first page
Call reliability
RLF
failure: Poor PSC plan
.................................................................................................................................................................................................................................
Introduction
A poor PSC plan can cause RLF due to synchronization if there are two cells sharing
the same PSC that are relatively close to each other. In coverage overlapping areas
both sites will interfere with each other in the DL because the PSCs of both cells are
non-orthogonal.
Another problem can also happen if two cells sharing the same PSC are relatively
close to each other, but do not necessarily have overlapping coverage areas. It may
happen that the RNC is mixing up the two cells and requesting to add a leg to the
wrong cell via the RRC Active Set Update procedure.
Due to the high number of PSCs that are available for the network design it should be
possible to create a proper PSC design for every network.
Failure Symptoms
Layer 1 UE logging can reveal interference in the DL. A protocol analyzer helps to
discover RLF due to synchronization problems. An indication for poor PSC planning
might also be high BLER in a good coverage area.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-10
Call reliability
RLF
failure: Pilot pollution and Around-the-Corner problem
.................................................................................................................................................................................................................................
Introduction
Pilot pollution means an excessive overlapping of pilots with no dominant pilot. This
leads to poor Ec/Io ratios and, in combination with the Around-the-Corner problem, to
sudden drops of the Ec/Io. As a consequence, the RLF could fail due to being
out-of-synchronization.
Failure symptoms
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-11
Issue a, October 2005
See notice on first page
Call reliability
RLF
failure: Poorly defined neighbor list
.................................................................................................................................................................................................................................
Introduction
Poorly defined neighbor lists (too many neighbors or missing neighbors) can cause the
UE to have radio links to non-optimal cells or to be unable to add a leg to an optimal
cell. The consequence might be poor Ec and Ec/Io of the cells in the active set. To
maintain the call the UE and NodeB have to transmit with higher power than required.
The call may drop caused by RLF due to being out-of-synchronization.
Failure symptoms
Low Ec and Ec/Io values and high UE transmit power can be discovered. Missing
neighbors are currently not reported as detected cells to the OMC-U.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-12
Call reliability
RLF
failure: Improved Aggregate Overload Control
.................................................................................................................................................................................................................................
The Improved Aggregate Overload Control (IAOC) has three main functions:
Ensures that the value of the demanded power remains within the linear range of
the power amplifier
Performs the amplifier protection based on power measurements
Controlling the maximum overall transmit power on a sector-carrier.
The function is located in the NodeB and is controlled by NodeB internal parameters.
The IAOC may scale down the DL transmit power on the Dedicated Channels (DCH)
if one of the three items above are out-of-range. This will impact the DL closed loop
power control mechanism that may lead to a RLF due to synchronization issues.
Failure symptoms
Usually if Load Control algorithms such as Dynamic Bearer Control and Congestion
Control are working correctly, IAOC should be rarely invoked by the Node B. Only
after specific investigations and clear proof that IAOC misbehavior is causing RLF
issues should settings of some IAOC parameters require optimization. .
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-13
Issue a, October 2005
See notice on first page
Call reliability
Failures
on RLC
.................................................................................................................................................................................................................................
Basic tasks
When timer protected PDUs are not acknowledged before the timer elapses, the PDUs
are retransmitted.
If retransmitted timer protected PDUs are unacknowledged for a certain time:
Go either to SDU discard or RLC reset of the RLC connection between the two
entities
If SDU discard does not succeed, go to RLC reset of the RLC connection between
the two entities
If RLC reset does not succeed, signal unrecoverable error to higher layers. In this
case the RRC might be dropped and the UE performs a Cell Update and the IE
AM_RLC error indication is set to TRUE.
To identify each PDU has (for DL and UL and per RLC entity separately) an
increasing SN (0, {, 4095 for AM, 0,{,127 for UM). Upon transmission, the data PDUs
are stored in a retransmission buffer when they are submitted to the MAC and PHY
layer. If a data PDU is NACK, it can be retransmitted.
ARQ uses the following mechanism:
Status reporting on the RX: the RX sends a status report in STATUS PDUs
containing a detailed list of received and missing PDUs. STATUS PDUs have
priority over retransmitted data. They can be sent periodically or unsolicited e.g.
after loss detection
Polling from TX: the TX can request a status report
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-14
Call reliability
Failures on RLC
Window mechanism: a sliding window allows the TX to transmit new PDUs while
waiting for the ACKs till end of the window size.
SDU discard function: when the delivery of a SDU cannot be managed because of
repeated errors, the transmission of SDUs is stopped and discarded on both TX and
RX side.
Failures on RLC
The following table lists problems that can be detected in interface traces and the
corresponding KPIs in the PM system:
Problem
Trace
Trigger
RLC Resets
Iub
RLC retransmission
Iub
Iub
Uu
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-15
Issue a, October 2005
See notice on first page
Call reliability
Network
interface outages
.................................................................................................................................................................................................................................
Introduction
Hardware failures can occur on the different nodes of the UTRAN and the CN, but
also on the particular interfaces.
There are many reasons for outages; analysing the FM data can retrieve a good
indication for the failure cause.
Potential problems
drops of the RAB and the RRC connection because of missing synchronisation
coverage issues
problems in the neighbour definition
problems in the cell/PLMN selection/reselection procedure
network accessibility might be limited.
Identifying outages
Outages can be easily identified when tracing the interfaces that have been out-of-sync.
Problem
Trace
Trigger
Iub out-of-sync I
Iub
Iub out-of-sync II
Iub
Any occurrence of an
AuditRequiredInformation
on NBAP
Iu out-of-sync I
Iu
Iu out-of-sync II
Iu
The most important KPIs describing the drops of the RABs due to network outages:
PM system
Formula
Precondition
Trouble
value
UTRAN
NumRABDropsNodeBFail /
NumRABSUM * 100
NumRABSUM >
X
>Y
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-16
Call reliability
PM system
Formula
Precondition
Trouble
value
UTRAN
NumRABDropsRNCFail /
NumRABSUM * 100
NumRABSUM >
X
>Y
UTRAN
NumRABDropsIubFail /
NumRABSUM * 100
NumRABSUM >
X
>Y
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-17
Issue a, October 2005
See notice on first page
Call reliability
Network
level retainability KPIs
.................................................................................................................................................................................................................................
Introduction
The retainability KPIs (all service types) is derived from the relation of total dropped
RABs to the total successful established RABs.
KPIs per service types
Lucent Retainability KPI CSV, which is the same as (1 - RAB dropping rate for
CSV12).
Lucent Retainability KPI CSD, which is the same as (1 - RAB dropping rate for CS
data)
Lucent Retainability KPI PSD, which is the same as (1 - RAB dropping rate for
PS).
When one of the Lucent Retainability KPI values is very low, this may be caused by
many different issues. Therefore it is advised to localize the issue by analyzing the
performance measurements and the possible failing reasons. There are several possible
failing reasons of abnormal RAB disconnects.
Some of the important reasons are:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
7-18
Call reliability
Exercises
.................................................................................................................................................................................................................................
1
A RAB drop does not always lead to a user- perceived dropped call because:
a
a
2
Where are the RLF and Radio Link Restore procedures in UL supervised?
a
UE by the RRC
C
3
A dropped call due to an RLC error can be easily identified by which of the following messages?
a
b
4
Which of the following load control functions should have the highest parameter
setting?
a
Congestion Control
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
7-19
Issue a, October 2005
See notice on first page
Overview
.................................................................................................................................................................................................................................
Objectives
Identify parameters that have a direct influence on the users perception of call
quality
Assess the quality of different UMTS services using KPIs
State the possible causes of high BLER rate
Identify QoS voice service parameters
Identify QoS data service parameters.
Contents
Network level quality KPIs
8-2
8-4
8-6
8-8
Exercises
8-11
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
8-1
Issue a, October 2005
See notice on first page
Network
level quality KPIs
.................................................................................................................................................................................................................................
Introduction
Although the call is successfully set up and maintained the user may perceive that the
quality of the call itself is poor. In case of a voice call this quality degradation can be
directly experienced during the conversation. In case of data call the poor quality may
cause throughput degradation.
Quality KPI
UL and DL Block Error Rate (BLER) are the KPIs providing an indication of the
quality of the UMTS call. The Lucent quality KPI capture the uplink failure on RNC
basis:
= 1- NumTransBlockErrUL 100 [%]
NumTransBlockTotUL
The quality KPI is derived from the uplink block error rate for all services (CSV, CSD,
PS).
Poor quality reasons
High values of the quality KPI indicates that the perceived uplink quality of the call is
poor. Usually this also has an impact on the UL/DL throughput related KPIs.
In order to correctly identify the root cause of high UL/DL BLER values, the UE and
the Node B transmitted power should be checked respectively:
If the UE and/or the Node B transmitted power has reached the maximum allowed
value, then the most likely root cause is given by poor RF conditions that are
limiting either the downlink or the uplink, or both.
If the UE and/or the Node B transmitted power has not reached the maximum
allowed value, then the most likely root cause is given by respectively UL and/or
DL Closed Loop Power Control issues.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
8-2
Basic root cause analysis method for high UL/DL BLER issues:
Poor RF
conditions
Yes
Max UE / Node B
transmitted power
reached?
No
UL/DL
power
control issues
Note: It should not be assumed that UL BLER issues will also result in DL BLER
issues and vice versa. In several scenarios the system may be either only uplink or
only downlink limited due to unbalanced loads.
Related PMs / KPIs
Other counters related to system load such as UL transport block error rate CSV, UL
transport block error rate CSD and UL transport block error rate PS may be used to
verify that the load in the cell is fairly high, which would increase the probability for
call setup failures.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
8-3
Issue a, October 2005
See notice on first page
Uplink
Block Error Rate (BLER)
.................................................................................................................................................................................................................................
Introduction
UL BLER is calculated at the RNC and normally should stay within a target quality
value that is defined depending on the supported radio bearers. For example for data,
the target quality value is currently equal to 5%, for voice it is equal to 0.8%.
Either poor RF conditions or UL Closed Loop Power Control issues may cause high
UL BLER values.
Poor RF Conditions
Poor RF conditions increase the probability of receiving blocks not correctly decoded
at the RNC. This means that if the UE transmitted power has already reached the
allowed limit, UL BLER may still show values higher than the target value.
If the analysis of the metrics above show UL BLER degradation is caused by poor RF
conditions (poor RF coverage or high UL interference), correct the conditions as shown
in RLF section.
If not, issues with UL Closed Loop Power Control may be causing the problem.
UL Closed Loop Power Control issues
UL Closed Loop Power Control can be split in two loops, i.e. Outer Loop and Inner
Loop.
1. The Outer Loop, located at the RNC, is responsible for updating the SIR target
according to the measured UL BLER in order to keep the UL target quality value
(e.g. UL BLER equal to 5% for PS services) of the UL Dedicated Channel (DCH).
2. The Inner Loop, located at the NodeB, is responsible for sending the Power
Control commands to the UE upon comparison of estimated SIR with the target
SIR provided by the Outer Loop. The UE adapts its transmitted power according to
the Power Control commands received by the NodeB.
Specific UTRAN parameters are responsible for the proper working of both Outer
Loop and Inner Loop. Usually these parameters are expected to be optimized before
Network Deployment and not to be changed afterwards.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
8-4
Figure
Improvement suggestions
If Outer Loop is not quickly updating the SIR target, the UL BLER may show values
greater than the target value for long periods of time. Note that UL BLER values much
lower than the target value (e.g. 1% to 2% with a target value of 5%) may cause
quality degradation due to UE transmitting at a higher power than necessary, causing
higher UL interference.
If analysis of the metrics is showing that in some scenarios the SIR target is not
quickly updated (i.e. UL BLER values are not distributed around the target value)
according to the measured UL BLER this issue should be escalated to System
Engineering.
If throughput or voice quality metrics are showing degradation even with UL BLER
values distributed around the target value this means the UL BLER target value is not
properly set. Since this target value can be differentiated by service type (i.e. PS/CS
and different supported data rate), further investigations should be requested.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
8-5
Issue a, October 2005
See notice on first page
Downlink
Block Error Rate (BLER)
.................................................................................................................................................................................................................................
Introduction
DL BLER is calculated at the UE and normally should stay within its target quality
value defined for the DL DCH on a per radio bearer basis as for UL BLER.
High DL BLER values may be caused by:
Poor RF conditions or
DL Closed Loop Power Control issues.
Poor RF conditions
Poor RF conditions increase the probability of receiving blocks not correctly decoded
at the UE.
Assuming DL Closed Loop Power Control is working properly, if the NodeB
transmitted power reaches the allowed limit on the DL DCH, DL BLER may still show
values higher than the target one due to RF issues.
Detecting poor RF conditions
Different UE traces including a CDMA air interface tester, RF Call Trace running in
parallel. After importing all traces into an analyzer, the following metrics should be
analyzed and correlated:
As for the Uplink, DL Closed Loop Power Control can be split into two loops, both
located in the UE:
Outer Loop
Inner Loop.
The Outer Loop is responsible for updating the SIR target according to the measured
DL BLER in order to keep the DL target quality value (e.g. DL BLER equal to 5%) of
the DL Dedicated Channel (DCH).
The Inner Loop is responsible for sending the Power Control commands to the NodeB
upon comparison of estimated SIR with the target SIR provided by the Outer Loop.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
8-6
The NodeB adapts its transmitted power according to the Power Control commands
received by the UE.
Detecting DL Closed Loop Power Control Issues
Assuming that RF issues are not the cause, investigate using the following metrics:
It should be verified that as soon as the DL BLER increases, the NodeB Transmitted
Power is increased and vice versa.
DL BLER should have values distributed around the defined target value to ensure that
the Closed Loop is working properly.
Analysing DL Closed Loop Power Control Issues
If analysis of the metrics shows that the SIR target is not quickly updated, escalate
the issue to System Engineering.
If throughput or voice quality metrics show degradation even with UL BLER
values distributed around the target value, the UL BLER target value is not set
properly. Further investigations are needed.
Assuming that Outer Loop Power Control is working properly at the UE, if the
NodeB Transmitted Code Power displays values close or equal to the maximum DL
DCH allowed power, parameter setting maxDLpower should be changed. Note that
this may cause decrease of DL capacity, as each single user will be allowed to use
more DL power on the DCH.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
8-7
Issue a, October 2005
See notice on first page
Quality
of Service (QoS)
.................................................................................................................................................................................................................................
Introduction
Quality of Service is more specific than the more general term quality.
QoS has to do with getting the particular service the user asks for:
Because of the asymmetry of the UMTS links, it is necessary to measure the UL and
DL voice quality separately. The equipment compares the received voice samples with
the transmitted voice samples. In this way, the evaluation software can do voice quality
classification for both directions independently.
The table below gives the QoS parameters for voice services. For the voice quality
evaluation, the Mean Opinion Score (MOS) is used. The MOS is defined by the ITU
and ranges from 1 to 5. For GSM Enhanced Full Rate (EFR) the theoretical maximum
is 4.3. Good voice quality can be considered when the MOS exceeds 3.0. Voice quality
degradation such as echo or voice delay are reflected by this measure.
The table below provides QoS parameters for voice services based on MOS.
Mean Opinion Score (MOS)
QoS value
Below 2.0
Poor
2.0 to 3.0
Fair
3.0 to 4.0
Good
Above 4.0
Excellent
Mobile subscribers surfing the Internet or downloading files from their companys
network could face data quality problems in UMTS networks. The user may complain
about low throughput rate, losses of connection or jitter.
The radio bearer can be dynamically assigned depending on traffic measurements or
load. Even the mobile state may be changed to idle mode/URA_PCH/CELL_PCH
mode.
Depending on the status of the RLC queue in the UE, the mobile might send :
The RNC may or may not react to these Measurement Reports by doing an RB
reconfiguration.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
8-8
A smaller radio bearer can be assigned if overload estimations are made by the RNC.
RRC Re-establishment
Another difference when describing the user perceived QoS for PS data services is a
feature called RRC Re-establishment. A drop of the RAB and RRC connection does
not (necessarily) mean that the PDP Context is removed from the GGSN or the FTP
session drops. After RRC Re-establishment, the FTP session can be resumed if the
session has not timed out in between.
For the user the drop of the RRC and RAB is visible by stalling of the FTP transfer
for the particular time-frame and because of low throughput rates. In case of real time
applications like video streaming or web radio the drop will be noticed by the user if
the buffer of the application is emptied and no new data is received.
Data service parameters
The following table shows parameters important for data service QoS:
Parameter
Description
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
8-9
Issue a, October 2005
See notice on first page
Configuration problems on the client PC, the network connection between GGSN
and the server (in the Internet) or configuration problems on the (Internet) server.
Packet loss, packet delay or packet corruption on the way between the GGSN and
the RNC.
Bad RF performance.
Non-optimized RLC parameter settings and RLC resets.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
8-10
Exercises
.................................................................................................................................................................................................................................
1
UL/DL SIR
UL/DL BLER
NumRABDrop.sum
maxDLpower
b
2
UE
Node B
RNC
b
3
At the UE, what does the Outer Loop Power Control do if the DL BLER is
higher than the target BLER value?
a
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
8-11
Issue a, October 2005
See notice on first page
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Soft/Softer Handover
9-3
9-4
9-5
9-8
Poor RF conditions
9-10
9-11
9-12
No UE answer
9-13
UE reject
9-14
9-16
9-17
9-18
9-20
9-21
9-22
9-23
Relocation failures
9-25
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-1
Issue a, October 2005
See notice on first page
Overview
9-26
9-30
9-31
9-32
9-34
Exercises
9-36
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-2
Soft/Softer Handover
Overview
.................................................................................................................................................................................................................................
Objectives
Contents
Soft/Softer Handover failure classification
9-4
9-5
9-8
Poor RF conditions
9-10
9-11
9-12
No UE answer
9-13
UE reject
9-14
9-16
9-17
9-18
9-20
9-21
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-3
Issue a, October 2005
See notice on first page
Soft/Softer
Handover failure classification
.................................................................................................................................................................................................................................
Classification
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-4
Soft/softer
handover failures in non-CELL DCH state
.................................................................................................................................................................................................................................
Introduction
If the UE is in a state other than CELL DCH and it is located in Soft/softer Handover
area, then it is possible that - during the transition to CELL DCH state - the UE goes
directly in Soft/softer Handover (S/SHO).
The non-CELL DCH state is applicable to the following scenarios of S/SHO:
at Call Setup
at Call Re-establishment
for UL Data Transfer in URA PCH
for DL Data Transfer in URA PCH
for DL Data Transfer in CELL_FACH.
Important! Failures in S/SHO in non-CELL DCH state are not identifiable via any
specific performance measurement or key performance indicator!
Scenarios
In all four scenarios the UE sends intra-frequency measurements to the RNC within
either RRC Connection Request or RRC Cell Update message.
Upon evaluating the UE measurements, the RNC decides whether the UE can enter the
CELL DCH state already in soft/softer handover. When the SHO algorithm condition is
fulfilled, the UTRAN allocates radio link resources before sending a confirmation
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-5
Issue a, October 2005
See notice on first page
message to the UEs. Afterwards, the UTRAN indicates to the UE to which links the
UE has to be connected before sending back a completion message.
Scenario
Step 2:
Link asignment indication
message
RRC RB Reconfiguration
Complete
2
3
4
Failures
Failure symptoms
The following symptoms can be the root cause of S/SHO failures in non-CELL DCH
state:
activeSetSizePS
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-6
activeSetSizeCS
AddThresholdSHO
Retrieve from UE logs as well as from Iub traces the RRC Connection Request
messages that include at least one reported pilot belonging to the Monitored Set
in the Information Element measured results on RACH.
Retrieve from UE logs as well as from Iub traces the RRC Connection Setup
Complete message corresponding to the test calls.
If the percentage is lower than 100% the following steps are required:
Evaluate the Ec/Io measured on the best cell. Retrieve the relevant NBAP
Radio Link Set-up (or Addition) Request/Response Connection Request and
identify failure-related messages.
Retrieve UE logs and from Iub traces the relevant RRC Connection Setup
message and identify:
either any failure-related message
or any message not answered by the UE.
Improvement suggestions
If calls are set up with too many pilots requesting to be in the Active Set, this may
result in failures caused by CAC algorithm or by unavailable NodeB resources.
Proper settings of all parameters:
MaxNoReportedCellsOnRACH
activeSetSizePS
activeSetSizeCS
AddThresholdSHO
should be performed to limit this scenario.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-7
Issue a, October 2005
See notice on first page
Soft/softer
handover failures in CELL DCH state
.................................................................................................................................................................................................................................
Introduction
If the UE is in CELL DCH state and it is located in Soft/softer Handover area, there
are three events for a soft/softer handover procedure:
Failures
Poor RF Conditions
Incorrect translations settings
No NodeB resources available
No transport resources available
No UE answer
UE Reject
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-8
NodeB/RNC Outages
Failure symptoms
The various failures and their symptoms, identification techniques, and improvement
suggestions for both Intra-RNC and Inter-RNC Soft handover are described in detail in
the following sections of this lesson.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-9
Issue a, October 2005
See notice on first page
Poor
RF conditions
.................................................................................................................................................................................................................................
Introduction
Poor RF conditions may cause issues along SHO procedure as well as in general on
maintaining the call. Investigation techniques and suggested fixes for improvements are
covered with Radio Link Failures in the Call reliability and optimization lesson.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-10
Node
B resource dry-up
.................................................................................................................................................................................................................................
Introduction
Upon successful decoding of Measurement Report message, the RNC allocates the
required resources at the NodeB over:
Failures
NodeB rejects the resource allocation request when no physical resources are available:
NumRLSetupFail.NodeBRes
NumRLAddFail.NodeBRes
Improvement suggestions
For Node B resource dry-up failures, the following improvement suggestions may
apply:
Improve RF coverage
Minimize Interference
Minimize the impact of round-the-corner effect
Adjust the uEActiveSetUpdateResponseTimer setting as best trade-off
between:
soft/softer handover delay minimization and
UE response time requirements.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-11
Issue a, October 2005
See notice on first page
Transport
resources dry-up
.................................................................................................................................................................................................................................
Introduction
The NBAP Radio Link setup or Radio Link Addition procedure may fail.
Failure symptoms
NumRLSetupFail.TransRes
NumRLAddFail.TransRes
The relevant NBAP messages Radio Link Setup Failure and Radio Link
Addition Failure triggering those counters can be retrieved via Iub traces.
Improvement suggestions
Capacity analysis focused on the Iub links traffic should provide recommendations for
optimized Iub links traffic distribution.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-12
No
UE answer
.................................................................................................................................................................................................................................
Introduction
Upon successful resource allocation in the NodeB, the RNC sends the RRC Active Set
Update message to the UE with the RRC Active Set Update procedure. A guard timer
is started on the RNC to supervise the reception of the RRC Active Set Update
Complete message from the UE.
The timer uEActiveSetUpdateResponseTimer defines the maximum value of the
guard timer.
Failures
The Active Set Update procedure fails if the guard timer expires and no message is
received from the UE or poor RF conditions exist due to poor coverage or high
interference.
Failure symptoms and identification techniques
Improve RF coverage
Minimize Interference
Minimize the impact of round-the-corner effect
Adjust uEActiveSetUpdateResponseTimer setting as best trade-off between
soft/softer handover delay minimization and
UE response time requirements.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-13
Issue a, October 2005
See notice on first page
UE
reject
.................................................................................................................................................................................................................................
Introduction
Upon sending the Active Set Update message, the RNC receives Active Set Update
Failure message from the UE due to:
Invalid configuration,
Incompatible simultaneous reconfiguration, or
Protocol Error.
Normally these failures are expected to occur seldom as they indicate incorrect
configurations in either the RNC or the UE due to RRC signaling issues like delays
or internal problems in UE or RNC.
Failures
If the Primary Scrambling Code (PSC) plan is not optimized and contiguous cells have
same PSC, the RNC may mix up the cells when receiving the Measurement Report
message from the UE.
The RNC then allocates resources to the wrong NodeB and sends an Active Set Update
message to the UE with an incorrect configuration.
Failure symptoms
Identification techniques
The following techniques will help to to identify the specific failure cause:
Improvement suggestions
Best trade-off between the processing load on the UE and the synchronisation
time
Effectively the performance of synchronisation procedure
Assign code groups to neighbouring cells/sectors which have smaller cross
correlation values with other codes of the group so that during initial cell
search, the UE will correctly identify the code in stage 3 of the cell search
process.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-14
UE reject
Important! The code groups which show poor cross correlation characteristics
should be allocated as far away as possible.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-15
Issue a, October 2005
See notice on first page
Hardware
or link outage
.................................................................................................................................................................................................................................
Introduction
At the OMC-U it can be checked whether alarms will be reported for this NodeB.
This is, however, in the area of Fault Management and not Call mobility optimization.
Failures
At the OMC-U Alarm specific reports are displayed for a particular Node B or RNC.
Failure symptoms
Identification techniques
Improvement suggestions
Detailed descriptions on the various alarms to be monitored are available in the RNC
and NodeB OAM Manuals.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-16
Incorrect
translation settings -Overview
.................................................................................................................................................................................................................................
Overview
In general, the handover translation parameters can be categorized into four main
thematic areas:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-17
Issue a, October 2005
See notice on first page
Incorrect
translations settings - measurement and reporting
.................................................................................................................................................................................................................................
Introduction
For specific issues, a number of parameters may need to be properly tuned in order to
improve the soft/softer handover performance:
measQty.filterCoefficient
reportingCellStatus.reportedCell
defines which set of cells (i.e. Active, Monitored or Detected) can trigger the
event of adding a pilot to the Active Set and are being measured by the UE
reportingCriteria1A.rcReportingInterval and
reportingCriteria1C.rcReportingInterval
define the report periodicity for reporting events Adding a pilot (1A) to or
Replacing a pilot (1C) in the Active set respectively
NumUndeclHORejPerNcell
is triggered when a detected cell not belonging to the neighbors list is reported
by the UE in order to be included in the Active Set.
Failure symptoms
Performance/quality degradation
Decreased soft/softer handover success rate
Further increase of dropped call rate.
Identification techniques
Drive tests including RF Call Trace will help to identify the specific failure cause:
Improvement suggestions
Setting of measQty.filterCoefficient
to low values speeds up the handover decision
Setting of parameter reportingCellStatus.reportedCell
allows UE to measure and report also Detected Set pilots helps to identify the
strong interferers. If the strong interferer does not belong to the neighbors list
then the pilot is not added to the Active Set.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-18
Setting of reportingCriteria1A.rcReportingInterval
reportingCriteria1C.rcReportingInterval
and
to low values increases the probability that Measurement Report messages are
successfully decoded at the UTRAN and helps to minimize the delay in the
soft/softer handover procedure
Setting of NumUndeclHORejPerNcell
is part of the Handover matrix counters and can be imported in an Undeclared
Neighbor List tool for neighbor plan optimization purposes.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-19
Issue a, October 2005
See notice on first page
The Neighbor List Selection Algorithm (NLSA) is used to set up a list of the most
effective pilot neighbors to be monitored by the UE to reduce UEs response time to
detect new pilots. A subset of the neighbor list defined and optimized during RF
planning and optimization, located in the RNC. This sub-list provides the updated
monitored set list to the UE via RRC Measurement Control message upon S/SHO
successful execution.
The NLSApriority setting within the attribute outFDDAdjCells defines the search
priority used in the NLSA. It is set on a per neighbor cell basis.
Failure symptoms and identification techniques
Improvement suggestions
The following suggestions may help to improve the performance with respect to the
Neighbor List Selection Algorithm.
Correlate the results of drive test analysis with the ones from system performance,
parameter settings and handover traffic:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-20
Incorrect
translation settings - Active Set Update procedure
.................................................................................................................................................................................................................................
Introduction
Upon successful resource allocation in the NodeB, the RNC sends the RRC Active Set
Update message to the UE via the RRC Active Set Update procedure. A guard timer is
started on the RNC to supervise the reception of the RRC Active Set Update Complete
message from the UE.
The attribute uEActiveSetUpdateResponseTimer defines the maximum value of the
guard timer.
The Active Set Update procedure fails if:
the guard timer expires and no message is received from the UE, or
poor RF conditions exist due to:
poor coverage or
high interference.
If the Active Set Update procedure fails, all the allocated UTRAN resources are
released simultaneously.
Important! If the setting of the timer uEActiveSetUpdateResponseTimer with
respect to the UE response time may is too low, this may also be a failure cause.
Improvement suggestions
The following suggestions may help to improve the performance with respect to the
Active Set Update procedure:
Improve RF coverage
Minimize interference
Minimize the impact of round-the-corner effect
Adjust uEActiveSetUpdateResponseTimer setting as best trade-off between:
soft/softer handover delay minimization and UE response time requirements.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-21
Issue a, October 2005
See notice on first page
Contents
Inter-system handover failures - overview
9-23
Relocation failures
9-25
9-26
9-30
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-22
Inter-system
handover failures - overview
.................................................................................................................................................................................................................................
Introduction
A handover to another network system or inter Radio Access Technology (inter RAT)
handover is always a hard handover with MSC involvement.
The UTRAN initiates the Relocation Preparation Procedure at the Iu interface towards
the MSC of the GSM network. The UE must have established at least a Circuit
Switched (CS) connection to the UMTS network.
The inter RAT-Handover can be performed for the following RAB combinations:
The inter-system handover algorithm for UMTS to GSM handover is developed for
UMTS coverage islands, which are located within a GSM network providing full
coverage within a certain area and for UMTS/GSM networks overlapping only in their
border regions.
The Lucent inter-system handover feature supports various handover algorithms to
provide optimum solutions dependent on customer needs:
DAHO
Handover is triggered based on serving cell measurements. The target cell
selection is solely performed on network configuration data without any
measurements of the GSM frequency.
MAHO
Handover is triggered based on GSM measurements performed by the UE and
serving cell measurements.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-23
Issue a, October 2005
See notice on first page
RRC Redirection
RRC redirection can be used to avoid call establishment in UMTS. If RRC
redirection is active, UTRAN redirects the UE to GSM immediately on RRC
connection request.
Directed Retry
Directed Retry allows for early handover to GSM before Radio Access Bearer
(RAB) resources are assigned in UMTS. At this time, the UE has a signalling
connection in UMTS only. On receipt of the RAB Assignment from the MSC,
the UTRAN rejects the RAB Assignment with cause directed retry and
initiates the handover procedure to GSM.
Failure classes
The inter RAT handover procedures may fail due to the following reasons:
Some of these failures are due to Network planning errors, others are the result of
features that are not activated (yet). However, most of them are detected later in the
optimization process.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-24
Relocation
failures
.................................................................................................................................................................................................................................
Failure symptoms and identification techniques
Parameters
hoRelocGuardTimer
TRELOCprep
TRelocOverall
TRELOCcomplete.
Improvement suggestions
The following suggestions for parameter values may help to improve the performance
with respect to the Relocation procedure:
TRELOCcomplete
KPIs
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-25
Issue a, October 2005
See notice on first page
Handover
procedure failures
.................................................................................................................................................................................................................................
Introduction
UMTS to GSM
The handover decision algorithm detects up to three potential GSM target cells, which
are used for successive handover attempts. If the handover procedure has failed for all
suitable GSM target cells, the handover decision algorithm is invoked again. If the
handover fails because the UE is not able to establish the call in the GSM system due
to insufficient radio conditions, successive handover attempts are not executed.
Handover algorithms
In certain networks or areas of a network it may not be possible to have a proper cell
planning that allows for the usage of DAHO. Therefore a second algorithm, which is
called mobile assisted handover (MAHO) takes into account the received signal
strength of the GSM neighbor cells at the current location of the UE.
Failures
The other two causes are expected to occur rarely and in general are not related to
RF issues.
Failure Symptoms
The following failure symptoms may apply during the handover procedure:
CS call drop
GSM access blocking
Call quality deterioration
HO delay
HO failure
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-26
Frequent HO
PS call drop.
The inter RAT handover combines the handover between two independent networks,
hence there is no KPI that can bridge this gap. The solution is to check and evaluate
the parameter and timer expiry settings according to the failure symptoms detected.
Cause
Explanation
Suggestion
RNC retriggering
interval for HO
attempt too long
TRELOCprep <
hoRelocGuardTimer
RNC cancellation of
active relocation too
long
TRELOCcomplete <
TRelocOverall
High value of
CS call drop
HO to GSM triggered
too late and UE
leaves the UMTS
coverage area before
it has received the
handover command
from the UMTS
Physical channel
failure
umts2GsmQTriggerDAHO.timeToTrigger
setting or
umts2GsmQTriggerDAHO.timeToTrigger
CheckIRATHO.FailOutCS.PhyChnFail content
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-27
Issue a, October 2005
See notice on first page
Cause
Explanation
Suggestion
Low value of
Adjust
umts2GsmQTriggerDAHO.threshold trigger
inter-RAT DAHO too late when the actual
quality drops below the threshold specified
for the quality of the own system (UMTS
frequency).
umts2GsmQTriggerDAHO.
threshold parameter setting
Adjust umts2GsmHOMeas.
combinedGsmNeighbourListSize parameter setting
HO delay
selection from too
long Neigbor list size
combinedGsmNeighbourListSize causes
refer to Relocation
procedures
No GSM cell
available
Low value of
Adjust umts2GsmHOMeas.
gsmQualityThreshold
umts2GsmHOMeas.gsmQualityThreshold
parameter setting
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-28
Cause
Explanation
Suggestion
High value
umts2GsmHOMeas.gsmFilterCoefficient
Adjust umts2GsmHOMeas.
gsmFilterCoefficient
parameter setting
High value of
Adjust
umts2GsmQTriggerDAHO.threshold triggers
umts2GsmQTriggerDAHO.
thresholdparameter setting
KPIs
Release
procedure failures
.................................................................................................................................................................................................................................
Introduction
Upon successful allocation of GSM resources in UE and GSM RAN, the 3G MSC
initiates the release of the UMTS resources in the UTRAN over the Iu Release
Command Message.
Failures
In general, failures are not expected to occur at this stage. It is assumed that no
outages occur in the UTRAN. The only failure cause due to reasons other than
UTRAN outages is given at the expiry of 3G-MSC timer TrelocOverall.
Failure symptoms and identification techniques
The setting of 3G-MSC timer TrelocOverall should should be checked against setting
of the timers hoRelocGuardTimer and TRELOCprep.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-30
Contents
Location update failure
9-32
9-34
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-31
Issue a, October 2005
See notice on first page
Location
update failure
.................................................................................................................................................................................................................................
Introduction
A UE that has registered to the CS-CN-domain and it is in IDLE state, monitors the
Location Are Code (LAC) is broadcast over the Uu interface BCCH.
When the UE detects a change in LAC, it requests a Location Update (LU). Upon
expiry of the timer T3212 the UE performs a LU periodically. The timer will be reset
at any Mobility Management communication. After a successful LU procedure the
CS-CN stores the current Location Area per mobile in the VLR record of the UE.
Failures
The following suggestions may help to improve Location Update failure issues:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-32
KPIs
The Location Update Success Rate can be evaluated by three separated KPIs:
InterVLRGeolLUSuccRate =
(succInterVLRGeoLocationUpdates
/attInterVLRPerioLocationUpdates)
*100%
IntraVLRGeoLUSuccRate =
(succIntraVLRGeoLocationUpdates
/attIntraVLRGeoLocationUpdates)
*100%
IntraVLRPerioLUSuccRate = (succIntraVLRPerioLocationUpdates
/attIntraVLRPerioLocationUpdates)
*100%.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-33
Issue a, October 2005
See notice on first page
Routing
update failure
.................................................................................................................................................................................................................................
Introduction
Similar to the Location Update, the Routing Area (RA) Update keeps the PS Core
Network updated on the UEs position.
A UE that has registered to the PS-CN domain and is either in IDLE state or in URA
PCH state, monitors the Routing Are Code (RAC) that is broadcast over the Uu
interface BCCH.
When the UE detects a change in RAC, it requests a Location Area Update (RAU).
Upon a geographical trigger or the expiry of the timer T3312 the UE performs a RAU
periodically. The timer will be reset at any GMM communication. After a successful
LU procedure the PS-CN stores the current Location Area per mobile in the SGSN
record of the UE.
Failures
Note: With respect to the periodical Routing Area Update by Mobility Management
communication, a high number of RAUs in particular areas may result in high
signaling traffic and call failures.
Improvement suggestions
The following suggestions may help to improve Location Update failure issues:
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-34
KPIs
There is no direct impact from Routing area design to the RAU failure rate. An
indirect impact is the evaluation of the volume of geographic RAUs that contributes to
the load on the resources used during RAU with the following related KPIs:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
9-35
Issue a, October 2005
See notice on first page
Exercises
.................................................................................................................................................................................................................................
Exercises
Which of the following soft/softer handover failures can occur in CELL FACH
state? Select all that apply.
a
1, 3
2
Which failure symptoms can occur at a soft/softer handover? Select all that apply
a
1, 2, 4
3
What reasons would cause a call that should be handed over to GSM to be retained in UMTS?
a
1, 2
4
Which feature of the inter-system handover algorithm for UMTS to GSM handover is used to avoid call establishment in UMTS?
a
RRC Redirection
Directed Retry
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
9-36
10
10
UTRAN
end-to-end key
performance indicators
Overview
.................................................................................................................................................................................................................................
Objectives
This lesson gives an overview over the key performance indicators (KPIs) for
end-to-end call setup and Quality of Service (QoS) within the UTRAN cluster.
What are KPIs?
KPIs are summarized quality and performance indicators which display a generalized
overall performance or quality status of the network.
KPIs can be subdivided into:
KPIs can be computed from a number of performance and control counters on cell,
cluster and network level.
Which KPIs are described here?
KPIs for
KPIs
KPIs
KPIs
KPIs for
KPIs
KPIs
KPIs
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-1
Issue a, October 2005
See notice on first page
Overview
Contents
KPIs for the Circuit Switched domain
10-3
10-4
10-9
10-14
10-18
10-19
10-24
10-30
10-35
10-36
10-38
Exercises
10-40
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-2
This lesson section gives an overview over the key performance indicators (KPIs) for
end-to-end call setup and Quality of Service (QoS) within the Circuit Switched (CS)
domain for the UTRAN cluster.
Contents
KPI for Mobile-originated end-to-end call setup in the Circuit Switched
domain
10-4
10-9
10-14
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-3
Issue a, October 2005
See notice on first page
This gives an overview over the key performance indicators for the mobile-originated
end-to-end call setup in the Circuit Switched domain (CS MO E2E).
Definitions for CS MO E2E call setups
CC Alerting
RRC Connection Request
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-4
RRC
RRC
connection
establishment
Uu
Node B
Iub
RRC connection
request (cause)
RNC
Iu-cs
CN
RRC
NBAP
Radio Link
setup request
NBAP
NBAP
Radio Link
setup response
NBAP
RRC
RRC connection
setup
RRC
RRC
RRC connection
setup complete
RRC
RRC
Measurement
control
RRC
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-5
Issue a, October 2005
See notice on first page
Uu
Node B
Iub
Initial direct
transfer
MM CM
service request
MM authentication
and ciphering
request
MM authentication
and ciphering
response
Security
mode
MM CM
service accept
CC setup
RNC
Iu-cs
CN
RRC
SCCP
Connection
request
SCCP
SCCP
Connection
confirm
SCCP
RANAP
Initial UE
message
RANAP
RANAP
RRC
Downlink
direct transfer
RRC
RRC
Initial direct
transfer
RRC
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Security mode
command
RANAP
RANAP
Security mode
complete
RANAP
RANAP
Common
ID
RANAP
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
RRC
Security mode
command
RRC
RRC
Security mode
complete
RRC
RRC
Downlink
direct transfer
RRC
RRC
Uplink
direct transfer
RRC
RANAP
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-6
Uu
Node B
Iub
RNC
RANAP
RAB assignment
NBAP
Radio Link
reconf.request
NBAP
NBAP
Radio Link
reconf.response
NBAP
RRC
Radio Bearer
setup request
RRC
RRC
Radio Bearer
setup complete
RRC
RANAP
CC call
proceeding
RANAP
RRC
Downlink
direct transfer
RRC
Downlink
direct transfer
CC connect
acknowledgement
RAB assignment
RANAP
request
RAB assignment
RANAP
response
Direct
transfer
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
RRC
RANAP
CC connect
CN
RRC
RANAP
CC alerting
Iu-cs
RRC
Downlink
direct transfer
RRC
RRC
Uplink
direct transfer
RRC
RANAP
Counters
UE (part)
RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail
RABFailEstab.T3
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-7
Issue a, October 2005
See notice on first page
Parts
Counters
NodeB (part)
SHO.FailRLSetupIubUTRANSide.NodeBRes
SHO.FailRLSetupIubUTRANSide.TransRes
RRC.FailConnEstab.RLSetupFailure
RRC.FailConnEstab.CAC
RRC.FailConnEstab.CAC
RABFailEstab.CodeStarv
RAB.FailEstabPSNoQueuing.DLIntfer
RNC (part)
VS.RRC.FailConnEstab.ProcessorLoad
The following counters are valid for all end-to-end call setups:
Counter name
Part
Description
RRC.FailConnEstab.RLSetupFailure
Node B
SHO.FailRLSetupIubUTRANSide.NodeBRes
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.SetupIncomplete
UE
UE
RABFailEstab.CodeStarv
Node B
RAB.FailEstabPSNoQueuing.DLIntfer
Node B
RABFailEstab.T3
UE
RAB.FailEstab.RBSetupFail
UE
VS.RRC.FailConnEstab.ProcessorLoad
RNC
SHO.FailRLSetupIubUTRANSide.TransRes
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-8
This gives an overview over the key performance indicators for the mobile-terminated
end-to-end call setup in the Circuit Switched domain (CS MT E2E).
Definitions for CS MT E2E call setups
CC Alerting
RRC Paging Type 1
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-9
Issue a, October 2005
See notice on first page
Uu
Node B
Iub
RANAP
Paging Type 1
RRC
RRC
RRC
connection
establishment
RNC
Paging
RRC connection
request (cause)
Iu-cs
Paging
CN
RANAP
RRC
RRC
NBAP
Radio Link
setup request
NBAP
NBAP
Radio Link
setup response
NBAP
RRC
RRC connection
setup
RRC
RRC
RRC connection
setup complete
RRC
RRC
Measurement
control
RRC
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-10
Uu
Node B
Iub
Initial direct
transfer
MM paging
response
MM authentication
and ciphering
request
MM authentication
and ciphering
response
Security
mode
MM CM
service accept
CC setup
RNC
Iu-cs
CN
RRC
SCCP
Connection
request
SCCP
SCCP
Connection
confirm
SCCP
RANAP
Initial UE
message
RANAP
RANAP
RRC
Downlink
direct transfer
RRC
RRC
Initial direct
transfer
RRC
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Security mode
command
RANAP
RANAP
Security mode
complete
RANAP
RANAP
Common
ID
RANAP
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
RRC
Security mode
command
RRC
RRC
Security mode
complete
RRC
RRC
Downlink
direct transfer
RRC
RRC
Uplink
direct transfer
RRC
RANAP
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-11
Issue a, October 2005
See notice on first page
Uu
Node B
Iub
RNC
RANAP
RAB assignment
NBAP
Radio Link
reconf.request
NBAP
NBAP
Radio Link
reconf.response
NBAP
RRC
Radio Bearer
setup request
RRC
RRC
Radio Bearer
setup complete
RRC
RANAP
CC call
confirm
RRC
Uplink
direct transfer
CC alerting
Uplink
direct transfer
CC connect
CC connect
acknowledgement
RRC
Uplink
direct transfer
Downlink
direct transfer
RAB assignment
RANAP
request
RAB assignment
RANAP
response
Direct
transfer
RANAP
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RRC
RANAP
RRC
CN
RRC
RANAP
RRC
Iu-cs
RRC
RRC
Counters
UE (part)
RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail
RABFailEstab.T3
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-12
Parts
Counters
NodeB (part)
SHO.FailRLSetupIubUTRANSide.NodeBRes
SHO.FailRLSetupIubUTRANSide.TransRes
RRC.FailConnEstab.RLSetupFailure
RRC.FailConnEstab.CAC
RRC.FailConnEstab.CAC
RABFailEstab.CodeStarv
RAB.FailEstabPSNoQueuing.DLIntfer
RNC (part)
VS.RRC.FailConnEstab.ProcessorLoad
The following counters are valid for all end-to-end call setups:
Counter name
Part
Description
RRC.FailConnEstab.RLSetupFailure
Node B
SHO.FailRLSetupIubUTRANSide.NodeBRes
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.SetupIncomplete
UE
UE
RABFailEstab.CodeStarv
Node B
RAB.FailEstabPSNoQueuing.DLIntfer
Node B
RABFailEstab.T3
UE
RAB.FailEstab.RBSetupFail
UE
VS.RRC.FailConnEstab.ProcessorLoad
RNC
SHO.FailRLSetupIubUTRANSide.TransRes
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-13
Issue a, October 2005
See notice on first page
KPI
for end-to-end call drops in the Circuit Switched domain
.................................................................................................................................................................................................................................
Overview
This gives an overview over the key performance indicators for the end-to-end call
drops in the Circuit Switched domain (CS E2E).
Definitions for CS E2E call drops
...
KPI for CS E2E call drops
Parts
CS_MO_E2E_Call_Drop
RF (part)
UE (part)
NodeB (part)
RNC (part)
CS_MO_E2E_Call_Success
CC Alerting
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-14
Counters
RF (part)
RAB.RelPS.Drop.DL_RLF
RAB.RelCS.Voice.CauseRLF
RAB.RelCS.Data.CauseRLF
No. of call drop during hard handover inter-frequency
IRATHO.TRelocOverall
UE (part)
RAB.Rel.Drop.UESigConnRel
NodeB (part)
RAB.Rel.Drop.OpInterv
RNC (part)
RAB.Rel.Drop.UETransDrnc
RAB.Rel.Drop.UEInactivity
Signaling flow
Figure 10-7 Normal CS E2E call release, mobile-originated and mobileterminated
UE
RRC
Uu
Node B
Iub
Uplink
direct transfer
CC Disconnect
CC Release
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Iu release
command
RANAP
Iu release
complete
RANAP
RRC
RRC
Uplink
direct transfer
RRC
RRC
RRC Connection
relelase
RRC
RRC
RRC Connection
release complete
RRC
Radio Link
deletion request
Radio Link
NBAP deletion response
CN
RANAP
Downlink
direct transfer
NBAP
Iu-cs
RRC
RRC
CC Release
complete
Iu Release
RNC
NBAP
NBAP
RANAP
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-15
Issue a, October 2005
See notice on first page
Uu
Node B
RNC
Iub
Iu-cs
CN
No
response
Radio Link
failure indication
NBAP
Iu release
Radio Link
deletion
NBAP
RANAP
Iu release
request
RANAP
RANAP
Iu release
command
RANAP
RANAP
Iu release
complete
RANAP
RANAP
SCCP
release
RANAP
NBAP
Radio Link
deletion request
NBAP
NBAP
Radio Link
deletion response
NBAP
Uu
Node B
RNC
Iub
RRC
Cell update
(RL Failure)
RRC
RRC
Cell update
confirm
RRC
Iu-cs
CN
The following counters are valid for all end-to-end call drop:
Counter name
RAB.RelPS.Drop.DL_RLF
Part
RF
Description
Number of call drop because of Downlink radio link
failure
RAB.RelCS.Voice.CauseRLF, RF
RAB.RelCS.Data.CauseRLF
(Calculated)
RF
RAB.Rel.Drop.UESigConnRel
UE
RAB.Rel.Drop.OpInterv
NodeB
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-16
Counter name
Part
RAB.Rel.Drop.UETransDrnc, RNC
RAB.Rel.Drop.UEInactivity,
Description
Number of call drop for RNC generated reasons.
Part
Description
IRATHO.TRelocOverall
RF
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-17
Issue a, October 2005
See notice on first page
This lesson section gives an overview over the key performance indicators (KPIs) for
end-to-end call setup and Quality of Service (QoS) within the Packet Switched (PS)
domain for the UTRAN cluster.
Contents
KPI for Mobile-originated end-to-end call setup in the Packet Switched
domain
10-19
10-24
10-30
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-18
This gives an overview over the key performance indicators for the mobile-originated
end-to-end call setup in the Packet Switched domain (PS MO E2E).
Definitions for PS MO E2E call setups
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-19
Issue a, October 2005
See notice on first page
RRC
RRC
connection
establishment
Uu
Node B
Iub
RRC connection
request (cause)
RNC
Iu-ps
CN
RRC
NBAP
Radio Link
setup request
NBAP
NBAP
Radio Link
setup response
NBAP
RRC
RRC Connection
setup
RRC
RRC
RRC Connection
setup complete
RRC
RRC
Measurement
control
RRC
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-20
Uu
Node B
Iub
Initial direct
transfer paging resp.
GMM attach
(request)
RNC
Security
mode
SCCP
Connection
request
SCCP
SCCP
Connection
confirm
SCCP
RANAP
Initial UE
message
RANAP
RRC
Downlink
direct transfer
RRC
RRC
Initial direct
transfer
RRC
GMM attach
(complete)
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Security mode
command
RANAP
RANAP
Security mode
complete
RANAP
RANAP
Common
ID
RANAP
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
RRC
Security mode
command
RRC
RRC
Security mode
complete
RRC
GMM attach
(accept)
CN
RRC
RANAP
GMM attach
(authentication
and ciphering)
Iu-ps
RRC
Downlink
direct transfer
RRC
RRC
Uplink
direct transfer
RRC
RANAP
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-21
Issue a, October 2005
See notice on first page
SM
PDP context
activation
(request)
Uu
Node B
Iub
RNC
Uplink
direct transfer
RRC
RRC
RANAP
RANAP
NBAP
Radio Link
reconf.request
NBAP
NBAP
Radio Link
reconf.response
NBAP
RAB assignment
RRC
Radio Bearer
setup
RRC
RRC
Radio Bearer
setup complete
RRC
RANAP
SM
PDP context
activation
(accept)
RANAP
Downlink
direct transfer
RRC
CN
Iu-ps
Direct
transfer
RANAP
RAB assignment
RANAP
request
RAB assignment
RANAP
response
Direct
transfer
RANAP
RRC
Parts
PS_MO_E2E_Call_Success
PS_MO_E2E_Call_
Attempts
Counters
UE (part)
RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail
RABFailEstab.T3
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-22
Parts
Counters
NodeB (part)
SHO.FailRLSetupIubUTRANSide.NodeBRes
SHO.FailRLSetupIubUTRANSide.TransRes
RRC.FailConnEstab.RLSetupFailure
RRC.FailConnEstab.CAC
RRC.FailConnEstab.CAC
RABFailEstab.CodeStarv
RAB.FailEstabPSNoQueuing.DLIntfer
RNC (part)
VS.RRC.FailConnEstab.ProcessorLoad
The following counters are valid for all end-to-end call setups:
Counter name
Part
Description
RRC.FailConnEstab.RLSetupFailure
Node B
SHO.FailRLSetupIubUTRANSide.NodeBRes
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.SetupIncomplete
UE
UE
RABFailEstab.CodeStarv
Node B
RAB.FailEstabPSNoQueuing.DLIntfer
Node B
RABFailEstab.T3
UE
RAB.FailEstab.RBSetupFail
UE
VS.RRC.FailConnEstab.ProcessorLoad
RNC
SHO.FailRLSetupIubUTRANSide.TransRes
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-23
Issue a, October 2005
See notice on first page
This gives an overview over the key performance indicators for the mobile-terminated
end-to-end call setup in the Packet Switched domain (PS MT E2E).
Definitions for PS MT E2E call setups
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-24
Uu
Node B
Iub
RANAP
Paging Type 1
RRC
RRC
RRC
connection
establishment
RNC
Paging
RRC connection
request (cause)
Iu-ps
Paging
CN
RANAP
RRC
RRC
NBAP
Radio Link
setup request
NBAP
NBAP
Radio Link
setup response
NBAP
RRC
RRC connection
setup response
RRC
RRC
RRC connection
setup complete
RRC
RRC
Measurement
control
RRC
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-25
Issue a, October 2005
See notice on first page
Uu
Node B
Iub
Initial direct
transfer paging resp.
GMM paging
response
RRC
GMM attach
(request)
Initial direct
transfer
RNC
Security
mode
SCCP
Connection
request
SCCP
SCCP
Connection
confirm
SCCP
RANAP
Initial UE
message
RANAP
Initial UE
message
RANAP
RRC
RANAP
RRC
Downlink
direct transfer
RRC
RRC
Initial direct
transfer
RRC
GMM attach
(complete)
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Security mode
command
RANAP
RANAP
Security mode
complete
RANAP
RANAP
Common
ID
RANAP
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
RRC
Security mode
command
RRC
RRC
Security mode
complete
RRC
GMM attach
(accept)
CN
RRC
RANAP
GMM attach
(authentication
and ciphering)
Iu-ps
RRC
Downlink
direct transfer
RRC
RRC
Uplink
direct transfer
RRC
RANAP
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-26
SM
PDP context
activation
(request)
Uu
RRC
Node B
Iub
Uplink
direct transfer
RNC
RANAP
NBAP
Radio Link
reconf.request
NBAP
NBAP
Radio Link
reconf.request
NBAP
RRC
Radio Bearer
setup response
RRC
RRC
Radio Bearer
setup complete
RRC
RANAP
SM
PDP context
activation
(accept)
RANAP
RRC
Downlink
direct transfer
CN
RRC
RANAP
RAB assignment
Iu-ps
Direct
transfer
RANAP
RAB assignment
RANAP
request
RAB assignment
RANAP
response
Direct
transfer
RANAP
RRC
Parts
PS_MT_E2E_Call_Success
PS_MT_E2E_Call_Attempts
PS-MT-E2E-call setup
Parts
Counters
UE (part)
RRC_Fail(T_u300) + RRC_Fail(from_UE) +
RB_Fail(from_UE) + RB_Fail (T_RB) + Rel_PS(T3350)
+ Rel_PS(T3360) + Rel_PS(T3385)
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-27
Issue a, October 2005
See notice on first page
PS-MT-E2E-call setup
Parts
Counters
NodeB (part)
RRC_Fail(Err_NodeB) + RRC_Fail(T_RLS) +
Reject_RNC(RRC_code) + Reject_RNC(RRC_pwr) +
RAB_Fail (code) + RAB_Fail (Pwr) + RAB_Fail(Err_
NodeB) + RAB_Fail(T_RL_R) + NodeB_Errors
RNC (part)
PS_CN (part)
Interfaces (part)
Others
Counters
UE (part)
RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail
RABFailEstab.T3
NodeB (part)
SHO.FailRLSetupIubUTRANSide.NodeBRes
SHO.FailRLSetupIubUTRANSide.TransRes
RRC.FailConnEstab.RLSetupFailure
RRC.FailConnEstab.CAC
RRC.FailConnEstab.CAC
RABFailEstab.CodeStarv
RAB.FailEstabPSNoQueuing.DLIntfer
RNC (part)
VS.RRC.FailConnEstab.ProcessorLoad
The following counters are valid for all end-to-end call setups:
Counter name
RRC.FailConnEstab.RLSetupFailure
Part
Node B
Description
No response from NodeB for a signaling Radio link
allocation (Signaling Radio Bearer). This is the number
of T_RLS expiry.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-28
Counter name
SHO.FailRLSetupIubUTRANSide.NodeBRes
Part
Description
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.CAC
Node B
RRC.FailConnEstab.SetupIncomplete
UE
UE
RABFailEstab.CodeStarv
Node B
RAB.FailEstabPSNoQueuing.DLIntfer
Node B
RABFailEstab.T3
UE
RAB.FailEstab.RBSetupFail
UE
VS.RRC.FailConnEstab.ProcessorLoad
RNC
SHO.FailRLSetupIubUTRANSide.TransRes
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-29
Issue a, October 2005
See notice on first page
KPI
for end-to-end call drops in the Packet Switched domain
.................................................................................................................................................................................................................................
Overview
This gives an overview over the key performance indicators for the end-to-end call
drops in the Packet Switched domain (PS E2E).
Definitions for PS E2E call drops
Parts
PS_MO_E2E_Call_Drop
RF (part)
UE (part)
NodeB (part)
RNC (part)
PS_CN (part)
PS_MO_E2E_Call_Success
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-30
Counters
RF (part)
RAB.RelPS.Drop.DL_RLF
No. of call drop during hard handover inter-frequency
VS.IRATHO.TimeoutOutPSUTRAN
UE (part)
RAB.Rel.Drop.UESigConnRel
NodeB (part)
RAB.Rel.Drop.OpInterv
RNC (part)
RAB.Rel.Drop.UETransDrnc
RAB.Rel.Drop.UEInactivity
PS_CN (part)
SM.AttDeactPdpContextSgsn.38
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-31
Issue a, October 2005
See notice on first page
Signaling flow
Figure 10-16 Normal PS E2E call release, mobile-originated and mobileterminated.
UE
RRC
Uu
Node B
Iub
Uplink
direct transfer
Request
SM deactivate
PDP context
Accept
RANAP
RANAP
Direct
transfer
RANAP
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Direct
transfer
RANAP
RANAP
Iu release
command
RANAP
Iu release
complete
RANAP
RRC
Uplink
direct transfer
RRC
RANAP
Request
GMM detach
RRC
RRC
Downlink
direct transfer
RRC
RRC
Uplink
direct transfer
RRC
Complete
Iu Release
Direct
transfer
RRC
Uplink
direct transfer
RRC
RRC Connection
relelase
RRC
RRC
RRC Connection
release complete
RRC
NBAP
Radio Link
deletion request
Radio Link
NBAP deletion response
CN
RANAP
Downlink
direct transfer
RRC
Iu-cs
RRC
RRC
Complete
Accept
RNC
NBAP
NBAP
RANAP
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-32
Uu
Node B
RNC
Iub
Iu-ps
CN
No
response
Radio Link
failure indication
NBAP
Iu release
Radio Link
deletion
NBAP
RANAP
Iu release
request
RANAP
RANAP
Iu release
command
RANAP
RANAP
Iu release
complete
RANAP
RANAP
SCCP
release
RANAP
NBAP
Radio Link
deletion request
NBAP
NBAP
Radio Link
deletion response
NBAP
Uu
Node B
RNC
Iub
RRC
Cell update
(RL Failure)
RRC
RRC
Cell update
confirm
RRC
Iu-ps
CN
The following counters are valid for all end-to-end call drop:
Counter name
RAB.RelPS.Drop.DL_RLF
Part
RF
Description
Number of call drop because of Downlink radio link
failure
RAB.RelCS.Voice.CauseRLF, RF
RAB.RelCS.Data.CauseRLF
(Calculated)
RF
RAB.Rel.Drop.UESigConnRel
UE
RAB.Rel.Drop.OpInterv
NodeB
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-33
Issue a, October 2005
See notice on first page
Counter name
Part
RAB.Rel.Drop.UETransDrnc, RNC
RAB.Rel.Drop.UEInactivity,
Description
Number of call drop for RNC generated reasons.
Part
Description
VS.IRATHO.TimeoutOutPSUTRAN
RF
SM.AttDeactPdpContextSgsn.38
PS_CN
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-34
This lesson gives an overview over the key performance indicators (KPIs) for Quality
of Service (QoS) monitoring within the UTRAN cluster.
Contents
KPIs for Quality of Service monitoring in the CS domain
10-36
10-38
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-35
Issue a, October 2005
See notice on first page
KPIs
for Quality of Service monitoring in the CS domain
.................................................................................................................................................................................................................................
Quality of Service
Delay
The interval between transmitting and receiving packets between two reference
points.
In this case the delay is referred to as RAB setup time.
Delay variation
In this case the delay variations are referred to as Achieved Bitrate distribution
and Transfer delay distribution.
Loss rate
In this case the loss rates are referred to as SDU error ratio and Residual bit
error ratio.
Conversational
Streaming
Delay in sec
<1
~1
Transfer delay
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-36
Formula
When more than one cell is the active set, for each cell the following KPI must be
available per traffic class:
CS RAB Assignment Success Rate (i) =
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-37
Issue a, October 2005
See notice on first page
KPIs
for Quality of Service monitoring in the PS domain
.................................................................................................................................................................................................................................
Quality of Service
Delay
The interval between transmitting and receiving packets between two reference
points.
In this case the delay is referred to as RAB setup time.
Delay variation
In this case the delay variations are referred to as Achieved Bitrate distribution
and Transfer delay distribution.
Loss rate
In this case the loss rates are referred to as SDU error ratio and Residual bit
error ratio.
Conversational
Streaming
Interactive
Background
Delay in sec
<1
~1
< 10
> 10
AchievedBitrate distribution
Transfer delay
X1
X1
X1
X1
X1
X1
X1
X1
Notes:
1.
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-38
Formula
When more than one cell is the active set, for each cell the following KPI must be
available per traffic class:
PS RAB Assignment Success Rate (i) =
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
10-39
Issue a, October 2005
See notice on first page
Exercises
.................................................................................................................................................................................................................................
Exercises
4
2
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
10-40
Index
................................................................................................
................................................................................................
B BLER, 8-2
N N300, 6-14
................................................................................................
Not optimizing
Consequences, 1-4
ChannelOccupRatePCH, 6-26
NumBadRACHTransBlock, 6-14
ChannelOccupRateRACH, 6-14
NumCellUpdateRequest.CellReselect, 6-12
NumGoodRACHTransBlock, 6-14
NumPageAttDiscard, 6-26
................................................................................................
D Definition of optimization, 1-2
................................................................................................
F Forward power overload duration, 6-20
NumRABEstFail.CodeStarv, 6-36
NumRABEstFail.Load, 6-32
NumRABEstFail.RBSetupFailure, 6-34
NumRABEstFail.T3, 6-34, 6-35
NumRLReconfigAtt, 6-33
NumRLReconfigFail.sum, 6-33
NumRRCConnAtt, 6-14
................................................................................................
................................................................................................
6-32
.................................................................................................................................................................................................................................
UM4801-IG.en.A4
Lucent Technologies - Proprietary
IN-1
Issue a, October 2005
See notice on first page
Index
................................................................................................
R RAB dropping rate for CS data, 7-18
6-18
................................................................................................
T T300, 6-14
.................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
UM4801-IG.en.A4
See notice on first page
Issue a, October 2005
IN-2