umts optimization
DESCRIPTION
umts optiTRANSCRIPT
UMTSUTRAN OptimizationUMTS-04.03
401-382-810R04.03Issue 1
August 2007
Alcatel-Lucent - ProprietaryThis document contains proprietary information of Alcatel-Lucent and
is not to be disclosed or used except in accordance with applicable agreements.
Copyright © 2007 Alcatel-LucentUnpublished 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 theirrespective owners.
The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.
Copyright © 2007 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-940R04.03. To order documentation from an order entry representative, use one ofthe following numbers:
Within the United States, call +1-888-582-3688, or send email to [email protected] (to fax an order, call 1-800-566-9568).
Within Canada, call +1 317 322 6616, or send email to [email protected].
International, call +1 317 322 6616, or send email to [email protected] (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
See notice on first age
Alcatel-Lucent - ProprietarySee notice on first page
Contents
About this information product
Purpose............................................................................................................................................................................................ xixi
Reason for reissue....................................................................................................................................................................... xixi
Intended audience...................................................................................................................................................................... xiixii
How to use this information product................................................................................................................................ xiixii
Conventions used....................................................................................................................................................................... xiixii
Systems supported..................................................................................................................................................................... xiixii
Related documentation............................................................................................................................................................ xiixii
Related training.......................................................................................................................................................................... xiixii
How to comment...................................................................................................................................................................... xiiixiii
Part I: Optimization concepts
1 Introduction to optimization
Overview ...................................................................................................................................................................................... 1-11-1
What is optimization?............................................................................................................................................................. 1-21-2
Why optimize a network ?................................................................................................................................................... 1-41-4
When to optimize a network ?........................................................................................................................................... 1-61-6
2 Information sources and tools
Gathering information
Overview ...................................................................................................................................................................................... 2-12-1
Key Performance Indicators................................................................................................................................................ 2-22-2
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
iii
Drive test ..................................................................................................................................................................................... 2-32-3
Customer complaints............................................................................................................................................................... 2-62-6
OMC-UPS tools........................................................................................................................................................................ 2-72-7
Analyzing information
Overview ...................................................................................................................................................................................... 2-92-9
Data analysis software......................................................................................................................................................... 2-102-10
Optimization and design tools.......................................................................................................................................... 2-132-13
3 Common optimization problems and their solutions
Overview ...................................................................................................................................................................................... 3-13-1
RF coverage problem............................................................................................................................................................. 3-23-2
Cell breathing problem.......................................................................................................................................................... 3-43-4
Pilot pollution problem.......................................................................................................................................................... 3-63-6
Near-far problem ..................................................................................................................................................................... 3-83-8
Around-the-corner problem.................................................................................................................................................. 3-93-9
Handover problem................................................................................................................................................................. 3-103-10
Missing neighbors problem................................................................................................................................................ 3-113-11
4 UTRAN Signaling
Overview ...................................................................................................................................................................................... 4-14-1
Protocol architecture of the air interface
Overview ...................................................................................................................................................................................... 4-34-3
Protocols of the air interface............................................................................................................................................... 4-44-4
Radio interface protocol architecture............................................................................................................................... 4-64-6
Service access points.............................................................................................................................................................. 4-84-8
Air interface channels
Overview ................................................................................................................................................................................... 4-124-12
Physical channels................................................................................................................................................................... 4-134-13
Contents
...................................................................................................................................................................................................................................
iv Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Transport channels................................................................................................................................................................. 4-204-20
Logical channels..................................................................................................................................................................... 4-244-24
Air interface protocols
Overview ................................................................................................................................................................................... 4-264-26
Medium Access Control.................................................................................................................................................... 4-274-27
Radio Link Control ............................................................................................................................................................... 4-314-31
Packet Data Convergence Protocol (PDCP)............................................................................................................... 4-344-34
Radio Resource Control...................................................................................................................................................... 4-354-35
RRC State Machine.............................................................................................................................................................. 4-384-38
RRC Connection and Signaling Connection.............................................................................................................. 4-394-39
Signaling radio bearers........................................................................................................................................................ 4-404-40
Radio bearer establishment................................................................................................................................................ 4-444-44
UTRAN protocols
Overview ................................................................................................................................................................................... 4-484-48
Iub protocol structure........................................................................................................................................................... 4-494-49
Protocols of the Iub interface........................................................................................................................................... 4-514-51
Iur interface .............................................................................................................................................................................. 4-544-54
Iu-cs interface.......................................................................................................................................................................... 4-564-56
Part II: Optimization process
5 Optimization process
Overview ...................................................................................................................................................................................... 5-15-1
Network lifecycle ..................................................................................................................................................................... 5-25-2
Optimization process phases................................................................................................................................................ 5-45-4
Planning and preparation (site readiness)....................................................................................................................... 5-75-7
Drive test optimization before live traffic...................................................................................................................... 5-95-9
Information gathering........................................................................................................................................................... 5-115-11
Contents
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
v
Information analysis............................................................................................................................................................. 5-125-12
6 Drive testing
Overview ...................................................................................................................................................................................... 6-16-1
Drive test optimization process.......................................................................................................................................... 6-26-2
Planning and preparation (site readiness)....................................................................................................................... 6-46-4
Optimization planning............................................................................................................................................................ 6-66-6
Perform cluster optimization............................................................................................................................................... 6-86-8
Perform system verification............................................................................................................................................... 6-116-11
Part III: Optimization and troubleshooting
7 UTRAN key performance indicators
Overview ...................................................................................................................................................................................... 7-17-1
Performance Counters and Key Performance Indicators......................................................................................... 7-27-2
KPI example - CS IRAT HO success rate (UMTS -> GSM)............................................................................... 7-67-6
CS IRAT HO success rate (UMTS -> GSM)............................................................................................................... 7-77-7
Performance counter trigger event basis........................................................................................................................ 7-87-8
Parameter trigger event basis............................................................................................................................................ 7-107-10
Parameter setting.................................................................................................................................................................... 7-127-12
Parameter discussion............................................................................................................................................................ 7-137-13
8 Call availability optimization and troubleshooting
Overview ...................................................................................................................................................................................... 8-18-1
Call availability
Overview ...................................................................................................................................................................................... 8-38-3
Call availability ......................................................................................................................................................................... 8-48-4
Determination of accessibility problem.......................................................................................................................... 8-68-6
Accessibility
Overview ...................................................................................................................................................................................... 8-78-7
Contents
...................................................................................................................................................................................................................................
vi Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Access preliminary procedures........................................................................................................................................... 8-88-8
Cell re-selection failures........................................................................................................................................................ 8-98-9
RACH access procedure failures..................................................................................................................................... 8-118-11
RRC connection establishment analysis
Overview ................................................................................................................................................................................... 8-158-15
Introduction to RRC connection establishment......................................................................................................... 8-168-16
Call admission control failures........................................................................................................................................ 8-198-19
Radio link setup analysis.................................................................................................................................................... 8-218-21
RRC connection setup failure........................................................................................................................................... 8-238-23
Paging failures........................................................................................................................................................................ 8-248-24
RAB establishment analysis
Overview ................................................................................................................................................................................... 8-268-26
RAB establishment................................................................................................................................................................ 8-278-27
Dynamic bearer control failures...................................................................................................................................... 8-308-30
Radio bearer establishment failures............................................................................................................................... 8-328-32
No answer from UE............................................................................................................................................................. 8-338-33
9 Call reliability optimization and troubleshooting
Overview ...................................................................................................................................................................................... 9-19-1
Dropped calls analysis........................................................................................................................................................... 9-29-2
Radio link failures analysis due to synchronization issues..................................................................................... 9-69-6
Dropped RAB analysis due to congestion..................................................................................................................... 9-99-9
10 Call quality optimization and troubleshooting
Overview ................................................................................................................................................................................... 10-110-1
Quality KPIs ............................................................................................................................................................................ 10-210-2
11 Call mobility optimization and troubleshooting
Overview ................................................................................................................................................................................... 11-111-1
Contents
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
vii
Soft/Softer handover and troubleshooting
Overview ................................................................................................................................................................................... 11-311-3
Soft/softer handover procedure........................................................................................................................................ 11-411-4
Average active set size........................................................................................................................................................ 11-711-7
Soft handover troubleshooting.......................................................................................................................................... 11-911-9
No Node B resources available..................................................................................................................................... 11-1211-12
No transport resources available................................................................................................................................... 11-1311-13
No UE answer...................................................................................................................................................................... 11-1411-14
UE reject ................................................................................................................................................................................. 11-1511-15
Unlisted set cells.................................................................................................................................................................. 11-1611-16
CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting
Overview ................................................................................................................................................................................. 11-1811-18
CS Voice UMTS to GSM (inter-RAT) handover procedure.............................................................................. 11-1911-19
CS Voice relocation preparation procedure troubleshooting.............................................................................. 11-2311-23
CS Voice IRAT handover procedure troubleshooting........................................................................................... 11-2511-25
CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting
Overview ................................................................................................................................................................................. 11-2611-26
CS Voice GSM to UMTS (inter-RAT) handover procedure.............................................................................. 11-2711-27
Relocation resource allocation procedure troubleshooting................................................................................. 11-3011-30
Handover procedure troubleshooting........................................................................................................................... 11-3211-32
PS UMTS to GSM (inter-RAT) Cell Change Order and troubleshooting
Overview ................................................................................................................................................................................. 11-3311-33
PS UMTS to GSM (inter-RAT) Cell Change Order procedure....................................................................... 11-3411-34
PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting............................................................ 11-3711-37
Serving HS-DSCH Cell Change
Overview ................................................................................................................................................................................. 11-3911-39
Contents
...................................................................................................................................................................................................................................
viii Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Serving HS-DSCH Cell Change procedure.............................................................................................................. 11-4011-40
Serving HS-DSCH Cell Change troubleshooting................................................................................................... 11-4311-43
Inter-frequency hard handover and troubleshooting
Overview ................................................................................................................................................................................. 11-4411-44
Inter-frequency hard handover procedure.................................................................................................................. 11-4511-45
Hard handover troubleshooting...................................................................................................................................... 11-5011-50
No Node B resources available..................................................................................................................................... 11-5311-53
No transport resources available................................................................................................................................... 11-5411-54
UE reject ................................................................................................................................................................................. 11-5511-55
Inter-system directed retry
Overview ................................................................................................................................................................................. 11-5611-56
Inter-system directed retry procedure.......................................................................................................................... 11-5711-57
Inter-system directed retry troubleshooting.............................................................................................................. 11-6011-60
12 Throughput optimization and troubleshooting
Overview ................................................................................................................................................................................... 12-112-1
Throughput optimization..................................................................................................................................................... 12-212-2
Glossary
Index
Contents
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
ix
About this information productAbout this information product
Purpose
This document describes the methods to perform an optimization of the UTRANNetwork 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 thanthe ones above may not be valid.
The UMTS UTRAN optimization manual is specific to the optimization of UMTSnetworks and does not cover other aspects of network management or networkengineering.
Reason for reissue
This is the first issue of this Information Product (IP) for UMTS Release 04.03.Updates for the addition of new information and corrections in subsequent documentissues will be summarized in this notice.
Reason for reissue:
Issue Reason for reissue
0.1 Preliminary version for FOA
1 Final version for GA
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007,
Alcatel-Lucent - ProprietarySee notice on first page
xi
Intended audience
Alcatel-Lucent assumes that anyone using the information in this manual has a generalfamiliarity with UMTS networks, and has specific experience working with, andoperating, the Alcatel-Lucent UMTS system.
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 toknow 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 theUTRAN 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 RemoteMaintenance Tool application.
The term “OMC” is a generic term to describe the Operation and Maintenance Centerentities 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 04.03.
Related documentation
The following related documentation is available:
• Performance Measurements Definitions Manual, UMTS-04.03/IMS 5.0,401-382-803R04.03
Related training
The following related courses are available:
• UMTS System Introduction,UM1001
• UMTS Hardware Overview,UM1911
About this information product
...................................................................................................................................................................................................................................
xii Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
,
• UMTS UTRAN Signaling and Parameters,UM4302
• UTRAN Processes and Parameters,UM4305
• UTRAN Optimization,UM4801.
How to comment
To comment on this information product, go to theOnline Comment Form(http://www.lucent-info.com/comments/enus/) or e-mail your comments to theComments Hotline ([email protected]).
About this information product
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007,
Alcatel-Lucent - ProprietarySee notice on first page
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 theoptimization process, a short description of typical areas for optimization problems,and an overview over UTRAN signaling.
Contents
Chapter 1, Introduction to optimization 1-1
Chapter 2, Information sources and tools 2-1
Chapter 3, Common optimization problems and their solutions 3-1
Chapter 4, UTRAN Signaling 4-1
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
I-1
1 1Introduction to optimization
Overview...................................................................................................................................................................................................................................
Purpose
This chapter provides an introduction to the concepts of optimization. It explains whatoptimization is, why optimization is performed and when optimization must beperformed.
Contents
What is optimization? 1-2
Why optimize a network ? 1-4
When to optimize a network ? 1-6
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
1-1
What is optimization?...................................................................................................................................................................................................................................
Definition
Optimize To make as effective, perfect, or useful as possible.
Optimizing a UMTS network
For a UMTS network, optimization means getting the entire UMTS network to operateaccording to the requirements of an operator.
Optimizing a UMTS network consist of optimizing:
• RF network
• Transmission network.
Most of the optimization takes place in the RF network. The transmission networkdoes not have many parameters or variables that can be changed to increase theeffectiveness of the network.
Requirements
By optimizing a network, an operator tries to find the best configuration and use of thenetwork. This strongly depends on the requirements that an operator has and thepriorities an operator assigns to these requirements.
Requirements can relate to:
• Quality of service
• Traffic expectations and predictions
• Coverage area
• Capacity
• Current and future business strategies (network expansion, market shares,profitability levels).
Requirements and costs
An operator weighs the requirements against the costs that are involved to meet therequirements and the priorities of the requirements. An operator could probably meetmany requirements, but the costs involved would be very large.
Therefore the financial cost is a very important issue to decide:
• Which requirements can be met
• Which solutions can be implemented to meet a requirement.
Introduction to optimization
...................................................................................................................................................................................................................................
1-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Finding compromises
Requirements for a network often contradict each other. Improving a network to meetone requirement can introduce a problem for another requirement. Optimizationtherefore usually involves finding a compromise (or trade-off) between differentrequirements. When an engineer makes a choice for implementing a solution, allrequirements an operator has must be kept in mind.
Example of finding compromises
An operator wants:
• RF coverage over a large area
• Minimal interference.
Increasing transmit power increases RF coverage but at the same time increasesinterference. An operator must decide what is more important and implement a solutionthat reflects that decision.
What is not optimization
Optimization does not include all actions that make a network work better. Faultmanagement actions, such as replacing a circuit pack, is not network optimization.Fault management only ensures the network operates as it is supposed to operate.
The starting point for optimization is a network that does not have errors. Beforestarting the optimization of a network or trying to solve an optimization problem, anengineer must ensure that a problem is not caused by an error or fault.
Introduction to optimization What is optimization?
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
1-3
Why optimize a network ?...................................................................................................................................................................................................................................
Goal of optimization
The goal of optimization is tofine-tunean existing network to meet the requirementsof an operator in the most efficient way.
Important! Optimization of an existing network must not be used to correct a badnetwork design.
Reasons for optimization
Optimization is needed because a network is never perfect. It never fully complies tothe requirements of an operator.
Optimization is needed because of:
Reason Example
Deviations from (planning) assumptions Changes in subscriber behavior (increaseduse of a service or a cell)
Changes in operator requirements Increased market share, introduction ofnew service
Changes in environment New buildings, snowfall, trees
Most of these reasons can not be prevented or can only be prevented partially. Goodmodels (for example for traffic behavior and forecasts) can help predict changes andthus help in designing and optimizing networks.
Consequences of not optimizing
Not optimizing a network means the goals of optimization are not met and the networkdoes not “meet the requirements of an operator, in the most efficient way.”
Of course a network must meet the requirements of an operator, but not meeting theserequirementsin the most efficient waycosts an operator money. By optimizing thenetwork, the same requirements could be met with fewer resources.
Not optimizing the network will cost money, related to:
• Subscribers, in missed revenue because of blocked calls or subscribers changing toother operators
• Operational and maintenance costs.
Introduction to optimization
...................................................................................................................................................................................................................................
1-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Subscribers
In a network that is not optimized, subscribers can experience:
• Blocked calls
• Dropped calls
• Smaller RF coverage area
• Lower voice quality
• Lower data rates.
Blocked calls are a direct loss of revenue for an operator. Poor network quality can bea reason for existing subscribers to change to another operator and for potentialcustomers to subscribe to competitors.
Operational costs
A network that is not optimized is more expensive to operate. The equipment is notused effectively, so more equipment is needed. The extra equipment increasesmaintenance and operational costs.
Also more errors and problems can be expected in a network that is not optimized.This increases the costs of fault management.
Result of optimization
An optimized network increases network coverage and network capacity.
This directly translates into:
• Lower operational and maintenance costs
• Higher number of voice and data users
• Higher average data throughputs
• Higher Quality of Service for voice and data users.
Introduction to optimization Why optimize a network ?
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
1-5
When to optimize a network ?...................................................................................................................................................................................................................................
Phases when optimization takes place
Optimization during the network life cycle:
Optimization is performed:
• Before a commercial network launch
• In a live, operational network.
Before a commercial network launch, typical optimization includes:
• Network design optimization
• Optimization based on drive testing.
This document covers in service optimization in a live, operational network, eventhough optimization methods and tools are similar during both phases.
Always
The environment in which a network operates isalwayschanging, so the network itselfmustalwayschange too, adapting to the changes that take place. There are alwaysreasons for optimization, therefore optimization in a live network never stops.
Network design
In serviceoptimization
Optimization Planning
Live network
Implementation
Network design& implementation
Y
N Acceptancecriteria met?
Introduction to optimization
...................................................................................................................................................................................................................................
1-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Optimization is always needed because there are always:
• Deviations from (planning) assumptions
• Changes in subscriber behavior
• Changes in operator requirements
• Changes in environment.
Introduction to optimization When to optimize a network ?
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
1-7
2 2Information sources and tools
Gathering information
Overview...................................................................................................................................................................................................................................
Purpose
This section provides information on tools and information sources that are used togather 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 canbe used to monitor and count messages on interfaces in the network. Protocol analyzersare available from many different vendors.
Contents
Key Performance Indicators 2-2
Drive test 2-3
Customer complaints 2-6
OMC-UPS tools 2-7
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-1
Key Performance Indicators...................................................................................................................................................................................................................................
Use of Key Performance Indicators
Key Performance Indicators (KPI) are calculated using measurements that are gatheredby the OMC-UPS. The KPIs are used to determine if the network complies to thelevels 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 reachingthresholds, are often the first indication of a problem that can be an issue foroptimization.
A KPI value can change suddenly, or gradually, but both types of change can be anindication 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 toUMTS PerformanceMeasurement Definitions Manual,401-382-803R04.03.
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.
Information sources and tools
...................................................................................................................................................................................................................................
2-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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. Duringnetwork deployment drive tests are used to check basic cell operation and to ensureclusters and the network meets customer requirements.
During optimization in a live network, drive tests recheck cell performance. Duringthese test, neighboring cells must be operational, so cell selection, interferencemeasurements and hand overs can be performed and tested.
After implementing a solution to correct an (optimization) problem, a drive test can beperformed to check if the problem is solved.
Regular drive tests are also a method for preventive maintenance to detect areas whereservices are degrading.
Components
Components of a typical drive test system (picture provided courtesy of AgilentTechnologies):
Information sources and tools
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-3
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
....................................................................................................................................................................................................................................
2-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Analyzing drive test data
Data that is gathered during a drive test can be displayed in real time or stored on thePC for off-line analysis.
The information must be analyzed to check for performance problems, that can besolved 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 theinformation.
Analysis tools can project the collected data on a map that includes characteristics ofthe terrain. On the map, details are shown such as coverage strength, and locationswhere handovers, cell reselections or dropped calls occur.
This information is used to identify problems and the locations where the problemsoccur.
Information sources and tools Drive test
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-5
Customer complaints...................................................................................................................................................................................................................................
Use of customer complaints
Customer complaints can provide an indication of problems. Especially if multiplecomplaints can be related to one source. Customer complaints can point to a problemon a specific location, time or related to a resource.
A customer complaint can be the trigger for further investigation using KPIs or drivetesting.
Trouble tickets
Customer complaints are typically documented as trouble tickets. The form of troubletickets (electronic, paper) and the way trouble tickets are stored and handled differsbetween 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 callscan be an indication of an RF coverage gap or a neighboring cell list problem. Sofurther investigation of the problem is needed.
Further investigation can determine that the dropped calls always occur when there is alot of traffic in the cell. The problem can be the result of an RF coverage gap becauseof cell breathing.
Detected problems
Although customer complaints are often not very specific, they can be helpful to detectproblems that may be an issue for optimization.
Information sources and tools
...................................................................................................................................................................................................................................
2-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
OMC-UPS tools...................................................................................................................................................................................................................................
OMC-UPS tools
The OMC-UPS offers the following tools that can be used in gathering information foroptimization:
• RF call trace
• OCNS.
RF call trace
RF call trace gathers radio related information associated to one or more cells. RF calltrace 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 thatUE is collected, as long as the UE is connected to the tracing RNC. The information iscomposed of measurements performed at the UE, the NodeB and the RNC. Allmeasurements are stored at the RNC until the OMC-UPS requests a transfer to theOMC-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 theOMC-UPS and generates downlink interference to simulate traffic.
The OMC-UPS administrator can define characteristics of the simulated traffic such asmode 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 simulatestraffic during testing before a network is live.
OCNS can also be used to generate additional traffic in a live cell, simulating heaviertraffic loads.
Detected problems
RF Call trace can be useful to detect all problems that may be an issue foroptimization.
Information sources and tools
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-7
OCNS can be useful to detect Cell breathing.
Information sources and tools OMC-UPS tools
....................................................................................................................................................................................................................................
2-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Analyzing information
Overview...................................................................................................................................................................................................................................
Purpose
This section provides information about tools that can be used during optimization.
Contents
Data analysis software 2-10
Optimization and design tools 2-13
Information sources and tools
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-9
Data analysis software...................................................................................................................................................................................................................................
Need for data analysis software
Data analysis software is needed to process data, because a large volume ofinformation is collected. The software helps to sort out the information, present it to anengineer and helps the engineer to draw conclusions.
The software also allows an operator to show the consequences of changes that aremade 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 characteristicsof the terrain. On the map, details are shown such as coverage strength, and locationswhere 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 orantenna tilt). An engineer can easily try different options. This helps an engineer todetermine what is the best solution to correct an optimization problem.
Information sources and tools
...................................................................................................................................................................................................................................
2-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Output of analysis tools
Data analysis tools can provide output on performance in different forms, but mostcommonly used are outputs in tables and graphical outputs. Especially graphical outputclearly shows problem areas in a network.
Typical output from data analysis software and illustrates a network before and afteroptimization:
The dark lines indicate areas that have no coverage. Changes in the shade of theantennas indicate changes in antenna tilt.
Analysis tool availability
Many tools are available for analyzing information. The main input for manycommercially available analysis software tool is drive test data. But also other inputscan be used.
Before optimization Optimizated design
Information sources and tools Data analysis software
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-11
Besides commercially available software tools also many proprietary tools areavailable.
Key capabilities
To be able to handle the large volumes of data from many sources with differentformats, data analysis tools must support key capabilities such as:
• Interfaces to different vendors of drive test equipment, protocol analyzers andmeasurement 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.
Information sources and tools Data analysis software
....................................................................................................................................................................................................................................
2-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Optimization and design tools...................................................................................................................................................................................................................................
This topic gives an overview of tools, developed by Alcatel-Lucent, that are used inoptimization and design of 3G networks.
LCAT
LCAT is the Lucent Cells Application Tool. It is a tools that allows an engineer todefine cells and sectors.
LCAT information as input for LDAT and SPAT3G.
LDAT3G
Lucent Data Analysis Tool for 3G (LDAT3G) is an application for performing RFanalysis of drive test data for IS-95, 3G CDMA, 1xEV-DO, and UMTS systems. Usedfor initial optimization of deployed network.
Drive test data, RF Call Trace, Cell Diagnostic Monitor, Packrat, and WINDS aresupported.
SPAT3G
Service Performance Analysis Tool for 3G (SPAT3G) is a tool that can be used toquickly troubleshoot and improve network performance. It gives you easy access to awealth of information at the system, cell, face, and carrier level that can be displayedgraphically or in tabular formats. SPAT3G is used to optimize a live network and notduring 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 ServiceMeasurements data, as well as FCIAlert, Handoff Matrix, and UNL data by rightclicking on a cell site.
• Displays handoff matrix data on a map display showing handoff relationshipsbetween sites.
AirPro
AirPro is an RF planning tool that is used to design wireless systems. AirPro can beused in the designs of new wireless networks, networks migrating from oldergeneration to newer generation and existing network optimization. AirPro includes RF
Information sources and tools
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
2-13
propagation analysis, interference prediction, RF optimization, and utilities that helpyou create and manage system designs for mobile systems in diverse operatingenvironments
Ocelot ®
Ocelot® is used to optimize tilt, azimuth and power levels of antennas in a scenario toget best coverage and capacity from the network. The benefit of usingOcelot® foroptimization is reduced dependence on drive testing required for calibrating the designparameters 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 (“trafficbalancing”)
• Reducing the amount of soft- and softer-handoff traffic
• Reducing the average power per user.
Information sources and tools Optimization and design tools
....................................................................................................................................................................................................................................
2-14 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
3 3Common optimization problemsand their solutions
Overview...................................................................................................................................................................................................................................
Purpose
This chapter describes typical problem areas that can be addressed by optimization andprovides 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 thatare given may solve that particular problem, but at the same time may introduce aproblem elsewhere.
Contents
RF coverage problem 3-2
Cell breathing problem 3-4
Pilot pollution problem 3-6
Near-far problem 3-8
Around-the-corner problem 3-9
Handover problem 3-10
Missing neighbors problem 3-11
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
3-1
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 andcan be checked using drive tests. The user equipment receive power is not an accuratemeasure of pathloss for spread spectrum technologies. The user equipment may havestrong receive power due to many overlapping sectors but no pilot fulfills the abovementioned 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 anaccurate measures for the RF coverage.
Optimization goal
The goal is to close RF coverage gaps and maximize RF coverage. Or to be moreprecise, maximize RF coverage, while continuing to comply to other requirements.Because increasing RF coverage must not mean other requirements such as interferencelevels can not be met anymore.
If RF coverage gaps can not be closed, it may be possible to move an RF coveragegap from an area with high traffic volumes to an area with low traffic volumes. Thisdoes 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 thenetwork.
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
...................................................................................................................................................................................................................................
3-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Possible solutions
Possible solutions for RF coverage problems are:
• Antenna tilt or reorientation
• Power increase
• New antenna or new cell site.
Common optimization problems and their solutions RF coverage problem
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
3-3
Cell breathing problem...................................................................................................................................................................................................................................
Definition
Cell breathing is the growing and shrinking of an RF coverage area, depending on thenetwork load.
An increase of the network load increases network interference. Higher interferencelowers the quality of service especially at the initial cell coverage border and thus thecoverage area shrinks. To remain connected, power levels must increase. When powercan not be increased further, a handover is needed.
A low network load leads to low network interference, which increases the cellcoverage. This can result in neighboring cells not being used because the mobiles stayconnected to the original cell and no handovers occur.
Cell breathing:
Traffic needed during optimization
Cell breathing occurs when the network is loaded, so RF optimization must beperformed on a loaded network. The network can be loaded with live traffic orsimulated traffic.
To simulate (additional) traffic on the downlink, the Orthogonal Channel NoiseSimulator (OCNS) can be activated on the OMC-UPS to generate downlinkinterference. On the uplink, an attenuator attached to the user equipment simulates theloading.
Cell at 30 % capacity
Cell at 60 % capacity
Common optimization problems and their solutions
...................................................................................................................................................................................................................................
3-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Optimization goal
The goal is to ensure that high load situations do not lead to RF coverage gaps. At thesame time, low load situations should not create large overlaps in cell coverage, whichmay lead to pilot pollution or unwanted handover behavior.
In both high and low load situations, the network must have sufficient coverage andthe network must be used efficiently.
Detection of the problem
There are several ways in which cell breathing problems show themselves in thenetwork.
These include:
• Dropped calls
• Poor quality, especially at cell edges (during high traffic loads)
• Appearance of RF coverage gaps (during high traffic loads)
• Failed handovers
• No handover to neighboring cells (during low traffic loads)
• Excessive or unexpected handovers (during high traffic loads)
• Pilot pollution (during low traffic loads).
Information sources
The following information sources are used to detect cell breathing problems:
• Drive tests
• Key performance indicators
• Customer complaints.
Possible solutions
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.
Common optimization problems and their solutions Cell breathing problem
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
3-5
Pilot pollution problem...................................................................................................................................................................................................................................
Definition
Pilot pollution is interference caused by overlapping pilots with similar signalstrengths.
The lack of a dominant pilot causes low Ec/Io ratios. Problem areas with low Ec/Ioratios may be misinterpreted as pilot pollution areas and lead to iterative drive testingand unnecessary parameter changes in attempts to establish a dominant pilot.
If a pilot has:
• Insufficient Ec signal strength (extensive pathloss), the problem area is consideredas 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 toexcessive pathloss or pilot pollution.
Pilot pollution is also considered if the number of present pilots is greater than theactual active set size of the user equipment. Present pilots which cannot be added intothe active set cause interference.
Another aspect for interference is multipath reception. Each received pilot isaccompanied by 2-3 strong multipaths. The user equipment uses a rake receiver toexploit multipath reception. Since the rake receiver has a limited number of fingers,unused multipaths act as interference. Consequently, a six-finger rake receiver is fullyoccupied when receiving three pilots (each with 2 multipaths). Any additional pilotsand multipaths are interference. Common trouble spots are bridges, upper floors inbuildings, elevated highways, street intersections, and large bodies of water.
Optimization goal
The goal is to minimize pilot pollution. Coverage of the dominant pilot must beincreased and coverage of the weaker pilots (which cause interference) must bedecreased. At the same time, continuous coverage through the soft handover must beensured.
Detection of the problem
There are several ways in which pilot pollution problems show themselves in thenetwork.
These include:
• Dropped calls
• Handover failures
Common optimization problems and their solutions
...................................................................................................................................................................................................................................
3-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• 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.
Common optimization problems and their solutions Pilot pollution problem
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
3-7
Near-far problem...................................................................................................................................................................................................................................
Definition
Near-far problems occur when user equipment near the cell site transmits on highpower. This creates excessive interference for user equipment that is located far awayfrom 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 isneeded to direct mobiles to power up or power down very quickly. The optimizationgoal is to ensure that all power control algorithms are working properly. Power controlparameters are tuned only when there are obvious power control failures.
Detection of the problem
There are several ways in which near-far problems show themselves in the network.
These include:
• High interference
• Node B always transmits on full power despite satisfying block error rates
• User equipment always transmits on full power despite satisfying block error rates.
Information sources
The following information sources are used to detect near-far problems:
• Drive test
• Key performance indicators
• Customer complaints.
Possible solutions
Possible solutions for near-far problems are:
• Changing power control parameters.
Common optimization problems and their solutions
...................................................................................................................................................................................................................................
3-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Around-the-corner problem...................................................................................................................................................................................................................................
Definition
Around-the-corner problems occur when user equipment travels beyond an obstructionand if there is significant downlink interference from a new sector with low pathloss.The downlink degrades momentarily until the handover is performed or the downlinkpower control reacts to compensate the interference.
When the user equipment goes into handover with the new cell site, fast power controlis needed to quickly reduce cell site transmit power.
The around-the-corner problem is a continual and unavoidable issue. Known troublespots 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.
Detection of the problem
There are several ways in which around-the-corner problems show themselves in thenetwork.
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.
Common optimization problems and their solutions
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
3-9
Handover problem...................................................................................................................................................................................................................................
Definition
Unnecessary delays in handovers may cause uplink/downlink interference. Quickhandovers are required when there are rapid changes in pathloss between the userequipment and the sector due to fading. Also, unnecessary handovers duenon-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 thresholdsand timers.
Handovers require signaling resources, and increase downlink interference, soexcessive handover activity must be minimized. Time delays due to resource allocation(channel units, transmission links to RNC, OVSF codes) degrade call quality andreduce the throughput of data calls.
Detection of the problem
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.
Common optimization problems and their solutions
...................................................................................................................................................................................................................................
3-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Missing neighbors problem...................................................................................................................................................................................................................................
Definition
A neighboring cell list contains the cell identifiers to which a handover is allowed. Thelist is kept in the RNC and is transmitted to the UE. The UE measures signals onlyfrom the neighboring cell list and uses these measurement for power control andhandovers. A handover can therefor only occur to a cell that is in the neighboring celllist 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 arereceived that are not in the neighboring cell list, these pilots cannot be added to theactive set and thus these pilots will cause interference. It is important that all receivedUMTS 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 beeliminated or declared in the neighboring cell list. They must not be ignored.
Detection of the problem
There are several ways in which missing neighbor problems show themselves in thenetwork.
These include:
• Dropped calls (when neighboring cell list is too short and UE can not handover toanother cell)
• High interference levels (UE transmits at high power levels to serving cell, becauseit can not handover to another cell)
• Unusual handover behavior (no handovers are performed from on cell to anothercell).
• Uneven traffic distribution (UE stay with a cell and are not handed over to aneighboring cell).
Information sources
The following information sources are used to detect missing neighbors problem:
• Drive test
• Key performance indicators
• Customer complaints.
Common optimization problems and their solutions
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
3-11
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 isimproved:
– Adjust power levels
– Change antenna orientation or tilt.
Common optimization problems and their solutions Missing neighbors problem
...................................................................................................................................................................................................................................
3-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
4 4UTRAN Signaling
Overview...................................................................................................................................................................................................................................
Purpose
Contents
Protocol architecture of the air interface 4-3
Protocols of the air interface 4-4
Radio interface protocol architecture 4-6
Service access points 4-8
Air interface channels 4-12
Physical channels 4-13
Transport channels 4-20
Logical channels 4-24
Air interface protocols 4-26
Medium Access Control 4-27
Radio Link Control 4-31
Packet Data Convergence Protocol (PDCP) 4-34
Radio Resource Control 4-35
RRC State Machine 4-38
RRC Connection and Signaling Connection 4-39
Signaling radio bearers 4-40
Radio bearer establishment 4-44
UTRAN protocols 4-48
Iub protocol structure 4-49
Protocols of the Iub interface 4-51
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-1
Iur interface 4-54
Iu-cs interface 4-56
UTRAN Signaling Overview
....................................................................................................................................................................................................................................
4-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 airinterface
• to explain how the layers communicate with one another by the use of channels.
Contents
Protocols of the air interface 4-4
Radio interface protocol architecture 4-6
Service access points 4-8
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-3
Protocols of the air interface...................................................................................................................................................................................................................................
Logical structure of the air or U u interface (PS example)
The following illustration shows the UTRAN protocol architecture (for DCH) with theprotocols of the Uu highlighted.
Description
The following table lists the protocols of the Uu and introduces the functions eachperforms.
Part Description
Radio Resource Control The RRC controls the connection between UE andUTRAN (setup, maintenance and teardown). Secondly,RRC provides the means for the transmission of NASsignaling. Finally, it is used by the Radio ResourceManagement algorithms.
Packet Data ConvergenceProtocol
The PDCP provides header compression anddecompression of IP data streams. It also transmits userdata from the non-access stratum to the RLC layer andvice versa.
RANAP
SSCOP
Uu Node B Iu-psIub RNC
MTP3-b
SGSN
SSCF
UE
-N
SCCP
PMM
SMPMM
-
ATM
U
STM
AAL5
1
IP
GTP
UDP
-
SM
MAC
Phy-up
PHY
RRC
IP
PDCP
RLC
ATM
E1/ STM-1
AAL2 AAL5
NBAP
PHY
ALCAP
SSCOP
STC.2
SSCF-UNIFP
SSCOP
NBAP
AAL5 AAL2
SSCOP
MTP3-b
SSCF-N
SCCP
RANAP
RRC
ATM
STM-1
GTP-U
UDP
PDCP
ALCAP
STC.2
SSCF-UNIIP
RLC
MAC
Phy
FP
-up
AAL5
User plane
Control plane
UTRAN Signaling
...................................................................................................................................................................................................................................
4-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Part Description
Radio Link Control The RLC provides functions related to data transfer, suchas segmentation and reassembly, in-sequence delivery,error-correction and flow control. Three modes areprovided: transparent, acknowledged andunacknowledged.
Medium Access Control The MAC prepares transport blocks for most efficienttransfer over the air. The functions include scheduling,multiplexing, channel type switching, UE identification(on common channels) and transport format selection ona frame-by-frame basis.
The MAC is responsible for mapping logical channelonto the appropriate transport channel.
UTRAN Signaling Protocols of the air interface
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-5
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 usertraffic
• 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 andthe BMC exist in the U plane only.
In the C plane, Layer 3 is partitioned into sub-layers where the lowest sub-layer whichis called the Radio-Resource Control (RRC), interfaces with Layer 2 and terminates inthe 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 theUTRAN 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
...................................................................................................................................................................................................................................
4-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 atthe interface between sub-layers. The SAP between the MAC and the physical layerprovides the transport channels. The SAPs between the RLC and the MAC sub-layerprovide 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 DedicatedControl (DC) SAPs.
The connections between the RRC and the MAC as well as the RRC and L1 providelocal 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. Forthis purpose separate Control SAPs are defined between the RRC and each lower layer(PDCP, RLC, MAC and L1).
Physical Layer (PHY)
Medium Access Control (MAC)
RLC RLCRLC
RLC RLCRLC
RLCRLC
BMC
PDCP DCP
controlcontrol
GC Nt DC
Radio Resource Control(RRC)
cont
rol
Layer 3
L2/PDCP
L2/BMC
L2/RLC
LogicalChannelsL2/MAC
TransportChannelsL1PhysicalChannels
C-plane signaling U-plane information
UTRAN Signaling Radio interface protocol architecture
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-7
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 differentkinds of channels for communications. The channels are divided into four broadcategories, 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.
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 overthe radio link. For example, the DTCH carries the actual user data; the BCCHprovides system information to all users in a cell.
• The transport channel service defines how and with what characteristics (withwhich QoS) data is transferred over the radio link. Every transport channel has atransport 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-linkedwith the Node B.
SAPs
Medium Access Control (MAC)L2
Radio ResourceControl (RRC)L3
Radio Link Control (RLC)L2
SAPs
SAPs
Physical LayerL1
Layer
Management
Air
SAPs
UTRAN Signaling
...................................................................................................................................................................................................................................
4-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Channel mapping
For each of the channel categories, there is a number of types, each with differentcharacteristics. The Radio Bearers map directly to the Logical Channels; the LogicalChannels map to the Transport Channels; and the Transport Channels map to thePhysical Channels.
The following illustration shows the relationships between channels linking differentprotocol layers.
UTRAN Signaling Service access points
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-9
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 areassociated with traffic-carrying channels, while others are necessary for cell discoveryby the UE and channel estimation.
S-SCH
S-CPICH
P-CPICH
PICH
PRACH
S-CCPCH
P-CCPCH
DPDCH
HS-DPCCH
DPCCH
HS-SCCH
E-DPCCH
E-DPDCH
HS-PDSCH
AICH
BCH
FACH
PCH
DCH
E-DCH
HS-DSCH
RACH
PCCH
BCCH
CTCH
DTCH
DCCH
CCCH
DPCH
P-SCH
E-AGCH
E-HICH
E-RGCH
Logical channels Transport channels
Physical channelsUplinkDownlinkBidirectionalData transferAssociation
Fixedchannels
UTRAN Signaling Service access points
....................................................................................................................................................................................................................................
4-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Multiple transport channels can be multiplexed onto a single physical channel, orconversely, one transport channel can be transferred over multiple physical channels(multicode). PCH and FACH can be multiplexed onto the same S-CCPCH or can eachbe transferred over separate S-CCPCHs.
Associated channels are used as follows:
• PICH indicates in an efficient manner that information for a mobile will shortly betransferred on the PCH transport channel
• AICH indicates that an access preamble has been received, and that the UE canstop ramping up its power, or (for PCPCH) that a collision detect preamble hasbeen received and resolved
• DPCCH carries power control information for associated channels as well as TFCindication for DPDCH and PDSCH, and pilot and feedback information. Theshared channels are power controlled, so a UE which uses them must also have adedicated channel set up and associated with them. This DCH can be of very lowbandwidth 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 UEthat data packets are being sent on the HS-PDSCH, and provides the UE withnecessary information to decode the data packets.
• The HS-DPCCH carries the UE feedback information used for link adaptation andthe Hybrid Automated Repeat request (HARQ) process.
UTRAN Signaling Service access points
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-11
Air interface channels
Overview...................................................................................................................................................................................................................................
Purpose
The purpose of this section is:
• 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 4-13
Transport channels 4-20
Logical channels 4-24
UTRAN Signaling
...................................................................................................................................................................................................................................
4-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Physical channels...................................................................................................................................................................................................................................
Overview
In this section, we will look at each of the physical channels that link the UE with theNode 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 orout of Node B control data. In the latter case, the information in the physical channeldoes not carry higher-layer traffic but is pure layer 1 control data created by the NodeB, e.g. SCH or CPICH.
Multiple transport channels can be multiplexed onto a single physical channel, orconversely, one transport channel can be transferred over multiple physical channels(multicode). For example, PCH and FACH can be multiplexed onto the sameS-CCPCH or can each be transferred over separate S-CCPCHs.
Transport channels are mapped to physical channels as shown in the illustration.
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-13
Channel mapping
The DCHs are coded and multiplexed and the resulting data stream is mappedsequentially directly to the physical channel(s).
S-SCH
S-CPICH
P-CPICH
PICH
PRACH
S-CCPCH
P-CCPCH
DPDCH
HS-DPCCH
DPCCH
HS-SCCH
E-DPCCH
E-DPDCH
HS-PDSCH
AICH
BCH
FACH
PCH
DCH
E-DCH
HS-DSCH
RACH
PCCH
BCCH
CTCH
DTCH
DCCH
CCCH
DPCH
P-SCH
E-AGCH
E-HICH
E-RGCH
Logical channels Transport channels
Physical channelsUplinkDownlinkBidirectionalData transferAssociation
Fixedchannels
UTRAN Signaling Physical channels
....................................................................................................................................................................................................................................
4-14 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
The mapping of BCH and FACH is equally straightforward where the data stream,after coding and interleaving, is mapped sequentially to the Primary and SecondaryCCPCH respectively.
Also for the RACH, the coded and interleaved bits are sequentially mapped to thephysical channel, in this case the message part of the random access burst on thePRACH.
The mapping of the PCH to the Secondary CCPCH is more complex to allow for anefficient sleep mode.
The mapping of the HS-DSCH to the HS-PDSCH is done by mapping the data streamsequentially directly to the physical channel.
Common downlink physical channels
The following is a list of the common downlink physical channels:
Commondownlinkphysicalchannels
Description
P-CCPCH The Primary Common Control Physical Channel is a fixed rate (32kbps, SF=256) downlink physical channels used to carry the BCH.
S-CCPCH The Secondary Common Control Physical Channel is used to carrythe FACH and PCH. It is of constant rate. However, in contrast tothe Primary CCPCH, the rate may be different for differentsecondary CCPCH within one cell and between cells, in order to beable to allocate different amount of FACH and PCH capacity to acell. The rate and spreading factor of each secondary CCPCH isbroadcast on the BCH. The set of possible rates is the same as forthe downlink DPCH.
The FACH and PCH can be mapped to separate secondaryCCPCHs.
The main difference between the Primary and Secondary CCPCH isthat the Primary CCPCH has a fixed predefined rate while theSecondary CCPCH has a constant rate that may be different fordifferent cells, depending on the capacity needed for FACH andPCH.
UTRAN Signaling Physical channels
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-15
Commondownlinkphysicalchannels
Description
P-SCH The Synchronisation Channel (SCH) is a downlink signal used forcell search. The SCH consists of two sub channels, the Primary andSecondary SCH. Along with the CPICH, the SCH channels provideinformation that enables the UE to camp on, search for and select acell.
During the first step of the initial cell search procedure, the UEuses the Primary Synchronisation Channel (P-SCH) to acquire slotsynchronisation to the strongest cell. The Primary SynchronisationCode 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 UEuses the secondary SCH to find frame synchronisation and identifythe 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 itbelongs to, therefore the UE can use this channel to determine thereceived signal strength of this particular cell. Furthermore theP-CPICH is also used as a phase and power reference for the otherdownlink physical channels.
The downlink common control channels have to reach all UEs inthe cell and should not be too loud to disturb other cells. As thecell size is often adjusted, it may occur that the power level of allcontrol channels must be readjusted. To simplify this, the powerlevel of all control channels are expressed in relation to the powerthat is used by the Pilot Channel of a cell. That is, when the powerof P-CPICH is reduced, the power of all other common channels isreduced by the same factor.
S-CPICH The Secondary Common pilot Channel may be transmitted over theentire cell or a part of the cell. There may be zero, one or severalS-CPICH per cell. An S-CPICH may be the phase reference for thesecondary CCPCH and the downlink DPCH. If this is the case, theUE is informed about this by higher layer signaling.
PICH The Paging Indicator Channel informs the UE that paginginformation will shortly be available for that mobile over theS-CCPCH. This is an efficient process which saves the UE fromhaving to permanently listen in on the S-CCPCH.
UTRAN Signaling Physical channels
....................................................................................................................................................................................................................................
4-16 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Commondownlinkphysicalchannels
Description
AICH The Acquisition Indicator Channel is a common downlink physicalchannel which works closely together with the uplink PRACH.Upon reception of an access preamble from a UE, the Node B usesthe AICH to acknowledge the success of the transmission and toinform the UE that it can stop ramping up its power.
PDSCH The Physical Downlink Shared Channel is shared by several usersbased 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 to15 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 theinformation about the configuration to be used next on theHS-PDSCH channel. It has a fixed spreading factor of 128. The UEcan monitor up to four HS-SCCH channels.
Dedicated downlink physical channels
The following is a list of the dedicated downlink physical channels:
Dedicateddownlinkphysicalchannels
Description
DPCH There is only one type of downlink dedicated physical channel, theDownlink Dedicated Physical Channel (downlink DPCH).
Within one downlink DPCH, dedicated user data generated at layer2 and above (from MAC and above at the RNC) and controlinformation generated at layer 1 (known pilot bits, TPC commands,and an optional TFCI) are multiplexed at the Node B andtransmitted together over the Uu interface. The downlink DPCH canthus be seen as a time multiplex of a downlink DPDCH and adownlink DPCCH.
E-HICH The E-DCH HARQ Indication Channel (E-HICH) carries theACK/NACK information from the E-DCH Active Set cells that apacket was received and retrieved successfully. This channel uses aspreading factor of 128.
UTRAN Signaling Physical channels
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-17
Dedicateddownlinkphysicalchannels
Description
E-AGCH The E-DCH Absolute Grant Channel carries the E-DCH RadioNetwork Temporary Identifier, the HARQ Process Activation flag,and the maximum power ratio the UEs may use for E-DCHtransmission. This channel uses a spreading factor of 256.
E-RGCH The E-DCH Relative Grant Channel (E-RGCH) With this, the radioresource 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 uplinkphysicalchannels
Description
PRACH The PRACH only exists in the uplink and enables the UE to sendmessages to the UTRAN, without having a dedicated channel.Typically, the PRACH is used when a mobile user wishes to initiatea 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 thePRACH and thus prevent collisions. UEs receive information onwhat access slots are available in the current cell over the broadcastchannel (BCH). The access slots have time offsets that are spaced1.25 ms apart.
Dedicated uplink physical channels
In contrast to the one dedicated downlink physical channel, there are two dedicateduplink physical channels: the Dedicated Physical Data CHannel (DPDCH) and theDedicated Physical Control CHannel (DPCCH). The uplink transmits the DPDCH andthe DPCCH logically separate from one another. There may be zero, one, or severaluplink DPCHs on each Layer 1 connection.
UTRAN Signaling Physical channels
....................................................................................................................................................................................................................................
4-18 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
The following is a list of the dedicated uplink physical channels:
Dedicateduplink physicalchannels
Description
DPDCH The uplink DPDCH is used to carry dedicated user data generatedat Layer 2 and above, i.e. data taken from the dedicated transportchannel (DCH). There may be zero, one, or several uplink DPDCHson each Layer 1 connection.
DPCCH UE-specific uplink channel that feedbacks the ACK/NACK forHARQ, and channel quality information for the scheduler. It has afixed spreading factor of 256. This channel is code multiplexed tothe uplink DPCCH.
The Layer 1 control information consists of the same controlinformation as used in the downlink with the addition of FBI bits:
• Transmit Power Control (TPC) allows the UE to tell the NodeB to either increase or decrease its transmission power.
• The TFCI is used in order to inform the receiving side of thecurrently valid Transport Format Combination, and hence howto decode, de-multiplex and deliver the received data on theappropriate Transport Channels.
• Pilot bits support channel estimation for coherent detection.
• By means of the FBI-Bits (FeedBack Information), the UE canhave the Node B regulate the phase and amplitude in the caseof Closed Loop Transmit Diversity.
HS-DPCCH The High Speed Dedicated Physical Control Channel is aUE-specific uplink channel that feedbacks the ACK/NACKmessages for Hybrid Automatic Repeat Requests (HARQ), andchannel quality information for the scheduler. It has a fixedspreading factor of 256. This channel is code multiplexed to theuplink DPCCH.
E-DPDCH The Enhanced Dedicated Physical Data Channel (E-DPDCH) carriesthe user traffic from the UE and uses a range of spreading factors,depending on the data traffic rate. E-DPDCH supports the 2 msTTI and the 10 ms TTI.
E-DPCCH The Enhanced Dedicated Physical Data Channel (E-DPDCH) carriescontrol information on the E-DCH associated physical layersignaling channel transmitted by the UE. This channel uses aspreading factor of 256 to forward the Transport FormatCombination Indicator used on E-DCH (E-TFCI), the HARQ relatedRetransmission Sequence Number (RSN), and a “happy bit” as afeedback to the Node B.
UTRAN Signaling Physical channels
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-19
Transport channels...................................................................................................................................................................................................................................
Introduction
The transport channels convey data from the MAC layer to the physical layer and thereare mapped to physical channels.
The physical layer offers the transport channels different bitrates, depending on thespreading 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
...................................................................................................................................................................................................................................
4-20 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
S-SCH
S-CPICH
P-CPICH
PICH
PRACH
S-CCPCH
P-CCPCH
DPDCH
HS-DPCCH
DPCCH
HS-SCCH
E-DPCCH
E-DPDCH
HS-PDSCH
AICH
BCH
FACH
PCH
DCH
E-DCH
HS-DSCH
RACH
PCCH
BCCH
CTCH
DTCH
DCCH
CCCH
DPCH
P-SCH
E-AGCH
E-HICH
E-RGCH
Logical channels Transport channels
Physical channelsUplinkDownlinkBidirectionalData transferAssociation
Fixedchannels
UTRAN Signaling Transport channels
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-21
Dedicated and common transport channels
There are two types of transport channels: dedicated transport channels and commontransport channels. The common transport channels may be used by multiple users, thededicated transport channel to one single UE only.
There are three dedicated transport channels:
Dedicatedtransportchannels
Description
DCH The Dedicated Channel (DCH) is a channel dedicated to oneparticular UE used in uplink or downlink direction.
E-DCH The Enhanced Dedicated Channel (E-DCH) is the uplink transportchannel that carries the E-DPDCH and the other E-DCH physicalchannels as associated channels.
E-DCH uses fixed coding and modulation codes, and multipleHARQ processes to enhance the uplink performance. The Node Bhas the power control for this channel to minimize uplinkinterference levels.
There are six common transport channels:
Commontransportchannels
Description
RACH The Random Access Channel (RACH) is a contention based uplinkchannel used for transmission of relatively small amounts of data,e.g. for initial access or non-real-time dedicated control or trafficdata.
FACH The Forward Access Channel (FACH) is a common downlinkchannel without closed-loop power control used for transmission ofrelatively small amount of data.
BCH The Broadcast Channel (BCH) is a downlink channel used forbroadcast of system information into an entire cell.
PCH The Paging Channel (PCH) is a downlink channel used forbroadcast of control information into an entire cell allowingefficient UE sleep mode procedures. Currently identifiedinformation types are paging and notification. Another use could beUTRAN notification of change of BCCH information.
UTRAN Signaling Transport channels
....................................................................................................................................................................................................................................
4-22 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Commontransportchannels
Description
CPCH The Common Packet Channel (CPCH) is a contention based uplinkchannel (FDD) used for transmission of bursty data traffic. Thischannel is shared by the UEs in a cell
DSCH The Downlink Shared Channel (DSCH) is a downlink channelshared by several UEs carrying dedicated control or traffic data.
HS-DSCH The High Speed Downlink Shared Channel (HS-DSCH) is thetransport channel that carries the Physical Downlink SharedChannel (HS-PDSCH) and the Shared Control Channel HS-SCCH)for HSDPA.
UTRAN Signaling Transport channels
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-23
Logical channels...................................................................................................................................................................................................................................
Introduction
A set of logical channel types is defined for different kinds of data transfer services asoffered by MAC. Each logical channel type is defined by the type of informationtransferred as opposed to transport channels which define how data is transported.
Logical Channels
The following is a list of the logical channels:
Logicalchannels
Description
BCCH Broadcast Control Channel (BCCH) is a downlink channel forbroadcasting system control information.
PCCH The Paging Control Channel (PCCH) is a downlink channel thattransfers paging information. This channel is used when thenetwork does not know the location cell of the UE, or, the UE is inthe cell connected state (utilising UE sleep mode procedures).
CCCH The Common Control Channel (CCCH) is a Bi-directional channelfor transmitting control information between network and UEs. Thischannel is commonly used by the UEs having no RRC connectionwith the network and by the UEs using common transport channelswhen accessing a new cell after cell reselection.
CTCH The Common Traffic Channel (CTCH) is a point-to-multipointunidirectional channel for transfer of dedicated user information forall or a group of specified UEs.
DCCH The Dedicated Control Channel (DCCH) is a point-to-pointbi-directional channel that transmits dedicated control informationbetween a UE and the network. This channel is established throughRRC 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 DTCHcan exist in both uplink and downlink.
Channel mapping
The following figure illustrates the logical channels and their corresponding transportchannels that MAC is responsible for mapping:
UTRAN Signaling
...................................................................................................................................................................................................................................
4-24 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
S-SCH
S-CPICH
P-CPICH
PICH
PRACH
S-CCPCH
P-CCPCH
DPDCH
HS-DPCCH
DPCCH
HS-SCCH
E-DPCCH
E-DPDCH
HS-PDSCH
AICH
BCH
FACH
PCH
DCH
E-DCH
HS-DSCH
RACH
PCCH
BCCH
CTCH
DTCH
DCCH
CCCH
DPCH
P-SCH
E-AGCH
E-HICH
E-RGCH
Logical channels Transport channels
Physical channelsUplinkDownlinkBidirectionalData transferAssociation
Fixedchannels
UTRAN Signaling Logical channels
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-25
Air interface protocols
Overview...................................................................................................................................................................................................................................
Purpose
The purpose of this section is:
• 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 4-27
Radio Link Control 4-31
Packet Data Convergence Protocol (PDCP) 4-34
Radio Resource Control 4-35
RRC State Machine 4-38
RRC Connection and Signaling Connection 4-39
Signaling radio bearers 4-40
Radio bearer establishment 4-44
UTRAN Signaling
...................................................................................................................................................................................................................................
4-26 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Medium Access Control...................................................................................................................................................................................................................................
Medium Access Control
The MAC model maps the transport channels it receives from the physical layer to thelogical 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 (alsoknown as transport block) according to the Transport Format defined for the transportchannel. Each transport channel can have different bit rates. Thus, the MAC model isresponsible for transporting blocks of data according to the specified channel bit rate.
The illustration shows the position of the MAC protocol.
Physical Layer (PHY)
Medium Access Control (MAC)
RLC RLCRLC
RLC RLCRLC
RLCRLC
BMC
PDCP DCP
controlcontrol
GC Nt DC
Radio Resource Control(RRC)
cont
rol
Layer 3
L2/PDCP
L2/BMC
L2/RLC
LogicalChannelsL2/MAC
TransportChannelsL1PhysicalChannels
C-plane signaling U-plane information
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-27
Functions and Services
The MAC sublayer provides the following functions and services:
Function andservice
Description
Mapping betweenlogical channelsand transportchannels.
The MAC is responsible for mapping logical channel(s) onto theappropriate transport channel(s).
Selection ofappropriateTransport Formatfor each TransportChannel dependingon instantaneoussource rate.
Given the Transport Format Combination Set assigned by RRC,MAC selects the appropriate transport format within an assignedtransport format set for each active transport channel dependingon source rate. The control of transport formats ensures efficientuse of transport channels.
Priority handlingbetween data flowsof one UE.
When selecting between the Transport Format Combinations inthe given Transport Format Combination Set, priorities of thedata flows to be mapped onto the corresponding TransportChannels can be taken into account. Priorities may be givenaccording to attributes of Radio Bearer services and RLC bufferstatus. The priority handling is achieved by selecting a TransportFormat Combination for which high priority data is mapped ontolayer 1 with a″high bit rate″ Transport Format, at the same timeletting lower priority data be mapped with a″low bit rate″ (couldbe zero bit rate) Transport Format. Transport format selectionmay also take into account transmit power indication from layer1.
Identification ofUEs on commontransport channels.
When a particular UE is addressed on a common downlinkchannel, or when a UE is using the RACH, there is a need forinband identification of the UE. Since the MAC layer handles theaccess to, and multiplexing onto, the transport channels, theidentification functionality is naturally also placed in MAC.
Traffic volumemonitoring.
Measurement of traffic volume on logical channels and reportingto RRC. Based on the reported traffic volume information, RRCperforms transport channel switching decisions.
Ciphering This function prevents unauthorised acquisition of data. Cipheringis performed in the MAC layer for transparent RLC mode.
Data transfer This service provides unacknowledged transfer of MAC SDUsbetween peer MAC entities. This service does not provide anydata segmentation. Therefore, segmentation/reassembly functionshould be achieved by upper layer.
UTRAN Signaling Medium Access Control
....................................................................................................................................................................................................................................
4-28 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Function andservice
Description
Reallocation ofradio resources andMAC parameters.
This service performs on request of RRC execution of radioresource reallocation and change of MAC parameters, i.e.reconfiguration of MAC functions such as change of identity ofUE, change of transport format (combination) sets, change oftransport 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 oneMAC-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″ MACtransmission.
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 channelclass on FACH and RACH transport channels, i.e. whether it carries CCCH ordedicated logical channel information.
• The C/T field provides identification of the logical channel instance when multiplelogical channels are carried on the same transport channel. The C/T field is usedalso to provide identification of the logical channel type on dedicated transportchannels 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 ofthe above parameters may be used.
UTRAN Signaling Medium Access Control
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-29
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 onMAC: C/T field is included in MAC header.
• DTCH or DCCH mapped to RACH/FACH: C/D field and UE-Id are included inthe MAC header. C/T field is included if multiplexing on MAC is applied.
UTRAN Signaling Medium Access Control
....................................................................................................................................................................................................................................
4-30 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Radio Link Control...................................................................................................................................................................................................................................
Introduction
The Radio Link Control (RLC) protocol is situated between the Medium AccessControl and the Radio Resource Control protocols.
Radio Link Control
The Radio Link Control (RLC) protocol provides logical link control over the radiointerface.
There may be several simultaneous RLC links per User Equipment; each link isidentified by a bearer id.
RLC provides three types of Service Access Points (SAP), corresponding to threedifferent 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 withoutguaranteeing delivery to the peer entity.
3. In Acknowledged Mode (AM), RLC transmits upper layer PDUs guaranteeingdelivery to the peer entity. AM RLC is used for the packet-switched RABs.
Physical Layer (PHY)
Medium Access Control (MAC)
RLC RLCRLC
RLC RLCRLC
RLCRLC
BMC
PDCP DCP
controlcontrol
GC Nt DC
Radio Resource Control(RRC)
cont
rol
Layer 3
L2/PDCP
L2/BMC
L2/RLC
LogicalChannelsL2/MAC
TransportChannelsL1PhysicalChannels
C-plane signaling U-plane information
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-31
The following illustration shows the three different RLC data transfer modes:
Services offered by the 3 modes
The type of transmission mode used depends on the link direction and the channel typeto be transmitted. For example, in the UE downlink side, the CCCH may be sent inTM; the DCCH may be sent in AM or UM; the DTCH may be sent in TM, AM orUM.
Transparent mode services
RLC receives SDUs from the higher layers. RLC might segment the SDUs intoappropriate RLC PDUs without adding any overhead. How to perform thesegmentation is decided upon when the service is established. RLC delivers the RLCPDUs to MAC through either a BCCH, PCCH, DCCH, or a DTCH. Which type oflogical 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 segmentedinto 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 thendecides which PDUs and when the PDUs are delivered to MAC.
The RLC also decides which logical channel should be used. The number of logicalchannels that is needed is decided upon when the service is established. The type ofthe logical channels depends on if the higher layer is located in the control plane(DCCH) or in the user plane (DTCH).
Radio Resource Control
Transparentmode
Acknowledgedmode
Unacknowledgedmode
RLC
MAC
L1
UTRAN Signaling Radio Link Control
....................................................................................................................................................................................................................................
4-32 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Unacknowledged mode services:
• Segmentation and reassembly
• Concatenation
• Transfer of user data.
Acknowledged mode services
RLC receives SDUs from the higher layers. For a packet switched service, the RLCSDU is normally one IP packet. The SDUs are segmented and/or concatenated toPDUs of fixed length. The length of the PDUs is decided upon when the service isestablished. After that RLC adds a header and the PDU is placed in the retransmissionbuffer and the transmission buffer.
The RLC then decides which PDUs and when the PDUs are delivered to MAC, e.g. itcould be useful to send RLC control PDUs on one logical channel and data PDUs onanother logical channel. The retransmission buffer also receives acknowledgementsfrom the receiving side, which are used to indicate retransmissions of PDUs and whento delete a PDU from the retransmission buffer.
Acknowledged mode services
• Segmentation and reassembly
• 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 allowsetting up different automatic repeat request (ARQ) schemes. An AM RLC entity isconfigured by approximately 20 parameters. Proper setting and optimisation of theseparameters is vital to provide packet-switched RABs with the required quality ofservice (QoS).
UTRAN Signaling Radio Link Control
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-33
Packet Data Convergence Protocol (PDCP)...................................................................................................................................................................................................................................
Introduction
PDCP is a layer–2, user plane protocol, located above the Radio Link Control protocol.
Header compression and decompression
The PDCP protocol provides header compression and decompression of IP data streamsat the transmitting and receiving entities respectively. Header compression algorithmsare available for TCP/IP, RTP/UDP/IP.
Transfer of user data
Transmission of user data means that PDCP receives PDCP SDU from the NAS andforwards 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 bufferingcapabilities. Each PDCP SDU is numbered from 0 — 255 and buffered until the RLCacknowledges the reception of transmitted PDCP PDPs. Once the acknowledgementarrives, data flow can recommence.
Physical Layer (PHY)
Medium Access Control (MAC)
RLC RLCRLC
RLC RLCRLC
RLCRLC
BMC
PDCP DCP
controlcontrol
GC Nt DC
Radio Resource Control(RRC)
cont
rol
Layer 3
L2/PDCP
L2/BMC
L2/RLC
LogicalChannelsL2/MAC
TransportChannelsL1PhysicalChannels
C-plane signaling U-plane information
UTRAN Signaling
...................................................................................................................................................................................................................................
4-34 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Radio Resource Control...................................................................................................................................................................................................................................
Introduction
Radio Resource Control (RRC) handles the control plane signaling of layer 3 betweenthe UEs and UTRAN
The following illustration shows the position of the RRC protocol in the RadioInterface Protocol architecture.
Interfaces
The RRC provides the signaling interface to the non-access stratum with the followingservices (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 linksto each of the lower layers.
The following illustration shows the lower layer interactions of the RRC.
Physical Layer (PHY)
Medium Access Control (MAC)
RLC RLCRLC
RLC RLCRLC
RLCRLC
BMC
PDCP DCP
controlcontrol
GC Nt DC
Radio Resource Control(RRC)
cont
rol
Layer 3
L2/PDCP
L2/BMC
L2/RLC
LogicalChannelsL2/MAC
TransportChannelsL1PhysicalChannels
C-plane signaling U-plane information
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-35
The arrows going to the RRC show the RRC receiving measurement data from thelower layers, the arrows going from the RRC show the RRC sending control messagesto the lower layers.
Functions
The RRC performs the following functions:
• Broadcast of information provided by the non-access stratum (Core Network): TheRRC 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 ofan RRC connection is initiated by a request from higher layers at the UE side toestablish 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 thenetwork to selected UEs. Higher layers on the network side can request paging andnotification. The RRC layer can also initiate paging during an established RRCconnection.
L1
MAC
RLC
RRC
L1
MAC
RLC
RRC
UTRAN UE
Radio ResourceAssignment(mapping, TF setfrequency, codeTS, etc)
RLC transmissioncontrol
UTRAN Signaling Radio Resource Control
....................................................................................................................................................................................................................................
4-36 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• Control of requested QoS.
• RRC connection mobility functions: The RRC layer performs evaluation, decisionand execution related to RRC connection mobility during an established RRCconnection, such as handover, preparation of handover to GSM, cell re-selectionand cell/paging area update procedures.
• UE measurement reporting and control of the reporting.
• Outer loop power control.
UTRAN Signaling Radio Resource Control
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-37
RRC State Machine...................................................................................................................................................................................................................................
RRC state machine
The RRC state machine is a description model of how the UE and the UTRANco-operate regarding RRC functionality.
The RRC state machine exists as two peer entities (UE and UTRAN). The two peerentities 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 anRRC connection. In idle mode, the UE is identified by non-access stratum identitiessuch as IMSI, P-TMSI and TMSI. In addition, the UTRAN has no information aboutthe individual idle mode UEs, and can only address either all UEs in a cell or all UEsin 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 isassigned a radio network temporary identity (RNTI) to be used as UE identity oncommon transport channels. The UE leaves connected mode and returns to idle modewhen 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 beidentified on the BCCH. URA is only internally known in the UTRAN.
• Cell level: different channel types can be used for data transfer such as Commontransport channels (RACH, FACH, CPCH, DSCH) or Dedicated transport channels(DCH).
UTRAN Signaling
...................................................................................................................................................................................................................................
4-38 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RRC Connection and Signaling Connection...................................................................................................................................................................................................................................
Definitions
RRC connection An RRC connection is a point-to-point bi-directional connectionbetween RRC peer entities on the UE and the UTRAN sides.
Signaling connection An acknowledged-mode link between the UE and the CN totransfer 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, thesignaling connection provides the resources necessary for all signalling messagesbetween the UE and the core network (MSC or SGSN). Such signaling messages couldbe for example, session management messages, such as a PDP context request; orMobility Management messages, such as those used in handover signaling.
The following illustration shows the RRC and the RANAP connections that make upthe signaling connection.
Uu Node B IuIub RNCUE
RANAPRRC RANAPRRC
RRC Connection RANAP Connection
Signaling Connection
Relay
SGSN\MSC
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-39
Signaling radio bearers...................................................................................................................................................................................................................................
Definitions
Signaling radio bearer The radio bearers available for transmission of RRC messagesare defined as “signalling radio bearers”.
Signaling connection An acknowledged-mode link between the UE and the CN totransfer higher layer information between the entities in the non-access stratum (viaRRC and RANAP).
RRC connection establishment in DCH state
This example shows the steps taken during the establishment of an RRC connection inDCH state.
UTRAN Signaling
...................................................................................................................................................................................................................................
4-40 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 messageConnection Request on the CCCH.
2. Radio Link Setup Request
1. CCCH: RRC Connection Request
3. Radio Link Setup Response
4. ALCAP Iub Data Transport Bearer Setup
UENode BServing RNS Serving RNC
5. Downlink Synchronization
6. Uplink Synchronization
7. CCCH: RRC Connection Setup
8. DCCH: RRC Connection Setup Complete
Select L1 +L2parameters
UTRAN Signaling Signaling radio bearers
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-41
...................................................................................................................................................................................................
2 After performing Call Admission Control (CAC), the SRNC decides to use a DCH forthis 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 tothe Node B.
...................................................................................................................................................................................................
3 The Node B allocates resources, starts PHY reception, and responses with the NBAPmessage Radio Link Setup Response.
...................................................................................................................................................................................................
4 The SRNC initiates the set-up of an Iub data transport bearer using the ALCAPprotocol. The request for the set-up of an Iub data transport bearer is acknowledged bythe Node B.
...................................................................................................................................................................................................
5 The Node B and the SRNC establish synchronism for the Iub and Iur data transportbearer by means of exchange of the appropriate DCH frame protocol frames downlinksynchronization.
...................................................................................................................................................................................................
6 The Node B and the SRNC establish synchronism for the Iub and Iur data transportbearer by means of exchange of the appropriate DCH frame protocol frames uplinksynchronization. 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 theSRNC.
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 thehigher layers (RLC AM)
UTRAN Signaling Signaling radio bearers
....................................................................................................................................................................................................................................
4-42 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• 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 severalsignaling radio bearers may be set up for transferring RRC signaling messagesusing 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 entitieswith the parameters given by the network-side RRC.
The following illustration shows the newly created signaling radio bearers after thecreation of the RRC connection.
Physical Layer (PHY)
Medium Access Control (MAC)
RLCRLC
RLCRLC
control Radio Resource Control(RRC)control
cont
rol
cont
rol
New RLCentities
MACparameters
L1Parameters
C-plane signaling U-plane information
SignalingRadioBearers
UTRAN Signaling Signaling radio bearers
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-43
Radio bearer establishment...................................................................................................................................................................................................................................
Definitions
Radio bearer A service provided by the RLC layer for transfer of user data betweenUE and SRNC.
Radio access bearer The service that the access stratum provides to the non-accessstratum for transfer of user data between UE and CN. Consists of radio bearerservice 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
...................................................................................................................................................................................................................................
4-44 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Radio Access Bearer establishment process
The following is a description of the Radio Access Bearer connection establishmentprocess:
...................................................................................................................................................................................................
1 The SGSN initiates the process by sending a RAB assignment request to the RNCindicating the RAB configuration and also passing the UL GTP tunnel Paramaters.
ALCAP
ALCAP
RRC RB Setup Complete
MSCRNCNode BUE
RANAPRAB Assignment Request
NBAP
NBAP
NBAP
RRC RB Setup Request
DCCH
DCCH
RL Reconfigure Prepare
RL Reconfigure Ready
RL Reconfigure Commit
ERQ (Establish Request)
ECF (Establish Confirm)
RANAPRAB Assignment Response
FP DL Synchron.
FP UL Synchron.
ALCAP
ALCAP
ERQ (Establish Request)
ECF (Establish Confirm)
UTRAN Signaling Radio bearer establishment
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-45
...................................................................................................................................................................................................
2 The UE already has a Radio Link setup, this procedure requires that a DTCH be addedto 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 changesyet.
...................................................................................................................................................................................................
3 Once the RL has been reconfigured in the Node B, the RNC sets up the AAL2 bearerto carry it. This is done via ALCAP Establish procedures and is followed by FPsynchronisation.
...................................................................................................................................................................................................
4 When the AAL2 connection is ready, the RNC instructs the Node B to commit thechanges it had prepared in the reconfiguration. The Commit message indicates theFrame number at which the change should occur.
...................................................................................................................................................................................................
5 The UTRAN has been configured for the new DTCH, so the UE can now be instructedto set up the Radio Bearer. The RNC does this via an RRC RB set-up request. Thisincludes 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 ofan RRC RB set-up Complete.
...................................................................................................................................................................................................
7 Reception of the set-up complete message by the RNC indicates that RAB assignmentprocedure is complete, it indicates this back to the SGSN via a RANAP RABassignment 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 theRadio Access Bearer.
UTRAN Signaling Radio bearer establishment
....................................................................................................................................................................................................................................
4-46 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Physical Layer (PHY)
Medium Access Control (MAC)
RLCRLC
RLCRLC
control Radio Resource Control(RRC)
cont
rol
New RLCentity
MACparameters
L1Parameters
C-plane signaling U-plane information
New RadioBearer
RLC
PDCP DCP
BMC
UTRAN Signaling Radio bearer establishment
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-47
UTRAN protocols
Overview...................................................................................................................................................................................................................................
Purpose
The purpose of this section is:
• to describe the protocol structure of the UTRAN interfaces
• to map the UTRAN protocols to their specific layers on the Control Plane and UserPlane
• to explain the function of the UTRAN protocols.
Contents
Iub protocol structure 4-49
Protocols of the Iub interface 4-51
Iur interface 4-54
Iu-cs interface 4-56
UTRAN Signaling
...................................................................................................................................................................................................................................
4-48 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Iub protocol structure...................................................................................................................................................................................................................................
Iub protocol structure
The following illustration shows the protocol structure of the Iub interface.
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 radionetwork user plane.
• The Transport Layer defines procedures for establishing physical connectionsbetween Node B and the RNC.
PhysicalLayer
Transport NetworkControl Plane
TransportNetworkLayer
NBAP
AAL5 AAL2
Transport NetworkUser plane
User PlaneControl Plane
RadioNetworkLayer
Transport NetworkUser plane
CP
CH
FP
US
CH
FP
DS
CH
FP
PC
H F
P
AAL5
FAC
H F
PR
AC
H F
PD
CH
FP
SSCOP
SSCF-UNISSCOP
ALCAP Q.2630.2
STC Q.2150.2
SSCF-UNI
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-49
Functional Separation
In order to maintain a concise structure, on the Iub interface the radio network layerand the transport layer are clearly separated. Therefore, the radio network signaling andIub data streams are separated from the data transport resource and traffic handling.This resource and traffic handling is controlled by the transport signaling. The transportsignalling is carried by a signalling bearer over the Iub interface.
UTRAN Signaling Iub protocol structure
....................................................................................................................................................................................................................................
4-50 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Protocols of the Iub interface...................................................................................................................................................................................................................................
Logical structure of the Iub interface
The following illustration shows the UTRAN protocol architecture with the protocolsof the Iub highlighted.
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.
RANAP
SSCOP
Uu Node B Iu-psIub RNC SGSNUE
SCCP
PMM
SMPMM
-
ATM
STM
AAL5
1
IP
GTP-U
UDP
SM
MAC
Phy-up
PHY
RRC
IP
PDCP
RLC
ATM
E1/ STM-1
AAL2 AAL5
NBAP
PHY
ALCAP
SSCOP
STC.2
SSCF -UNIFP
SSCOP
NBAP
AAL5 AAL2
SSCOP
MTP3-b
SSCF-N
SCCP
RANAP
RRC
ATM
STM- 1
GTP-U
UDP
PDCP
ALCAP
STC.2
SSCF -UNIIP
RLC
MAC
Phy
FP
-up
AAL5
User plane
Control plane
MTP3-b
SSCF-N
UTRAN Signaling
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-51
Access Link Control Application Part
The Access Link Control Application Part ALCAP over SSCOP on AAL5 provides thedynamic setup and teardown of data bearers over AAL2 links. ALCAP is notresponsible for signaling bearers, ensuring the separation of the two domains. Theapplication protocol of the control plane, NBAP, requests ALCAP to create or teardown 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 sentbetween 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 5and the NBAP and ALCAP processing entities.
The SSCF-UNI maps the requirements of the layer above to the requirements ofSSCOP. Also SAAL connection management, link status and remote processor statusmechanisms are provided. SSCOP provides mechanisms for the establishment andrelease of connections and the reliable exchange of signaling information betweensignaling entities. It adapts the upper layer protocol to the requirements of the LowerATM cells.
Framing protocols
The AAL2 links are used to carry user plane data which are encapsulated in variousFraming Protocols (DCHFP, FACHFP and RACHFP)
ATM Adaptation Layer
The ATM Adaptation Layer (AAL) is defined to enhance the services provided by theATM 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 AALservice 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 ATMbackbone network.
UTRAN Signaling Protocols of the Iub interface
....................................................................................................................................................................................................................................
4-52 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
The physical layer
The PCM30 or PCM24 interface (E1 or T1) is used on the Iub interface as the physicallayer at the Node B. ATM concentrators are used to combine the PCM30/PCM24carriers to STM-1 or OC-3 which is the physical interface at the RNC.
UTRAN Signaling Protocols of the Iub interface
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-53
Iur interface...................................................................................................................................................................................................................................
Introduction
Several different higher-layer protocols are used on the Iur interface. This topicprovides a short explanation for each of them.
Interface diagram
The following figure shows the location of the Iur interface in the UMTS network.
Physical layer
The SDH STM-1 or the SONET OC-3 interface is used on the Iur interface as thephysical layer.
ATM
ATM is used on the Iur interface for the transportation of packages using the ATMbackbone network.
VLR
MSC
Core Network
IuCS IuPSIuPS IuCS
IubIubIubIub
Node B
Cells CellsCellsCells
Node BNode BNode B
SGSN
IurRNC RNC
UTRAN Signaling
...................................................................................................................................................................................................................................
4-54 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RNSAP
The Radio Network Subsystem Application Part (RNSAP) protocol is used for allcontrol 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 controlof 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 Iur interface
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-55
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 thecore 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) opticalinterfaces.
Protocols used
The WAG supports the following protocol stack for the Iu-cs interface:
RadioNetwork
Control Plane
RadioNetwork
Layer
User Plane
TransportNetwork
Layer
TransportNetwork
Control Plane
RANAP User planeprotocol
SCCP
MTP3-B
SSCF-NNI
SSCOP
AAL5 AAL5
SSCOP
SSCF-NNI
MTP3-B
Q.2150.1
Q.2630.1
AAL2
STM-1
ATM
UTRAN Signaling
...................................................................................................................................................................................................................................
4-56 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
UTRAN Signaling Iu-cs interface
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
4-57
Part II: Optimization process
Overview...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 5, Optimization process 5-1
Chapter 6, Drive testing 6-1
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
II-1
5 5Optimization process
Overview...................................................................................................................................................................................................................................
Purpose
This lesson describes when optimization is performed during a network lifecycle andthe phases of the optimization process.
Contents
Network lifecycle 5-2
Optimization process phases 5-4
Planning and preparation (site readiness) 5-7
Drive test optimization before live traffic 5-9
Information gathering 5-11
Information analysis 5-12
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
5-1
Network lifecycle...................................................................................................................................................................................................................................
Network lifecycle
Stages of the lifecycle of a network:
Network lifecycle stages
This shows the stages in the lifecycle of a network and the place of optimization in thelifecycle:
...................................................................................................................................................................................................
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 softwarethat provides recommendations for:
• Antenna tilt and orientation
• Power levels.
Network design
In serviceoptimization
Optimization Planning
Live network
Implementation
Network design& implementation
Y
N Acceptancecriteria met?
Optimization process
...................................................................................................................................................................................................................................
5-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
...................................................................................................................................................................................................
3 Sites are planned and engineered according to the network design.
This translates the design in equipment in the real environment. This can mean thatthere 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 completedsite.
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. Datafrom the drive tests, together with installation and parameter data from the site, is usedas 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 ifthe network complies to the customer requirements.
If the customer accepts the network, the network goes live and commercial use canbegin.
...................................................................................................................................................................................................
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 includenew cells, thus restarting this process.
Optimization process Network lifecycle
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
5-3
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:
Sufficientinformation?
Y
N
Y
N
Identify reason
Determine solution
Implement solution
Begin
Gather information
Analyze information
Optimizationproblem?
N
Gather and analyzeinformation
Problemsolved?
Y
Optimization process
...................................................................................................................................................................................................................................
5-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 bestsolution, 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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
5-5
Result: Implementation can range from a simple change of a OMC-UPS parameterto the entire process of design, planning, engineering and optimization andcommissioning 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 toStage 1.
the problem is not solved, Restore the original settings when parameters werechanged.
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 livenetwork 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.
Optimization process Optimization process phases
...................................................................................................................................................................................................................................
5-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Planning and preparation (site readiness)...................................................................................................................................................................................................................................
Introduction
Before optimization is performed, site readiness checks should be performed. Thesechecks ensure that all cells are operating as required.
Important:
Site readiness checks are usually performed after a new network or new cells aredeployed and before the network goes operational. When they have been performedand satisfactory performance can be guaranteed, the checks do not have to be madeanymore.
Checks
Site readiness checks include:
• Spectrum clearance
• Antenna check
• Sector verification.
Spectrum clearance
Spectrum clearance ensures no external interference is present and sufficient guardbands are obeyed.
Detection of interference can be very time-consuming and difficult once the UMTSsystem is up and running. It is desirable to have a high degree of confidence that thespectrum 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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
5-7
Sector verification
Sector verification ensures the basic functionality of a sector. This includes basic callprocessing and handovers. Measurements are made on UMTS signal levels to verifythat each sector is transmitting with the appropriate power levels and the correctscrambling 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 testterminal. Once all data from the sector tests have beencollected, the measurement datacan be post-processed. If sector problems do occur, they need to be remedied and thetests repeated until they are successful.
Baseline existing system
The objective of baselining the existing system is to collect the RF performancemetrics of the existing UMTS system equipment. Baseline driving should be performedprior to any RF optimization activity and involves measuring the Key PerformanceIndicators. It is important to keep the drive routes and KPIs identical for performancevalidation and comparison purposes.
Optimization process Planning and preparation (site readiness)
...................................................................................................................................................................................................................................
5-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Drive test optimization before live traffic...................................................................................................................................................................................................................................
Purpose
Before a network takes on live traffic, an optimization using drive tests is usuallyperformed. These drive tests are performed to correct problems and to prove that thenetwork meets customer requirements.
Stages
This illustrates optimization steps that are performed before a network is commerciallydeployed:
...................................................................................................................................................................................................
1 Perform site readiness checks.
This ensures all cells are operating as required.
Site readiness checks include:
• 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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
5-9
• 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.
Optimization process Drive test optimization before live traffic
...................................................................................................................................................................................................................................
5-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 multiplesources of information are needed.
The main information sources are:
• Key performance indicators
• Drive tests
• Customer complaints.
Information from one of these sources, can trigger further investigation. During themore detailed investigation information from other sources is gathered.
Key performance indicators
Key performance indicators (KPI) are used to determine if the network complies to thelevels 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 areoften the first indication of an optimization problem.
Drive tests
Drive tests can be used to gather information in the network. A drive test can beperformed to gather information about a specific problem or problem area. Drive testscan also be performed to gather general information about the network performance.
Customer complaints
Customer complaints can provide an indication of problems. Especially if multiplecomplaints can be related to one source. Customer complaints can point to a problemon a specific location, time or related to a resource.
Optimization process
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
5-11
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 andprotocols in a network work. This allows the engineer to link information and events toa 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 theproblem 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 thelarge volumes of detailed information that is available. Engineers can use softwaretools to handle the information and determine if there are problems.
Software tools can also be used to determine the consequences of implementing asolution in the network. Using models, software can simulate the impact on thenetwork of implementing a solution.
Commercially available and proprietary tools are available to analyze information anddetermine impacts.
Optimization process
...................................................................................................................................................................................................................................
5-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
6 6Drive testing
Overview...................................................................................................................................................................................................................................
Purpose
Contents
Drive test optimization process 6-2
Planning and preparation (site readiness) 6-4
Optimization planning 6-6
Perform cluster optimization 6-8
Perform system verification 6-11
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
6-1
Drive test optimization process...................................................................................................................................................................................................................................
Purpose
Before a network takes on live traffic, optimization using drive tests is usuallyperformed. These drive tests are performed to correct problems and to prove that thenetwork meets customer requirements.
Stages
The following is the optimization process that is performed prior to a network beingcommercially deployed:
...................................................................................................................................................................................................
1 Perform site readiness checks.
This ensures all cells are operating as required.
Site readiness checks include:
• 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
...................................................................................................................................................................................................................................
6-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• 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 Drive test optimization process
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
6-3
Planning and preparation (site readiness)...................................................................................................................................................................................................................................
Introduction
Before optimization is performed, site readiness checks should be performed. Thesechecks ensure that all cells are operating as required.
Important:
Site readiness checks are usually performed after a new network or new cells aredeployed and before the network goes operational. When they have been performedand satisfactory performance can be guaranteed, the checks do not have to be madeanymore.
Checks
Site readiness checks include:
• Spectrum clearance
• Antenna check
• Sector verification.
Spectrum clearance
Spectrum clearance ensures no external interference is present and sufficient guardbands are obeyed.
Detection of interference can be very time-consuming and difficult once the UMTSsystem is up and running. It is desirable to have a high degree of confidence that thespectrum 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
...................................................................................................................................................................................................................................
6-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Sector verification
Sector verification ensures the basic functionality of a sector. This includes basic callprocessing and handovers. Measurements are made on UMTS signal levels to verifythat each sector is transmitting with the appropriate power levels and the correctscrambling 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 testterminal. Once all data from the sector tests have beencollected, the measurement datacan be post-processed. If sector problems do occur, they need to be remedied and thetests repeated until they are successful.
Baseline existing system
The objective of baselining the existing system is to collect the RF performancemetrics of the existing UMTS system equipment. Baseline driving should be performedprior to any RF optimization activity and involves measuring the Key PerformanceIndicators. It is important to keep the drive routes and KPIs identical for performancevalidation and comparison purposes.
Drive testing Planning and preparation (site readiness)
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
6-5
Optimization planning...................................................................................................................................................................................................................................
Introduction
The optimization planning phase ensures system and tool readiness for RF optimizationbefore beginning the actual drive testing.
Perform RF parameter audit
At the beginning of the RF optimization process, RF parameters must be inspected forconsistency 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 theneighbor relations with network design plots. Neighbor relations need to be verified forrecent updates, validity and appropriateness. The recommended strategy is to have aminimum 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 numberused is based on network expansion as well as on the topographical environment. Theclusters are selected to provide a center cell site with two rings of surrounding cellsites as shown in the figure below.
It may be worthwhile to utilize natural barriers such as hills and water bodies forcluster separation to minimize overlap and influence between the clusters. A little cellsite overlap should remain between each cluster to ensure continuity across theboundaries.
The following figure shows
Drive testing
...................................................................................................................................................................................................................................
6-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 driveroute should maintain a distance equal to 1/2 of the cell site radius. Sector drive routesusually do not require customer approval.
Planning drive routes for Cluster Optimization
The routes for Cluster Optimization should consist of major roads, highways andhotspots. Total time to drive all routes in a typical cluster should be approximately 6 to8 hours.
One control route per cluster is chosen to verify system performance. A control route isa 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 overlappingcluster regions. A border route is chosen by the way it crosses the cluster borderswithout going into the cluster areas.
Planning drive routes for System Verification.
The System Verification drive routes are used to collect the metrics for the ExitCriteria. The routes are a combination of the cluster control routes and routes betweenthe individual clusters.
2
1
C
7
6
8
B
9 10 11
A 3
4
5
Drive testing Optimization planning
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
6-7
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 coreactivity is to provide system tuning, as well as data collection and reporting. Designchanges relating to cell site layout modifications or adding a new cell site may beconsidered if critical coverage holes are discovered during optimization.
Antennae corrective actions are more frequent for new deployments, such as Greenfieldor Overlay scenarios. They are uncommon in existing systems, such as NetworkExpansion or Additional Carrier System. Fine tuning of the transmit powers is the mosteffective procedure in already optimized networks.
Cluster size
Cluster optimization consists of procedures performed on geographical groupings ofcell sites that are large enough to have meaningful multi-cell site optimization. Severalfactors make it worthwhile to optimize the system in manageable sized clusters. Thereis a better focus on the area optimized, as smaller sector numbers make it easier totrack the parameter changes and the impact of their performance.
Another benefit to smaller cluster optimization is that multiple teams can optimizedifferent clusters simultaneously. Each team is able to maintain focus on its clusterwith minimal impact from other teams. In addition, smaller cluster optimization aids inspeeding up the system tests for commercial operation. Optimization in equippedclusters 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 laterintegrated. All cell sites in the network (or a network section) are switched on. Eachcluster is tested under unloaded and loaded conditions. If live traffic exists, cells in thetested 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 thenetwork or network sections before continuing with the loaded cluster tests. After asmall set of adjacent clusters pass the exit criteria, a border exit drive must beperformed. The border exit drive is performed under loaded conditions in order toverify and confirm the exit criteria at the borders of the clusters.
Drive testing
...................................................................................................................................................................................................................................
6-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Multiple cluster testing
During multiple cluster testing the optimization teams working on neighbor clustersmust coordinate activities especially regarding neighbor relations, loading conditions orpossible overshooting sites. Also, the UMTS on GSM overlay must be scanned forscattered coverage or coverage holes.
Cluster optimization tools
The required data collection, processing and analysis tools for cluster optimization area phone-based data collection tool kit including CAIT3G, a UMTS terminal, WINDSas 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 Agilentscanner is an important tool due to its multiple pilot measurement capability, which isespecially useful for more in depth coverage analysis (e.g. pilot pollution) inchallenging 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 underunloaded network conditions using the optimization route. Once the data from the firstphase is collected, problem spots are identified and optimized. The unloaded drive testidentifies coverage holes, handover regions and multiple pilot coverage areas. It alsospots possible overshooting sites (where interference is minimal) from areas belongingto neighbor clusters.
The first pass might lead to correction of neighbor lists and adjustments of thefundamental RF parameters such as transmit powers and/or antenna azimuths andantenna tilts. The drive test information highlights fundamental flaws in the RF designunder best-case conditions.
Loaded cluster optimization
The second cluster optimization phase is performed under loaded conditions. The driveroutes for the loaded cluster optimization are exactly the same routes as those used forthe unloaded measurement drives.
Drive testing Perform cluster optimization
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
6-9
Loaded testing produces a rise in the noise floor, which has the effect of shrinking thecoverage area (cell breathing). This causes an increase of negative Ec/Io values,identify potential coverage holes, results in higher BLER, results in lower mobilitythroughput, and more dropped calls.
The objective is to fix the problems observed by the field teams. This involves thefine-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 alsooccasionally performed.
Problematic cluster
Problem areas may be re-driven after implementing changes. It is not recommended todrive a problem area more than three times. If the problem cannot be solved after threetest drives, either a root cause analysis is performed or cluster optimization proceedswith the next cluster. It is generally not recommended to attempt resolution ofcomplex, time-intensive performance issues, such as location-specific problems likecell site equipment failures. For such problems, it is advisable to report the behaviorand 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 bythe customer.
The final statistics from the cluster exit drive are presented to the customer forapproval. These statistics contain plots as well as data in tabular form. The approval toexit the cluster is based on the terms of the contract. Approval with exceptions allowsthe cluster to be exited under the condition that any problems will be resolved duringsystem wide optimization. If the cluster is not approved, loaded cluster optimizationmust be continued until the troubles are resolved. A report specifying the reasons whythe exit drive did not pass the exit criteria is required.
Drive testing Perform cluster optimization
...................................................................................................................................................................................................................................
6-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Perform system verification...................................................................................................................................................................................................................................
The final phase
System verification is the final phase of the RF Drive Test Based Optimization activityand it focuses specifically on collecting overall performance statistics. Systemverification begins after all clusters in the UMTS network have been tested. It isperformed under loaded conditions with all cells activated. System verification involvesfusion of the previously optimized clusters and once again is required to demonstratethat Exit Criteria are met system-wide.
A comprehensive drive test
System verification is a comprehensive drive test covering the major highways andprimary roads in the defined coverage area. There is a focus on the problem areasidentified during the Cluster Optimization (system verification driving routes). Theprocedures and analysis are identical to those used in Cluster Performance Verification.Performance data will be collected and statistics will be made to characterize coverageand performance over the entire network.
The system drive routes should not be used for optimization. System drives do notallow changing parameters due to side effects. Optimizing a system route can result invery good performance on the system verification driving routes but poor performanceelsewhere. 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 acase-by-case basis after the entire drive has been completed. Individual ClusterOptimization drives are used to fix existing coverage problems by adjusting transmitpowers and neighbor lists. In extreme situations, handover thresholds, channel powerparameters or other low tuning parameters may require modification. After anyparameter changes are made, another drive test must be completed to ensure thesurrounding regions are still performing properly.
Ready for live traffic
The final statistics from the system verification phase are presented for approval. Thesame tools that were used for Cluster Optimization are used for the system verificationphase. At the end of the system-wide drive test phase, the RF Optimization procedureis considered complete. The UMTS network is ready for live traffic testing leading intocommercial service. Once significant loading with live traffic is present on the
Drive testing
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
6-11
network, additional tuning of system parameters will be required to accommodateuneven traffic conditions (e.g. traffic hot spots) and other dynamic effects which cannotbe modeled with simulated traffic loading.
It is possible for problem areas to remain after system verification is complete. Anexample 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.
Drive testing Perform system verification
...................................................................................................................................................................................................................................
6-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Part III: Optimization andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 7, UTRAN key performance indicators 7-1
Chapter 8, Call availability optimization and troubleshooting 8-1
Chapter 9, Call reliability optimization and troubleshooting 9-1
Chapter 10, Call quality optimization and troubleshooting 10-1
Chapter 11, Call mobility optimization and troubleshooting 11-1
Chapter 12, Throughput optimization and troubleshooting 12-1
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
III-1
7 7UTRAN key performanceindicators
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 7-2
KPI example - CS IRAT HO success rate (UMTS -> GSM) 7-6
CS IRAT HO success rate (UMTS -> GSM) 7-7
Performance counter trigger event basis 7-8
Parameter trigger event basis 7-10
Parameter setting 7-12
Parameter discussion 7-13
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-1
Performance Counters and Key Performance Indicators...................................................................................................................................................................................................................................
What are Performance Counters?
The Performance Counters are metrics that may be used to assess the performance ofprocess steps within a UMTS network. The 3GPP standards define four types ofmeasurement 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 ofperformance 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 measurementjob will be active. The amount of data that is collected by a network element isdetermined 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
...................................................................................................................................................................................................................................
7-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 thePerformanceMeasurements Definitions Manual, UMTS-04.03/IMS 5.0,401-382-803R04.03.
What are Key Performance Indicators?
The Key Performance Indicators are metrics that may be used to assess theperformance of a UMTS network. Such assessments may be used as a general healthcheck on a network, or in a warranty situations where it is important to ascertainwhether the deployed network is achieving a level of performance consistent with thecustomer design requirements.
The Key Performance Indicators are clear, simple, unambiguous and measurablemetrics on which the vendor can commit with the customer during the contractsdefinition and can be asked to demonstrate their validity on live networks.
PM counters and KPIs are powerful measure to evaluate the performance of wirelessnetworks.
Available Key Performance Indicators
Key Performance Indicators are available within the UTRAN in following areas:
• Accessibility performance indicators
• Reliability (call drop) performance indicators
collection start
Time
transferred
computed
Interval
Recording Interval
Reporting Period
measurement Job
Full Hour
12:00 14:00
collection stop
Measurement
Results
Aggregation
Create or Resume
Measurement
Results
UTRAN key performance indicators Performance Counters and Key Performance Indicators
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-3
• 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 reconfigurationperformance 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
UTRAN key performance indicators Performance Counters and Key Performance Indicators
...................................................................................................................................................................................................................................
7-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• Common control channel / load performance indicators
• Location services performance indicators.
For detailed information refer to the relevant chapters in thePerformanceMeasurements Definitions Manual, UMTS-04.03/IMS 5.0,401-382-803R04.03.
Difference between Drive Test data and KPI data
PM counters and KPIs reflect the network viewpoint, whereas Drive Test data reflectthe subscriber’s viewpoint.
UTRAN key performance indicators Performance Counters and Key Performance Indicators
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-5
KPI example - CS IRAT HO success rate (UMTS -> GSM)...................................................................................................................................................................................................................................
KPI definition
This Key Performance Indicator provides the number of successful outgoing circuitswitched Inter-RAT handovers based on the strongest cell of the Active link versus thenumber of attempted relocation preparations for outgoing circuit switched Inter-RAThandovers per cell from the UE’s point of view.
The Performance Measurements Definitions Manual, UMTS-04.03/IMS 5.0,401-382-803R04.03 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).
UTRAN key performance indicators
...................................................................................................................................................................................................................................
7-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
CS IRAT HO success rate (UMTS -> GSM)...................................................................................................................................................................................................................................
Description
This KPI indicates the overall hard handover inter RAT performance towards GSMnetwork for CS calls starting from the relocation attempt.
Relocation attempts are triggered by transmission of a RANAP messageRELOCATION REQUIRED from the SRNC to the MSC, indicating an attemptedrelocation preparation of a UMTS to GSM handover.
Note: Normally released calls during IRAT should not be considered for this successratio. They are subtracted from the attempts.
Formula
The formula to calculate the CS IRAT HO success rate (UMTS -> GSM):
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.
IRATHO.SuccOutCS= x 100
IRATHO.AttRelocPrepOutCS - IRATHO.FailRelocPrepOutCS.RelocCanc
UTRAN key performance indicators
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-7
Performance counter trigger event basis...................................................................................................................................................................................................................................
Performance counter trigger conditions
The following trigger conditions apply for the performance counters of this KPI:
• IRATHO.AttRelocPrepOutCSThe counter is incremented on transmission of a RANAP message RELOCATIONREQUIRED from the SRNC to the MSC, indicating an attempted relocationpreparation of a UMTS to GSM handover.
• IRATHO.SuccOutCSThe counter is incremented on receipt of a RANAP message IU RELEASECOMMAND sent from the CS CN to the serving RNC, indicating a successfulinter-RAT handover with cause IE set to “Successful Relocation (11)” or “NormalRelease (83)”.
• IRATHO.FailRelocPrepOutCS.RelocCancThe counter is incremented on receipt of a RANAP message RELOCATIONPREPARATION FAILURE containing the cause, “Relocation Cancelled (10)”, sentfrom the MSC to the SRNC indicating a failed relocation preparation for UMTS toGSM.
In case the best cell is on the SRNC, the cell MO representing the best cell isincremented. In case the best cell is on the DRNC, the PRNC MO representing thebest cell is incremented.
Note: Normally released calls during IRAT should not be considered for this successratio. 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 countersIRATHO.AttRelocPrepOutCS, IRATHO.AttRelocPrepOutCS-.RelocCancandIRATHO.SuccOutCS are used in the KPI formula.
UTRAN key performance indicators
...................................................................................................................................................................................................................................
7-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Ongoing CS Voice Call-Inter-RAT UMTS to GSM HO has
been triggered
Y
The call is continued in UMTS
YY
NN
Handover fromUTRAN Failure
received?
N NN
YY
Retry withanother GSMtarget cell?
Y
The call is continued in UMTSInc: NumUMTS-GSM_HOPerNCell.Fail
Inc: IRATHO.FailOutCS.sumDepending on the cause received from the
UE increment either:.PhyChnFail
.ConfUnaccept.ProtErr
IRATHO.FailOutCSIRATHO.FailOutCS
IRATHO.FailOutCS
N
RNC sends RANAP “RelocationRequired” to the MSC
Inc: IRATHO.AttRelocPrepOutCS
The RNC initiates the RANAPRelocation Cancel procedure. The
call is continued in UMTS.Increment following sub counters of:
IRATHO.FailRelocPrepOutCS:.sum
.T_RELOCprep_exp
RNC sends RRC “Handover fromUTRAN Command” to the UE
Increment:IRATHO.AttOutCS
Increment:NumUMTS-GSM_HOPerNCell.Att
If trigger was based on RSCP:Increment:
IRATHO.AttOutCS.RSCP
TRELOCprepexpired?
RelocationCommandreceived?
RelocationPreparation
Failurereceived?
Y
Inc: IRATHO.FailRelocPrepOutCS.sumand depending on the cause received from
MSC Increment the following subcounters of:
IRATHO.FailRelocPrepOutCS:.FailTarSys
.NotSupTarSys
.TarNotAllowed.NoRRTarSys
N
RNC issues an Iu Release Requestto the MSC.
Inc: IRATHO.TRelocOverall
RNC releases resources andsends Iu Release Complete
If cause is set to'Successful Relocation' or
'Normal Release':Inc: IRATHO.SuccOutCS
If trigger was based on RSCP:Inc: IRATHO.SuccOutCS.RSCP
TRELOCOverallexpired?
Iu ReleaseCommandreceived?
END
END
END END
END
Additional failures causing inc. of:IRATHO.FailRelocPrepOutCS.sum- Receive a RANAP Relocation Command
containing RABs to be deleted- Receive a RANAP Relocation Command
which does not contain L3 information- Lost communication with the UE due to
all Radio Links failing.
UTRAN key performance indicators Performance counter trigger event basis
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-9
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 parametermeasurementQuantityInterRATHHO is used for inter-RAT hardhandover from UTRAN to GSM. It determines the quantity to be used formeasurements of the UMTS.
• Compressed Mode Activation:The parameterumts2GsmQActCM2D defines the measurement criteria for activationof compressed mode for UMTS to GSM HO with following sub-parameters:
– .rSCPThreshold and.eCN0Threshold specify a value for the quality of theown system (UMTS frequency) for triggering event 2D (actual quality dropsbelow specified threshold). This event is used to start inter-RAT measurementsfor a UE that requires compressed mode.
– .timeToTrigger specifies the time for which the triggering condition must betrue before the UE sends an event triggered measurement report to the UTRAN.
• Compressed Mode Deactivation:The parameterumts2GsmQDeactCM2Fdefines the measurement criteria for activationof compressed mode for UMTS to GSM HO with following sub-parameters:
– .rSCPThreshold and.eCN0Threshold specifiy a value for the quality of theown system (UMTS frequency) for triggering event 2F (actual quality risesabove specified threshold). This event is used to stop Inter-RAT measurementsfor a UE that requires compressed mode.
– .timeToTrigger specifies the time for which the triggering condition must betrue before the UE sends an event triggered measurement report to the UTRAN.
• MAHO Trigger Condition:The parameterumts2GsmQTriggerMAHO defines the measurement criteria to triggerUMTS to GSM HO (MAHO) with following sub-parameters:
– .rSCPThreshold and.eCN0Threshold specifiy a value for the quality of theown system (UMTS frequency) for triggering inter-RAT MAHO in case ofService Handover set to″should not″ (actual quality drops below specifiedthreshold).
– .timeToTrigger specifies the time for which the triggering condition must betrue before the UE sends an event triggered measurement report to the UTRAN.
– .weight specifies weighting between strongest link and remaining active linksfor computing the quality of the own system (UMTS system).
UTRAN key performance indicators
...................................................................................................................................................................................................................................
7-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
IRAT handover events 2D and 3C
The following graphic shows the Inter-RAT handover events 2D and 3C for the UMTSto GSM handover service “should”.
Before the CPICH of the UMTS system declines under the event 2D the UE will noteven know the GSM cell is there. When the signal of the CPICH is below thethreshold, the compressed mode measurements will start. From the 3C event on, theRSSI of the GSM system is above the threshold, that is, the GSM cell is strongenough. Since the UE „should“ handover it will send a report 3C to relocate to GSM.The performance countersIRATHO.AttRelocPrepOutCS andIRATHO.SuccOutCS areincremented accordingly.
Time
Measurement
Quantity
UTRAN Cell
Connected
CPICH (UTRAN)
RSSI (GSM)
Event 2D threshold
used system below
DT
Event 2DStart compressed
mode measurements
Event 3C threshold
GSM above
Event 3C
Relocate to GSM
DT
umts2GsmQActCM2D
IRATHO.SuccOutCSumts2GsmQTriggerMAHO
IRATHO.AttRelocPrepOutCS
UTRAN key performance indicators Parameter trigger event basis
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-11
Parameter setting...................................................................................................................................................................................................................................
Parameters and initial value settings
The actions for the Inter-RAT handover considered depend on values of parameterswhich 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
– .rSCPThreshold: -108 dBm
– .eCN0Threshold: -13 dB
– .timeToTrigger: 5000 ms
• MAHO Trigger Condition:Parameter:umts2GsmQTriggerMAHO
– .rSCPThreshold: -108 dBm
– .eCN0Threshold: -13.0 dB
– .timeToTrigger: 120 ms
– .weight: 1.0
UTRAN key performance indicators
...................................................................................................................................................................................................................................
7-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Parameter discussion...................................................................................................................................................................................................................................
Purpose
The following tables display and discuss the parameter settings that are relevant for theInter-RAT Handover of a Circuit Switched call from UMTS to GSM.
measurementQuantityInterRATHHO
The following table displays the settings for the parameter “Measurement quantity forInter-RAT HO trigger condition”:
Subparameters Recommendation Explanation
RSCP Boundary cells When going away from the center of the UMTScell, the RSCP level may lower, whereas theEc/No may stay constant. In this situation, Ec/Nomeasurements will not be a suitable basis forInter-RAT trigger conditions.
ECN0 Central cells When going towards the center of the UMTScell, the RSCP level may stay constant, whereasthe noise level may change significantly. In thissituation, RSCP measurements will not be asuitable basis for Inter-RAT trigger conditions.
RSCP_ECN0 Default setting In most cases, the measurements of both, RSCPand Ec/No measurements will be a suitable basisfor Inter-RAT trigger conditions.
umts2GsmQTriggerMAHO
The following table displays the settings for the parameter “MAHO TriggerCondition”:
Subparameters Too low values Too high values
rSCPThreshold/eCN0Threshold
Handover is triggered too late.
Call quality may get unacceptably bad.
Call may drop.
The value should be chosen higherthan required for minimal call qualityof a static call. This is necessary toregard for the time that is required toexecute the handover to GSM and themovement of the UE.
Handover is triggered too early.
A handover to GSM is performedalthough the quality of the UMTSsignal is sufficient, i.e. the UE is stillinside the UMTS area.
UTRAN key performance indicators
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-13
Subparameters Too low values Too high values
timeToTrigger Handover is triggered too early.
Measurement report is sent even if thetrigger condition is only fulfilled for avery short time. Such fast time fadingmay be caused for example byinterference and should not cause ahandover to GSM.
Handover is triggered too late.
Call will drop
In case of bad quality the UE has towait for the time to trigger beforesending the measurement report. Thistime in conjunction with the time forthe execution of the handover to GSM,the UE may have already moved outof coverage of the UMTS area and isnot able to receive the handovercommand from the UMTS network.
weight Quality of the strongest cell has higherinfluence than the estimated quality ofthe active set.
weight: 0 means that the strongestcell of the Active Set is taken intoaccount, only.
weight: <1 means that the quality ofthe strongest cell is taken into accountwith higher preference than the othercells of the Active Set.
Quality of the strongest cell has lessinfluence than the estimated quality ofthe active set.
weight: 1 means that all cells of theActive Set are taken account with thesame preference.
weight: >1 means that the quality ofthe strongest cell is taken into accountwith lower preference than the othercells of the Active Set.
umts2GsmQActCM2D
The following table displays the settings for the parameter “Compressed ModeActivation”:
UTRAN key performance indicators Parameter discussion
...................................................................................................................................................................................................................................
7-14 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Subparameters Too low values Too high values
rSCPThreshold/eCN0Threshold
Compressed mode will be activated toolate.
Call may drop before IRAT PMs canbe performed.
Call may drop before HO to GSM isinitiated.
Set value to the same or higher valuethan the HO threshold(umts2GsmQTriggerMAHO.threshold).
The time of activated CM is reducedto a minimum if both thresholds areequal at a constant TTT. A higherthreshold for CM activation may berequired to regard for further qualitydegradation during the time the UEperforms IRAT PMs.
Compressed mode is activated earlierthan required.
CM active although quality of UMTSsignal is sufficient, IRAT HO not to beconsidered at this time.
CM has negative impact on throughputand/or cell capacity and it should beavoided to activate compressed modeif not required,
timeToTrigger Compressed mode will be activatedearlier than required.
Measurement report is sent even if thetrigger condition is only fulfilled for avery short time.
Fast time fading may be caused due tointerference and should not trigger theactivation of CM.
Compressed mode will be activated toolate.
Call may drop due to followingscenario: In case of bad quality UEhas to wait for the time to triggerbefore sending the PM report. Furthertime is required to activate CM,perform IRAT PMs and execute theHO to GSM. During this time the UEmay already have moved out of UMTScoverage area, and the call drops.
umts2GsmQDeactCM2F
The following table displays the settings for the parameter “Compressed ModeDeactivation”:
UTRAN key performance indicators Parameter discussion
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
7-15
Subparameters Too low values Too high values
rSCPThreshold/eCN0Threshold
Frequent toggling of the compressedmode
Compressed mode is deactivated aftera previous activation if the UMTSquality raises only by a small amount.
High signalling load
Negative effect on the call quality.
Compressed mode is kept activatedvery long.
CM active although quality of UMTSsignal is sufficient, IRAT HO not to beconsidered at this time.
CM has negative impact on throughputand/or cell capacity and it should beavoided to keep CM activated if notrequired.
timeToTrigger Compressed mode will be deactivatedearlier than required.
Measurement report is sent even if thetrigger condition is only fulfilled for avery short time.
Fast time fading may be caused due tointerference and should not trigger thedeactivation of CM.
Compressed mode will be deactivatedtoo late.
UTRAN key performance indicators Parameter discussion
...................................................................................................................................................................................................................................
7-16 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
8 8Call availability optimizationand troubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This chapter describes the UTRAN measurements and performance indicators that canbe used to localize problems and to optimize issues related to setting up mobileoriginating and mobile terminating calls.
Contents
Call availability 8-3
Call availability 8-4
Determination of accessibility problem 8-6
Accessibility 8-7
Access preliminary procedures 8-8
Cell re-selection failures 8-9
RACH access procedure failures 8-11
RRC connection establishment analysis 8-15
Introduction to RRC connection establishment 8-16
Call admission control failures 8-19
Radio link setup analysis 8-21
RRC connection setup failure 8-23
Paging failures 8-24
RAB establishment analysis 8-26
RAB establishment 8-27
Dynamic bearer control failures 8-30
Radio bearer establishment failures 8-32
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-1
No answer from UE 8-33
Call availability optimization and troubleshooting Overview
....................................................................................................................................................................................................................................
8-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Call availability
Overview...................................................................................................................................................................................................................................
Purpose
This section describes the performance indicators that can be used to retrieveinformation about the overall network accessibility.
Contents
Call availability 8-4
Determination of accessibility problem 8-6
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-3
Call availability...................................................................................................................................................................................................................................
Introduction
Call availability defines the availability of the UMTS network to allow a call to be setup successfully.
In the call setup process, the UE makes the transition from Idle mode to Cell DCHstate via establishing the RRC connection and establishes the call via establishing theRAB.
Call setup process
The call setup process in UTRAN consists of RRC connection establishment and RABestablishment. With the RRC connection establishment procedure, the UE executes thetransition from Idle mode to CELL_DCH state and establishes the signallingconnection to communicate with the CN.
With the RAB establishment procedure, the CN requests the UTRAN to establish theRAB associated with the call. This involves reconfiguring the radio link(s) to includethe radio link configuration and setting up the transport bearer for the new RAB. TheUTRAN 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 failuresare still impacting the call availability, as the UE needs to register with the CN beforemaking 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 accessprocedure.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RRC connection establishment phase
During the RRC connection establishment phase, the UE executes the transition fromIdle mode to Cell_DCH state and establishes the signalling connection to communicatewith the CN. This involves setting up the radio link(s) to include the radio linkconfiguration and setting up the transport bearer for the signaling radio bearer. TheUTRAN 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 theRAB associated with the call. This involves reconfiguring the radio link(s) to includethe radio link configuration and setting up the transport bearer for the new RAB. TheUTRAN also informs the UE about the configuration of the new RAB.
Call availability optimization and troubleshooting Call availability
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-5
Determination of accessibility problem...................................................................................................................................................................................................................................
Introduction
In order to quickly determine whether there are severe problems in the UMTS networkit is possible to analyze the general UMTS mobile subscriber satisfaction level, from anetwork 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 RABestablishment success rate, the successful RRC connection establishment rate and therelevant Standalone Radio Bearer drop rate.
Abnormal accessibility rate values
When one of the accessibility rate values is very low, the reason can be caused bymany different issues. Therefore it is advised to localize the issue by analyzing theperformance 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.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Accessibility
Overview...................................................................................................................................................................................................................................
Purpose
This section describes which performance measurements and performance indicatorscan be used to analyze the network performance during the access phase.
Note: This procedure is often also referred to as the preliminary procedure, whichshould be performed before the UE can gain network access.
Contents
Access preliminary procedures 8-8
Cell re-selection failures 8-9
RACH access procedure failures 8-11
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-7
Access preliminary procedures...................................................................................................................................................................................................................................
Preliminary procedures failures
In general any call-related procedure initiated via RRC messages sent by the UE to theUTRAN is preceded by two preliminary procedures such as cell selection/re-selectionand random access.
Successful completion of both procedures is a basic prerequisite to succeed in any callsetup procedure.
Not visible for performance management
Both the cell selection/re-selection and random access procedures are not visible to thenetwork before successful receipt of RRC messages relevant for specific callprocedure. Therefore failures occurring during both procedures will not affect the valueof any RRC connection performance indicators. As cell selection is executed in the UEwithout any signaling to the network it is not possible to see any impact onPerformance Measurements (PM). However if the thresholds for quality and level forthe 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 thisissue may become apparent in decreased network traffic.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Cell re-selection failures...................................................................................................................................................................................................................................
Overview
As cell reselection is a pure UE procedure there are no PMs directly related to thisfeature. The reselection behavior of the mobile can only be investigated using a testmobile system. However the reselection behavior of the mobile indirectly influencesthe network quality. Wrong cell reselection may lead to RACH accesses on cells notoffering 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 cellre-selection process. If the hysteresis for cell re-selection is set too large the UE willpossibly access a cell which is not the optimal choice in terms of interference. On theother hand, if the hysteresis for cell re-selection is set too small, the effect ofping-pong re-selections is more likely.
In order to determine whether ping-ponging is occurring during the cell updatesre-selection process, the number of cell update messages that are received from the UEthat are in the Cell FACH state may provide an indication. The measurement counterVS.MM.CellUpdateReq.CellReselectprovides the number of requested cell updates withcause “Cell Reselection” received by the RNC from the UE. If the hysteresis is set toolow, this PM counter value will be abnormally large compared to a properly set cellwith similar traffic. The success of RRC Connection Establishment may be affected ifping pong reselection is occurring during cell re-selection.
Additionally there could be related issues due to potential coverage problems whichcould be monitored by the measurementVS.MM.RRCConnDrop.CellResel_CellUp. Thiscounter 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 reselectionprocedure.
If the reselection procedure frequently triggers the reselection of a new cell this willalso increase the number of LA/ RA/ URA updates at the borders of UMTS mobilityareas. Therefore, an increase of Location Area/ Routing Area/URA updates will bevisible if the UE exhibit a more frequent cell reselection. The counters,VS.MM.UraUpdateReq.UraChangeandVS.MM.UraUpdateReq.PeriodUpdategive thenumber of URA updates performed in this cell, separated by cause. Other counters forlocation updates are available from the core network, such as,VS.SS7LocUpdateAttSucc(3G-MSC measurements) and from the 3G-SGSN applicationmeasurements, such as,MM.AttInterSgsnRaUpdate.UandMM.AttIntraSgsnRaUp-date.U.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-9
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
Call availability optimization and troubleshooting Cell re-selection failures
....................................................................................................................................................................................................................................
8-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 connectionrequest 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 RACHpreamble is relatively low and is calculated using open loop power control
2. Each of the following RACH preambles are transmitted with an increased powertill an acknowledgment (ACK) is received on the AICH
3. After receiving the ACK on the AICH the UE transmits the RACH message partwith an embedded RRCconnection request message.
RRC RRC
Uu
RACH Preamble
UE
RACH Preamble
RNCNode B
VS.RACHTransBlock.Bad
Access indication
RACH message
(RRC Connection Request)
RACH Preamble
(AICH)
Iub
VS.RACHTransBlock.Good
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-11
Timer settings
Guard timer T300 (determined by UTRAN parametert300) and N300 (determined byUTRAN parametern300) is supervising the transmission of the RRC ConnectionRequest message on the UE side.
Poor settings of timern300may result in insufficient retransmission of the RACHmessage and poor settings for timert300 may result in RACH messages beingretransmitted too early or too late and thus affecting the procedures that initiated theRACH access (for example Call setup).
If the RACH Preamble is acknowledged at a very low Eb/N0 and parameterpowerOffsetPpmis set relatively small, this will increase the probability that the RACHMessage Part would be sent at a power that is too low to be decoded correctly (badCRC) by the NodeB. IfpowerOffsetPpmis set above the recommended value, thesuccess rate of RACH will improve (the rate of RACH Message Part received withgood CRC increases). However, this increase of the power of the RACH Message Partwill 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 thanthe designed value (UE power class) which could cause unsuccessful decoding oracknowledgement of RACH preambles and messages.
PMs / KPIs indications
RRC.AttConnEstab.sumis triggered on the RNC after reception of the RRC connectionrequest message independent of the establishment cause. Low values at a specificNodeB ofRRC.AttConnEstab.sumare indicative of problems. Nevertheless this countercannot prove that there are actually problems because, for example, NACKs sent byNode B on AICH are not counted. It may be that at a particular cell low traffic isresulting in low values of counterRRC.AttConnEstab.sum.
However the KPI - Successful RRC connection establishment rate (including repeatedattempts) calculates the RRC Connection establishments with repeated attempts whichcan be used to assess the Access issue from the network perspective. Low values showthat the access process may need to be optimized and there could be RACH accessfailures. It must be noted that though this KPI is low, it does not mean that the
Call availability optimization and troubleshooting RACH access procedure failures
....................................................................................................................................................................................................................................
8-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
subscriber faces an issue in access since there would be several retries of the RRCattempt before it is a failed RRC connection attempt which requires the subscriber totry again. The number of retries is set by the parametern300 in the OMC.
The PM countersVS.RACHTransBlock.BadandVS.RACHTransBlock.Goodmay beused to arrive at the ratio between number of RACH TBs received with bad CRC tototal number of RACH TBs. A high value for this ratio may be indicative of problemswith the quality over the RACH.
The KPI - RACH transport block good CRC rate can be used to obtain the percentageof Transport Blocks with good CRC and low values are indicative of issues of reducedpower of the RACH message part (causing bad CRC) and may be related to settings ofpowerOffsetPpm.
The PM counterVS.ChannelOccupRateRACHis the ratio of total bits transferred onthe RACH to maximum bits available for RACH usage (service rate) per granularityperiod. If this ratio is very high the resources on the RACH may not be sufficient.
The PM counterVS.RACHcongestionprovides the percentage of time the RACH is incongested state. This helps to determine the overload status for the RACH and isuseful for field diagnostics.
The following PM counters maybe used to study failures in the Access procedure:
• RRC.FailConnEstab.SetupIncompleteNumber of RRC connection attempt failures, when RNC does not receive the“RRC Connection Setup Complete” message from the UE. Includes failures forrepeated RRC connection attempts from the same UE.
• RRC.FailConnEstab.sumThis measurement provides the total number of failed RRC connectionestablishments. Includes rejects for repeated RRC connection attempts from thesame UE
• RRC.FailConnEstab.CACThis counter is incremented whenever the RNC sends an “RRC Connection Reject”message with cause “Congestion”. Congestion will occur due to Call AdmissionControl (CAC).
• RRC.FailConnEstab.RLSetupFailureThis counter is incremented whenever the RNC sends an “RRC Connection Reject”message with cause “unspecified” for the case where the SRNC receives a “RadioLink Setup Failure” message.
Related PMs / KPIs
The related PMs / KPIs are:
• VS.RACHTransBlock.Bad
• VS.RACHTransBlock.Good
Call availability optimization and troubleshooting RACH access procedure failures
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-13
• VS.ChannelOccupRateRACH
• VS.RACHcongestion
• RACH transport block good CRC rate
• RRC.FailConnEstab.SetupIncomplete
• RRC.FailConnEstab.sum:
• RRC.FailConnEstab.CAC
• RRC.FailConnEstab.RLSetupFailure
Call availability optimization and troubleshooting RACH access procedure failures
....................................................................................................................................................................................................................................
8-14 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RRC connection establishment analysis
Overview...................................................................................................................................................................................................................................
Purpose
This section describes the performance measurements and performance indicators canbe used to localize problems and to optimize issues related to the RRC connectionestablishment.
Contents
Introduction to RRC connection establishment 8-16
Call admission control failures 8-19
Radio link setup analysis 8-21
RRC connection setup failure 8-23
Paging failures 8-24
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-15
Introduction to RRC connection establishment...................................................................................................................................................................................................................................
RRC Connection establishment procedure
In general the RRC connection establishment procedure may occur in differentscenarios 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 theRRC connection request message. This means that cell selection/re-selection as well asrandom access procedures have been successfully completed.
Call setup stages
In case of a mobile originated call setup, the RRC Connection Establishment proceduremay 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 andsynchronization
3. RRC connection setup.
Note: For a mobile terminating call the paging procedure precedes the random accessprocedure.
An example of a mobile originated call flow:
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-16 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 canbe seen from measurementsRRC.FailConnEstab.SetupIncompleteandRRC.FailConnEstab.RLSetupFailure. Congestion in the NodeB/RNC can cause RRCConnection failures and will be seen from the measurementRRC.FailConnEstab.CAC.Overload of the RNC processor can cause discards of RRC Connection requests whichcan consequently affect the Successful RRC Connection Establishment rate (included
ALCAP Iub transport bearer
DCH-FP: UL/DL synchronization
RRC RRC
UuUE RNCNode B
RRC.FailConnEstab.CAC
RRC Connection Setup
(CCCH over FACH)
Iub
RRC.FailConnEstab.SetupIncomplete
RRC RRCRRC Connection Request
(RACH)
CAC
NBAP NBAPRL Setup Request
NBAP NBAPRL Setup Response
RRC RRCRRC Connection Setup Complete
(DCCH over DCH)
1
2
3
RRC.FailConnEstab.RLSetupFailure
Call availability optimization and troubleshooting Introduction to RRC connection establishment
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-17
repeated attempts). This can be observed by monitoringRRC.FailConnEstab.Processor-Load. It must be noted that this also includes RRC Connection attempt retries, hencethe KPI - RRC establishment success rate (UE perspective)should also be used tostudy the effect of RRC failures from the subscriber experience point of view.
Low values of the KPI, successful RRC connections establishment rate, may also bedue to RRC connections failures occurring during other procedures such as networkattach or SMS and location update.
There are individual measurements for each type of RRC connection attempt (forexample,RRC.AttConnEstab.OrigConvCall, RRC.AttConnEstab.Registration) and theircorresponding success measurements (for example,RRC.SuccConnEstab.OrigConvCall,RRC.SuccConnEstab.Registration). These can provide the success rates for each RRCConnection procedure which may help in isolating issues in specific procedures.
Related PMs / KPIs
The related PMs / KPIs are:
• RRC.FailConnEstab.SetupIncomplete
• RRC.FailConnEstab.CAC
• RRC.FailConnEstab.RLSetupFailure
• 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 availability optimization and troubleshooting Introduction to RRC connection establishment
....................................................................................................................................................................................................................................
8-18 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Call admission control failures...................................................................................................................................................................................................................................
Introduction
Call Admission Control (CAC) is used to prevent overload of the system. Loadconditions for the downlink are based on the total transmit power of the cell. Theuplink load measure is the measured RSSI value relative to the typical noise floor thatwas estimated using long term measurements.
If the defined load thresholds for CAC are exceeded the RRC connection establishmentrequest is denied and a RRC Connection Reject message with cause, “Congestion” issent by the RNC to the UE.
Abnormal value
The triggering of CAC can be partly monitored using the PM counter,RRC.FailConnEstab.CACthat is triggered in case of CAC. If the values of this counterindicate that overload situations have occurred over long periods of time, CAC shouldbe the reason for the experienced call setup problems.
The KPI,Failed RRC connection establishment rate - congestion (conv Call)can beused to find issues related to conversation calls. The KPI,Failed PS RRC connectionestablishment rate - Congestionwill help identify cells where the RRC Connectionshave failed to establish for Packet calls due to congestion.
Load measurements
Other counters related to system load such asVS.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 ofChannel 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.Meanand Channel Code Utilization which providesthe percentage of Code utilization. All of these may be used to verify whether the loadin the cell is fairly high, which would increase the probability for call setup failures.
Related PMs / KPIs
The related PMs / KPIs are:
• RRC.FailConnEstab.CAC
• VS.RF.ForwrdTrafficChn.Overload
• VS.RF.ChanElementUsage.Total
• VS.ChanCodeUtil
• VS.RF.ChanElementUsage.Dedicated
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-19
• 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
Call availability optimization and troubleshooting Call admission control failures
....................................................................................................................................................................................................................................
8-20 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Radio link setup analysis...................................................................................................................................................................................................................................
Introduction
Once the RNC has verified that the requested resources have passed the call admissioncontrol check, the RNC requests the Node B to allocate these resources through theNBAP radio link setup procedure.
In general at least one radio link has to be set up. In the case where the UE is in asoft/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 perservice type.
Radio link setup failure
In order to allocate the requested resources, the RNC sends the radio link setup requestmessage 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 SetupResponse message to the RNC. If the establishment of at least one radio link fails thenthe Node B sends back the radio link setup failure message to the RNC.
Lack of NodeB Resources
The measurementsRLM.FailRLSetupIub.NodeBRes.CSV, RLM.FailRLSetupIub.NodeB-Res.PSDandRLM.FailRLSetupIub.NodeBRes.CSDrecord failures in Radio Link setupprocedures. High values for these counters indicate that there were RL failures due tomissing Node B resources. This indicates possible UMTS Channel Unit (UCU) outagesor 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 theNode B capacity in terms of the availability of physical resources is close to the limitduring the time of the failures.
Lack of Transport Resources
The measurementsRLM.FailRLSetupIub.TransRes.CSV, RLM.FailRLSetupIub.TransRe-s.PSD, RLM.FailRLSetupIub.TransRes.CSDandRLM.FailRLSetupIur.TransResrecordfailures in Radio Link setup procedure. High values for these counters indicate thatthere are failures due to missing transport resource. This indicates that transportresource is unavailable due to missing binding IDs for the transport bearer.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-21
The measurement,RRC.FailConnEstab.RLSetupFailureprovides a count of failures dueto RL Setup failures and can be used in conjunction with the above PMs. If thiscounter is high while the resource counters show zero/low numbers, then it could meanthat there are RF related issues in the area preventing call setup.
Related PMs / KPIs
The related PMs / KPIs are:
• 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.FailConnEstab.RLSetupFailure
Call availability optimization and troubleshooting Radio link setup analysis
....................................................................................................................................................................................................................................
8-22 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RRC connection setup failure...................................................................................................................................................................................................................................
Introduction
Once the NBAP radio link setup procedure has been successfully completed and thetransport bearer has been established and synchronized, the UTRAN initiates the RRCconnection setup procedure to complete the RRC connection establishment.
The performance measurementRRC.FailConnEstab.SetupIncompleteis used to recordfailures occurred during the RRC connection setup procedure.
Related PMs / KPIs
The related PMs / KPIs are:
• RRC.FailConnEstab.SetupIncompleteAbnormally high values of the above mostly point to RF related issues likecoverage/interference or parameter settings
Possible reasons for high values are:
1. Optimal settings of the UTRAN attributesuERRCConnSetup-ResponseTimerandmaxRRCConnSetupRetriesare not correct
2. The RRC connection setup message is not successfully decoded due to poor FACHcoverage
3. The RNC cannot successfully decode the RRC connection setup complete message.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-23
Paging failures...................................................................................................................................................................................................................................
Paging procedure
In case of an MT call the UE in Idle state has to be paged before sending the RRCConnection Request message. The RRC paging Type 1 message is sent on the PagingChannel (PCH) by the core network (this means 3G-MSC for circuit-switched calls orSGSN 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 MTcall.
In a successful case the UE receives, and correctly decodes, the paging message andsends back the RRC Connection Request message with the relevant cause to theUTRAN (this means Terminating High Priority Signaling for PS calls and TerminatingConversational Call for Voice calls).
However it may occur that the UE either does not receive or does not correctly decodethe Paging message.
PMs / KPIs indications
The failure causes can be identified via the UTRAN countersVS.MM.PageAttDiscardandVS.MM.PagAttDiscard.ProcessorLoad. PCH Traffic can be evaluated via thecounterVS.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 poorPCH 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 pagingmessages
• 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. RRCConnections are dropped when the UE does not respond to Paging messages possiblydue to coverage or UE issues. This is recorded by the measurement,VS.MM.RRCConn-Drop.UTRANPagingFailure.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-24 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Related PMs / KPIs
The related PMs / KPIs are:
• 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.
Call availability optimization and troubleshooting Paging failures
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-25
RAB establishment analysis
Overview...................................................................................................................................................................................................................................
Purpose
This section describes the performance measurements and performance indicators canbe used to localize problems and to optimize issues related to the RAB establishment.
Contents
RAB establishment 8-27
Dynamic bearer control failures 8-30
Radio bearer establishment failures 8-32
No answer from UE 8-33
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-26 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RAB establishment...................................................................................................................................................................................................................................
RAB establishment procedure
As soon as the RRC connection establishment procedure has been completed, the callsetup procedure is finalized via the RAB establishment procedure. Once the RRCconnection is established, the UE can then establish the signaling connection with theCN via UTRAN. If a PS call is to be setup, the UE may initiate PDP ContextActivation procedure over the signaling connection to the SGSN. If a CS call is to besetup, the UE may initiate the Call Setup procedure over the signaling connection tothe MSC. The CN will send the RAB assignment request to UTRAN to establish theRAB associated with the call.
RAB establishment initiators
The RAB Establishment procedure is initiated by the core network via the sending ofRAB assignment request. This procedure is successfully completed upon receipt ofRANAP RAB assignment response message at the core network.
RAB establishment call flow
An example RAB establishment call flow:
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-27
Uu
RAB.FailEstabCSNoQueuing.T3expRAB.FailEstabPSNoQueuing.T3exp
Iub Iu-ps/csMSC/SGSNSRNCNode B
RAB.FailEstabCSNoQueuing.ULIntferRAB.FailEstabPSNoQueuing.ULIntferRAB.FailEstabCSNoQueuing.DLPwrRAB.FailEstabPSNoQueuing.DLPwrRAB.FailEstabCSNoQueuing.CodeStarvRAB.FailEstabPSNoQueuing.CodeStarv
UE
RRC Radio bearer setup
RANAP RABAssignment Response
Radio linkreconfiguration commit
NBAP Radio linkreconfiguration ready
NBAP Radio linkreconfiguration prepare
RANAP RAB assignment request
Node B RNC data transport bearer sync
ALCAP Iub transport bearer establishment
ALCAP Iu transport bearer establishment
RRC DL Direct Transfer
RANAP Direct Transfer
RANAP Direct Transfer
RRC DL Direct Transfer
RANAP Direct Transfer(PS ONLY: Act PDP Context Acc)
DBC
RAB.FailEstabCSNoQueuing.RBSetupFailRAB.FailEstabPSNoQueuing.RBSetupFail
(Only for CS domain)
(PS: PDP Context RequestCS: Call Setup Request)
RRC UL Direct Transfer
(PS: PDP Context RequestCS: Call Setup Request)
(CS ONLY: Call Setup Request)
(CS ONLY: Call Proceeding)
(DCCH over DCH)
RRC Radio bearer setup complete
(DCCH over DCH)
(PS ONLY: Act PDP Context Acc)
Call availability optimization and troubleshooting RAB establishment
....................................................................................................................................................................................................................................
8-28 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RAB establishment stages
The RAB Establishment procedure for both PS and CS calls may be categorized intothe 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 asfollows:
• Dynamic bearer control failure
• Radio bearer establishment failures
• Miscellaneous failures, for example code starvation.
PMs / KPIs indications
The related PMs / KPIs are:
• 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
Call availability optimization and troubleshooting RAB establishment
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-29
Dynamic bearer control failures...................................................................................................................................................................................................................................
Introduction
During RAB establishment the Dynamic Bearer Control (DBC) procedure is triggered(see“RAB establishment call flow” (p. 8-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 RABestablishment process is discontinued.
Uplink Interference
When the DBC threshold for Uplink Interference is crossed, a DBC failure occurs anda RAB Assignment response failure is sent by the RNC causing the measurementsRAB.FailEstabCSNoQueuing.ULIntferandRAB.FailEstabPSNoQueuing.ULIntferforCS or PS RAB assignment respectively to be pegged. This maybe due to interferencefrom 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 aRAB Assignment response failure is sent by the RNC causing the measurementsRAB.FailEstabCSNoQueuing.DLPwrandRAB.FailEstabPSNoQueuing.DLPwrfor CSor PS RAB assignment respectively to be pegged. This is related to unavailability ofDownlink power resource in the NodeB to establish the new RAB connection. Thismaybe due to a large number of voice or low speed calls or few high speed calls thathave consumed NodeB power resources.
Code Starvation
When a DBC failure occurs due to lack of Code resources, a RAB Assignmentresponse failure is sent by the RNC causing the measurementsRAB.FailEstabCSNo-Queuing.CodeStarvandRAB.FailEstabPSNoQueuing.CodeStarvfor CS or PS RABassignment respectively to be pegged. The measurementVS.ChanCodeUtilcan bemonitored for code usage in conjunction with this RAB failure measurement.
System load counters
Counters related to system load such asVS.RF.ForwrdTrafficChn.Overload,VS.RF.TxCodePwr.Max, VS.RF.TxCodePwr.MeanandVS.RF.RTWP.Max,VS.RF.RTWP.Meanmay be used to verify that the load in the cell or NodeB is fairlyhigh.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-30 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Other counters
Issues in the NodeB that causes RAB Establishment failure due to NodeB specificerrors 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
The related PMs / KPIs are:
• 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
Call availability optimization and troubleshooting Dynamic bearer control failures
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-31
Radio bearer establishment failures...................................................................................................................................................................................................................................
Introduction
Once the required resources have been successfully reconfigured in the Node B, theRRC radio bearer establishment procedure is executed in order to set up a new radiobearer at the UE.
Radio bearer establishment procedure
The RNC sends the radio bearer setup message to the UE that then sends back theradio bearer setup complete message to the RNC, therefore, successfully allocatingresources for the new radio bearer.
Radio bearer establishment failures from UE
Upon receiving the radio bearer setup message the UE may not successfully allocatethe required resources to setup the new radio bearer. In this case the UE sends back theradio bearer setup failure message to the RNC and the radio bearer establishmentprocedure 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 KPIRAB Establishment Success Rate. Theycan be identified via the PM countersRAB.FailEstabCSNoQueuing.RBSetupFailandRAB.FailEstabCSNoQueuing.RBSetupFail, triggered when radio bearer setup failuremessage is received at the RNC.
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................
8-32 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
No answer from UE...................................................................................................................................................................................................................................
Introduction
Upon sending the RRC radio bearer setup message to the UE, a guard timer is startedon the RNC in order to supervise the reception of the RRC radio bearer setup completemessage from the UE. The guard timer is configured by UTRAN parameteruERadioBearerSetup-ResponseTimer. If the guard timer expires and no message isreceived from the UE, then the radio bearer establishment procedure fails and all theallocated UTRAN resources are released.
No answer from UE failures
The normal reason for this failure scenario is due to poor RF conditions, that couldresult because of poor coverage or high interference.
In addition, too low a setting of the timeruERadioBearerSetupResponse-Timerwithrespect to the UE response time may be the failure cause.
PMs / KPIs indications
This failure causes degradation of the KPIRAB establishment success rate. Thespecific UTRAN PM counterRAB.FailEstabCSNoQueuing.T3expandRAB.FailEstabPSNoQueuing.T3expare triggered when the guard timer expires for CSand PS RAB establishments respectively.
Related PMs / KPIs
The related PMs / KPIs are:
• RAB.FailEstabCSNoQueuing.T3exp
• RAB.FailEstabPSNoQueuing.T3exp
• RAB.FailEstabPSNoQueuing.T3exp.DCH_DCH
• RAB.FailEstabPSNoQueuing.T3exp.DCH_HSDSCH
• RAB.FailEstabPSNoQueuing.T3exp.EDCH_HSDSCH
Call availability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
8-33
9 9Call reliability optimization andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This chapter describes the UTRAN measurements and performance indicators that canbe used to localize problems and to optimize issues related to maintaining the call.
Contents
Dropped calls analysis 9-2
Radio link failures analysis due to synchronization issues 9-6
Dropped RAB analysis due to congestion 9-9
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
9-1
Dropped calls analysis...................................................................................................................................................................................................................................
Introduction
As soon as the call is successfully set-up, the second factor of the UMTS userperception is the probability of maintaining the call, as opposed to the probability ofdropping the call.
A call drop is defined as an abnormal termination of a voice/data session due to anyreason causing the user to re-initiate the session. A drop on a PS session will still resultin 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 RateandCS Data RAB drop rate, which are defined as the percentage of dropped RAB dueto any UTRAN generated reason against the total number of established RABs for thedifferent type of services, can be calculated.
Signalling flow
The signaling flow of total RABs dropped (all service types):
Call reliability optimization and troubleshooting
...................................................................................................................................................................................................................................
9-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
On the UTRAN call handling procedures the dropped RABs are identified by thefollowing:
• 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 corenetwork are released.
RANAP
Iu release command(Release cause: as per TS 25.413)
RANAP
RRC Connection release(Note: message sent if RRC
connection still exists)
RRC Connection release complete(Release cause: as per TS 25.331)
Cell_DCH
UE_Idle
NBAP RL Deletion procedure
ALCAP release procedure
Uu Iub Iu-psUE Node B SGSN
RANAP
Iu release request(UTRAN generated reason)
RAB 64 kbps UL and DL
RRC
A dropped RAB connectiondue to any kind of failure
RNC
RANAP
RRC
RAB.Rel.Drop.sum
Note: RNC decides to drop RABdue to an unrecoverable failure
RANAP pleteIu release com
(DCCH)
(DCCH)
Call reliability optimization and troubleshooting Dropped calls analysis
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
9-3
Note: For PS calls the PDP context will not be released in the SGSN and the contextwill 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 theUMTS Performance Measurements DefinitionManual,401-382-803 that list the RAB Drop counter for the different causes statedabove. These can be studied with respect to the number of established RABs to obtaina ratio for the specific issue and studied on a cell by cell basis to find out high runnercells.
Related PMs / KPIs
The related PMs / KPIs are:
• 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
Call reliability optimization and troubleshooting Dropped calls analysis
...................................................................................................................................................................................................................................
9-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• 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>
Call reliability optimization and troubleshooting Dropped calls analysis
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
9-5
Radio link failures analysis due to synchronization issues...................................................................................................................................................................................................................................
Introduction
Radio Link Failures (RLF) due to synchronization issues can take place in both thedownlink and uplink direction. The physical layer in the Node B and UE checks thesynchronization status of every radio frame.
RLF in the downlink
The RLF procedure in the downlink is supervised in the UE. In the Cell_DCH State,the UE starts timerT313 after receivingN313 consecutive out-of-sync indications. TheUE stops and resets timerT313 upon receiving successiveN315 in-sync indications. IfT313 expires, the UE considers that the radio condition is terminated with an RLF. TheUE will no longer transmit any data on the terminated RL. This will cause the uplinkRLF 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 thePM 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 aresupervised 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 radiolink sets to trigger RLF and radio link restore procedures.
Initialstate
In-syncstate
Out-of-syncstate
RL Restore
RL Failure
RL Restore
Call reliability optimization and troubleshooting
...................................................................................................................................................................................................................................
9-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 uplinksynchronization 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 theNode B via the NBAP radio link deletion procedure incrementing the PM counterVS.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 counterVS.RAB.DROP.<CS service type>.Cause<UL/DL>RLFis incremented.
Radio link failures due to synchronization issues can be identified via PM counterVS.RLM.DropRL.ULRLFLossSyncthat is triggered after expiration of the guard timerT_RL_RESYNCH.
In case of Radio link failures NOT due to synchronization issues, the PM counterVS.RLM.DropRL.ULRLFNoLossSyncrecords the results.
In case RLF for a UE with one radio link only occurs, the radio link loss results in adropped call. The Iu connection is then abnormally released causing the RAB dropPMs 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
The related PMs / KPIs are:
• 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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
9-7
• PS RAB Drop Rate due to DL RLF
• PS RAB Drop Rate due to UL RLF
• Total PS Dropped RABs cause UL RLF
Call reliability optimization and troubleshooting Radio link failures analysis due to synchronization issues
...................................................................................................................................................................................................................................
9-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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. Onlyin the case where further data rate reduction is not possible would finally a PS RAB bedropped.
RAB Drops due to Downlink Power
Established RABs could be dropped when the Downlink Power resource in the NodeBis not available to maintain the call. This could happen due to the a large number ofUEs handled by the NodeB and some of the UEs maybe moving away from the cellsite transmitter causing increase in allocated DL power to service these UEs. Withproper design these UEs should handover to another NodeB, but if this does nothappen the RAB will be dropped with the RNC initiating an Iu Release procedure withcause “no resource available” and event “downlink power” occurred in the RNC.
The countersVS.RAB.Drop.CS.DLPwrandVS.RAB.Drop.PS.DLPwrwill be pegged forCS or PS calls respectively.
The following NodeB counters can provide additional information on the power levelsof 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.TxPwrMean.AllCodes
• 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 theNodeB is so high that the call cannot be maintained and is terminated. This couldhappen due to a large number of UEs handled by the NodeB or in nearby NodeBscausing high uplink interference. Geographical terrain and presence of water bodiescould also increase uplink interference as the NodeB might have a Line of Sight
Call reliability optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
9-9
visibility to distant UEs. With proper design and parameter settings in the network, theuplink interference can be reduced, but if high uplink interference is seen, the RABwill be dropped with the RNC initiating an Iu Release procedure with cause “noresource available” and event “uplink interference” occurred in the RNC.
The countersVS.RAB.Drop.CS.ULIntferandVS.RAB.Drop.PS.ULIntferwill be peggedfor CS or PS calls respectively.
The following counters can be observed to further understand the interferenceconditions 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.TxPwrMean.AllCodes
• 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 calland the UE does not support URA_PCH State, or if the UE is redirected, or if multiplePDP contexts are in place for the call. The counterVS.RAB.Drop.UEInactivitywill bepegged when such events occur. RAB drop analysis, the contribution of these dropsprovide an insight into the UE equipment used by the customers and their userexperience 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 commandto any of the following Managed Objects:
• IuR
• IuPS
• IuCS
• IuB
• Lcell
• HSDPA
Call reliability optimization and troubleshooting Dropped RAB analysis due to congestion
...................................................................................................................................................................................................................................
9-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• LRNC
• LNodeB
This could happen due to parameter changes or when operations work is carried out onthe network. This can be minimized by observing traffic patterns in the area of impactand 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 reportingpoor quality and power (5A/6A) and the parameterrABreleaseMinRateGbrRabisconfigured to “TRUE” , then the PS RAB maybe dropped. The percentage of suchdrops 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 DropRate due to DL Power, PS RAB Drop Rate due to DL Power, CS RAB Drop Rate dueto UL InterferenceandPS RAB Drop Rate due to UL Interferenceand acomprehensive picture of the power and interference issues in the cell can be inferredand 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 failuresare detected by the UE (upon RLC resets/disruptions) which would subsequently notifythe RNC via RRC Cell Update with cause “UnrecoverableRLCError”. The DL RLCfailures are normally detected by the TPU RLC layer which would then notify the BSCvia 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 severalreasons such as authentication errors, unsupported Integrity protection algorithm, O&Mintervention among others causes. Performance measurements for Circuit and Packetcore network related drops are pegged as listed below. Further analysis can be done byisolating the Core network element that is common to the RNCs where these counts
Call reliability optimization and troubleshooting Dropped RAB analysis due to congestion
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
9-11
are seen to be high. Corresponding Core Network initiated drop measurements fromthe 3G MSC and 3G SGSN will need to be analyzed for obtaining the root cause ofthe 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 orvice versa. This can occur due to poor coverage or interference issues leading to timerDchHsDSCHexpiry while waiting for a Radio Bearer reconfiguration completemessage from the UE. The RAB is also dropped when a Radio Bearer reconfigurationfailure message is sent by the UE.
Related PMs/KPIs
• VS.RAB.Drop.Reconf.DCH_HSDSCH
• VS.RAB.Drop.Reconf.HSDSCH_DCH
Call reliability optimization and troubleshooting Dropped RAB analysis due to congestion
...................................................................................................................................................................................................................................
9-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
10 10Call quality optimization andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This chapter describes the performance indicators that can be used to retrieveinformation about the call quality.
Quality is defined as the quality of the connection as perceived by the subscriber. Theintention 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 10-2
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
10-1
Quality KPIs...................................................................................................................................................................................................................................
Introduction
Although a call is successfully set up and maintained the user may perceive that thequality of the call itself is poor. In case of a voice call this quality degradation can bedirectly experienced during the conversation. In case of a data call the poor qualitymay cause throughput degradation.
There are several aspects that determine the call quality, such as delay, jitter andBLER, 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 theUMTS 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, CSV4.75, PS.
Poor quality reasons
High values of the quality KPIs indicate that the perceived uplink quality of the call ispoor. 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 andthe Node B transmitted power should be checked respectively:
• If the UE and/or the Node B transmitted power has reached the maximum allowedvalue, then the most likely root cause is given by poor RF conditions that arelimiting either the downlink or the uplink, or both.
• If the UE and/or the Node B transmitted power has not reached the maximumallowed value, then the most likely root cause is given by respectively UL and/orDL closed loop power control issues.
Basic root cause analysis method for high UL/DL BLER issues:
Call quality optimization and troubleshooting
...................................................................................................................................................................................................................................
10-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Note: It should not be assumed that UL BLER issues will also result in DL BLERissues and vice versa. In several scenarios the system may be either only uplink oronly downlink limited due to unbalanced loads.
Other abnormal values
Other counters related to system load such asTransmitted Code Power, Received TotalWideband Power, Forward channel overload durationandSignal to Interference Ratiomay be used to verify that the load in the cell is fairly high, which would increase theprobability for call setup failures. There are also several RAB Drop measurementsrelated to Radio link failure, UL interference and DL Power which can be studied inparallel to ascertain the quality issues faced by the subscriber.
Note: DL BLER distribution per cell and UL BLER distribution per cell can be derivedusing the probe (for example, Tektronix). A prerequisite is to enable periodicmeasurement 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
• CSV 5.9 UL Transport BLER
Poor RFconditions
UL/DLpower
control issues
High UL/DL BLER
Max UE / Node Btransmitted power
reached?
NoYes
Call quality optimization and troubleshooting Quality KPIs
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
10-3
• CSV 7.95 UL Transport BLER
• CSV 12.2 UL Transport BLER
• 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 RABmodification 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 particularcell/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
Call quality optimization and troubleshooting Quality KPIs
...................................................................................................................................................................................................................................
10-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
11 11Call mobility optimization andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This chapter describes the UTRAN measurements and performance indicators that canbe used to localize problems and to optimize issues related to call mobility.
Contents
Soft/Softer handover and troubleshooting 11-3
Soft/softer handover procedure 11-4
Average active set size 11-7
Soft handover troubleshooting 11-9
No Node B resources available 11-12
No transport resources available 11-13
No UE answer 11-14
UE reject 11-15
Unlisted set cells 11-16
CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting 11-18
CS Voice UMTS to GSM (inter-RAT) handover procedure 11-19
CS Voice relocation preparation procedure troubleshooting 11-23
CS Voice IRAT handover procedure troubleshooting 11-25
CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting 11-26
CS Voice GSM to UMTS (inter-RAT) handover procedure 11-27
Relocation resource allocation procedure troubleshooting 11-30
Handover procedure troubleshooting 11-32
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-1
PS UMTS to GSM (inter-RAT) Cell Change Order andtroubleshooting
11-33
PS UMTS to GSM (inter-RAT) Cell Change Order procedure 11-34
PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting 11-37
Serving HS-DSCH Cell Change 11-39
Serving HS-DSCH Cell Change procedure 11-40
Serving HS-DSCH Cell Change troubleshooting 11-43
Inter-frequency hard handover and troubleshooting 11-44
Inter-frequency hard handover procedure 11-45
Hard handover troubleshooting 11-50
No Node B resources available 11-53
No transport resources available 11-54
UE reject 11-55
Inter-system directed retry 11-56
Inter-system directed retry procedure 11-57
Inter-system directed retry troubleshooting 11-60
Call mobility optimization and troubleshooting Overview
....................................................................................................................................................................................................................................
11-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Soft/Softer handover and troubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This section provides soft/softer handover optimization and troubleshootinginformation.
Contents
Soft/softer handover procedure 11-4
Average active set size 11-7
Soft handover troubleshooting 11-9
No Node B resources available 11-12
No transport resources available 11-13
No UE answer 11-14
UE reject 11-15
Unlisted set cells 11-16
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-3
Soft/softer handover procedure...................................................................................................................................................................................................................................
Introduction
In UMTS networks soft/softer handover is the basic feature that ensures seamlessmobility 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 theActive Set (this means event 1A) is depicted. Step 4 has been grayed out as it refers tothe removal of a radio link (this means event 1B). Both step 2 and 4 will be used incase of a radio link replacement (this means event 1C).
The basic Intra-RNC soft handover procedure is:
RRC RRC
UE SRNCNode B - 2
Active Set Update
(Radio Link addition)
RRC RRCRRC Measurement Report (Event 1A)
(DCCH over DCH)
NBAP NBAPRL Setup Request
NBAP NBAPRL Setup Response
RRC RRCActive Set Update Complete
RRC RRCRCC Measurement Control
(DCCH over DCH)
PM-A =
PM-B =
SHO.AttRLAddUESide
PM-D =
NBAP NBAPRL Deletion Request
NBAP NBAPRL Deletion Response
Node B - 1
PM-APM-B
PM-CPM-D
RLM.AttRLSetupIubRLM.AttRLSetupIub.CSVRLM.AttRLSetupIub.CSDRLM.AttRLSetupIub.PSD
RLM.SuccRLSetupIubRLM.FailRLSetupIub.NodeBRes.CSVRLM.FailRLSetupIub.NodeBRes.CSDRLM.FailRLSetupIub.NodeBRes.PSDRLM.FailRLSetupIub.TransRes.CSVRLM.FailRLSetupIub.TransRes.CSDRLM.FailRLSetupIub.TransRes.PSD
PM-C =
SHO.SuccRLAddUESideSHO.FailRLAddUESide.InvalidConfigSHO.FailRLAddUESide.IncompSimultReconfSHO.FailRLAddUESide.ProtErrSHO.FailRLAddUESide.ConfigUnsupportSHO.FailRLAddUESide.NoReply
1
2
3
4
5
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 RRCmeasurement report message
2. Set up resources in the UTRAN via NBAP procedure (in case of addition orreplacement)
3. Soft/softer handover execution via RRC active set update procedure. Soft/softerhandover procedure is successfully executed on receipt of an RRC active set updatecomplete message at the RNC
4. Clear resources in the UTRAN via NBAP procedure (case of removal orreplacement)
5. Monitored Set update upon Neighbor List Selection Algorithm (NLSA) evaluationvia an RRC measurement control message.
Handover scenarios
Soft/softer handovers can be executed as Intra-RNC as well as Inter-RNC. In case ofInter-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 andDCH Framing Protocols are executed on the Iub interface in between Radio LinkSet-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 sameNode 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 aswhere SRNC is executing Active Set Update procedure (step 3) while DRNC is takingcare of the NBAP procedures (steps 2 and 4) initiated by the SRNC through the Iurinterface via corresponding Radio Network Subsystem Application Part (RNSAP)procedures.
This means that, for example, in case of event 1A triggered in one Node B belongingto the DRNC then the SRNC initiates the setup of the resources at the DRNC via theRNSAP Radio Link Setup procedure. Afterwards the DRNC allocates the requiredresources at the relevant Node B via the NBAP Radio Link Setup procedure. Thisexample is valid when no soft handover context exists at the Node B, otherwiseRNSAP and NBAP Radio Link Addition procedures are executed instead.
Call mobility optimization and troubleshooting Soft/softer handover procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-5
Soft/softer handover procedure is successfully executed on receipt of RRC Active SetUpdate Complete message at the RNC.
Call mobility optimization and troubleshooting Soft/softer handover procedure
....................................................................................................................................................................................................................................
11-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Average active set size...................................................................................................................................................................................................................................
Description
The “Active Set Size” may either be provided as distribution (presentage of set sizebeing used) or the average.
Active Set Size Distribution
The Active Set Size Distribution KPI provides the RL active set size distribution inpercent. The active set size per UE is in the range one to six. Per active set size (1 to6), the percentage how often the relevant active set size is used will be provided on aper 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))
Percentage Active Set Size 2 = 100 × (VS.RLSetAct.Size2 / (VS.RLSetAct.Size1 +VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5+ VS.RLSetAct.Size6))
Percentage Active Set Size 3 = 100 × (VS.RLSetAct.Size3 / (VS.RLSetAct.Size1 +VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5+ VS.RLSetAct.Size6))
Percentage Active Set Size 4 = 100 × (VS.RLSetAct.Size4 / (VS.RLSetAct.Size1 +VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5+ VS.RLSetAct.Size6))
Percentage Active Set Size 5 = 100 × (VS.RLSetAct.Size5 / (VS.RLSetAct.Size1 +VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5+ VS.RLSetAct.Size6))
Percentage Active Set Size 6 = 100 × (VS.RLSetAct.Size6 / (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, thatis the number of radio links established per active UE. It is derived from the sum of allRLs active in the cell divided by the sum of active sets on a per cell basis.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-7
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)
Call mobility optimization and troubleshooting Average active set size
....................................................................................................................................................................................................................................
11-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Soft handover troubleshooting...................................................................................................................................................................................................................................
Introduction
In general failures that occur during this procedure result in an increase of interferencein the system. This may have an impact on the call reliability by causing dropped callsas well as causing degradations of either the voice call quality or the packet sessionperformances.
The major SHO failure components
The major components that constitute failures of both Intra-RNC and Inter-RNC Softhandover 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 ofthe SRNC. These PMs are all provided on a per target cell basis. The identical set ofPM counters exist for the so-called Inter-RNC SHO, where SHO is performed for cellson 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 beingsent 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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-9
Related PMs / KPIs
The related PMs / KPIs are:
• 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
....................................................................................................................................................................................................................................
11-10 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• SHO.FailRLAddUESide.InterRNC.Signalling
• SHO.FailRLAddUESide.InterRNC.CSD
• SHO.FailRLAddUESide.InterRNC.CSDandPS
• SHO.FailRLAddUESide.InterRNC.CSVandPS
Call mobility optimization and troubleshooting Soft handover troubleshooting
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-11
No Node B resources available...................................................................................................................................................................................................................................
Introduction
Upon successful decoding of Measurement Report message, the RNC requests theNode B to allocate the required resources via NBAP Radio Link Addition procedure incase of respectively soft or softer handover (refer to“Soft/softer handover signalingflow” (p. 11-4))
No Node B resources available
The Node B may reject the resource allocation request due to no physical resourcesavailable. This kind of failure indicates that there are capacity issues in specific areasof the network.
This failure causes degradation ofSoft/softer Handover Success RateKPIs. TheUTRAN PM counterRLM.FailRLSetupIub.NodeBRes.<service type>identifies thesefailure causes either on a per cell basis or on a per RNC basis in case the failureoccurs in the SRNC or in the DRNC respectively.
Additional counters such asVS.RLM.MeanActiveRLandVS.RLM.MaxActiveRLprovidean indication of the number of active Radio Links.
Related PMs / KPIs
The related PMs / KPIs are:
• RLM.FailRLSetupIub.NodeBRes.<service type>
• VS.RLM.MeanActiveRL
• VS.RLM.MaxActiveRL
• Successful Active Set Update Addition Rate
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-12 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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.
This failure causes degradation of Soft/softer Handover Success Rate KPIs. TheUTRAN PM counterRLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD>identifies thesefailure causes either on a per cell basis or on a per RNC basis in case the failureoccurs in the SRNC or in the DRNC respectively.
Abnormal SHO.FailRLSetupIubUTRANSide.TransRes values
High values ofRLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD>identify no Iub linksare available due to maximum supported capacity reached.
Related PMs / KPIs
The related PMs / KPIs are:
• RLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD>
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-13
No UE answer...................................................................................................................................................................................................................................
Introduction
Upon successful resource allocation in the NodeB the RNC executes the soft/softerhandover via the RRC active set update procedure by sending to the UE the RRCactive set update message (see“Soft/softer handover signaling flow” (p. 11-4)).
If the guard timer expires and no message is received from the UE then the active setupdate procedure fails and all the allocated UTRAN resources are released.
The normal reason for this failure scenario is given by poor RF conditions either dueto poor coverage or high interference.
This failure causes degradation ofSoft/softer Handover Success RateKPIs. TheUTRAN PM counterSHO.FailRLAddUESide.NoReplyis triggered when the guardtimer expires.
Abnormal soft/softer handover success rate KPI values
Low values are caused by theSHO.FailRLAddUESide.NoReplycounter.
Related PMs / KPIs
The related PMs / KPIs are:
• SHO.FailRLAddUESide.NoReply
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-14 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
UE reject...................................................................................................................................................................................................................................
Introduction
Upon sending the Active Set Update message, in the case of failure the RNC receivesthe 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 ofSoft/softer handover success rateKPIs.
The following UTRAN PM counters are triggered on receiving the Active Set UpdateFailure 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 simultaneousre-configuration)
• SHO.FailRLAddUESide.ProtErr(in case of protocol error)
• SHO.FailRLAddUESide.ConfigUnsupport(in case of configuration unsupported)
Related PMs / KPIs
The related PMs / KPIs are:
• SHO.FailRLAddUESide.InvalidConfig
• SHO.FailRLAddUESide.IncompSimultReconf
• SHO.FailRLAddUESide.ProtErr
• SHO.FailRLAddUESide.ConfigUnsupport
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-15
Unlisted set cells...................................................................................................................................................................................................................................
Introduction
For the intra-frequency (soft / softer) handover procedure, the RNC sends a list of cellsto the UE. This list is called Cell_Info_List and it contains all cells that the UE willmeasure for intra-frequency mobility purposes. It contains all active set cells and alsothe monitored set cells (i.e. the so called neighbor cells). In addition to the active setand 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, belongto the unlisted set.
detectedSetCellReporting
For the purpose of intra-frequency measurements the 3GPP standard allows to whichcells the UE will measure to be specified, i.e. it is possible to specify if the UE will orwill not search for unlisted set cells. In the Alcatel-Lucent UTRAN the operator hasthe possibility to switch ON or OFF measurements and reporting of unlisted set cellsby means of the parameterdetectedSetCellReporting(parameter can be set to True orFalse). If the UE also searches for unlisted set cells, this will somehow slow down themeasurement process for the cells in the Cell_Info_List, but on the other hand suchmeasurements are very useful for network optimization. By means of thesemeasurements the operator is able to recognize if some cells are missing in theneighbor list, i.e. the operator is able to optimize the neighbor cell relationship byadding missing neighbor cells to the monitored set.
Neighboring cells
Each UMTS cell has its specific list of neighboring cells, which is used to derive themonitored set and the Cell_Info_List. For a UE in soft handover, there are now two ormore active set cells, which each have their individual neighbor lists. In this case theAlcatel-Lucent UTRAN generates a Cell_Info_List with all relevant monitored set cellsby invoking the Neighbor List Selection Algorithm (NLSA). The NLSA makes use ofseveral criteria, including the priority given to each cell in the neighbor lists, i.e. thehigher the priority given to a specific cell in the neighbor list, the higher theprobability that this cell is included in the Cell_Info_List. In case some relevant cell ismissing in the Cell_Info_List, the operator may consider to increase the priority givento that particular neighbor cell. If the cell is not included in the neighbor list at all itshould be added.
Handling of measurement reports in soft handover
In the case where reporting of unlisted set cells has been enabled, the UE will alsocontinuously search for cells not included in the Cell_Info_List. It will send ameasurement report to the RNC as soon as the reporting criteria for the unlisted set
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-16 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
cell are met. Whenever a Primary Scrambling Code (PSC) is received from a UE, theRNC will check if the corresponding cell was included in the Cell_Info_List. If it wasnot included in the list, then the relevant counter per primary scrambling code shall beincremented for the current best cell. This allows optimization of the neighbor cellrelationship in the network. The corresponding counter is given below.
Additionally, the RNC will check if the reported PSC is listed in the neighbor list ofany of the active set cells. In this case the cell can be identified unambiguously and thesoft handover procedure will be executed to add that cell to the active set. This is anindication that the NLSA did not select the most relevant cells to be contained in theCell_Info_List.
The priorities given to the neighbor cells need to be adapted in this case. If the celldoes not belong to the neighbor list of any of the active set cells, then the cell cannotbe identified unambiguously. No soft handover will be performed in this case. Insteadthe measurement report from the UE will be ignored and only the event will becaptured by the corresponding counter.
Related PMs / KPIs
The related PMs / KPIs are:
Number of Unlisted Neighbour Cells per Current Best Cell
Per unlisted neighbour cell the following measurement types is added:
• NumUnlistHORejPerNcell.PrimScrCodeIdentification of unlisted neighbour cell using the primary scrambling code
• NumUnlistHORejPerNcell.RejHONumber of rejected HO for the previously specified unlisted neighbour cell
Call mobility optimization and troubleshooting Unlisted set cells
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-17
CS Voice UMTS to GSM (inter-RAT) handover andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This section provides CS Voice UMTS to GSM (inter Radio Access Technology orinter-RAT) handover procedure and troubleshooting information.
Contents
CS Voice UMTS to GSM (inter-RAT) handover procedure 11-19
CS Voice relocation preparation procedure troubleshooting 11-23
CS Voice IRAT handover procedure troubleshooting 11-25
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-18 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 UMTScoverage islands are located within a GSM network, which provides full coveragewithin a certain area.
CS Voice UMTS to GSM inter-RAT procedure
CS Voice UMTS to GSM (inter-RAT) handover is always a hard handover with3G-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 RABcombinations:
• 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 CShandover is completed, the UE has to send a routing area update request message tothe GSM network containing an indication that the GSM/GPRS network needs tocontinue an already established UTRAN CN context. Whether the UE is able tocontinue 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 UMTSnetwork depending on the radio conditions.
In general the UMTS-to-GSM handover procedure can be separated in the followingsteps:
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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-19
T_interRatGuard
Radio Link Deletion Response
IU Release Complete
3
2
1
UE BSC
Relocation Required
SRNCBTSNode BInter-RAT HO triggered
within the SRNC
Channel activation procedure(with HO Reference No.)
HO Access(with HO Reference No.)
Handover Detect
Handover Complete
Handover from UTRAN Command(including GSM HO Command)
3G-MSC 2G-MSC
Radio Access Network Core Network
Map-prep-Handover req.
Handover request
Channel activation Ack.
HO Rrequest Ack.(with HO Command)
Map-prep-Handover resp.
IAM
ACMRelocation Command
(including GSM HO Command)
Handover Detect
Map-Process-Access-Sig req.
Physical Information
SABMEstablish Indication
Handover Complete
Map-Send-Access-Sig req.
Answer
IU Release Command
UA
Radio Link Deletion Request
Call mobility optimization and troubleshooting CS Voice UMTS to GSM (inter-RAT) handover procedure
....................................................................................................................................................................................................................................
11-20 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Success rate KPIs
The following KPIs provide an indication of the success rate for CS Voice UMTS toGSM handover:
• Relocation Preparation for CS UMTS to GSM HHO Success RateThis KPI indicates the relocation preparation performance for UMTS to GSM HHOfor CS calls.
• CS IRAT HO Success Rate (UMTS -> GSM)This KPI indicates the overall hard handover inter RAT performance towards GSMnetwork for CS calls starting from the relocation attempt.
• CS UMTS to GSM HHO Inter RAT Success RateThis KPI indicates the hard handover inter RAT performance towards GSMnetwork for CS calls based on Ec/No and RSCP measurements.
• CS UMTS to GSM HHO Inter RAT Success Rate - RSCP onlyThis KPI indicates the hard handover inter RAT performance towards GSMnetwork for CS calls based on RSCP measurement only.
Matrix KPIs
For UMTS to GSM optimization, but also for specific troubleshooting, there arespecial handover Matrix PM counters available. Different to other PMs, these MatrixPM counters are provided on a per originating UMTS cell to relevant terminating GSMtarget cell basis.
The UMTS to- GSM Handover Matrix PMs> CS UMTS to GSM Handover SuccessRate per GSM Neighbour Cellhelp to locate problems between UMTS and GSM cellsby providing the number of handover attempts and failures from the UMTS originatingcell to relevant GSM target cells. The counter is only available for those GSM cellsthat 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 asfollows:
1. Relocation preparation procedure failures
2. Handover procedure failures.
Related PMs / KPIs
The related PMs / KPIs are:
• 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>
Call mobility optimization and troubleshooting CS Voice UMTS to GSM (inter-RAT) handover procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-21
• 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
Call mobility optimization and troubleshooting CS Voice UMTS to GSM (inter-RAT) handover procedure
....................................................................................................................................................................................................................................
11-22 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
CS Voice relocation preparation procedure troubleshooting...................................................................................................................................................................................................................................
Introduction
Relocation preparation failures occur during the RANAP relocation preparationprocedure, for example GSM handover resource allocation fails or the core networkrejects 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 therelocation cancel procedure enables the CN to initiate the release of the resourcesallocated during the relocation preparation procedure in the GSM network. The SRNCconsiders the UMTS to GSM handover as impossible at this point in time and keepsthe existing radio connections established. This means that the existing Iu-signalingconnection can be further used for the call.
Relocation preparation failure
Receiving a Relocation Preparation Failure message from the 3G-MSC, the SRNC stillmaintains the call. If the failure cause specified within the message isRelocationFailure in Target CN/RNCor Target Systemor Relocation not supported in Target RNCor Relocation Target Not Allowedor No Radio Resources Available in Target Cell, thenSRNC repeats the relocation preparation procedure with the next suitable cell from thelist of potential GSM target cells otherwise the SRNC considers the UMTS to GSMhandover as impossible at this point in time.
The counterIRATHO.FailRelocPrepOutCS.sumincludes all the failure causes occurredalong the Handover Relocation Preparation procedure.
Also the following PM counters help to identify the specified failure causes:
• IRATHO.FailRelocPrepOutCS.RelocCanc
• IRATHO.FailRelocPrepOutCS.ReqCiphNotSupp
• IRATHO.FailRelocPrepOutCS.FailTarSys
• IRATHO.FailRelocPrepOutCS.NotSupTarSys
• IRATHO.FailRelocPrepOutCS.TarNotAllowed
• IRATHO.FailRelocPrepOutCS.NoRRTarCell
• IRATHO.FailRelocPrepOutCS.TrLdHighTarCell
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-23
• IRATHO.FailRelocPrepOutCS.AbstSyntErr
• IRATHO.FailRelocPrepOutCS.OmInt
• IRATHO.FailRelocPrepOutCS.NoResAv
• IRATHO.FailRelocPrepOutCS.UnspecFail
• IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp
Call mobility optimization and troubleshooting CS Voice relocation preparation proceduretroubleshooting
....................................................................................................................................................................................................................................
11-24 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
CS Voice IRAT handover procedure troubleshooting...................................................................................................................................................................................................................................
Introduction
Upon successful completion of relocation preparation procedure, the SRNC sends thehandover 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 handoverfrom 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 counterIRATHO.FailOutCS-.PhyChnFailwill be incremented.
Unacceptable configuration / protocol Error
Unacceptable configuration and protocol error are expected to occur seldom and ingeneral they are not related to RF issues. These are pegged by the PM countersIRATHO.FailOutCS.ConfUnacceptand IRATHO.FailOutCS.ProtErr.
Related PMs / KPIs
The related PMs / KPIs are:
• IRATHO.FailOutCS.PhyChnFail
• IRATHO.FailOutCS.ConfUnaccept
• IRATHO.FailOutCS.ProtErr
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-25
CS Voice GSM to UMTS (inter-RAT) handover andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This section provides CS Voice GSM to UMTS (inter Radio Access Technology orinter-RAT) handover and troubleshooting information.
Contents
CS Voice GSM to UMTS (inter-RAT) handover procedure 11-27
Relocation resource allocation procedure troubleshooting 11-30
Handover procedure troubleshooting 11-32
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-26 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
CS Voice GSM to UMTS (inter-RAT) handover procedure...................................................................................................................................................................................................................................
Introduction
Handover from GSM to UMTS (inter-RAT) is supported for CS voice calls. The GSMcan trigger the handover depending on several conditions, for example, as soon assufficient UMTS coverage is available or when the GSM coverage is no longersufficient.
CS Voice GSM to UMTS (inter-RAT) handover
CS Voice GSM to UMTS handover can be performed for the following RABcombinations:
• 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 followingsteps:
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
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-27
CS Voice GSM to UMTS handover signaling flows
Relocation Complete
Clear Complete
Relocation Request
ALCAP Iu Transport Bearer Setup
Radio Link Setup Response
ALCAP Iu Transport Bearer Setup+ Frame Protocol Sync.
Relocation Request Ack.(Including HO to UTRAN Command)
Radio Link Release
3
2
1
UE BSC
Handover Required
SRNCBTSNode B
Relocation Request
In Sync. Detection
Radio Link Restore Indication
Handover Command(including HO to UTRAN Command)
3G-MSC 2G-MSC
Radio Access Network Core Network
Map-prep-Handover req.
Radio Link Setup Request
Map-prep-Handover resp.
IAM
ACM
Handover Command(including HO to UTRAN Command)
Relocation DetectMap-Process-
Access-Sig req.
Map-Send-Access-Sig req.
Answer
Clear Command
Handover to UTRAN Complete
Call mobility optimization and troubleshooting CS Voice GSM to UMTS (inter-RAT) handover procedure
....................................................................................................................................................................................................................................
11-28 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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 thepercentage 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 beclassified as follows:
1. Relocation resource allocation procedure failures
2. Handover procedure failures.
Related PMs / KPIs
The related PMs / KPIs are:
• 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 CallRelease Impacted
Call mobility optimization and troubleshooting CS Voice GSM to UMTS (inter-RAT) handover procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-29
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 resourceallocation fails in the target cell.
Failure causes
A failure occurs due to the following 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 GSMto UMTS handover is aborted. If the PM counterIRATHO.FailIncCS.HoNotEnabledhas a value greater 0, the network configuration should be checked. If the handovershould be allowed, then the UMTS network has to be reconfigured to allow for theincoming GSM to UMTS handover. If the handover should not be allowed for thistarget cell, then the GSM network should be reconfigured so that no handover isinitiated 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 onlythe PM counterIRATHO.FailIncCS.sumis 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 Requestmessage
• The UE does not support the target cell frequency band
• The ciphering or integrity protection cannot be configured because the UE SecurityCapability 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 setupfails on Iub or the ALCAP Iu transport bearer cannot be established.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-30 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Related PMs/KPIs
The related PMs / KPIs are:
• IRATHO.FailIncCS.sum
• IRATHO.FailIncCS.HoNotEnabled
Call mobility optimization and troubleshooting Relocation resource allocation procedure troubleshooting
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-31
Handover procedure troubleshooting...................................................................................................................................................................................................................................
Introduction
Relocation failures occur during the handover procedure, when the UE does not accessthe target cell or the MSC cancels the relocation before the UE has accessed the targetcell.
Failure causes
A failure occurs due to the following causes:
• Timer expiry
• Relocation cancel.
Timer expiry
After the relocation resource allocation procedure the UTRAN waits for the UE toaccess the target cell and to send the RRC message HANDOVER TO UTRANCOMPLETE. If this message is not received the PM countersIRATHO.FailIncCS.sumand IRATHO.FailIncCS.T_hoToUtranCompleteare incremented.
Probable causes for this failure are:
• The UE has moved out of GSM coverage and the call has dropped before thehandover command was sent to the UE by the GSM network. If this occurs, thenthe handover should be initiated earlier in GSM
• The UE cannot access the UMTS cell due to insufficient radio conditions. In caseof measurement based handover the threshold values for the UMTS system shouldbe increased to ensure that the UMTS quality is sufficient before a handover isinitiated. In case of blind handover the network configuration should be checked ifthe UMTS cell is a acceptable target for the complete coverage area of the GSMsource cell.
Relocation cancel
The GSM network has cancelled the relocation due to any reason that is outside of thescope of UTRAN.
Related PMs/KPIs
The related PMs / KPIs are:
• IRATHO.FailIncCS.sum
• IRATHO.FailIncCS.T_hoToUtranComplete
• IRATHO.FailIncCS.RelocCancel
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-32 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
PS UMTS to GSM (inter-RAT) Cell Change Orderand troubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This section provides PS UMTS to GSM (inter-RAT) Cell Change Order andtroubleshooting information.
Contents
PS UMTS to GSM (inter-RAT) Cell Change Order procedure 11-34
PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting 11-37
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-33
PS UMTS to GSM (inter-RAT) Cell Change Order procedure...................................................................................................................................................................................................................................
Introduction
Cell Change Order from UMTS to GSM is supported in the current Alcatel-LucentUMTS Release. The UMTS to GSM (inter-RAT) Cell Change Order is based on theassumption that UMTS coverage islands are located within a GSM network, whichprovides 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 aGSM target cell. The UE must have established a packet-switched (PS) but nocircuit-switched (CS) connection to the UMTS network.
For a UE which is involved simultaneously in a CS voice call and a PS connection theCS voice inter-RAT handover procedure is applicable.
Upon a cell change order failure the PS connection is further served by the UMTSnetwork depending on the radio conditions.
In general the UMTS to GSM Cell Change Order procedure can be separated in thefollowing 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
...................................................................................................................................................................................................................................
11-34 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
PS UMTS to GSM Cell Change Order signaling flow
Success rate KPIs
The following KPIs provide an indication of the success rate for UMTS to GSMhandover:
• PS IRAT HO Success Rate (UMTS -> GSM)This KPI measures the percentage of Cell Change Order from UTRAN proceduressuccessfully completed.
• PS UMTS to GSM HHO Inter RAT Success Rate - RSCP onlyThis KPI indicates the percentage of Cell Change Order from UTRAN proceduressuccessfully completed based on RSCP measurement only.
RANAP
3. The UE accesses the GSMsystem and initiates routingarea update. The packet contextis transferred to the new SGSN
RANAP5. SRNS Context Response
RANAP RANAP6. Iu Release Command
UE SGSNServing
RNC
2. Cell Change Order from UTRAN
1. UTRAN decision to perform Cell Change Order from UTRAN:PS connection only, Cell_DCH or Cell_FACHRegard for “Service Handover”Measurement based (MAHO: 2d, 2f, 3a, 3c; DAHO: 2d)
RRC
RANAP
RRC
RANAP4. SRNS Context Request
RANAP RANAP7. Iu Release Complete
Call mobility optimization and troubleshooting PS UMTS to GSM (inter-RAT) Cell Change Orderprocedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-35
Matrix KPIs
For UMTS to GSM optimization, but also for specific troubleshooting, there arespecial handover Matrix PM counters available. Different to other PMs, these MatrixPM counters are provided on a per originating UMTS cell to relevant terminating GSMtarget cell basis.
The UMTS to GSM Handover Matrix PMsVS.MX.IRATHO.OutPSUTRAN.<type> PSHard Handover Inter RAT Success Rate per GSM Neighbour Cellhelp to locateproblems between UMTS and GSM cells by providing the number of handoverattempts and failures from the UMTS originating cell to relevant GSM target cells. Thecounter is only available for those GSM cells that are a target for handover in thereporting 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 asfollows:
1. The UE returns to UMTS with a failure indication
2. The procedure times out
Related PMs / KPIs
The related PMs / KPIs are:
• 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
Call mobility optimization and troubleshooting PS UMTS to GSM (inter-RAT) Cell Change Orderprocedure
....................................................................................................................................................................................................................................
11-36 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
PS UMTS to GSM (inter-RAT) Cell Change Ordertroubleshooting...................................................................................................................................................................................................................................
Introduction
Cell Change Order from UTRAN failures occur when the Cell Change Order fromUTRAN command was sent to the UE and the UE either returns with a failuremessage to UMTS or the procedures times out.
Failure causes
A failure occurs due to the following 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 RNCstarts the timercellChangeOrderFromUTRANSupervisionTimer. If neither the Iuconnection is released by the SGSN nor the UE returns with Cell Change Order fromUTRAN Failure before the timer expires, then the Iu connection release is initiated bythe RNC. In case of procedure timeout the UTRAN has no knowledge if the call wassuccessfully established in GSM or the call was dropped.
The Cell Change Order procedure time includes the time needed for the UE to accessthe GSM cell, optionally perform location area update, perform routing area update andsecurity procedures. All in all several seconds are needed. If the procedure timeoutoccurs it should be verified that the parametercellChangeOrderFromUTRANSu-pervisionTimeis set to a sufficiently high value. Also some resources are occupied alittle bit longer in UMTS in case of failure, there is no drawback of a highercellChangeOrderFromUTRANSupervisionTime.
Another cause for this failure could be that the UE has moved out of UMTS coverageand the call has dropped before the Cell Change Order command was sent to the UEor the UE could not return to UMTS with a Cell Change Order from UTRAN Failuremessage. If this occurs then the Cell Change Order should be initiated earlier byincreasing the threshold values.
The counterVS.IRATHO.TimeoutOutPSUTRANpegs the procedure timeout on expiryof the cellChangeOrderFromUTRANSupervisionTimer.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-37
The most likely failure cause is that there are network configuration issues in the corenetwork 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 RNCmaintains the call in UMTS. The next Cell Change Order is attempted aftercellChangeOrderFromUTRANRepetitionTimeif the conditions for a Cell Change toGSM are still fulfilled.
Failure causes
The failure causes that are pegged separately are as follows:
• Physical channel failure
• Unacceptable configuration
• Protocol error.
The counterIRATHO.FailOutPSUTRAN.sumincludes all the failure causes occurredalong 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 counterIRATHO.FailOutP-SUTRAN.PhyChnFailwill be incremented.
Unacceptable configuration / protocol Error
“Unacceptable configuration” and “protocol error” are expected to occur rarely and ingeneral they are not related to RF issues. These are pegged by the PM countersIRATHO.FailOutPSUTRAN.ConfUnacceptand IRATHO.FailOutPSUTRAN.ProtErr.
Related PMs / KPIs
The related PMs / KPIs are:
• IRATHO.FailOutPSUTRAN.sum
• IRATHO.FailOutPSUTRAN.ConfUnaccept
• IRATHO.FailOutPSUTRAN.PhyChnFail
• IRATHO.FailOutPSUTRAN.ProtErr
• VS.IRATHO.TimeoutOutPSUTRAN
Call mobility optimization and troubleshooting PS UMTS to GSM (inter-RAT) Cell Change Ordertroubleshooting
....................................................................................................................................................................................................................................
11-38 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Serving HS-DSCH Cell Change
Overview...................................................................................................................................................................................................................................
Purpose
This section provides Serving HS-DSCH Cell Change procedure and troubleshootinginformation.
Contents
Serving HS-DSCH Cell Change procedure 11-40
Serving HS-DSCH Cell Change troubleshooting 11-43
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-39
Serving HS-DSCH Cell Change procedure...................................................................................................................................................................................................................................
Introduction
Serving HS-DSCH Cell Change is supported in current Alcatel-Lucent UMTS Releasefor HSDPA calls. When the best cell within the active set changes to another cell thenthe Serving HS-DSCH Cell Change procedure is performed. The procedure involves ahard 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 theHS-DSCH channel from the old best cell to the new best cell while keeping the activeset unchanged. The procedure is triggered by the receipt of a event 1d or receipt ofevent 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
...................................................................................................................................................................................................................................
11-40 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Serving HS-DSCH Cell Change signaling flows (example for inter-NodeB serving cell change)
Success rate KPIs
Following KPI provides an indication of the success rate for Serving HS-DSCH CellChange:
• HS-DSCH Cell Change Success RateThis KPI measures the percentage of Serving HS-DSCH Cell Change proceduressuccessfully completed.
RL Reconfig Ready
For example, Event 1D
New NodeB
SynchronousReconfigure
Reset MAC-hsentity
DATA
ALCAP Iub HS-DSCHData Transfer Bearer
Release
RL Reconfig Prepare
RL Reconfig Commit
RL Reconfig Prepare
ALCAP Iub HS-DSCH Data Transport Bearer Setup
RL Reconfig Ready
SourceHS-DSCH cell
S-RNC=
C-RNCUETarget
HS-DSCH cell
Serving HS-DSCHcell change decision
RL Reconfig Commit
Transport Channel Reconfiguration
Transport Channel Reconfiguration
Call mobility optimization and troubleshooting Serving HS-DSCH Cell Change procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-41
Serving HS-DSCH Cell Change failures
Components that constitute failures of Serving HS-DSCH Cell Change may beclassified as follows:
1. The UE transmits a failure indication
2. The procedure times out
Related PMs / KPIs
The related PMs / KPIs are:
• HS-DSCH Cell Change Success Rate
Call mobility optimization and troubleshooting Serving HS-DSCH Cell Change procedure
....................................................................................................................................................................................................................................
11-42 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Serving HS-DSCH Cell Change troubleshooting...................................................................................................................................................................................................................................
Introduction
Serving HS-DSCH Cell Change failures occur when RRC reconfiguration commandwas sent to the UE and the UE either replies with a failure message or the procedurestimes out.
Failure causes
A failure occurs due to the following 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 thetimer tSynchTranChanComplete. If neither a RRC Reconfiguration Complete norFailure message is received from the UE before the timer expires, then the Iuconnection release is initiated by the RNC
RRC Reconfiguration Failure
On receipt of a RRC Reconfiguration Failure message from the UE, the RNCreconfigures the call to DCH (R99), if possible, to further maintain the call in UMTS.
Related PMs / KPIs
The related PMs / KPIs are:
• VS.AttServCellChangeHSDSCH
• VS.FailServCellChangeHSDSCH.sum
• VS.FailServCellChangeHSDSCH.TransChnReconfigFail
• VS.FailServCellChangeHSDSCH.TransChnReconfigTout
• Successful Serving HS-DSCH Cell Changes
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-43
Inter-frequency hard handover and troubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This section provides Inter-frequency hard handover and hard handover troubleshootinginformation.
Contents
Inter-frequency hard handover procedure 11-45
Hard handover troubleshooting 11-50
No Node B resources available 11-53
No transport resources available 11-54
UE reject 11-55
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-44 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Inter-frequency hard handover procedure...................................................................................................................................................................................................................................
Introduction
Inter-frequency hard handover (HHO) is particularly needed to change frequencieswithin a UMTS network. Generally, changing of frequencies cannot be doneseamlessly due to limitations in the mobile and in the radio access network. Thus abreak 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, qualitybased inter-frequency HHO may be used to transfer the call to another UMTSfrequency providing better quality. If the load in an UMTS cell becomes too high, loadbased inter-frequency HHO may be used to transfer the call to another UMTS cell onanother frequency with less load.
The handover algorithms are:
• mobile assisted handover (MAHO), i.e. based on measurements and data baseassisted 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 andDAHO are applicable, preference is given to MAHO.
Inter-frequency HHO is performed for circuit switched calls, packet switched calls aswell 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 setupin 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 isstopped and measurement 2B and 2F are setup
3. On receipt of measurement 2F, if the signal quality is strong again, measurement2B and 2F are stopped and measurement 2D is setup again
4. On receipt of measurement 2B from the UE, inter-frequency HHO procedure istriggered.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-45
Quality based inter-frequency HHO (DAHO)
1. Measurement 2D is setup in the UE. On receipt of measurement 2D from the UE,inter-frequency HHO procedure is triggered.
Load based inter-frequency HHO (MAHO)
1. Measurement 2C is setup in the UE. On receipt of measurement 2C from the UE,inter-frequency HHO procedure is triggered.
Load based inter-frequency HHO (DAHO)
1. No Measurements are setup in the UE. If the load in the cell on current usedfrequency is too high, inter-frequency HHO procedure is triggered
Inter-frequency hard handover signaling flow
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
2. Radio Link Setup Response
3. ALCAP Iub Transport Bearer Setup
5. UE Detected
6. Physical Channel Reconfiguration Complete
8. Radio Link Deletion Response
9. ALCAP Iub Transport Bearer Release
UE SRNC
Measurement Report Event 2B
new Node Bold Node B
1. Radio Link Setup Request
4. Physical Channel Reconfiguration
7. Radio Link Deletion Request
4
3
2
1
Call mobility optimization and troubleshooting Inter-frequency hard handover procedure
....................................................................................................................................................................................................................................
11-46 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
3. Execute hard handover towards UE:
• via RRC physical channel re-configuration procedure for DCH to DCHhandover, or
• via transport channel re-configuration procedure for HSDSCH to HSDSCH orHSDSCH/E-DCH to HSDSCH/E-DCH handover.
The hard handover procedure is successfully executed on receipt of a RRC physicalchannel reconfiguration complete or transport channel reconfiguration completemessage at the RNC.
4. Clear resources on the old frequency in the UTRAN via NBAP procedure. Theentire procedure is supervised by the inter-frequency hard handover proceduretimer.
Hard handover scenarios
In the current release, Inter-Frequency hard handovers can be executed for followingconfigurations:
• 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 differentRNC roles is applied as follows:
• The controlling RNC (CRNC) provides the Iub Interface towards Node B andcontrols the setup, addition and release of radio links with NBAP signalling
• The serving RNC (SRNC) provides the Iu Interface towards core network (CN) andthe Uu Interface towards UE for the actual connection. Depending on the actualconfiguration the SRNC provides the Iur interface(s) towards drift RNC(s) and/orthe Iub Interface(s) towards Node B(s).The SRNC controls the measurements to be performed by the UE. On reception ofmeasurement reports the SRNC initiates and controls the handover protocol withRRC, RNSAP and NBAP signalling. It acts as CRNC for Node B(s) directlyconnected and controls the CRNC functions at a drift RNC for Node B(s) notdirectly connected.
• The drift RNC (DRNC) acts as CRNC. It performs the CRNC functions inaccordance to requests of the SRNC and reports the results.
Note: Intra Node B handover or Inter Node B / Intra-RNC handover may take placeeither 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 Bhandover within a DRNC the procedure is executed in the same way as where SRNCis executing physical channel or transport channel reconfiguration procedure (step 3)
Call mobility optimization and troubleshooting Inter-frequency hard handover procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-47
while DRNC is taking care of the NBAP procedures (steps 2 and 4) initiated by theSRNC through the Iur interface via corresponding Radio Network SubsystemApplication Part (RNSAP) procedures.
Inter-frequency hard handover towards a target cell which is controlled by a DRNC isonly applicable for quality based DCH to DCH handover.
The figure below shows the all-embracing successful inter-frequency handoverprocedure (DCH to DCH) for inter Node B, Inter-RNC case. Two DRNCs and theSRNC are involved. The description can be reduced to the various network scenariosgiven above by allocating the CRNC to the SRNC or to the DRNC respectively. If theCRNC is at the SRNC, then the RNSAP procedures 1, 5, 6 and/or 10, 14, 15 can beomitted.
Call mobility optimization and troubleshooting Inter-frequency hard handover procedure
....................................................................................................................................................................................................................................
11-48 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
14. Radio Link Deletion Response
15. ALCAP Iur Transport Bearer Release
3. Radio Link Setup Response
4. ALCAP Iub Transport Bearer Setup
8. UE Detected
9. Physical Channel Reconfiguration Complete
12. Radio Link Deletion Response
13. ALCAP Iub Transport Bearer Release
UE SRNC
Measurements and Handover Decision
Node B newNode B old
1. Radio Link
7. Physical Channel Reconfiguration
10. Radio Link Deletion Request
DRNC newDRNC old
Setup Request2. Radio Link Setup Request
5. Radio Link Setup
6. ALCAP IurTransport Bearer Setup
11. Radio Link Deletion Request
Call mobility optimization and troubleshooting Inter-frequency hard handover procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-49
Hard handover troubleshooting...................................................................................................................................................................................................................................
Introduction
In general failures that occur during this procedure result in an increase of interferencein the system. This may have an impact on the call reliability by causing dropped callsas well as causing degradations of either the voice call quality or the packet sessionperformances.
The major HHO failure components
The major components that constitute failures of both Intra-RNC and Inter-RNC Hardhandover 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. InterRNC HHO involves a DRNC and may be performed between SRNC and DRNC orbetween two DRNCs.
With respect to setting up the resources in UTRAN (step 2 of the interworkinginter-frequency HHO procedure) the counters which are already defined for softhandover radio link performance measurement are reused for hard handover. In detailthe 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
...................................................................................................................................................................................................................................
11-50 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• 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 theDRNC. 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.QualAttempted preparations for outgoing inter-frequency hard handovers due to quality
• VS.HHO.AttPrepOutInterFreq.LoadAttempted preparations for outgoing inter-frequency hard handovers due to load
Call mobility optimization and troubleshooting Hard handover troubleshooting
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-51
With respect to hard handover execution (step 3 of the interworking inter-frequencyHHO procedure) the following hard handover specific counters are used:
• HHO.AttOutInterFreq.QualAttempted outgoing inter-frequency hard handovers due to quality
• HHO.SuccOutInterFreq.QualSuccessful 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.LoadAttempted outgoing inter-frequency hard handovers due to load
• HHO.SuccOutInterFreq.LoadSuccessful 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 intraRNC handover and on per PRNC basis in case of inter RNC handover. The loadrelated counters (*.Load) are applied on per cell basis only.
If the inter-frequency hard handover procedure timer expires while step 3 is inprogress, then the following hard handover specific counters are used for CS- or PS -RABs respectively:
• VS.RAB.Drop.CS.InterFreqHHONumber of dropped CS RABs due to inter-frequency hard handover
• VS.RAB.Drop.PS.InterFreqHHONumber of dropped PS RABs due to inter-frequency hard handover
In order to be able to analyze the handover performance with respect to neighbor cellrelations the following matrix counters are used. The number of attempted andsuccessful 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
Call mobility optimization and troubleshooting Hard handover troubleshooting
....................................................................................................................................................................................................................................
11-52 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
No Node B resources available...................................................................................................................................................................................................................................
No Node B resources available
The Node B may reject the resource allocation request due to no physical resourcesavailable. This kind of failure indicates that there are capacity issues in specific areasof the network. As CAC and DBC thresholds ensure enough radio capacity for SHOresources, this may be caused by either too many overlapping pilots or by an impropersetting of some of the SHO algorithm parameters.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-53
No transport resources available...................................................................................................................................................................................................................................
Introduction
The NBAP / RNSAP radio link setup and radio link addition procedure may fail due tono transport resources available, this means no Iub/Iur links are available due tomaximum supported capacity reached.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-54 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
UE reject...................................................................................................................................................................................................................................
Introduction
Upon sending the physical channel reconfiguration or transport channel reconfigurationmessage in the case of failure the RNC receives the physical channel reconfigurationfailure 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
• Physical channel failure
• 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
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-55
Inter-system directed retry
Overview...................................................................................................................................................................................................................................
Purpose
This section provides inter-system directed retry optimization and troubleshootinginformation
Contents
Inter-system directed retry procedure 11-57
Inter-system directed retry troubleshooting 11-60
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-56 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Inter-system directed retry procedure...................................................................................................................................................................................................................................
Introduction
Directed retry combines RAB assignment with hard handover. The RAB assignmentduring call setup is avoided in UMTS and shifted to GSM instead. The original RABassignment procedure only provides the trigger for the UMTS-to-GSM handover andwill not be executed. The subsequent handover procedure implicitly performs thetraffic channel assignment functions within GSM. In the current release inter-systemdirected retry is supported for emergency calls. Furthermore it is supported for WPScalls in case of congestion.
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-57
Inter-system directed retry signaling flow
10. Radio Link Deletion Response
14. IU Release Complete
4
3
1
UE BSC
1. Rab Assignment Request
SRNCBTSNode B
Channel Activation
Handover Complete
3G-MSC 2G-MSC
Map-prep-HO req.
2. RAB Assignment ResponseCause: Directed Retry
Handover Request(incl. GSM HO Command)
Map PrepHandover resp.
IAM
ACM
Handover Detect
Map-PrAcc Signal
Establish Indication
Handover Complete
Map SendEnd Signal
ANM
6. IU Release Command
9. Radio Link Deletion Request
DRNC
Decision for Directed Retry
3. RAB Assignment ResponseCause: Directed Retry
Channel Activation Ack.
Handover Request Ack.
Relocation Command(incl. GSM HO Command)
Handover from UTRAN Command(incl. GSM HO Command)
Handover AccessHandover Detect
Physical Information
SABM
7. ALCAP Iu Transport B Release
Radio Link Failure Indication
8. RL DeleteRequest
11. ALCAP Iub Transport B Release8. RL DeleteResponse
13. ALCAP Iur Transport B Release
2
UA
Call mobility optimization and troubleshooting Inter-system directed retry procedure
....................................................................................................................................................................................................................................
11-58 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
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.
Call mobility optimization and troubleshooting Inter-system directed retry procedure
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
11-59
Inter-system directed retry troubleshooting...................................................................................................................................................................................................................................
Introduction
The functions for troubleshooting in case of directed retry are essentially the same asfor UMTS-to-GSM handover (refer to the respective sections). Only during therelocation preparation procedure specific directed retry PMs are used.
Directed retry PMs/KPIs
During the relocation preparation procedure the following specific directed retry PMsare used:
• VS.IRATHO.AttRelocPrep.DirRetryAttempted relocation preparations for inter-system directed retry
• VS.IRATHO.SuccRelocPrep.DirRetrySuccessful relocation preparations for inter-system directed retry
• Failed relocation preparation for inter-system directed retry for the following causesfrom 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 specificdirected retry PM is used:
• VS.IRATHO.SuccOutCS.DirRetrySuccessful Inter-System UMTS to GSM Directed Retry
Call mobility optimization and troubleshooting
...................................................................................................................................................................................................................................
11-60 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
12 12Throughput optimization andtroubleshooting
Overview...................................................................................................................................................................................................................................
Purpose
This chapter describes the UTRAN measurements and performance indicators that canbe used to measure the throughput for the various uplink and downlink speeds and canprovide an analysis to optimization related issues.
Contents
Throughput optimization 12-2
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
12-1
Throughput optimization...................................................................................................................................................................................................................................
RLC SDU Throughput and Data volume
Radio Link Control (RLC) is the layer two protocols used in 3G UMTS cellularsystems for flow control and error recovery. In the layered architecture of UMTS radiointerface protocols, RLC sits above the MAC (Medium Access Control) layer, whichhandles the scheduling of radio bearers with different QoS requirements, and below theRRC (Radio Resource Control) layer, which is responsible for setting up, modifyingand 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 RLCPDU size is set according to the lowest possible bit rate for the services using RLC. Incase of small SDUs, several SDUs can be concatenated into one RLC PDU. At thereceiving end, the PDUs that contain fragments of an SDU are reassembled and theSDU is delivered to the higher layer.
The Alcatel-Lucent throughput KPIs measure at the RLC SDU layer. Total throughputon the RLC SDU layer for the uplink and downlink on a RNC level are available fromthe VS.Datarate.xx.xxPMs. The Data volume indicators which calculate using theDatarate 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 whichincludes silence periods in the 15 minute interval. Metrics are available for HSDPA,EDCH and Non-HSDPA packet calls for the downlink and uplink. Individual downlinkthroughput for bearer rates of 16kbps, 32kbps, 64kbps, 128kbps and 384kbps can beseen from the PM,VS.Datarate.PSxxDLand uplink throughput for bearer rates of 16kbps, 32kbps, 64kbps, 128kbps and 384kbps byVS.Datarate.PSxxUL. The KPI,HSDPA - data volume on RLC SDUprovides the data volume on Uu after compressionby Packet Data Convergence Protocol. The metricUL E-DCH - data volume on RLCSDU provides the data volume on the EDCH (uplink) at the RLC SDU layercalculating the payload bits included in the RLC PDU received from the NodeB. Allthe 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 poorsignal strength and interference. In such cases drive tests in the affected area wouldprovide insight into the problem. There could also be issues due to power control andDynamic Bearer Control (DBC) parameter settings, which would need to be optimized.In some cases the user profile configurations for the various QoS negotiated could alsolead to lower throughput, which would require the profiles to be reconfigured in thecore 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
...................................................................................................................................................................................................................................
12-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
• 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
• UL 128 kbps - data volume on RLC SDU
• UL 384 kbps - data volume on RLC SDU
QoS Based Throughput
Downlink throughput at the RLC SDU layer based on QoS type can be measured bythe 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 forthe various QoS classes may need to be optimized at the core network. However astudy of the radio conditions, RLC, DBC, Power control parameters and value of otherthroughput indicators will need to be investigated in tandem to derive an accurateanalysis 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 toreduce the load on the RNC and as a consequence the throughput experienced by thesubscriber will be affected. The total number of payload bits in the PDU discarded areaggregated and divided by the number of seconds in the granularity period and the lostthroughput is reported through these counters. A large value for these PMs will requiredetailed planning steps to alleviate load on the RNCs. The counters are pegged for the
Throughput optimization and troubleshooting Throughput optimization
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
12-3
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 geta 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 becalculated by the KPI,DL mean user data rate received on PS CN. The data rate ofdiscarded DL user bits on the IuPS is calculated by recording the discarded TrafficPDUs and can be measured usingDL 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
Throughput optimization and troubleshooting Throughput optimization
...................................................................................................................................................................................................................................
12-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
Glossary
....................................................................................................................................................................................................................................
Numerics
3GPP3rd Generation Partnership Project
....................................................................................................................................................................................................................................
A AALAsynchronous Transfer Mode Adaptation Layer
AICHAcquisition Indicator Chanel
ALCAPAccess Link Control Application Protocol
AMAcknowledged Mode
ARQAutromatic Repeat Request
ATMAsynchronous Transmission Mode
....................................................................................................................................................................................................................................
B BCCHBroadcast Control Channel
BCHBroadcast Channel
BLERBlocking Error Rate
....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
GL-1
BMCBroadcast/Multicast Control
....................................................................................................................................................................................................................................
C CACCall Admission Control
CCCall Control
CCCHCommon Control Channel
CCPCHCommon Control Physical Channel
CDMACode Division Multiple Access
CFNConnection Frame Number
CPCHCommon Packet Channel
CPICHCommon Pilot Channel
CRNCControlling Radio Network Controller
CSCircuit Switched domain
CTCHCommon Traffic Channel
....................................................................................................................................................................................................................................
D DBCDynamic Bearer Control
DCDedicated Control
DCCHDedicated Control Channel
Glossary
...................................................................................................................................................................................................................................
GL-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
DCHDedicated Channel
DLDownLink
DPCCHDedicated Physical Control Channel
DPCHDedicated Physical Channel
DPDCHDedicated Physical Data Channel
DRNCDrift Radio Network Controller
DSCHDownlink Shared Channel
DTCHDedicated Traffic Channel
....................................................................................................................................................................................................................................
E E2EEnd-to-End
Ec/IoSignal to Noise ratio
....................................................................................................................................................................................................................................
F FACHForward Access Channel
FBIFeedBack Information
FDDFrequency Division Duplex
FPFrame Protocol
....................................................................................................................................................................................................................................
G GCGeneral Control
Glossary
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
GL-3
GPRSGeneral Packet Radio Service
GPSGlobal Positioning System
GSMGlobal System for Mobile communications
GTPGPRS Tunnelling Protocol
....................................................................................................................................................................................................................................
I IPInternet Protocol
IRATInter-Radio Access Technology
....................................................................................................................................................................................................................................
K KPIKey Performance Indicator
....................................................................................................................................................................................................................................
L LALocation Area
LCATLucent Cells Application Tool
LDAT3GLucent Data Analysis Tool for 3G
....................................................................................................................................................................................................................................
M MACMedium Access Control
MAC-bBroadcast Medium Access Control
MAC-c/shCommon Medium Access Control
MAC-dDedicated Medium Access Control
Glossary
...................................................................................................................................................................................................................................
GL-4 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
MMMobility Management
MOMobile Originated call
MSCMobile Switching Center
MTMobile Terminated call
MTP3Message Transfer Protocol 3
....................................................................................................................................................................................................................................
N NASNetwork Access Server
NBAPNode B Application Part
NtNotification
....................................................................................................................................................................................................................................
O OCNSOrthogonal Channel Noise Simulation
OMCOperation and Maintenance Center
OMC-UPSOMC for the UTRAN and the Packet Core cluster
....................................................................................................................................................................................................................................
P P-CCPCHPrimary Common Control Physical Channel
P-CPICHPrimary Common Pilot Channel
P-SCHPrimary Synchronization Channel
PCPersonal Computer
Glossary
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
GL-5
PCCHPaging Control Channel
PCHPaging Channel
PCPCHPhysical Common Packet Channel
PDCPPacket Data Convergence Protocol
PDPPacket Data Protocol
PDSCHPhysical Downlink Shared Channel
PDUPacket Data Unit
PICHPaging Indication Channel
PMPerformance Management
PMMPacket Mobility Management
PRACHPhysical Random Access Channel
PSPacket Switched domain
PSCPrimary Scrambling Code
....................................................................................................................................................................................................................................
Q QoSQuality of Service
....................................................................................................................................................................................................................................
R RARouting Area
Glossary
...................................................................................................................................................................................................................................
GL-6 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
RABRadio Access Bearer
RACHRandom Access Channel
RANAPRadio Access Network Application Protocol
RBRadio Bearer
RFRadio Frequency
RLCRadio Link Control
RLFRadio Link Failure
RNCRadio Network Controller
RNSAPRadio Network Subsystem Application Part
RNTIRadio Network Temporary Identity
RRCRadio Resource Control
RTPReal-Time Protocol
....................................................................................................................................................................................................................................
S S-CCPCHSecondary Common Control Physical Channel
S-CPICHSecondary Common Pilot Channel
S-SCHSecondary Synchronization Channel
SAALSignaling ATM Adaptation Layer
Glossary
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
GL-7
SAPService Access Point
SCHSynchronization Channel
SDUService Data Unit
SFSpreading Factor
SGSNServing GPRS Support Node
SMSession Management
SPAT3GService Performance Analysis Tool for 3G
SRNCServing Radio Network Controller
SSCFService Specific Coordination Function
SSCOPService Specific Connection Oriented Protocol
STMSynchronous Transport Module
....................................................................................................................................................................................................................................
T TFCTraffic Format Combination
TMTRansparent Mode
TPCTransmit Power Control
....................................................................................................................................................................................................................................
U UCUUMTS Channel Unit
Glossary
...................................................................................................................................................................................................................................
GL-8 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007
UDPUser DAtagram Protocol
UEUser Equipment
ULUpLink
UMUnacknowledged Mode
UMSCUMTS Mobile Switching Center
UMTSUniversal Mobile Telecommunication System
UNIUser-Network Interface
URAUTRAN REgistration Area
USCHUplink Shared Channel
UTRANUMTS Terrestrial Radio Access Network
....................................................................................................................................................................................................................................
V VLRVisitor Location Register
....................................................................................................................................................................................................................................
W WAGWireless Application Gateway
Glossary
...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
GL-9
Index
A Access preliminary procedures,8-8
Average active set size,11-7
................................................................................................
C Call admission control failures,8-19
Call availability, 8-4
Call mobility optimization and troubleshooting
CS Voice GSM to UMTS (inter-RAT) handoverand troubleshooting,11-26
CS Voice UMTS to GSM (inter-RAT) handoverand troubleshooting,11-18
PS UMTS to GSM (inter-RAT) Cell ChangeOrder and troubleshooting,11-33
Serving HS-DSCH Cell Change,11-39
Soft/Softer handover and troubleshooting,11-3
Cell re-selection failures,8-9
Connected mode,4-38
CS IRAT HO success rate (UMTS -> GSM),7-7
CS Voice GSM to UMTS (inter-RAT) handoverprocedure,11-27
CS Voice IRAT handover proceduretroubleshooting,11-25
CS Voice relocation preparation proceduretroubleshooting,11-23
CS Voice UMTS to GSM (inter-RAT) handoverprocedure,11-19
................................................................................................
D Definition of optimization,1-2
Determination of accessibility problem,8-6
Dropped calls analysis,9-2
Dropped RAB analysis due to congestion,9-9
Dynamic bearer control failures,8-30
................................................................................................
H Handover procedure troubleshooting,11-32
................................................................................................
I Idle mode,4-38
Inter-frequency hard handover procedure,11-45
Inter-system directed retry troubleshooting,11-60
Interfaces
Iu-cs, 4-56
Introduction to RRC connection establishment,8-16
Iu-cs interface,4-56
................................................................................................
K Key performance indicators for UTRAN
CS IRAT HO success rate (UMTS -> GSM),7-7
KPI, 2-2
................................................................................................
L Logical channels,4-24
................................................................................................
M MAC, 4-31
Medium Access Control,4-27
................................................................................................
N Network layer,4-35....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007
Alcatel-Lucent - ProprietarySee notice on first page
IN-1
No answer from UE,8-33
No Node B resources available,11-12, 11-53
No transport resources available,11-13, 11-54
No UE answer,11-14
Not optimizing
Consequences,1-4
................................................................................................
O Optimization costs,1-2
Optimization requirements,1-2
................................................................................................
P Paging failures,8-24
Physical channels,4-13
PS UMTS to GSM (inter-RAT) Cell Change Orderprocedure,11-34
PS UMTS to GSM (inter-RAT) Cell Change Ordertroubleshooting,11-37
................................................................................................
Q Quality KPIs, 10-2
................................................................................................
R RAB establishment,8-27
RACH access procedure failures,8-11
Radio bearer establishment failures,8-32
Radio link failures analysis due to synchronizationissues,9-6
Radio link setup analysis,8-21
Reasons for optimization,1-4
Relocation resource allocation proceduretroubleshooting,11-30
RLC, 4-31
RRC, 4-38
RRC connection setup failure,8-23
................................................................................................
S Serving HS-DSCH Cell Change procedure,11-40
Serving HS-DSCH Cell Change troubleshooting,11-43
Soft handover troubleshooting,11-9
Soft/softer handover procedure,11-4
................................................................................................
T Throughput optimization,12-2
Transport channels,4-20
................................................................................................
U UE reject,11-15, 11-55
Unlisted Set Cells,11-16
Index
...................................................................................................................................................................................................................................
IN-2 Alcatel-Lucent - ProprietarySee notice on first page
401-382-810R04.03Issue 1, August 2007