UMTS Optimization 5.1

See notice on first age
UMTS
UTRAN Optimization
UMTS-5.1
401-382-810R5.1
Issue 1
September 2008
Alcatel-Lucent - Proprietary
This document contains proprietary information of Alcatel-Lucent and
is not to be disclosed or used except in accordance with applicable agreements.
Copyright © 2008 Alcatel-Lucent
Unpublished and Not for Publication
All Rights Reserved
See notice on first age
Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their
respective owners.
The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2008 Alcatel-Lucent. All Rights Reserved.
Notice
Every effort was made to ensure that the information in this Information Product (IP) was complete and accurate at the time of printing.
However, information is subject to change.
Ordering information
The order number for this information product is 401-382-940R5.1. To order documentation from an order entry representative, use one of the
following numbers:
Within the United States, call +1-888-582-3688, or send email to cicorders@alcatel-lucent.com (to fax an order, call 1-800-566-9568).
Within Canada, call +1 317 322 6616, or send email to cicorders@alcatel-lucent.com.
International, call +1 317 322 6616, or send email to intlorders@alcatel-lucent.com (to fax an order, call +1 317 322 6699).
Technical support
For initial technical assistance, please call one of the following numbers:
North America, Central and Latin America and Asia Pacific regions:
Customer Technical Assistance Management (CTAM) center: +1 630 713 0488
Europe, Middle East and African regions:
International Customer Management Center (ICMC): +353 1692 4579
Information product support
For non-technical questions or comments regarding this information product, please call one of the following numbers:
North America, Central and Latin America and Asia Pacific regions:
Customer Technical Assistance Management (CTAM) center: +1 630 713 0488
Europe, Middle East and African regions:
International Customer Management Center (ICMC): +353 1692 4579
Alcatel-Lucent - Proprietary
See notice on first page
Contents
About this information product

Purpose ............................................................................................................................................................................................ xi
Reason for reissue ....................................................................................................................................................................... xi
Intended audience ........................................................................................................................................................................ xi
How to use this information product ................................................................................................................................. xii
Conventions used ....................................................................................................................................................................... xii
Systems supported ..................................................................................................................................................................... xii
Related documentation ............................................................................................................................................................. xii
Related training ........................................................................................................................................................................... xii
How to comment ...................................................................................................................................................................... xiii
Part I: Optimization concepts
1 Information sources and tools
Gathering information
Overview ...................................................................................................................................................................................... 1-1
Key Performance Indicators ................................................................................................................................................. 1-2
Drive test ...................................................................................................................................................................................... 1-3
Customer complaints ............................................................................................................................................................... 1-6
OMC-UPS tools ........................................................................................................................................................................ 1-7
Analyzing information
Overview ...................................................................................................................................................................................... 1-9
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary iii
Issue 1, September 2008 See notice on first page
Contents
Data analysis software ......................................................................................................................................................... 1-10
Optimization and design tools .......................................................................................................................................... 1-13
2 Common optimization problems and their solutions
Overview ...................................................................................................................................................................................... 2-1
RF coverage problem .............................................................................................................................................................. 2-2
Cell breathing problem ........................................................................................................................................................... 2-4
Pilot pollution problem ........................................................................................................................................................... 2-6
Near-far problem ..................................................................................................................................................................... 2-8
Around-the-corner problem .................................................................................................................................................. 2-9
Handover problem ................................................................................................................................................................. 2-10
Missing neighbors problem ................................................................................................................................................ 2-11
3 UTRAN Signaling
Overview ...................................................................................................................................................................................... 3-1
Protocol architecture of the air interface
Overview ...................................................................................................................................................................................... 3-3
Protocols of the air interface ................................................................................................................................................ 3-4
Radio interface protocol architecture ................................................................................................................................ 3-6
Service access points ............................................................................................................................................................... 3-8
Air interface channels
Overview .................................................................................................................................................................................... 3-12
Physical channels ................................................................................................................................................................... 3-13
Transport channels ................................................................................................................................................................. 3-20
Logical channels ..................................................................................................................................................................... 3-24
Air interface protocols
Overview .................................................................................................................................................................................... 3-26
Medium Access Control .................................................................................................................................................... 3-27
...................................................................................................................................................................................................................................
iv Alcatel-Lucent - Proprietary 401-382-810R5.1
See notice on first page Issue 1, September 2008
Contents
Radio Link Control ................................................................................................................................................................ 3-31
Packet Data Convergence Protocol (PDCP) ............................................................................................................... 3-34
Radio Resource Control ...................................................................................................................................................... 3-35
RRC State Machine ............................................................................................................................................................... 3-38
RRC Connection and Signaling Connection ............................................................................................................... 3-39
Signaling radio bearers ........................................................................................................................................................ 3-40
Radio bearer establishment ................................................................................................................................................ 3-44
UTRAN protocols
Overview .................................................................................................................................................................................... 3-48
Iub protocol structure ........................................................................................................................................................... 3-49
Protocols of the Iub interface ............................................................................................................................................ 3-51
Iur interface .............................................................................................................................................................................. 3-54
Iu-cs interface .......................................................................................................................................................................... 3-56
Part II: Optimization process
4 Optimization process
Overview ...................................................................................................................................................................................... 4-1
Network lifecycle ...................................................................................................................................................................... 4-2
Optimization process phases ................................................................................................................................................ 4-4
Planning and preparation (site readiness) ....................................................................................................................... 4-7
Drive test optimization before live traffic ...................................................................................................................... 4-9
Information gathering ........................................................................................................................................................... 4-11
Information analysis .............................................................................................................................................................. 4-12
5 Drive testing
Overview ...................................................................................................................................................................................... 5-1
Drive test optimization process ........................................................................................................................................... 5-2
Planning and preparation (site readiness) ....................................................................................................................... 5-4
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary v
Contents
Optimization planning ............................................................................................................................................................ 5-6
Perform cluster optimization ................................................................................................................................................ 5-8
Perform system verification ............................................................................................................................................... 5-11
Part III: Optimization and troubleshooting
6 UTRAN key performance indicators
Overview ...................................................................................................................................................................................... 6-1
Performance Counters and Key Performance Indicators .......................................................................................... 6-2
KPI example - CS IRAT HO success rate (UMTS -> GSM) ................................................................................ 6-6
CS IRAT HO success rate (UMTS -> GSM) ............................................................................................................... 6-7
Performance counter trigger event basis ......................................................................................................................... 6-8
Parameter trigger event basis ............................................................................................................................................ 6-10
Parameter setting .................................................................................................................................................................... 6-12
Parameter discussion ............................................................................................................................................................. 6-13
7 Call availability optimization and troubleshooting
Overview ...................................................................................................................................................................................... 7-1
Call availability
Overview ...................................................................................................................................................................................... 7-3
Call availability ......................................................................................................................................................................... 7-4
Determination of accessibility problem ........................................................................................................................... 7-6
Accessibility
Overview ...................................................................................................................................................................................... 7-7
Access preliminary procedures ........................................................................................................................................... 7-8
Cell re-selection failures ........................................................................................................................................................ 7-9
RACH access procedure failures ..................................................................................................................................... 7-11
RRC connection establishment analysis
Overview .................................................................................................................................................................................... 7-15
...................................................................................................................................................................................................................................
vi Alcatel-Lucent - Proprietary 401-382-810R5.1
Contents
Introduction to RRC connection establishment ......................................................................................................... 7-16
Call admission control failures ......................................................................................................................................... 7-19
Radio link setup analysis .................................................................................................................................................... 7-21
RRC connection setup failure ........................................................................................................................................... 7-23
Paging failures ......................................................................................................................................................................... 7-24
RAB establishment analysis
Overview .................................................................................................................................................................................... 7-26
RAB establishment ................................................................................................................................................................ 7-27
Dynamic bearer control failures ....................................................................................................................................... 7-30
Radio bearer establishment failures ................................................................................................................................ 7-32
No answer from UE .............................................................................................................................................................. 7-33
8 Call reliability optimization and troubleshooting
Overview ...................................................................................................................................................................................... 8-1
Dropped calls analysis ............................................................................................................................................................ 8-2
Radio link failures analysis due to synchronization issues ..................................................................................... 8-6
Dropped RAB analysis due to congestion ..................................................................................................................... 8-9
9 Call quality optimization and troubleshooting
Overview ...................................................................................................................................................................................... 9-1
Quality KPIs ............................................................................................................................................................................... 9-2
10 Call mobility optimization and troubleshooting
Overview .................................................................................................................................................................................... 10-1
Soft/Softer handover and troubleshooting
Overview .................................................................................................................................................................................... 10-3
Soft/softer handover procedure ......................................................................................................................................... 10-4
Average active set size ......................................................................................................................................................... 10-7
Soft handover troubleshooting .......................................................................................................................................... 10-9
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary vii
Contents
No Node B resources available ..................................................................................................................................... 10-12
No transport resources available ................................................................................................................................... 10-13
No UE answer ....................................................................................................................................................................... 10-14
UE reject ................................................................................................................................................................................. 10-15
Unlisted set cells .................................................................................................................................................................. 10-16
CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting
Overview ................................................................................................................................................................................. 10-18
CS Voice UMTS to GSM (inter-RAT) handover procedure .............................................................................. 10-19
CS Voice relocation preparation procedure troubleshooting .............................................................................. 10-23
CS Voice IRAT handover procedure troubleshooting ........................................................................................... 10-25
CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting
Overview ................................................................................................................................................................................. 10-26
CS Voice GSM to UMTS (inter-RAT) handover procedure .............................................................................. 10-27
Relocation resource allocation procedure troubleshooting ................................................................................. 10-30
Handover procedure troubleshooting ........................................................................................................................... 10-32
PS UMTS to GSM (inter-RAT) Cell Change Order and troubleshooting
Overview ................................................................................................................................................................................. 10-33
PS UMTS to GSM (inter-RAT) Cell Change Order procedure ....................................................................... 10-34
PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting ............................................................ 10-37
Serving HS-DSCH Cell Change
Overview ................................................................................................................................................................................. 10-39
Serving HS-DSCH Cell Change procedure .............................................................................................................. 10-40
Serving HS-DSCH Cell Change troubleshooting ................................................................................................... 10-43
Inter-frequency hard handover and troubleshooting
Overview ................................................................................................................................................................................. 10-44
Inter-frequency hard handover procedure .................................................................................................................. 10-45
...................................................................................................................................................................................................................................
viii Alcatel-Lucent - Proprietary 401-382-810R5.1
Contents
Hard handover troubleshooting ...................................................................................................................................... 10-50
No Node B resources available ..................................................................................................................................... 10-53
No transport resources available ................................................................................................................................... 10-54
UE reject ................................................................................................................................................................................. 10-55
Inter-system directed retry
Overview ................................................................................................................................................................................. 10-56
Inter-system directed retry procedure .......................................................................................................................... 10-57
Inter-system directed retry troubleshooting ............................................................................................................... 10-60
11 Throughput optimization and troubleshooting
Overview .................................................................................................................................................................................... 11-1
Throughput optimization ..................................................................................................................................................... 11-2
Glossary
Index
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary ix
Purpose
This document describes the methods to perform an optimization of the UTRAN
Network based on performance indicators and drive tests. These include:
• identification of sources of performance data,
• description of drive testing equipment, methods and tool
• identification of performance data and traffic measurements to locate trouble spots
• solution proposals for improving the performance
• evaluation of the effectiveness of counter measures.
Use of this document, or the information it contains, with any configuration other than
the ones above may not be valid.
The UMTS UTRAN optimization manual is specific to the optimization of UMTS
networks and does not cover other aspects of network management or network
engineering.
Reason for reissue

This is the first issue of this Information Product (IP) for UMTS Release 5.1. Updates
for the addition of new information and corrections in subsequent document issues will
be summarized in this notice.
Reason for reissue:
Issue Reason for reissue

1 Final version for GA
Intended audience
Alcatel-Lucent assumes that anyone using the information in this manual has a general
familiarity with UMTS networks, and has specific experience working with, and
operating, the Alcatel-Lucent UMTS system.
....................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary xi
,
Therefore, the audience for this manual consists of:

• Network operators
• Field support personnel
• RF engineers
• Network planners
• Systems engineers who work with the Alcatel-Lucent UMTS network and need to
know how to plan and expand a UMTS network using network statistics.
How to use this information product

Use this documentation as a guidance for the preparation of optimization tasks in the
UTRAN Network. Use it in combination with the latest user documentation.
Conventions used
The term “FIMS-UT” is a generic term to describe any local maintenance terminal
(LMT) for any UTRAN network element.
The terms “RMT” and “Node B RMT” are used to describe the Node B Remote
Maintenance Tool application.
The term “OMC” is a generic term to describe the Operation and Maintenance Center
entities which control the UTRAN network elements.
Acronyms are explained on their first appearance in the text.
Systems supported
This document applies to the Alcatel-Lucent UMTS System Release 5.1.
Related documentation
The following related documentation is available:
• Performance Measurements Definitions Manual, UMTS-5.1/IMS 7.0,
401-382-803R5.1
Related training
The following related courses are available:
• UMTS System Introduction, UM1001
• UMTS Hardware Overview, UM1911
• UMTS UTRAN Signaling and Parameters, UM4302
• UTRAN Processes and Parameters, UM4305
• UTRAN Optimization, UM4801.
...................................................................................................................................................................................................................................
xii Alcatel-Lucent - Proprietary 401-382-810R5.1
,
How to comment
To comment on this information product, go to the Online Comment Form
(http://www.lucent-info.com/comments/enus/) or e-mail your comments to the
Comments Hotline (comments@alcatel-lucent.com).
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary xiii
,
Part I: Optimization concepts
Overview
...................................................................................................................................................................................................................................
Purpose
This document part provides an introduction to the concepts of UTRAN optimization,
information on tools and sources that are used to gather the information for the
optimization process, a short description of typical areas for optimization problems,
and an overview over UTRAN signaling.
Contents
Chapter 1, Information sources and tools 1-1

Chapter 2, Common optimization problems and their solutions 2-1
Chapter 3, UTRAN Signaling 3-1
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary I-1
1 I nformation sources and tools
1
Gathering information
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides information on tools and information sources that are used to
gather information that is used in the optimization process.
This section describes the use of:
• Customer complaints
• Drive testing
• Key Performance Indicators.
Other tools
Protocol analyzers can also be used to gather performance data. Protocol analyzers can
be used to monitor and count messages on interfaces in the network. Protocol analyzers
are available from many different vendors.
Contents
Key Performance Indicators 1-2

Drive test 1-3
Customer complaints 1-6
OMC-UPS tools 1-7
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary 1-1
Information sources and tools
Key Performance Indicators

...................................................................................................................................................................................................................................
Use of Key Performance Indicators

Key Performance Indicators (KPI) are calculated using measurements that are gathered
by the OMC-UPS. The KPIs are used to determine if the network complies to the
levels of performance that are needed.
Key Performance Indicators (KPI) 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 a problem that can be an issue for
optimization.
A KPI value can change suddenly, or gradually, but both types of change can be an
indication that optimization will be needed.
Available KPIs
KPIs that can be 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.
For detailed information on all the available KPIs, refer to UMTS Performance
Measurement Definitions Manual, UMTS-5.1/IMS 7.0, 401-382-803R5.1.
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
• Handover problems (failures or ping-ponging)
• Missing neighbor cells in the neighboring cell list.
...................................................................................................................................................................................................................................
1-2 Alcatel-Lucent - Proprietary 401-382-810R5.1
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 test 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 test, neighboring cells must be operational, so cell selection, interference
measurements and hand overs 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 is 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):
...................................................................................................................................................................................................................................
Information sources and tools Drive test
Components of a drive test system are:

• UMTS scanner/receiver
• UMTS antenna
• PC with software for logging the data
• UMTS terminal
• Vehicle with location/positioning equipment (for example GPS).
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.
....................................................................................................................................................................................................................................
Information sources and tools Drive test
Analyzing drive test data

Data that is gathered during a drive test can be displayed in real time or stored on the
PC for off-line analysis.
The information must be analyzed to check for performance problems, that can be
solved by network optimization.
Automated tools are needed because a large volume of information is collected.
Automated tools help to sort out the information and draw conclusions from the
information.
Analysis tools can project the collected data on a map that includes characteristics of
the terrain. On the map, details are shown such as coverage strength, and locations
where handovers, cell reselections or dropped calls occur.
This information is used to identify problems and the locations where the problems
occur.
....................................................................................................................................................................................................................................
Customer complaints
...................................................................................................................................................................................................................................
Use of 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.
A customer complaint can be the trigger for further investigation using KPIs or drive
testing.
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.
Trouble ticket information

Trouble tickets typically contain the following information:
• UE type and model
• Type of problem (for example dropped call, poor quality)
• Time and place of the problem.
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
problems that may be an issue for optimization.
...................................................................................................................................................................................................................................
OMC-UPS tools
...................................................................................................................................................................................................................................
OMC-UPS tools
The OMC-UPS 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 a 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-UPS requests a transfer to the
OMC-UPS.
Use of RF call trace

The operator can use information from RF call traces to:
• Verify call establishment
• Check performance and maintenance of radio links
• Check radio link quality and coverage.
OCNS
Orthogonal Channel Noise Simulator (OCNS) is a tool that is activated on the
OMC-UPS and generates downlink interference to simulate traffic.
The OMC-UPS 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 problems that may be an issue for
optimization.
...................................................................................................................................................................................................................................
Information sources and tools OMC-UPS tools
OCNS can be useful to detect Cell breathing.
....................................................................................................................................................................................................................................
Analyzing information
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides information about tools that can be used during optimization.
Contents
Data analysis software 1-10

Optimization and design tools 1-13
...................................................................................................................................................................................................................................
Data analysis software

...................................................................................................................................................................................................................................
Need for data analysis software

Data analysis software is needed to process data, because a large volume of
information is collected. The software helps to sort out the information, present it to an
engineer and helps the engineer to draw conclusions.
The software also allows an operator to show the consequences of changes that are
made to the network.
Data analysis software is used in:
• Network design optimization
• Live network performance optimization.
Inputs for analysis software tools

Data analysis tools can project the collected data on a map that includes characteristics
of the terrain. On the map, details are shown such as coverage strength, and locations
where handovers, cell reselections or dropped calls occur.
To show and analyze information, inputs are needed such as:
• Maps (with terrain features and roads)
• Location and orientation of sites
• Parameter settings for cells, antennas and sites (power, antenna tilts)
• Drive test data
• Performance measurements.
Benefits of data analysis software

Data analysis software helps an engineer to:
• Identify and locate a problem
• Determine the source of a problem
• Find solutions
• Predict the effects of implementing a solution.
Predict effect of changes

Optimization software predicts the effects of changes (for example in power level or
antenna tilt). An engineer can easily try different options. This helps an engineer to
determine what is the best solution to correct an optimization problem.
...................................................................................................................................................................................................................................
Information sources and tools Data analysis software
Output of analysis tools

Data analysis tools can provide output on performance in different forms, but most
commonly used are outputs in tables and graphical outputs. Especially graphical output
clearly shows problem areas in a network.
Typical output from data analysis software and illustrates a network before and after
optimization:
Before optimization Optimizated design
The dark lines indicate areas that have no coverage. Changes in the shade of the
antennas indicate changes in antenna tilt.
Analysis tool availability

Many tools are available for analyzing information. The main input for many
commercially available analysis software tool is drive test data. But also other inputs
can be used.
....................................................................................................................................................................................................................................
Information sources and tools Data analysis software
Besides commercially available software tools also many proprietary tools are
available.
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.
....................................................................................................................................................................................................................................
Optimization and design tools

...................................................................................................................................................................................................................................
This topic gives an overview of tools, developed by Alcatel-Lucent, that are used in
optimization and design of 3G networks.
LCAT
LCAT is the Lucent Cells Application Tool. It is a tools that allows an engineer to
define cells and sectors.
LCAT information as input for LDAT and SPAT3G.
LDAT3G
Lucent Data Analysis Tool for 3G (LDAT3G) is an application for performing RF
analysis of drive test data for IS-95, 3G CDMA, 1xEV-DO, and UMTS systems. Used
for initial optimization of deployed network.
Drive test data, RF Call Trace, Cell Diagnostic Monitor, Packrat, and WINDS are
supported.
SPAT3G
Service Performance Analysis Tool for 3G (SPAT3G) is a tool that can be used to
quickly troubleshoot and improve network performance. It gives you easy access to a
wealth of information at the system, cell, face, and carrier level that can be displayed
graphically or in tabular formats. SPAT3G is used to optimize a live network and not
during initial optimization.
SPAT3G:
• Displays of performance metrics for all network entities at different report levels
(ECP, Cell, Face, Carrier, and IWF/PCF).
• Provides data trending for a metric or multiple metrics in a single chart per system,
cell, face, and carrier. SPAT3G also provides peg trending at the system, cell, face,
and carrier levels, allowing more detailed analysis.
• Provides ROP Analysis, Metric and Service Measurement Trending, or Service
Measurements data, as well as FCIAlert, Handoff Matrix, and UNL data by right
clicking on a cell site.
• Displays handoff matrix data on a map display showing handoff relationships
between sites.
AirPro
AirPro is an RF planning tool that is used to design wireless systems. AirPro can be
used in the designs of new wireless networks, networks migrating from older
generation to newer generation and existing network optimization. AirPro includes RF
...................................................................................................................................................................................................................................
Information sources and tools Optimization and design tools
propagation analysis, interference prediction, RF optimization, and utilities that help

you create and manage system designs for mobile systems in diverse operating
environments
Ocelot ®
Ocelot ® is used to optimize tilt, azimuth and power levels of antennas in a scenario to
get best coverage and capacity from the network. The benefit of using Ocelot ® for
optimization is reduced dependence on drive testing required for calibrating the design
parameters and post deployment optimization using service measurements.
In post deployment optimization, Ocelot ® is used in:
• Moving traffic from heavily-loaded sectors to more lightly-loaded sectors (“traffic
balancing”)
• Reducing the amount of soft- and softer-handoff traffic
• Reducing the average power per user.
....................................................................................................................................................................................................................................
2 2 ommon optimization problems
C
and their solutions
Overview
...................................................................................................................................................................................................................................
Purpose
This chapter describes typical problem areas that can be addressed by optimization and
provides possible solutions for the problem.
For each problem, the topic provides:
• Description and definition of the problem
• How the problem shows itself in a network
• Consequences for the network and the users
• Useful tools and information sources
• 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
RF coverage problem 2-2

Cell breathing problem 2-4
Pilot pollution problem 2-6
Near-far problem 2-8
Around-the-corner problem 2-9
Handover problem 2-10
Missing neighbors problem 2-11
...................................................................................................................................................................................................................................
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 an
accurate measures for the 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.
Because increasing RF coverage must not mean other requirements such as interference
levels can not be met anymore.
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.
Detection of the problem

There are several ways in which RF coverage problems show themselves in the
network.
These include:
• Dropped calls
• Failed handovers.
Information sources
The following information sources are used to detect RF coverage problems:
• Drive test
• Key performance indicators
• Customer complaints.
...................................................................................................................................................................................................................................
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.
...................................................................................................................................................................................................................................
Cell breathing problem

...................................................................................................................................................................................................................................
Definition
Cell breathing is the growing and shrinking of an RF coverage area, depending on the
network load.
An increase of the network load increases network interference. Higher interference
lowers the quality of service especially at the initial cell coverage border and 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 the 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
Traffic needed during optimization

Cell breathing occurs when the network is loaded, so RF optimization must be
performed on a loaded network. The network can be loaded with live traffic or
simulated traffic.
To simulate (additional) traffic on the downlink, the Orthogonal Channel Noise
Simulator (OCNS) can be activated on the OMC-UPS to generate downlink
interference. On the uplink, an attenuator attached to the user equipment simulates the
loading.
...................................................................................................................................................................................................................................
Common optimization problems and their solutions Cell breathing problem
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.

There are several ways in which cell breathing problems show themselves in the
network.
These include:
• Dropped calls
• Poor quality, especially at cell edges (during high traffic loads)
• Appearance of RF coverage gaps (during high traffic loads)
• Failed handovers
• No handover to neighboring cells (during low traffic loads)
• Excessive or unexpected handovers (during high traffic loads)
• Pilot pollution (during low traffic loads).
Information sources
The following information sources are used to detect cell breathing problems:
• Drive tests
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.
...................................................................................................................................................................................................................................
Pilot pollution problem

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

There are several ways in which pilot pollution problems show themselves in the
network.
These include:
• Dropped calls
• Handover failures
...................................................................................................................................................................................................................................
Common optimization problems and their solutions Pilot pollution problem
• Increased interference
• Decreased capacity.
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.
...................................................................................................................................................................................................................................
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.

There are several ways in which near-far problems show themselves in the network.
These include:
• High interference
• Node B always transmits on full power despite satisfying block error rates
• User equipment always transmits on full power despite satisfying block error rates.
Information sources
The following information sources are used to detect near-far problems:
• Drive test
Possible solutions
Possible solutions for near-far problems are:
• Changing power control parameters.
...................................................................................................................................................................................................................................
Around-the-corner problem
...................................................................................................................................................................................................................................
Definition
Around-the-corner problems occur when user equipment travels beyond an obstruction
and if 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.

There are several ways in which around-the-corner problems show themselves in the
network.
These include:
• High interference
• Unusual handover behavior.
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.
...................................................................................................................................................................................................................................
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
non-contiguous UMTS coverage or pilot pollution lead to excessive handover activity.
Optimization goal
The goal is to optimize the 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.

There are several ways in which handover problems show themselves in the network.
These include:
• Dropped calls (because of handover failure)
• Ping-ponging (frequent handovers between 2 cells).
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.
...................................................................................................................................................................................................................................
Missing neighbors problem

...................................................................................................................................................................................................................................
Definition
A neighboring cell list contains the cell identifiers to which a handover is allowed. The
list is kept in the RNC and is transmitted to the UE. The UE measures signals only
from the neighboring cell list and uses these measurement for power control and
handovers. A handover can therefor 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.

There are several ways in which missing neighbor problems show themselves in the
network.
These include:
• Dropped calls (when neighboring cell list is too short and UE can not handover to
another cell)
• High interference levels (UE transmits at high power levels to serving cell, because
it can not handover to another cell)
• Unusual handover behavior (no handovers are performed from on cell to another
cell).
• Uneven traffic distribution (UE stay with a cell and are not handed over to a
neighboring cell).
Information sources
The following information sources are used to detect missing neighbors problem:
• Drive test
...................................................................................................................................................................................................................................
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 U TRAN Signaling
3
Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Protocol architecture of the air interface 3-3

Protocols of the air interface 3-4
Radio interface protocol architecture 3-6
Service access points 3-8
Air interface channels 3-12
Physical channels 3-13
Transport channels 3-20
Logical channels 3-24
Air interface protocols 3-26
Medium Access Control 3-27
Radio Link Control 3-31
Packet Data Convergence Protocol (PDCP) 3-34
Radio Resource Control 3-35
RRC State Machine 3-38
RRC Connection and Signaling Connection 3-39
Signaling radio bearers 3-40
Radio bearer establishment 3-44
UTRAN protocols 3-48
Iub protocol structure 3-49
Protocols of the Iub interface 3-51
...................................................................................................................................................................................................................................
UTRAN Signaling Overview
Iur interface 3-54

Iu-cs interface 3-56
....................................................................................................................................................................................................................................
UTRAN Signaling
Protocol architecture of the air interface
Overview
...................................................................................................................................................................................................................................
Purpose
The purpose of this section is:
• to describe the protocols of the air interface
• to match these protocols to their correct layer in the protocol architecture of the air
interface
• to explain how the layers communicate with one another by the use of channels.
Contents
Protocols of the air interface 3-4

Radio interface protocol architecture 3-6
Service access points 3-8
...................................................................................................................................................................................................................................
UTRAN Signaling
Protocols of the air interface

...................................................................................................................................................................................................................................
Logical structure of the air or Uu interface (PS example)

The following illustration shows the UTRAN protocol architecture (for DCH) with the
protocols of the Uu highlighted.
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
UE Uu Node B Iub RNC Iu-ps SGSN
Description
The following table lists the protocols of the Uu and introduces the functions each
performs.
Part Description
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.
...................................................................................................................................................................................................................................
UTRAN Signaling Protocols of the air interface
Part Description
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.
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.
....................................................................................................................................................................................................................................
UTRAN Signaling
Radio interface protocol architecture

...................................................................................................................................................................................................................................
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.
Structure of radio protocol architecture

The following figure illustrates the logical structure of the radio protocol architecture:
...................................................................................................................................................................................................................................
UTRAN Signaling Radio interface protocol architecture
C-plane signaling U-plane information

GC Nt DC
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
Explanation of overall protocol structure

Each block in the previous figure represents an instance of the respective protocol.
Service Access Points (SAP) for peer-to-peer communication are marked with ovals at
the interface between sub-layers. The SAP between the MAC and the physical layer
provides the transport channels. The SAPs between the RLC and the MAC sub-layer
provide the logical channels. In the C-plane, the interface from RRC to higher layers
(CC, MM) is defined by the General Control (GC), Notification (Nt) and Dedicated
Control (DC) SAPs.
The connections between the RRC and the MAC as well as the RRC and L1 provide
local inter-layer control services.
Equivalent control interfaces exist between:
• The RRC and the RLC sub-layer
• The RRC and the PDCP sub-layer
• The RRC and the BMC sub-layer.
These interfaces allow the RRC to control the configuration of the lower layers. For
this purpose separate Control SAPs are defined between the RRC and each lower layer
(PDCP, RLC, MAC and L1).
....................................................................................................................................................................................................................................
UTRAN Signaling
Service access points

...................................................................................................................................................................................................................................
Service access points

The layers provide services to the layer above, and use the services of the layer below.
These services are provided through Service Access Points, which provide different
kinds of channels for communications. The channels are divided into four broad
categories, depending on which layer interface provides them. These categories are:
• Radio Bearers provided by the RLC
• Logical Channels provided by the MAC to the RLC
• Transport Channels provided by the PHY to the MAC
• Physical Channels provided to the PHY.
The SAPs and their position between the layers are illustrated in the following figure.
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
What are the different channels for?

The different channels provide the following different services.
• The logical channel service contains the type of information that is transferred over
the radio link. For example, the DTCH carries the actual user data; the BCCH
provides system information to all users in a cell.
• The transport channel service defines how and with what characteristics (with
which QoS) data is transferred over the radio link. Every transport channel has a
transport format assigned to it which contains information such as channel coding,
interleaving and rate matching.
• The physical channel service provides the means by which the UE is radio-linked
with the Node B.
...................................................................................................................................................................................................................................
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
Uplink
Downlink P-SCH
Bidirectional
Fixed
Data transfer S-SCH channels
Association
P-CPICH
Logical channels Transport channels

S-CPICH
BCCH BCH P-CCPCH
PCCH PCH PICH
CCCH FACH S-CCPCH
CTCH RACH PRACH
DCCH AICH
DTCH DCH DPDCH

DPCH
DPCCH
HS-DPCCH
HS-DSCH HS-PDSCH
HS-SCCH
E-DCH E-DPDCH
E-DPCCH
E-HICH
E-AGCH E-RGCH
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
(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.
• HS-SCCH is used for UE addressing for HSDPA, that is, indicating a specific UE
that data packets are being sent on the HS-PDSCH, and provides the UE with
necessary information to decode the data packets.
• The HS-DPCCH carries the UE feedback information used for link adaptation and
the Hybrid Automated Repeat request (HARQ) process.
....................................................................................................................................................................................................................................
UTRAN Signaling
Air interface channels
Overview
...................................................................................................................................................................................................................................
Purpose
• to describe the channels of the air interface
• to map these channels to their layer of the air interface
• to explain the function of the channels.
Contents
Physical channels 3-13

Transport channels 3-20
Logical channels 3-24
...................................................................................................................................................................................................................................
UTRAN Signaling
Physical channels
...................................................................................................................................................................................................................................
Overview
In this section, we will look at each of the physical channels that link the UE with the
Node B and consider their mapping relationships to the transport channels.
We shall consider the following groups of physical channels:
• Common downlink physical channels.
• Dedicated downlink physical channels
• Common uplink physical channels
• Dedicated uplink physical channels
Introduction
In the Node B, physical channels are created out of either related transport channels or
out of Node B control data. In the latter case, the information in the physical channel
does not carry higher-layer traffic but is pure layer 1 control data created by the Node
B, e.g. SCH or CPICH.
Multiple transport channels can be multiplexed onto a single physical channel, or
conversely, one transport channel can be transferred over multiple physical channels
(multicode). For example, PCH and FACH can be multiplexed onto the same
S-CCPCH or can each be transferred over separate S-CCPCHs.
Transport channels are mapped to physical channels as shown in the illustration.
...................................................................................................................................................................................................................................
UTRAN Signaling Physical channels
Physical channels
Uplink
Downlink P-SCH
Bidirectional
Fixed
Association
P-CPICH

S-CPICH
BCCH BCH P-CCPCH
PCCH PCH PICH
CCCH FACH S-CCPCH
CTCH RACH PRACH
DCCH AICH
DTCH DCH DPDCH

DPCH
DPCCH
HS-DPCCH
HS-DSCH HS-PDSCH
HS-SCCH
E-DCH E-DPDCH
E-DPCCH
E-HICH
E-AGCH E-RGCH
Channel mapping
The DCHs are coded and multiplexed and the resulting data stream is mapped
sequentially directly to the physical channel(s).
....................................................................................................................................................................................................................................
The mapping of BCH and FACH is equally straightforward where the data stream,
after coding and interleaving, is mapped sequentially to the Primary and Secondary
CCPCH respectively.
Also for the RACH, the coded and interleaved bits are sequentially mapped to the
physical channel, in this case the message part of the random access burst on the
PRACH.
The mapping of the PCH to the Secondary CCPCH is more complex to allow for an
efficient sleep mode.
The mapping of the HS-DSCH to the HS-PDSCH is done by mapping the data stream
sequentially directly to the physical channel.
Common downlink physical channels

The following is a list of the common downlink physical channels:
Common Description
downlink
physical
channels
P-CCPCH The Primary Common Control Physical Channel is a fixed rate (32
kbps, SF=256) downlink physical channels used to carry the BCH.
S-CCPCH The Secondary Common Control Physical Channel is used to carry
the FACH and PCH. It is of constant rate. However, in contrast to
the Primary CCPCH, the rate may be different for different
secondary CCPCH within one cell and between cells, in order to be
able to allocate different amount of FACH and PCH capacity to a
cell. The rate and spreading factor of each secondary CCPCH is
broadcast on the BCH. The set of possible rates is the same as for
the downlink DPCH.
The FACH and PCH can be mapped to separate secondary
CCPCHs.
The main difference between the Primary and Secondary CCPCH is
that the Primary CCPCH has a fixed predefined rate while the
Secondary CCPCH has a constant rate that may be different for
different cells, depending on the capacity needed for FACH and
PCH.
....................................................................................................................................................................................................................................
Common Description
downlink
physical
channels
P-SCH The Synchronisation Channel (SCH) is a downlink signal used for
cell search. The SCH consists of two sub channels, the Primary and
Secondary SCH. Along with the CPICH, the SCH channels provide
information that enables the UE to camp on, search for and select a
cell.
During the first step of the initial cell search procedure, the UE
uses the Primary Synchronisation Channel (P-SCH) to acquire slot
synchronisation to the strongest cell. The Primary Synchronisation
Code in the P-SCH is the same for every cell in the system.
S-SCH During the second step of the initial cell search procedure, the UE
uses the secondary SCH to find frame synchronisation and identify
the code group of the cell found in the first step.
P-CPICH The Primary Common Pilot Channel is a fixed rate (30 kbit/s, SF =
256) downlink physical channel.
This channel is coded with the scrambling code of the cell that it
belongs to, therefore the UE can use this channel to determine the
received signal strength of this particular cell. Furthermore the
P-CPICH is also used as a phase and power reference for the other
downlink physical channels.
The downlink common control channels have to reach all UEs in
the cell and should not be too loud to disturb other cells. As the
cell size is often adjusted, it may occur that the power level of all
control channels must be readjusted. To simplify this, the power
level of all control channels are expressed in relation to the power
that is used by the Pilot Channel of a cell. That is, when the power
of P-CPICH is reduced, the power of all other common channels is
reduced by the same factor.
S-CPICH The Secondary Common pilot Channel may be transmitted over the
entire cell or a part of the cell. There may be zero, one or several
S-CPICH per cell. An S-CPICH may be the phase reference for the
secondary CCPCH and the downlink DPCH. If this is the case, the
UE is informed about this by higher layer signaling.
PICH The Paging Indicator Channel informs the UE that paging
information will shortly be available for that mobile over the
S-CCPCH. This is an efficient process which saves the UE from
having to permanently listen in on the S-CCPCH.
....................................................................................................................................................................................................................................
Common Description
downlink
physical
channels
AICH The Acquisition Indicator Channel is a common downlink physical
channel which works closely together with the uplink PRACH.
Upon reception of an access preamble from a UE, the Node B uses
the AICH to acknowledge the success of the transmission and to
inform the UE that it can stop ramping up its power.
PDSCH The Physical Downlink Shared Channel is shared by several users
based on code multiplexing.
HS-PDSCH The High Speed Physical Downlink Shared Channel (HS-PDSCH)
carries the data traffic in the form of MAC-hs Packet Data Units
(PDUs). It has a fixed spreading factor of 16. This allows for up to
15 parallel channels. The transmit power is set by the scheduler,
that is, it is constant during one transmit time interval.
HS-SCCH The High Speed Shared Control Channel (HS-SCCH) transmits the
information about the configuration to be used next on the
HS-PDSCH channel. It has a fixed spreading factor of 128. The UE
can monitor up to four HS-SCCH channels.
Dedicated downlink physical channels

The following is a list of the dedicated downlink physical channels:
Dedicated Description
downlink
physical
channels
DPCH There is only one type of downlink dedicated physical channel, the
Downlink Dedicated Physical Channel (downlink DPCH).
Within one downlink DPCH, dedicated user data generated at layer
2 and above (from MAC and above at the RNC) and control
information generated at layer 1 (known pilot bits, TPC commands,
and an optional TFCI) are multiplexed at the Node B and
transmitted together over the U u interface. The downlink DPCH can
thus be seen as a time multiplex of a downlink DPDCH and a
downlink DPCCH.
E-HICH The E-DCH HARQ Indication Channel (E-HICH) carries the
ACK/NACK information from the E-DCH Active Set cells that a
packet was received and retrieved successfully. This channel uses a
spreading factor of 128.
....................................................................................................................................................................................................................................
downlink
physical
channels
E-AGCH The E-DCH Absolute Grant Channel carries the E-DCH Radio
Network Temporary Identifier, the HARQ Process Activation flag,
and the maximum power ratio the UEs may use for E-DCH
transmission. This channel uses a spreading factor of 256.
E-RGCH The E-DCH Relative Grant Channel (E-RGCH) With this, the radio
resource limitations established on particular UEs can be changed.
This channel uses a spreading factor of 128.
Common uplink physical channels

The following is a list of the common uplink physical channels:
Common uplink Description

physical
channels
PRACH The PRACH only exists in the uplink and enables the UE to send
messages to the UTRAN, without having a dedicated channel.
Typically, the PRACH is used when a mobile user wishes to initiate
a call and requests radio resources.
Because all the users in a cell need to share the use of the PRACH,
a mechanism was devised (slotted Aloha) to regulate access to the
PRACH and thus prevent collisions. UEs receive information on
what access slots are available in the current cell over the broadcast
channel (BCH). The access slots have time offsets that are spaced
1.25 ms apart.
Dedicated uplink physical channels

In contrast to the one dedicated downlink physical channel, there are two dedicated
uplink physical channels: the Dedicated Physical Data CHannel (DPDCH) and the
Dedicated Physical Control CHannel (DPCCH). The uplink transmits the DPDCH and
the DPCCH logically separate from one another. There may be zero, one, or several
uplink DPCHs on each Layer 1 connection.
....................................................................................................................................................................................................................................
The following is a list of the dedicated uplink physical channels:
uplink physical
channels
DPDCH The uplink DPDCH is used to carry dedicated user data generated
at Layer 2 and above, i.e. data taken from the dedicated transport
channel (DCH). There may be zero, one, or several uplink DPDCHs
on each Layer 1 connection.
DPCCH UE-specific uplink channel that feedbacks the ACK/NACK for
HARQ, and channel quality information for the scheduler. It has a
fixed spreading factor of 256. This channel is code multiplexed to
the uplink DPCCH.
The Layer 1 control information consists of the same control
information as used in the downlink with the addition of FBI bits:
• Transmit Power Control (TPC) allows the UE to tell the Node
B to either increase or decrease its transmission power.
• The TFCI is used in order to inform the receiving side of the
currently valid Transport Format Combination, and hence how
to decode, de-multiplex and deliver the received data on the
appropriate Transport Channels.
• Pilot bits support channel estimation for coherent detection.
• By means of the FBI-Bits (FeedBack Information), the UE can
have the Node B regulate the phase and amplitude in the case
of Closed Loop Transmit Diversity.
HS-DPCCH The High Speed Dedicated Physical Control Channel is a
UE-specific uplink channel that feedbacks the ACK/NACK
messages for Hybrid Automatic Repeat Requests (HARQ), and
channel quality information for the scheduler. It has a fixed
spreading factor of 256. This channel is code multiplexed to the
uplink DPCCH.
E-DPDCH The Enhanced Dedicated Physical Data Channel (E-DPDCH) carries
the user traffic from the UE and uses a range of spreading factors,
depending on the data traffic rate. E-DPDCH supports the 2 ms
TTI and the 10 ms TTI.
E-DPCCH The Enhanced Dedicated Physical Data Channel (E-DPDCH) carries
control information on the E-DCH associated physical layer
signaling channel transmitted by the UE. This channel uses a
spreading factor of 256 to forward the Transport Format
Combination Indicator used on E-DCH (E-TFCI), the HARQ related
Retransmission Sequence Number (RSN), and a “happy bit” as a
feedback to the Node B.
....................................................................................................................................................................................................................................
UTRAN Signaling
Transport channels
...................................................................................................................................................................................................................................
Introduction
The transport channels convey data from the MAC layer to the physical layer and there
are mapped to physical channels.
The physical layer offers the transport channels different bitrates, depending on the
spreading factor used.
Several transport channels are multiplexed on one physical channel.
Transport channels are mapped to physical channels as shown in the illustration.
...................................................................................................................................................................................................................................
UTRAN Signaling Transport channels
Physical channels
Uplink
Downlink P-SCH
Bidirectional
Fixed
Association
P-CPICH

S-CPICH
BCCH BCH P-CCPCH
PCCH PCH PICH
CCCH FACH S-CCPCH
CTCH RACH PRACH
DCCH AICH
DTCH DCH DPDCH

DPCH
DPCCH
HS-DPCCH
HS-DSCH HS-PDSCH
HS-SCCH
E-DCH E-DPDCH
E-DPCCH
E-HICH
E-AGCH E-RGCH
....................................................................................................................................................................................................................................
Dedicated and common transport channels

There are two types of transport channels: dedicated transport channels and common
transport channels. The common transport channels may be used by multiple users, the
dedicated transport channel to one single UE only.
There are three dedicated transport channels:
transport
channels
DCH The Dedicated Channel (DCH) is a channel dedicated to one
particular UE used in uplink or downlink direction.
E-DCH The Enhanced Dedicated Channel (E-DCH) is the uplink transport
channel that carries the E-DPDCH and the other E-DCH physical
channels as associated channels.
E-DCH uses fixed coding and modulation codes, and multiple
HARQ processes to enhance the uplink performance. The Node B
has the power control for this channel to minimize uplink
interference levels.
There are six common transport channels:
Common Description
transport
channels
RACH The Random Access Channel (RACH) is a contention based uplink
channel used for transmission of relatively small amounts of data,
e.g. for initial access or non-real-time dedicated control or traffic
data.
FACH The Forward Access Channel (FACH) is a common downlink
channel without closed-loop power control used for transmission of
relatively small amount of data.
BCH The Broadcast Channel (BCH) is a downlink channel used for
broadcast of system information into an entire cell.
PCH The Paging Channel (PCH) is a downlink channel used for
broadcast of control information into an entire cell allowing
efficient UE sleep mode procedures. Currently identified
information types are paging and notification. Another use could be
UTRAN notification of change of BCCH information.
....................................................................................................................................................................................................................................
Common Description
transport
channels
CPCH The Common Packet Channel (CPCH) is a contention based uplink
channel (FDD) used for transmission of bursty data traffic. This
channel is shared by the UEs in a cell
DSCH The Downlink Shared Channel (DSCH) is a downlink channel
shared by several UEs carrying dedicated control or traffic data.
HS-DSCH The High Speed Downlink Shared Channel (HS-DSCH) is the
transport channel that carries the Physical Downlink Shared
Channel (HS-PDSCH) and the Shared Control Channel HS-SCCH)
for HSDPA.
....................................................................................................................................................................................................................................
UTRAN Signaling
Logical channels
...................................................................................................................................................................................................................................
Introduction
A set of logical channel types is defined for different kinds of data transfer services as
offered by MAC. Each logical channel type is defined by the type of information
transferred as opposed to transport channels which define how data is transported.
Logical Channels
The following is a list of the logical channels:
Logical Description
channels
BCCH Broadcast Control Channel (BCCH) is a downlink channel for
broadcasting system control information.
PCCH The Paging Control Channel (PCCH) is a downlink channel that
transfers paging information. This channel is used when the
network does not know the location cell of the UE, or, the UE is in
the cell connected state (utilising UE sleep mode procedures).
CCCH The Common Control Channel (CCCH) is a Bi-directional channel
for transmitting control information between network and UEs. This
channel is commonly used by the UEs having no RRC connection
with the network and by the UEs using common transport channels
when accessing a new cell after cell reselection.
CTCH The Common Traffic Channel (CTCH) is a point-to-multipoint
unidirectional channel for transfer of dedicated user information for
all or a group of specified UEs.
DCCH The Dedicated Control Channel (DCCH) is a point-to-point
bi-directional channel that transmits dedicated control information
between a UE and the network. This channel is established through
RRC connection setup procedure.
DTCH The Dedicated Traffic Channel (DTCH) is a point-to-point channel,
dedicated to one UE, for the transfer of user information. A DTCH
can exist in both uplink and downlink.
Channel mapping
The following figure illustrates the logical channels and their corresponding transport
channels that MAC is responsible for mapping:
...................................................................................................................................................................................................................................
UTRAN Signaling Logical channels
Physical channels
Uplink
Downlink P-SCH
Bidirectional
Fixed
Association
P-CPICH

S-CPICH
BCCH BCH P-CCPCH
PCCH PCH PICH
CCCH FACH S-CCPCH
CTCH RACH PRACH
DCCH AICH
DTCH DCH DPDCH

DPCH
DPCCH
HS-DPCCH
HS-DSCH HS-PDSCH
HS-SCCH
E-DCH E-DPDCH
E-DPCCH
E-HICH
E-AGCH E-RGCH
....................................................................................................................................................................................................................................
UTRAN Signaling
Air interface protocols
Overview
...................................................................................................................................................................................................................................
Purpose
• to describe the protocols of the air interface
• to map these protocols to their layer and sublayer of the protocol stack
• to explain the function of the air interface protocols.
Contents
Medium Access Control 3-27

Radio Link Control 3-31
Packet Data Convergence Protocol (PDCP) 3-34
Radio Resource Control 3-35
RRC State Machine 3-38
RRC Connection and Signaling Connection 3-39
Signaling radio bearers 3-40
Radio bearer establishment 3-44
...................................................................................................................................................................................................................................
UTRAN Signaling
Medium Access Control

...................................................................................................................................................................................................................................

The MAC model maps the transport channels it receives from the physical layer to the
logical channels it passes on to the Radio Link Control protocol and vice versa.
MAC takes each RLC PDU from the logical channel and constructs a MAC PDU (also
known as transport block) according to the Transport Format defined for the transport
channel. Each transport channel can have different bit rates. Thus, the MAC model is
responsible for transporting blocks of data according to the specified channel bit rate.
The illustration shows the position of the MAC protocol.

GC Nt DC
control
(RRC)
PDCP
DCP L2/PDCP
control
BMC L2/BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC RLC RLC
Logical
Channels
Transport
Channels
Physical
Channels
...................................................................................................................................................................................................................................
UTRAN Signaling Medium Access Control
Functions and Services

The MAC sublayer provides the following functions and services:
Function and Description

service
Mapping between The MAC is responsible for mapping logical channel(s) onto the
logical channels appropriate transport channel(s).
and transport
channels.
Selection of Given the Transport Format Combination Set assigned by RRC,
appropriate MAC selects the appropriate transport format within an assigned
Transport Format transport format set for each active transport channel depending
for each Transport on source rate. The control of transport formats ensures efficient
Channel depending use of transport channels.
on instantaneous
source rate.
Priority handling When selecting between the Transport Format Combinations in
between data flows the given Transport Format Combination Set, priorities of the
of one UE. data flows to be mapped onto the corresponding Transport
Channels can be taken into account. Priorities may be given
according to attributes of Radio Bearer services and RLC buffer
status. The priority handling is achieved by selecting a Transport
Format Combination for which high priority data is mapped onto
layer 1 with a ″high bit rate″ Transport Format, at the same time
letting lower priority data be mapped with a ″low bit rate″ (could
be zero bit rate) Transport Format. Transport format selection
may also take into account transmit power indication from layer
1.
Identification of When a particular UE is addressed on a common downlink
UEs on common channel, or when a UE is using the RACH, there is a need for
transport channels. inband identification of the UE. Since the MAC layer handles the
access to, and multiplexing onto, the transport channels, the
identification functionality is naturally also placed in MAC.
Traffic volume Measurement of traffic volume on logical channels and reporting
monitoring. to RRC. Based on the reported traffic volume information, RRC
performs transport channel switching decisions.
Ciphering This function prevents unauthorised acquisition of data. Ciphering
is performed in the MAC layer for transparent RLC mode.
Data transfer This service provides unacknowledged transfer of MAC SDUs
between peer MAC entities. This service does not provide any
data segmentation. Therefore, segmentation/reassembly function
should be achieved by upper layer.
....................................................................................................................................................................................................................................
Function and Description

service
Reallocation of This service performs on request of RRC execution of radio
radio resources and resource reallocation and change of MAC parameters, i.e.
MAC parameters. reconfiguration of MAC functions such as change of identity of
UE, change of transport format (combination) sets, change of
transport channel type.
MAC entities
MAC is structured into the following dedicated MAC entities:
• Dedicated MAC (MAC-d) terminates in the SRNC
• Common MAC (MAC-c/sh) terminates in the CRNC
• MAC-b is the entity that handles the broadcast channel (BCH). There is one
MAC-b entity in each UE and one MAC-b in the Node B.
Data transfer type

The MAC protocol can be one of two data transfer types:
• transparent MAC
• or non-transparent MAC.
The data transfer type depends on whether a MAC header is attached to the packet.
The case where no MAC header is required is referred to as ″transparent″ MAC
transmission.
Parameters of the MAC header

The following fields are defined for the MAC header:
• The C/D field is a single-bit flag that provides identification of the logical channel
class on FACH and RACH transport channels, i.e. whether it carries CCCH or
dedicated logical channel information.
• The C/T field provides identification of the logical channel instance when multiple
logical channels are carried on the same transport channel. The C/T field is used
also to provide identification of the logical channel type on dedicated transport
channels and on FACH and RACH when used for user data transmission.
• The UE-Id field provides an identifier of the UE.
Depending on the logical to transport mapping relationship, all, a selection or none of
the above parameters may be used.
....................................................................................................................................................................................................................................
Here are some examples:

• DTCH or DCCH mapped to DCH, no multiplexing of dedicated channels on MAC:
No MAC header is required.
• DTCH or DCCH mapped to DCH, with multiplexing of dedicated channels on
MAC: C/T field is included in MAC header.
• DTCH or DCCH mapped to RACH/FACH: C/D field and UE-Id are included in
the MAC header. C/T field is included if multiplexing on MAC is applied.
....................................................................................................................................................................................................................................
UTRAN Signaling
Radio Link Control

...................................................................................................................................................................................................................................
Introduction
The Radio Link Control (RLC) protocol is situated between the Medium Access
Control and the Radio Resource Control protocols.

GC Nt DC
control
(RRC)
PDCP
DCP L2/PDCP
control
BMC L2/BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC RLC RLC
Logical
Channels
Transport
Channels
Physical
Channels
Radio Link Control

The Radio Link Control (RLC) protocol provides logical link control over the radio
interface.
There may be several simultaneous RLC links per User Equipment; each link is
identified by a bearer id.
RLC provides three types of Service Access Points (SAP), corresponding to three
different RLC data transfer modes:
1. In Transparent Mode (TM), RLC transmits upper layer protocol data units (PDUs)
without adding any protocol control information (no RLC header).
2. In Unacknowledged Mode (UM), RLC transmits upper layer PDUs without
guaranteeing delivery to the peer entity.
3. In Acknowledged Mode (AM), RLC transmits upper layer PDUs guaranteeing
delivery to the peer entity. AM RLC is used for the packet-switched RABs.
...................................................................................................................................................................................................................................
UTRAN Signaling Radio Link Control
The following illustration shows the three different RLC data transfer modes:
Radio Resource Control
Transparent Acknowledged Unacknowledged

mode mode mode
RLC
MAC
L1
Services offered by the 3 modes

The type of transmission mode used depends on the link direction and the channel type
to be transmitted. For example, in the UE downlink side, the CCCH may be sent in
TM; the DCCH may be sent in AM or UM; the DTCH may be sent in TM, AM or
UM.
Transparent mode services

RLC receives SDUs from the higher layers. RLC might segment the SDUs into
appropriate RLC PDUs without adding any overhead. How to perform the
segmentation is decided upon when the service is established. RLC delivers the RLC
PDUs to MAC through either a BCCH, PCCH, DCCH, or a DTCH. Which type of
logical channel depends on if the higher layer is located in the control plane (BCCH,
PCCH, DCCH) or user plane (DTCH).
Transparent mode services:
• Segmentation and reassembly
• Transfer of user data.
Unacknowledged mode services

RLC receives SDUs from the higher layers. If the SDU is too large it is segmented
into appropriate RLC PDUs. The SDU might also be concatenated with other SDUs.
RLC adds a header and the PDU is placed in the transmission buffer. The RLC then
decides which PDUs and when the PDUs are delivered to MAC.
The RLC also decides which logical channel should be used. The number of logical
channels that is needed is decided upon when the service is established. The type of
the logical channels depends on if the higher layer is located in the control plane
(DCCH) or in the user plane (DTCH).
....................................................................................................................................................................................................................................
UTRAN Signaling Radio Link Control
Unacknowledged mode services:

• Concatenation
• Transfer of user data.
Acknowledged mode services

RLC receives SDUs from the higher layers. For a packet switched service, the RLC
SDU is normally one IP packet. The SDUs are segmented and/or concatenated to
PDUs of fixed length. The length of the PDUs is decided upon when the service is
established. After that RLC adds a header and the PDU is placed in the retransmission
buffer and the transmission buffer.
The RLC then decides which PDUs and when the PDUs are delivered to MAC, e.g. it
could be useful to send RLC control PDUs on one logical channel and data PDUs on
another logical channel. The retransmission buffer also receives acknowledgements
from the receiving side, which are used to indicate retransmissions of PDUs and when
to delete a PDU from the retransmission buffer.
Acknowledged mode services
• Concatenation
• Transfer of user data
• Error correction
• In-sequence delivery of higher layer PDUs
• Duplicate detection
• Flow Control
• Protocol error detection
• Recovery.
The Acknowledged Mode (AM) RLC ″toolbox″ includes various functions that allow
setting up different automatic repeat request (ARQ) schemes. An AM RLC entity is
configured by approximately 20 parameters. Proper setting and optimisation of these
parameters is vital to provide packet-switched RABs with the required quality of
service (QoS).
....................................................................................................................................................................................................................................
UTRAN Signaling
Packet Data Convergence Protocol (PDCP)

...................................................................................................................................................................................................................................
Introduction
PDCP is a layer–2, user plane protocol, located above the Radio Link Control protocol.

GC Nt DC
control
(RRC)
PDCP
DCP L2/PDCP
control
BMC L2/BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC RLC RLC
Logical
Channels
Transport
Channels
Physical
Channels
Header compression and decompression

The PDCP protocol provides header compression and decompression of IP data streams
at the transmitting and receiving entities respectively. Header compression algorithms
are available for TCP/IP, RTP/UDP/IP.
Transfer of user data

Transmission of user data means that PDCP receives PDCP SDU from the NAS and
forwards it to the RLC layer and vice versa.
Data buffer
If the SRNC needs to be relocated and a delay ensues, the PDCP also has buffering
capabilities. Each PDCP SDU is numbered from 0 — 255 and buffered until the RLC
acknowledges the reception of transmitted PDCP PDPs. Once the acknowledgement
arrives, data flow can recommence.
...................................................................................................................................................................................................................................
UTRAN Signaling

...................................................................................................................................................................................................................................
Introduction
Radio Resource Control (RRC) handles the control plane signaling of layer 3 between
the UEs and UTRAN
The following illustration shows the position of the RRC protocol in the Radio
Interface Protocol architecture.

GC Nt DC
control
(RRC)
PDCP
DCP L2/PDCP
control
BMC L2/BMC
RLC RLC
RLC RLC L2/RLC
RLC RLC RLC RLC
Logical
Channels
Transport
Channels
Physical
Channels
Interfaces
The RRC provides the signaling interface to the non-access stratum with the following
services (see illustration above):
• General Control (GC): information broadcast service
• Notification (Nt): paging and notification broadcast services
• Dedicated Control (DC): connection management and message transfer.
The RRC connects to the RLC over any of its 3 connection modes.
The RRC manages the configuration of layer 2 and layer 1 protocols with direct links
to each of the lower layers.
The following illustration shows the lower layer interactions of the RRC.
...................................................................................................................................................................................................................................
UTRAN Signaling Radio Resource Control
The arrows going to the RRC show the RRC receiving measurement data from the
lower layers, the arrows going from the RRC show the RRC sending control messages
to the lower layers.
Radio Resource
Assignment
(mapping, TF set
frequency, code
RRC TS, etc) RRC
RLC transmission
RLC control RLC
MAC MAC
L1 L1
UTRAN UE
Functions
The RRC performs the following functions:
• Broadcast of information provided by the non-access stratum (Core Network): The
RRC layer performs system information broadcasting from the network to all UEs.
The system information is normally repeated on a regular basis.
• Broadcast of information related to the access stratum.
• Establishment, re-establishment, maintenance and release of RRC connections.
• Establishment, reconfiguration and release of Radio Bearers: The establishment of
an RRC connection is initiated by a request from higher layers at the UE side to
establish the first Signalling Connection for the UE.
• Assignment, reconfiguration and release of radio resources for the RRC connection:
The RRC layer can, on request from higher layers, perform the establishment,
reconfiguration and release of Radio Bearers in the user plane.
• Paging/notification: The RRC layer can broadcast paging information from the
network to selected UEs. Higher layers on the network side can request paging and
notification. The RRC layer can also initiate paging during an established RRC
connection.
....................................................................................................................................................................................................................................
UTRAN Signaling Radio Resource Control
• Control of requested QoS.

• RRC connection mobility functions: The RRC layer performs evaluation, decision
and execution related to RRC connection mobility during an established RRC
connection, such as handover, preparation of handover to GSM, cell re-selection
and cell/paging area update procedures.
• UE measurement reporting and control of the reporting.
• Outer loop power control.
....................................................................................................................................................................................................................................
UTRAN Signaling
RRC State Machine

...................................................................................................................................................................................................................................
RRC state machine

The RRC state machine is a description model of how the UE and the UTRAN
co-operate regarding RRC functionality.
The RRC state machine exists as two peer entities (UE and UTRAN). The two peer
entities are synchronized.
There are two modes in the RRC state machine:
• Idle mode
• Connected mode.
UE position can be known on different levels:
– URA level
– Cell level
Idle mode
After power on, the UE stays in idle mode until it transmits a request to establish an
RRC connection. In idle mode, the UE is identified by non-access stratum identities
such as IMSI, P-TMSI and TMSI. In addition, the UTRAN has no information about
the individual idle mode UEs, and can only address either all UEs in a cell or all UEs
in a paging group. The UE receives paging messages on the PCH.
Connected mode
Connected mode is entered when the RRC connection is established. The UE is
assigned a radio network temporary identity (RNTI) to be used as UE identity on
common transport channels. The UE leaves connected mode and returns to idle mode
when the RRC connection is released or at RRC connection failure.
The connected mode of the UE can be known on different levels:
• URA level (UTRAN registration area): URA is a specified set of cells hich can be
identified on the BCCH. URA is only internally known in the UTRAN.
• Cell level: different channel types can be used for data transfer such as Common
transport channels (RACH, FACH, CPCH, DSCH) or Dedicated transport channels
(DCH).
...................................................................................................................................................................................................................................
UTRAN Signaling
RRC Connection and Signaling Connection

...................................................................................................................................................................................................................................
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
RRC Connection RANAP Connection
Relay
RRC RANAP
RRC RANAP
UE Uu Node B Iub RNC Iu SGSN\MSC
...................................................................................................................................................................................................................................
UTRAN Signaling
Signaling radio bearers

...................................................................................................................................................................................................................................
Definitions
Signaling radio bearer The radio bearers available for transmission of RRC messages
are defined as “signalling radio bearers”.
Signaling connection An acknowledged-mode link between the UE and the CN to
transfer higher layer information between the entities in the non-access stratum (via
RRC and RANAP).
RRC connection establishment in DCH state

This example shows the steps taken during the establishment of an RRC connection in
DCH state.
...................................................................................................................................................................................................................................
UTRAN Signaling Signaling radio bearers
Node B
UE Serving RNS Serving RNC
1. CCCH: RRC Connection Request
Select L1 +L2
parameters
2. Radio Link Setup Request
3. Radio Link Setup Response
4. ALCAP Iub Data Transport Bearer Setup
5. Downlink Synchronization
6. Uplink Synchronization
7. CCCH: RRC Connection Setup
8. DCCH: RRC Connection Setup Complete
Steps of the RRC connection establishment

The following is a description of the RRC connection establishment process:
...................................................................................................................................................................................................
1 The UE initiates the set-up of an RRC connection by sending an RRC message

Connection Request on the CCCH.
....................................................................................................................................................................................................................................
...................................................................................................................................................................................................
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.
Signaling radio bearers per RRC connection

4 signaling radio bearers are set up per RRC connection.
• 2 signaling radio bearers for transport of RRC generated signaling messages.
The 2 signaling radio bearers are for transferring messages thus:
– 1 for transferring messages through an RLC UM entity and
– 1 for transferring messages through an RLC AM entity.
• 1 signaling radio bearer for transferring NAS messages set to ″high priority″ by the
higher layers (RLC AM)
....................................................................................................................................................................................................................................
• And 1 signaling radio bearer for transferring NAS messages set to ″low priority″
by the higher layers (RLC AM)
• Subsequent to the establishment of the signaling connection zero to several
signaling radio bearers may be set up for transferring RRC signaling messages
using transparent mode RLC (RLC TM entity).
Signaling radio bearer configuration at the UE

The RRC on the UE side configures L1 and MAC and creates the new RLC entities
with the parameters given by the network-side RRC.
The following illustration shows the newly created signaling radio bearers after the
creation of the RRC connection.
control Radio Resource Control

control (RRC)
control
control
Signaling
Radio
Bearers
New RLC
entities
RLC
RLC
RLC
RLC
MAC
parameters
Medium Access Control (MAC)
L1
Parameters
Physical Layer (PHY)
....................................................................................................................................................................................................................................
UTRAN Signaling
Radio bearer establishment

...................................................................................................................................................................................................................................
Definitions
Radio bearer A service provided by the RLC layer for transfer of user data between
UE and SRNC.
Radio access bearer The service that the access stratum provides to the non-access
stratum for transfer of user data between UE and CN. Consists of radio bearer
service and Iu bearer service. Known by RAB identifier (RAB ID).
Radio Access Bearer establishment

This example shows the steps involved in the establishment of a Radio Access Bearer.
...................................................................................................................................................................................................................................
UTRAN Signaling Radio bearer establishment
UE Node B RNC MSC
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
Radio Access Bearer establishment process

The following is a description of the Radio Access Bearer connection establishment
process:
...................................................................................................................................................................................................
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.
Radio Access Bearer establishment

The following illustration shows the newly created radio bearer after the creation of the
Radio Access Bearer.
....................................................................................................................................................................................................................................
New Radio
Bearer
control Radio Resource Control
(RRC)
PDCP DCP
control
BMC
RLC RLC New RLC

entity
RLC
RLC
RLC
MAC
parameters
Medium Access Control (MAC)
L1
Parameters
Physical Layer (PHY)
....................................................................................................................................................................................................................................
UTRAN Signaling
UTRAN protocols
Overview
...................................................................................................................................................................................................................................
Purpose
• to describe the protocol structure of the UTRAN interfaces
• to map the UTRAN protocols to their specific layers on the Control Plane and User
Plane
• to explain the function of the UTRAN protocols.
Contents
Iub protocol structure 3-49

Protocols of the Iub interface 3-51
Iur interface 3-54
Iu-cs interface 3-56
...................................................................................................................................................................................................................................
UTRAN Signaling
Iub protocol structure

...................................................................................................................................................................................................................................
Iub protocol structure

The following illustration shows the protocol structure of the Iub interface.
Transport Network
Control Plane Control Plane User Plane
Radio NBAP
DCH FP
RACH FP
FACH FP
PCH FP
DSCH FP
USCH FP
CPCH FP
Network
Layer
Transport
Network Transport Network Transport Network
Layer User plane ALCAP Q.2630.2 User plane
STC Q.2150.2
SSCF-UNI SSCF-UNI
SSCOP SSCOP
AAL5 AAL5 AAL2
Physical
Layer
Two functional layers

The Iub interface protocol architecture consists of two functional layers:
• The Radio Network Layer defines procedures related to the operation of Node B.
The radio network layer consists of a radio network control plane and a radio
network user plane.
• The Transport Layer defines procedures for establishing physical connections
between Node B and the RNC.
...................................................................................................................................................................................................................................
UTRAN Signaling Iub protocol structure
Functional Separation
In order to maintain a concise structure, on the Iub interface the radio network layer
and the transport layer are clearly separated. Therefore, the radio network signaling and
Iub data streams are separated from the data transport resource and traffic handling.
This resource and traffic handling is controlled by the transport signaling. The transport
signalling is carried by a signalling bearer over the Iub interface.
....................................................................................................................................................................................................................................
UTRAN Signaling
Protocols of the Iub interface

...................................................................................................................................................................................................................................
Logical structure of the Iub interface

The following illustration shows the UTRAN protocol architecture with the protocols
of the Iub highlighted.
SM SM
IP PMM PMM
PDCP RRC
RRC PDCP GTP
-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 - 1
STM STM-1
Control plane
User plane
UE Uu Node B Iub RNC Iu-ps SGSN
Overview of the Iub protocols

The following table lists the protocols of the Iub.
• Access Link Control Application Part ALCAP
• Node B Application Part NBAP
• Service Specific Connection Oriented Protocol SSCOP
• Framing protocols FP
• ATM Adaptation Layer AAL
• Asynchronous Transmission Mode ATM
• The physical layer.
...................................................................................................................................................................................................................................
UTRAN Signaling Protocols of the Iub interface
Access Link Control Application Part

The Access Link Control Application Part ALCAP over SSCOP on AAL5 provides the
dynamic setup and teardown of data bearers over AAL2 links. ALCAP is not
responsible for signaling bearers, ensuring the separation of the two domains. The
application protocol of the control plane, NBAP, requests ALCAP to create or tear
down a data bearer. User data is ultimately transmitted over these data bearers.
Node B Application Part

The Node B Application Protocol (NBAP) is used for all control messages that are sent
between the RNC and the Node B.
The signaling bearer in the Radio Network Control Plane is SAAL-UNI over ATM.
These are SSCF-UNI on top of SSCOP and AAL Type 5.
Service Specific Connection Oriented Protocol

The SSCOP protocol stack provides the layer of processing between the AAL Type 5
and the NBAP and ALCAP processing entities.
The SSCF-UNI maps the requirements of the layer above to the requirements of
SSCOP. Also SAAL connection management, link status and remote processor status
mechanisms are provided. SSCOP provides mechanisms for the establishment and
release of connections and the reliable exchange of signaling information between
signaling entities. It adapts the upper layer protocol to the requirements of the Lower
ATM cells.
Framing protocols
The AAL2 links are used to carry user plane data which are encapsulated in various
Framing Protocols (DCHFP, FACHFP and RACHFP)
ATM Adaptation Layer

The ATM Adaptation Layer (AAL) is defined to enhance the services provided by the
ATM layer to support the functions required by the next higher layer.
Different AALs support various protocols to suit the different needs of a range of AAL
service users. AAL2 and AAL5 are used at the Iub.
AAL2 links are used to carry user plane data (circuit and packet).
AAL5 links are used to carry control plane data.
ATM
ATM is used on the Iub interface for the transportation of packages using the ATM
backbone network.
....................................................................................................................................................................................................................................
UTRAN Signaling Protocols of the Iub interface
The physical layer

The PCM30 or PCM24 interface (E1 or T1) is used on the Iub interface as the physical
layer at the Node B. ATM concentrators are used to combine the PCM30/PCM24
carriers to STM-1 or OC-3 which is the physical interface at the RNC.
....................................................................................................................................................................................................................................
UTRAN Signaling
I...................................................................................................................................................................................................................................
ur interface
Introduction
Several different higher-layer protocols are used on the Iur interface. This topic
provides a short explanation for each of them.
Interface diagram
The following figure shows the location of the Iur interface in the UMTS network.
Core Network
VLR
MSC SGSN
IuCS IuPS
IuPS IuCS
Iur
RNC RNC
Iub Iub Iub Iub
Node B Node B Node B Node B
Cells Cells Cells Cells
Physical layer
The SDH STM-1 or the SONET OC-3 interface is used on the Iur interface as the
physical layer.
ATM
ATM is used on the Iur interface for the transportation of packages using the ATM
backbone network.
...................................................................................................................................................................................................................................
UTRAN Signaling Iur interface
RNSAP
The Radio Network Subsystem Application Part (RNSAP) protocol is used for all
control messages that are sent between the Serving RNC and the Drift RNC.
ALCAP
The Access Link Control Application Part (ALCAP) protocol is used for ATM control
of the circuit switched connections between the serving RNC and the drift RNC.
User data
The user data (signaling/voice/data) sent between the serving RNC and the drift RNC.
....................................................................................................................................................................................................................................
UTRAN Signaling
Iu-cs interface
...................................................................................................................................................................................................................................
Key functions
Transport of data and control traffic for circuit-switched services, including:
• Establishment and release of circuit-switched access bearers
• Transfer of non-access stratum signaling messages between user equipment and the
core network
Transport layer
The transport layer supports Asynchronous Transfer Mode (ATM).
ATM Adaptation Layer 2 and ATM Adaptation Layer 5 are used.
Physical layer
The physical layer supports shared Synchronous Transport Module-1 (STM-1) optical
interfaces.
Protocols used
The WAG supports the following protocol stack for the Iu-cs interface:
Radio Transport
Network Network
Control Plane Control Plane User Plane
Radio RANAP User plane

Network protocol
Layer
Q.2630.1
Transport SCCP Q.2150.1
Network MTP3-B MTP3-B
Layer
SSCF-NNI SSCF-NNI
SSCOP SSCOP
AAL5 AAL5 AAL2
ATM
STM-1
...................................................................................................................................................................................................................................
UTRAN Signaling Iu-cs interface
....................................................................................................................................................................................................................................
Part II: Optimization process
Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 4, Optimization process 4-1

Chapter 5, Drive testing 5-1
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary II-1
4 O ptimization process
4
Overview
...................................................................................................................................................................................................................................
Purpose
This lesson describes when optimization is performed during a network lifecycle and
the phases of the optimization process.
Contents
Network lifecycle 4-2

Optimization process phases 4-4
Planning and preparation (site readiness) 4-7
Drive test optimization before live traffic 4-9
Information gathering 4-11
Information analysis 4-12
...................................................................................................................................................................................................................................
Optimization process
Network 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
Network lifecycle stages

This shows the stages in the lifecycle of a network and the place of optimization in the
lifecycle:
...................................................................................................................................................................................................
1 Create a design for a UMTS network.

The design is typically created using (RF) design software.
...................................................................................................................................................................................................
2 Optimize the design of the network.

The design is typically optimized for coverage or capacity using optimization software
that provides recommendations for:
• Antenna tilt and orientation
• Power levels.
...................................................................................................................................................................................................................................
Optimization process Network lifecycle
...................................................................................................................................................................................................
3 Sites are planned and engineered according to the network design.

This translates the design in equipment in 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.
...................................................................................................................................................................................................
4 During implementation the sites are built.

This can mean that there are differences between the planned site and the completed
site.
The data from the completed 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 before live traffic”
...................................................................................................................................................................................................
6 When all sites are completed and tested, final (drive) tests are performed to check if
the network complies to the customer 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.
...................................................................................................................................................................................................................................
Optimization process phases

...................................................................................................................................................................................................................................
Purpose
This topic shows the stages of the optimization process in a live network.
Site readiness checks must have been performed before optimization starts.
Optimization process flow

Optimization process flow:
Begin
Gather information
Analyze information
Optimization N
problem?
Sufficient N
information?
Identify reason
Determine solution
Implement solution
Gather and analyze

information
Y Problem N
solved?
...................................................................................................................................................................................................................................
Optimization process Optimization process phases
Optimization process stages

The optimization process consists of the following stages:
...................................................................................................................................................................................................
1 Collect information.
Result: Main information sources are:
• Drive tests
• Customer complaints
• Performance measurements and Key Performance Indicators (KPIs).
...................................................................................................................................................................................................
2 Analyze information to determine if the network complies to requirements.

Result: Use automated (computer) tools to handle large quantities of complex data.
...................................................................................................................................................................................................
3 Determine if a problem is an optimization problem.

Result: For example, make sure the problem is not a fault.
...................................................................................................................................................................................................
4 If needed, gather additional information.

...................................................................................................................................................................................................
5 Identify the reason for the problem.

Result: For example:
• Capacity
• RF Coverage
• Cell breathing.
...................................................................................................................................................................................................
6 Determine solutions for the problem.

Result: Typically there are multiple solutions to solve a problem. Choose the best
solution, for example based on:
• Cost of implementation
• Easy of implementation
• Chance of success.
...................................................................................................................................................................................................
7 Implement the solution that was chosen.

Implement only one solution at a time.
...................................................................................................................................................................................................................................
Optimization process Optimization process phases
Result: Implementation can range from a simple change of a OMC-UPS parameter

to the entire process of design, planning, engineering and optimization and
commissioning of new cells and sites.
...................................................................................................................................................................................................
8 Gather and analyze information.

Focus on the problem and the solution that was implemented.
...................................................................................................................................................................................................
9 When ... then ...

the problem is solved, go to Stage 1.
the problem is not solved, Restore the original settings when parameters were
changed.
go to Stage 6.
Continuous optimization
This process only has a “Begin” and not an “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.
...................................................................................................................................................................................................................................
Planning and preparation (site readiness)

...................................................................................................................................................................................................................................
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.
...................................................................................................................................................................................................................................
Optimization process Planning and preparation (site readiness)
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
can be post-processed. If sector problems do occur, they need to be remedied and the
tests repeated until they are successful.
Baseline existing system

The objective of baselining the existing system is to collect the RF performance
metrics of the existing UMTS system equipment. Baseline driving should be performed
prior to any RF optimization activity and involves measuring the Key Performance
Indicators. It is important to keep the drive routes and KPIs identical for performance
validation and comparison purposes.
...................................................................................................................................................................................................................................
Drive test optimization before live traffic

...................................................................................................................................................................................................................................
Purpose
Before a network takes on live traffic, an 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
This illustrates optimization steps that are performed before a network is commercially
deployed:
...................................................................................................................................................................................................
1 Perform site readiness checks.

This ensures all cells are operating as required.
• Spectrum clearance,
to ensure no external interferences are present and sufficient guard band are obeyed
• Antenna checks,
to ensure that the antenna system is properly installed (tilt, azimuth, cabling)
• Sector verification,
to ensure basic functionality of a sector (call processing, hand overs).
...................................................................................................................................................................................................
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.
...................................................................................................................................................................................................
3 Perform cluster optimization using drive tests.

This includes:
• Define clusters (group of cells)
• Unloaded cluster optimization,
to identify RF coverage holes, hand over regions and pilot coverage areas
...................................................................................................................................................................................................................................
Optimization process Drive test optimization before live traffic
• Loaded cluster optimization,

to measure effects of cell breathing
• Cluster performance verification,
to prove network meets customer criteria.
...................................................................................................................................................................................................
4 Perform system verification,

to prove the entire network (all clusters) meets customer exit criteria.
Result
The network is now ready for live traffic testing which leads into commercial service.
...................................................................................................................................................................................................................................
Information gathering
...................................................................................................................................................................................................................................
Purpose
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:
• Drive tests
Information from one of these sources, can trigger further investigation. During the
more detailed investigation information from other sources is gathered.
Key performance indicators

Key performance indicators (KPI) are used to determine if the network complies to the
levels of performance that are needed.
KPIs are calculated using measurements that are gathered by the OMC-UPS.
Changes in values of the key performance indicators, especially reaching thresholds are
often the first indication of an optimization problem.
Drive tests
Drive tests can be used to gather information in the network. A drive test can be
performed to gather information about a specific problem or problem area. Drive tests
can also be performed to gather general information about the network performance.
Customer complaints
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.
...................................................................................................................................................................................................................................
Information analysis
...................................................................................................................................................................................................................................
Purpose
Analysis of the information determines:
1. Whether 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).
Data analysis software tools

Because of the scale and complexity of a network, engineers are not able to handle the
large volumes of detailed information that is available. Engineers can use software
tools to handle the information and determine if there are problems.
Software tools can also be used to determine the consequences of implementing a
solution in the network. Using models, software can simulate the impact on the
network of implementing a solution.
Commercially available and proprietary tools are available to analyze information and
determine impacts.
...................................................................................................................................................................................................................................
5 D rive testing
5
Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Drive test optimization process 5-2

Planning and preparation (site readiness) 5-4
Optimization planning 5-6
Perform cluster optimization 5-8
Perform system verification 5-11
...................................................................................................................................................................................................................................
Drive testing
Drive test optimization process

...................................................................................................................................................................................................................................
Purpose
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:
...................................................................................................................................................................................................
1 Perform site readiness checks.

This ensures all cells are operating as required.
• Spectrum clearance,
to ensure no external interferences are present and sufficient guard band are obeyed
• Antenna checks,
to ensure that the antenna system is properly installed (tilt, azimuth, cabling)
• Sector verification,
to ensure basic functionality of a sector (call processing, hand overs).
...................................................................................................................................................................................................
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.
...................................................................................................................................................................................................
3 Perform cluster optimization using drive tests.

This includes:
• Define clusters (group of cells)
• Unloaded cluster optimization,
to identify RF coverage holes, hand over regions and pilot coverage areas
...................................................................................................................................................................................................................................
Drive testing Drive test optimization process
• Loaded cluster optimization,

to measure effects of cell breathing
• Cluster performance verification,
to prove network meets customer criteria.
...................................................................................................................................................................................................
4 Perform system verification,

to prove the entire network (all clusters) meets customer exit criteria.
Result
The network is now ready for live traffic testing which leads into commercial service.
...................................................................................................................................................................................................................................
Drive testing
Planning and preparation (site readiness)

...................................................................................................................................................................................................................................
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
• 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.
...................................................................................................................................................................................................................................
Drive testing Planning and preparation (site readiness)
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
can be post-processed. If sector problems do occur, they need to be remedied and the
tests repeated until they are successful.
Baseline existing system

The objective of baselining the existing system is to collect the RF performance
metrics of the existing UMTS system equipment. Baseline driving should be performed
prior to any RF optimization activity and involves measuring the Key Performance
Indicators. It is important to keep the drive routes and KPIs identical for performance
validation and comparison purposes.
...................................................................................................................................................................................................................................
Drive testing
Optimization planning
...................................................................................................................................................................................................................................
Introduction
The optimization planning phase ensures system and tool readiness for RF optimization
before beginning the actual drive testing.
Perform RF parameter audit

At the beginning of the RF optimization process, RF parameters must be inspected for
consistency with the UMTS parameter catalogue.
Validate initial neighbor lists

An important step in the RF optimization planning phase is neighbor list verification.
The complete neighbor lists in the UMTS network are required to compare the
neighbor relations with network design plots. Neighbor relations need to be verified for
recent updates, validity and appropriateness. The recommended strategy is to have a
minimum number of neighbor relations in the neighbor lists.
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.
The following figure shows
...................................................................................................................................................................................................................................
Drive testing Optimization planning
B
1
2 9 10 11
A 3 8
4 7
5 6 C
Drive route planning

Drive routes need to be defined for the following:
• Sector Verification
• Cluster Optimization
• System Verification.
Planning drive routes for Sector Verification
Each cell site is driven approximately around the entire cell site. The selected drive
route should maintain a distance equal to 1/2 of the cell site radius. Sector drive routes
usually do not require customer approval.
Planning drive routes for Cluster Optimization
The routes for Cluster Optimization should consist of major roads, highways and
hotspots. Total time to drive all routes in a typical cluster should be approximately 6 to
8 hours.
One control route per cluster is chosen to verify system performance. A control route is
a subset of the optimization route and should be limited to about 1 to 2 hours.
Additional border routes are chosen to verify system performance on overlapping
cluster regions. A border route is chosen by the way it crosses the cluster borders
without going into the cluster areas.
Planning drive routes for System Verification.
The System Verification drive routes are used to collect the metrics for the Exit
Criteria. The routes are a combination of the cluster control routes and routes between
the individual clusters.
...................................................................................................................................................................................................................................
Drive testing
Perform cluster optimization

...................................................................................................................................................................................................................................
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.
When to perform cluster optimization

Cluster optimization should be performed for network sections that are fully deployed.
This avoids a re-testing of already optimized clusters in case cell sites are later
integrated. All cell sites in the network (or a network section) are switched on. Each
cluster is tested under unloaded and loaded conditions. If live traffic exists, cells in the
tested clusters must be barred for all users except for the test users (optimization team).
It is recommended to finish the unloaded cluster tests for all clusters within the
network or network sections before continuing with the loaded cluster tests. After a
small set of adjacent clusters pass the exit criteria, a border exit drive must be
performed. The border exit drive is performed under loaded conditions in order to
verify and confirm the exit criteria at the borders of the clusters.
...................................................................................................................................................................................................................................
Drive testing Perform cluster optimization
Multiple cluster testing

During multiple cluster testing the optimization teams working on neighbor clusters
must coordinate activities especially regarding neighbor relations, loading conditions or
possible overshooting sites. Also, the UMTS on GSM overlay must be scanned for
scattered coverage or coverage holes.
Cluster optimization tools

The required data collection, processing and analysis tools for cluster optimization are
a phone-based data collection tool kit including CAIT3G, a UMTS terminal, WINDS
as well as the post-processing tool LDAT3G. In addition to the phone-based tool kit,
the scanner-based tool Agilent can be used during cluster optimization. The Agilent
scanner is an important tool due to its multiple pilot measurement capability, which is
especially useful for more in depth coverage analysis (e.g. pilot pollution) in
challenging RF environments (e.g. large water-bodies, bridges, un-even terrain, etc.)
3 phases of cluster optimization

Cluster optimization consists of three phases:
• Unloaded cluster optimization
• Loaded cluster optimization
• Cluster performance verification
Unloaded cluster optimization

During the first cluster optimization phase, a measurement drive is performed under
unloaded network conditions using the optimization route. Once the data from the first
phase is collected, problem spots are identified and optimized. The unloaded drive test
identifies coverage holes, handover regions and multiple pilot coverage areas. It also
spots possible overshooting sites (where interference is minimal) from areas belonging
to neighbor clusters.
The first pass might lead to correction of neighbor lists and adjustments of the
fundamental RF parameters such as transmit powers and/or antenna azimuths and
antenna tilts. The drive test information highlights fundamental flaws in the RF design
under best-case conditions.
Loaded cluster optimization

The second cluster optimization phase is performed under loaded conditions. The drive
routes for the loaded cluster optimization are exactly the same routes as those used for
the unloaded measurement drives.
...................................................................................................................................................................................................................................
Drive testing Perform cluster optimization
Loaded testing produces a rise in the noise floor, which has the effect of shrinking the
coverage area (cell breathing). This causes an increase of negative Ec/Io values,
identify potential coverage holes, results in higher BLER, results in lower mobility
throughput, and more dropped calls.
The objective is to fix the problems observed by the field teams. This involves the
fine-tuning of RF parameters such as the transmit power or handover parameters.
Antenna re-adjustments (e.g. down-tilts, azimuths, patterns/types or heights) are also
occasionally performed.
Problematic cluster
Problem areas may be re-driven after implementing changes. It is not recommended to
drive a problem area more than three times. If the problem cannot be solved after three
test drives, either a root cause analysis is performed or cluster optimization proceeds
with the next cluster. It is generally not recommended to attempt resolution of
complex, time-intensive performance issues, such as location-specific problems like
cell site equipment failures. For such problems, it is advisable to report the behavior
and proceed with the next cluster. The problem cluster can be verified at a later stage.
Cluster performance verification

In the third phase, the cluster performance is measured against the cluster exit criteria.
The exit drive’s purpose is to verify and to confirm specific exit criteria demanded by
the customer.
The final statistics from the cluster exit drive are presented to the customer for
approval. These statistics contain plots as well as data in tabular form. The approval to
exit the cluster is based on the terms of the contract. Approval with exceptions allows
the cluster to be exited under the condition that any problems will be resolved during
system wide optimization. If the cluster is not approved, loaded cluster optimization
must be continued until the troubles are resolved. A report specifying the reasons why
the exit drive did not pass the exit criteria is required.
...................................................................................................................................................................................................................................
Drive testing
Perform system verification

...................................................................................................................................................................................................................................
The final phase

System verification is the final phase of the RF Drive Test Based Optimization activity
and it focuses specifically on collecting overall performance statistics. System
verification begins after all clusters in the UMTS network have been tested. It is
performed under loaded conditions with all cells activated. System verification involves
fusion of the previously optimized clusters and once again is required to demonstrate
that Exit Criteria are met system-wide.
A comprehensive drive test

System verification is a comprehensive drive test covering the major highways and
primary roads in the defined coverage area. There is a focus on the problem areas
identified during the Cluster Optimization (system verification driving routes). The
procedures and analysis are identical to those used in Cluster Performance Verification.
Performance data will be collected and statistics will be made to characterize coverage
and performance over the entire network.
The system drive routes should not be used for optimization. System drives do not
allow changing parameters due to side effects. Optimizing a system route can result in
very good performance on the system verification driving routes but poor performance
elsewhere. System optimization is a continuation of Cluster Performance Verification.
The main difference is the larger contiguous area of coverage.
Problem areas
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.
Ready for live traffic

The final statistics from the system verification phase are presented for approval. The
same tools that were used for Cluster Optimization are used for the system verification
phase. At the end of the system-wide drive test phase, the RF Optimization procedure
is considered complete. The UMTS network is ready for live traffic testing leading into
commercial service. Once significant loading with live traffic is present on the
...................................................................................................................................................................................................................................
Drive testing Perform system verification
network, additional tuning of system parameters will be required to accommodate

uneven traffic conditions (e.g. traffic hot spots) and other dynamic effects which cannot
be modeled with simulated traffic loading.
It is possible for problem areas to remain after system verification is complete. An
example would be a coverage hole that will be fixed by a future cell site addition.
Such items must be well documented with alternative solutions proposed.
...................................................................................................................................................................................................................................
Part III: Optimization and
troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 6, UTRAN key performance indicators 6-1

Chapter 7, Call availability optimization and troubleshooting 7-1
Chapter 8, Call reliability optimization and troubleshooting 8-1
Chapter 9, Call quality optimization and troubleshooting 9-1
Chapter 10, Call mobility optimization and troubleshooting 10-1
Chapter 11, Throughput optimization and troubleshooting 11-1
...................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary III-1
6 6 TRAN key performance
U
indicators
Overview
...................................................................................................................................................................................................................................
Purpose
This chapter gives an overview over the use of key performance indicators (KPIs)
within the UTRAN cluster.
Contents
Performance Counters and Key Performance Indicators 6-2

KPI example - CS IRAT HO success rate (UMTS -> GSM) 6-6
CS IRAT HO success rate (UMTS -> GSM) 6-7
Performance counter trigger event basis 6-8
Parameter trigger event basis 6-10
Parameter setting 6-12
Parameter discussion 6-13
...................................................................................................................................................................................................................................
UTRAN key performance indicators
Performance Counters and Key Performance Indicators

...................................................................................................................................................................................................................................
What are Performance Counters?

The Performance Counters are metrics that may be used to assess the performance of
process steps within a UMTS network. The 3GPP standards define four types of
measurement counters:
• Cumulative counter pegging
• Discrete event notification
• Gauge (dynamic variable)
• Status inspection counter pegging.
Performance Management
Performance Management (PM) is used to schedule the collection and transfer of
performance data. The data collected is used to verify the following
• Grade and quality of service
• RF planning & optimization
• Network load
• For example, call processing flow.
Performance Measurement scheduling

The measurement schedule specifies the time frames during which the measurement
job will be active. The amount of data that is collected by a network element is
determined by the settings of:
• The data aggregation interval
• The reporting period
• The recording interval
• The measurement schedule
The diagram shows the relation between these values:
...................................................................................................................................................................................................................................
UTRAN key performance indicators Performance Counters and Key Performance Indicators
12:00 Recording Interval 14:00
Reporting Period Results

transferred
Full Hour
Time
Results
computed
Aggregation
Interval
Measurement
collection start Measurement
collection stop
Create or Resume
measurement Job
Available PM counters
In UMTS PM counters are available on logical network element level, for example:
• RNC, NodeB, SGSN, GGSN, HLR, ATM, { and/or
• RACH/PACH/PCH/DCH, LAC/RAC, Iur, {
For detailed information refer to the relevant chapters in the Performance
Measurements Definitions Manual, UMTS-5.1/IMS 7.0, 401-382-803R5.1.
What are Key Performance Indicators?

The Key Performance Indicators are metrics that may be used to assess the
performance of a UMTS network. Such assessments may be used as a general health
check on a network, or in a warranty situations where it is important to ascertain
whether the deployed network is achieving a level of performance consistent with the
customer design requirements.
The Key Performance Indicators are clear, simple, unambiguous and measurable
metrics on which the vendor can commit with the customer during the contracts
definition and can be asked to demonstrate their validity on live networks.
PM counters and KPIs are powerful measure to evaluate the performance of wireless
networks.
Available Key Performance Indicators

Key Performance Indicators are available within the UTRAN in following areas:
• Accessibility performance indicators
• Reliability (call drop) performance indicators
...................................................................................................................................................................................................................................
• Quality performance indicators

• Throughput and rate performance indicators:
– PS data throughput (RLC SDU layer) performance indicators
– PS data throughput (Iu Interface) performance indicators
– AMR performance indicators
– Traffic performance indicators
– Blocking / congestion performance indicators
– UE state transition / data rate modification performance indicators
– CS Voice rate performance indicators
• Connection establishment performance indicators:
– Cell and URA update performance indicators
– RRC connection establish performance indicators
– RRC connection re-establish performance indicators
– RRC connection drop performance indicators
– RAB establishment success performance indicators
– RAB mean (average active) performance indicators
– RAB modification performance indicators
– Radio bearer setup, radio bearer and transport channel reconfiguration
performance indicators
• Handover performance indicators:
– Soft/Softer handover performance indicators
– Radio link management performance indicators
– Radio link configuration performance management
– CS GSM to UMTS handover performance indicators
– CS UMTS to GSM handover performance indicators
– PS Inter-RAT handover performance indicators
– Inter system directed retry performance indicators
– Inter frequency hard handover performance indicators
– Intra frequency hard handover performance indicators
– SRNS relocation performance indicators
• HSDPA and E-DCH related performance indicators:
– Compressed mode performance indicators
– HS-DSCH / E-DCH cell change performance indicators
– HSDPA resource performance indicators
– DCH/HSDSCH/E-DCH and data rate reconfiguration performance indicators
• SCCP performance indicators
...................................................................................................................................................................................................................................
• Common control channel / load performance indicators

• Location services performance indicators.
For detailed information refer to the relevant chapters in the Performance
Measurements Definitions Manual, UMTS-5.1/IMS 7.0, 401-382-803R5.1.
Difference between Drive Test data and KPI data

PM counters and KPIs reflect the network viewpoint, whereas Drive Test data reflect
the subscriber’s viewpoint.
...................................................................................................................................................................................................................................
KPI example - CS IRAT HO success rate (UMTS -> GSM)

...................................................................................................................................................................................................................................
KPI definition
This Key Performance Indicator provides the number of successful outgoing circuit
switched Inter-RAT handovers based on the strongest cell of the Active link versus the
number of attempted relocation preparations for outgoing circuit switched Inter-RAT
handovers per cell from the UE’s point of view.
The Performance Measurements Definitions Manual, UMTS-5.1/IMS 7.0,
401-382-803R5.1 files this KPI as follows:
1. Main group:
UTRAN key performance indicator
2. Subgroup:
CS UMTS to GSM handover performance indicator
3. KPI:
CS IRAT HO success rate (UMTS -> GSM).
...................................................................................................................................................................................................................................
CS IRAT HO success rate (UMTS -> GSM)

...................................................................................................................................................................................................................................
Description
This KPI indicates the overall hard handover inter RAT performance towards GSM
network for CS calls starting from the relocation attempt.
Relocation attempts are triggered by transmission of a RANAP message
RELOCATION REQUIRED from the SRNC to the MSC, indicating an attempted
relocation preparation of a UMTS to GSM handover.
Note: Normally released calls during IRAT should not be considered for this success
ratio. They are subtracted from the attempts.
Formula
The formula to calculate the CS IRAT HO success rate (UMTS -> GSM):
IRATHO.SuccOutCS
= x 100
IRATHO.AttRelocPrepOutCS - IRATHO.FailRelocPrepOutCS.RelocCanc
Related performance measurements

The related performance measurements are:
• IRATHO.AttRelocPrepOutCS
• IRATHO.SuccOutCS
• IRATHO.FailRelocPrepOutCS.RelocCanc
Reporting range
The performance indicator report can be generated per:
• Cell (SRNC)
• PRNC(DRNC)
Class
This is a class 1 KPI.
...................................................................................................................................................................................................................................
Performance counter trigger event basis

...................................................................................................................................................................................................................................
Performance counter trigger conditions

The following trigger conditions apply for the performance counters of this KPI:
• IRATHO.AttRelocPrepOutCS
The counter is incremented on transmission of a RANAP message RELOCATION
REQUIRED from the SRNC to the MSC, indicating an attempted relocation
preparation of a UMTS to GSM handover.
• IRATHO.SuccOutCS
The counter is incremented on receipt of a RANAP message IU RELEASE
COMMAND sent from the CS CN to the serving RNC, indicating a successful
inter-RAT handover with cause IE set to “Successful Relocation (11)” or “Normal
Release (83)”.
The counter is incremented on receipt of a RANAP message RELOCATION
PREPARATION FAILURE containing the cause, “Relocation Cancelled (10)”, sent
from the MSC to the SRNC indicating a failed relocation preparation for UMTS to
GSM.
In case the best cell is on the SRNC, the cell MO representing the best cell is
incremented. In case the best cell is on the DRNC, the PRNC MO representing the
best cell is incremented.
Note: Normally released calls during IRAT should not be considered for this success
ratio. They are subtracted from the attempts.
Flow diagram
The following flow chart shows the sequence of events for CS (Circuit Switched)
inter-RAT UMTS to GSM handover.
The performance counters IRATHO.AttRelocPrepOutCS, IRATHO.AttRelocPrepOutCS-
.RelocCancand IRATHO.SuccOutCS are used in the KPI formula.
...................................................................................................................................................................................................................................
UTRAN key performance indicators Performance counter trigger event basis
Ongoing CS Voice Call- Additional failures causing inc. of:

Inter-RAT UMTS to GSM HO has IRATHO.FailRelocPrepOutCS.sum
been triggered - Receive a RANAP Relocation Command
containing RABs to be deleted
- Receive a RANAP Relocation Command
which does not contain L3 information
RNC sends RANAP “Relocation - Lost communication with the UE due to
Required” to the MSC all Radio Links failing.
Inc: IRATHO.AttRelocPrepOutCS
Relocation
Relocation N
N Preparation TRELOCprep N
Command
Failure expired?
received?
received?
Y Y Y
RNC sends RRC “Handover from Inc: IRATHO.FailRelocPrepOutCS.sum The RNC initiates the RANAP
UTRAN Command” to the UE and depending on the cause received from Relocation Cancel procedure. The
Increment: MSC Increment the following subcounters call is continued in UMTS.
IRATHO.AttOutCS of: IRATHO.FailRelocPrepOutCS: Increment following sub counters of:
Increment: .FailTarSys .ReqCiphNotSupp .OmInt IRATHO.FailRelocPrepOutCS:
NumUMTS-GSM_HOPerNCell.Att .NotSupTarSys .RelocCanc .UnspecFail .sum
If trigger was based on RSCP: .TarNotAllowed . NoResAv .NoRRTarCell .T_RELOCprep_exp
Increment: .NoRRTarSys .AbstSyntErr
IRATHO.AttOutCS.RSCP .TrLdHighTarCell .NotSupTarSys
END
Retry with Y
another GSM
target cell?
N
The call is continued in UMTS
END
Iu Release N Handover from N

Command
N TRELOCOverall
UTRAN Failure expired?
received? received?
Y Y Y
RNC releases resources and The call is continued in UMTS RNC issues an Iu Release Request
sends Iu Release Complete Inc: NumUMTS-GSM_HOPerNCell.Fail to the MSC.
If cause is set to Inc: IRATHO.FailOutCS.sum Inc: IRATHO.TRelocOverall
'Successful Relocation' or Depending on the cause received from the
'Normal Release': UE increment either:
Inc: IRATHO.SuccOutCS IRATHO.FailOutCS.PhyChnFail
If trigger was based on RSCP: IRATHO.FailOutCS.ConfUnaccept END
Inc: IRATHO.SuccOutCS.RSCP IRATHO.FailOutCS.ProtErr
END END
...................................................................................................................................................................................................................................
Parameter trigger event basis

...................................................................................................................................................................................................................................
Parameter trigger conditions

The most relevant parameters and their setting for this process are:
• Measurement quantity for Inter-RAT HO trigger condition:
The parameter measurementQuantityInterRATHHO is used for inter-RAT hard
handover from UTRAN to GSM. It determines the quantity to be used for
measurements of the UMTS.
• Compressed Mode Activation:
The parameter umts2GsmQActCM2D defines the measurement criteria for activation
of compressed mode for UMTS to GSM HO with following sub-parameters:
– .rSCPThreshold and .eCN0Threshold specify a value for the quality of the
own system (UMTS frequency) for triggering event 2D (actual quality drops
below specified threshold). This event is used to start inter-RAT measurements
for a UE that requires compressed mode.
– .timeToTrigger specifies the time for which the triggering condition must be
true before the UE sends an event triggered measurement report to the UTRAN.
• Compressed Mode Deactivation:
The parameter umts2GsmQDeactCM2Fdefines the measurement criteria for activation
of compressed mode for UMTS to GSM HO with following sub-parameters:
– .rSCPThreshold and .eCN0Threshold specifiy a value for the quality of the
own system (UMTS frequency) for triggering event 2F (actual quality rises
above specified threshold). This event is used to stop Inter-RAT measurements
for a UE that requires compressed mode.
• MAHO Trigger Condition:
The parameter umts2GsmQTriggerMAHO defines the measurement criteria to trigger
UMTS to GSM HO (MAHO) with following sub-parameters:
– .rSCPThreshold and .eCN0Threshold specifiy a value for the quality of the
own system (UMTS frequency) for triggering inter-RAT MAHO in case of
Service Handover set to ″should not″ (actual quality drops below specified
threshold).
– .weight specifies weighting between strongest link and remaining active links
for computing the quality of the own system (UMTS system).
...................................................................................................................................................................................................................................
UTRAN key performance indicators Parameter trigger event basis
IRAT handover events 2D and 3C

The following graphic shows the Inter-RAT handover events 2D and 3C for the UMTS
to GSM handover service “should”.
DT DT
Measurement
Quantity CPICH (UTRAN)
Event 2D threshold umts2GsmQActCM2D

used system below
IRATHO.AttRelocPrepOutCS
umts2GsmQTriggerMAHO
Event 3C threshold IRATHO.SuccOutCS
GSM above
RSSI (GSM)
Time
UTRAN Cell Event 2D Event 3C

Start compressed
Connected Relocate to GSM
mode measurements
Before the CPICH of the UMTS system declines under the event 2D the UE will not
even know the GSM cell is there. When the signal of the CPICH is below the
threshold, the compressed mode measurements will start. From the 3C event on, the
RSSI of the GSM system is above the threshold, that is, the GSM cell is strong
enough. Since the UE „should“ handover it will send a report 3C to relocate to GSM.
The performance counters IRATHO.AttRelocPrepOutCS and IRATHO.SuccOutCS are
incremented accordingly.
...................................................................................................................................................................................................................................
Parameter setting
...................................................................................................................................................................................................................................
Parameters and initial value settings

The actions for the Inter-RAT handover considered depend on values of parameters
which trigger the Mobile Assisted Handover Process (MAHO) from UMTS to GSM.
The most relevant parameters and their setting for this process are:
• Measurement quantity for Inter-RAT HO trigger condition:
Parameter: measurementQuantityInterRATHHO: RSCP_ECN0
• Compressed Mode Activation:
Parameter: umts2GsmQActCM2D
– .rSCPThreshold: -111 dBm
– .eCN0Threshold: -16 dB
– .timeToTrigger: 320 ms
• Compressed Mode Deactivation:
Parameter: umts2GsmQDeactCM2F
– .eCN0Threshold: -13 dB
• MAHO Trigger Condition:
Parameter: umts2GsmQTriggerMAHO
– .eCN0Threshold: -13.0 dB
– .weight: 1.0
...................................................................................................................................................................................................................................
Parameter discussion
...................................................................................................................................................................................................................................
Purpose
The following tables display and discuss the parameter settings that are relevant for the
Inter-RAT Handover of a Circuit Switched call from UMTS to GSM.
measurementQuantityInterRATHHO
The following table displays the settings for the parameter “Measurement quantity for
Inter-RAT HO trigger condition”:
Subparameters Recommendation Explanation

RSCP Boundary cells When going away from the center of the UMTS
cell, the RSCP level may lower, whereas the
Ec/No may stay constant. In this situation, Ec/No
measurements will not be a suitable basis for
Inter-RAT trigger conditions.
ECN0 Central cells When going towards the center of the UMTS
cell, the RSCP level may stay constant, whereas
the noise level may change significantly. In this
situation, RSCP measurements will not be a
suitable basis for Inter-RAT trigger conditions.
RSCP_ECN0 Default setting In most cases, the measurements of both, RSCP
and Ec/No measurements will be a suitable basis
for Inter-RAT trigger conditions.
umts2GsmQTriggerMAHO
The following table displays the settings for the parameter “MAHO Trigger
Condition”:
Subparameters Too low values Too high values

rSCPThreshold/ Handover is triggered too late. Handover is triggered too early.
eCN0Threshold Call quality may get unacceptably bad. A handover to GSM is performed
Call may drop. although the quality of the UMTS
signal is sufficient, i.e. the UE is still
The value should be chosen higher
inside the UMTS area.
than required for minimal call quality
of a static call. This is necessary to
regard for the time that is required to
execute the handover to GSM and the
movement of the UE.
...................................................................................................................................................................................................................................
UTRAN key performance indicators Parameter discussion

timeToTrigger Handover is triggered too early. Handover is triggered too late.
Measurement report is sent even if the Call will drop
trigger condition is only fulfilled for a In case of bad quality the UE has to
very short time. Such fast time fading wait for the time to trigger before
may be caused for example by sending the measurement report. This
interference and should not cause a time in conjunction with the time for
handover to GSM. the execution of the handover to GSM,
the UE may have already moved out
of coverage of the UMTS area and is
not able to receive the handover
command from the UMTS network.
weight Quality of the strongest cell has higher Quality of the strongest cell has less
influence than the estimated quality of influence than the estimated quality of
the active set. the active set.
weight: 0 means that the strongest weight: 1 means that all cells of the
cell of the Active Set is taken into Active Set are taken account with the
account, only. same preference.
weight: <1 means that the quality of weight: >1 means that the quality of
the strongest cell is taken into account the strongest cell is taken into account
with higher preference than the other with lower preference than the other
cells of the Active Set. cells of the Active Set.
umts2GsmQActCM2D
The following table displays the settings for the parameter “Compressed Mode
Activation”:
...................................................................................................................................................................................................................................

rSCPThreshold/ Compressed mode will be activated too Compressed mode is activated earlier
eCN0Threshold late. than required.
Call may drop before IRAT PMs can CM active although quality of UMTS
be performed. signal is sufficient, IRAT HO not to be
Call may drop before HO to GSM is considered at this time.
initiated. CM has negative impact on throughput
Set value to the same or higher value and/or cell capacity and it should be
than the HO threshold avoided to activate compressed mode
(umts2GsmQTriggerMAHO.threshold). if not required,
The time of activated CM is reduced

to a minimum if both thresholds are
equal at a constant TTT. A higher
threshold for CM activation may be
required to regard for further quality
degradation during the time the UE
performs IRAT PMs.
timeToTrigger Compressed mode will be activated Compressed mode will be activated too
earlier than required. late.
Measurement report is sent even if the Call may drop due to following
trigger condition is only fulfilled for a scenario: In case of bad quality UE
very short time. has to wait for the time to trigger
Fast time fading may be caused due to before sending the PM report. Further
interference and should not trigger the time is required to activate CM,
activation of CM. perform IRAT PMs and execute the
HO to GSM. During this time the UE
may already have moved out of UMTS
coverage area, and the call drops.
umts2GsmQDeactCM2F
The following table displays the settings for the parameter “Compressed Mode
Deactivation”:
...................................................................................................................................................................................................................................

rSCPThreshold/ Frequent toggling of the compressed Compressed mode is kept activated
eCN0Threshold mode very long.
Compressed mode is deactivated after CM active although quality of UMTS
a previous activation if the UMTS signal is sufficient, IRAT HO not to be
quality raises only by a small amount. considered at this time.
High signalling load CM has negative impact on throughput
Negative effect on the call quality. and/or cell capacity and it should be
avoided to keep CM activated if not
required.
timeToTrigger Compressed mode will be deactivated Compressed mode will be deactivated
earlier than required. too late.
Measurement report is sent even if the
trigger condition is only fulfilled for a
very short time.
Fast time fading may be caused due to
interference and should not trigger the
deactivation of CM.
...................................................................................................................................................................................................................................
7 7 all availability optimization
C
and troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This chapter describes the UTRAN measurements and performance indicators that can
be used to localize problems and to optimize issues related to setting up mobile
originating and mobile terminating calls.
Contents
Call availability 7-3

Determination of accessibility problem 7-6
Accessibility 7-7
Access preliminary procedures 7-8
Cell re-selection failures 7-9
RACH access procedure failures 7-11
RRC connection establishment analysis 7-15
Introduction to RRC connection establishment 7-16
Call admission control failures 7-19
Radio link setup analysis 7-21
RRC connection setup failure 7-23
Paging failures 7-24
RAB establishment analysis 7-26
RAB establishment 7-27
Dynamic bearer control failures 7-30
Radio bearer establishment failures 7-32
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Overview
No answer from UE 7-33
....................................................................................................................................................................................................................................
Call availability optimization and troubleshooting
Call availability
Overview
...................................................................................................................................................................................................................................
Purpose
This section describes the performance indicators that can be used to retrieve
information about the overall network accessibility.
Contents

Determination of accessibility problem 7-6
...................................................................................................................................................................................................................................
Call availability
...................................................................................................................................................................................................................................
Introduction
Call availability defines the availability of the UMTS network to allow a call to be set
up successfully.
In the call setup process, the UE makes the transition from Idle mode to Cell DCH
state via establishing the RRC connection and establishes the call via establishing the
RAB.
Call setup process

The call setup process in UTRAN consists of RRC connection establishment and RAB
establishment. With the RRC connection establishment procedure, the UE executes the
transition from Idle mode to CELL_DCH state and establishes the signalling
connection to communicate with the CN.
With the RAB establishment procedure, the CN requests the UTRAN to establish the
RAB associated with the call. This involves reconfiguring the radio link(s) to include
the radio link configuration and setting up the transport bearer for the new RAB. The
UTRAN also informs the UE about the configuration of the new RAB.
The call is successfully set-up only if both procedures are successfully completed
Related transition states

In order to allow the user to originate or receive a call, the UE has to perform:
• Cell (re)-selection and random access procedure
• UE registration with CN
• Reception of paging if receiving a call.
Call setup failures

Call setup failures can occur during UE registration stage with the CN. These failures
are still impacting the call availability, as the UE needs to register with the CN before
making a call. However, this is out of the scope of this section.
Network level access phase

During the network level access phase, the UE has to successfully perform the cell
(re)-selection process as well as to gain network access using the random access
procedure.
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Call availability
RRC connection establishment phase

During the RRC connection establishment phase, the UE executes the transition from
Idle mode to Cell_DCH state and establishes the signalling connection to communicate
with the CN. This involves setting up the radio link(s) to include the radio link
configuration and setting up the transport bearer for the signaling radio bearer. The
UTRAN also informs the UE about the configuration of the signaling radio bearer.
RAB establishment phase

During the RAB establishment phase, the CN requests the UTRAN to establish the
RAB associated with the call. This involves reconfiguring the radio link(s) to include
the radio link configuration and setting up the transport bearer for the new RAB. The
UTRAN also informs the UE about the configuration of the new RAB.
....................................................................................................................................................................................................................................
Determination of accessibility problem

...................................................................................................................................................................................................................................
Introduction
In order to quickly determine whether there are severe problems in the UMTS network
it is possible to analyze the general UMTS mobile subscriber satisfaction level, from a
network point of view, with respect to the network accessibility.
Related PMs / KPIs

The related PMs / KPIs are:
• CS Data call success rate
• CS Speech call success rate
• PS call success rate
• E-DCH call success rate
• HSDPA call success rate
• DCH call success rate
Each of the KPIs above is derived from multiplying the service type specific RAB
establishment success rate, the successful RRC connection establishment rate and the
relevant Standalone Radio Bearer drop rate.
Abnormal accessibility rate values

When one of the accessibility rate values is very low, the reason can be caused by
many different issues. Therefore it is advised to localize the issue by analyzing the
performance measurements and KPIs separated over the accessibility call phases:
• Network level access phase
• RRC connection establishment phase
• Signaling Radio Bearer (SRB) drop
• RAB establishment phase.
...................................................................................................................................................................................................................................
Accessibility
Overview
...................................................................................................................................................................................................................................
Purpose
This section describes which performance measurements and performance indicators
can be used to analyze the network performance during the access phase.
Note: This procedure is often also referred to as the preliminary procedure, which
should be performed before the UE can gain network access.
Contents
Access preliminary procedures 7-8

Cell re-selection failures 7-9
RACH access procedure failures 7-11
...................................................................................................................................................................................................................................
Access preliminary procedures

...................................................................................................................................................................................................................................
Preliminary procedures failures

In general any call-related procedure initiated via RRC messages sent by the UE to the
UTRAN is preceded by two preliminary procedures such as cell selection/re-selection
and random access.
Successful completion of both procedures is a basic prerequisite to succeed in any call
setup procedure.
Not visible for performance management

Both the cell selection/re-selection and random access procedures are not visible to the
network before successful receipt of RRC messages relevant for specific call
procedure. Therefore failures occurring during both procedures will not affect the value
of any RRC connection performance indicators. As cell selection is executed in the UE
without any signaling to the network it is not possible to see any impact on
Performance Measurements (PM). However if the thresholds for quality and level for
the cell selection criterion are chosen too high then the UE may not be able to (re-)
select a cell in large parts of the coverage area. From the system performance this
issue may become apparent in decreased network traffic.
...................................................................................................................................................................................................................................
Cell re-selection failures

...................................................................................................................................................................................................................................
Overview
As cell reselection is a pure UE procedure there are no PMs directly related to this
feature. The reselection behavior of the mobile can only be investigated using a test
mobile system. However the reselection behavior of the mobile indirectly influences
the network quality. Wrong cell reselection may lead to RACH accesses on cells not
offering the best radio conditions for this UE.
PMs / KPIs indications

When the UE is in Idle mode, in a cell, it should continuously perform the cell
re-selection process. If the hysteresis for cell re-selection is set too large the UE will
possibly access a cell which is not the optimal choice in terms of interference. On the
other hand, if the hysteresis for cell re-selection is set too small, the effect of
ping-pong re-selections is more likely.
In order to determine whether ping-ponging is occurring during the cell updates
re-selection process, the number of cell update messages that are received from the UE
that are in the Cell FACH state may provide an indication. The measurement counter
VS.MM.CellUpdateReq.CellReselect provides the number of requested cell updates with
cause “Cell Reselection” received by the RNC from the UE. If the hysteresis is set too
low, this PM counter value will be abnormally large compared to a properly set cell
with similar traffic. The success of RRC Connection Establishment may be affected if
ping pong reselection is occurring during cell re-selection.
Additionally there could be related issues due to potential coverage problems which
could be monitored by the measurement VS.MM.RRCConnDrop.CellResel_CellUp. This
counter measures the number of times there has been no response from the UE when a
“UTRAN Mobility Confirm” message is sent from the RNC during a cell reselection
procedure.
If the reselection procedure frequently triggers the reselection of a new cell this will
also increase the number of LA/ RA/ URA updates at the borders of UMTS mobility
areas. Therefore, an increase of Location Area/ Routing Area/URA updates will be
visible if the UE exhibit a more frequent cell reselection. The counters,
VS.MM.UraUpdateReq.UraChange and VS.MM.UraUpdateReq.PeriodUpdate give the
number of URA updates performed in this cell, separated by cause. Other counters for
location updates are available from the core network, such as,
VS.SS7LocUpdateAttSucc (3G-MSC measurements) and from the 3G-SGSN application
measurements, such as, MM.AttInterSgsnRaUpdate.U and MM.AttIntraSgsnRaUp-
date.U.
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Cell re-selection failures
Related PMs / KPIs

The related PMs are:
• VS.MM.CellUpdateReq.CellReselect
• VS.MM.RRCConnDrop.CellResel_CellUp
• VS.MM.RRCConnDrop.Period_UraUpdate
• VS.MM.UraUpdateReq.UraChange
• VS.MM.UraUpdateReq.PeriodUpdate
• VS.SS7LocUpdateAttSucc
• MM.AttInterSgsnRaUpdate.U
• MM.AttIntraSgsnRaUpdate.U
The related KPIs are:
• Cell update request rate due to cell reselection
....................................................................................................................................................................................................................................
RACH access procedure failures

...................................................................................................................................................................................................................................
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 separated 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 ACK on the AICH the UE transmits the RACH message part
with an embedded RRCconnection request message.
UE Node B RNC
Uu Iub
RACH Preamble
RACH Preamble
RACH Preamble
Access indication
(AICH)
RACH message VS.RACHTransBlock.Bad

RRC RRC
(RRC Connection Request) VS.RACHTransBlock.Good
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting RACH access procedure failures
Timer settings
Guard timer T300 (determined by UTRAN parameter t300) and N300 (determined by
UTRAN parameter n300) is supervising 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
retransmitted too early or too late and thus affecting the procedures that initiated the
RACH access (for example Call setup).
If the RACH Preamble is acknowledged at a very low Eb/N0 and parameter
powerOffsetPpm is set relatively small, this will increase the probability that the RACH
Message Part would be sent at a power that is too low to be decoded correctly (bad
CRC) by the NodeB. If powerOffsetPpm is set above the recommended value, the
success rate of RACH will improve (the rate of RACH Message Part received with
good CRC increases). However, this increase of the power of the RACH Message Part
will cause additional uplink interference to the system.
Possible failing reasons

Possible reasons why the RACH access procedure could fail are:
• The Node B does not successfully decode any of the RACH preambles
• The UE does not receive an ACK on the AICH (Acquisition Indicator Channel)
• The UE is receiving a NACK on the AICH
• The Node B does not successfully decode the RACH message part
• Unsuccessful retransmission of the RACH message part.
There could also be reasons of large cell/sector size and UEs with lower power than
the designed value (UE power class) which could cause unsuccessful decoding or
acknowledgement of RACH preambles and messages.

RRC.AttConnEstab.sum 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 RRC.AttConnEstab.sum are indicative of problems. Nevertheless this counter
cannot prove that there are actually problems because, for example, NACKs sent by
Node B on AICH are not counted. It may be that at a particular cell low traffic is
resulting in low values of counter RRC.AttConnEstab.sum.
However the KPI - Successful RRC connection establishment rate (including repeated
attempts) calculates the RRC Connection establishments with repeated attempts which
can be used to assess the Access issue from the network perspective. Low values show
that the access process may need to be optimized and there could be RACH access
failures. It must be noted that though this KPI is low, it does not mean that the
....................................................................................................................................................................................................................................
subscriber faces an issue in access since there would be several retries of the RRC
attempt before it is a failed RRC connection attempt which requires the subscriber to
try again. The number of retries is set by the parameter n300 in the OMC.
The PM counters VS.RACHTransBlock.Bad and VS.RACHTransBlock.Good 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.
The KPI - RACH transport block good CRC rate can be used to obtain the percentage
of Transport Blocks with good CRC and low values are indicative of issues of reduced
power of the RACH message part (causing bad CRC) and may be related to settings of
powerOffsetPpm.
The PM counter VS.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.
The PM counter VS.RACHcongestion provides the percentage of time the RACH is in
congested state. This helps to determine the overload status for the RACH and is
useful for field diagnostics.
The following PM counters maybe used to study failures in the Access procedure:
• RRC.FailConnEstab.SetupIncomplete
Number of RRC connection attempt failures, when RNC does not receive the
“RRC Connection Setup Complete” message from the UE. Includes failures for
repeated RRC connection attempts from the same UE.
• RRC.FailConnEstab.sum
This measurement provides the total number of failed RRC connection
establishments. Includes rejects for repeated RRC connection attempts from the
same UE
• RRC.FailConnEstab.CAC
This counter is incremented whenever the RNC sends an “RRC Connection Reject”
message with cause “Congestion”. Congestion will occur due to Call Admission
Control (CAC).
• RRC.FailConnEstab.RLSetupFailure
This counter is incremented whenever the RNC sends an “RRC Connection Reject”
message with cause “unspecified” for the case where the SRNC receives a “Radio
Link Setup Failure” message.
Related PMs / KPIs

• VS.RACHTransBlock.Bad
• VS.RACHTransBlock.Good
....................................................................................................................................................................................................................................
• VS.ChannelOccupRateRACH
• VS.RACHcongestion
• RACH transport block good CRC rate
• RRC.FailConnEstab.sum:
....................................................................................................................................................................................................................................
RRC connection establishment analysis
Overview
...................................................................................................................................................................................................................................
Purpose
This section describes the performance measurements and performance indicators can
be used to localize problems and to optimize issues related to the RRC connection
establishment.
Contents
Introduction to RRC connection establishment 7-16

Call admission control failures 7-19
Radio link setup analysis 7-21
RRC connection setup failure 7-23
Paging failures 7-24
...................................................................................................................................................................................................................................
Introduction to RRC connection establishment

...................................................................................................................................................................................................................................
RRC Connection establishment procedure

In general the RRC connection establishment procedure may occur in different
scenarios such as:
• Network attach
• Location and Routing Area Update
• MO/MT call setup.
RRC connection establishment starts with the successful receipt at the RNC of the
RRC connection request message. This means that cell selection/re-selection as well as
random access procedures have been successfully completed.
Call setup stages

In case of a mobile originated call setup, the RRC Connection Establishment procedure
may be categorized into the following basic stages:
1. Call Admission Control (CAC) at the RNC
2. Node B Application Part (NBAP) Radio Link Setup (including transport bearer and
synchronization
3. RRC connection setup.
Note: For a mobile terminating call the paging procedure precedes the random access
procedure.
An example of a mobile originated call flow:
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Introduction to RRC connection establishment
UE Node B RNC
Uu Iub
RRC Connection Request

RRC RRC
(RACH)
CAC 1 RRC.FailConnEstab.CAC
RL Setup Request
NBAP NBAP
2 RRC.FailConnEstab.RLSetupFailure
RL Setup Response
NBAP NBAP
ALCAP Iub transport bearer
DCH-FP: UL/DL synchronization
RRC Connection Setup

RRC RRC
(CCCH over FACH)
3 RRC.FailConnEstab.SetupIncomplete
RRC Connection Setup Complete
RRC RRC
(DCCH over DCH)
Connection establishment failures

The RRC Connection Establishment Failures may occur due to following reasons:
• Call admission control failures
• Radio link setup failures
• RRC connection setup failures
• Paging failures
• Soft/softer handover failures at call setup
• RNC Processor Overload.
• Iub congestion
Most of these failure causes are normally associated with poor RF conditions and can
be seen from measurements RRC.FailConnEstab.SetupIncomplete and
RRC.FailConnEstab.RLSetupFailure. Congestion in the NodeB/RNC can cause RRC
Connection failures and will be seen from the measurement RRC.FailConnEstab.CAC.
Overload of the RNC processor can cause discards of RRC Connection requests which
can consequently affect the Successful RRC Connection Establishment rate (included
....................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Introduction to RRC connection establishment
repeated attempts). This can be observed by monitoring RRC.FailConnEstab.Processor-

Load. It must be noted that this also includes RRC Connection attempt retries, hence
the KPI - RRC establishment success rate (UE perspective) should also be used to
study the effect of RRC failures from the subscriber experience point of view.
Low values of the KPI, successful RRC connections establishment rate, may also be
due to RRC connections failures occurring during other procedures such as network
attach or SMS and location update.
There are individual measurements for each type of RRC connection attempt (for
example, RRC.AttConnEstab.OrigConvCall, RRC.AttConnEstab.Registration) and their
corresponding success measurements (for example, RRC.SuccConnEstab.OrigConvCall,
RRC.SuccConnEstab.Registration). These can provide the success rates for each RRC
Connection procedure which may help in isolating issues in specific procedures.
Related PMs / KPIs

• Successful RRC connections establishment rate (including repeated attempts)
• RRC establishment success rate (UE perspective)
• RRC.FailConnEstab.ProcessorLoad
• RRC.FailConnEstab.CongOrigConvCall
• RRC.FailConnEstab.CongTermConvCall
• RRC.FailConnEstab.CongOrigStrmCall
• RRC.FailConnEstab.CongTermStrmCall
• RRC.FailConnEstab.CongOrigIntactCall
• RRC.FailConnEstab.CongTermIntactCall
• RRC.FailConnEstab.CongOrigBgrdCall
• RRC.FailConnEstab.CongTermBgrdCall
• RRC.FailConnEstab.CongOrigHighPrioSig
....................................................................................................................................................................................................................................
Call admission control failures

...................................................................................................................................................................................................................................
Introduction
Call Admission Control (CAC) is used to prevent overload of the system. Load
conditions for the downlink are based on the total transmit power of the cell. The
uplink load measure is the measured RSSI value relative to the typical noise floor that
was estimated using long term measurements.
If the defined load thresholds for CAC are exceeded the RRC connection establishment
request is denied and a RRC Connection Reject message with cause, “Congestion” is
sent by the RNC to the UE.
Abnormal value
The triggering of CAC can be partly monitored using the PM counter,
RRC.FailConnEstab.CAC that is triggered in case of CAC. If the values of this counter
indicate that overload situations have occurred over long periods of time, CAC should
be the reason for the experienced call setup problems.
The KPI, Failed RRC connection establishment rate - congestion (conv Call) can be
used to find issues related to conversation calls. The KPI, Failed PS RRC connection
establishment rate - Congestion will help identify cells where the RRC Connections
have failed to establish for Packet calls due to congestion.
Load measurements
Other counters related to system load such as VS.RF.ForwrdTrafficChn.Overload,
which provides the percentage of time the carrier was in power control overload,
VS.RF.ChanElementUsage.Total, and related counts that provide the percentage of
Channel Element usage in the NodeB, Transmitted Carrier Power - VS.RF.TxP-
wr.AllCodes.Max, VS.RF.TxPwrMean.AllCodes, Received total wideband power -
VS.RF.RTWP.Max, VS.RF.RTWP.Mean and Channel Code Utilization which provides
the percentage of Code utilization. All of these may be used to verify whether the load
in the cell is fairly high, which would increase the probability for call setup failures.
Related PMs / KPIs

• VS.RF.ForwrdTrafficChn.Overload
• VS.RF.ChanElementUsage.Total
• VS.ChanCodeUtil
• VS.RF.ChanElementUsage.Dedicated
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Call admission control failures
• VS.RF.ChanElementUsage.DCH.Mean
• VS.RF.ChanElementUsage.DCH.Max
• VS.RF.ChanElementUsage.EDCH.Mean
• VS.RF.ChanElementUsage.EDCH.Max
• VS.RF.ChanElementUsage.HSDPA.Mean
• VS.RF.ChanElementUsage.HSDPA.Max
• VS.FP.UL.CongTime
• VS.RF.TxPwr.AllCodes.Max
• VS.RF.TxPwrMean.AllCodes
• VS.RF.RTWP.Max
• VS.RF.RTWP.Mean
• RRC.FailConnEstab.CongOrigConvCall
• RRC.FailConnEstab.CongTermConvCall
• RRC.FailConnEstab.CongOrigStrmCall
• RRC.FailConnEstab.CongTermStrmCall
• RRC.FailConnEstab.CongOrigIntactCall
• RRC.FailConnEstab.CongTermIntactCall
• RRC.FailConnEstab.CongOrigBgrdCall
• RRC.FailConnEstab.CongTermBgrdCall
• RRC.FailConnEstab.CongOrigHighPrioSig
....................................................................................................................................................................................................................................
Radio link setup analysis

...................................................................................................................................................................................................................................
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 the case where the UE is in a
soft/softer handover region during call setup more than one radio link has to be set up.
Note: A radio link is associated to one cell, while a RAB is associated to one UE per
service type.
Radio link setup failure

In order to allocate the requested resources, the RNC sends the radio link setup request
message to the relevant Node B. Upon reception of radio link setup request message,
the Node B reserves the necessary resources and sends back the Radio Link Setup
Response message to the RNC. If the establishment of at least one radio link fails then
the Node B sends back the radio link setup failure message to the RNC.
Lack of NodeB Resources

The measurements RLM.FailRLSetupIub.NodeBRes.CSV, RLM.FailRLSetupIub.NodeB-
Res.PSD and RLM.FailRLSetupIub.NodeBRes.CSD record failures in Radio Link setup
procedures. High values for these counters indicate that there were RL failures due to
missing Node B resources. This indicates possible UMTS Channel Unit (UCU) outages
or resource shortages.
Specific Node B counters such as Total Channel Element Usage (VS.RF.ChanElemen-
tUsage.Total) and Dedicated Channel Element Usage (VS.RF.ChanElementUsage.Dedi-
cate) provide important information on the Node B traffic and indicate whether the
Node B capacity in terms of the availability of physical resources is close to the limit
during the time of the failures.
Lack of Transport Resources

The measurements RLM.FailRLSetupIub.TransRes.CSV, RLM.FailRLSetupIub.TransRe-
s.PSD, RLM.FailRLSetupIub.TransRes.CSD and RLM.FailRLSetupIur.TransRes record
failures in Radio Link setup procedure. High values for these counters indicate that
there are failures due to missing transport resource. This indicates that transport
resource is unavailable due to missing binding IDs for the transport bearer.
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Radio link setup analysis
The measurement, RRC.FailConnEstab.RLSetupFailure provides a count of failures due

to RL Setup failures and can be used in conjunction with the above PMs. If this
counter is high while the resource counters show zero/low numbers, then it could mean
that there are RF related issues in the area preventing call setup.
Related PMs / KPIs

• RLM.FailRLSetupIur.sum
• RLM.FailRLSetupIub.NodeBRes.CSV
• RLM.FailRLSetupIub.NodeBRes.CSD
• RLM.FailRLSetupIub.NodeBRes.PSD
• RLM.FailRLSetupIub.TransRes.CSV
• RLM.FailRLSetupIub.TransRes.CSD
• RLM.FailRLSetupIub.TransRes.PSD
• RLM.FailRLSetupIur.TransRes
• VS.RF.ChanElementUsage.Total
• VS.RF.ChanElementUsage.Dedicated
....................................................................................................................................................................................................................................
RRC connection setup failure

...................................................................................................................................................................................................................................
Introduction
Once the NBAP radio link setup procedure has been successfully completed and the
transport bearer has been established and synchronized, the UTRAN initiates the RRC
connection setup procedure to complete the RRC connection establishment.
The performance measurement RRC.FailConnEstab.SetupIncomplete is used to record
failures occurred during the RRC connection setup procedure.
Related PMs / KPIs

Abnormally high values of the above mostly point to RF related issues like
coverage/interference or parameter settings
Possible reasons for high values are:
1. Optimal settings of the UTRAN attributes uERRCConnSetup-ResponseTimer and
maxRRCConnSetupRetries are not correct
2. The RRC connection setup message is not successfully decoded due to poor FACH
coverage
3. The RNC cannot successfully decode the RRC connection setup complete message.
...................................................................................................................................................................................................................................
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.

The failure causes can be identified via the UTRAN counters VS.MM.PageAttDiscard
and VS.MM.PagAttDiscard.ProcessorLoad. PCH Traffic can be evaluated via the
counter VS.ChannelOccupRatePCH.
Note: Paging related PMs and KPIs are typically derived from the core network.
Possible failure causes

In general, the possible failure causes are Paging Channel (PCH) congestion or poor
PCH coverage.
Also issues on the transport network may impact the Paging procedure, for example:
• Transport over Iu interfaces, RANAP protocol takes care of transmitting the paging
messages
• Transport over Iub interface, the PCH is carried by the AAL2 protocol
• Transport over RACH (paging response in uplink direction)
• Transport problems over the RACH (paging response in uplink direction)
In all these cases the MT call is not successfully completed.
Processor overload in the RNC can also cause Paging messages to be discarded. RRC
Connections are dropped when the UE does not respond to Paging messages possibly
due to coverage or UE issues. This is recorded by the measurement, VS.MM.RRCConn-
Drop.UTRANPagingFailure.
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Paging failures
Related PMs / KPIs

• VS.MM.NumPageAttDiscard
• VS.MM.PagAttDiscard.ProcessorLoad
• VS.ChannelOccupRatePCH
• VS.MM.RRCConnDrop.UTRANPagingFailure.
Note: Paging related PMs and KPIs are typically derived from the core network.
....................................................................................................................................................................................................................................
RAB establishment analysis
Overview
...................................................................................................................................................................................................................................
Purpose
This section describes the performance measurements and performance indicators can
be used to localize problems and to optimize issues related to the RAB establishment.
Contents
RAB establishment 7-27

Dynamic bearer control failures 7-30
Radio bearer establishment failures 7-32
No answer from UE 7-33
...................................................................................................................................................................................................................................
RAB establishment
...................................................................................................................................................................................................................................
RAB establishment procedure

As soon as the RRC connection establishment procedure has been completed, the call
setup procedure is finalized via the RAB establishment procedure. Once the RRC
connection is established, the UE can then establish the signaling connection with the
CN via UTRAN. If a PS call is to be setup, the UE may initiate PDP Context
Activation procedure over the signaling connection to the SGSN. If a CS call is to be
setup, the UE may initiate the Call Setup procedure over the signaling connection to
the MSC. The CN will send the RAB assignment request to UTRAN to establish the
RAB associated with the call.
RAB establishment initiators

The RAB Establishment procedure is initiated by the core network via the sending of
RAB assignment request. This procedure is successfully completed upon receipt of
RANAP RAB assignment response message at the core network.
RAB establishment call flow

An example RAB establishment call flow:
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting RAB establishment
UE Node B SRNC MSC/SGSN

Uu Iub Iu-ps/cs
RRC UL Direct Transfer

(PS: PDP Context Request RANAP Direct Transfer
CS: Call Setup Request) (PS: PDP Context Request
CS: Call Setup Request)
RANAP Direct Transfer

(CS ONLY: Call Setup Request)
RRC DL Direct Transfer
(CS ONLY: Call Proceeding)
RANAP RAB assignment request
ALCAP Iu transport bearer establishment

(Only for CS domain)
DBC
NBAP Radio link RAB.FailEstabCSNoQueuing.ULIntfer

reconfiguration prepare RAB.FailEstabPSNoQueuing.ULIntfer
RAB.FailEstabCSNoQueuing.DLPwr
NBAP Radio link RAB.FailEstabPSNoQueuing.DLPwr
reconfiguration ready RAB.FailEstabCSNoQueuing.CodeStarv
RAB.FailEstabPSNoQueuing.CodeStarv
ALCAP Iub transport bearer establishment
Node B RNC data transport bearer sync
Radio link
reconfiguration commit
RAB.FailEstabCSNoQueuing.RBSetupFail
RAB.FailEstabPSNoQueuing.RBSetupFail
RRC Radio bearer setup
(DCCH over DCH) RAB.FailEstabCSNoQueuing.T3exp
RAB.FailEstabPSNoQueuing.T3exp
RRC Radio bearer setup complete
(DCCH over DCH) RANAP RAB
Assignment Response
RANAP Direct Transfer

(PS ONLY: Act PDP Context Acc)
RRC DL Direct Transfer

(PS ONLY: Act PDP Context Acc)
....................................................................................................................................................................................................................................
Call availability optimization and troubleshooting RAB establishment
RAB establishment stages

The RAB Establishment procedure for both PS and CS calls may be categorized into
the following basic stages:
1. PDP Context Activation (PS) or Call Setup (CS) Request by the UE
2. RANAP RAB Assignment Request
3. Dynamic Bearer Control at the RNC
4. NBAP Radio Link Reconfiguration
5. RRC Radio Bearer Establishment
6. RANAP RAB Assignment Response
7. PDP Context Accept (PS) or Call Alerting and Connect Procedures
RAB establishment attempt failures

The major RAB establishment attempt failure components may be classified as
follows:
• Dynamic bearer control failure
• Radio bearer establishment failures
• Miscellaneous failures, for example code starvation.

• RAB establishment success rate
• CSV RAB establishment success rate
• PS RAB establishment success rate
• CSD RAB establishment success rate
• E-DCH PS RAB Establishment Success Rate
• HSDPA PS RAB establishment success rate
• DCH PS RAB establishment success rate
....................................................................................................................................................................................................................................
Dynamic bearer control failures

...................................................................................................................................................................................................................................
Introduction
During RAB establishment the Dynamic Bearer Control (DBC) procedure is triggered
(see “RAB establishment call flow” (p. 7-27)).
During the DBC check if the Uplink, Downlink or Code resources are not available
(this is checked against the DBC threshold), then the DBC failure occurs and the RAB
establishment process is discontinued.
Uplink Interference
When the DBC threshold for Uplink Interference is crossed, a DBC failure occurs and
a RAB Assignment response failure is sent by the RNC causing the measurements
RAB.FailEstabCSNoQueuing.ULIntfer and RAB.FailEstabPSNoQueuing.ULIntfer for
CS or PS RAB assignment respectively to be pegged. This maybe due to interference
from other mobiles or related to antenna or cable issues.
Downlink Power
When the DBC threshold for Downlink power is crossed, a DBC failure occurs and a
RAB Assignment response failure is sent by the RNC causing the measurements
RAB.FailEstabCSNoQueuing.DLPwr and RAB.FailEstabPSNoQueuing.DLPwr for CS
or PS RAB assignment respectively to be pegged. This is related to unavailability of
Downlink power resource in the NodeB to establish the new RAB connection. This
maybe due to a large number of voice or low speed calls or few high speed calls that
have consumed NodeB power resources.
Code Starvation
When a DBC failure occurs due to lack of Code resources, a RAB Assignment
response failure is sent by the RNC causing the measurements RAB.FailEstabCSNo-
Queuing.CodeStarv and RAB.FailEstabPSNoQueuing.CodeStarv for CS or PS RAB
assignment respectively to be pegged. The measurement VS.ChanCodeUtil can be
monitored for code usage in conjunction with this RAB failure measurement.
System load counters

Counters related to system load such as VS.RF.ForwrdTrafficChn.Overload,
VS.RF.TxCodePwr.Max, VS.RF.TxCodePwr.Mean and VS.RF.RTWP.Max,
VS.RF.RTWP.Mean may be used to verify that the load in the cell or NodeB is fairly
high.
...................................................................................................................................................................................................................................
Call availability optimization and troubleshooting Dynamic bearer control failures
Other counters
Issues in the NodeB that causes RAB Establishment failure due to NodeB specific
errors or time expiries, but not due to lack of resources are captured by the counters:
• RAB.FailEstabCSNoQueuing.RLReconfFail.NodeBErr
• RAB.FailEstabPSNoQueuing.RLReconfFail.NodeBErr
Related PMs / KPIs

• VS.RF.ForwrdTrafficChn.Overload
• VS.RF.TxCodePwr.Max
• VS.RF.TxCodePwr.Mean
• VS.RF.RTWP.Max
• VS.RF.RTWP.Mean
• VS.ChanCodeUtil
• VS.FwdPowerOvldDuration
• RAB.FailEstabCSNoQueuing.RLReconfFail.NodeBErr
• RAB.FailEstabPSNoQueuing.RLReconfFail.NodeBErr
....................................................................................................................................................................................................................................
Radio bearer establishment failures

...................................................................................................................................................................................................................................
Introduction
Once the required resources have been successfully reconfigured in the Node B, the
RRC radio bearer establishment procedure is executed in order to set up a new radio
bearer at the UE.
Radio bearer establishment procedure

The RNC sends the radio bearer setup message to the UE that then sends back the
radio bearer setup complete message to the RNC, therefore, successfully allocating
resources for the new radio bearer.
Radio bearer establishment failures from UE

Upon receiving the radio bearer setup message the UE may not successfully allocate
the required resources to setup the new radio bearer. In this case the UE sends back the
radio bearer setup failure message to the RNC and the radio bearer establishment
procedure fails.
Possible reasons for Radio Bearer establishment failures are:
• A radio bearer failure from the UE
• No answer from UE
This is mainly caused by poor RF conditions.
All RB failures impact the value of the KPI RAB Establishment Success Rate. They
can be identified via the PM counters RAB.FailEstabCSNoQueuing.RBSetupFail and
RAB.FailEstabCSNoQueuing.RBSetupFail, triggered when radio bearer setup failure
message is received at the RNC.
...................................................................................................................................................................................................................................
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
uERadioBearerSetup-ResponseTimer. If the guard timer expires and no message is
received from the UE, then the radio bearer establishment procedure fails and all the
allocated UTRAN resources are released.
No answer from UE failures

The normal reason for this failure scenario is due to poor RF conditions, that could
result because of poor coverage or high interference.
In addition, too low a setting of the timer uERadioBearerSetupResponse-Timer with
respect to the UE response time may be the failure cause.

This failure causes degradation of the KPI RAB establishment success rate. The
specific UTRAN PM counter RAB.FailEstabCSNoQueuing.T3exp and
RAB.FailEstabPSNoQueuing.T3expare triggered when the guard timer expires for CS
and PS RAB establishments respectively.
Related PMs / KPIs

• RAB.FailEstabCSNoQueuing.T3exp
• RAB.FailEstabPSNoQueuing.T3exp
• RAB.FailEstabPSNoQueuing.T3exp.DCH_DCH
• RAB.FailEstabPSNoQueuing.T3exp.DCH_HSDSCH
• RAB.FailEstabPSNoQueuing.T3exp.EDCH_HSDSCH
...................................................................................................................................................................................................................................
8 8 all reliability optimization and
C
troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
be used to localize problems and to optimize issues related to maintaining the call.
Contents
Dropped calls analysis 8-2

Radio link failures analysis due to synchronization issues 8-6
Dropped RAB analysis due to congestion 8-9
...................................................................................................................................................................................................................................
Call reliability optimization and troubleshooting
Dropped calls analysis

...................................................................................................................................................................................................................................
Introduction
As soon as the call is successfully set-up, the second factor of the 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. 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 the KPIs, CS Speech RAB Drop Rate PS Data, RAB Drop Rate
and CS Data RAB drop rate, which are defined as the percentage of dropped RAB due
to any UTRAN generated reason against the total number of established RABs for the
different type of services, can be calculated.
Signalling flow
The signaling flow of total RABs dropped (all service types):
...................................................................................................................................................................................................................................
Call reliability optimization and troubleshooting Dropped calls analysis
UE Node B RNC SGSN

Uu Iub Iu-ps
RRC RRC
RAB 64 kbps UL and DL
A dropped RAB connection

due to any kind of failure Note: RNC decides to drop RAB
due to an unrecoverable failure
Cell_DCH
Iu release request
(UTRAN generated reason)
RANAP RANAP
RAB.Rel.Drop.sum
Iu release command
(Release cause: as per TS 25.413)
RANAP RANAP
RRC Connection release

(Note: message sent if RRC
connection still exists)
(DCCH)
RRC Connection release complete

(Release cause: as per TS 25.331)
(DCCH)
NBAP RL Deletion procedure
ALCAP release procedure
RANAP Iu release complete

UE_Idle
On the UTRAN call handling procedures the dropped RABs are identified by the
following:
• RANAP Iu Release Request procedure
• RANAP Iu RAB Release Request procedure
• RANAP Reset procedure
• RANAP Reset Resource procedure
In case of an Iu Release Request message the resources on the UTRAN and core
network are released.
...................................................................................................................................................................................................................................
Note: For PS calls the PDP context will not be released in the SGSN and the context
will move into the preserved state.
Possible failing reasons

The major components that constitute RAB Drops may be classified as follows:
• Radio Link Failure, caused by:
– poor RF coverage
– poorly defined neighbor list
– poor Primary Scrambling Code (PSC) plan-pilot pollution
– DL power overload.
– UL Interference
• Operator intervention (for example reset, lock action)
• Inter-RAT handover due to supervision timer expiry (UMTS to GSM)
• URA_PCH time-out (due to the UE not performing a periodical URA update)
• Iu, Iub and Iur link failure
• RRC signal connection release Indication sent by the UE.
• Failures during SRNS Relocation procedure
• Unsuccessful termination of the Iu Rate control procedure
• UE Inactivity.
There are several PM counts listed in the UMTS Performance Measurements Definition
Manual, 401-382-803 that list the RAB Drop counter for the different causes stated
above. These can be studied with respect to the number of established RABs to obtain
a ratio for the specific issue and studied on a cell by cell basis to find out high runner
cells.
Related PMs / KPIs

• CS Speech RAB Drop Rate
• CS Data RAB Drop Rate
• PS RAB Drop Rate (PS RAB establishment)
• UTRAN PS RAB drop rate (always-on)
• PS RAB drop rate - Traffic
• UTRAN PS RAB drop rate - Traffic
• E-DCH RAB drop rate - E-DCH traffic
• UTRAN E-DCH RAB drop rate - E-DCH traffic
• HSDPA RAB drop rate - HSDPA traffic
...................................................................................................................................................................................................................................
• UTRAN HSDPA RAB drop rate - HSDPA traffic

• DCH RAB drop rate - DCH traffic
• UTRAN DCH RAB drop rate - DCH traffic
• Cell_FACH RAB drop rate - Cell_FACH traffic
• UTRAN Cell_FACH RAB drop rate - Cell_FACH traffic
• VS.RAB.Drop.<xx>
...................................................................................................................................................................................................................................
Radio link failures analysis due to synchronization issues

...................................................................................................................................................................................................................................
Introduction
Radio Link Failures (RLF) due to synchronization issues can take place in both the
downlink and uplink direction. The physical layer in the Node B and UE checks the
synchronization status of every radio frame.
Initial
RL Restore state
RL Failure
In-sync Out-of-sync
state state
RL Restore
RLF in the downlink

The RLF procedure in the downlink is supervised in the UE. In the Cell_DCH State,
the UE starts timer T313 after receiving N313 consecutive out-of-sync indications. The
UE stops and resets timer T313 upon receiving successive N315 in-sync indications. If
T313 expires, the UE considers that the radio condition is terminated with an RLF. The
UE will no longer transmit any data on the terminated RL. This will cause the uplink
RLF procedure to be started within the UTRAN.
Note: For details on timers/counters above, refer to 3GPP 25.331.
As a downlink RLF typically ends up causing an uplink RLF, it is assumed that the
PM counters for the uplink RLF usually covers all RLF.
RLF and radio link restore in the uplink

In the Cell_DCH state 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 in a given Node B,
this means a softer handover status. The Node B needs to monitor the complete radio
link sets to trigger RLF and radio link restore procedures.
...................................................................................................................................................................................................................................
Call reliability optimization and troubleshooting Radio link failures analysis due to synchronization issues
Abnormal uplink RAB disconnects

When loss of uplink synchronization of the air interface radio conditions occurs:
• The Node B sends an NBAP Radio Link Failure Indication with cause
“synchronization failure” to the RNC upon detection of loss of uplink
synchronization on the air interface
• The RNC then starts the timer: T_RL_RESYNC
• If the radio link recovers, an NBAP RL Restore message is sent and timer,
T_RL_RESYNC is stopped.
• If the timer T_RL_RESYNC expires, the RNC removes the particular radio link in the
Node B via the NBAP radio link deletion procedure incrementing the PM counter
VS.RLM.DropRL.ULRLFLossSync.
The following cases have to be distinguished:
– The UE has more than one radio link, which will not lead to a dropped call
– In case the dropped radio link is the last or only one the UE is connected to,
the call is dropped and the RNC releases the Iu connection. The PM counter
VS.RAB.DROP.<CS service type>.Cause<UL/DL>RLF is incremented.
Radio link failures due to synchronization issues can be identified via PM counter
VS.RLM.DropRL.ULRLFLossSync that is triggered after expiration of the guard timer
T_RL_RESYNCH.
In case of Radio link failures NOT due to synchronization issues, the PM counter
VS.RLM.DropRL.ULRLFNoLossSync records the results.
In case RLF for a UE with one radio link only occurs, the radio link loss results in a
dropped call. The Iu connection is then abnormally released causing the RAB drop
PMs to be incremented.
The RLF specific counters triggered per service are:
• VS.RAB.Drop.CSV.CauseULRLF
• VS.RAB.Drop.CSD.CauseULRLF
• VS.RAB.Drop.PS.DCH.CauseULRLF
• VS.RAB.Drop.PS.HSDSCH.CauseULRLF
• VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail
• VS.RAB.Drop.CS.DL_RLF
• VS.RAB.Drop.PS.DL_RLF
Related PMs / KPIs

• CS RAB Drop Rate due to DL RLF
• CS RAB Drop Rate due to UL RLF
...................................................................................................................................................................................................................................
Call reliability optimization and troubleshooting Radio link failures analysis due to synchronization issues
• PS RAB Drop Rate due to DL RLF

• PS RAB Drop Rate due to UL RLF
• Total PS Dropped RABs cause UL RLF
...................................................................................................................................................................................................................................
Dropped RAB analysis due to congestion

...................................................................................................................................................................................................................................
Introduction
A PS RAB (from DCH or HSDSCH) might be abnormally released due to congestion.
Typically a PS RAB would not be released, but the data rate would be reduced. Only
in the case where further data rate reduction is not possible would finally a PS RAB be
dropped.
RAB Drops due to Downlink Power

Established RABs could be dropped when the Downlink Power resource in the NodeB
is not available to maintain the call. This could happen due to the a large number of
UEs handled by the NodeB and some of the UEs maybe moving away from the cell
site transmitter causing increase in allocated DL power to service these UEs. With
proper design these UEs should handover to another NodeB, but if this does not
happen the RAB will be dropped with the RNC initiating an Iu Release procedure with
cause “no resource available” and event “downlink power” occurred in the RNC.
The counters VS.RAB.Drop.CS.DLPwr and VS.RAB.Drop.PS.DLPwr will be pegged for
CS or PS calls respectively.
The following NodeB counters can provide additional information on the power levels
of the NodeB where these failures are seen:
• VS.RAB.Drop.CS.DLPwr
• VS.RF.TxCodePwr.Max
• VS.RF.TxCodePwr.Mean
• VS.RF.TxCodePwr.LEminus9 to VS.RF.TxCodePwr.LEplus46
• VS.RF.TxPwr.HsPdschCodes.Max
• VS.RF.TxPwr.HsPdschCodes.Mean
• VS.RF.TxPwr.HsScchCodes.Max
• VS.RF.TxPwr.HsScchCodes.Mean
• VS.RF.TxPwr.AllCodes.Max
• VS.RF.TxPwr.AllCodes.LE10 to VS.RF.TxPwr.AllCodes.LE100
RAB Drops due to Uplink Interference

Established RABs could be dropped when the uplink interference received by the
NodeB is so high that the call cannot be maintained and is terminated. This could
happen due to a large number of UEs handled by the NodeB or in nearby NodeBs
causing high uplink interference. Geographical terrain and presence of water bodies
could also increase uplink interference as the NodeB might have a Line of Sight
...................................................................................................................................................................................................................................
Call reliability optimization and troubleshooting Dropped RAB analysis due to congestion
visibility to distant UEs. With proper design and parameter settings in the network, the
uplink interference can be reduced, but if high uplink interference is seen, the RAB
will be dropped with the RNC initiating an Iu Release procedure with cause “no
resource available” and event “uplink interference” occurred in the RNC.
The counters VS.RAB.Drop.CS.ULIntfer and VS.RAB.Drop.PS.ULIntfer will be pegged
for CS or PS calls respectively.
The following counters can be observed to further understand the interference
conditions in the NodeB:
• VS.RF.RTWP.Max
• VS.RF.RTWP.Mean
• VS.RF.RTWP.LE110 to VS.RF.RTWP.GT90
• VS.RF.SIR.Max
• VS.RF.SIR.Mean
• VS.RF.SIRerror.Max
• VS.RF.SIRerror.Mean
• VS.RF.SIR.LEminus11 to VS.RF.SIR.LEplus20
• VS.RF.SIRerror.LEminus30 to VS.RF.SIRerror.LEplus31
• VS.RF.TxPwr.AllCodes.LE10 to VS.RF.TxPwr.AllCodes.LE100
RAB Drops due to UE inactivity

Established RABs could be forced to drop if the inactivity timer expires for the call
and the UE does not support URA_PCH State, or if the UE is redirected, or if multiple
PDP contexts are in place for the call. The counter VS.RAB.Drop.UEInactivity will be
pegged when such events occur. RAB drop analysis, the contribution of these drops
provide an insight into the UE equipment used by the customers and their user
experience due to limitations in the UE or Network.
RAB drops due to Operator intervention

Active calls could be dropped when the operator issues a LOCK or RESET command
to any of the following Managed Objects:
• IuR
• IuPS
• IuCS
• IuB
• Lcell
• HSDPA
...................................................................................................................................................................................................................................
• LRNC
• LNodeB
This could happen due to parameter changes or when operations work is carried out on
the network. This can be minimized by observing traffic patterns in the area of impact
and scheduling operator intervention activities when the subscriber traffic is at its least.
PS Data RAB Drop Rate due to UE Poor Quality and Minimum rate
When an active Packet call is in progress at the minimum rate with the UE reporting
poor quality and power (5A/6A) and the parameter rABreleaseMinRateGbrRab is
configured to “TRUE” , then the PS RAB maybe dropped. The percentage of such
drops can be obtained by the KPI, PS Data RAB Drop Rate due to UE Poor Quality &
Minimum Rate. It must be noted that these PS RAB drops will occur for QoS Class
“streaming” only. This KPI can be studied in conjunction with KPIs, CS RAB Drop
Rate due to DL Power, PS RAB Drop Rate due to DL Power, CS RAB Drop Rate due
to UL Interference and PS RAB Drop Rate due to UL Interference and a
comprehensive picture of the power and interference issues in the cell can be inferred
and steps to improve power and decrease interference can be taken.
RAB Drops due to Radio Link Control (RLC) errors

RLC errors on the uplink or downlink can lead to RAB drops. The UL RLC failures
are detected by the UE (upon RLC resets/disruptions) which would subsequently notify
the RNC via RRC Cell Update with cause “UnrecoverableRLCError”. The DL RLC
failures are normally detected by the TPU RLC layer which would then notify the BSC
via BTI TPU Radio Bearer Failure Indication.
Related PMs/KPIs
• VS.RAB.Drop.CS.ULRLCFail.DCCH
• VS.RAB.Drop.CS.DLRLCFail.DCCH
• VS.RAB.Drop.PS.ULRLCFail.DCCH
• VS.RAB.Drop.PS.ULRLCFail.DTCH
• VS.RAB.Drop.PS.DLRLCFail.DCCH
• VS.RAB.Drop.PS.DLRLCFail.DTCH
RAB Drops initiated by the Core Network

RAB drops can be initiated by the Packet or Circuit Core network due to several
reasons such as authentication errors, unsupported Integrity protection algorithm, O&M
intervention among others causes. Performance measurements for Circuit and Packet
core network related drops are pegged as listed below. Further analysis can be done by
isolating the Core network element that is common to the RNCs where these counts
...................................................................................................................................................................................................................................
are seen to be high. Corresponding Core Network initiated drop measurements from
the 3G MSC and 3G SGSN will need to be analyzed for obtaining the root cause of
the problem.
Related PMs/KPIs
• VS.RAB.Drop.CN_Init.CS
• VS.RAB.Drop.CN_Init.PS.Cell_DCH.DCH_DCH
• VS.RAB.Drop.CN_Init.PS.Cell_DCH.DCH_HSDSCH
• VS.RAB.Drop.CN_Init.PS.Cell_DCH.EDCH_HSDSCH
• VS.RAB.Drop.CN_Init.PS.Cell_FACH
• VS.RAB.Drop.CN_Init.PS.URA_PCH
RAB Drops during reconfiguration

RAB drops occur when the radio bearers are reconfigured from DCH to HSDSCH or
vice versa. This can occur due to poor coverage or interference issues leading to timer
DchHsDSCH expiry while waiting for a Radio Bearer reconfiguration complete
message from the UE. The RAB is also dropped when a Radio Bearer reconfiguration
failure message is sent by the UE.
Related PMs/KPIs
• VS.RAB.Drop.Reconf.DCH_HSDSCH
• VS.RAB.Drop.Reconf.HSDSCH_DCH
...................................................................................................................................................................................................................................
9 9 all quality optimization and
C
troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This chapter describes the performance indicators that can be used to retrieve
information about the call quality.
Quality is defined as the quality of the connection as perceived by the subscriber. The
intention of the metrics are to measure, as closely as possible, the customers’
perception of the network performance in terms of service quality.
Contents
Quality KPIs 9-2
...................................................................................................................................................................................................................................
Call quality optimization and troubleshooting
Quality KPIs
...................................................................................................................................................................................................................................
Introduction
Although a 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 a data call the poor quality
may cause throughput degradation.
There are several aspects that determine the call quality, such as delay, jitter and
BLER, where, in this release, measurements are available for the UL Block Error Rate.
Quality KPI
UL Block Error Rate (BLER) is the KPI providing an indication of the quality of the
UMTS call. The quality KPIs capture the uplink failure on RNC basis:
(A / B) × 100
Where:
A = The number of errored Transport Blocks per service type
B = The total number of Transport Blocks per service type
The quality KPIs on Uplink Block Error Rate can be calculated for services CSD, CSV
4.75, PS.
Poor quality reasons

High values of the quality KPIs indicate that the perceived uplink quality of the call is
poor. Usually this also has an impact on the UL/DL throughput related KPIs.
In order to correctly identify the root cause of high UL/DL BLER values, the UE and
the Node B transmitted power should be checked respectively:
• If the UE and/or the Node B transmitted power has reached the maximum allowed
value, then the most likely root cause is given by poor RF conditions that are
limiting either the downlink or the uplink, or both.
• If the UE and/or the Node B transmitted power has not reached the maximum
allowed value, then the most likely root cause is given by respectively UL and/or
DL closed loop power control issues.
Basic root cause analysis method for high UL/DL BLER issues:
...................................................................................................................................................................................................................................
Call quality optimization and troubleshooting Quality KPIs
High UL/DL BLER
Yes Max UE / Node B No UL/DL

Poor RF transmitted power power
conditions reached? control issues
Note: It should not be assumed that UL BLER issues will also result in DL BLER
issues and vice versa. In several scenarios the system may be either only uplink or
only downlink limited due to unbalanced loads.
Other abnormal values

Other counters related to system load such as Transmitted Code Power, Received Total
Wideband Power, Forward channel overload duration and Signal to Interference Ratio
may be used to verify that the load in the cell is fairly high, which would increase the
probability for call setup failures. There are also several RAB Drop measurements
related to Radio link failure, UL interference and DL Power which can be studied in
parallel to ascertain the quality issues faced by the subscriber.
Note: DL BLER distribution per cell and UL BLER distribution per cell can be derived
using the probe (for example, Tektronix). A prerequisite is to enable periodic
measurement reports from the UE.
Related PMs / KPIs
• VS.RF.RTWP.xx
• VS.RF.TxCodePwr.xx
• VS.RF.SIRerror.xx
• VS.FwdPowerOvldDuration
• CS Data UL Transport Block Error Rate
• CS Voice UL Transport Block Error Rate
• CSV 4.75 UL Transport BLER
...................................................................................................................................................................................................................................
Call quality optimization and troubleshooting Quality KPIs

• PS UL Transport Block Error Rate
• VS.RAB.Drop.CSV.CauseULRLF
• VS.RAB.Drop.CSD.CauseULRLF
• VS.RAB.Drop.PS.DCH.CauseULRLF
• VS.RAB.Drop.PS.HSDSCH.CauseULRLF
• VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail
• VS.RAB.Drop.CS.ULIntfer
• VS.RAB.Drop.PS.ULIntfer
• VS.RAB.Drop.CS.DLPwr
• VS.RAB.Drop.PS.DLPwr
• VS.RAB.Drop.CS.DL_RLF
• VS.RAB.Drop.PS.DL_RLF
RAB Modification failures affecting subscriber

The poor quality of the subscriber experience can also be studied by analyzing RAB
modification attempts and failures due to various causes such as BLER, congestion,
UE Transmit power etc. RAB modifications could be SGSN initiated or RNC initiated.
By observing the number of RAB modifications and their reasons in a particular
cell/area/RNC, the quality issues that may be faced by the subscriber can be assessed.
Related PMs / KPIs
• RAB.AttModPS.Strm
• RAB.FailModPSNoQueuing.Strm
• RAB.FailModPSNoQueuing.Incr
• RAB.FailModPSNoQueuing.IncompReq
• RAB.FailModPSNoQueuing.ProcFail
• VS.RAB.AttModPSRNCini.BLER.Strm
• VS.RAB.AttModPSRNCini.UEtxPwr.Strm
• VS.RAB.AttModPSRNCini.ULConC.Strm
• VS.RAB.AttModPSRNCini.DLConC.Strm
• VS.DataRateFail.Dec.RABMod
• VS.DataRateFail.Timeout
• VS.DataRateFail.FailMsg
...................................................................................................................................................................................................................................
10 10 mobility optimization and
Call
troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
be used to localize problems and to optimize issues related to call mobility.
Contents
Soft/Softer handover and troubleshooting 10-3

Soft/softer handover procedure 10-4
Average active set size 10-7
Soft handover troubleshooting 10-9
No Node B resources available 10-12
No transport resources available 10-13
No UE answer 10-14
UE reject 10-15
Unlisted set cells 10-16
CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting 10-18
CS Voice UMTS to GSM (inter-RAT) handover procedure 10-19
CS Voice relocation preparation procedure troubleshooting 10-23
CS Voice IRAT handover procedure troubleshooting 10-25
CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting 10-26
CS Voice GSM to UMTS (inter-RAT) handover procedure 10-27
Relocation resource allocation procedure troubleshooting 10-30
Handover procedure troubleshooting 10-32
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Overview
PS UMTS to GSM (inter-RAT) Cell Change Order and 10-33

troubleshooting
PS UMTS to GSM (inter-RAT) Cell Change Order procedure 10-34
PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting 10-37
Serving HS-DSCH Cell Change 10-39
Serving HS-DSCH Cell Change procedure 10-40
Serving HS-DSCH Cell Change troubleshooting 10-43
Inter-frequency hard handover and troubleshooting 10-44
Inter-frequency hard handover procedure 10-45
Hard handover troubleshooting 10-50
UE reject 10-55
Inter-system directed retry 10-56
Inter-system directed retry procedure 10-57
Inter-system directed retry troubleshooting 10-60
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting
Soft/Softer handover and troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides soft/softer handover optimization and troubleshooting
information.
Contents
Soft/softer handover procedure 10-4

Average active set size 10-7
Soft handover troubleshooting 10-9
No UE answer 10-14
UE reject 10-15
Unlisted set cells 10-16
...................................................................................................................................................................................................................................
Soft/softer handover procedure

...................................................................................................................................................................................................................................
Introduction
In UMTS networks soft/softer handover is the basic feature that ensures seamless
mobility as well as call performance and quality improvements.
Soft/softer handover signaling flow

The basic Intra-RNC soft handover procedure in case of addition of a pilot to the
Active Set (this means event 1A) is depicted. Step 4 has been grayed out as it refers to
the removal of a radio link (this means event 1B). Both step 2 and 4 will be used in
case of a radio link replacement (this means event 1C).
The basic Intra-RNC soft handover procedure is:
UE Node B - 1 Node B - 2 SRNC
RRC Measurement Report (Event 1A)

RRC RRC 1
(DCCH over DCH)
RL Setup Request
NBAP NBAP
2 PM-A
RL Setup Response PM-B
NBAP NBAP
Active Set Update

RRC RRC
(Radio Link addition)
PM-C
3 PM-D
Active Set Update Complete
RRC RRC
RL Deletion Request
NBAP NBAP
4
RL Deletion Response
NBAP NBAP
RCC Measurement Control

RRC RRC 5
(DCCH over DCH)
PM-A = RLM.AttRLSetupIub PM-C = SHO.AttRLAddUESide

RLM.AttRLSetupIub.CSV
RLM.AttRLSetupIub.CSD
RLM.AttRLSetupIub.PSD
PM-B = RLM.SuccRLSetupIub PM-D = SHO.SuccRLAddUESide

RLM.FailRLSetupIub.NodeBRes.CSV SHO.FailRLAddUESide.InvalidConfig
RLM.FailRLSetupIub.NodeBRes.CSD SHO.FailRLAddUESide.IncompSimultReconf
RLM.FailRLSetupIub.NodeBRes.PSD SHO.FailRLAddUESide.ProtErr
RLM.FailRLSetupIub.TransRes.CSV SHO.FailRLAddUESide.ConfigUnsupport
RLM.FailRLSetupIub.TransRes.CSD SHO.FailRLAddUESide.NoReply
RLM.FailRLSetupIub.TransRes.PSD
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Soft/softer handover procedure
Soft/softer handover procedure steps

The soft/softer handover procedure steps for UE in Cell_DCH state are:
1. Reporting of soft/softer handover triggering event to the UTRAN via an RRC
measurement report message
2. Set up resources in the UTRAN via NBAP procedure (in case of addition or
replacement)
3. Soft/softer handover execution via RRC active set update procedure. Soft/softer
handover procedure is successfully executed on receipt of an RRC active set update
complete message at the RNC
4. Clear resources in the UTRAN via NBAP procedure (case of removal or
replacement)
5. Monitored Set update upon Neighbor List Selection Algorithm (NLSA) evaluation
via an RRC measurement control message.
Handover scenarios
Soft/softer handovers can be executed as Intra-RNC as well as Inter-RNC. In case of
Inter-RNC soft/softer handover, the RNCs involved are defined as Serving RNC
(SRNC) and one or several Drift RNCs (DRNC).
Soft handover event 1A

In case of soft handover with event 1A triggered, other procedures via ALCAP and
DCH Framing Protocols are executed on the Iub interface in between Radio Link
Set-up (step 2) and Active Set Update (step 3) procedures.
Softer handover
In case of softer handover, the NBAP Radio Link Addition is executed within the same
Node B instead of NBAP Radio Link Setup.
Inter-RNC soft handover

In case of Inter-RNC soft handover the procedure is executed in the same way as
where SRNC is executing Active Set Update procedure (step 3) while DRNC is taking
care of the NBAP procedures (steps 2 and 4) initiated by the SRNC through the Iur
interface via corresponding Radio Network Subsystem Application Part (RNSAP)
procedures.
This means that, for example, in case of event 1A triggered in one Node B belonging
to the DRNC then the SRNC initiates the setup of the resources at the DRNC via the
RNSAP Radio Link Setup procedure. Afterwards the DRNC allocates the required
resources at the relevant Node B via the NBAP Radio Link Setup procedure. This
example is valid when no soft handover context exists at the Node B, otherwise
RNSAP and NBAP Radio Link Addition procedures are executed instead.
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Soft/softer handover procedure
Soft/softer handover procedure is successfully executed on receipt of RRC Active Set

Update Complete message at the RNC.
....................................................................................................................................................................................................................................
Average active set size

...................................................................................................................................................................................................................................
Description
The “Active Set Size” may either be provided as distribution (presentage of set size
being used) or the average.
Active Set Size Distribution

The Active Set Size Distribution KPI provides the RL active set size distribution in
percent. The active set size per UE is in the range one to six. Per active set size (1 to
6), the percentage how often the relevant active set size is used will be provided on a
per cell basis.
KPI formula
Percentage Active Set Size 1 = 100 × (VS.RLSetAct.Size1 / (VS.RLSetAct.Size1 +
VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5
+ VS.RLSetAct.Size6))
Average Active Set Size

The KPI Average Active Set Size provides the “overhead” due to SHO radio links, that
is the number of radio links established per active UE. It is derived from the sum of all
RLs active in the cell divided by the sum of active sets on a per cell basis.
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Average active set size
KPI formula
Average Active Set Size = ((VS.RLSetAct.Size1 × 1) + (VS.RLSetAct.Size2 × 2) +
(VS.RLSetAct.Size3 × 3) + (VS.RLSetAct.Size4 × 4) + (VS.RLSetAct.Size5 × 5) +
(VS.RLSetAct.Size6 × 6)) / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 +
VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)
....................................................................................................................................................................................................................................
Soft handover troubleshooting

...................................................................................................................................................................................................................................
Introduction
In general failures that occur during this procedure result in an increase of interference
in the system. This may have an impact on the call reliability by causing dropped calls
as well as causing degradations of either the voice call quality or the packet session
performances.
The major SHO failure components

The major components that constitute failures of both Intra-RNC and Inter-RNC Soft
handover are:
• Poor RF conditions
• Incorrect translations settings
• No Node B resources available
• No transport resources available
• No UE answer
• UE Reject
• Node B / RNC outages
• Iub, Iur link outages
• Iur configuration to drift RNC.
Intra- / Inter-SHO PMs / KPIs

Regarding any SHO PM counters, Intra-RNC SHO is defined as SHO within cells of
the SRNC. These PMs are all provided on a per target cell basis. The identical set of
PM counters exist for the so-called Inter-RNC SHO, where SHO is performed for cells
on the DRNC. These PMs are provided on a per target DRNC basis.
Counter in the context of SHO are based on the “Active Set Update” message being
sent to the UE. The PM counters are split up per RL type:
• Signaling
• PS
• CS Voice
• CS Data
• PS and CS combinations
In addition there are separate counters for:
• Add / replace RLs from active set
• Delete RL from active set
• Per failure cause on RL addition / replacement
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Soft handover troubleshooting
Related PMs / KPIs

• SHO.AttRLAddUESide
• SHO.SuccRLAddUESide
• SHO.FailRLAddUESide.InvalidConfig
• SHO.FailRLAddUESide.IncompSimultReconf
• SHO.FailRLAddUESide.ProtErr
• SHO.FailRLAddUESide.ConfigUnsupport
• SHO.FailRLAddUESide.NoReply
• SHO.AttRLDelUESide
• SHO.SuccRLDelUESide
• SHO.AttRLAddUESide.IntraRNC.CSV
• SHO.AttRLAddUESide.IntraRNC.PSLowData
• SHO.AttRLAddUESide.IntraRNC.PSHighData
• SHO.AttRLAddUESide.IntraRNC.Signalling
• SHO.AttRLAddUESide.IntraRNC.CSD
• SHO.AttRLAddUESide.IntraRNC.CSDandPS
• SHO.AttRLAddUESide.IntraRNC.CSVandPS
• SHO.FailRLAddUESide.IntraRNC.CSV
• SHO.FailRLAddUESide.IntraRNC.PSLowData
• SHO.FailRLAddUESide.IntraRNC.PSHighData
• SHO.FailRLAddUESide.IntraRNC.Signalling
• SHO.FailRLAddUESide.IntraRNC.CSD
• SHO.FailRLAddUESide.IntraRNC.CSDandPS
• SHO.FailRLAddUESide.IntraRNC.CSVandPS
• SHO.AttRLAddUESide.InterRNC.CSV
• SHO.AttRLAddUESide.InterRNC.PSLowData
• SHO.AttRLAddUESide.InterRNC.PSHighData
• SHO.AttRLAddUESide.InterRNC.Signalling
• SHO.AttRLAddUESide.InterRNC.CSD
• SHO.AttRLAddUESide.InterRNC.CSDandPS
• SHO.AttRLAddUESide.InterRNC.CSVandPS
• SHO.FailRLAddUESide.InterRNC.CSV
• SHO.FailRLAddUESide.InterRNC.PSLowData
• SHO.FailRLAddUESide.InterRNC.PSHighData
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Soft handover troubleshooting
• SHO.FailRLAddUESide.InterRNC.Signalling
• SHO.FailRLAddUESide.InterRNC.CSD
• SHO.FailRLAddUESide.InterRNC.CSDandPS
• SHO.FailRLAddUESide.InterRNC.CSVandPS
....................................................................................................................................................................................................................................
No Node B resources available

...................................................................................................................................................................................................................................
Introduction
Upon successful decoding of Measurement Report message, the RNC requests the
Node B to allocate the required resources via NBAP Radio Link Addition procedure in
case of respectively soft or softer handover (refer to “Soft/softer handover signaling
flow” (p. 10-4))

The Node B may reject the resource allocation request due to no physical resources
available. This kind of failure indicates that there are capacity issues in specific areas
of the network.
This failure causes degradation of Soft/softer Handover Success Rate KPIs. The
UTRAN PM counter RLM.FailRLSetupIub.NodeBRes.<service type> identifies these
failure causes either on a per cell basis or on a per RNC basis in case the failure
occurs in the SRNC or in the DRNC respectively.
Additional counters such as VS.RLM.MeanActiveRL andVS.RLM.MaxActiveRL provide
an indication of the number of active Radio Links.
Related PMs / KPIs

• RLM.FailRLSetupIub.NodeBRes.<service type>
• VS.RLM.MeanActiveRL
• VS.RLM.MaxActiveRL
• Successful Active Set Update Addition Rate
...................................................................................................................................................................................................................................
No transport resources available

...................................................................................................................................................................................................................................
Introduction
The NBAP radio link setup procedure may fail due to no transport resources available,
this means no Iub links are available due to maximum supported capacity reached.
UTRAN PM counter RLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD> identifies these
failure causes either on a per cell basis or on a per RNC basis in case the failure
occurs in the SRNC or in the DRNC respectively.
Abnormal SHO.FailRLSetupIubUTRANSide.TransRes values

High values of RLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD> identify no Iub links
are available due to maximum supported capacity reached.
Related PMs / KPIs

• RLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD>
...................................................................................................................................................................................................................................
No UE answer
...................................................................................................................................................................................................................................
Introduction
Upon successful resource allocation in the NodeB the RNC executes the soft/softer
handover via the RRC active set update procedure by sending to the UE the RRC
active set update message (see “Soft/softer handover signaling flow” (p. 10-4)).
If the guard timer expires and no message is received from the UE then the active set
update procedure fails and all the allocated UTRAN resources are released.
The normal reason for this failure scenario is given by poor RF conditions either due
to poor coverage or high interference.
UTRAN PM counter SHO.FailRLAddUESide.NoReply is triggered when the guard
timer expires.
Abnormal soft/softer handover success rate KPI values

Low values are caused by the SHO.FailRLAddUESide.NoReply counter.
Related PMs / KPIs

• SHO.FailRLAddUESide.NoReply
...................................................................................................................................................................................................................................
UE reject
...................................................................................................................................................................................................................................
Introduction
Upon sending the Active Set Update message, in the case of failure the RNC receives
the Active Set Update Failure message from the UE.
UE reject
The UE reject failure causes are:
• Invalid configuration:
– scrambling codes inconsistencies
– same radio links to be added and deleted
– radio link deletion required for the only link/links currently in the Active Set
• Incompatible simultaneous re-configuration
• Protocol Error.
The failure causes result in degradation of Soft/softer handover success rate KPIs.
The following UTRAN PM counters are triggered on receiving the Active Set Update
Failure message depending on the failure cause included at the UTRAN:
• SHO.FailRLAddUESide.InvalidConfig (in case of invalid configuration)
• SHO.FailRLAddUESide.IncompSimultReconf (in case of incompatible simultaneous
re-configuration)
• SHO.FailRLAddUESide.ProtErr (in case of protocol error)
• SHO.FailRLAddUESide.ConfigUnsupport (in case of configuration unsupported)
Related PMs / KPIs

• SHO.FailRLAddUESide.InvalidConfig
• SHO.FailRLAddUESide.IncompSimultReconf
• SHO.FailRLAddUESide.ProtErr
• SHO.FailRLAddUESide.ConfigUnsupport
...................................................................................................................................................................................................................................
Unlisted set cells

...................................................................................................................................................................................................................................
Introduction
For the intra-frequency (soft / softer) handover procedure, the RNC sends a list of cells
to the UE. This list is called Cell_Info_List and it contains all cells that the UE will
measure for intra-frequency mobility purposes. It contains all active set cells and also
the monitored set cells (i.e. the so called neighbor cells). In addition to the active set
and the monitored set there is a third set of cells called the “unlisted” or “detected” set.
For a UE, all cells of the network not belonging to the active or monitored set, belong
to the unlisted set.
detectedSetCellReporting
For the purpose of intra-frequency measurements the 3GPP standard allows to which
cells the UE will measure to be specified, i.e. it is possible to specify if the UE will or
will not search for unlisted set cells. In the Alcatel-Lucent UTRAN the operator has
the possibility to switch ON or OFF measurements and reporting of unlisted set cells
by means of the parameter detectedSetCellReporting (parameter can be set to True or
False). If the UE also searches for unlisted set cells, this will somehow slow down the
measurement process for the cells in the Cell_Info_List, but on the other hand such
measurements are very useful for network optimization. By means of these
measurements the operator is able to recognize if some cells are missing in the
neighbor list, i.e. the operator is able to optimize the neighbor cell relationship by
adding missing neighbor cells to the monitored set.
Neighboring cells
Each UMTS cell has its specific list of neighboring cells, which is used to derive the
monitored set and the Cell_Info_List. For a UE in soft handover, there are now two or
more active set cells, which each have their individual neighbor lists. In this case the
Alcatel-Lucent UTRAN generates a Cell_Info_List with all relevant monitored set cells
by invoking the Neighbor List Selection Algorithm (NLSA). The NLSA makes use of
several criteria, including the priority given to each cell in the neighbor lists, i.e. the
higher the priority given to a specific cell in the neighbor list, the higher the
probability that this cell is included in the Cell_Info_List. In case some relevant cell is
missing in the Cell_Info_List, the operator may consider to increase the priority given
to that particular neighbor cell. If the cell is not included in the neighbor list at all it
should be added.
Handling of measurement reports in soft handover

In the case where reporting of unlisted set cells has been enabled, the UE will also
continuously search for cells not included in the Cell_Info_List. It will send a
measurement report to the RNC as soon as the reporting criteria for the unlisted set
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Unlisted set cells
cell are met. Whenever a Primary Scrambling Code (PSC) is received from a UE, the
RNC will check if the corresponding cell was included in the Cell_Info_List. If it was
not included in the list, then the relevant counter per primary scrambling code shall be
incremented for the current best cell. This allows optimization of the neighbor cell
relationship in the network. The corresponding counter is given below.
Additionally, the RNC will check if the reported PSC is listed in the neighbor list of
any of the active set cells. In this case the cell can be identified unambiguously and the
soft handover procedure will be executed to add that cell to the active set. This is an
indication that the NLSA did not select the most relevant cells to be contained in the
Cell_Info_List.
The priorities given to the neighbor cells need to be adapted in this case. If the cell
does not belong to the neighbor list of any of the active set cells, then the cell cannot
be identified unambiguously. No soft handover will be performed in this case. Instead
the measurement report from the UE will be ignored and only the event will be
captured by the corresponding counter.
Related PMs / KPIs

Number of Unlisted Neighbour Cells per Current Best Cell
Per unlisted neighbour cell the following measurement types is added:
• NumUnlistHORejPerNcell.PrimScrCode
Identification of unlisted neighbour cell using the primary scrambling code
• NumUnlistHORejPerNcell.RejHO
Number of rejected HO for the previously specified unlisted neighbour cell
....................................................................................................................................................................................................................................
CS Voice UMTS to GSM (inter-RAT) handover and

troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides CS Voice UMTS to GSM (inter Radio Access Technology or
inter-RAT) handover procedure and troubleshooting information.
Contents
CS Voice UMTS to GSM (inter-RAT) handover procedure 10-19

CS Voice relocation preparation procedure troubleshooting 10-23
CS Voice IRAT handover procedure troubleshooting 10-25
...................................................................................................................................................................................................................................
CS Voice UMTS to GSM (inter-RAT) handover procedure

...................................................................................................................................................................................................................................
Introduction
Handover from UMTS to GSM is supported in current Alcatel-Lucent UMTS Release.
The UMTS to GSM (inter-RAT) handover is based on the assumption that UMTS
coverage islands are located within a GSM network, which provides full coverage
within a certain area.
CS Voice UMTS to GSM inter-RAT procedure

CS Voice UMTS to GSM (inter-RAT) handover is always a hard handover with
3G-MSC involvement. The UE must have established at least a circuit-switched (CS)
connection to the UMTS network.
CS Voice UMTS to GSM Handover can be performed for the following RAB
combinations:
• One CS voice connection, or
• One CS voice connection and simultaneous PS connection(s)
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 message 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.
CS Voice UMTS to GSM handover procedure

Upon a handover failure the CS and PS connections are further served by the UMTS
network depending on the radio conditions.
In general the UMTS-to-GSM handover procedure can be separated in the following
steps:
1. Handover relocation preparation within UMTS RAN/CN and GSM RAN/CN
2. Handover execution involving also the UE
3. Release of UMTS resources.
CS Voice UMTS to GSM handover signaling flows

CS Voice UMTS to GSM handover call signaling flow:
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting CS Voice UMTS to GSM (inter-RAT) handover procedure
Radio Access Network Core Network

UE Node B BTS SRNC BSC 3G-MSC 2G-MSC
Inter-RAT HO triggered
within the SRNC
Relocation Required
Map-prep-
Handover req.
Handover request
Channel activation procedure
(with HO Reference No.)
Channel activation Ack.

HO Rrequest Ack.
1
(with HO Command)
Map-prep-
Handover resp.
T_interRatGuard
IAM
ACM
Relocation Command
(including GSM HO Command)
Handover from UTRAN Command
(including GSM HO Command)
HO Access
(with HO Reference No.)
Handover Detect
Handover Detect
Physical Information
2
Map-Process-
SABM
Access-Sig req.
Establish Indication
UA
Handover Complete
Handover Complete
Map-Send-
Access-Sig req.
IU Release Command
Answer
Radio Link Deletion Request
3
Radio Link Deletion Response
IU Release Complete
....................................................................................................................................................................................................................................
Success rate KPIs

The following KPIs provide an indication of the success rate for CS Voice UMTS to
GSM handover:
• Relocation Preparation for CS UMTS to GSM HHO Success Rate
This KPI indicates the relocation preparation performance for UMTS to GSM HHO
for CS calls.
• CS IRAT HO Success Rate (UMTS -> GSM)
This KPI indicates the overall hard handover inter RAT performance towards GSM
network for CS calls starting from the relocation attempt.
• CS UMTS to GSM HHO Inter RAT Success Rate
This KPI indicates the hard handover inter RAT performance towards GSM
network for CS calls based on Ec/No and RSCP measurements.
• CS UMTS to GSM HHO Inter RAT Success Rate - RSCP only
This KPI indicates the hard handover inter RAT performance towards GSM
network for CS calls based on RSCP measurement only.
Matrix KPIs
For UMTS to GSM optimization, but also for specific troubleshooting, there are
special handover Matrix PM counters available. Different to other PMs, these Matrix
PM counters are provided on a per originating UMTS cell to relevant terminating GSM
target cell basis.
The UMTS to- GSM Handover Matrix PMs > CS UMTS to GSM Handover Success
Rate per GSM Neighbour Cell help to locate problems between UMTS and GSM cells
by providing the number of handover attempts and failures from the UMTS originating
cell to relevant GSM target cells. The counter is only available for those GSM cells
that are a target for handover in the reporting period and are reported on a daily basis.
UMTS to GSM handover failures

Components that constitute failures of UMTS to GSM handover may be classified as
follows:
1. Relocation preparation procedure failures
2. Handover procedure failures.
Related PMs / KPIs

• CS UMTS to GSM Handover Success Rate per GSM Neighbour Cell - Att
• CS UMTS to GSM Handover Success Rate per GSM Neighbour Cell - Fail
• Relocation Preparation for CS UMTS to GSM HHO Success Rate
• Relocation Preparation UMTS to GSM Failure Rate - <failure cause>
....................................................................................................................................................................................................................................
• CS IRAT HO Success Rate (UMTS -> GSM)

• CS UMTS to GSM HHO Inter RAT Success Rate
• CS UMTS to GSM HHO Failure Rate - <failure cause>
• Likely Dropped Call Rate in Target System due to CS UMTS to GSM HHO
• CS UMTS to GSM HHO Inter RAT Success Rate - RSCP only
....................................................................................................................................................................................................................................
CS Voice relocation preparation procedure troubleshooting

...................................................................................................................................................................................................................................
Introduction
Relocation preparation failures occur during the RANAP relocation preparation
procedure, for example GSM handover resource allocation fails or the core network
rejects the UMTS to GSM handover request.
Failure causes
A failure occurs due to the following causes:
• Timer T_RELOCprep expiry at the SRNC
• Relocation preparation failure.
Timer T_RELOCprep expiry at the SRNC

The SRNC initiates the Relocation Cancel procedure at the Iu interface. Note that the
relocation cancel procedure enables the CN to initiate the release of the resources
allocated during the relocation preparation procedure in the GSM network. The SRNC
considers the UMTS to GSM handover as impossible at this point in time and keeps
the existing radio connections established. This means that the existing Iu-signaling
connection can be further used for the call.
Relocation preparation failure

Receiving a Relocation Preparation Failure message from the 3G-MSC, the SRNC still
maintains the call. If the failure cause specified within the message is Relocation
Failure in Target CN/RNC or Target System or Relocation not supported in Target RNC
or Relocation Target Not Allowed or No Radio Resources Available in Target Cell, then
SRNC repeats the relocation preparation procedure with the next suitable cell from the
list of potential GSM target cells otherwise the SRNC considers the UMTS to GSM
handover as impossible at this point in time.
The counter IRATHO.FailRelocPrepOutCS.sum includes all the failure causes occurred
along the Handover Relocation Preparation procedure.
Also the following PM counters help to identify the specified failure causes:
• IRATHO.FailRelocPrepOutCS.ReqCiphNotSupp
• IRATHO.FailRelocPrepOutCS.FailTarSys
• IRATHO.FailRelocPrepOutCS.NotSupTarSys
• IRATHO.FailRelocPrepOutCS.TarNotAllowed
• IRATHO.FailRelocPrepOutCS.NoRRTarCell
• IRATHO.FailRelocPrepOutCS.TrLdHighTarCell
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting CS Voice relocation preparation procedure
troubleshooting
• IRATHO.FailRelocPrepOutCS.AbstSyntErr
• IRATHO.FailRelocPrepOutCS.OmInt
• IRATHO.FailRelocPrepOutCS.NoResAv
• IRATHO.FailRelocPrepOutCS.UnspecFail
• IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp
....................................................................................................................................................................................................................................
CS Voice IRAT handover procedure troubleshooting

...................................................................................................................................................................................................................................
Introduction
Upon successful completion of relocation preparation procedure, the SRNC sends the
handover from UTRAN command including the GSM handover command to the UE.
If the UE fails to complete the requested handover then the SRNC receives a handover
from UTRAN command failure message from the UE.
Failure causes
The failure causes specified within the message are as follows:
• Physical channel failure
• Unacceptable configuration
• Protocol error.
Physical channel failure

The physical channel failure cause occurs when the UE cannot access the target GSM.
This is mainly caused by poor RF conditions. The PM counter IRATHO.FailOutCS-
.PhyChnFail will be incremented.
Unacceptable configuration / protocol Error

Unacceptable configuration and protocol error are expected to occur seldom and in
general they are not related to RF issues. These are pegged by the PM counters
IRATHO.FailOutCS.ConfUnaccept and IRATHO.FailOutCS.ProtErr.
Related PMs / KPIs

• IRATHO.FailOutCS.PhyChnFail
• IRATHO.FailOutCS.ConfUnaccept
• IRATHO.FailOutCS.ProtErr
...................................................................................................................................................................................................................................
CS Voice GSM to UMTS (inter-RAT) handover and

troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides CS Voice GSM to UMTS (inter Radio Access Technology or
inter-RAT) handover and troubleshooting information.
Contents
CS Voice GSM to UMTS (inter-RAT) handover procedure 10-27

Relocation resource allocation procedure troubleshooting 10-30
Handover procedure troubleshooting 10-32
...................................................................................................................................................................................................................................
CS Voice GSM to UMTS (inter-RAT) handover procedure

...................................................................................................................................................................................................................................
Introduction
Handover from GSM to UMTS (inter-RAT) is supported for CS voice calls. The GSM
can trigger the handover depending on several conditions, for example, as soon as
sufficient UMTS coverage is available or when the GSM coverage is no longer
sufficient.
CS Voice GSM to UMTS (inter-RAT) handover

CS Voice GSM to UMTS handover can be performed for the following RAB
combinations:
• CS signaling only, or
• One CS voice RAB + CS signaling
CS Voice GSM to UMTS (inter-RAT) handover procedure

In general CS Voice GSM to UMTS handover can be separated into the following
steps:
1. Handover relocation preparation within the GSM RAN/CN and UMTS RAN/CN
2. Handover execution involving also the UE
3. Release of GSM resources
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting CS Voice GSM to UMTS (inter-RAT) handover procedure
CS Voice GSM to UMTS handover signaling flows
Radio Access Network Core Network

UE Node B BTS SRNC BSC 3G-MSC 2G-MSC
Handover Required
Map-prep-
Handover req.
Relocation Request
ALCAP Iu Transport Bearer Setup

Radio Link Setup Request
Radio Link Setup Response

1
ALCAP Iu Transport Bearer Setup
+ Frame Protocol Sync.
Relocation Request Ack.
(Including HO to UTRAN Command)
Map-prep-
Handover resp.
IAM
ACM
Handover Command
(including HO to UTRAN Command)
Handover Command
(including HO to UTRAN Command)
In Sync. Detection
Radio Link Restore Indication

Relocation Detect
Map-Process-
Access-Sig req.
2
Handover to UTRAN Complete
Relocation Complete
Map-Send-
Access-Sig req.
Answer
Clear Command
Radio Link Release

Clear Complete 3
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting CS Voice GSM to UMTS (inter-RAT) handover procedure
Success rate KPIs

One main KPI provides an indication of the success rate for GSM to UMTS handover.
The KPI Incoming CS Inter RAT Handover Success Rate (GSM->UMTS) measures the
percentage of GSM to UMTS handovers successfully completed.
CS Voice GSM to UMTS handover failures

Components that constitute failures of GSM to UMTS handover in UMTS may be
classified as follows:
1. Relocation resource allocation procedure failures
2. Handover procedure failures.
Related PMs / KPIs

• IRATHO.AttIncCS
• IRATHO.SuccIncCS
• IRATHO.FailIncCS.sum
• IRATHO.FailIncCS.T_hoToUtranComplete
• IRATHO.FailIncCS.HoNotEnabled
• IRATHO.FailIncCS.RelocCancel
• RAB.FailEstabCSNoQueuing.CSV.RelocIratHO
• Incoming CS Inter RAT Handover Success Rate (GSM->UMTS)
• Incoming CS Inter RAT Handover Success Rate (GSM->UMTS) - Normal Call
Release Impacted
....................................................................................................................................................................................................................................
Relocation resource allocation procedure troubleshooting

...................................................................................................................................................................................................................................
Introduction
Relocation failures occur during the RANAP relocation resource allocation procedure,
for example the GSM to UMTS handover is disabled in the target cell, or the resource
allocation fails in the target cell.
Failure causes
• GSM to UMTS handover is not enabled in the target cell
• The resource allocation fails due to any other reason.
GSM to UMTS handover is not enabled in the target cell

The SRNC returns a RANAP Relocation Failure message to core network. The GSM
to UMTS handover is aborted. If the PM counter IRATHO.FailIncCS.HoNotEnabled
has a value greater 0, the network configuration should be checked. If the handover
should be allowed, then the UMTS network has to be reconfigured to allow for the
incoming GSM to UMTS handover. If the handover should not be allowed for this
target cell, then the GSM network should be reconfigured so that no handover is
initiated to this target cell.
The resource allocation fails due to any other reason

If the handover resource allocation procedure fails due to any other reason then only
the PM counter IRATHO.FailIncCS.sum is incremented.
This can happen in case of following failures:
• 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 because the UE Security
Capability is not present in the Relocation Request message
• No S-RNTI 2 can be allocated
• No reduced range uplink scrambling code can be allocated
• The requested radio resources cannot be established, for example, radio link setup
fails on Iub or the ALCAP Iu transport bearer cannot be established.
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Relocation resource allocation procedure troubleshooting
Related PMs/KPIs
• IRATHO.FailIncCS.HoNotEnabled
....................................................................................................................................................................................................................................
Handover procedure troubleshooting

...................................................................................................................................................................................................................................
Introduction
Relocation failures occur during the handover procedure, when the UE does not access
the target cell or the MSC cancels the relocation before the UE has accessed the target
cell.
Failure causes
• Timer expiry
• Relocation cancel.
Timer expiry
After the relocation resource allocation procedure the UTRAN waits for the UE to
access the target cell and to send the RRC message HANDOVER TO UTRAN
COMPLETE. If this message is not received the PM counters IRATHO.FailIncCS.sum
and IRATHO.FailIncCS.T_hoToUtranComplete are incremented.
Probable causes for this failure are:
• The UE has moved out of GSM coverage and the call has dropped before the
handover command was sent to the UE by the GSM network. If this occurs, then
the handover should be initiated earlier in GSM
• The UE cannot access the UMTS cell due to insufficient radio conditions. In case
of measurement based handover the threshold values for the UMTS system should
be increased to ensure that the UMTS quality is sufficient before a handover is
initiated. In case of blind handover the network configuration should be checked if
the UMTS cell is a acceptable target for the complete coverage area of the GSM
source cell.
Relocation cancel
The GSM network has cancelled the relocation due to any reason that is outside of the
scope of UTRAN.
Related PMs/KPIs
• IRATHO.FailIncCS.T_hoToUtranComplete
• IRATHO.FailIncCS.RelocCancel
...................................................................................................................................................................................................................................
PS UMTS to GSM (inter-RAT) Cell Change Order

and troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides PS UMTS to GSM (inter-RAT) Cell Change Order and
troubleshooting information.
Contents
PS UMTS to GSM (inter-RAT) Cell Change Order procedure 10-34

PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting 10-37
...................................................................................................................................................................................................................................
PS UMTS to GSM (inter-RAT) Cell Change Order procedure

...................................................................................................................................................................................................................................
Introduction
Cell Change Order from UMTS to GSM is supported in the current Alcatel-Lucent
UMTS Release. The UMTS to GSM (inter-RAT) Cell Change Order is based on the
assumption that UMTS coverage islands are located within a GSM network, which
provides full coverage within a certain area.
PS UMTS to GSM Cell Change Order procedure

In case of PS UMTS to GSM Cell Change Order the UE is ordered to connect to a
GSM target cell. The UE must have established a packet-switched (PS) but no
circuit-switched (CS) connection to the UMTS network.
For a UE which is involved simultaneously in a CS voice call and a PS connection the
CS voice inter-RAT handover procedure is applicable.
Upon a cell change order failure the PS connection is further served by the UMTS
network depending on the radio conditions.
In general the UMTS to GSM Cell Change Order procedure can be separated in the
following steps:
1. Decision to perform Cell Change Order and target cell determination
2. Cell Change Order execution involving also the UE
3. Release of UMTS resources.
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting PS UMTS to GSM (inter-RAT) Cell Change Order
procedure
PS UMTS to GSM Cell Change Order signaling flow
Serving
UE RNC SGSN
1. UTRAN decision to perform Cell Change Order from UTRAN:

PS connection only, Cell_DCH or Cell_FACH
Regard for “Service Handover”
Measurement based (MAHO: 2d, 2f, 3a, 3c; DAHO: 2d)
2. Cell Change Order from UTRAN

RRC RRC
3. The UE accesses the GSM

system and initiates routing
area update. The packet context
is transferred to the new SGSN 4. SRNS Context Request
RANAP RANAP
5. SRNS Context Response

RANAP RANAP
6. Iu Release Command
RANAP RANAP
7. Iu Release Complete
RANAP RANAP
Success rate KPIs

The following KPIs provide an indication of the success rate for UMTS to GSM
handover:
• PS IRAT HO Success Rate (UMTS -> GSM)
This KPI measures the percentage of Cell Change Order from UTRAN procedures
successfully completed.
• PS UMTS to GSM HHO Inter RAT Success Rate - RSCP only
This KPI indicates the percentage of Cell Change Order from UTRAN procedures
successfully completed based on RSCP measurement only.
....................................................................................................................................................................................................................................
procedure
Matrix KPIs
For UMTS to GSM optimization, but also for specific troubleshooting, there are
special handover Matrix PM counters available. Different to other PMs, these Matrix
PM counters are provided on a per originating UMTS cell to relevant terminating GSM
target cell basis.
The UMTS to GSM Handover Matrix PMs VS.MX.IRATHO.OutPSUTRAN.<type> PS
Hard Handover Inter RAT Success Rate per GSM Neighbour Cell help to locate
problems between UMTS and GSM cells by providing the number of handover
attempts and failures from the UMTS originating cell to relevant GSM target cells. The
counter is only available for those GSM cells that are a target for handover in the
reporting period and are reported on a daily basis.
UMTS to GSM Cell Change Order failures

Components that constitute failures of UMTS to GSM handover may be classified as
follows:
1. The UE returns to UMTS with a failure indication
2. The procedure times out
Related PMs / KPIs

• PS Hard Handover Inter RAT Success Rate per GSM Neighbour Cell:
– VS.MX.IRATHO.OutPSUTRAN.Att
– VS.MX.IRATHO.OutPSUTRAN.FailTimeout
– VS.MX.IRATHO.OutPSUTRAN.Ncell_CI
– VS.MX.IRATHO.OutPSUTRAN.Ncell_LAC
– VS.MX.IRATHO.OutPSUTRAN.Ncell_MCC
– VS.MX.IRATHO.OutPSUTRAN.Ncell_MNC
• PS IRAT HO Success Rate (UMTS -> GSM)
• Likely Dropped Call Rate in Target System during PS Inter RAT Hard Handover
• PS UMTS to GSM HHO Inter RAT Success Rate - RSCP only
....................................................................................................................................................................................................................................

troubleshooting
...................................................................................................................................................................................................................................
Introduction
Cell Change Order from UTRAN failures occur when the Cell Change Order from
UTRAN command was sent to the UE and the UE either returns with a failure
message to UMTS or the procedures times out.
Failure causes
• Expiry of the cell change order procedure supervision timer
• Cell Change Order from UTRAN Failure.
Expiry of the Cell Change Order procedure supervision timer

On transmission of the Cell Change Order from UTRAN command to the UE the RNC
starts the timer cellChangeOrderFromUTRANSupervisionTimer. If neither the Iu
connection is released by the SGSN nor the UE returns with Cell Change Order from
UTRAN Failure before the timer expires, then the Iu connection release is initiated by
the RNC. In case of procedure timeout the UTRAN has no knowledge if the call was
successfully established in GSM or the call was dropped.
The Cell Change Order procedure time includes the time needed for the UE to access
the GSM cell, optionally perform location area update, perform routing area update and
security procedures. All in all several seconds are needed. If the procedure timeout
occurs it should be verified that the parameter cellChangeOrderFromUTRANSu-
pervisionTime is set to a sufficiently high value. Also some resources are occupied a
little bit longer in UMTS in case of failure, there is no drawback of a higher
cellChangeOrderFromUTRANSupervisionTime.
Another cause for this failure could be that the UE has moved out of UMTS coverage
and the call has dropped before the Cell Change Order command was sent to the UE
or the UE could not return to UMTS with a Cell Change Order from UTRAN Failure
message. If this occurs then the Cell Change Order should be initiated earlier by
increasing the threshold values.
The counter VS.IRATHO.TimeoutOutPSUTRAN pegs the procedure timeout on expiry
of the cellChangeOrderFromUTRANSupervisionTimer.
...................................................................................................................................................................................................................................
troubleshooting
The most likely failure cause is that there are network configuration issues in the core
network between GSM and 3G SGSN. Typical causes are:
• the trunks between the SGSNs are not configured correctly
• the 2G SGSN does not know which 3G SGSN to contact, or
• security procedure issues within the GSM system
Cell Change Order from UTRAN Failure

On receipt of a Cell Change from UTRAN Failure message from the UE, the RNC
maintains the call in UMTS. The next Cell Change Order is attempted after
cellChangeOrderFromUTRANRepetitionTime if the conditions for a Cell Change to
GSM are still fulfilled.
Failure causes
The failure causes that are pegged separately are as follows:
• Unacceptable configuration
• Protocol error.
The counter IRATHO.FailOutPSUTRAN.sum includes all the failure causes occurred
along the receipt of Cell Change Order from UTRAN Failure message from the UE.
Physical channel failure

The physical channel failure cause occurs when the UE cannot access the target GSM.
This is mainly caused by poor RF conditions. The PM counter IRATHO.FailOutP-
SUTRAN.PhyChnFail will be incremented.
Unacceptable configuration / protocol Error

“Unacceptable configuration” and “protocol error” are expected to occur rarely and in
general they are not related to RF issues. These are pegged by the PM counters
IRATHO.FailOutPSUTRAN.ConfUnaccept and IRATHO.FailOutPSUTRAN.ProtErr.
Related PMs / KPIs

• IRATHO.FailOutPSUTRAN.sum
• IRATHO.FailOutPSUTRAN.ConfUnaccept
• IRATHO.FailOutPSUTRAN.PhyChnFail
• IRATHO.FailOutPSUTRAN.ProtErr
• VS.IRATHO.TimeoutOutPSUTRAN
....................................................................................................................................................................................................................................
Serving HS-DSCH Cell Change
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides Serving HS-DSCH Cell Change procedure and troubleshooting
information.
Contents
Serving HS-DSCH Cell Change procedure 10-40

Serving HS-DSCH Cell Change troubleshooting 10-43
...................................................................................................................................................................................................................................
Serving HS-DSCH Cell Change procedure

...................................................................................................................................................................................................................................
Introduction
Serving HS-DSCH Cell Change is supported in current Alcatel-Lucent UMTS Release
for HSDPA calls. When the best cell within the active set changes to another cell then
the Serving HS-DSCH Cell Change procedure is performed. The procedure involves a
hard handover of the serving HS-DSCH cell while the active set remains unchanged.
Serving HS-DSCH Cell Change procedure

In case of Serving HS-DSCH Cell Change UTRAN and UE switch synchronously the
HS-DSCH channel from the old best cell to the new best cell while keeping the active
set unchanged. The procedure is triggered by the receipt of a event 1d or receipt of
event 1b or 1c where the serving HS-DSCH link is to be removed from the active set.
Upon a Serving HS-DSCH Cell Change failure the call is reconfigured to DCH (R99),
if possible, to further maintain the call in UMTS.
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Serving HS-DSCH Cell Change procedure
Serving HS-DSCH Cell Change signaling flows (example for inter-NodeB serving cell change)
S-RNC
Target Source =
UE HS-DSCH cell HS-DSCH cell C-RNC
Serving HS-DSCH
For example, Event 1D
cell change decision
RL Reconfig Prepare
RL Reconfig Prepare
RL Reconfig Ready
RL Reconfig Ready
ALCAP Iub HS-DSCH Data Transport Bearer Setup New NodeB
Transport Channel Reconfiguration

Synchronous
Reconfigure
RL Reconfig Commit
RL Reconfig Commit
Transport Channel Reconfiguration

Reset MAC-hs
entity
DATA
ALCAP Iub HS-DSCH

Data Transfer Bearer
Release
Success rate KPIs

Following KPI provides an indication of the success rate for Serving HS-DSCH Cell
Change:
• HS-DSCH Cell Change Success Rate
This KPI measures the percentage of Serving HS-DSCH Cell Change procedures
successfully completed.
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Serving HS-DSCH Cell Change procedure
Serving HS-DSCH Cell Change failures

Components that constitute failures of Serving HS-DSCH Cell Change may be
classified as follows:
1. The UE transmits a failure indication
2. The procedure times out
Related PMs / KPIs

• HS-DSCH Cell Change Success Rate
....................................................................................................................................................................................................................................
Serving HS-DSCH Cell Change troubleshooting

...................................................................................................................................................................................................................................
Introduction
Serving HS-DSCH Cell Change failures occur when RRC reconfiguration command
was sent to the UE and the UE either replies with a failure message or the procedures
times out.
Failure causes
• Expiry of the Serving HS-DSCH Cell Change supervision timer
• RRC Reconfiguration Failure
Expiry of the Serving HS-DSCH Cell Change supervision timer

On transmission of the RRC Reconfiguration command to the UE the RNC starts the
timer tSynchTranChanComplete. If neither a RRC Reconfiguration Complete nor
Failure message is received from the UE before the timer expires, then the Iu
connection release is initiated by the RNC
RRC Reconfiguration Failure

On receipt of a RRC Reconfiguration Failure message from the UE, the RNC
reconfigures the call to DCH (R99), if possible, to further maintain the call in UMTS.
Related PMs / KPIs

• VS.AttServCellChangeHSDSCH
• VS.FailServCellChangeHSDSCH.sum
• VS.FailServCellChangeHSDSCH.TransChnReconfigFail
• VS.FailServCellChangeHSDSCH.TransChnReconfigTout
• Successful Serving HS-DSCH Cell Changes
...................................................................................................................................................................................................................................
Inter-frequency hard handover and troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides Inter-frequency hard handover and hard handover troubleshooting
information.
Contents
Inter-frequency hard handover procedure 10-45

Hard handover troubleshooting 10-50
UE reject 10-55
...................................................................................................................................................................................................................................
Inter-frequency hard handover procedure

...................................................................................................................................................................................................................................
Introduction
Inter-frequency hard handover (HHO) is particularly needed to change frequencies
within a UMTS network. Generally, changing of frequencies cannot be done
seamlessly due to limitations in the mobile and in the radio access network. Thus a
break in the bearer occurs whenever an inter-frequency HHO is performed.
In the current release Inter-frequency HHO is triggered due to quality and due to load.
If the signal quality in inter-frequency HHO border cells becomes too low, quality
based inter-frequency HHO may be used to transfer the call to another UMTS
frequency providing better quality. If the load in an UMTS cell becomes too high, load
based inter-frequency HHO may be used to transfer the call to another UMTS cell on
another frequency with less load.
The handover algorithms are:
• mobile assisted handover (MAHO), i.e. based on measurements and data base
assisted handover, and
• data base assisted handover (DAHO), i.e. based on configuration data
They are used for quality and load based inter-frequency HHO. If both, MAHO and
DAHO are applicable, preference is given to MAHO.
Inter-frequency HHO is performed for circuit switched calls, packet switched calls as
well as for the combination of both.
Inter-frequency HHO measurements

One or more of the inter-frequency measurement events 2B, 2C, 2D and 2F are setup
in the UE dependent on the used inter-frequency HHO algorithm.
Quality based inter-frequency HHO (MAHO) w/o compressed mode
1. Measurement 2B is setup in the UE. On receipt of measurement 2B from the UE,
inter-frequency HHO procedure is triggered.
Quality based inter-frequency HHO (MAHO) w/ compressed mode
1. Measurement 2D is setup in the UE to determine the signal quality
2. On receipt of measurement 2D, if the signal quality is weak, measurement 2D is
stopped and measurement 2B and 2F are setup
3. On receipt of measurement 2F, if the signal quality is strong again, measurement
2B and 2F are stopped and measurement 2D is setup again
4. On receipt of measurement 2B from the UE, inter-frequency HHO procedure is
triggered.
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Inter-frequency hard handover procedure
Quality based inter-frequency HHO (DAHO)

1. Measurement 2D is setup in the UE. On receipt of measurement 2D from the UE,
Load based inter-frequency HHO (MAHO)
1. Measurement 2C is setup in the UE. On receipt of measurement 2C from the UE,
Load based inter-frequency HHO (DAHO)
1. No Measurements are setup in the UE. If the load in the cell on current used
frequency is too high, inter-frequency HHO procedure is triggered
Inter-frequency hard handover signaling flow
UE old Node B new Node B SRNC
Measurement Report Event 2B

1
1. Radio Link Setup Request
2. Radio Link Setup Response 2

3. ALCAP Iub Transport Bearer Setup
4. Physical Channel Reconfiguration
5. UE Detected
3
6. Physical Channel Reconfiguration Complete
7. Radio Link Deletion Request
8. Radio Link Deletion Response

4
9. ALCAP Iub Transport Bearer Release
The hard handover procedure steps for UE in Cell_DCH state are:

1. Initiate hard handover when any trigger condition described above applies
2. Set up resources on the new frequency in the UTRAN via NBAP procedure
....................................................................................................................................................................................................................................
3. Execute hard handover towards UE:

•
via RRC physical channel re-configuration procedure for DCH to DCH
handover, or
• via transport channel re-configuration procedure for HSDSCH to HSDSCH or
HSDSCH/E-DCH to HSDSCH/E-DCH handover.
The hard handover procedure is successfully executed on receipt of a RRC physical
channel reconfiguration complete or transport channel reconfiguration complete
message at the RNC.
4. Clear resources on the old frequency in the UTRAN via NBAP procedure. The
entire procedure is supervised by the inter-frequency hard handover procedure
timer.
Hard handover scenarios

In the current release, Inter-Frequency hard handovers can be executed for following
configurations:
• Intra Node B handover
• Inter Node B / Intra-RNC handover
• Inter-RNC handover (quality based only and DCH to DCH only).
In case of more than one RNC being involved a functional split leading to different
RNC roles is applied as follows:
• The controlling RNC (CRNC) provides the Iub Interface towards Node B and
controls the setup, addition and release of radio links with NBAP signalling
• The serving RNC (SRNC) provides the Iu Interface towards core network (CN) and
the Uu Interface towards UE for the actual connection. Depending on the actual
configuration the SRNC provides the Iur interface(s) towards drift RNC(s) and/or
the Iub Interface(s) towards Node B(s).
The SRNC controls the measurements to be performed by the UE. On reception of
measurement reports the SRNC initiates and controls the handover protocol with
RRC, RNSAP and NBAP signalling. It acts as CRNC for Node B(s) directly
connected and controls the CRNC functions at a drift RNC for Node B(s) not
directly connected.
• The drift RNC (DRNC) acts as CRNC. It performs the CRNC functions in
accordance to requests of the SRNC and reports the results.
Note: Intra Node B handover or Inter Node B / Intra-RNC handover may take place
either within the SRNC or within a DRNC
Hard handover over Iur

In case of Inter-RNC hard handover or in case of Intra Node B - or Inter Node B
handover within a DRNC the procedure is executed in the same way as where SRNC
is executing physical channel or transport channel reconfiguration procedure (step 3)
....................................................................................................................................................................................................................................
while DRNC is taking care of the NBAP procedures (steps 2 and 4) initiated by the
SRNC through the Iur interface via corresponding Radio Network Subsystem
Application Part (RNSAP) procedures.
Inter-frequency hard handover towards a target cell which is controlled by a DRNC is
only applicable for quality based DCH to DCH handover.
The figure below shows the all-embracing successful inter-frequency handover
procedure (DCH to DCH) for inter Node B, Inter-RNC case. Two DRNCs and the
SRNC are involved. The description can be reduced to the various network scenarios
given above by allocating the CRNC to the SRNC or to the DRNC respectively. If the
CRNC is at the SRNC, then the RNSAP procedures 1, 5, 6 and/or 10, 14, 15 can be
omitted.
....................................................................................................................................................................................................................................
UE Node B old Node B new DRNC old DRNC new SRNC
Measurements and Handover Decision
1. Radio Link
2. Radio Link Setup Request Setup Request
3. Radio Link Setup Response
4. ALCAP Iub Transport Bearer Setup
5. Radio Link Setup
6. ALCAP Iur
Transport Bearer Setup
7. Physical Channel Reconfiguration
8. UE Detected
9. Physical Channel Reconfiguration Complete
13. ALCAP Iub Transport Bearer Release
15. ALCAP Iur Transport Bearer Release
....................................................................................................................................................................................................................................
Hard handover troubleshooting

...................................................................................................................................................................................................................................
Introduction
In general failures that occur during this procedure result in an increase of interference
in the system. This may have an impact on the call reliability by causing dropped calls
as well as causing degradations of either the voice call quality or the packet session
performances.
The major HHO failure components

The major components that constitute failures of both Intra-RNC and Inter-RNC Hard
handover are:
• Poor RF conditions
• Incorrect translations settings
• No Node B resources available
• No transport resources available
• No UE answer
• UE Reject
• Node B / RNC outages
• Iub, Iur link outages
• Iur configuration to drift RNC.
Intra/Inter RNC HHO PMs/KPIs

Intra RNC HHO is defined as HHO between cells controlled by the same RNC. Inter
RNC HHO involves a DRNC and may be performed between SRNC and DRNC or
between two DRNCs.
With respect to setting up the resources in UTRAN (step 2 of the interworking
inter-frequency HHO procedure) the counters which are already defined for soft
handover radio link performance measurement are reused for hard handover. In detail
the following are reused:
Attempted, successful and failed radio link setups on Iub:
• RLM.AttRLSetupIub
• RLM.AttRLSetupIub.CSV
• RLM.AttRLSetupIub.CSD
• RLM.AttRLSetupIub.PSD
• RLM.SuccRLSetupIub
• RLM.FailRLSetupIub.NodeBRes.CSV
• RLM.FailRLSetupIub.NodeBRes.CSD
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Hard handover troubleshooting
• RLM.FailRLSetupIub.NodeBRes.PSD
• RLM.FailRLSetupIub.TransRes.CSV
• RLM.FailRLSetupIub.TransRes.CSD
• RLM.FailRLSetupIub.TransRes.PSD
Attempted and failed radio link additions on Iub:
• RLM.AttRLAddIub
• RLM.AttRLAddIub.CSV
• RLM.AttRLAddIub.CSD
• RLM.AttRLAddIub.PSD
• RLM.SuccRLAddIub
• RLM.FailRLAddIub.NodeBRes.CSV
• RLM.FailRLAddIub.NodeBRes.CSD
• RLM.FailRLAddIub.NodeBRes.PSD
• RLM.FailRLAddIub.TransRes.CSV
• RLM.FailRLAddIub.TransRes.CSD
• RLM.FailRLAddIub.TransRes.PSD
Attempted and failed radio link setups on Iur:
• RLM.AttRLSetupIur
• RLM.FailRLSetupIur.sum
• RLM.FailRLSetupIur.TransRes
Attempted and failed radio link additions on Iur:
• RLM.AttRLAddIur
• RLM.FailRLAddIur.sum
• RLM.FailRLAddIur.TransRes
Note: The latter counters are used when both source and target cell are located at the
DRNC. In this case a radio link addition procedure is performed on the Iur Interface.
Furthermore the following hard handover specific counters are used in step 2:
• VS.HHO.AttPrepOutInterFreq.Qual
Attempted preparations for outgoing inter-frequency hard handovers due to quality
• VS.HHO.AttPrepOutInterFreq.Load
Attempted preparations for outgoing inter-frequency hard handovers due to load
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Hard handover troubleshooting
With respect to hard handover execution (step 3 of the interworking inter-frequency

HHO procedure) the following hard handover specific counters are used:
• HHO.AttOutInterFreq.Qual
Attempted outgoing inter-frequency hard handovers due to quality
• HHO.SuccOutInterFreq.Qual
Successful outgoing inter-frequency hard handovers due to quality
• Failed outgoing inter-frequency hard handovers due to quality:
– HHO.FailOutInterFreq.Qual.ConfigUnsupported
– HHO.FailOutInterFreq.Qual.PhysChanFail
– HHO.FailOutInterFreq.Qual.ProtErr
• HHO.AttOutInterFreq.Load
Attempted outgoing inter-frequency hard handovers due to load
• HHO.SuccOutInterFreq.Load
Successful outgoing inter-frequency hard handovers due to load
• Failed inter-frequency hard handovers due to load:
– HHO.FailOutInterFreq.Load.ConfigUnsupported
– HHO.FailOutInterFreq.Load.PhysChanFail
– HHO.FailOutInterFreq.Load.ProtErr
These quality related counters (*.Qual) are applied on per cell basis in case of intra
RNC handover and on per PRNC basis in case of inter RNC handover. The load
related counters (*.Load) are applied on per cell basis only.
If the inter-frequency hard handover procedure timer expires while step 3 is in
progress, then the following hard handover specific counters are used for CS- or PS -
RABs respectively:
• VS.RAB.Drop.CS.InterFreqHHO
Number of dropped CS RABs due to inter-frequency hard handover
• VS.RAB.Drop.PS.InterFreqHHO
Number of dropped PS RABs due to inter-frequency hard handover
In order to be able to analyze the handover performance with respect to neighbor cell
relations the following matrix counters are used. The number of attempted and
successful inter-frequency hard handover per neighbor cell from the current best cell:
• HHO.InterFreqPerNCell.Ncell_MCC
• HHO.InterFreqPerNCell.Ncell_MNC
• HHO.InterFreqPerNCell.Ncell_LAC
• HHO.InterFreqPerNCell.Ncell_CI
• HHO.InterFreqPerNCell.Att
• HHO.InterFreqPerNCell.Succ
....................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

The Node B may reject the resource allocation request due to no physical resources
available. This kind of failure indicates that there are capacity issues in specific areas
of the network. As CAC and DBC thresholds ensure enough radio capacity for SHO
resources, this may be caused by either too many overlapping pilots or by an improper
setting of some of the SHO algorithm parameters.
...................................................................................................................................................................................................................................
No transport resources available

...................................................................................................................................................................................................................................
Introduction
The NBAP / RNSAP radio link setup and radio link addition procedure may fail due to
no transport resources available, this means no Iub/Iur links are available due to
maximum supported capacity reached.
...................................................................................................................................................................................................................................
UE reject
...................................................................................................................................................................................................................................
Introduction
Upon sending the physical channel reconfiguration or transport channel reconfiguration
message in the case of failure the RNC receives the physical channel reconfiguration
failure or transport channel reconfiguration failure message from the UE respectively.
In this case the UE returns to the old channel configuration.
Failure causes
The UE Failure causes are:
• Configuration unsupported
• Protocol error.
Related PMs / KPIs

The related PMs / KPIs due to quality based handover are:
• HHO.FailInterFreq.Qual.ConfigUnsupported
• HHO.FailInterFreq.Qual.PhysChanFail
• HHO.FailInterFreq.Qual.ProtErr
The related PMs/KPIs due to load based handover are:
• HHO.FailInterFreq.Load.ConfigUnsupported
• HHO.FailInterFreq.Load.PhysChanFail
• HHO.FailInterFreq.Load.ProtErr
...................................................................................................................................................................................................................................
Inter-system directed retry
Overview
...................................................................................................................................................................................................................................
Purpose
This section provides inter-system directed retry optimization and troubleshooting
information
Contents
Inter-system directed retry procedure 10-57

Inter-system directed retry troubleshooting 10-60
...................................................................................................................................................................................................................................
Inter-system directed retry procedure

...................................................................................................................................................................................................................................
Introduction
Directed retry combines RAB assignment with hard handover. The RAB assignment
during call setup is avoided in UMTS and shifted to GSM instead. The original RAB
assignment procedure only provides the trigger for the UMTS-to-GSM handover and
will not be executed. The subsequent handover procedure implicitly performs the
traffic channel assignment functions within GSM. In the current release inter-system
directed retry is supported for emergency calls. Furthermore it is supported for WPS
calls in case of congestion.
...................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Inter-system directed retry procedure
Inter-system directed retry signaling flow
UE Node B BTS DRNC SRNC BSC 3G-MSC 2G-MSC

1. Rab Assignment Request
Decision for Directed Retry

1
2. RAB Assignment Response
Cause: Directed Retry
3. RAB Assignment Response

Cause: Directed Retry
Map-prep-HO req.
Handover Request
(incl. GSM HO Command)
Channel Activation
Channel Activation Ack.
Handover Request Ack. 2

Map Prep
Handover resp.
IAM
Relocation Command ACM

Handover from UTRAN Command
Handover Access
Handover Detect
Handover Detect
Physical Information
SABM
UA
3
Establish Indication
Map-PrAcc Signal
Handover Complete
Handover Complete
Radio Link Failure Indication
Map Send
End Signal
6. IU Release Command
7. ALCAP Iu Transport B Release

8. RL Delete
Request
ANM
4
11. ALCAP Iub Transport B Release
8. RL Delete
Response
14. IU Release Complete
13. ALCAP Iur Transport B Release
....................................................................................................................................................................................................................................
Call mobility optimization and troubleshooting Inter-system directed retry procedure
Inter-system directed retry procedure

The inter-system directed retry procedure steps are:
1. Decision to perform directed retry
2. Relocation preparation procedure with setup of resources in GSM
3. Handover execution via handover to UTRAN procedure
4. Clear resources in the UTRAN via NBAP procedure.
....................................................................................................................................................................................................................................
Inter-system directed retry troubleshooting

...................................................................................................................................................................................................................................
Introduction
The functions for troubleshooting in case of directed retry are essentially the same as
for UMTS-to-GSM handover (refer to the respective sections). Only during the
relocation preparation procedure specific directed retry PMs are used.
Directed retry PMs/KPIs

During the relocation preparation procedure the following specific directed retry PMs
are used:
• VS.IRATHO.AttRelocPrep.DirRetry
Attempted relocation preparations for inter-system directed retry
• VS.IRATHO.SuccRelocPrep.DirRetry
Successful relocation preparations for inter-system directed retry
• Failed relocation preparation for inter-system directed retry for the following causes
from network point of view:
– VS.IRATHO.FailRelocPrep.DirRetry.T_RELOCprep_exp
(For the cause, “T_RELOCprep expiry”
– VS.IRATHO.FailRelocPrep.DirRetry.FailTarSys
(For the cause, “relocation failure in target system”)
– VS.IRATHO.FailRelocPrep.DirRetry.NotSupTarSys
(For the cause, “relocation not supported in target system”)
– VS.IRATHO.FailRelocPrep.DirRetry.TarNotAllowed
(For the cause, “relocation target not allowed”)
– VS.IRATHO.FailRelocPrep.DirRetry.NoRRTarSys
(For the cause, “no radio resources available in target cell”)
– VS.IRATHO.FailRelocPrep.DirRetry.IncompRxState
(For the cause, “ message not compatible with receiver state”)
When the directed retry procedure is completed successfully then the following specific
directed retry PM is used:
• VS.IRATHO.SuccOutCS.DirRetry
Successful Inter-System UMTS to GSM Directed Retry
...................................................................................................................................................................................................................................
11 11
Throughput optimization and
troubleshooting
Overview
...................................................................................................................................................................................................................................
Purpose
be used to measure the throughput for the various uplink and downlink speeds and can
provide an analysis to optimization related issues.
Contents
Throughput optimization 11-2
...................................................................................................................................................................................................................................
Throughput optimization and troubleshooting
Throughput optimization
...................................................................................................................................................................................................................................
RLC SDU Throughput and Data volume

Radio Link Control (RLC) is the layer two protocols used in 3G UMTS cellular
systems for flow control and error recovery. In the layered architecture of UMTS radio
interface protocols, RLC sits above the MAC (Medium Access Control) layer, which
handles the scheduling of radio bearers with different QoS requirements, and below the
RRC (Radio Resource Control) layer, which is responsible for setting up, modifying
and releasing all the lower layer protocol entities. Higher layer data packets, or SDUs
(Service Data Units) are segmented into RLC PDUs (Protocol Data Units). The RLC
PDU size is set according to the lowest possible bit rate for the services using RLC. In
case of small SDUs, several SDUs can be concatenated into one RLC PDU. At the
receiving end, the PDUs that contain fragments of an SDU are reassembled and the
SDU is delivered to the higher layer.
The Alcatel-Lucent throughput KPIs measure at the RLC SDU layer. Total throughput
on the RLC SDU layer for the uplink and downlink on a RNC level are available from
the VS.Datarate.xx.xx PMs. The Data volume indicators which calculate using the
Datarate PMs are more useful to study the amount of data that has been transferred,
since the throughput numbers from PM counters show only a mean value which
includes silence periods in the 15 minute interval. Metrics are available for HSDPA,
EDCH and Non-HSDPA packet calls for the downlink and uplink. Individual downlink
throughput for bearer rates of 16kbps, 32kbps, 64kbps, 128kbps and 384kbps can be
seen from the PM, VS.Datarate.PSxxDL and uplink throughput for bearer rates of 16
kbps, 32kbps, 64kbps, 128kbps and 384kbps by VS.Datarate.PSxxUL. The KPI,
HSDPA - data volume on RLC SDU provides the data volume on Uu after compression
by Packet Data Convergence Protocol. The metric UL E-DCH - data volume on RLC
SDU provides the data volume on the EDCH (uplink) at the RLC SDU layer
calculating the payload bits included in the RLC PDU received from the NodeB. All
the above mentioned indicators and PMs are calculated on an RNC basis.
Lower throughput or data volume values could be due to various reasons such as poor
signal strength and interference. In such cases drive tests in the affected area would
provide insight into the problem. There could also be issues due to power control and
Dynamic Bearer Control (DBC) parameter settings, which would need to be optimized.
In some cases the user profile configurations for the various QoS negotiated could also
lead to lower throughput, which would require the profiles to be reconfigured in the
core network. Iub and Iur issues could also lead to lower throughputs.
Related PMs and KPIs
• Total DL - data volume on RLC SDU
• DL non-HSDPA - data volume on RLC SDU
• HSDPA - data volume on RLC SDU
...................................................................................................................................................................................................................................
Throughput optimization and troubleshooting Throughput optimization
• DL 64 kbps - data volume on RLC SDU

• DL 128kbps - data volume on RLC SDU
• DL 384kbps - data volume on RLC SDU
• Total UL - data volume on RLC SDU
• UL E-DCH - data volume on RLC SDU
• UL 64 kbps - data volume on RLC SDU
QoS Based Throughput

Downlink throughput at the RLC SDU layer based on QoS type can be measured by
the following PMs on a per RNC basis:
• VS.DataRate.PSDLIntact.DCH
• VS.DataRate.PSDLBgrd.DCH
• VS.DataRate.PSDLStrm.DCH
• VS.DataRate.PSDLIntact.HSDSCH
• VS.DataRate.PSDLBgrd.HSDSCH
Similar PMs are available in the uplink for the RNC:
• VS.DataRate.PSULStrm
• VS.DataRate.PSULIntact.DCH
• VS.DataRate.PSULBgrd.DCH
• VS.DataRate.PSULIntact.EDCH
• VS.DataRate.PSULBgrd.EDCH
If lower throughput is observed from these indicators then the user profile settings for
the various QoS classes may need to be optimized at the core network. However a
study of the radio conditions, RLC, DBC, Power control parameters and value of other
throughput indicators will need to be investigated in tandem to derive an accurate
analysis of the possible reasons.
Weighted Random Early Discard throughput measurements

Throughput is regulated through the Weighted Random Early Discard (WRED)
mechanism when the RNC processors are congested. Random packets are discarded to
reduce the load on the RNC and as a consequence the throughput experienced by the
subscriber will be affected. The total number of payload bits in the PDU discarded are
aggregated and divided by the number of seconds in the granularity period and the lost
throughput is reported through these counters. A large value for these PMs will require
detailed planning steps to alleviate load on the RNCs. The counters are pegged for the
...................................................................................................................................................................................................................................
Throughput optimization and troubleshooting Throughput optimization
throughput lost for the different QoS classes for uplink and downlink packet calls.
These measurements can be studied with the RNC processor load measurements to get
a good picture of the situation.
Related measurements
• VS.DataRate.PSDL.IntAct.DiscardWRED
• VS.DataRate.PSDL.Bgrd.DiscardWRED
• VS.DataRate.PSDL.Strm.DiscardWRED
• VS.DataRate.PSUL.IntAct.DiscardWRED
• VS.DataRate.PSUL.Bgrd.DiscardWRED
• VS.DataRate.PSUL.Strm.DiscardWRED
• VS.PO.BSCCP.Mean
• VS.PO.BSCOAM.Mean
• VS.PO.TPUCP.Mean
• VS.PO.TPUSP.Mean
• VS.PO.TPUTP.Mean
• VS.PO.TPUGICCP1.Mean
• VS.PO.TPUGICCP2.Mean
PS Data Throughput (Iu Interface)

The Mean Downlink Packet user data throughput on the IuPS interface can be
calculated by the KPI, DL mean user data rate received on PS CN. The data rate of
discarded DL user bits on the IuPS is calculated by recording the discarded Traffic
PDUs and can be measured using DL discarded data rate received on PS CN.
Related PMs / KPIs
• DL mean user data rate received on PS CN
• DL discarded data rate received on PS CN
...................................................................................................................................................................................................................................
Glossary
....................................................................................................................................................................................................................................
Numerics
3GPP
3rd Generation Partnership Project
....................................................................................................................................................................................................................................
A AAL
Asynchronous Transfer Mode Adaptation Layer
AICH
Acquisition Indicator Chanel
ALCAP
Access Link Control Application Protocol
AM
Acknowledged Mode
ARQ
Autromatic Repeat Request
ATM
Asynchronous Transmission Mode
....................................................................................................................................................................................................................................
B BCCH
Broadcast Control Channel
BCH
Broadcast Channel
BLER
Blocking Error Rate
....................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary GL-1
Glossary
BMC
Broadcast/Multicast Control
....................................................................................................................................................................................................................................
C CAC
Call Admission Control
CC
Call Control
CCCH
Common Control Channel
CCPCH
Common Control Physical Channel
CDMA
Code Division Multiple Access
CFN
Connection Frame Number
CPCH
Common Packet Channel
CPICH
Common Pilot Channel
CRNC
Controlling Radio Network Controller
CS
Circuit Switched domain
CTCH
Common Traffic Channel
....................................................................................................................................................................................................................................
D DBC
Dynamic Bearer Control
DC
Dedicated Control
DCCH
Dedicated Control Channel
...................................................................................................................................................................................................................................
GL-2 Alcatel-Lucent - Proprietary 401-382-810R5.1
Glossary
DCH
Dedicated Channel
DL
DownLink
DPCCH
Dedicated Physical Control Channel
DPCH
Dedicated Physical Channel
DPDCH
Dedicated Physical Data Channel
DRNC
Drift Radio Network Controller
DSCH
Downlink Shared Channel
DTCH
Dedicated Traffic Channel
....................................................................................................................................................................................................................................
E E2E
End-to-End
Ec/Io
Signal to Noise ratio
....................................................................................................................................................................................................................................
F FACH
Forward Access Channel
FBI
FeedBack Information
FDD
Frequency Division Duplex
FP
Frame Protocol
....................................................................................................................................................................................................................................
G GC
General Control
...................................................................................................................................................................................................................................
Glossary
GPRS
General Packet Radio Service
GPS
Global Positioning System
GSM
Global System for Mobile communications
GTP
GPRS Tunnelling Protocol
....................................................................................................................................................................................................................................
I IP
Internet Protocol
IRAT
Inter-Radio Access Technology
....................................................................................................................................................................................................................................
K KPI
Key Performance Indicator
....................................................................................................................................................................................................................................
L LA
Location Area
LCAT
Lucent Cells Application Tool
LDAT3G
Lucent Data Analysis Tool for 3G
....................................................................................................................................................................................................................................
M MAC
MAC-b
Broadcast Medium Access Control
MAC-c/sh
Common Medium Access Control
MAC-d
Dedicated Medium Access Control
...................................................................................................................................................................................................................................
Glossary
MM
Mobility Management
MO
Mobile Originated call
MSC
Mobile Switching Center
MT
Mobile Terminated call
MTP3
Message Transfer Protocol 3
....................................................................................................................................................................................................................................
N NAS
Network Access Server
NBAP
Node B Application Part
Nt
Notification
....................................................................................................................................................................................................................................
O OCNS
Orthogonal Channel Noise Simulation
OMC
Operation and Maintenance Center
OMC-UPS
OMC for the UTRAN and the Packet Core cluster
....................................................................................................................................................................................................................................
P P-CCPCH
Primary Common Control Physical Channel
P-CPICH
Primary Common Pilot Channel
P-SCH
Primary Synchronization Channel
PC
Personal Computer
...................................................................................................................................................................................................................................
Glossary
PCCH
Paging Control Channel
PCH
Paging Channel
PCPCH
Physical Common Packet Channel
PDCP
Packet Data Convergence Protocol
PDP
Packet Data Protocol
PDSCH
Physical Downlink Shared Channel
PDU
Packet Data Unit
PICH
Paging Indication Channel
PM
Performance Management
PMM
Packet Mobility Management
PRACH
Physical Random Access Channel
PS
Packet Switched domain
PSC
Primary Scrambling Code
....................................................................................................................................................................................................................................
Q QoS
Quality of Service
....................................................................................................................................................................................................................................
R RA
Routing Area
...................................................................................................................................................................................................................................
Glossary
RAB
Radio Access Bearer
RACH
Random Access Channel
RANAP
Radio Access Network Application Protocol
RB
Radio Bearer
RF
Radio Frequency
RLC
Radio Link Control
RLF
Radio Link Failure
RNC
Radio Network Controller
RNSAP
Radio Network Subsystem Application Part
RNTI
Radio Network Temporary Identity
RRC
RTP
Real-Time Protocol
....................................................................................................................................................................................................................................
S S-CCPCH
Secondary Common Control Physical Channel
S-CPICH
Secondary Common Pilot Channel
S-SCH
Secondary Synchronization Channel
SAAL
Signaling ATM Adaptation Layer
...................................................................................................................................................................................................................................
Glossary
SAP
Service Access Point
SCH
Synchronization Channel
SDU
Service Data Unit
SF
Spreading Factor
SGSN
Serving GPRS Support Node
SM
Session Management
SPAT3G
Service Performance Analysis Tool for 3G
SRNC
Serving Radio Network Controller
SSCF
Service Specific Coordination Function
SSCOP
Service Specific Connection Oriented Protocol
STM
Synchronous Transport Module
....................................................................................................................................................................................................................................
T TFC
Traffic Format Combination
TM
TRansparent Mode
TPC
Transmit Power Control
....................................................................................................................................................................................................................................
U UCU
UMTS Channel Unit
...................................................................................................................................................................................................................................
Glossary
UDP
User DAtagram Protocol
UE
User Equipment
UL
UpLink
UM
Unacknowledged Mode
UMSC
UMTS Mobile Switching Center
UMTS
Universal Mobile Telecommunication System
UNI
User-Network Interface
URA
UTRAN REgistration Area
USCH
Uplink Shared Channel
UTRAN
UMTS Terrestrial Radio Access Network
....................................................................................................................................................................................................................................
V VLR
Visitor Location Register
....................................................................................................................................................................................................................................
W WAG
Wireless Application Gateway
...................................................................................................................................................................................................................................
Index
A Access preliminary procedures, 7-8 Dropped calls analysis, 8-2

Average active set size, 10-7 Dropped RAB analysis due to congestion, 8-9
................................................................................................ Dynamic bearer control failures, 7-30
C Call admission control failures, 7-19 ................................................................................................
Call availability, 7-4 H Handover procedure troubleshooting, 10-32
Call mobility optimization and troubleshooting ................................................................................................
CS Voice GSM to UMTS (inter-RAT) handover I Idle mode, 3-38

and troubleshooting, 10-26
Inter-frequency hard handover procedure, 10-45
CS Voice UMTS to GSM (inter-RAT) handover
and troubleshooting, 10-18 Inter-system directed retry troubleshooting, 10-60
PS UMTS to GSM (inter-RAT) Cell Change Interfaces

Order and troubleshooting, 10-33 Iu-cs, 3-56
Serving HS-DSCH Cell Change, 10-39 Introduction to RRC connection establishment, 7-16
Soft/Softer handover and troubleshooting, 10-3 Iu-cs interface, 3-56
Cell re-selection failures, 7-9 ................................................................................................
Connected mode, 3-38 K Key performance indicators for UTRAN
CS IRAT HO success rate (UMTS -> GSM), 6-7 CS IRAT HO success rate (UMTS -> GSM), 6-7
CS Voice GSM to UMTS (inter-RAT) handover KPI, 1-2
procedure, 10-27
................................................................................................
CS Voice IRAT handover procedure
troubleshooting, 10-25 L Logical channels, 3-24
CS Voice relocation preparation procedure ................................................................................................

troubleshooting, 10-23
M MAC, 3-31
CS Voice UMTS to GSM (inter-RAT) handover
procedure, 10-19 Medium Access Control, 3-27
................................................................................................ ................................................................................................
D Determination of accessibility problem, 7-6 N Network layer, 3-35
No answer from UE, 7-33

....................................................................................................................................................................................................................................
401-382-810R5.1 Alcatel-Lucent - Proprietary IN-1
Index
No Node B resources available, 10-12, 10-53 ................................................................................................
No transport resources available, 10-13, 10-54 U UE reject, 10-15, 10-55

No UE answer, 10-14 Unlisted Set Cells, 10-16
................................................................................................
P Paging failures, 7-24
Physical channels, 3-13

procedure, 10-34
................................................................................................
Q Quality KPIs, 9-2
................................................................................................
R RAB establishment, 7-27
RACH access procedure failures, 7-11

Radio bearer establishment failures, 7-32
Radio link failures analysis due to synchronization
issues, 8-6
Radio link setup analysis, 7-21
Relocation resource allocation procedure
RLC, 3-31
RRC, 3-38
RRC connection setup failure, 7-23
................................................................................................
S Serving HS-DSCH Cell Change procedure, 10-40
Serving HS-DSCH Cell Change troubleshooting,

10-43
Soft handover troubleshooting, 10-9
Soft/softer handover procedure, 10-4
................................................................................................
T Throughput optimization, 11-2
Transport channels, 3-20
...................................................................................................................................................................................................................................
IN-2 Alcatel-Lucent - Proprietary 401-382-810R5.1

UMTS Optimization 5.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UMTS Optimization 5.1

Uploaded by

Copyright:

Available Formats

See notice on first age

Information product support

About this information product

Reason for reissue ....................................................................................................................................................................... xi

Intended audience ........................................................................................................................................................................ xi

How to use this information product ................................................................................................................................. xii

Conventions used ....................................................................................................................................................................... xii

Systems supported ..................................................................................................................................................................... xii

Related documentation ............................................................................................................................................................. xii

Related training ........................................................................................................................................................................... xii

How to comment ...................................................................................................................................................................... xiii

Part I: Optimization concepts

1 Information sources and tools

Overview ...................................................................................................................................................................................... 1-1

Key Performance Indicators ................................................................................................................................................. 1-2

Drive test ...................................................................................................................................................................................... 1-3

Customer complaints ............................................................................................................................................................... 1-6

OMC-UPS tools ........................................................................................................................................................................ 1-7

Overview ...................................................................................................................................................................................... 1-9

Data analysis software ......................................................................................................................................................... 1-10

Optimization and design tools .......................................................................................................................................... 1-13

2 Common optimization problems and their solutions

Overview ...................................................................................................................................................................................... 2-1

RF coverage problem .............................................................................................................................................................. 2-2

Cell breathing problem ........................................................................................................................................................... 2-4

Pilot pollution problem ........................................................................................................................................................... 2-6

Near-far problem ..................................................................................................................................................................... 2-8

Around-the-corner problem .................................................................................................................................................. 2-9

Handover problem ................................................................................................................................................................. 2-10

Missing neighbors problem ................................................................................................................................................ 2-11

Overview ...................................................................................................................................................................................... 3-1

Protocol architecture of the air interface

Overview ...................................................................................................................................................................................... 3-3

Protocols of the air interface ................................................................................................................................................ 3-4

Radio interface protocol architecture ................................................................................................................................ 3-6

Service access points ............................................................................................................................................................... 3-8

Air interface channels

Overview .................................................................................................................................................................................... 3-12

Physical channels ................................................................................................................................................................... 3-13

Transport channels ................................................................................................................................................................. 3-20

Logical channels ..................................................................................................................................................................... 3-24

Air interface protocols

Overview .................................................................................................................................................................................... 3-26

Medium Access Control .................................................................................................................................................... 3-27

Radio Link Control ................................................................................................................................................................ 3-31

Packet Data Convergence Protocol (PDCP) ............................................................................................................... 3-34

Radio Resource Control ...................................................................................................................................................... 3-35

RRC State Machine ............................................................................................................................................................... 3-38

RRC Connection and Signaling Connection ............................................................................................................... 3-39

Signaling radio bearers ........................................................................................................................................................ 3-40

Radio bearer establishment ................................................................................................................................................ 3-44

Overview .................................................................................................................................................................................... 3-48

Iub protocol structure ........................................................................................................................................................... 3-49

Protocols of the Iub interface ............................................................................................................................................ 3-51

Iur interface .............................................................................................................................................................................. 3-54

Iu-cs interface .......................................................................................................................................................................... 3-56

Part II: Optimization process

Overview ...................................................................................................................................................................................... 4-1

Network lifecycle ...................................................................................................................................................................... 4-2

Optimization process phases ................................................................................................................................................ 4-4

Planning and preparation (site readiness) ....................................................................................................................... 4-7

Drive test optimization before live traffic ...................................................................................................................... 4-9

Information gathering ........................................................................................................................................................... 4-11