UMTS Optimization

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


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


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


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


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,


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


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

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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007,


xiii

http://www.lucent-info.com/comments/enus/

http://www.lucent-info.com/comments/enus/

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


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


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


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.


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


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


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?


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


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


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


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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


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.


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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


2-7

OCNS can be useful to detect Cell breathing.

Information sources and tools OMC-UPS tools

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


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

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


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


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


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


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.


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



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


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.


There are several ways in which pilot pollution problems show themselves in thenetwork.

These include:

• Dropped calls

• Handover failures


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


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


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.


There are several ways in which near-far problems show themselves in the network.

These include:

• High interference

• Node B always transmits on full power despite satisfying block error rates

• User equipment always transmits on full power despite satisfying block error rates.

Information sources

The following information sources are used to detect near-far problems:

• Drive test



Possible solutions

Possible solutions for near-far problems are:

• Changing power control parameters.


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


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.


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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.


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


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.


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




...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


4-1

Iur interface 4-54

Iu-cs interface 4-56

UTRAN Signaling Overview

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


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


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

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


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


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

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


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


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

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


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


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


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


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.


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


4-11

Air interface channels

Overview...................................................................................................................................................................................................................................

Purpose


• to describe the channels of the air interface

• to map these channels to their layer of the air interface

• to explain the function of the channels.

Contents

Physical channels 4-13

Transport channels 4-20

Logical channels 4-24

UTRAN Signaling

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


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


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



Fixedchannels

UTRAN Signaling Physical channels

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


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.


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


4-15


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.


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


401-382-810R04.03Issue 1, August 2007


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.


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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.


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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



Fixedchannels

UTRAN Signaling Transport channels

....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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.


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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



Fixedchannels

UTRAN Signaling Logical channels

....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


4-25

Air interface protocols

Overview...................................................................................................................................................................................................................................

Purpose


• to describe the protocols of the air interface

• to map these protocols to their layer and sublayer of the protocol stack

• to explain the function of the air interface protocols.

Contents

Medium Access Control 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

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


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.



RLC RLCRLC

RLC RLCRLC

RLCRLC

BMC

PDCP DCP

controlcontrol

GC Nt DC


cont

rol

Layer 3

L2/PDCP

L2/BMC

L2/RLC




UTRAN Signaling

...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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.


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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.



RLC RLCRLC

RLC RLCRLC

RLCRLC

BMC

PDCP DCP

controlcontrol

GC Nt DC


cont

rol

Layer 3

L2/PDCP

L2/BMC

L2/RLC




UTRAN Signaling

...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


401-382-810R04.03Issue 1, August 2007

Unacknowledged mode services:


• 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


• 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


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.



RLC RLCRLC

RLC RLCRLC

RLCRLC

BMC

PDCP DCP

controlcontrol

GC Nt DC


cont

rol

Layer 3

L2/PDCP

L2/BMC

L2/RLC




UTRAN Signaling

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


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.



RLC RLCRLC

RLC RLCRLC

RLCRLC

BMC

PDCP DCP

controlcontrol

GC Nt DC


cont

rol

Layer 3

L2/PDCP

L2/BMC

L2/RLC




UTRAN Signaling

...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


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

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


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


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

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


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


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)


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


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.



RLCRLC

RLCRLC

control Radio Resource Control(RRC)control

cont

rol

cont

rol

New RLCentities

MACparameters

L1Parameters


SignalingRadioBearers


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


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.


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


401-382-810R04.03Issue 1, August 2007



RLCRLC

RLCRLC

control Radio Resource Control(RRC)

cont

rol

New RLCentity

MACparameters

L1Parameters


New RadioBearer

RLC

PDCP DCP

BMC


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


4-47

UTRAN protocols

Overview...................................................................................................................................................................................................................................

Purpose


• to describe the protocol structure of the UTRAN interfaces

• to map the UTRAN protocols to their specific layers on the Control Plane and 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

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


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


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

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


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


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

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


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


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

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


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


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

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


401-382-810R04.03Issue 1, August 2007

UTRAN Signaling Iu-cs interface

....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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

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


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


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


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


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


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

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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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)

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


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.


• 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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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:


• Drive tests


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


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.


• 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

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


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


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


• 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

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


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


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

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


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


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

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


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


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

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


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


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

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


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


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


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

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


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


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


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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


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.


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


– .weight specifies weighting between strongest link and remaining active linksfor computing the quality of the own system (UMTS system).


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


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


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


– .eCN0Threshold: -13 dB


• MAHO Trigger Condition:Parameter:umts2GsmQTriggerMAHO


– .eCN0Threshold: -13.0 dB


– .weight: 1.0


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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


7-13


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

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


401-382-810R04.03Issue 1, August 2007



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”:


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


7-15



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.


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


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


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


8-1

No answer from UE 8-33

Call availability optimization and troubleshooting Overview

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


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


Determination of accessibility problem 8-6

Call availability optimization and troubleshooting

...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


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.


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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

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


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


• VS.RACHTransBlock.Bad

• VS.RACHTransBlock.Good


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


8-13

• VS.ChannelOccupRateRACH

• VS.RACHcongestion

• RACH transport block good CRC rate

• RRC.FailConnEstab.SetupIncomplete

• RRC.FailConnEstab.sum:

• RRC.FailConnEstab.CAC

• RRC.FailConnEstab.RLSetupFailure


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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:


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


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


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


• RRC.FailConnEstab.SetupIncomplete



• 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

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


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



• VS.RF.ForwrdTrafficChn.Overload

• VS.RF.ChanElementUsage.Total

• VS.ChanCodeUtil

• VS.RF.ChanElementUsage.Dedicated


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


• 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


Call availability optimization and troubleshooting Radio link setup analysis

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


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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.


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


401-382-810R04.03Issue 1, August 2007

Related PMs / KPIs


• VS.MM.NumPageAttDiscard

• VS.MM.PagAttDiscard.ProcessorLoad

• VS.ChannelOccupRatePCH

• VS.MM.RRCConnDrop.UTRANPagingFailure.

Note: Paging related PMs and KPIs are typically derived from the core network.

Call availability optimization and troubleshooting Paging failures

....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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:


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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.



• 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


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.


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


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


• 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


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.


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


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.


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


• RAB.FailEstabCSNoQueuing.T3exp

• RAB.FailEstabPSNoQueuing.T3exp

• RAB.FailEstabPSNoQueuing.T3exp.DCH_DCH

• RAB.FailEstabPSNoQueuing.T3exp.DCH_HSDSCH

• RAB.FailEstabPSNoQueuing.T3exp.EDCH_HSDSCH


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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

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


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


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


• 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


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


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>


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


• 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


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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


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

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


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


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


10-3



• 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

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


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


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



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

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


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


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


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


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


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

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


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






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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


11-9

Related PMs / KPIs


• SHO.AttRLAddUESide

• SHO.SuccRLAddUESide

• SHO.FailRLAddUESide.InvalidConfig

• SHO.FailRLAddUESide.IncompSimultReconf

• SHO.FailRLAddUESide.ProtErr

• SHO.FailRLAddUESide.ConfigUnsupport

• SHO.FailRLAddUESide.NoReply

• SHO.AttRLDelUESide

• SHO.SuccRLDelUESide

• SHO.AttRLAddUESide.IntraRNC.CSV

• SHO.AttRLAddUESide.IntraRNC.PSLowData

• SHO.AttRLAddUESide.IntraRNC.PSHighData

• SHO.AttRLAddUESide.IntraRNC.Signalling

• SHO.AttRLAddUESide.IntraRNC.CSD

• SHO.AttRLAddUESide.IntraRNC.CSDandPS

• SHO.AttRLAddUESide.IntraRNC.CSVandPS

• SHO.FailRLAddUESide.IntraRNC.CSV

• SHO.FailRLAddUESide.IntraRNC.PSLowData

• SHO.FailRLAddUESide.IntraRNC.PSHighData

• SHO.FailRLAddUESide.IntraRNC.Signalling

• SHO.FailRLAddUESide.IntraRNC.CSD

• SHO.FailRLAddUESide.IntraRNC.CSDandPS

• SHO.FailRLAddUESide.IntraRNC.CSVandPS

• SHO.AttRLAddUESide.InterRNC.CSV

• SHO.AttRLAddUESide.InterRNC.PSLowData

• SHO.AttRLAddUESide.InterRNC.PSHighData

• SHO.AttRLAddUESide.InterRNC.Signalling

• SHO.AttRLAddUESide.InterRNC.CSD

• SHO.AttRLAddUESide.InterRNC.CSDandPS

• SHO.AttRLAddUESide.InterRNC.CSVandPS

• SHO.FailRLAddUESide.InterRNC.CSV

• SHO.FailRLAddUESide.InterRNC.PSLowData

• SHO.FailRLAddUESide.InterRNC.PSHighData

Call mobility optimization and troubleshooting Soft handover troubleshooting

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


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


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


• RLM.FailRLSetupIub.NodeBRes.<service type>

• VS.RLM.MeanActiveRL

• VS.RLM.MaxActiveRL

• Successful Active Set Update Addition Rate


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


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


• RLM.FailRLSetupIub.TransRes.<CSV/CSD/PSD>


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


• SHO.FailRLAddUESide.NoReply


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


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


• SHO.FailRLAddUESide.InvalidConfig

• SHO.FailRLAddUESide.IncompSimultReconf

• SHO.FailRLAddUESide.ProtErr

• SHO.FailRLAddUESide.ConfigUnsupport


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


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


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


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


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:


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


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


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


• IRATHO.FailOutCS.PhyChnFail

• IRATHO.FailOutCS.ConfUnaccept

• IRATHO.FailOutCS.ProtErr


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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

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


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


• 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


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


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


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


401-382-810R04.03Issue 1, August 2007

Related PMs/KPIs



• IRATHO.FailIncCS.HoNotEnabled

Call mobility optimization and troubleshooting Relocation resource allocation procedure troubleshooting

....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


• 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



• IRATHO.FailIncCS.T_hoToUtranComplete

• IRATHO.FailIncCS.RelocCancel


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


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


• 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

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


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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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:


• 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


• 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

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


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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


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


• HS-DSCH Cell Change Success Rate

Call mobility optimization and troubleshooting Serving HS-DSCH Cell Change procedure

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


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


• 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


• VS.AttServCellChangeHSDSCH

• VS.FailServCellChangeHSDSCH.sum

• VS.FailServCellChangeHSDSCH.TransChnReconfigFail

• VS.FailServCellChangeHSDSCH.TransChnReconfigTout

• Successful Serving HS-DSCH Cell Changes


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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



UE reject 11-55


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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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

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


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)


....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


401-382-810R04.03Issue 1, August 2007


15. ALCAP Iur Transport Bearer Release


4. ALCAP Iub Transport Bearer Setup

8. UE Detected

9. Physical Channel Reconfiguration Complete


13. ALCAP Iub Transport Bearer Release

UE SRNC

Measurements and Handover Decision

Node B newNode B old

1. Radio Link

7. Physical Channel Reconfiguration


DRNC newDRNC old

Setup Request2. Radio Link Setup Request

5. Radio Link Setup

6. ALCAP IurTransport Bearer Setup



....................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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


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

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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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.


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


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


• 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


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


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


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


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.


...................................................................................................................................................................................................................................401-382-810R04.03Issue 1, August 2007


11-57

Inter-system directed retry signaling flow


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


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

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


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


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


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


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


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

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


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



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


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

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


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


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


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

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


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


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

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


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


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

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


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


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


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


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

UMTS Optimization

Documents

Transcript of UMTS Optimization