Professional Documents
Culture Documents
Instructor Guide
UMTS UTRAN Optimization
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.
1 Introduction to optimization
Gathering information
Analyzing information
4 UTRAN Signaling
.................................................................................................................................................................................................................................
iv Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Contents
5 Optimization process
Call availability
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary v
Issue a, October 2005 See notice on first page
Contents
7 Call reliability
.................................................................................................................................................................................................................................
vi Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Contents
Soft/Softer Handover
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary vii
Issue a, October 2005 See notice on first page
Contents
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
KPI for end-to-end call drops in the Circuit Switched domain ............................................................................... 10-14
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
KPI for end-to-end call drops in the Packet Switched domain ............................................................................... 10-30
.................................................................................................................................................................................................................................
viii Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Contents
Index
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary ix
Issue a, October 2005 See notice on first page
List of figures
10-7 Normal CS E2E call release, mobile-originated and mobile-terminated ......................................... 10-15
10-16 Normal PS E2E call release, mobile-originated and mobile-terminated. ........................................ 10-32
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary xi
Issue a, October 2005 See notice on first page
About this information product
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:
• Identify sources of performance data (measurement reports, customer complaints)
• Describe drive testing equipment, methods and tools
• Interpret performance data and traffic measurements to locate trouble spots
• Provide solutions for improving the performance
• Evaluate the effectiveness of counter measures.
Conventions used
Acronyms are explained on their first appearance in the text.
Related documentation
The following related documents are available:
• UMTS Performance measurements definitions manual, 401-382-803R0301
• Flexent ® UMTS Radio Network Controller, Operations, Administration and
Maintenance, 401-382-360R0301
• Flexent ®UMTS Macrocell Indoor, Operation, Administration and Maintenance for
+24 V, 401-382-462R0301
• Flexent ® UMTS Modular Cell Outdoor, Operation, Administration and
Maintenance for +24 V, 401-382-760R0301
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary xiii
Issue a, October 2005 See notice on first page
,
About this information product
Related training
The following related courses are available:
• UM1001 UMTS System Introduction
• UM1911 UMTS Hardware Overview
• UM4304 UTRAN Signaling
• UM4305 UTRAN Processes and Parameter Settings
• UM4301 UTRAN RF Cellular Engineering.
How to comment
To comment on this information product, go to the Online Comment Form
(http://www.lucent-info.com/comments/enus/) or email your comments to the
Comments Hotline (comments@lucent.com).
.................................................................................................................................................................................................................................
xiv Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
,
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
This course is to be delivered as a class-room based instructor-led course.
The classroom
The classroom should contain:
• Tables and chairs for up to 12 students and an instructor
• LCD projector and screen for Microsoft PowerPoint ™ presentation materials
• Flipchart with markers
• Whiteboard with dry erase markers and eraser, or a Chalkboard with chalk
• Bulletin board and thumb tacks
• Power cords for auxiliary power
• Remote maintenance tools
• Personal computers, or workstations, for each student (maximum of two students
per workstation).
Course duration
The course takes five days.
Materials
The following materials are required for this class:
• One paper-based instructor guide
• One PowerPoint presentation
• One paper-based student guide for each student.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary xv
Issue a, October 2005 See notice on first page
,
Course plan prologue Course plan prologue
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.
.................................................................................................................................................................................................................................
xvi Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
,
Part I: Optimization concepts
Overview
.................................................................................................................................................................................................................................
Objectives
After completing the following lessons, you will be able to:
• Define the scope of UTRAN Optimization
• Describe what KPIs are
• Describe the most common Optimization problems and their solutions
• Place the UTRAN protocols and channels in their architectural context
• Place the UTRAN protocols and channels in a call flow context.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary I-1
Issue a, October 2005 See notice on first page
1 I ntroduction to optimization
1
Overview
.................................................................................................................................................................................................................................
Objectives
After completing the following lesson, you will be able to:
• Describe what optimization is
• Explain why optimization is performed
• Explain when optimization must be performed.
Contents
.................................................................................................................................................................................................................................
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
Optimize To make as effective, perfect, or useful as possible.
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).
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
.................................................................................................................................................................................................................................
1-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Introduction to optimization What is optimization?
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 1-3
Issue a, October 2005 See notice on first page
Introduction to optimization
Goal of optimization
The goal of optimization is to fine-tune an existing network to meet the requirements
of an operator in the most efficient way.
Important! Optimization of an existing network must not be used to correct a bad
network design.
Reason Example
Deviations from (planning) assumptions Changes in subscriber behavior (increased
use of a service or a cell)
Changes in operator requirements Increased market share, introduction of
new service
Changes in environment New buildings, snowfall, trees
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.
Subscribers
In a network that is not optimized, subscribers can experience:
• Blocked calls
• Dropped calls
• Smaller RF coverage area
.................................................................................................................................................................................................................................
1-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Introduction to optimization Why optimize a network ?
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
An optimized network increases network coverage and network capacity.
This directly translates into:
• Lower operational and maintenance costs
• Higher number of voice and data users
• Higher average data throughputs
• Higher Quality of Service for voice and data users.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 1-5
Issue a, October 2005 See notice on first page
Introduction to optimization
Network design
Optimization Planning
Implementation
N Acceptance
criteria met?
Network design
& implementation
Y
Live network
In service
optimization
Optimization is performed:
• Before a commercial network launch
• In a live, operational network.
Before a commercial network launch, typical optimization includes:
• Network design optimization
• Optimization based on drive testing.
This document covers in service optimization in a live, operational network, even
though optimization methods and tools are similar during both phases.
Always
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:
• Deviations from (planning) assumptions
• Changes in subscriber behavior
.................................................................................................................................................................................................................................
1-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Introduction to optimization When to optimize a network ?
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 1-7
Issue a, October 2005 See notice on first page
Introduction to optimization
Exercises
.................................................................................................................................................................................................................................
Exercise
.................................................................................................................................................................................................................................
1-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
2 I nformation sources and tools
2
Overview
.................................................................................................................................................................................................................................
Objectives
After completing the following lesson, you will be able to:
• 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
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 2-1
Issue a, October 2005 See notice on first page
Information sources and tools
Gathering information
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe the different tools and information sources that can be used to detect
optimization problems.
• Identify the tools and methods to gather optimization information.
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
.................................................................................................................................................................................................................................
2-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Information sources and tools
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:
• Handover failure rates
• Channel occupancy rates
• Dropped RRC connections rate
• RAB failure rates
• Radio link dropping rates.
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
Information sources and tools
Drive test
.................................................................................................................................................................................................................................
Purpose
Drive tests are performed to measure:
• RF spectrum coverage and interference
• UTRAN parameters (mobile measurements, protocol messages)
• Network quality (call completion, hand over, data rates, voice quality).
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
Components of a typical drive test system (picture provided courtesy of Agilent
Technologies):
.................................................................................................................................................................................................................................
2-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Information sources and tools Drive test
Detecting problems
Drive testing can be useful in detecting most problems that occur:
• 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.
Drive testing can also detect:
• Poor voice reception quality
• Poor data rates.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 2-5
Issue a, October 2005 See notice on first page
Information sources and tools
Customer complaints
.................................................................................................................................................................................................................................
Trouble tickets
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.
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.
.................................................................................................................................................................................................................................
2-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Information sources and tools
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.
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
RF Call trace can be useful to detect all optimization problems.
OCNS can be useful to detect Cell breathing.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 2-7
Issue a, October 2005 See notice on first page
Information sources and tools
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:
• Describe the role of tools to analyze information.
Contents
.................................................................................................................................................................................................................................
2-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Information sources and tools
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 2-9
Issue a, October 2005 See notice on first page
Information sources and tools Data analysis software
Typical output from data analysis software and illustrates a network before and after
optimization:
The dark lines indicate areas that have no coverage. Changes in the shade of the
antennas indicate changes in antenna tilt.
.................................................................................................................................................................................................................................
2-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Information sources and tools Data analysis software
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:
• Interfaces to different vendors of drive test equipment, protocol analyzers and
measurement programs
• Open interfaces
• Multiple technologies
• Interfaces to databases to retrieve and store data
• Synchronization of data from different sources to remove timing variations
• Database querying and filtering to reduce data volumes.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 2-11
Issue a, October 2005 See notice on first page
Information sources and tools
Exercises
.................................................................................................................................................................................................................................
Exercises
.................................................................................................................................................................................................................................
2-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
3 3 ommon optimization problems
C
and their solutions
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:
• Describe and define the problems
• Describe how the problem shows itself in a network
• Explain the consequences for the network and the users
• Suggest possible solutions.
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
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 3-1
Issue a, October 2005 See notice on first page
Common optimization problems and their solutions
RF coverage problem
.................................................................................................................................................................................................................................
Definition
The RF coverage area is the area where two conditions are met:
• Pathloss < maximum allowed pathloss
• Ec/Io > minimum signal-to-noise ratio.
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
The goal is to close RF coverage gaps and maximize RF coverage. Or to be more
precise, maximize RF coverage, while continuing to comply to other requirements.
Increasing RF coverage must not mean other requirements such as interference levels
are compromised.
If RF coverage gaps can not be closed, it may be possible to move an RF coverage
gap from an area with high traffic volumes to an area with low traffic volumes. This
does not solve the RF coverage problem itself, but lowers the impact of a gap.
Information sources
The following information sources are used to detect RF coverage problems:
• Drive test
• Key performance indicators
• Customer complaints.
.................................................................................................................................................................................................................................
3-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Common optimization problems and their solutions RF coverage problem
Possible solutions
Possible solutions for RF coverage problems are:
• Antenna tilt or reorientation
• Power increase
• New antenna or new cell site.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 3-3
Issue a, October 2005 See notice on first page
Common optimization problems and their solutions
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
Optimization goal
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.
.................................................................................................................................................................................................................................
3-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Common optimization problems and their solutions Cell breathing problem
Information sources
The following information sources are used to detect cell breathing problems:
• Drive tests
• Key performance indicators
• Customer complaints.
Possible solutions
Possible solutions for cell breathing are:
• Increase coverage area:
– Antenna downtilt or reorientation
– Power increase.
– New antenna or new cell site.
• Change handover parameters
• Change neighboring cell list.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 3-5
Issue a, October 2005 See notice on first page
Common optimization problems and their solutions
Definition
Pilot pollution is interference caused by overlapping pilots with similar signal
strengths.
The lack of a dominant pilot causes low Ec/Io ratios. Problem areas with low Ec/Io
ratios may be misinterpreted as pilot pollution areas and lead to iterative drive testing
and unnecessary parameter changes in attempts to establish a dominant pilot.
If a pilot has:
• Insufficient Ec signal strength (extensive pathloss), the problem area is considered
as a RF coverage hole
• Sufficient Ec signal strength (low pathloss), the problem area has pilot pollution.
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.
.................................................................................................................................................................................................................................
3-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Common optimization problems and their solutions Pilot pollution problem
Information sources
The following information sources are used to detect pilot pollution problems:
• Drive tests.
Possible solutions
Possible solutions for pilot pollution problems are:
• Antenna tilt and azimuth rotation
• P-CPICH channel power changes
• Change neighboring cell lists.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 3-7
Issue a, October 2005 See notice on first page
Common optimization problems and their solutions
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.
Information sources
The following information sources are used to detect near-far problems:
• Drive test
• Key performance indicators
• Customer complaints.
Possible solutions
Possible solutions for near-far problems are:
• Changing power control parameters.
.................................................................................................................................................................................................................................
3-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Common optimization problems and their solutions
Around-the-corner problem
.................................................................................................................................................................................................................................
Definition
Around-the-corner problems occur when user equipment travels beyond an obstruction
where there is significant downlink interference from a new sector with low pathloss.
The downlink degrades momentarily until the handover is performed or the downlink
power control reacts to compensate the interference.
When the user equipment goes into handover with the new cell site, fast power control
is needed to quickly reduce cell site transmit power.
The around-the-corner problem is a continual and unavoidable issue. Known trouble
spots are elevated highways and street intersections.
Optimization goal
The goal is to optimize the power control mechanism.
The optimization goal is similar to the near-far goals.
Information sources
The following information sources are used to detect around-the-corner problems:
• Drive tests
• Key performance indicators.
Possible solutions
Possible solutions for around-the-corner problems are:
• Changing power control parameters
• Changing handover parameters.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 3-9
Issue a, October 2005 See notice on first page
Common optimization problems and their solutions
Handover problem
.................................................................................................................................................................................................................................
Definition
Unnecessary delays in handovers may cause uplink/downlink interference. Quick
handovers are required when there are rapid changes in pathloss between the user
equipment and the sector due to fading. Also, unnecessary handovers due to
non-contiguous UMTS coverage or pilot pollution lead to excessive handover activity.
Optimization goal
The goal is to optimize handover performance by careful selection of thresholds and
timers.
Handovers require signaling resources, and increase downlink interference, so
excessive handover activity must be minimized. Time delays due to resource allocation
(channel units, transmission links to RNC, OVSF codes) degrade call quality and
reduce the throughput of data calls.
Information sources
The following information sources are used to detect handover problems:
• Drive test
• Key performance indicators.
Possible solutions
Possible solutions for handover problems are:
• Adjust handover parameters
• Change the neighboring cell list.
.................................................................................................................................................................................................................................
3-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Common optimization problems and their solutions
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.
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
Common optimization problems and their solutions Missing neighbors problem
Possible solutions
Possible solutions for missing neighbor problems are:
• Updating the neighboring cell list to include or exclude a pilot.
• Change RF coverage, so pilots are not received anymore or pilot reception is
improved:
– Adjust power levels
– Change antenna orientation or tilt.
.................................................................................................................................................................................................................................
3-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Common optimization problems and their solutions
Exercises
.................................................................................................................................................................................................................................
Exercises
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 3-13
Issue a, October 2005 See notice on first page
4 U TRAN Signaling
4
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this lesson, you will be able to:
• Place the UTRAN protocols and channels in their architectural context
• Place the UTRAN protocols and channels in a call flow context.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 4-1
Issue a, October 2005 See notice on first page
UTRAN Signaling
Overview
.................................................................................................................................................................................................................................
Objectives
After completion of this section, you will be able to:
• describe the protocols of the air interface
• match these protocols to their correct layer in the protocol architecture of the air
interface
• explain how the layers communicate with one another by the use of channels.
Contents
.................................................................................................................................................................................................................................
4-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling
SM SM
IP PMM PMM
PDCP RRC RRC PDCPGTP-U GTP-U
RLC RANAP RANAP
RLC
MAC UDP UDP
MAC
Phy -up ALCAP ALCAP Phy-up SCCP SCCP
STC.2 NBAP NBAP STC.2 MTP3-b MTP3-b
IP IP
FP SSCF
-UNI SSCF-UNI FP SSCF
-N SSCF
-N
SSCOP SSCOP SSCOP SSCOP
PHY PHY
AAL2 AAL5 AAL5 AAL2 AAL5 AAL5
ATM ATM ATM
E1/ STM
-1 STM
-1 STM-1
Control plane
User plane
Description
The following table lists the protocols of the Uu and introduces the functions each
performs.
Part Description
Radio Resource Control The RRC controls the connection between UE and
UTRAN (setup, maintenance and teardown). Secondly,
RRC provides the means for the transmission of NAS
signaling. Finally, it is used by the Radio Resource
Management algorithms.
Packet Data Convergence The PDCP provides header compression and
Protocol decompression of IP data streams. It also transmits user
data from the non-access stratum to the RLC layer and
vice versa.
Radio Link Control The RLC provides functions related to data transfer, such
as segmentation and reassembly, in-sequence delivery,
error-correction and flow control. Three modes are
provided: transparent, acknowledged and
unacknowledged.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 4-3
Issue a, October 2005 See notice on first page
UTRAN Signaling Protocols of the air interface
Part Description
Medium Access Control The MAC prepares transport blocks for most efficient
transfer over the air. The functions include scheduling,
multiplexing, channel type switching, UE identification
(on common channels) and transport format selection on
a frame-by-frame basis.
The MAC is responsible for mapping logical channel
onto the appropriate transport channel.
.................................................................................................................................................................................................................................
4-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling
A layered architecture
The radio protocol architecture in the UTRAN is layered.
• 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 Radio interface protocol architecture
control
control Radio Resource Control Layer 3
(RRC)
PDCP
DCP L2/PDCP
control
BMC L2/BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC RLC RLC
Logical
Channels
Medium Access Control (MAC) L2/MAC
Transport
Channels
Physical Layer (PHY) L1
Physical
Channels
.................................................................................................................................................................................................................................
4-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling
L
a Radio Resource
y Control (RRC)
e L3 SAPs
r
Radio Link Control (RLC)
M L2
a SAPs
n
a Medium Access Control (MAC)
g L2
e SAPs
m
e Physical Layer
n L1
t SAPs
Air
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 4-7
Issue a, October 2005 See notice on first page
UTRAN Signaling Service access points
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 P-SCH
Uplink
S-SCH
Birirectional
P-CPICH
DCCH AICH
DTCH
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
.................................................................................................................................................................................................................................
4-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling Service access points
(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
Overview
.................................................................................................................................................................................................................................
Objectives
After completion of this section, you will be able to:
• Place the UTRAN protocols and channels in a call flow context.
Contents
.................................................................................................................................................................................................................................
4-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling
Definitions
RRC connection An RRC connection is a point-to-point bi-directional connection
between RRC peer entities on the UE and the UTRAN sides.
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.
The signaling connection is made up of an RRC and a RANAP connection.
Signaling connection
Consisting of an RRC (signaling) connection and a RANAP (signaling) connection, the
signaling connection provides the resources necessary for all signalling messages
between the UE and the core network (MSC or SGSN). Such signaling messages could
be for example, session management messages, such as a PDP context request; or
Mobility Management messages, such as those used in handover signaling.
The following illustration shows the RRC and the RANAP connections that make up
the signaling connection.
Signaling Connection
Relay
RRC RANAP
RRC RANAP
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 4-11
Issue a, October 2005 See notice on first page
UTRAN Signaling
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).
Node B
UE Serving RNS Serving RNC
Select L1 +L2
parameters
2. Radio Link Setup Request
5. Downlink Synchronization
6. Uplink Synchronization
.................................................................................................................................................................................................................................
4-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling Signaling radio bearers
2 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.
.................................................................................................................................................................................................
3 The Node B allocates resources, starts PHY reception, and responses with the NBAP
message Radio Link Setup Response.
.................................................................................................................................................................................................
4 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.
.................................................................................................................................................................................................
5 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.
.................................................................................................................................................................................................
6 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.
.................................................................................................................................................................................................
7 The message RRC connection setup is sent on a CCCH from the SRNC to the UE.
.................................................................................................................................................................................................
8 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 Signaling radio bearers
Signaling
Radio
Bearers
New RLC
entities
RLC
RLC
RLC
RLC
MAC
parameters
Medium Access Control (MAC)
L1
Parameters
Physical Layer (PHY)
.................................................................................................................................................................................................................................
4-14 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling
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).
RANAP
RAB Assignment Request
ALCAP
ERQ (Establish Request)
ALCAP
NBAP ECF (Establish Confirm)
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 Radio bearer establishment
1 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.
.................................................................................................................................................................................................
2 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.
.................................................................................................................................................................................................
3 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.
.................................................................................................................................................................................................
4 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.
.................................................................................................................................................................................................
5 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.
.................................................................................................................................................................................................
6 Once the UE has configured the RB, it returns a confirmation message in the form of
an RRC RB set-up Complete.
.................................................................................................................................................................................................
7 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.
.................................................................................................................................................................................................................................
4-16 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN Signaling Radio bearer establishment
New Radio
Bearer
control Radio Resource Control
(RRC)
PDCP DCP
control
BMC
MAC
parameters
Medium Access Control (MAC)
L1
Parameters
Physical Layer (PHY)
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 4-17
Issue a, October 2005 See notice on first page
UTRAN Signaling
Exercises
.................................................................................................................................................................................................................................
Exercises
.................................................................................................................................................................................................................................
4-18 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Part II: Optimization process
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this lesson, you will be able to:
• 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
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary II-1
Issue a, October 2005 See notice on first page
5 O ptimization process
5
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this lesson, you will be able to:
• 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
Optimization process phases 5-4
Drive test optimization process 5-7
Planning and preparation (site readiness) 5-9
Optimization planning 5-11
Perform cluster optimization 5-13
Perform system verification 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
Stages of the lifecycle of a network:
Network design
Optimization Planning
Implementation
N Acceptance
criteria met?
Network design
& implementation
Y
Live network
In service
optimization
.................................................................................................................................................................................................................................
5-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
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.
.................................................................................................................................................................................................
5 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”
.................................................................................................................................................................................................
6 When all sites are completed and tested, final (drive) tests are performed to check if
the network complies to the customeŕs requirements.
If the customer accepts the network, the network goes live and commercial use can
begin.
.................................................................................................................................................................................................
7 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
Objectives
This topic shows the stages of the optimization process in a live network.
Site readiness checks must have been performed before optimization starts.
Begin
Gather information
Analyze information
Optimization N
problem?
Sufficient N
information?
Identify reason
Determine solution
Implement solution
Y Problem N
solved?
.................................................................................................................................................................................................................................
5-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Optimization process Optimization process phases
1 Collect information.
Result: Main information sources are:
• Drive tests
• Customer complaints
• Performance measurements and KPIs.
.................................................................................................................................................................................................
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 5-5
Issue a, October 2005 See notice on first page
Optimization process Optimization process phases
Continuous optimization
This process has a “Beginning” and no “End”.
Optimization starts when a network goes live and never stops. Circumstances in a live
network always change and therefore optimization can not stop.
After an optimization problem has been solved, the optimization cycle continues,
detecting and solving other optimization problems.
.................................................................................................................................................................................................................................
5-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
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:
.................................................................................................................................................................................................
2 Plan optimization.
Ensure the system and tools are ready and available for drive test optimization.
This includes:
• Check proper RF parameter settings
• Check proper initial neighboring cell list settings
• Check availability of tools, equipment and personnel
• Define clusters
• Plan routes for drive testing.
.................................................................................................................................................................................................
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 5-7
Issue a, October 2005 See notice on first page
Optimization process Drive test optimization process
.................................................................................................................................................................................................................................
5-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Optimization process
Introduction
Before optimization is performed, site readiness checks should be performed. These
checks ensure that all cells are operating as required.
Important:
Site readiness checks are usually performed after a new network or new cells are
deployed and before the network goes operational. When they have been performed
and satisfactory performance can be guaranteed, the checks do not have to be made
anymore.
Checks
Site readiness checks include:
• Spectrum clearance
• Antenna check
• Sector verification.
Spectrum clearance
Spectrum clearance ensures no external interference is present and sufficient guard
bands are obeyed.
Detection of interference can be very time-consuming and difficult once the UMTS
system is up and running. It is desirable to have a high degree of confidence that the
spectrum is cleared prior to any testing.
Antenna check
Antenna checks ensure that the antenna system is properly installed.
Proper installation must be checked with regard to:
• 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 Planning and preparation (site readiness)
can be post-processed. If sector problems do occur, they need to be remedied and the
tests repeated until they are successful.
.................................................................................................................................................................................................................................
5-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Optimization process
Optimization planning
.................................................................................................................................................................................................................................
Introduction
The optimization planning phase ensures system and tool readiness for RF optimization
before beginning the actual drive testing.
Tool readiness
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 9 10 11
A 3 8
4 7
5 6 C
.................................................................................................................................................................................................................................
5-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Optimization process
Introduction
RF optimization execution consists of drive tests, problem area identification,
verification drives, and final drives to ensure completion of exit criteria. The core
activity is to provide system tuning, as well as data collection and reporting. Design
changes relating to cell site layout modifications or adding a new cell site may be
considered if critical coverage holes are discovered during optimization.
Antennae corrective actions are more frequent for new deployments, such as Greenfield
or Overlay scenarios. They are uncommon in existing systems, such as Network
Expansion or Additional Carrier System. Fine tuning of the transmit powers is the most
effective procedure in already optimized networks.
Cluster size
Cluster optimization consists of procedures performed on geographical groupings of
cell sites that are large enough to have meaningful multi-cell site optimization. Several
factors make it worthwhile to optimize the system in manageable sized clusters. There
is a better focus on the area optimized, as smaller sector numbers make it easier to
track the parameter changes and the impact of their performance.
Another benefit to smaller cluster optimization is that multiple teams can optimize
different clusters simultaneously. Each team is able to maintain focus on its cluster
with minimal impact from other teams. In addition, smaller cluster optimization aids in
speeding up the system tests for commercial operation. Optimization in equipped
clusters can proceed simultaneously with installation of other clusters.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 5-13
Issue a, October 2005 See notice on first page
Optimization process Perform cluster optimization
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 5-15
Issue a, October 2005 See notice on first page
Optimization process
Problem areas
Specific problem areas identified by the system verification will be addressed on a
case-by-case basis after the entire drive has been completed. Individual Cluster
Optimization drives are used to fix existing coverage problems by adjusting transmit
powers and neighbor lists. In extreme situations, handover thresholds, channel power
parameters or other low tuning parameters may require modification. After any
parameter changes are made, another drive test must be completed to ensure the
surrounding regions are still performing properly.
.................................................................................................................................................................................................................................
5-16 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Optimization process Perform system verification
.................................................................................................................................................................................................................................
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:
• If there is an optimization problem
• Optimization solutions
• If the problem is solved.
Information sources
As much information as possible should be used as input for optimization, so multiple
sources of information are needed.
The main information sources are:
• Key performance indicators
• Drive tests
• Customer complaints.
Information from one of these sources, can trigger further investigation. During the
more detailed investigation information from other sources is gathered.
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
Customer complaints can provide an indication of problems. Especially if multiple
complaints can be related to one source. Customer complaints can point to a problem
on a specific location, time or related to a resource.
.................................................................................................................................................................................................................................
5-18 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Optimization process
Information analysis
.................................................................................................................................................................................................................................
After information is collected, analysis of the information determines:
1. If there is an optimization problem
2. The source of the problem
3. Possible solutions for the problem
4. Consequences of implementing a solution.
Role of an engineer
The knowledge and experience of an engineer is an important tool in analyzing data.
An experienced optimization engineer has detailed knowledge of how processes and
protocols in a network work. This allows the engineer to link information and events to
a common source. An experienced engineer can even relate events to a single source,
that do not seem to relate to each other.
The engineer can identify possible sources of a problem, solutions that can solve the
problem and predict consequences of a solution (in a general way).
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 5-19
Issue a, October 2005 See notice on first page
Optimization process
Exercises
.................................................................................................................................................................................................................................
Exercises
3 If, after loaded tests, a problem cannot be solved after three test drives, what
should be done?
a A root cause analysis
b Further drive tests and optimization until the problem has been solved
c Cluster Optimization proceeds with the next cluster
a, c
.................................................................................................................................................................................................................................
5-20 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Part III: Optimization and
troubleshooting
Overview
.................................................................................................................................................................................................................................
Objectives
After completing the following lessons, you will be able to:
• Suggest methods of dealing with issues affecting access.
• Describe methods of resolving Radio Link Failures
• Identify parameters that have a direct influence on the useŕs perception of call
quality
• Identify failure symptoms and suggest improvements for problems related to call
mobility.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary III-1
Issue a, October 2005 See notice on first page
6 6 all availability and
C
optimization
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this lesson, you will be able to:
• Describe the call setup process
• Narrow down the failing issues to a performance area
• Narrow down the failing issues to one or more performance metrics
• Suggest methods of dealing with issues affecting access.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-1
Issue a, October 2005 See notice on first page
Call availability and optimization Overview
.................................................................................................................................................................................................................................
6-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
Call availability
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe the basic call setup process
• Recognise KPIs which reflect the general satisfaction level with network
accessibility.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-3
Issue a, October 2005 See notice on first page
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization Call availability
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-5
Issue a, October 2005 See notice on first page
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe the procedures relating to cell search, SIB decoding, cell
selection/reselection and RACH access
• Identify related KPIs and reasons for failures of those procedures.
Contents
Introduction 6-8
Cell Search & RRC SIB decoding 6-9
Cell selection 6-10
Cell re-selection failures 6-12
RACH access procedure failures 6-14
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-7
Issue a, October 2005 See notice on first page
Call availability and optimization
Introduction
.................................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
6-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
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:
• Slot synchronization by using the Primary Synchronization Channel (P-SCH)
• Frame synchronization and code group identification utilizing the Secondary
Synchronization Channel (S-SCH)
• Scrambling code identification on the Primary Common Pilot Channel (P-CPICH).
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-9
Issue a, October 2005 See notice on first page
Call availability and optimization
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:
• The parameter settings related to cell selection should be verified.
• If all settings are compliant with the recommendations, the behavior should be
investigated using a measurement UE and executing the attach procedure in the
location where coverage issues are observed.
.................................................................................................................................................................................................................................
6-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization 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
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization Cell re-selection failures
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-13
Issue a, October 2005 See notice on first page
Call availability and optimization
Overview
The RACH Access Procedure is used in the following cases:
• When attaching to the network
• When setting up a call
• When answering to a page
• When performing a Location Update/Routing Area update.
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
The RACH is transmitted on the physical layer in two separate parts:
1. A certain number of RACH Preambles are sent. The power of the first RACH
Preamble is relatively low and is calculated using open loop power control.
2. Each of the following RACH Preambles are transmitted with an increased power
till an acknowledgment (ACK) is received on the AICH.
3. After receiving the AICH the UE transmits the RACH Message Part with an
embedded RRC Connection Request message.
The signaling flow of a basic RACH transmission procedure:
Ue Node B RNC
Uu Iub
RACH Preamble
RACH Preamble
RACH Preamble
Access indication
(AICH)
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
.................................................................................................................................................................................................................................
6-14 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization RACH access procedure failures
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
• NumRRCConnAtt is triggered on the RNC after reception of the RRC Connection
Request message independent of the establishment cause. Low values at a specific
NodeB of NumRRCConnAtt are indicative of problems; nevertheless this counter
cannot prove that there are actually problems because RACH Preambles discarded
by the NodeB are not counted. It may be that at a particular cell low traffic is
resulting in low values of counter NumRRCConnAtt3.
• PM counter NumBadRACHTransBlock and NumGoodRACHTransBlock may be
used to arrive at the ratio between number of RACH TBs received with bad CRC
to total number of RACH TBs. A high value for this ratio may be indicative of
problems with the quality over the RACH.
• PM counter ChannelOccupRateRACH is the ratio of total bits transferred on the
RACH to maximum bits available for RACH usage (service rate) per granularity
period. If this ratio is very high the resources on the RACH may not be sufficient.
Improvement suggestions
The fixes for improvement depend on the detected reason for the failure:
NodeB does not decode the RACH Preamble
Possible reasons:
• The UE is not camping on an optimal cell due to incorrect selection/reselection
parameter settings.
• Due to hardware problems the sensitivity of the RX path could be reduced
• The power of the Initial RACH Preamble is too low. In this case it is necessary to
increase UTRAN parameter constantVal
• The power required for RACH Preamble detection does not exceed
physicalRACH.preambleThreshold. In this case the three parameters
MaxRetranPreamble, physicalRACH.preambleThreshold and powerRampStep have
to be optimized
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-15
Issue a, October 2005 See notice on first page
Call availability and optimization RACH access procedure failures
The RACH coverage of the best server is too poor in terms of low Ec/Io that might
be caused by:
– Pilot pollution: In this case the RF environment has to be optimized by e.g.
antenna tilting, variation of the power settings of single NodeBs etc.
– The coverage of the best server is simply too low (low Ec/N0, RSCP or high
pathloss). In case of coverage issues it may be useful to lower the detection
threshold defined by UTRAN parameter physicalRACHpreambleThreshold or to
increase the CPICH power controlled by UTRAN parameter pCPICH.power. If
increases are made to the CPICH power, then care must be taken to balance the
powers for the rest of the channels (if required), so that a situation does not
arise whereby the user detects and uses a cell based on pilot power, but has
insufficient traffic power available to carry the call.
UE receives no ACK on AICH
Possible reasons:
• The power of the AICH determined by UTRAN parameter aICHPower is not
sufficient.
• The AICH is interfered with by other non RF-optimized NodeBs. In this case, the
RF environment has to be optimized by e.g. antenna tilting, variation of the power
settings of single NodeBs, antenna azimuth changes.
Lack of Node B resources
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 physicalRACHpreambleTh-
reshold 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.
.................................................................................................................................................................................................................................
6-16 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe the RRC connection establishment process
• Identify related KPIs and reasons for failures in scenarios related to the RRC
connection establishment process.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-17
Issue a, October 2005 See notice on first page
Call availability and optimization
UE Node B RNC
Uu Iub
CAC 1
NumRRCConRej
RL Setup Request
NBAP NBAP
2
RL Setup Response
NBAP NBAP
.................................................................................................................................................................................................................................
6-18 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization Introduction to RRC connection establishment
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-19
Issue a, October 2005 See notice on first page
Call availability and optimization
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.
Load measurements
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.
.................................................................................................................................................................................................................................
6-20 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
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:
• Notraffic channel resources available at the NodeB
• Faults either in the NodeB
• Faults in the Iub links.
In all failure cases the RNC sends back to the UE an RRC Connection Reject
message with cause “unspecified”.
If the establishment of at least one radio link fails, the Node B sends back the Radio
Link Setup Failure message to the RNC.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-21
Issue a, October 2005 See notice on first page
Call availability and optimization Radio link setup failure
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.
.................................................................................................................................................................................................................................
6-22 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
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:
• If V30001 <= N30001 (that is determined by UTRAN parameter
maxRRCConnSetupRetries), the RNC increments V30001 by one, resets timer
T30001 and sends the RRC Connection Setup message again.
• If V30001 > N30001, the RNC will send an RRC Connection Reject message to
the UE; the resources reserved on NBAP and ALCAP are released.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-23
Issue a, October 2005 See notice on first page
Call availability and optimization RRC connection setup failure
The following figure shows the call flow of the unsuccessful case.
.................................................................................................................................................................................................................................
6-24 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization RRC connection setup failure
Failure symptoms
The PM counter NumRRCConnEstFail is used to record failures occurred during the
RRC Connection Setup procedure.
Causes for a failure may be indicated as follows:
• 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 maxRRCConnSetupRe-
tries 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
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-26 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization 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 UE’s 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.power-
Offset2 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
Call availability and optimization
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe the RAB establishment process
• Identify related KPIs and reasons for failures in procedures related to the RAB
establishment process.
Contents
Introduction 6-29
Dynamic bearer control failures 6-32
Radio link reconfiguration failures 6-33
Radio bearer establishment failures 6-34
No answer from UE 6-35
Code starvation 6-36
.................................................................................................................................................................................................................................
6-28 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
Introduction
.................................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-29
Issue a, October 2005 See notice on first page
Call availability and optimization Introduction
UE Node B SRNC CN
Uu Iub Iu-ps
RANAP RAB
assignment request
2
ALCAP Iu transport bearer establishment
DBC NumRABEstFail.Load 3
NBAP Radio link
reconfiguration prepare
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-31
Issue a, October 2005 See notice on first page
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-32 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
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)).
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-33
Issue a, October 2005 See notice on first page
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-34 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
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.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-35
Issue a, October 2005 See notice on first page
Call availability and optimization
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.
.................................................................................................................................................................................................................................
6-36 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call availability and optimization
Exercises
.................................................................................................................................................................................................................................
Exercises
Answer the following questions.
1 The fault in which card of the Node B could lead to a Radio link setup failure?
a MCR
b CTU
c IOU
d UCU
d
2 Which of the following KPIs indicates RRC SIB message decoding failure?
a NumRRCConRej
b NumRRCConnEstFail
c NumBadRACHTransBlock
4 Give a possible reason for a poor success rate of RRC Setup Establishment? Se-
lect all that apply.
a Radio Link Failure
b RRC SIB message decoding failure
c RACH Access Procedure failure
d A radio bearer failure
a, b, c
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 6-37
Issue a, October 2005 See notice on first page
Call availability and optimization Exercises
.................................................................................................................................................................................................................................
6-38 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
7 C all reliability
7
Overview
.................................................................................................................................................................................................................................
Objectives
After completion of this lesson, you should be able to:
• List factors that can cause dropped calls
• Describe methods of resolving Radio Link Failures
• Describe the Radio Link Restore and Deletion processes
• Identify causes of failure and develop stategies to solve them.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-1
Issue a, October 2005 See notice on first page
Call reliability
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.
.................................................................................................................................................................................................................................
7-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability Dropped calls analysis
Signaling flow
The signaling flow of total RABs dropped:
Cell_DCH
Iu release request
(UTRAN generated reason)
RANAP RANAP
NumRABDrop.sum
Iu release command
(UTRAN generated reason)
RANAP RANAP
UE_Idle
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.
.................................................................................................................................................................................................................................
7-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability
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.
Initial
state
RL Restore
RL Failure
In-sync Out-of-sync
state state
RL Restore
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-5
Issue a, October 2005 See notice on first page
Call reliability
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.
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.
.................................................................................................................................................................................................................................
7-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability RLF and Radio Link Restore in the Uplink
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-7
Issue a, October 2005 See notice on first page
Call reliability
Introduction
The RLF procedure in the downlink is supervised in the UE by RRC.
.................................................................................................................................................................................................................................
7-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability
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
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.
.................................................................................................................................................................................................................................
7-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability
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
Pilot pollution and the Around-the-Corner problem can be discovered by Layer 1 UE
logging (low Ec and Ec/Io values of the cells in the active set, sudden drop of Ec and
Ec/Io of the cells in the active set). A protocol analyzer can help to discover RLF due
to synchronization problems.
Soft/Softer HO issues could also be the reason for pilot pollution.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-11
Issue a, October 2005 See notice on first page
Call reliability
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.
.................................................................................................................................................................................................................................
7-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability
Failure symptoms
System Load related counters such as FwdPowerOvldDuration, Average Transmitted
Carrier Power (i.e. ave_tssi), Maximum Transmitted Carrier Power (i.e. max_tssi)
provide useful indications on the DL power load measured on a per cell basis.
It is hard to identify lower coverage caused by IAOC via RF Call Trace drive tests
because the power of the CPICH is unchanged. Lower DL transmit power of the
dedicated channel can be indirectly detected by a higher BLER. A protocol analyzer
can discover RLF due to synchronization problems
Specific investigations on IAOC may also require use of the Cell Diagnostic Monitor
(Cell DM) tool along a drive test in order to verify live when and where the IAOC
steps in, by checking whether the NodeB Transmitted Code Power suddenly decreases.
With the help of Cell DM, it can be seen that the DL transmit power is always lower
than the maximum allowed DL power configured by UTRAN parameter maxDLPower.
Improvement suggestions
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
The RLC is a layer 2 sublayer. RLC provides three basic tasks:
1. Buffering
2. Segmentation and reassembly
3. Error control
.................................................................................................................................................................................................................................
7-14 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
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
These are RLC failure symptoms:
• Retransmission of RLC identifiable as out-of-sequence RLC PDUs on Iub (extract
the particular call to distinguish from other RLC PDUs).
• A dropped call due to an RLC error can be easily identified by a Cell Update
message with cause “RLC unrecoverable error”.
The following table lists problems that can be detected in interface traces and the
corresponding KPIs in the PM system:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-15
Issue a, October 2005 See notice on first page
Call reliability
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
Outages may lead to:
• 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.
.................................................................................................................................................................................................................................
7-16 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability Network interface outages
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-17
Issue a, October 2005 See notice on first page
Call reliability
Introduction
The retainability KPIs (all service types) is derived from the relation of total dropped
RABs to the total successful established RABs.
.................................................................................................................................................................................................................................
7-18 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call reliability
Exercises
.................................................................................................................................................................................................................................
1 A RAB drop does not always lead to a user- perceived dropped call because:
a UE can maintain the call via Call Re-establishment procedure
b The UE always has a backup RAB
c The RRC automatically reconfigures new resources
a
2 Where are the RLF and Radio Link Restore procedures in UL supervised?
a UE by the RRC
b RNC by the RRC
c NodeB by the NBAP
C
3 A dropped call due to an RLC error can be easily identified by which of the fol-
lowing messages?
a Iu Release Command message
b Cell Update message
c RRC Release message
b
4 Which of the following load control functions should have the highest parameter
setting?
a Connection Admission Control
b Dynamic bearer control
c Congestion Control
c
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 7-19
Issue a, October 2005 See notice on first page
8 C all quality and optimization
8
Overview
.................................................................................................................................................................................................................................
Objectives
After completion of this lesson, you should be able to:
• Identify parameters that have a direct influence on the useŕs 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
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 8-1
Issue a, October 2005 See notice on first page
Call quality and optimization
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:
The quality KPI is derived from the uplink block error rate for all services (CSV, CSD,
PS).
.................................................................................................................................................................................................................................
8-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call quality and optimization Network level quality KPIs
Basic root cause analysis method for high UL/DL BLER 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.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 8-3
Issue a, October 2005 See notice on first page
Call quality and optimization
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.
• RF coverage and interference: Ec/Io and Ec measurements jointly with Total to
Aggregate Ec/Io ratio
• UE traces (RFCT) should be performed and data imported to an RF analysis tool:
UL BLER provided via RF Call Trace jointly with DL BLER provided via a
CDMA air interface tester
• UE Transmitted Power and UE Peak Transmit Power Margin
• UL TCP/IP Throughput with DL TCP/IP Throughput and DL Physical Layer
Throughput.
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.
.................................................................................................................................................................................................................................
8-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call quality and optimization Uplink Block Error Rate (BLER)
Figure
The following graphic shows uplink outer loop power control.
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
Call quality and optimization
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.
The NodeB adapts its transmitted power according to the Power Control commands
received by the UE.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 8-7
Issue a, October 2005 See notice on first page
Call quality and optimization
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:
• that the network allocates the correct resources and
• that the traffic mechanisms support the request during the traffic flow.
.................................................................................................................................................................................................................................
8-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call quality and optimization Quality of Service (QoS)
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.
Parameter Description
Measurement Report 4a threshold Threshold defining when the Measurement
Report 4a is triggered
Measurement Report 4b threshold Threshold defining when the Measurement
Report 4b is triggered
Enable PDCP compression Defines whether or not PDCP compression
is used
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 8-9
Issue a, October 2005 See notice on first page
Call quality and optimization Quality of Service (QoS)
.................................................................................................................................................................................................................................
8-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call quality and optimization
Exercises
.................................................................................................................................................................................................................................
3 At the UE, what does the Outer Loop Power Control do if the DL BLER is
higher than the target BLER value?
a Calculate a higher SIR ratio
b Calculate a lower SIR ratio
c Raise the BLER target
d Lower the BLER target
a
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 8-11
Issue a, October 2005 See notice on first page
9 C all mobility and optimization
9
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this lesson, you will be able to:
• Describe the soft/softer handover process
• Narrow down the failing issues to a performance area
• Narrow down the failing issues to one or more performance metrics
• Suggest methods of dealing with issues affecting soft/softer handovers.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-1
Issue a, October 2005 See notice on first page
Call mobility and optimization Overview
.................................................................................................................................................................................................................................
9-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
Soft/Softer Handover
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe the basic handover process
• Describe Soft/Softer Handover failures in CELL DCH and non-CELL DCH states
• Recognize KPIs which reflect the Soft/Softer Handover procedures within the
UMTS network.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-3
Issue a, October 2005 See notice on first page
Call mobility and optimization
Classification
Soft/Softer Handover failures are classified as follows:
• Failures in non-CELL DCH state:
– Random Access Detection Failure
– Call Admission Control Failure
– Radio Link Set-up Failure
– RRC Connection Set-up Failure
– Incorrect parameter settings.
• Failures in CELL DCH state:
– Poor RF Conditions
– Incorrect translations settings
– No NodeB resources available
– No transport resources available
– No UE answer
– UE Reject
– NodeB/RNC Outages
– Iub, Iur link Outages.
.................................................................................................................................................................................................................................
9-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
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
The following scenarios might apply to Soft/softer handover failures in non-CELL
DCH state:
1. UE is in idle state and initiates the transition to CELL DCH state (S/SHO at
Call Setup)
2. UE is in “forced” idle state due to unsupported URA PCH state (S/SHO at Call
Re-establishment)
3. UE is in URA PCH state and the network needs to transmit data to the UE
(S/SHO for DL Data Transfer in URA PCH)
4. UE is in URA PCH state and requests to transmit data to the network (S/SHO
for UL Data Transfer in URA PCH).
Process
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
Call mobility and optimization Soft/softer handover failures in non-CELL DCH state
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.
Failures
The following failures are possible in non-CELL DCH state:
• Random Access Detection Failure
• Call Admission Control Failure
• Radio Link Set-up Failure
• RRC Connection Set-up Failure
• Incorrect parameter settings.
Failure symptoms
The following symptoms can be the root cause of S/SHO failures in non-CELL DCH
state:
• Random Access Detection Failure:
– RRC Connection Request or RRC Cell Update messages are not successfully
decoded at the RNC
– Pilot candidates for S/SHO never getting the chance to be reported to the
UTRAN.
• Call Admission Control Failure:
Request to setup the call with more than one link is rejected due to overload
• Radio Link Setup Failure:
Power resources available but NodeB fails in setting up more than one link
• RRC Connection Setup Failure:
Resources successfully allocated at the NodeB but RRC Connection Setup
procedure fails.
• An additional failure may be due to incorrect setting of related parameters as
listed below:
– MaxNoReportedCellsOnRACH
(maximum number of cells to be reported on RACH)
– activeSetSizePS
.................................................................................................................................................................................................................................
9-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Soft/softer handover failures in non-CELL DCH state
Identification techniques
Evaluate success rate of S/SHO at call set-up:
• 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
Call mobility and optimization
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:
• Addition of a pilot to the Active Set
(i.e. event 1A is included in Measurement Report message),
performed as NBAP Radio Link Setup procedure for the first pilot or NBAP
Radio Link Addition procedure for additional pilots.
• Removal of a pilot from the Active Set
(i.e. event 1B is included in Measurement Report message),
performed as NBAP Radio Link Deletion procedure.
• Replacement of worse pilot in the Active Set by best candidate pilot
(i.e. event 1C is included in Measurement Report message),
performed as NBAP Radio Link Setup or NBAP Radio Link Addition
procedure for the best candidate pilot, followed by NBAP Radio Link Deletion
procedure for worse pilot in Active Set.
Important! Soft/softer handovers can be executed as Intra-RNC as well as
Inter-RNC. In case of Inter-RNC soft/softer handover the two RNC involved are
defined as Serving RNC (S-RNC) and Drift RNC (D-RNC).
Process
If the UE is in CELL DCH state, the soft/softer handover can be summarized as
follows:
• RRC Measurement Report message reports a soft/softer handover triggering
event to the UTRAN
• NBAP procedure sets up resources in the UTRAN (case of setup/addition or
replacement)
• RRC Active Set Update procedure executes the Soft/softer Handover
• NBAP procedure releases resources in the UTRAN (case of removal or
replacement)
• RRC Measurement Control message evaluates the Monitored Set update upon
Neighbor List Selection Algorithm (NLSA).
Failures
The following failures are possible in CELL DCH state:
• Poor RF Conditions
• Incorrect translations settings
• No NodeB resources available
• No transport resources available
• No UE answer
• UE Reject
.................................................................................................................................................................................................................................
9-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Soft/softer handover failures in CELL DCH state
• NodeB/RNC Outages
• Iub, Iur link 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
Call mobility and optimization
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.
.................................................................................................................................................................................................................................
9-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
Introduction
Upon successful decoding of Measurement Report message, the RNC allocates the
required resources at the NodeB over:
• either NBAP Radio Link Set-up for (soft handover) or
• NBAP Radio Link Addition procedure (for softer handover).
Failures
NodeB rejects the resource allocation request when no physical resources are available:
• NumRLSetupFail.NodeBRes
identifies failure in the S-RNC on a per cell basis
• NumRLAddFail.NodeBRes
identifies failure in the D-RNC on a per RNC basis.
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
Call mobility and optimization
Introduction
If the maximum supported capacity of the Radio Link is reached, no transport
resources (Iub links) are available.
Failures
The NBAP Radio Link setup or Radio Link Addition procedure may fail.
Failure symptoms
The dry-up of transport resources results in a degradation of Soft/softer Handover
Success Rate KPI’s
The degradation of Soft/softer Handover Success Rate KPI’s are tracked in the
following counters:
• NumRLSetupFail.TransRes
on a per cell basis in the S-RNC
• NumRLAddFail.TransRes
on a per RNC basis in the D-RNC.
Identification techniques
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.
.................................................................................................................................................................................................................................
9-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
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.
Improvement suggestions
• 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
Call mobility and optimization
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
The following failure symptoms will appear:
• Degradation of Soft/softer Handover Success Rate KPI’s
• NumIntraRNCSHOFail.UERejis triggered on receiving the Active Set Update
Failure message at the UTRAN.
Identification techniques
The following techniques will help to to identify the specific failure cause:
• Trace test calls via a protocol analyzer
• Retrieve Active Set Update and Active Set Update Failure messages from
protocol analyzer
Improvement suggestions
Reorganization or optimization of the Primary Scrambling Code planning stategy:
• 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.
.................................................................................................................................................................................................................................
9-14 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization 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
Call mobility and optimization
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
• NBAP procedure fails, for example due to:
– faulty Traffic Card in the NodeB
– broken or unstable Iub link NBAP ATM bearer configuration.
• Random Access Detection failure, for example a decoding failure in the UCU
card of the Node B
Identification techniques
• Alarm Entity at the OMC-U GUI
• Collect UCU trace taken directly from the NodeB (monitor the channel
elements of the NodeB)
• Collect FMS traces (internal and external messages of the RNC) and TPU
traces (e.g., uplink power control testing) at the RNC.
Improvement suggestions
Detailed descriptions on the various alarms to be monitored are available in the RNC
and NodeB OAM Manuals.
.................................................................................................................................................................................................................................
9-16 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
Overview
In general, the handover translation parameters can be categorized into four main
thematic areas:
• Measurement and reporting
• Soft Handover algorithm
• NLSA algorithm
• Active Set Update procedure
Important! Depending on the thematic area, incorrect settings of handover
parameters may cause different problems. Therefore, it is strongly recommended to
run a consistency check on these parameter settings before starting any detailed
investigations.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-17
Issue a, October 2005 See notice on first page
Call mobility and optimization
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
defines the length of the filtering period
• 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
The following failure symptoms will appear:
• 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:
• Total to Active Ec/Io Ratio helps to identify high interference areas
• Record of the time when Measurement Report messages are sent, that is, the
soft/softer handover has been triggered.
• The analysis of the UE measurements on the Monitored Set pilots before
sending the Measurement Report indicates whether the UE decision is fast
enough compared to the specific RF scenario.
Improvement suggestions
The following suggestions will help to to improve the translation settings:
• 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.
.................................................................................................................................................................................................................................
9-18 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Incorrect translations settings - measurement and
reporting
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-19
Issue a, October 2005 See notice on first page
Call mobility and optimization
Introduction
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 UE’s 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.
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:
• In order to identify which NLSA priority setting needs to be changed
accordingly:
– either increase the priority of strong detected pilots, or
– decrease the priority of weak monitored pilots.
• If several areas are showing a high number of detected pilots compared to the
monitored list size:
– increase the value of parameter combinedNeighbourhoodListSize to minimize
interference issues by including more pilots in the monitored set.
.................................................................................................................................................................................................................................
9-20 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
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.
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
Call mobility and optimization
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe failures in UMTS to GSM handover procedures
• Recognize KPIs which reflect the UMTS to GSM handover.
Contents
.................................................................................................................................................................................................................................
9-22 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
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:
• One CS voice connection, or
• One CS voice connection and simultaneous PS connection.
For a UE, which is involved simultaneously in a CS connection and a PS
connection, the CS connection will be transferred to the target GSM cell first.
When the CS handover is completed, the UE has to send a routing area update
request to the GSM network containing an indication that the GSM/GPRS network
needs to continue an already established UTRAN CN context. Whether the UE is
able to continue both the CS and PS connections in GSM/GPRS depends on its
capabilities.
Upon a handover failure the CS and PS connections are further served by the
UMTS network if possible according to the radio conditions.
Handover decision
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
Call mobility and optimization Inter-system handover failures - overview
• 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:
• UMTS to GSM handover:
– The Relocation Preparation procedure is not completed in time
– The overall Relocation procedure is not completed in time, i.e. the MSC does
not initiate the Iu Release procedure.
– A failure is detected during the Relocation Preparation procedure.
– The UE fails to complete the requested handover.
– Receipt of an incorrect RELOCATION COMMAND message.
• GSM to UMTS handover:
– The GSM to UMTS handover feature is not enabled in UTRAN.
The target cell id is not controlled by the RNC.
– The RNC fails to decode the ″RRC container″ within the RELOCATION
REQUEST message.
– The UE does not support the target cell frequency band.
– The ciphering or integrity protection cannot be configured.
– No S-RNTI 2 can be allocated.
– No reduced range uplink scrambling code can be allocated.
– The requested radio resources cannot be established.
– The RNC does not receive a HANDOVER TO UTRAN COMPLETE message
from the UE.
– The MSC cancels the relocation by releasing the Iu connection.
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.
.................................................................................................................................................................................................................................
9-24 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
Relocation failures
.................................................................................................................................................................................................................................
Parameters
The following parameters apply for relocation failures:
• 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 < TRELOCprep < hoRelocGuardTimer
• TRELOCcomplete < TRelocOverall.
KPIs
The percentage of Handover Relocation procedures successfully completed is defined
according to the following formula:
Total Relocation Preparation UMTS to GSM HO Success Rate =
[(NumAttRelocPrepUMTS-GSM
- NumFailRelocPrepUMTS-GSM.sum)
/ NumAttRelocPrepUMTS-GSM]
* 100
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-25
Issue a, October 2005 See notice on first page
Call mobility and optimization
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
The following algorithms apply to UMTS to GSM handover.
DAHO
Database assisted handover (DAHO) is a terminology given to a handover where the
decision for executing the handover procedure is based solely on precise knowledge of
the network topology.
MAHO
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 failure causes specified within the message are as follows:
• Physical Channel Failure
for example loss of synchronization between UE and NodeB due to poor RF
conditions.
• Unacceptable Configuration
for example blocking rate or timeouts
• Protocol Error.
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
.................................................................................................................................................................................................................................
9-26 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Handover procedure failures
• Frequent HO
• PS call drop.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-27
Issue a, October 2005 See notice on first page
Call mobility and optimization Handover procedure failures
.................................................................................................................................................................................................................................
9-28 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Handover procedure failures
KPIs
The percentage of UMTS to GSM Handover successfully completed is defined
according to the following formula:
Total UMTS to GSM Handover Success Rate =
[(NumAttHoUMTS-GSM
- NumFailHoUMTS-GSM.sum)
/NumAttHoUMTS-GSM]
* 100
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-29
Issue a, October 2005 See notice on first page
Call mobility and optimization
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.
Improvement suggestions
The setting of 3G-MSC timer TrelocOverall should should be checked against setting
of the timers hoRelocGuardTimer and TRELOCprep.
.................................................................................................................................................................................................................................
9-30 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization
Overview
.................................................................................................................................................................................................................................
Objectives
After completing this section, you will be able to:
• Describe failures in Location and Routing area update procedures
• Recognize KPIs which reflect the Location and Routing area update process.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-31
Issue a, October 2005 See notice on first page
Call mobility and optimization
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 Location update failures may apply:
• Location Update Reject message is sent back to the UE
• UE timer T3120 expiry
• Radio Resources release before completion of the procedure.
Improvement suggestions
The following suggestions may help to improve Location Update failure issues:
• Check inconsistencies of the Location Area identifier between LACs in the
MSC and UTRAN.
• A high number of periodical Location Update in particular areas require a
careful review of the LA plan.
• The setting of timer T3212 can be increased.
.................................................................................................................................................................................................................................
9-32 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Location update failure
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
Call mobility and optimization
Introduction
Similar to the Location Update, the Routing Area (RA) Update keeps the PS Core
Network updated on the UE’s 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
The following Routing Area Update failures may apply:
• Routing Update Reject message is sent back to the UE
• UE timer T3330 expiry
• Radio Resources release before completion of the procedure.
Improvement suggestions
The following suggestions may help to improve Location Update failure issues:
• Check inconsistencies of the Routing Area identifier between RACs in the
SGSN and UTRAN.
• A high number of periodical Routing Area Update in particular areas require a
careful review of the RA plan.
• The setting of timer T3312 can be increased.
.................................................................................................................................................................................................................................
9-34 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Call mobility and optimization Routing update failure
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:
• SGSN initiated inter SGSN RA update success rate =
(succInterSgsnRaUpdate
/attInterSgsnRaUpdate)
*100%
• SGSN initiated intra SGSN RA update success rate =
(succIntraSgsnRaUpdate
/attIntraSgsnRaUpdate)
*100%
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 9-35
Issue a, October 2005 See notice on first page
Call mobility and optimization
Exercises
.................................................................................................................................................................................................................................
Exercises
1 Which of the following soft/softer handover failures can occur in CELL FACH
state? Select all that apply.
a Random Access Channel Procedure Failure
b Active Set Update Failure
c Radio Link Setup Failure
d Iub link outage
1, 3
2 Which failure symptoms can occur at a soft/softer handover? Select all that apply
a Radio Link Setup Failure
b Iur link outage
c GSM access blocking
d Increased Pilot pollution
1, 2, 4
3 What reasons would cause a call that should be handed over to GSM to be re-
tained in UMTS?
a Relocation procedure unsuccessful or not completed on time
b No GSM cell available
c RNC retriggering interval for HO attempt too long
d PS call is dropped in simultaneous CS/PS call
1, 2
4 Which feature of the inter-system handover algorithm for UMTS to GSM han-
dover is used to avoid call establishment in UMTS?
a Database assisted Handover
b Moblie assisted Handover
c RRC Redirection
d Directed Retry
3
.................................................................................................................................................................................................................................
9-36 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
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.
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-1
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators Overview
Contents
.................................................................................................................................................................................................................................
10-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators
Overview
.................................................................................................................................................................................................................................
Objectives
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 10-4
domain
KPI for Mobile-terminated end-to-end call setup in the Circuit Switched 10-9
domain
KPI for end-to-end call drops in the Circuit Switched domain 10-14
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-3
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Overview
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).
Formula
The end-to-end Call setup success ratio is defined as follows:
CC Alerting
E2E CS MO Call setup Success Ratio =
RRC Connection Request
.................................................................................................................................................................................................................................
10-4 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Circuit Switched domain
RRC connection
RRC request (cause) RRC
Radio Link
NBAP setup request NBAP
Radio Link
NBAP setup response NBAP
RRC
connection RRC connection
RRC RRC
establishment setup
RRC connection
RRC setup complete RRC
Measurement
RRC control RRC
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-5
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Circuit Switched domain
Connection
SCCP SCCP
request
MM CM
service request Connection
SCCP confirm SCCP
Initial UE
RANAP message RANAP
MM authentication Direct
RANAP RANAP
transfer
and ciphering
request Downlink
RRC RRC
direct transfer
Initial direct
RRC transfer RRC
MM authentication
and ciphering
Direct
response RANAP transfer RANAP
Security mode
RANAP RANAP
command
Security mode
RRC RRC
command
Security
mode Security mode
RRC RRC
complete
Security mode
RANAP RANAP
complete
Common
RANAP RANAP
ID
Direct
RANAP RANAP
transfer
MM CM
Downlink
service accept RRC
direct transfer
RRC
Uplink
RRC RRC
direct transfer
CC setup
Direct
RANAP RANAP
transfer
.................................................................................................................................................................................................................................
10-6 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Circuit Switched domain
Radio Link
NBAP reconf.request NBAP
Radio Link
NBAP reconf.response NBAP
RAB assignment
Radio Bearer
RRC RRC
setup request
Radio Bearer
RRC setup complete RRC
RAB assignment
RANAP response RANAP
Direct
RANAP RANAP
CC call transfer
proceeding Downlink
RRC RRC
direct transfer
Direct
RANAP RANAP
transfer
CC alerting
Downlink
RRC direct transfer RRC
Direct
RANAP transfer RANAP
CC connect
Downlink
RRC RRC
direct transfer
Parts 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
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Circuit Switched domain
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
.................................................................................................................................................................................................................................
10-8 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators
Overview
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).
Formula
The end-to-end Call setup success ratio is defined as follows:
CC Alerting
E2E CS MT Call setup Success Ratio =
RRC Paging Type 1
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-9
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Circuit Switched domain
RRC connection
RRC request (cause) RRC
Radio Link
NBAP setup request NBAP
Radio Link
NBAP setup response NBAP
RRC
connection RRC connection
RRC RRC
establishment setup
RRC connection
RRC setup complete RRC
Measurement
RRC control RRC
.................................................................................................................................................................................................................................
10-10 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Circuit Switched domain
Connection
SCCP SCCP
request
MM paging
response Connection
SCCP confirm SCCP
Initial UE
RANAP message RANAP
Direct
RANAP RANAP
MM authentication transfer
and ciphering
Downlink
request RRC
direct transfer
RRC
Initial direct
RRC transfer RRC
MM authentication
and ciphering
Direct
response RANAP transfer RANAP
Security mode
RANAP RANAP
command
Security mode
RRC RRC
command
Security
mode Security mode
RRC RRC
complete
Security mode
RANAP RANAP
complete
Common
RANAP RANAP
ID
Direct
RANAP RANAP
transfer
MM CM
service accept Downlink
RRC RRC
direct transfer
Uplink
RRC RRC
direct transfer
CC setup
Direct
RANAP RANAP
transfer
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-11
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Circuit Switched domain
Radio Link
NBAP reconf.request NBAP
Radio Link
NBAP reconf.response NBAP
RAB assignment
Radio Bearer
RRC RRC
setup request
Radio Bearer
RRC setup complete RRC
RAB assignment
RANAP response RANAP
Uplink
RRC RRC
CC call direct transfer
confirm
Direct
RANAP RANAP
transfer
Uplink
RRC RRC
direct transfer
CC alerting
Direct
RANAP transfer RANAP
Uplink
RRC RRC
direct transfer
CC connect
Direct
RANAP transfer RANAP
Direct
RANAP transfer RANAP
CC connect
acknowledgement RRC
Downlink
RRC
direct transfer
Parts Counters
UE (part) RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail
RABFailEstab.T3
.................................................................................................................................................................................................................................
10-12 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Circuit Switched domain
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
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-13
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Overview
This gives an overview over the key performance indicators for the end-to-end call
drops in the Circuit Switched domain (CS E2E).
Formula
...
CS-E2E-call drop
KPI Parts
CS_MO_E2E_Call_Drop RF (part)
UE (part)
NodeB (part)
RNC (part)
CS_MO_E2E_Call_Success CC Alerting
.................................................................................................................................................................................................................................
10-14 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Circuit Switched
domain
Signaling flow
CC Disconnect Direct
RANAP RANAP
transfer
Direct
RANAP RANAP
transfer
CC Release
Downlink
RRC RRC
direct transfer
Uplink RRC
RRC direct transfer
CC Release
complete Direct
RANAP RANAP
transfer
Iu release
RANAP RANAP
command
RRC Connection
RRC relelase RRC
RRC Connection
RRC release complete RRC
Iu Release
Radio Link
NBAP deletion request NBAP
Radio Link
NBAP deletion response NBAP
Iu release
RANAP RANAP
complete
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-15
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Circuit Switched
domain
Radio Link
NBAP failure indication NBAP
Iu release
Iu release RANAP request RANAP
Iu release
RANAP RANAP
command
Radio Link
NBAP deletion request NBAP
Radio Link
deletion Radio Link
NBAP deletion response NBAP
Iu release
RANAP complete RANAP
SCCP
RANAP RANAP
release
Cell update
RRC confirm RRC
.................................................................................................................................................................................................................................
10-16 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Circuit Switched
domain
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-17
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Overview
.................................................................................................................................................................................................................................
Objectives
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 10-19
domain
KPI for Mobile-terminated end-to-end call setup in the Packet Switched 10-24
domain
KPI for end-to-end call drops in the Packet Switched domain 10-30
.................................................................................................................................................................................................................................
10-18 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators
Overview
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).
Formula
The end-to-end Call setup success ratio is defined as follows:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-19
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Packet Switched domain
RRC connection
RRC request (cause) RRC
Radio Link
NBAP setup request NBAP
Radio Link
NBAP setup response NBAP
RRC
connection RRC Connection
RRC RRC
establishment setup
RRC Connection
RRC setup complete RRC
Measurement
RRC control RRC
.................................................................................................................................................................................................................................
10-20 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Packet Switched domain
Connection
SCCP SCCP
request
GMM attach
(request) Connection
SCCP confirm SCCP
Initial UE
RANAP message RANAP
Direct
RANAP RANAP
transfer
Downlink
RRC RRC
GMM attach direct transfer
(authentication
Initial direct
and ciphering) RRC transfer RRC
Direct
RANAP transfer RANAP
Security mode
RANAP RANAP
command
Security mode
RRC RRC
command
Security
mode Security mode
RRC RRC
complete
Security mode
RANAP RANAP
complete
Common
RANAP RANAP
ID
Downlink
RRC RRC
direct transfer
Uplink
RRC RRC
direct transfer
GMM attach
(complete) Direct
RANAP RANAP
transfer
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-21
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Packet Switched domain
RAB assignment
RANAP request RANAP
Radio Link
NBAP reconf.request NBAP
Radio Link
NBAP reconf.response NBAP
RAB assignment
Radio Bearer
RRC RRC
setup
Radio Bearer
RRC setup complete RRC
RAB assignment
RANAP response RANAP
Direct
SM RANAP
transfer
RANAP
PDP context
activation Downlink
RRC RRC
(accept) direct transfer
PS-MO-E2E-call setup
KPI Parts
PS_MO_E2E_Call_Success SM Activate PDP Context Accept, comprising:
UE (part)
NodeB (part)
RNC (part)
PS_MO_E2E_Call_ RCC Connection Request
Attempts
Parts Counters
UE (part) RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail
RABFailEstab.T3
.................................................................................................................................................................................................................................
10-22 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in the
Packet Switched domain
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
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-23
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Overview
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).
Formula
The end-to-end Call setup success ratio is defined as follows:
.................................................................................................................................................................................................................................
10-24 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Packet Switched domain
RRC connection
RRC request (cause) RRC
Radio Link
NBAP setup request NBAP
Radio Link
NBAP setup response NBAP
RRC
connection RRC connection
RRC RRC
establishment setup response
RRC connection
RRC setup complete RRC
Measurement
RRC control RRC
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-25
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Packet Switched domain
Connection
SCCP SCCP
request
GMM paging
response Connection
SCCP confirm SCCP
Initial UE
RANAP message RANAP
Initial direct
RRC RRC
transfer
GMM attach
(request) Initial UE
RANAP message RANAP
Direct
RANAP RANAP
transfer
Downlink
RRC RRC
GMM attach direct transfer
(authentication
Initial direct
and ciphering) RRC transfer RRC
Direct
RANAP transfer RANAP
Security mode
RANAP RANAP
command
Security mode
RRC RRC
command
Security
mode Security mode
RRC RRC
complete
Security mode
RANAP RANAP
complete
Common
RANAP RANAP
ID
Downlink
RRC RRC
direct transfer
Uplink
RRC RRC
direct transfer
GMM attach
(complete) Direct
RANAP RANAP
transfer
.................................................................................................................................................................................................................................
10-26 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Packet Switched domain
RAB assignment
RANAP request RANAP
Radio Link
NBAP NBAP
reconf.request
Radio Link
NBAP reconf.request NBAP
RAB assignment
Radio Bearer
RRC RRC
setup response
Radio Bearer
RRC setup complete RRC
RAB assignment
RANAP response RANAP
Direct
SM RANAP
transfer
RANAP
PDP context
activation Downlink
RRC RRC
(accept) direct transfer
PS-MT-E2E-call setup
KPI Parts
PS_MT_E2E_Call_Success SM Activate PDP Context Accept, comprising:
UE (part)
NodeB (part)
RNC (part)
PS_CN (part)
Interfaces (part)
Others
PS_MT_E2E_Call_Attempts RCC Connection Request
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
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Packet Switched domain
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) Sccp_Fail(Timer) + RAB_Fail(TRabAssg) + RNC_Errors
PS_CN (part) Reject_PS_CN. + Sccp_Fail(blckg) + Abnormal_Release_
before_PDP_accept
Interfaces (part) Iu (Fail) + Iub (Fail) + Iur (Fail)
Others Any other call setup failure which excludes the above
mentioned but occurs after RACH and before PDP
context accept
Parts 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
.................................................................................................................................................................................................................................
10-28 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in the
Packet Switched domain
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-29
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Overview
This gives an overview over the key performance indicators for the end-to-end call
drops in the Packet Switched domain (PS E2E).
Formula
.................................................................................................................................................................................................................................
10-30 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switched
domain
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-31
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switched
domain
Signaling flow
Request Direct
RANAP RANAP
transfer
SM deactivate Direct
RANAP RANAP
PDP context transfer
Downlink
Accept RRC RRC
direct transfer
Uplink RRC
RRC direct transfer
Direct
Complete RANAP
transfer
RANAP
Uplink
RRC RRC
direct transfer
Direct
Request RANAP RANAP
transfer
Direct
GMM detach RANAP
transfer
RANAP
Downlink
Accept RRC
direct transfer
RRC
Uplink RRC
RRC direct transfer
Direct
Complete RANAP
transfer
RANAP
Iu release
RANAP RANAP
command
RRC Connection
RRC relelase RRC
RRC Connection
RRC release complete RRC
Iu Release
Radio Link
NBAP deletion request NBAP
Radio Link
NBAP deletion response NBAP
Iu release
RANAP RANAP
complete
.................................................................................................................................................................................................................................
10-32 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switched
domain
Radio Link
NBAP failure indication NBAP
Iu release
Iu release RANAP request RANAP
Iu release
RANAP RANAP
command
Radio Link
NBAP deletion request NBAP
Radio Link
deletion Radio Link
NBAP deletion response NBAP
Iu release
RANAP complete RANAP
SCCP
RANAP RANAP
release
Cell update
RRC confirm RRC
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-33
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switched
domain
.................................................................................................................................................................................................................................
10-34 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators
Overview
.................................................................................................................................................................................................................................
Objectives
This lesson gives an overview over the key performance indicators (KPIs) for Quality
of Service (QoS) monitoring within the UTRAN cluster.
Contents
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-35
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Quality of Service
Quality of Service (QoS) is used to measure a specified set of performance attributes
that are typically associated with a particular service.
There are four different QoS classes which must be considered:
• Conversational class (for example voice)
• Streaming class (for example video, audio)
• Interactive class (for example web browsing)
• Background class (for example file transfer).
The most important measurable parameters used are:
• 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”.
.................................................................................................................................................................................................................................
10-36 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPIs for Quality of Service monitoring in the CS domain
Formula
When more than one cell is the active set, for each cell the following KPI must be
available per traffic class:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-37
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Quality of Service
Quality of Service (QoS) is used to measure a specified set of performance attributes
that are typically associated with a particular service.
There are four different QoS classes which must be considered:
• Conversational class (for example voice)
• Streaming class (for example video, audio)
• Interactive class (for example web browsing)
• Background class (for example file transfer).
The most important measurable parameters used are:
• 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”.
Notes:
1. Not guaranteed values
.................................................................................................................................................................................................................................
10-38 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
UTRAN end-to-end key performance indicators KPIs for Quality of Service monitoring in the PS domain
Formula
When more than one cell is the active set, for each cell the following KPI must be
available per traffic class:
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary 10-39
Issue a, October 2005 See notice on first page
UTRAN end-to-end key performance indicators
Exercises
.................................................................................................................................................................................................................................
Exercises
.................................................................................................................................................................................................................................
10-40 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005
Index
.................................................................................................................................................................................................................................
UM4801-IG.en.A4 Lucent Technologies - Proprietary IN-1
Issue a, October 2005 See notice on first page
Index
................................................................................................
T T300, 6-14
U uERadioBearerSetupResponse, 6-34
.................................................................................................................................................................................................................................
IN-2 Lucent Technologies - Proprietary UM4801-IG.en.A4
See notice on first page Issue a, October 2005