Umts Optimization Lucent

242
Instructor Guide UMTS UTRAN Optimization UM4801-IG.en.A4 Issue a October 2005 Lucent Technologies - Proprietary This document contains proprietary information of Lucent Technologies and is not to be disclosed or used except in accordance with applicable agreements. Copyright © 2005 Lucent Technologies Unpublished and Not for Publication All Rights Reserved See notice on first age

Transcript of Umts Optimization Lucent

Page 1: Umts Optimization Lucent

Instructor Guide

UMTS UTRAN Optimization

UM4801-IG.en.A4Issue a

October 2005

Lucent Technologies - ProprietaryThis document contains proprietary information of Lucent Technologies and

is not to be disclosed or used except in accordance with applicable agreements.

Copyright © 2005 Lucent TechnologiesUnpublished and Not for Publication

All Rights Reserved

See notice on first age

Page 2: Umts Optimization Lucent

This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced,distributed, or altered in any fashion by any entity (either internal or external to Lucent Technologies), except in accordance with applicableagreements, contracts or licensing, without the express written consent of Lucent Technologies and the business management owner of thematerial.

Trademarks

All trademarks and service marks specified herein are owned by their respective companies.

See notice on first age

Lucent Technologies - ProprietarySee notice on first page

Page 3: Umts Optimization Lucent

Contents

About this information product

Objectives........................................................................................................................................................................................................xiiixiii

Reason for reissue.....................................................................................................................................................................................xiiixiii

How to use this information product.............................................................................................................................................xiiixiii

Conventions used.......................................................................................................................................................................................xiiixiii

Related documentation............................................................................................................................................................................xiiixiii

Related training............................................................................................................................................................................................xivxiv

How to comment........................................................................................................................................................................................xivxiv

Course plan prologue

Course plan prologue.................................................................................................................................................................................xvxv

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

Exercises..........................................................................................................................................................................................................1-81-8

2 Information sources and tools

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

Gathering information

Overview .........................................................................................................................................................................................................2-22-2

Key Performance Indicators................................................................................................................................................................2-32-3

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

iii

Page 4: Umts Optimization Lucent

Drive test .........................................................................................................................................................................................................2-42-4

Customer complaints................................................................................................................................................................................2-62-6

OMC-U tools ................................................................................................................................................................................................2-72-7

Analyzing information

Overview .........................................................................................................................................................................................................2-82-8

Data analysis software............................................................................................................................................................................2-92-9

Exercises ......................................................................................................................................................................................................2-122-12

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

Exercises.......................................................................................................................................................................................................3-133-13

4 UTRAN Signaling

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

Protocol architecture of the air interface

Overview .........................................................................................................................................................................................................4-24-2

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

Radio interface protocol architecture.............................................................................................................................................4-54-5

Service access points...............................................................................................................................................................................4-74-7

Air interface protocols

Overview .......................................................................................................................................................................................................4-104-10

RRC Connection and Signaling Connection..........................................................................................................................4-114-11

Signaling radio bearers........................................................................................................................................................................4-124-12

Contents

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

iv Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 5: Umts Optimization Lucent

Radio bearer establishment...............................................................................................................................................................4-154-15

Exercises ......................................................................................................................................................................................................4-184-18

Part II: Optimization process

5 Optimization process

Overview .........................................................................................................................................................................................................5-15-1

Lifecycle ..........................................................................................................................................................................................................5-25-2

Optimization process phases...............................................................................................................................................................5-45-4

Drive test optimization process.........................................................................................................................................................5-75-7

Planning and preparation (site readiness)................................................................................................................................... 5-95-9

Optimization planning..........................................................................................................................................................................5-115-11

Perform cluster optimization............................................................................................................................................................5-135-13

Perform system verification..............................................................................................................................................................5-165-16

Information gathering...........................................................................................................................................................................5-185-18

Information analysis..............................................................................................................................................................................5-195-19

Exercises.......................................................................................................................................................................................................5-205-20

Part III: Optimization and troubleshooting

6 Call availability and optimization

Overview .........................................................................................................................................................................................................6-16-1

Call availability

Overview .........................................................................................................................................................................................................6-36-3

Call availability ...........................................................................................................................................................................................6-46-4

Determination of accessibility problem........................................................................................................................................ 6-66-6

Network level accessibility

Overview .........................................................................................................................................................................................................6-76-7

Introduction ....................................................................................................................................................................................................6-86-8

Cell Search & RRC SIB decoding..................................................................................................................................................6-96-9

Cell selection..............................................................................................................................................................................................6-106-10

Cell re-selection failures.....................................................................................................................................................................6-126-12

Contents

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

v

Page 6: Umts Optimization Lucent

RACH access procedure failures...................................................................................................................................................6-146-14

RRC connection establishment analysis

Overview .......................................................................................................................................................................................................6-176-17

Introduction to RRC connection establishment....................................................................................................................6-186-18

Call admission control failures.......................................................................................................................................................6-206-20

Radio link setup failure.......................................................................................................................................................................6-216-21

RRC connection setup failure..........................................................................................................................................................6-236-23

Paging failures...........................................................................................................................................................................................6-266-26

RAB establishment analysis

Overview .......................................................................................................................................................................................................6-286-28

Introduction .................................................................................................................................................................................................6-296-29

Dynamic bearer control failures.....................................................................................................................................................6-326-32

Radio link reconfiguration failures...............................................................................................................................................6-336-33

Radio bearer establishment failures.............................................................................................................................................6-346-34

No answer from UE..............................................................................................................................................................................6-356-35

Code starvation.........................................................................................................................................................................................6-366-36

Exercises ......................................................................................................................................................................................................6-376-37

7 Call reliability

Overview .........................................................................................................................................................................................................7-17-1

Dropped calls analysis..........................................................................................................................................................................7-27-2

Radio link failures analysis due to synchronization issues..............................................................................................7-57-5

RLF and Radio Link Restore in the Uplink..............................................................................................................................7-67-6

RLF and Radio Link Restore in the Downlink.......................................................................................................................7-87-8

RLF failure: Poor RF coverage.........................................................................................................................................................7-97-9

RLF failure: Poor PSC plan.............................................................................................................................................................7-107-10

RLF failure: Pilot pollution and Around-the-Corner problem.....................................................................................7-117-11

RLF failure: Poorly defined neighbor list................................................................................................................................ 7-127-12

RLF failure: Improved Aggregate Overload Control........................................................................................................7-137-13

Contents

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

vi Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 7: Umts Optimization Lucent

Failures on RLC.......................................................................................................................................................................................7-147-14

Network interface outages.................................................................................................................................................................7-167-16

Network level retainability KPIs...................................................................................................................................................7-187-18

Exercises.......................................................................................................................................................................................................7-197-19

8 Call quality and optimization

Overview .........................................................................................................................................................................................................8-18-1

Network level quality KPIs ...............................................................................................................................................................8-28-2

Uplink Block Error Rate (BLER)....................................................................................................................................................8-48-4

Downlink Block Error Rate (BLER).............................................................................................................................................8-68-6

Quality of Service (QoS).......................................................................................................................................................................8-88-8

Exercises.......................................................................................................................................................................................................8-118-11

9 Call mobility and optimization

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

Soft/Softer Handover

Overview .........................................................................................................................................................................................................9-39-3

Soft/Softer Handover failure classification................................................................................................................................ 9-49-4

Soft/softer handover failures in non-CELL DCH state......................................................................................................9-59-5

Soft/softer handover failures in CELL DCH state................................................................................................................9-89-8

Poor RF conditions.................................................................................................................................................................................9-109-10

Node B resource dry-up......................................................................................................................................................................9-119-11

Transport resources dry-up................................................................................................................................................................9-129-12

No UE answer...........................................................................................................................................................................................9-139-13

UE reject .......................................................................................................................................................................................................9-149-14

Hardware or link outage.....................................................................................................................................................................9-169-16

Incorrect translation settings -Overview................................................................................................................................... 9-179-17

Incorrect translations settings - measurement and reporting........................................................................................9-189-18

Incorrect translation settings - Neighbor List Selection Algorithm.........................................................................9-209-20

Incorrect translation settings - Active Set Update procedure.......................................................................................9-219-21

Contents

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

vii

Page 8: Umts Optimization Lucent

UMTS to GSM handover

Overview .......................................................................................................................................................................................................9-229-22

Inter-system handover failures - overview..............................................................................................................................9-239-23

Relocation failures..................................................................................................................................................................................9-259-25

Handover procedure failures............................................................................................................................................................9-269-26

Release procedure failures.................................................................................................................................................................9-309-30

Location and Routing area update

Overview .......................................................................................................................................................................................................9-319-31

Location update failure........................................................................................................................................................................9-329-32

Routing update failure..........................................................................................................................................................................9-349-34

Exercises ......................................................................................................................................................................................................9-369-36

10 UTRAN end-to-end key performance indicators

Overview .......................................................................................................................................................................................................10-110-1

KPIs for the Circuit Switched domain

Overview .......................................................................................................................................................................................................10-310-3

KPI for Mobile-originated end-to-end call setup in the Circuit Switched domain........................................10-410-4

KPI for Mobile-terminated end-to-end call setup in the Circuit Switched domain.......................................10-910-9

KPI for end-to-end call drops in the Circuit Switched domain...............................................................................10-1410-14

KPIs for the Packet Switched domain

Overview ....................................................................................................................................................................................................10-1810-18

KPI for Mobile-originated end-to-end call setup in the Packet Switched domain......................................10-1910-19

KPI for Mobile-terminated end-to-end call setup in the Packet Switched domain.....................................10-2410-24

KPI for end-to-end call drops in the Packet Switched domain...............................................................................10-3010-30

KPIs for Quality of Service monitoring

Overview ....................................................................................................................................................................................................10-3510-35

KPIs for Quality of Service monitoring in the CS domain.......................................................................................10-3610-36

KPIs for Quality of Service monitoring in the PS domain........................................................................................10-3810-38

Contents

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

viii Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 9: Umts Optimization Lucent

Exercises....................................................................................................................................................................................................10-4010-40

Index

Contents

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

ix

Page 10: Umts Optimization Lucent
Page 11: Umts Optimization Lucent

List of figures

Part III: Optimization and troubleshooting

10 UTRAN end-to-end key performance indicators

10-1 RRC connection establishment..................................................................................................................................... 10-510-5

10-2 MM and authentication......................................................................................................................................................10-510-5

10-3 RAB assignment and call connect..............................................................................................................................10-610-6

10-4 RRC connection establishment.................................................................................................................................. 10-1010-10

10-5 MM and authentication...................................................................................................................................................10-1010-10

10-6 RAB assignment and call connect...........................................................................................................................10-1110-11

10-7 Normal CS E2E call release, mobile-originated and mobile-terminated.........................................10-1510-15

10-8 CS E2E uplink radio link failure detection........................................................................................................10-1610-16

10-9 CS E2E downlink radio link failure detection.................................................................................................10-1610-16

10-10 RRC connection establishment.................................................................................................................................. 10-2010-20

10-11 GMM attach...........................................................................................................................................................................10-2010-20

10-12 RAB assignement and PDP context activation................................................................................................10-2110-21

10-13 Paging and RRC connection establishment........................................................................................................10-2510-25

10-14 GMM attach...........................................................................................................................................................................10-2510-25

10-15 RAB assignment and PDP context activation...................................................................................................10-2610-26

10-16 Normal PS E2E call release, mobile-originated and mobile-terminated.........................................10-3210-32

10-17 PS E2E uplink radio link failure detection........................................................................................................10-3210-32

10-18 PS E2E downlink radio link failure detection..................................................................................................10-3310-33

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

xi

Page 12: Umts Optimization Lucent
Page 13: Umts Optimization Lucent

About this information product

Objectives

This document is designed as a reference for the participants of the training courseUM4801.

This course is designed to enable the student to:

• Identify sources of performance data (measurement reports, customer complaints)

• Describe drive testing equipment, methods and tools

• Interpret performance data and traffic measurements to locate trouble spots

• Provide solutions for improving the performance

• Evaluate the effectiveness of counter measures.

Reason for reissue

This is the first release of this reference material.

How to use this information product

Use this course documentation in combination with the latest user documentation.

Conventions used

Acronyms are explained on their first appearance in the text.

Related documentation

The following related documents are available:

• UMTS Performance measurements definitions manual,401-382-803R0301

• Flexent® UMTS Radio Network Controller, Operations, Administration andMaintenance,401-382-360R0301

• Flexent®UMTS Macrocell Indoor, Operation, Administration and Maintenance for+24 V, 401-382-462R0301

• Flexent® UMTS Modular Cell Outdoor, Operation, Administration andMaintenance for +24 V,401-382-760R0301

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

UM4801-IG.en.A4Issue a, October 2005,

Lucent Technologies - ProprietarySee notice on first page

xiii

Page 14: Umts Optimization Lucent

• Flexent® UMTS Macrocell Compact, Operation, Administration and Maintenancefor +24 V, 401-382-961R0301

• Flexent® UMTS Microcell (Type M), Operation, Administration and Maintenancefor +24 V, 401-382-966R0301.

Related training

The following related courses are available:

• UM1001 UMTS System Introduction

• UM1911 UMTS Hardware Overview

• UM4304 UTRAN Signaling

• UM4305 UTRAN Processes and Parameter Settings

• UM4301 UTRAN RF Cellular Engineering.

How to comment

To comment on this information product, go to theOnline Comment Form(http://www.lucent-info.com/comments/enus/) or email your comments to theComments Hotline ([email protected]).

About this information product

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

xiv Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

,

Page 15: Umts Optimization Lucent

Course plan prologue

Course plan prologue.................................................................................................................................................................................................................................

Intended audience

This course is designed for personnel involved in the performance evaluation and theoptimization of UMTS Terrestrial Radio Access Networks (UTRAN).

Delivery method

This course is to be delivered as a class-room based instructor-led course.

The classroom

The classroom should contain:

• Tables and chairs for up to 12 students and an instructor

• LCD projector and screen forMicrosoft PowerPoint™ presentation materials

• Flipchart with markers

• Whiteboard with dry erase markers and eraser, or a Chalkboard with chalk

• Bulletin board and thumb tacks

• Power cords for auxiliary power

• Remote maintenance tools

• Personal computers, or workstations, for each student (maximum of two studentsper workstation).

Course duration

The course takes five days.

Materials

The following materials are required for this class:

• One paper-based instructor guide

• One PowerPoint presentation

• One paper-based student guide for each student.

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

UM4801-IG.en.A4Issue a, October 2005,

Lucent Technologies - ProprietarySee notice on first page

xv

Page 16: Umts Optimization Lucent

Training environment

Each day, the instructor should be mindful of the appearance of the room. At the endof the day, the instructor should remind students to discard any trash.

On the last day of class, the instructor should return the learning environment to itsoriginal orderliness, if possible.

Course plan prologue Course plan prologue

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

xvi Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

,

Page 17: Umts Optimization Lucent

Part I: Optimization concepts

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

Objectives

After completing the following lessons, you will be able to:

• Define the scope of UTRAN Optimization

• Describe what KPIs are

• Describe the most common Optimization problems and their solutions

• Place the UTRAN protocols and channels in their architectural context

• Place the UTRAN protocols and channels in a call flow context.

Contents

Lesson 1, Introduction to optimization 1-1

Lesson 2, Information sources and tools 2-1

Lesson 3, Common optimization problems and their solutions 3-1

Lesson 4, UTRAN Signaling 4-1

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

I-1

Page 18: Umts Optimization Lucent
Page 19: Umts Optimization Lucent

1 1Introduction to optimization

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

Objectives

After completing the following lesson, you will be able to:

• Describe what optimization is

• Explain why optimization is performed

• Explain when optimization must be performed.

Contents

What is optimization? 1-2

Why optimize a network ? 1-4

When to optimize a network ? 1-6

Exercises 1-8

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

1-1

Page 20: Umts Optimization Lucent

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.

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 different

Introduction to optimization

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

1-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 21: Umts Optimization Lucent

requirements. When an engineer makes a choice to implement 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?

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

1-3

Page 22: Umts Optimization Lucent

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 changingto other operators

• Operational and maintenance costs.

Subscribers

In a network that is not optimized, subscribers can experience:

• Blocked calls

• Dropped calls

• Smaller RF coverage area

Introduction to optimization

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

1-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 23: Umts Optimization Lucent

• Lower voice quality

• Lower data rates.

Blocked calls are a direct loss of revenue for an operator. Poor network quality canbe a reason for existing subscribers changing to another operator and for potentialcustomers subscribing 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 ?

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

1-5

Page 24: Umts Optimization Lucent

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.

Optimization is always needed because there are always:

• Deviations from (planning) assumptions

• Changes in subscriber behavior

Network design

In serviceoptimization

Optimization Planning

Live network

Implementation

Network design& implementation

Y

N Acceptancecriteria met?

Introduction to optimization

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

1-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 25: Umts Optimization Lucent

• Changes in operator requirements

• Changes in environment.

Introduction to optimization When to optimize a network ?

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

1-7

Page 26: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercise

1 Which of the following statements concerning optimization is most accurate?

a Optimization is an important part of the Fault Management process.

b The starting point for optimization is an error-free network.

c Optimization is performed prior to a network launch.

b

Introduction to optimization

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

1-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 27: Umts Optimization Lucent

2 2Information sources and tools

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

Objectives

After completing the following lesson, you will be able to:

• Describe the different information sources that can be used to detect optimizationproblems

• Identify the tools and methods to gather optimization information

• Describe the role of tools to analyze information.

Contents

Gathering information 2-2

Key Performance Indicators 2-3

Drive test 2-4

Customer complaints 2-6

OMC-U tools 2-7

Analyzing information 2-8

Data analysis software 2-9

Exercises 2-12

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

2-1

Page 28: Umts Optimization Lucent

Gathering information

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

Objectives

After completing this section, you will be able to:

• Describe the different tools and information sources that can be used to detectoptimization problems.

• Identify the tools and methods to gather optimization information.

Available information sources

There are several tools and information sources that are used to gather information thatis used as input for optimization.

These include:

• Key Performance Indicators.

• Drive testing

• Customer complaints

• OMC-U tools

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

Drive test 2-4

Customer complaints 2-6

OMC-U tools 2-7

Information sources and tools

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

2-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 29: Umts Optimization Lucent

Key Performance Indicators.................................................................................................................................................................................................................................

Use of KPIs

Key Performance Indicators (KPIs) are calculated using measurements that aregathered by the OMC-U. The KPIs are used to determine if the network complies tothe levels of performance that are needed.

Key Performance Indicators play an important role in detecting (optimization)problems. Changes in values of the key performance indicators, especially reachingthresholds, are often the first indication of an optimization problem.

A KPI value can change suddenly, or gradually, but both types of change can be anindication that optimization is needed.

Available KPIs

For detailed information on all the available KPIs, refer toUMTS Performancemeasurements definitions manual,401-382-803R0301.

KPIs that can be an indication of a performance problem that needs optimization are:

• Handover failure rates

• Channel occupancy rates

• Dropped RRC connections rate

• RAB failure rates

• Radio link dropping rates.

Detected problems

KPIs can be useful in detecting all the problems that were mentioned, such as:

• RF coverage gaps

• Cell breathing

• Pilot pollution

• Near-far problems

• Around-the-corner problems

• Hand over problems (failures or ping-ponging)

• Missing neighbor cells in the neighboring cell list.

Information sources and tools

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

2-3

Page 30: Umts Optimization Lucent

Drive test.................................................................................................................................................................................................................................

Purpose

Drive tests are performed to measure:

• RF spectrum coverage and interference

• UTRAN parameters (mobile measurements, protocol messages)

• Network quality (call completion, hand over, data rates, voice quality).

When to perform

Drive tests are performed during network deployment and in a live network. 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 tests, neighboring cells must be operational, so cell selection, interferencemeasurements and handovers can be performed and tested.

After implementing a solution to correct an (optimization) problem, a drive test can beperformed to check if the problem has been solved.

Regular drive tests are also a method for preventive maintenance to detect areas whereservices are degrading.

Components

Components of a typical drive test system (picture provided courtesy of AgilentTechnologies):

Information sources and tools

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

2-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 31: Umts Optimization Lucent

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.

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

2-5

Page 32: Umts Optimization Lucent

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 detectall optimization problems.

Information sources and tools

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

2-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 33: Umts Optimization Lucent

OMC-U tools.................................................................................................................................................................................................................................

OMC-U tools

The OMC-U 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 an RF call trace is activated for a UE, information about calls established bythat UE is collected, as long as the UE is connected to the tracing RNC. Theinformation is composed of measurements performed at the UE, the NodeB and theRNC. All measurements are stored at the RNC until the OMC-U requests a transfer tothe OMC-U.

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 simulates traffic on thedownlink. OCNS is activated on the OMC-U and generates downlink interference tosimulate traffic.

The OMC-U 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 optimization problems.

OCNS can be useful to detect Cell breathing.

Information sources and tools

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

2-7

Page 34: Umts Optimization Lucent

Analyzing information

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

Objectives

This section provides information about tools that can be used during optimization.

After completing this section, you will be able to:

• Describe the role of tools to analyze information.

Contents

Data analysis software 2-9

Information sources and tools

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

2-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 35: Umts Optimization Lucent

Data analysis software.................................................................................................................................................................................................................................

Need for data analysis software

Data analysis software is needed to process data because a large volume of informationis collected. The software helps to sort out the information, present it to an engineerand 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.

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.

Information sources and tools

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

2-9

Page 36: Umts Optimization Lucent

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 tools is drive test data. But also other sourcesof input can be used.

Besides commercially available software tools, also many proprietary tools areavailable.

Before optimization Optimizated design

Information sources and tools Data analysis software

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

2-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 37: Umts Optimization Lucent

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

2-11

Page 38: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

1 Which of the following RF problems can OCNS help to detect?

a Around-the-corner problem

b Cell breathing

c Missing neighbors

d Pilot pollution

b

Information sources and tools

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

2-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 39: Umts Optimization Lucent

3 3Common optimization problemsand their solutions

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

Objectives

This lesson describes typical problem areas that can be addressed by optimization andprovides possible solutions for the problem.

After completing this lesson, you will be able to:

• Describe and define the problems

• Describe how the problem shows itself in a network

• Explain the consequences for the network and the users

• Suggest possible solutions.

Since optimization usually is a trade-off, keep in mind that the possible solutions 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

Exercises 3-13

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-1

Page 40: Umts Optimization Lucent

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 theabove-mentioned coverage conditions. Therefore, the Ec/Io ratio and the Ec signalstrength (connected to the pathloss) of the Primary Common Pilot Channel are used asaccurate measures for 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.Increasing RF coverage must not mean other requirements such as interference levelsare compromised.

If RF coverage gaps can not be closed, it may be possible to move an RF coveragegap from an area with high traffic volumes to an area with low traffic volumes. Thisdoes not solve the RF coverage problem itself, but lowers the impact of a gap.

Detection of the problem

There are several ways in which RF coverage problems show themselves in thenetwork.

These include:

• Dropped calls

• Failed handovers.

Information sources

The following information sources are used to detect RF coverage problems:

• Drive test

• Key performance indicators

• Customer complaints.

Common optimization problems and their solutions

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

3-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 41: Umts Optimization Lucent

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-3

Page 42: Umts Optimization Lucent

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, 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 cell coverage.This can result in neighboring cells not being used because the mobiles stay connectedto 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-U to generate downlink interference.On the uplink, an attenuator attached to the user equipment simulates the loading.

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.

Cell at 30 % capacity

Cell at 60 % capacity

Common optimization problems and their solutions

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

3-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 43: Umts Optimization Lucent

Detection of the problem

There are several ways in which cell breathing problems are manifest in the network.

These include:

• Dropped calls

• Poor quality, especially at cell edges (during high traffic loads)

• Appearance of RF coverage gaps (during high traffic loads)

• Failed handovers

• No handover to neighboring cells (during low traffic loads)

• Excessive or unexpected handovers (during high traffic loads)

• Pilot pollution (during low traffic loads).

Information sources

The following information sources are used to detect cell breathing problems:

• Drive tests

• Key performance indicators

• Customer complaints.

Possible solutions

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-5

Page 44: Umts Optimization Lucent

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 of interference is multipath reception. Each received pilot isaccompanied by 2-3 strong multipaths. The user equipment uses a rake receiver toexploit multipath reception. Since the rake receiver has a limited number of fingers,unused multipaths act as interference. Consequently, a six-finger rake receiver is fullyoccupied when receiving three pilots (each with 2 multipaths). Any additional pilotsand multipaths are interference. Common trouble spots are bridges, upper floors inbuildings, elevated highways, street intersections, and large bodies of water.

Optimization goal

The goal is to minimize pilot pollution. Coverage of the dominant pilot must beincreased and coverage of the weaker pilots (which cause interference) must bedecreased. At the same time, continuous coverage through the soft handover must beensured.

Detection of the problem

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

These include:

• Dropped calls

• Handover failures

• Increased interference

• Decreased capacity.

Common optimization problems and their solutions

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

3-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 45: Umts Optimization Lucent

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-7

Page 46: Umts Optimization Lucent

Near-far problem.................................................................................................................................................................................................................................

Definition

Near-far problems occur when user equipment near the cell site transmits on highpower. This creates excessive interference for user equipment that is located far awayfrom the cell site.

Optimization goal

The goal of the cell site is to receive all user equipment at equal signal strengths.Therefore, power control must be tightly controlled. Fast closed loop power control isneeded to direct mobiles to power up or power down very quickly. The optimizationgoal is to ensure that all power control algorithms are working properly. Power controlparameters are tuned only when there are obvious power control failures.

Detection of the problem

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

These include:

• High interference

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

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

Information sources

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

• Drive test

• Key performance indicators

• Customer complaints.

Possible solutions

Possible solutions for near-far problems are:

• Changing power control parameters.

Common optimization problems and their solutions

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

3-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 47: Umts Optimization Lucent

Around-the-corner problem.................................................................................................................................................................................................................................

Definition

Around-the-corner problems occur when user equipment travels beyond an obstructionwhere there is significant downlink interference from a new sector with low pathloss.The downlink degrades momentarily until the handover is performed or the downlinkpower control reacts to compensate the interference.

When the user equipment goes into handover with the new cell site, fast power controlis needed to quickly reduce cell site transmit power.

The around-the-corner problem is a continual and unavoidable issue. Known troublespots are elevated highways and street intersections.

Optimization goal

The goal is to optimize the power control mechanism.

The optimization goal is similar to the near-far goals.

Detection of the problem

There are several ways in which around-the-corner problems show themselves in thenetwork.

These include:

• High interference

• Unusual handover behavior.

Information sources

The following information sources are used to detect around-the-corner problems:

• Drive tests

• Key performance indicators.

Possible solutions

Possible solutions for around-the-corner problems are:

• Changing power control parameters

• Changing handover parameters.

Common optimization problems and their solutions

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-9

Page 48: Umts Optimization Lucent

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 due tonon-contiguous UMTS coverage or pilot pollution lead to excessive handover activity.

Optimization goal

The goal is to optimize handover performance by careful selection of thresholds andtimers.

Handovers require signaling resources, and increase downlink interference, soexcessive handover activity must be minimized. Time delays due to resource allocation(channel units, transmission links to RNC, OVSF codes) degrade call quality andreduce the throughput of data calls.

Detection of the problem

There are several ways in which handover problems show themselves in the network.

These include:

• Dropped calls (because of handover failure)

• Ping-ponging (frequent handovers between 2 cells).

Information sources

The following information sources are used to detect handover problems:

• Drive test

• Key performance indicators.

Possible solutions

Possible solutions for handover problems are:

• Adjust handover parameters

• Change the neighboring cell list.

Common optimization problems and their solutions

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

3-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 49: Umts Optimization Lucent

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 therefore only occur to a cell that is in the neighboring celllist of a UE, so setting up proper neighboring cell lists is very important.

Missing neighbors are pilots that are not in the neighboring cell list. When pilots arereceived that are not in the neighboring cell list, these pilots cannot be added to theactive set and thus these pilots will cause interference. It is important that all receivedUMTS sectors are either eliminated or declared in the neighboring cell list.

Optimization goal

The goal is to optimize the neighboring cell lists. Received pilots must either beeliminated or declared in the neighboring cell list. They must not be ignored.

Detection of the problem

There are several ways in which missing neighbor problems show themselves in thenetwork.

These include:

• Dropped calls (when neighboring cell list is too short and UE can not handover toanother cell)

• High interference levels (UE transmits at high power levels to serving cell, becauseit can not handover to another cell)

• Unusual handover behavior (no handovers are performed from one cell to anothercell).

• Uneven traffic distribution (UEs stay with a cell and are not handed over to aneighboring cell).

Information sources

The following information sources are used to detect missing neighbors problem:

• Drive test

• Key performance indicators

• Customer complaints.

Common optimization problems and their solutions

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-11

Page 50: Umts Optimization Lucent

Possible solutions

Possible solutions for missing neighbor problems are:

• Updating the neighboring cell list to include or exclude a pilot.

• Change RF coverage, so pilots are not received anymore or pilot reception isimproved:

– Adjust power levels

– Change antenna orientation or tilt.

Common optimization problems and their solutions Missing neighbors problem

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

3-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 51: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

1 What is the consequence of cell breathing?

a Improvement of quality at cell edges

b RF coverage area shrinks with increased load

c Interference due to overlapping pilots

d UEs near the cell site transmit on high power, creating excessive interference

b

2 Which of the following may solve the around-the-corner problem?

a Change neighboring cell list

b Change P-CPICH channel power

c Change antenna orientation or tilt

d Change handover parameters

d

Common optimization problems and their solutions

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

3-13

Page 52: Umts Optimization Lucent
Page 53: Umts Optimization Lucent

4 4UTRAN Signaling

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

Objectives

After completing this lesson, you will be able to:

• Place the UTRAN protocols and channels in their architectural context

• Place the UTRAN protocols and channels in a call flow context.

Contents

Protocol architecture of the air interface 4-2

Protocols of the air interface 4-3

Radio interface protocol architecture 4-5

Service access points 4-7

Air interface protocols 4-10

RRC Connection and Signaling Connection 4-11

Signaling radio bearers 4-12

Radio bearer establishment 4-15

Exercises 4-18

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-1

Page 54: Umts Optimization Lucent

Protocol architecture of the air interface

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

Objectives

After completion of this section, you will be able to:

• describe the protocols of the air interface

• match these protocols to their correct layer in the protocol architecture of the airinterface

• explain how the layers communicate with one another by the use of channels.

Contents

Protocols of the air interface 4-3

Radio interface protocol architecture 4-5

Service access points 4-7

UTRAN Signaling

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

4-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 55: Umts Optimization Lucent

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.

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.

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-3

Page 56: Umts Optimization Lucent

Part Description

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

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

4-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 57: Umts Optimization Lucent

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.

UTRAN Signaling

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-5

Page 58: Umts Optimization Lucent

Structure of radio protocol architecture

The following figure illustrates the logical structure of the radio protocol architecture:

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

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

4-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 59: Umts Optimization Lucent

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-7

Page 60: Umts Optimization Lucent

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.

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.

Multiple transport channels can be multiplexed onto a single physical channel, orconversely, one transport channel can be transferred over multiple physical channels

PCPCH

Physical channels

DPCH

Downlink

Uplink

P-CCPCH

P-SCH

DCH

BCH

RACH

FACH

CPCH

DSCH

PCH

Transport channels S-CPICH

P-CPICH

S-CCPCH

AICH

DPDCH

DPCCH

PDSCH

PRACH

PICH

S-SCH

BCCH

CTCH

CCCH

PCCH

Logical channels

DTCH

DCCH

Birirectional

UTRAN Signaling Service access points

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

4-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 61: Umts Optimization Lucent

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

UTRAN Signaling Service access points

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-9

Page 62: Umts Optimization Lucent

Air interface protocols

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

Objectives

After completion of this section, you will be able to:

• Place the UTRAN protocols and channels in a call flow context.

Contents

RRC Connection and Signaling Connection 4-11

Signaling radio bearers 4-12

Radio bearer establishment 4-15

UTRAN Signaling

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

4-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 63: Umts Optimization Lucent

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-11

Page 64: Umts Optimization Lucent

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.

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

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

4-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 65: Umts Optimization Lucent

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

UTRAN Signaling Signaling radio bearers

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-13

Page 66: Umts Optimization Lucent

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)

• And 1 signaling radio bearer for transferring NAS messages set to″low priority″by the higher layers (RLC AM)

• Subsequent to the establishment of the signaling connection zero to severalsignaling radio bearers may be set up for transferring RRC signaling messagesusing transparent mode RLC (RLC TM entity).

Signaling radio bearer configuration at the UE

The RRC on the UE side configures L1 and MAC and creates the new RLC entitieswith the parameters given by the network-side RRC.

The following illustration shows the newly created signaling radio bearers after thecreation of the RRC connection.

Physical Layer (PHY)

Medium Access Control (MAC)

RLCRLC

RLCRLC

control Radio Resource Control(RRC)control

cont

rol

cont

rol

New RLCentities

MACparameters

L1Parameters

C-plane signaling U-plane information

SignalingRadioBearers

UTRAN Signaling Signaling radio bearers

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

4-14 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 67: Umts Optimization Lucent

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.

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-15

Page 68: Umts Optimization Lucent

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.

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

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.

UTRAN Signaling Radio bearer establishment

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

4-16 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 69: Umts Optimization Lucent

Radio Access Bearer establishment

The following illustration shows the newly created radio bearer after the creation of theRadio Access Bearer.

Physical Layer (PHY)

Medium Access Control (MAC)

RLCRLC

RLCRLC

control Radio Resource Control(RRC)

cont

rol

New RLCentity

MACparameters

L1Parameters

C-plane signaling U-plane information

New RadioBearer

RLC

PDCP DCP

BMC

UTRAN Signaling Radio bearer establishment

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

4-17

Page 70: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

1 Where is the NBAP terminated?

a UE and Node B

b Node B and RNC

c UE and RNC

d RNC and RNC

b

2 What kind of channel is the FACH?

a Physical

b Transport

c Logical

d Bearer

b

3 Which channel carries the pilot?

a P-CPICH

b PRACH

c P-CCPCH

d AICH

a

UTRAN Signaling

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

4-18 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 71: Umts Optimization Lucent

Part II: Optimization process

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

Objectives

After completing this lesson, you will be able to:

• Describe when optimization is performed during a network lifecycle and the phasesof the optimization process

• Describe what site readiness entails

• Describe the optimization planning phase

• Describe the RF optimization execution phase.

Contents

Lesson 5, Optimization process 5-1

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

II-1

Page 72: Umts Optimization Lucent
Page 73: Umts Optimization Lucent

5 5Optimization process

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

Objectives

After completing this lesson, you will be able to:

• Describe when optimization is performed during a network lifecycle and the phasesof the optimization process

• Describe what site readiness entails

• Describe the optimization planning phase

• Describe the RF optimization execution phase.

Contents

Lifecycle 5-2

Optimization process phases 5-4

Drive test optimization process 5-7

Planning and preparation (site readiness) 5-9

Optimization planning 5-11

Perform cluster optimization 5-13

Perform system verification 5-16

Information gathering 5-18

Information analysis 5-19

Exercises 5-20

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-1

Page 74: Umts Optimization Lucent

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.

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

3 Sites are planned and engineered according to the network design.

Network design

In serviceoptimization

Optimization Planning

Live network

Implementation

Network design& implementation

Y

N Acceptancecriteria met?

Optimization process

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

5-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 75: Umts Optimization Lucent

This translates the design into the real environment. This can mean that there aredifferences 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 process”

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

6 When all sites are completed and tested, final (drive) tests are performed to check ifthe network complies to the customer´s 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 Lifecycle

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-3

Page 76: Umts Optimization Lucent

Optimization process phases.................................................................................................................................................................................................................................

Objectives

This topic shows the stages of the optimization process in a live network.

Site readiness checks must have been performed before optimization starts.

Optimization process flow

Optimization process flow:

Sufficientinformation?

Y

N

Y

N

Identify reason

Determine solution

Implement solution

Begin

Gather information

Analyze information

Optimizationproblem?

N

Gather and analyzeinformation

Problemsolved?

Y

Optimization process

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

5-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 77: Umts Optimization Lucent

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

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-5

Page 78: Umts Optimization Lucent

Result: Implementation can range from a simple change of an OMC parameter tothe 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 has a “Beginning” and no “End”.

Optimization starts when a network goes live and never stops. Circumstances in a livenetwork always change and therefore optimization can not stop.

After an optimization problem has been solved, the optimization cycle continues,detecting and solving other optimization problems.

Optimization process Optimization process phases

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

5-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 79: Umts Optimization Lucent

Drive test optimization process.................................................................................................................................................................................................................................

Objectives

Before a network takes on live traffic, optimization using drive tests is usuallyperformed. These drive tests are performed to correct problems and to prove that thenetwork meets customer requirements.

Stages

The following is the optimization process that is performed prior to a network beingcommercially deployed:

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

1 Perform site readiness checks.

This ensures all cells are operating as required.

Site readiness checks include:

• Spectrum clearance,to ensure no external interferences are present and sufficient guard band are obeyed

• Antenna checks,to ensure that the antenna system is properly installed (tilt, azimuth, cabling)

• Sector verification,to ensure basic functionality of a sector (call processing, hand overs).

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

2 Plan optimization.

Ensure the system and tools are ready and available for drive test optimization.

This includes:

• Check proper RF parameter settings

• Check proper initial neighboring cell list settings

• Check availability of tools, equipment and personnel

• Define clusters

• Plan routes for drive testing.

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

3 Perform cluster optimization using drive tests.

This includes:

• Define clusters (group of cells)

• Unloaded cluster optimization,to identify RF coverage holes, hand over regions and pilot coverage areas

Optimization process

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-7

Page 80: Umts Optimization Lucent

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

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

5-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 81: Umts Optimization Lucent

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.

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 data

Optimization process

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-9

Page 82: Umts Optimization Lucent

can be post-processed. If sector problems do occur, they need to be remedied and thetests repeated until they are successful.

Baseline existing system

The objective of baselining the existing system is to collect the RF performancemetrics of the existing UMTS system equipment. Baseline driving should be performedprior to any RF optimization activity and involves measuring the Key PerformanceIndicators. It is important to keep the drive routes and KPIs identical for performancevalidation and comparison purposes.

Optimization process Planning and preparation (site readiness)

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

5-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 83: Umts Optimization Lucent

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.

Optimization process

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-11

Page 84: Umts Optimization Lucent

The following figure shows

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

Optimization process Optimization planning

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

5-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 85: Umts Optimization Lucent

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.

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.

Optimization process

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-13

Page 86: Umts Optimization Lucent

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.

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.

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 proceeds

Optimization process Perform cluster optimization

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

5-14 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 87: Umts Optimization Lucent

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

Optimization process Perform cluster optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-15

Page 88: Umts Optimization Lucent

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

Optimization process

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

5-16 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 89: Umts Optimization Lucent

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.

Optimization process Perform system verification

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-17

Page 90: Umts Optimization Lucent

Information gathering.................................................................................................................................................................................................................................

Information is needed to determine:

• If there is an optimization problem

• Optimization solutions

• If the problem is solved.

Information sources

As much information as possible should be used as input for optimization, so multiplesources of information are needed.

The main information sources are:

• Key performance indicators

• Drive tests

• Customer complaints.

Information from one of these sources, can trigger further investigation. During themore detailed investigation information from other sources is gathered.

Key performance indicators

Key performance indicators (KPI) are used to determine if the network complies to thelevels of performance that are needed.

KPIs are calculated using measurements that are gathered by the OMC-U.

Changes in values of the key performance indicators, especially reaching thresholds areoften the first indication of an optimization problem.

Drive tests

Drive tests can be used to gather information in the network. A drive test can beperformed to gather information about a specific problem or problem area. Drive testscan also be performed to gather general information about the network performance.

Customer complaints

Customer complaints can provide an indication of problems. Especially if multiplecomplaints can be related to one source. Customer complaints can point to a problemon a specific location, time or related to a resource.

Optimization process

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

5-18 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 91: Umts Optimization Lucent

Information analysis.................................................................................................................................................................................................................................

After information is collected, analysis of the information determines:

1. If there is an optimization problem

2. The source of the problem

3. Possible solutions for the problem

4. Consequences of implementing a solution.

Role of an engineer

The knowledge and experience of an engineer is an important tool in analyzing data.An experienced optimization engineer has detailed knowledge of how processes andprotocols in a network work. This allows the engineer to link information and events toa common source. An experienced engineer can even relate events to a single source,that do not seem to relate to each other.

The engineer can identify possible sources of a problem, solutions that can solve theproblem and predict consequences of a solution (in a general way).

Data analysis software tools

Because of the scale and complexity of a network, engineers are not able to handle thelarge volumes of detailed information that is available. Engineers can use softwaretools to handle the information and determine if there are problems.

Software tools can also be used to determine the consequences of implementing asolution in the network. Using models, software can simulate the impact on thenetwork of implementing a solution.

Commercially available and proprietary tools are available to analyze information anddetermine impacts.

Optimization process

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

5-19

Page 92: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

1 What do sector verification tests verify?

a Proper installation of antenna

b Basic call-processing functions

c No external interference is present

b

2 What does a measurement drive performed under unloaded network conditionstest?

a Fundamental flaws in the RF design

b Basic call-processing functions

c Non-optimized RF parameters

a

3 If, after loaded tests, a problem cannot be solved after three test drives, whatshould be done?

a A root cause analysis

b Further drive tests and optimization until the problem has been solved

c Cluster Optimization proceeds with the next cluster

a, c

Optimization process

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

5-20 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 93: Umts Optimization Lucent

Part III: Optimization andtroubleshooting

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

Objectives

After completing the following lessons, you will be able to:

• Suggest methods of dealing with issues affecting access.

• Describe methods of resolving Radio Link Failures

• Identify parameters that have a direct influence on the user´s perception of callquality

• Identify failure symptoms and suggest improvements for problems related to callmobility.

Contents

Lesson 6, Call availability and optimization 6-1

Lesson 7, Call reliability 7-1

Lesson 8, Call quality and optimization 8-1

Lesson 9, Call mobility and optimization 9-1

Lesson 10, UTRAN end-to-end key performance indicators 10-1

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

III-1

Page 94: Umts Optimization Lucent
Page 95: Umts Optimization Lucent

6 6Call availability andoptimization

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

Objectives

After completing this lesson, you will be able to:

• Describe the call setup process

• Narrow down the failing issues to a performance area

• Narrow down the failing issues to one or more performance metrics

• Suggest methods of dealing with issues affecting access.

Contents

Call availability 6-3

Call availability 6-4

Determination of accessibility problem 6-6

Network level accessibility 6-7

Introduction 6-8

Cell Search & RRC SIB decoding 6-9

Cell selection 6-10

Cell re-selection failures 6-12

RACH access procedure failures 6-14

RRC connection establishment analysis 6-17

Introduction to RRC connection establishment 6-18

Call admission control failures 6-20

Radio link setup failure 6-21

RRC connection setup failure 6-23

Paging failures 6-26

RAB establishment analysis 6-28

Introduction 6-29

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-1

Page 96: Umts Optimization Lucent

Dynamic bearer control failures 6-32

Radio link reconfiguration failures 6-33

Radio bearer establishment failures 6-34

No answer from UE 6-35

Code starvation 6-36

Exercises 6-37

Call availability and optimization Overview

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

6-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 97: Umts Optimization Lucent

Call availability

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

Objectives

After completing this section, you will be able to:

• Describe the basic call setup process

• Recognise KPIs which reflect the general satisfaction level with networkaccessibility.

Contents

Call availability 6-4

Determination of accessibility problem 6-6

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-3

Page 98: Umts Optimization Lucent

Call availability.................................................................................................................................................................................................................................

Introduction

Call availability is defined as the first main factor that identifies the user perception,from a UMTS point of view, of the UMTS network in successfully setting up a call.

Via the call set-up process, the UE executes the transition from Idle state to Cell_DCHstate, requests and acknowledges the resources setup; the UTRAN and the CoreNetwork allocate all the requested resources.

Call setup process

The call setup process consists of different procedures depending on what kind ofsession/service type is required (for example CS or PS). RRC ConnectionEstablishment and RAB Establishment procedure are the main procedures on theUTRAN side.

With the RRC Connection Establishment procedure, the UE requests resources fromthe UTRAN and executes the transition from Idle to CELL_DCH state, entering theUTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radiolinks.

With the RAB Establishment procedure, all the requested resources are allocated by theCore Network and by the UTRAN in terms of Radio Access Bearers (RABs) while theUE stays in Cell_DCH state and acknowledges the resources setup.

The call is successfully set-up only if both procedures are successfully completed.

Related transition states

In order to allow the user to successfully originate or receive a call, the UE must passthe following states:

• From the power-off state to the Idle state

• From the Idle state to the Cell_DCH state.

Call setup failures

Call setup failures can occur during the Network Attach procedures when the UEexecutes the transition from the power off to the Idle state. These failures impact CallAvailability as the user needs to get the UE to the Idle state before attempting callsetup.

Network level access phase

During the network level access phase, the UE has to successfully perform the cell(re)selection process as well as to gain network access using the Random Accessprocedure.

Call availability and optimization

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

6-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 99: Umts Optimization Lucent

RRC Connection Establishment phase

During the RRC Connection Establishment phase, the UE requests resources from theUTRAN and executes the transition from Idle to Cell_DCH state and enters theUTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radiolinks.

RAB establishment phase

During the RAB Establishment phase, the requested resources are allocated by theCore Network and by the UTRAN in terms of Radio Access Bearers (RABs) while theUE stays in Cell_DCH state and acknowledges the resources setup.

Call availability and optimization Call availability

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-5

Page 100: Umts Optimization Lucent

Determination of accessibility problem.................................................................................................................................................................................................................................

Introduction

In order to quickly determine whether there are severe problems in the UMTS network,it is possible to analyze the general satisfaction level, from a network point of view, ofthe UMTS mobile subscriber about the network accessibility.

Related PMs / KPIs

The related PMs / KPIs are:

• CSV Accessibility rate

• CSD Accessibility rate

• PSD Accessibility rate.

Each of the KPIs above is derived from multiplying the service type specificRABEstablishment Success Ratewith the Successful RRC Connection Establishment Rate.

Abnormal accessibility rate values

When one of the Accessibility rate values is very low, this can be caused by manydifferent 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

• RAB establishment phase.

Call availability and optimization

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

6-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 101: Umts Optimization Lucent

Network level accessibility

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

Objectives

After completing this section, you will be able to:

• Describe the procedures relating to cell search, SIB decoding, cellselection/reselection and RACH access

• Identify related KPIs and reasons for failures of those procedures.

Contents

Introduction 6-8

Cell Search & RRC SIB decoding 6-9

Cell selection 6-10

Cell re-selection failures 6-12

RACH access procedure failures 6-14

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-7

Page 102: Umts Optimization Lucent

Introduction.................................................................................................................................................................................................................................

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

Successful completion of both procedures is a basic prerequisite to succeed in any callprocedure.

Not visible for performance management

Both the cell selection/re-selection and Random Access Detection procedures are notvisible to the network before successful reception of RRC messages relevant for thespecific call procedure. Therefore, failures occurring during both procedures will notaffect the value of any RRC connection performance indicators.

Call availability and optimization

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

6-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 103: Umts Optimization Lucent

Cell Search & RRC SIB decoding.................................................................................................................................................................................................................................

Introduction

Cell Search and RRC System Information Broadcast (SIB) messages decoding precedecell selection and re-selection procedures.

Both procedures directly affect cell selection and re-selection, thus some more detailson this are provided here.

Process

Generally the process of cell search can be divided into three stages:

• Slot synchronization by using the Primary Synchronization Channel (P-SCH)

• Frame synchronization and code group identification utilizing the SecondarySynchronization Channel (S-SCH)

• Scrambling code identification on the Primary Common Pilot Channel (P-CPICH).

P-SCH, the S-SCH and the P-CPICH power settings

The behavior of the cell search algorithms is largely impacted by the power settings ofthe three physical channels involved in this process: the P-SCH, the S-SCH and theP-CPICH.

If problems during the cell search procedure occur in areas of good coverage, thepower settings of the channels involved, defined by corresponding UTRAN parameters,should be examined. This could be done using drive test equipment allowing thesupervising of the three different stages of cell search, which helps to identify thecauses of unsuccessful cell search operation.

P-CCPCH power setting

Once the UE has successfully synchronized to the P-CPICH scrambling code of theNodeB, it starts to decode the RRC SIB messages on the Broadcast Channel (BCH).The power setting for the P-CCPCH, which carries the BCH information, may affectthe SIB decoding success rate.

If this power is too low the UE may not be able to properly decode the SIB and cantherefore not read the parameters related to several UE procedures such as cellselection and re-selection, RACH access, and handover. SIB decoding issues should beexamined using UE drive test equipment by recording and evaluating the SIB detectionerror rate.

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-9

Page 104: Umts Optimization Lucent

Cell selection.................................................................................................................................................................................................................................

Introduction

Once the UE has successfully completed Cell Search and SIB Decoding, it performscell selection. During this procedure the UE tries to find a cell of a suitable PublicLand Mobile Network (PLMN) which satisfies the cell selection criteria.

Two thresholds for quality and level of the received pilot are used within the cellselection criteria. Current UE measurements must exceed both thresholds before theUE tries to access this cell.

Both thresholds are defined as UTRAN parameters:

• sIB3QqualMin

• sIB3QRXLevMin

If the cell selection criteria are not fulfilled, the UE will not access the network on theRACH and is therefore not visible to the network. This can be caused by incorrectparameters settings or by bad coverage.

Failure Symptoms

If the selection criteria are not fulfilled, the UE will not try to attach to the network,i.e. it will not send an RRC Connection Request message on the RACH set to“Registration”. Therefore, this failure is not visible from the network. On the UE side,the UE stays on “Searching” state that is visualized in the display.

If the UE enters the “Limited Service” state, Cell Selection was successful but the UEhas either camped on a cell belonging to a different PLMN or failures occurred duringthe Registration procedure on the initially selected PLMN (e.g. due to Core Networkissues).

All problems with cell selection can only be verified either using UE traces orobserving that traffic is lower than expected and users are complaining about problemsduring attach.

Improvement suggestions

If problems with the cell selection criteria within the RF-design coverage area aresuspected:

• The parameter settings related to cell selection should be verified.

• If all settings are compliant with the recommendations, the behavior should beinvestigated using a measurement UE and executing the attach procedure in thelocation where coverage issues are observed.

Call availability and optimization

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

6-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 105: Umts Optimization Lucent

• Measuring the current values of pilot Ec and Ec/Io in this location allows you tojudge whether the cell selection criteria should be fulfilled in this area.

• Under certain circumstances, it may be indicated to lower both quality and levelthresholds even further to allow the UE to attach. Care must also be taken toensure that the calls may be maintained at an acceptable quality with these loweredthresholds. Otherwise, UEs will be allowed to get onto the network, but will beunable to sustain sufficient quality, and may result in more dropped calls andunhappy customers.

Call availability and optimization Cell selection

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-11

Page 106: Umts Optimization Lucent

Cell re-selection failures.................................................................................................................................................................................................................................

Overview

Once the UE is able to select a cell and attach to the network, it should continuouslyperform the cell re-selection process.

If the parameters for cell re-selection have too much hysteresis, the UE will possiblyaccess a cell which is not the optimal choice in terms of interference. On the otherhand, lower re-selection hysteresis values will make the effect of ping-pongre-selections more likely.

If the UE selects a cell within a different URA, the UE will start the URA updateprocedure, pegging the PM counterNumUraUpdateRequest.UraChange.

Two important parameters (sIB3Qhyst2andsIB3Treselection) broadcast on the RRCSIB 3 message define the hysteresis of the measurement value Ec/Io and the hysteresistime.

Failure symptoms

If the hysteresis values are too high, this might cause call setup failures. Detailed rootcause analysis of cell reselection problems can only be performed via UE tracing.However, an increased number of RRC Connection Establishment failures incombination with high hysteresis values for cell reselection can indicate cell reselectionproblems causing this behavior. The parameters should be changed according to therecommendations to rectify this issue.

Another performance measurement related to cell reselection is the number of CellUpdate requests due to reselection. Only if reselection appears at the LA or RAboundaries will a Cell Update be performed. Nevertheless, this value should increasefor hysteresis values that are set too low in cells at an LA / RA boundary whencompared to a properly set cell with similar traffic.

Improvement suggestions

Before starting the investigation, it should be checked whether all reselection settingsare compliant with the recommendations.

If an increased number of Cell Update requests are observed at an LA/ RA boundary,and it is verified in a drive test that the reselection hysteresis is too small, then thehysteresis parameters must be raised.

After changing the reselection parameters, it can be verified in another drive test thatthe reselection hysteresis is high enough and that ping-pong reselections are extremelyunlikely.

Reselection issues that result in lower call setup success rates may indicate a hysteresissetting that is set too high. This should again be verified in a drive test and thenchecked whether it has improved after a parameter adjustment.

Call availability and optimization

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

6-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 107: Umts Optimization Lucent

Related PMs / KPIs

The related PMs / KPIs are:

• NumCellUpdateRequest.CellReselect

• NumUraUpdateRequest.UraChange.

If the UE selects a cell within a different URA, the UE will start the URA updateprocedure, pegging the PM counterNumUraUpdateRequest.UraChange. The number ofCell Update requests due to reselection is pegged byNumCellUpdateRequest.CellReselect.

Call availability and optimization Cell re-selection failures

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-13

Page 108: Umts Optimization Lucent

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 separate 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 AICH the UE transmits the RACH Message Part with anembedded RRC Connection Request message.

The signaling flow of a basic RACH transmission procedure:

Timer settings

Guard timer T300 (determined by UTRAN parametert300) and N300 (determined byUTRAN parametern300) supervises the transmission of the RRC Connection Requestmessage on the UE side.

Poor settings of timern300 may result in insufficient retransmission of the RACHmessage and poor settings for timert300 may result in RACH messages being

UeUu Iub

Node B RNC

RACH Preamble

Access indication(AICH)

RACH message(RRC Connection Request)

RACH Preamble

RACH Preamble

NumBadRACHTransBlock

NumGoodRACHTransBlockRRCRRC

Call availability and optimization

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

6-14 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 109: Umts Optimization Lucent

retransmitted too early or too late and thus affecting the procedures that initiated theRACH access (for example call setup).

Upon reception of the RRC Connection Request message at the RNC, PM counterNumRRCConnAttis incremented by one. When the UE is not able to eithersuccessfully attach to the network or successfully perform a Location Update, the CellSelection/Reselection procedures fails and the UE enters a″limited service″ state.

Failure symptoms

There are four PM counters that may help to identify RACH Access problems:NumRRCConnAtt, NumBadRACHTransBlock, NumGoodRACHTransBlockandChannelOccupRateRACH

• NumRRCConnAttis triggered on the RNC after reception of the RRC ConnectionRequest message independent of the establishment cause. Low values at a specificNodeB ofNumRRCConnAttare indicative of problems; nevertheless this countercannot prove that there are actually problems because RACH Preambles discardedby the NodeB are not counted. It may be that at a particular cell low traffic isresulting in low values of counterNumRRCConnAtt3.

• PM counterNumBadRACHTransBlockandNumGoodRACHTransBlockmay beused to arrive at the ratio between number of RACH TBs received with bad CRCto total number of RACH TBs. A high value for this ratio may be indicative ofproblems with the quality over the RACH.

• PM counterChannelOccupRateRACHis the ratio of total bits transferred on theRACH 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.

Improvement suggestions

The fixes for improvement depend on the detected reason for the failure:

NodeB does not decode the RACH Preamble

Possible reasons:

• The UE is not camping on an optimal cell due to incorrect selection/reselectionparameter settings.

• Due to hardware problems the sensitivity of the RX path could be reduced

• The power of the Initial RACH Preamble is too low. In this case it is necessary toincrease UTRAN parameterconstantVal

• The power required for RACH Preamble detection does not exceedphysicalRACH.preambleThreshold. In this case the three parametersMaxRetranPreamble, physicalRACH.preambleThresholdandpowerRampStephaveto be optimized

Call availability and optimization RACH access procedure failures

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-15

Page 110: Umts Optimization Lucent

The RACH coverage of the best server is too poor in terms of low Ec/Io that mightbe caused by:

– Pilot pollution: In this case the RF environment has to be optimized by e.g.antenna tilting, variation of the power settings of single NodeBs etc.

– The coverage of the best server is simply too low (low Ec/N0, RSCP or highpathloss). In case of coverage issues it may be useful to lower the detectionthreshold defined by UTRAN parameterphysicalRACHpreambleThresholdor toincrease the CPICH power controlled by UTRAN parameterpCPICH.power. Ifincreases are made to the CPICH power, then care must be taken to balance thepowers for the rest of the channels (if required), so that a situation does notarise whereby the user detects and uses a cell based on pilot power, but hasinsufficient traffic power available to carry the call.

UE receives no ACK on AICH

Possible reasons:

• The power of the AICH determined by UTRAN parameteraICHPoweris notsufficient.

• The AICH is interfered with by other non RF-optimized NodeBs. In this case, theRF environment has to be optimized by e.g. antenna tilting, variation of the powersettings of single NodeBs, antenna azimuth changes.

Lack of Node B resources

The UE receives a NACK on the AICH if the NodeB detects the RACH Preamble, butdoes not have enough resources to process the RACH Message Part.

NodeB does not decode the RACH Message

Possible reasons:

• The maximum allowed power on the RACH is set too low. In this case, the settingsof the two UTRAN parameterssIB3MaxAllowedULTxPowerandsIB4MaxAllowedULTxPowerhave to be optimized

• The power settings configuring the DPCCH relative power of the RACH MessagePart is set too low. In this case, the power settings ofphysicalRACHpreambleTh-resholdandPowerOffsetPpmhave to be optimized.

• The power settings configuring the DPDCH relative power of the RACH MessagePart is set too low. In this case, the power settings ofgainFactorBcandgainFactorBdhave to be optimized.

• Unsuccessful retransmission of the RACH Message Part. Possible reason is notoptimal UTRAN parameter settings oft300 andn300.

Call availability and optimization RACH access procedure failures

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

6-16 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 111: Umts Optimization Lucent

RRC connection establishment analysis

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

Objectives

After completing this section, you will be able to:

• Describe the RRC connection establishment process

• Identify related KPIs and reasons for failures in scenarios related to the RRCconnection establishment process.

Contents

Introduction to RRC connection establishment 6-18

Call admission control failures 6-20

Radio link setup failure 6-21

RRC connection setup failure 6-23

Paging failures 6-26

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-17

Page 112: Umts Optimization Lucent

Introduction to RRC connection establishment.................................................................................................................................................................................................................................

RRC Connection establishment procedure

In general the RRC connection establishment procedure may occur in differentscenarios such as:

• Network attach (the UE is switched on and moves to Idle state)

• Location update

• MO/MT call setup (the UE moves from Idle state to Cell_DCH state).

RRC Connection Establishment starts with the successful receipt at the RNC of theRRC Connection Request message. This means that cell selection/re-selection as wellas Random Access Detection 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 proceeds the random accessprocedure.

An example of a mobile originated call flow:

1

2

3

CAC

UEUu Iub

Node B RNC

RL Setup Request

RRC Connection ReqRACH( )

RL Setup Response

NumRRCConRej

NumRRCConEstFailRRC Connection Setup Complete

(DCCH over DCH)

RRC Connection Setup(CCCH over FACH)

RRCRRC

NBAPNBAP

NBAPNBAP

RRCRRC

RRCRRC

Call availability and optimization

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

6-18 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 113: Umts Optimization Lucent

Related PMs / KPIs

The related PMs / KPIs are:

• NumRRCConnEstFail

• NumRRCConnRej

• Successful RRC connections establishment rate.

Connection establishment failures

The RRC Connection Establishment Failures may occur due to following reasons:

• Call Admission Control failures

• Radio Link Setup failures

• Transport Bearer failures

• RRC Connection Setup failures

• Paging failures

• Soft/softer Handover failures at call setup.

Most of these failure causes are normally associated with poor RF conditions.

Low values of KPI RRC Connections Establishment Rate may also be due to RRCConnections Failures occurring during other procedures such as Network Attach, SMSand Location Update.

Call availability and optimization Introduction to RRC connection establishment

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-19

Page 114: Umts Optimization Lucent

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 is sentby the RNC to the UE.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRRCConnRej

• Average transmitted carrier power

• Forward power overload duration

• Maximum transmitted carrier power

• Maximum received signal strength indicator.

Abnormal NumRRCConnRej value

The triggering of CAC can be partly monitored using the PM counterNumRRCConnRejthat may be triggered not only in case of CAC but also in case ofRRC Connection Reject message sent to the UE with unspecified cause. If the valuesof this counter indicate that overload situations have occurred over long periods oftime, CAC may be one reason for the call setup problems experienced.

Load measurements

Other counters related to system load such asForward Power Overload Duration,Average Transmitted Carrier Power, Maximum Transmitted Carrier PowerandMaximum Received Signal Strength Indicatormay be used to verify that the load in thecell is fairly high, which would increase the probability for call setup failures.

Call availability and optimization

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

6-20 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 115: Umts Optimization Lucent

Radio link setup failure.................................................................................................................................................................................................................................

Introduction

Once the RNC has verified that the requested resources have passed the CallAdmission Control check, the RNC requests the Node B to allocate these resourcesthrough the NBAP Radio Link Setup procedure. In general at least one radio link hasto be set up; in case of soft/softer handover at call set-up more than one radio link hasto be set-up.

This procedure may fail due to different reasons such as:

• Notraffic channel resources available at the NodeB

• Faults either in the NodeB

• Faults in the Iub links.

In all failure cases the RNC sends back to the UE anRRC Connection Rejectmessage with cause “unspecified”.

No Traffic Channel Resources available

In order to allocate the requested resources, the RNC sends theRadio Link SetupRequest message to the relevant Node B. Upon reception of theRadio Link SetupRequest message, the Node B reserves the necessary resources and sends back theRadio Link Setup Response message to the RNC.

If the establishment of at least one radio link fails, the Node B sends back theRadioLink Setup Failure message to the RNC.

Typical failure causes can be classified as following:

• Radio Network Layer Cause, e.g. no NodeB resources available, requested TXDiversity Mode not supported, number of UL/DL channelisation codes notsupported, UL/DL Spreading Factor not supported;

• Transport Layer Cause due to unavailable transport resources;

• Protocol Cause due to semantic error;

• Miscellaneous Cause, e.g. HW failure.

Failure symptoms

Via Radio Link PM counters such asNumRLSetupFail.NodeBResandNumRLSetupFail.TransRes, it is possible to at least identify radio links unavailabilityissues along all radio link set-up procedures (that may occur along soft handoverprocedures as well as along call re-establishment).

Specific NodeB counters such as Total Channel Element Usage (ce_usage) andDedicated Channel Element Usage (dedic_ce_usage) provide important information onthe NodeB traffic and indicates if the NodeB capacity in terms of the availability ofphysical resources is close to the limit.

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-21

Page 116: Umts Optimization Lucent

Improvement suggestions

Assuming that no faults have been detected at NodeB via alarm analysis, the mostlikely failure cause is the one related to the unavailability of NodeB traffic resources.

In order to limit the occurrence of this failure cause, it is also recommended tocarefully review the link dimensioning plan according to the link allocation strategies.As the Radio Link Setup Request is transferred over NBAP on Iub, the availability oftransport and transmission resources is critical for success.

Traffic analysis focused on the critical Node Bs should be done by looking also atRAB sessions active and soft/softer traffic. RAB assignment is handled by RadioAccess Network Application Part (RANAP) on Iu links, so particular RANAPresources on transport/transmission layer impacts the radio link setup success. Actualimpacts could be caused by ATM QoS profile settings in the UTRAN and the transportnetwork.

NodeB traffic card faulty

Besides the RX-related problems, radio link setup failures may be caused by a faultyChannel Unit in the UCU card. Open an Alarm entity of the RNC to which the NodeBis connected and check whether alarms for UCU cards are displayed.

Iub links down

On Service Specific Connection Oriented Protocol (SSCOP) POLL and STAT ProtocolData Units (PDUs) are sent regularly in uplink and downlink in order to check the linkstatus. The POLL PDU is used to request, across an SSCOP connection, statusinformation about the peer SSCOP entity. The STAT PDU is used to respond to thisstatus request (POLL PDU) received from a peer SSCOP entity. Check with a protocolanalyzer connected to Iub whether these PDUs are being sent. If the PDUs cannot beseen, the Iub link must be checked.

Call availability and optimization Radio link setup failure

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

6-22 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 117: Umts Optimization Lucent

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 measurementNumRRCConnEstFailis used to record failuresoccurred during the RRC Connection Setup procedure.

Before starting this procedure the Serving RNC (SRNC) assigns a Radio NetworkTemporary Identity (RNTI) to the UE. If the RNTI pool in an RNC runs out of range,the RRC Connection Setup is not possible. This could be the case if the RNTI poolsize is below the number of mobiles requiring RNTIs at the same time.

The process

At this stage the RNC sends the RRC Connection Setup message, resets counterV30001 and starts its internal guard timer T30001 (determined by UTRAN parameteruERRCConnSetupGuardTimer). When the RNC receives theRRC Connection SetupComplete message sent on the Dedicated Control Channel (DCCH) before T30001expires, the RNC stops T30001 and the UE is in CELL DCH mode.

If the RNC does not receive theRRC Connection Setup Complete message beforeT30001 expires, the RNC may start again sending theRRC Connection Setupmessage on the Forward Access Channel (FACH) depending on the status of counterV30001:

• If V30001 <= N30001 (that is determined by UTRAN parametermaxRRCConnSetupRetries), the RNC increments V30001 by one, resets timerT30001 and sends theRRC Connection Setup message again.

• If V30001 > N30001, the RNC will send anRRC Connection Reject message tothe UE; the resources reserved on NBAP and ALCAP are released.

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-23

Page 118: Umts Optimization Lucent

The following figure shows the call flow of the unsuccessful case.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRRCConnEstFail.

Abnormal NumRRCConnEstFail value

Possible reasons for failures in the RRC Connection Setup procedure:

• Not optimal settings of the UTRAN attributesuERRCConnSetupResponseTimer andmaxRRCConnSetupRetries

• The RRC Connection Setup message is not successfully decoded due to poorFACH coverage

• The RNC cannot successfully decode the RRC Connection Setup Completemessage.

Call availability and optimization RRC connection setup failure

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

6-24 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 119: Umts Optimization Lucent

Failure symptoms

The PM counterNumRRCConnEstFailis used to record failures occurred during theRRC Connection Setup procedure.

Causes for a failure may be indicated as follows:

• RRC Connection Reject message is sent from the RNC to the UE with cause“unspecified” upon maximum number ofRRC Connection Setup messageretransmissions being reached.

• RRC Connection Requestmessage is received at the RNC with value of the IE“Protocol error indicator” set to True. This indicates that theRRC ConnectionSetup message received at the UE was either invalid or requesting an unsupportedconfiguration.

Improvement suggestions

The suggested fixes will depend on the root cause. Below are the possible root causesand their possible solutions:

• The UTRAN parameteruERRCConnSetupGuardTimerandmaxRRCConnSetupRe-tries are not optimally set. In this case, it might be useful to increase one or bothparameters according to the dependencies and recommended settings provided inUMTS ParCat.

• The RRC Connection Setup message is not successfully decoded due to poorFACH coverage.The reasons might be:

– Pilot pollution: In case of pilot pollution the RF environment has to beoptimized by e.g. antenna tilting, variation of the power settings of singleNodeBs etc.

– The power of the FACH determined by UTRAN parameterfACH.maxPowerisnot sufficient.

• The RNC cannot decode theRRC Connection Setup Complete messagesuccessfully. In this case, increasing the power (defined by parameterDPCCH_power_offset) to be used at radio link set-up on the UL DCH by the UEmay help to increase the probability of successful decoding. Note that increasingthe UL DCH power may increase UL interference.

Call availability and optimization RRC connection setup failure

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-25

Page 120: Umts Optimization Lucent

Paging failures.................................................................................................................................................................................................................................

Paging procedure

In case of an MT call the UE in Idle state has to be paged before sending the RRCConnection Request message. The RRC paging type 1 message is sent on the PagingChannel (PCH) by the core network (this means 3G-MSC for circuit-switched calls orSGSN for packet-switched calls) to all the UEs belonging to the same Location Area(LA) (in case of a CS MT call) or to the same Routing Area (RA) (in case of a PS MTcall).

In a successful case the UE receives and correctly decodes the paging message andsends back the RRC Connection Request message with the relevant cause to theUTRAN (this means Terminating High Priority Signaling for PS calls and TerminatingConversational Call for Voice calls).

However it may occur that the UE either does not receive or does not correctly decodethe Paging message.

PMs / KPIs indications

The failure causes can be identified via UTRAN counterNumPageAttDiscard, PCHTraffic can be evaluated via counterChannelOccupRatePCH.

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

Related PMs / KPIs

The related PMs / KPIs are:

• NumPageAttDiscard

• ChannelOccupRatePCH.

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

Possible failure causes

In general the possible failure causes are Paging Channel (PCH) congestion or poorPCH coverage.

Also issues on transport network may impact the Paging procedure as:

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

Call availability and optimization

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

6-26 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 121: Umts Optimization Lucent

Improvement suggestions

If the identified cause is poor PCH coverage, the power of the PCH should beincreased via parameterpCHPower. To increase the UE’s probability of successfullydecoding the PCH, the pilot and Transport Format Combination Index (TFCI) bitswithin the S-CCPCH frames may be transmitted at a higher power by power offsetsdefined via parameterssecondaryCCPCH.powerOffset1andsecondaryCCPCH.power-Offset2respectively. .

If this failure occurs in the network due to PCH congestion, actions have to be taken toimprove the Location Area and the Routing Area plan. The Paging Channel (PCH) isnormally dimensioned such that it meets the needs for the expected normal pagingtraffic and the performance requirements of MT calls. Over dimensioning the PCHleads to a waste of resources.

Furthermore, the implementation within UTRAN of UTRAN mobility states allows afurther reduction of the use of the PCH as paging can be done on a cell basis or URA(UTRAN registration Area) basis rather than in all UTRAN cells of a particular RA orLA.

Call availability and optimization Paging failures

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-27

Page 122: Umts Optimization Lucent

RAB establishment analysis

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

Objectives

After completing this section, you will be able to:

• Describe the RAB establishment process

• Identify related KPIs and reasons for failures in procedures related to the RABestablishment process.

Contents

Introduction 6-29

Dynamic bearer control failures 6-32

Radio link reconfiguration failures 6-33

Radio bearer establishment failures 6-34

No answer from UE 6-35

Code starvation 6-36

Call availability and optimization

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

6-28 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 123: Umts Optimization Lucent

Introduction.................................................................................................................................................................................................................................

RAB establishment procedure

As soon as the RRC connection establishment procedure has been completed, the callsetup procedure is finalized via the RAB Establishment procedure.

The RAB Establishment procedure is executed in case of call setup with:

• Packet-switched (PS) calls

• Circuit-switched (CS) calls.

RAB establishment initiators

The RAB Establishment procedure is initiated by the core network, this means SGSNfor PS calls or 3G-MSC for CS calls, upon receipt of an RRC/RANAP Uplink DirectTransfer message from the UE requesting either a Packet Data Protocol (PDP) ContextActivation (PS call) or a Call Setup (CS call). This procedure is successfully completedupon receipt of RANAP RAB Assignment Response message at the core network.

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-29

Page 124: Umts Optimization Lucent

RAB establishment call flow

An example RAB establishment call flow:

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

Uu Iub Iu-psCNSRNCNode B

NumRABEstFail.Load

UE

RRC Radio bearer setup(DCCH over DCH)

RANAP RAB AssignmentResponse

Radio link reconfigurationcommit

NBAP Radio linkreconfiguration ready

NBAP Radio linkreconfiguration prepare

RANAP RABassignment request

Node B RNC data transport bearer sync

ALCAP Iub transport bearer establishment

ALCAP Iu transport bearer establishment

RRC UL Direct Transfer(PS: PDP Context RequestCS: Call Setup Request)

RRC DL Direct Transfer(CS ONLY: Call Proceeding)

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

RANAP Direct Transfer(CS ONLY: Call Setup Request)

RRC Radio bearer setup Comp(DCCH over DCH)

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

1

2

3

4

5

6

7

RANAP Direct Transfer(PS ONLY: Act PDP Context Acc)

DBC

NumRLReconfigFail.sum

NumRABEstFail.T3

NumRABEstFail.RBSetupFail

Call availability and optimization Introduction

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

6-30 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 125: Umts Optimization Lucent

6. RANAP RAB Assignment Response

7. PDP Context Accept (PS) or Call Alerting and Connect Procedures.

PMs / KPIs indications

When RAB Establishment Failures occur then KPITotal RAB Establishment SuccessRateis affected due to total number of RAB establishment failures that incorporates allthe RAB Establishment Failure causes. Some of the failure causes listed above can beidentified via specific PM counters as depicted in the signaling flow.

The Total RAB Establishment Success Rateis the percentage of calls for all supportedservice types that successful established a RAB, against the number of valid callsrequested. Since the only part of the UMTS network considered here is the UTRAN,the call is identified as a Radio Access Bearer (RAB).

Related PMs / KPIs

The related PMs / KPIs are:

• Total RAB establishment success rate

• Total number of RAB establishment failures.

RAB establishment Attempt failures

The major RAB Establishment Attempt failure components may be classified asfollows:

• Dynamic Bearer Control failure

• Radio Link Reconfiguration failure

• Radio Bearer Establishment failures

• Miscellaneous failures, for example Code Starvation.

Call availability and optimization Introduction

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-31

Page 126: Umts Optimization Lucent

Dynamic bearer control failures.................................................................................................................................................................................................................................

Introduction

During RAB establishment the Dynamic Bearer Control (DBC) procedure is triggered.(See“RAB establishment call flow” (p. 6-30)). DBC failure will result in assignmentof a lower data rate. In case even the lowest data rate can not be assigned, the RABestablishment is rejected incrementingNumRABEstFail.Load. If the value of thiscounter indicates that an overload situation has occurred, then the root cause of thisoverload situation should be investigated.

Average Transmitted Carrier Power, Maximum Transmitted Carrier PowerandMaximum Received Signal Strength Indicatormay be used to verify that the load in thecell is fairly high.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRABEstFail.Load

• Forward Power Overload Duration

• Average transmitted carrier power

• Maximum transmitted carrier power

• Maximum received signal strength indicator.

Abnormal NumRABEstFail.Load value

If the value of this counter indicates that an overload situation has occurred, then theroot cause of this overload situation should be investigated.

Other system load counters

Other counters related to system load such asForward Power Overload Duration,Average Transmitted Carrier Power, Maximum Transmitted Carrier PowerandMaximum Received Signal Strength Indicatormay be used to verify that the load in thecell is fairly high.

Call availability and optimization

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

6-32 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 127: Umts Optimization Lucent

Radio link reconfiguration failures.................................................................................................................................................................................................................................

Introduction

The NBAP radio link reconfiguration procedure is responsible for preparing a newconfiguration of all existing radio links related to one RRC connection within a NodeB. (See“RAB establishment call flow” (p. 6-30)).

Radio link reconfiguration procedure

The radio link reconfiguration procedure is initiated by the RNC on sending the NBAPRadio Link Reconfiguration Prepare message to the Node B. Upon reception, the NodeB reserves necessary resources for the new configuration of the existing Radio Link(s)accordingly and sends back the NBAP Radio Link Reconfiguration Ready message tothe RNC.

Radio link reconfiguration failure

If the Node B cannot reserve the necessary resources then the procedure fails and anNBAP Radio Link Reconfiguration Failure message is sent back to the RNC instead ofan NBAP Radio Link Reconfiguration Ready message.

PMs / KPIs indications

The RL Reconfiguration Successes can be derived as difference between attemptscounted by PMNumRLReconfigAttand failure counted by PMNumRLReconfig-Fail.sum.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRLReconfigAtt

• NumRLReconfigFail.sum.

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-33

Page 128: Umts Optimization Lucent

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 sends back the RadioBearer Setup Complete message to the RNC upon successfully allocating resources forthe 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 set-up the new Radio Bearer. In this case the UE sends backthe Radio Bearer Setup Failure message to the RNC and the Radio BearerEstablishment procedure fails.

Possible reasons for Radio Bearer establishment failures are:

• A Badio bearer failure from the UE

• No answer from UE.

This is mainly caused by poor RF conditions.

All RB failure impact the value of KPIRAB Establishment Success Rate. They can beidentified via PM counterNumRABEstFail.RBSetupFailtriggered when Radio BearerSetup Failure message is received at the RNC.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRABEstFail.RBSetupFailure

Call availability and optimization

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

6-34 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 129: Umts Optimization Lucent

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 SetupComplete message from the UE. The guard timer is configured by UTRAN parameteruERadioBearerSetupResponseTimer. 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

Normal reason for this failure scenario is due to poor RF conditions, which couldresult because of poor coverage or high interference.

In addition, too low a setting of timeruERadioBearerSetupResponseTimerwith respectto the UE response time may be the failure cause.

PMs / KPIs indications

This failure causes degradation of KPIRAB Establishment Success Rate. The specificUTRAN PM counterNumRABEstFail.T3is triggered when the guard timer expires.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRABEstFail.T3.

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-35

Page 130: Umts Optimization Lucent

Code starvation.................................................................................................................................................................................................................................

Introduction

The number of times there is no channelization code available is counted using the PMcounterNumRABEstFail.CodeStarv. If this happens quite often it can contribute to anincreased number of failed RAB establishments. Chat applications are considered themost important cause of code starvation issues.

Related PMs / KPIs

The related PMs / KPIs are:

• NumRABEstFail.CodeStarv.

Call availability and optimization

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

6-36 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 131: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

Answer the following questions.

1 The fault in which card of the Node B could lead to a Radio link setup failure?

a MCR

b CTU

c IOU

d UCU

d

2 Which of the following KPIs indicates RRC SIB message decoding failure?

a NumRRCConRej

b NumRRCConnEstFail

c NumBadRACHTransBlock

d None of the above

d

3 Which process will insufficient AICH power level adversely affect?

a Call Admission Control

b RRC Connection Setup

c RACH Access Procedure

d Paging

c

4 Give a possible reason for a poor success rate of RRC Setup Establishment? Se-lect all that apply.

a Radio Link Failure

b RRC SIB message decoding failure

c RACH Access Procedure failure

d A radio bearer failure

a, b, c

Call availability and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

6-37

Page 132: Umts Optimization Lucent

5 What could a low number ofNumRRCConnAtt indicate?

a RACH Access Procedure failure

b Radio Link Failure

c Call Admission Control failure

d RRC Connection Setup failure

1

6 Which procedure may have a direct adverse affect onNumRABEstFail.Load?

a Dynamic Bearer Control (DBC) procedure

b NBAP Radio Link Setup procedure

c RRC connection setup procedure

d RAB establishment procedure

1

Call availability and optimization Exercises

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

6-38 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 133: Umts Optimization Lucent

7 7Call reliability

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

Objectives

After completion of this lesson, you should be able to:

• List factors that can cause dropped calls

• Describe methods of resolving Radio Link Failures

• Describe the Radio Link Restore and Deletion processes

• Identify causes of failure and develop stategies to solve them.

Contents

Dropped calls analysis 7-2

Radio link failures analysis due to synchronization issues 7-5

RLF and Radio Link Restore in the Uplink 7-6

RLF and Radio Link Restore in the Downlink 7-8

RLF failure: Poor RF coverage 7-9

RLF failure: Poor PSC plan 7-10

RLF failure: Pilot pollution and Around-the-Corner problem 7-11

RLF failure: Poorly defined neighbor list 7-12

RLF failure: Improved Aggregate Overload Control 7-13

Failures on RLC 7-14

Network interface outages 7-16

Network level retainability KPIs 7-18

Exercises 7-19

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-1

Page 134: Umts Optimization Lucent

Dropped calls analysis.................................................................................................................................................................................................................................

Introduction

As soon as the call is successfully set up, the second factor influencing 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. Where a drop on a PS session willstill result in PDP context preservation, and the end user will be able to re-establishseamlessly (with some delay). PS drops are generally not as severe for end users as CSdrops.

On the UTRAN side, KPIRAB Dropping Rate, defined as the percentage of droppedRAB due to any reason against the total number of established RABs for all services,can be calculated.

Call reliability

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

7-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 135: Umts Optimization Lucent

Signaling flow

The signaling flow of total RABs dropped:

On the UTRAN call handling procedures the dropped RABs are identified by either aRANAP Iu Release Request message or RANAP Reset Resource message sent by theRNC to the core network. When a Release Request message is sent, the resources onthe UTRAN and core network are released.

Note: For PS calls the PDP context will not be released.

Possible failing reasons

The major components that constitute RAB Drops may be classified as follows:

• Radio Link Failure, caused by:

– poor RF coverage

– poorly defined neighbor list

RANAP Iu release complete

RANAP

Iu release command(UTRAN generated reason)

RANAP

RRC Connection release(DCCH)

RRC Connection release complete(DCCH)

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 RAB 64 kbps UL and DL

A dropped RAB connectiondue to any kind of failure

RNC

RANAP

RRC

NumRABDrop.sum

Expiry of timerT_RL_RESYNC

Call reliability Dropped calls analysis

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-3

Page 136: Umts Optimization Lucent

– poor Primary Scrambling Code (PSC) plan

– pilot pollution

– DL power overload.

• Operator interaction (for example lock action)

• Inter-RAT handover due to supervision timer expiry (UMTS to GSM)

• URA_PCH time-out (due to the UE not performing a periodical URA update)

• Iu, Iub and Iur link failure

• RRC Signal Connection Release Indication sent by the UE.

Related PMs / KPIs

The related PMs / KPIs are:

• Total RAB dropping rate.

Call reliability Dropped calls analysis

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

7-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 137: Umts Optimization Lucent

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. The physical layer in the Node B and UE checks thesynchronization status of every radio frame.

Radio link states

The three states of the radio link are:

Initialstate

In-syncstate

Out-of-syncstate

RL Restore

RL Failure

RL Restore

Call reliability

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-5

Page 138: Umts Optimization Lucent

RLF and Radio Link Restore in the Uplink.................................................................................................................................................................................................................................

Introduction

The RLF and Radio Link Restore procedures in the uplink are supervised in the NodeB by the NBAP protocol. As each UE may have more than one uplink radio linkallocated (e.g. in soft/softer handover status), the Node B needs to monitor thecomplete radio link sets to trigger RLF and Radio Link Restore procedures.

Triggering the RLF procedure

When the radio link set is in the in-sync state and the NodeB is receivingN_OUTSYNC_IND consecutive out-of-sync indications, Node B starts timerT_RLFAILURE (T_RLFAILURE is determined by UTRAN parametertRLFailure,N_OUTSYNC_IND by UTRAN parameternoOutSyncInd).

The Node B stops and resets timer T_RLFAILURE upon receiving successiveN_INSYNC_IND in-sync indications (determined by UTRAN parameter noInSyncInd).

If T_RLFAILURE expires, the NodeB triggers the RLF procedure and indicates whichradio link set is out-of-sync. When the RLF procedure is triggered, the state of theradio link set changes to the out-of-sync state. In this case, the Node B indicates theRLF to the RNC by sending a Radio Link Failure Indication on NBAP with the cause“Synchronisation Failure”.

RNC and the RLF indication

Upon reception of the Radio Link Failure Indication with cause “SynchronisationFailure” the RNC starts timer T_RL_RESYNCH (determined by UTRAN parameterradioLinkFailureResynchronisationResponseTimer).

If the RNC receives from the NodeB theNBAP Radio Link Restore Indicationmessage, timer T_RL_RESYNCH is stopped and no further action is taken. The RadioLink Restore Indication is sent in case the radio link set is previously in theout-of-sync state and N_INSYNC_IND successive in-sync indications are received. TheNodeB indicates which radio link set has re-established synchronization. When theRadio Link Restore procedure is triggered, the state of the radio link set changes to thein-sync state.

Call reliability

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

7-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 139: Umts Optimization Lucent

Removing the radio link

Upon expiry of timer T_RL_RESYNCH, the RNC removes the particular radio link inthe NodeB via theNBAP Radio Link Deletionprocedure. The following two caseshave to be distinguished:

• The UE has more than one Radio Link either to several cells or in case of amultiple link scenario to one or several cells. In this case, the RNC starts the RRCActive Set Update procedure (which will not lead to a dropped call).

• If the dropped radio link is the last one the UE is connected to, the call is droppedand the RNC sends theRANAP Iu Release Requestmessage with specified cause“Release due to UTRAN generated reason” to the CN. When a UE loses the radioconnection in CELL DCH, the UE may initiate a new cell selection by transitioningto CELL_FACH state/idle mode.

Call reliability RLF and Radio Link Restore in the Uplink

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-7

Page 140: Umts Optimization Lucent

RLF and Radio Link Restore in the Downlink.................................................................................................................................................................................................................................

Introduction

The RLF procedure in the downlink is supervised in the UE by RRC.

RLF and restore

In the CELL DCH State, the UE starts timerT313 after receivingN313 consecutiveout-of-sync indications for the established DPCCH physical channel.

The UE stops and resets timerT313 upon receiving successiveN315 in-syncindications. IfT313 expires, the UE considers that the radio condition is terminatedwith an RLF.

1 or more radio links

As already discussed, two different cases have to be distinguished depending onwhether the dropped radio link was the last remaining one or not.

The following two cases have to be distinguished:

• The UE has more than one Radio Link either to several cells or in case of amultiple link scenario to one or several cells. In this case, the RNC starts the RRCActive Set Update procedure (which will not lead to a dropped call).

• If the dropped radio link is the last one the UE is connected to, the call is dropped.

Call reliability

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

7-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 141: Umts Optimization Lucent

RLF failure: Poor RF coverage.................................................................................................................................................................................................................................

Introduction

Uplink or downlink synchronization may be lost due to poor RF coverage. Note thatbecause of the cell breathing effect, the area where drop calls could occur may changewith the cell load.

Failure symptoms

Poor coverage can be detected with RF Call Trace enabled (for UL measurements) andUE tracing (for the DL measurements). Low Ec and Ec/Io values are expected in eitherUL and/or DL.

Furthermore, high transmit power in the UL and/or DL direction is expected. Aprotocol analyzer can discover RLF due to synchronization problems by identifyingRLF messages.

Cell breathing can be detected by changes in the measured Ec/Io on the same drive testroute. Note that the received Ec values are constant whereas the Io values changes withthe cell load.

Improvement suggestions

Poor RF coverage may be caused by faulty hardware (e.g. broken RF cable or faultyantenna). Other reasons may be a non-optimized RF environment or simply coverageholes in the network.

Call reliability

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-9

Page 142: Umts Optimization Lucent

RLF failure: Poor PSC plan.................................................................................................................................................................................................................................

Introduction

A poor PSC plan can cause RLF due to synchronization if there are two cells sharingthe same PSC that are relatively close to each other. In coverage overlapping areasboth sites will interfere with each other in the DL because the PSCs of both cells arenon-orthogonal.

Another problem can also happen if two cells sharing the same PSC are relativelyclose to each other, but do not necessarily have overlapping coverage areas. It mayhappen that the RNC is mixing up the two cells and requesting to add a leg to the“wrong” cell via the RRC Active Set Update procedure.

Due to the high number of PSCs that are available for the network design it should bepossible to create a proper PSC design for every network.

Failure Symptoms

Layer 1 UE logging can reveal interference in the DL. A protocol analyzer helps todiscover RLF due to synchronization problems. An indication for poor PSC planningmight also be high BLER in a good coverage area.

Call reliability

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

7-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 143: Umts Optimization Lucent

RLF failure: Pilot pollution and Around-the-Corner problem.................................................................................................................................................................................................................................

Introduction

Pilot pollution means an excessive overlapping of pilots with no dominant pilot. Thisleads to poor Ec/Io ratios and, in combination with the Around-the-Corner problem, tosudden drops of the Ec/Io. As a consequence, the RLF could fail due to beingout-of-synchronization.

Failure symptoms

Pilot pollution and the Around-the-Corner problem can be discovered by Layer 1 UElogging (low Ec and Ec/Io values of the cells in the active set, sudden drop of Ec andEc/Io of the cells in the active set). A protocol analyzer can help to discover RLF dueto synchronization problems.

Soft/Softer HO issues could also be the reason for pilot pollution.

Call reliability

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-11

Page 144: Umts Optimization Lucent

RLF failure: Poorly defined neighbor list.................................................................................................................................................................................................................................

Introduction

Poorly defined neighbor lists (too many neighbors or missing neighbors) can cause theUE to have radio links to non-optimal cells or to be unable to add a leg to an optimalcell. The consequence might be poor Ec and Ec/Io of the cells in the active set. Tomaintain the call the UE and NodeB have to transmit with higher power than required.The call may drop caused by RLF due to being out-of-synchronization.

Failure symptoms

Low Ec and Ec/Io values and high UE transmit power can be discovered. Missingneighbors are currently not reported as “detected cells” to the OMC-U.

Call reliability

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

7-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 145: Umts Optimization Lucent

RLF failure: Improved Aggregate Overload Control.................................................................................................................................................................................................................................

The Improved Aggregate Overload Control (IAOC) has three main functions:

• Ensures that the value of the demanded power remains within the linear range ofthe power amplifier

• Performs the amplifier protection based on power measurements

• Controlling the maximum overall transmit power on a sector-carrier.

The function is located in the NodeB and is controlled by NodeB internal parameters.

The IAOC may scale down the DL transmit power on the Dedicated Channels (DCH)if one of the three items above are out-of-range. This will impact the DL closed looppower control mechanism that may lead to a RLF due to synchronization issues.

Failure symptoms

System Load related counters such asFwdPowerOvldDuration, Average TransmittedCarrier Power (i.e.ave_tssi), Maximum Transmitted Carrier Power (i.e.max_tssi)provide useful indications on the DL power load measured on a per cell basis.

It is hard to identify lower coverage caused by IAOC via RF Call Trace drive testsbecause the power of the CPICH is unchanged. Lower DL transmit power of thededicated channel can be indirectly detected by a higher BLER. A protocol analyzercan discover RLF due to synchronization problems

Specific investigations on IAOC may also require use of the Cell Diagnostic Monitor(Cell DM) tool along a drive test in order to verify live when and where the IAOCsteps in, by checking whether the NodeB Transmitted Code Power suddenly decreases.

With the help of Cell DM, it can be seen that the DL transmit power is always lowerthan the maximum allowed DL power configured by UTRAN parametermaxDLPower.

Improvement suggestions

Usually if Load Control algorithms such as Dynamic Bearer Control and CongestionControl are working correctly, IAOC should be rarely invoked by the Node B. Onlyafter specific investigations and clear proof that IAOC misbehavior is causing RLFissues should settings of some IAOC parameters require optimization. .

Call reliability

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-13

Page 146: Umts Optimization Lucent

Failures on RLC.................................................................................................................................................................................................................................

Basic tasks

The RLC is a layer 2 sublayer. RLC provides three basic tasks:

1. Buffering

2. Segmentation and reassembly

3. Error control

Data transfer modes

The RLC provides three data transfer modes:

1. Transparent Mode data transfer

2. Unacknowledged Mode data transfer

3. Acknowledged Mode data transfer

RLC error recovery

When timer protected PDUs are not acknowledged before the timer elapses, the PDUsare retransmitted.

If retransmitted timer protected PDUs are unacknowledged for a certain time:

• Go either to SDU discard or RLC reset of the RLC connection between the twoentities

• If SDU discard does not succeed, go to RLC reset of the RLC connection betweenthe two entities

• If RLC reset does not succeed, signal unrecoverable error to higher layers. In thiscase the RRC might be dropped and the UE performs a Cell Update and the IE“AM_RLC error indication” is set to TRUE.

RLC ARQ mechanism

To identify each PDU has (for DL and UL and per RLC entity separately) anincreasing SN (0,{, 4095 for AM, 0,{,127 for UM). Upon transmission, the data PDUsare stored in a retransmission buffer when they are submitted to the MAC and PHYlayer. If a data PDU is NACK, it can be retransmitted.

ARQ uses the following mechanism:

• Status reporting on the RX: the RX sends a status report in STATUS PDUscontaining a detailed list of received and missing PDUs. STATUS PDUs havepriority over retransmitted data. They can be sent periodically or unsolicited e.g.after loss detection

• Polling from TX: the TX can request a status report

Call reliability

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

7-14 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 147: Umts Optimization Lucent

• Window mechanism: a sliding window allows the TX to transmit new PDUs whilewaiting for the ACKs till end of the window size.

• SDU discard function: when the delivery of a SDU cannot be managed because ofrepeated errors, the transmission of SDUs is stopped and discarded on both TX andRX side.

Failures on RLC

These are RLC failure symptoms:

• Retransmission of RLC identifiable as out-of-sequence RLC PDUs on Iub (extractthe particular call to distinguish from other RLC PDUs).

• A dropped call due to an RLC error can be easily identified by a Cell Updatemessage with cause “RLC unrecoverable error”.

The following table lists problems that can be detected in interface traces and thecorresponding KPIs in the PM system:

Problem Trace Trigger

RLC Resets Iub Any occurrence of RLC Resets in Iub traces

RLC retransmission Iub Any occurrence of retransmission of RLCPDUs per RLC session

SDU discard withexplicit signalling

Iub Any occurrence of a Move Receiving Window(MRW) command indicating a SDU discardand/or a MRW-ACK

Dropped call due toRLC error

Uu Any occurrence of a RRC Cell Updatemessage with specified cell update cause (notfailure cause) “RLC unrecoverable error”.There might be optional a failure causespecified. The IE AM_RLC error might be setto TRUE.

Call reliability Failures on RLC

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-15

Page 148: Umts Optimization Lucent

Network interface outages.................................................................................................................................................................................................................................

Introduction

Hardware failures can occur on the different nodes of the UTRAN and the CN, butalso on the particular interfaces.

There are many reasons for outages; analysing the FM data can retrieve a goodindication for the failure cause.

Potential problems

Outages may lead to:

• drops of the RAB and the RRC connection because of missing synchronisation

• coverage issues

• problems in the neighbour definition

• problems in the cell/PLMN selection/reselection procedure

• network accessibility might be limited.

Identifying outages

Outages can be easily identified when tracing the interfaces that have been out-of-sync.

Problem Trace Trigger

Iub out-of-sync I Iub Missing STAT PDUs onAAL5 for more than 5seconds

Iub out-of-sync II Iub Any occurrence of anAuditRequiredInformationon NBAP

Iu out-of-sync I Iu Missing STAT PDUs onAAL5 for more than 5seconds

Iu out-of-sync II Iu Any occurrence of a Reseton RANAP

KPIs describing network outages

The most important KPIs describing the drops of the RABs due to network outages:

PM system Formula Precondition Troublevalue

UTRAN NumRABDropsNodeBFail /NumRABSUM * 100

NumRABSUM >X

> Y

Call reliability

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

7-16 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 149: Umts Optimization Lucent

PM system Formula Precondition Troublevalue

UTRAN NumRABDropsRNCFail /NumRABSUM * 100

NumRABSUM >X

> Y

UTRAN NumRABDropsIubFail /NumRABSUM * 100

NumRABSUM >X

> Y

Call reliability Network interface outages

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-17

Page 150: Umts Optimization Lucent

Network level retainability KPIs.................................................................................................................................................................................................................................

Introduction

The retainability KPIs (all service types) is derived from the relation of total droppedRABs to the total successful established RABs.

KPIs per service types

The KPIs per service types are:

• Lucent Retainability KPI CSV, which is the same as (1 -RAB dropping rate forCSV12).

• Lucent Retainability KPI CSD, which is the same as (1 -RAB dropping rate for CSdata)

• Lucent Retainability KPI PSD, which is the same as (1 -RAB dropping rate forPS).

Related PMs / KPIs

The related PMs / KPIs are:

• RAB dropping rate for CSV12

• RAB dropping rate for CS data

• RAB dropping rate for PS.

Abnormal KPI values

When one of the Lucent Retainability KPI values is very low, this may be caused bymany different issues. Therefore it is advised to localize the issue by analyzing theperformance measurements and the possible failing reasons. There are several possiblefailing reasons of abnormal RAB disconnects.

Some of the important reasons are:

• Radio Link Failure (RLF) due to RRC connection failures

• Iu interface failures

• Iub or Iur interface failures.

Call reliability

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

7-18 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 151: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

1 A RAB drop does not always lead to a user- perceived dropped call because:

a UE can maintain the call via Call Re-establishment procedure

b The UE always has a backup RAB

c The RRC automatically reconfigures new resources

a

2 Where are the RLF and Radio Link Restore procedures in UL supervised?

a UE by the RRC

b RNC by the RRC

c NodeB by the NBAP

C

3 A dropped call due to an RLC error can be easily identified by which of the fol-lowing messages?

a Iu Release Command message

b Cell Update message

c RRC Release message

b

4 Which of the following load control functions should have the highest parametersetting?

a Connection Admission Control

b Dynamic bearer control

c Congestion Control

c

Call reliability

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

7-19

Page 152: Umts Optimization Lucent
Page 153: Umts Optimization Lucent

8 8Call quality and optimization

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

Objectives

After completion of this lesson, you should be able to:

• Identify parameters that have a direct influence on the user´s perception of callquality

• Assess the quality of different UMTS services using KPIs

• State the possible causes of high BLER rate

• Identify QoS voice service parameters

• Identify QoS data service parameters.

Contents

Network level quality KPIs 8-2

Uplink Block Error Rate (BLER) 8-4

Downlink Block Error Rate (BLER) 8-6

Quality of Service (QoS) 8-8

Exercises 8-11

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

8-1

Page 154: Umts Optimization Lucent

Network level quality KPIs.................................................................................................................................................................................................................................

Introduction

Although the 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 data call the poor quality maycause throughput degradation.

Quality KPI

UL and DL Block Error Rate (BLER) are the KPIs providing an indication of thequality of the UMTS call. The Lucent quality KPI capture the uplink failure on RNCbasis:

The quality KPI is derived from the uplink block error rate for all services (CSV, CSD,PS).

Poor quality reasons

High values of the quality KPI indicates that the perceived uplink quality of the call 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.

NumTransBlockTotUL= 1- × 100 [%]

NumTransBlockErrUL

Call quality and optimization

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

8-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 155: Umts Optimization Lucent

Basic root cause analysis method for high UL/DL BLER issues:

Note: It should not be assumed that UL BLER issues will also result in DL BLERissues and vice versa. In several scenarios the system may be either only uplink oronly downlink limited due to unbalanced loads.

Related PMs / KPIs

The related PMs / KPIs are:

• UL transport block error rate CSV

• UL transport block error rate CS data

• UL transport block error rate PS.

Other abnormal values

Other counters related to system load such asUL transport block error rate CSV, ULtransport block error rate CSDandUL transport block error rate PSmay be used toverify that the load in the cell is fairly high, which would increase the probability forcall setup failures.

Poor RFconditions

UL/DLpower

control issues

High UL/DL BLER

Max UE / Node Btransmitted power

reached?

NoYes

Call quality and optimization Network level quality KPIs

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

8-3

Page 156: Umts Optimization Lucent

Uplink Block Error Rate (BLER).................................................................................................................................................................................................................................

Introduction

UL BLER is calculated at the RNC and normally should stay within a target qualityvalue that is defined depending on the supported radio bearers. For example for data,the target quality value is currently equal to 5%, for voice it is equal to 0.8%.

Either poor RF conditions or UL Closed Loop Power Control issues may cause highUL BLER values.

Poor RF Conditions

Poor RF conditions increase the probability of receiving blocks not correctly decodedat the RNC. This means that if the UE transmitted power has already reached theallowed limit, UL BLER may still show values higher than the target value.

• RF coverage and interference: Ec/Io and Ec measurements jointly with Total toAggregate Ec/Io ratio

• UE traces (RFCT) should be performed and data imported to an RF analysis tool:UL BLER provided via RF Call Trace jointly with DL BLER provided via aCDMA air interface tester

• UE Transmitted Power and UE Peak Transmit Power Margin

• UL TCP/IP Throughput with DL TCP/IP Throughput and DL Physical LayerThroughput.

If the analysis of the metrics above show UL BLER degradation is caused by poor RFconditions (poor RF coverage or high UL interference), correct the conditions as shownin RLF section.

If not, issues with UL Closed Loop Power Control may be causing the problem.

UL Closed Loop Power Control issues

UL Closed Loop Power Control can be split in two loops, i.e. Outer Loop and InnerLoop.

1. The Outer Loop, located at the RNC, is responsible for updating the SIR targetaccording to the measured UL BLER in order to keep the UL target quality value(e.g. UL BLER equal to 5% for PS services) of the UL Dedicated Channel (DCH).

2. The Inner Loop, located at the NodeB, is responsible for sending the PowerControl commands to the UE upon comparison of estimated SIR with the targetSIR provided by the Outer Loop. The UE adapts its transmitted power according tothe Power Control commands received by the NodeB.

Specific UTRAN parameters are responsible for the proper working of both OuterLoop and Inner Loop. Usually these parameters are expected to be optimized beforeNetwork Deployment and not to be changed afterwards.

Call quality and optimization

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

8-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 157: Umts Optimization Lucent

Figure

The following graphic shows uplink outer loop power control.

Improvement suggestions

If Outer Loop is not quickly updating the SIR target, the UL BLER may show valuesgreater than the target value for long periods of time. Note that UL BLER values muchlower than the target value (e.g. 1% to 2% with a target value of 5%) may causequality degradation due to UE transmitting at a higher power than necessary, causinghigher UL interference.

If analysis of the metrics is showing that in some scenarios the SIR target is notquickly updated (i.e. UL BLER values are not distributed around the target value)according to the measured UL BLER this issue should be escalated to SystemEngineering.

If throughput or voice quality metrics are showing degradation even with UL BLERvalues distributed around the target value this means the UL BLER target value is notproperly set. Since this target value can be differentiated by service type (i.e. PS/CSand different supported data rate), further investigations should be requested.

Call quality and optimization Uplink Block Error Rate (BLER)

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

8-5

Page 158: Umts Optimization Lucent

Downlink Block Error Rate (BLER).................................................................................................................................................................................................................................

Introduction

DL BLER is calculated at the UE and normally should stay within its target qualityvalue defined for the DL DCH on a per radio bearer basis as for UL BLER.

High DL BLER values may be caused by:

• Poor RF conditions or

• DL Closed Loop Power Control issues.

Poor RF conditions

Poor RF conditions increase the probability of receiving blocks not correctly decodedat the UE.

Assuming DL Closed Loop Power Control is working properly, if the NodeBtransmitted power reaches the allowed limit on the DL DCH, DL BLER may still showvalues higher than the target one due to RF issues.

Detecting poor RF conditions

Different UE traces including a CDMA air interface tester, RF Call Trace running inparallel. After importing all traces into an analyzer, the following metrics should beanalyzed and correlated:

• RF coverage and interference: Ec/Io and Ec measurements jointly with Total toAggregate Ec/Io ratio

• UL BLER provided via RF Call Trace jointly with DL BLER provided

• NodeB Transmitted Code Power

• UL TCP/IP Throughput with DL TCP/IP Throughput and DL physical layerthroughput.

If the analysis of the metrics shows DL BLER degradation is caused by poor RFconditions, actions should be taken as recommended in the RLF section.

If not, the DL Closed Loop Power Control may be causing this problem.

DL Closed Loop Power Control Issues

As for the Uplink, DL Closed Loop Power Control can be split into two loops, bothlocated in the UE:

• Outer Loop

• Inner Loop.

The Outer Loop is responsible for updating the SIR target according to the measuredDL BLER in order to keep the DL target quality value (e.g. DL BLER equal to 5%) ofthe DL Dedicated Channel (DCH).

The Inner Loop is responsible for sending the Power Control commands to the NodeBupon comparison of estimated SIR with the target SIR provided by the Outer Loop.

Call quality and optimization

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

8-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 159: Umts Optimization Lucent

The NodeB adapts its transmitted power according to the Power Control commandsreceived by the UE.

Detecting DL Closed Loop Power Control Issues

Assuming that RF issues are not the cause, investigate using the following metrics:

• DL BLER via CDMA Air Interface Tracer

• NodeB Transmitted Code Power via RF Call Trace.

It should be verified that as soon as the DL BLER increases, the NodeB TransmittedPower is increased and vice versa.

DL BLER should have values distributed around the defined target value to ensure thatthe Closed Loop is working properly.

Analysing DL Closed Loop Power Control Issues

• If analysis of the metrics shows that the SIR target is not quickly updated, escalatethe issue to System Engineering.

• If throughput or voice quality metrics show degradation even with UL BLERvalues distributed around the target value, the UL BLER target value is not setproperly. Further investigations are needed.

• Assuming that Outer Loop Power Control is working properly at the UE, if theNodeB Transmitted Code Power displays values close or equal to the maximum DLDCH allowed power, parameter settingmaxDLpower should be changed. Note thatthis may cause decrease of DL capacity, as each single user will be allowed to usemore DL power on the DCH.

Call quality and optimization Downlink Block Error Rate (BLER)

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

8-7

Page 160: Umts Optimization Lucent

Quality of Service (QoS).................................................................................................................................................................................................................................

Introduction

“Quality of Service” is more specific than the more general term “quality”.

QoS has to do with getting the particular service the user asks for:

• that the network allocates the correct resources and

• that the traffic mechanisms support the request during the traffic flow.

QoS – voice service

Because of the asymmetry of the UMTS links, it is necessary to measure the UL andDL voice quality separately. The equipment compares the received voice samples withthe transmitted voice samples. In this way, the evaluation software can do voice qualityclassification for both directions independently.

The table below gives the QoS parameters for voice services. For the voice qualityevaluation, the Mean Opinion Score (MOS) is used. The MOS is defined by the ITUand ranges from 1 to 5. For GSM Enhanced Full Rate (EFR) the theoretical maximumis 4.3. Good voice quality can be considered when the MOS exceeds 3.0. Voice qualitydegradation such as echo or voice delay are reflected by this measure.

The table below provides QoS parameters for voice services based on MOS.

Mean Opinion Score (MOS) QoS value

Below 2.0 Poor

2.0 to 3.0 Fair

3.0 to 4.0 Good

Above 4.0 Excellent

QoS – data services

Mobile subscribers surfing the Internet or downloading files from their company’snetwork could face data quality problems in UMTS networks. The user may complainabout low throughput rate, losses of connection or jitter.

The radio bearer can be dynamically assigned depending on traffic measurements orload. Even the mobile state may be changed to idle mode/URA_PCH/CELL_PCHmode.

Depending on the status of the RLC queue in the UE, the mobile might send :

• Measurement Report 4a (if traffic volume exceeds a threshold)

• Measurement Report 4b (if traffic volume falls below a threshold).

The RNC may or may not react to these Measurement Reports by doing an RBreconfiguration.

Call quality and optimization

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

8-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 161: Umts Optimization Lucent

A smaller radio bearer can be assigned if overload estimations are made by the RNC.

RRC Re-establishment

Another difference when describing the user perceived QoS for PS data services is afeature called RRC Re-establishment. A drop of the RAB and RRC connection doesnot (necessarily) mean that the PDP Context is removed from the GGSN or the FTPsession drops. After RRC Re-establishment, the FTP session can be resumed if thesession has not timed out in between.

For the user the drop of the RRC and RAB is visible by stalling of the FTP transferfor the particular time-frame and because of low throughput rates. In case of real timeapplications like video streaming or web radio the drop will be noticed by the user ifthe buffer of the application is emptied and no new data is received.

Data service parameters

The following table shows parameters important for data service QoS:

Parameter Description

Measurement Report 4a threshold Threshold defining when the MeasurementReport 4a is triggered

Measurement Report 4b threshold Threshold defining when the MeasurementReport 4b is triggered

Enable PDCP compression Defines whether or not PDCP compressionis used

Data service failure symptoms

Poor data quality can be identified in TCP/IP protocol traces by:

• IP Packet loss (or packet corruption)

– Will cause retransmission if TCP is used on the transport layer

– Will result in a slow down of the throughput

– Could cause a reset of the transport protocol.

• IP Packet delay

– Will result in a slow down of the throughput

– User experiences packet delay as jitter, e.g. the download stalls when browsingWWW or downloading data via FTP

– May cause retransmission on TCP layer.

• High BLER in the UL and/or DL. ( UE traces (DL) and RF Call Trace (UL)).

• Low throughput on RLC, RLC retransmission and RLC resets (Iub traces).

Call quality and optimization Quality of Service (QoS)

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

8-9

Page 162: Umts Optimization Lucent

Data service improvement suggestions

Poorly performing data connections can be caused by:

• Configuration problems on the client PC, the network connection between GGSNand the server (in the Internet) or configuration problems on the (Internet) server.

• Packet loss, packet delay or packet corruption on the way between the GGSN andthe RNC.

• Bad RF performance.

• Non-optimized RLC parameter settings and RLC resets.

Call quality and optimization Quality of Service (QoS)

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

8-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 163: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

1 Which KPI provides an indication of the quality of the UMTS Call?

a UL/DL SIR

b UL/DL BLER

c NumRABDrop.sum

d maxDLpower

b

2 Where is the Inner Loop Power Control located?

a UE

b Node B

c RNC

b

3 At the UE, what does the Outer Loop Power Control do if the DL BLER ishigher than the target BLER value?

a Calculate a higher SIR ratio

b Calculate a lower SIR ratio

c Raise the BLER target

d Lower the BLER target

a

Call quality and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

8-11

Page 164: Umts Optimization Lucent
Page 165: Umts Optimization Lucent

9 9Call mobility and optimization

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

Objectives

After completing this lesson, you will be able to:

• Describe the soft/softer handover process

• Narrow down the failing issues to a performance area

• Narrow down the failing issues to one or more performance metrics

• Suggest methods of dealing with issues affecting soft/softer handovers.

Contents

Soft/Softer Handover 9-3

Soft/Softer Handover failure classification 9-4

Soft/softer handover failures in non-CELL DCH state 9-5

Soft/softer handover failures in CELL DCH state 9-8

Poor RF conditions 9-10

Node B resource dry-up 9-11

Transport resources dry-up 9-12

No UE answer 9-13

UE reject 9-14

Hardware or link outage 9-16

Incorrect translation settings -Overview 9-17

Incorrect translations settings - measurement and reporting 9-18

Incorrect translation settings - Neighbor List Selection Algorithm 9-20

Incorrect translation settings - Active Set Update procedure 9-21

UMTS to GSM handover 9-22

Inter-system handover failures - overview 9-23

Relocation failures 9-25

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-1

Page 166: Umts Optimization Lucent

Handover procedure failures 9-26

Release procedure failures 9-30

Location and Routing area update 9-31

Location update failure 9-32

Routing update failure 9-34

Exercises 9-36

Call mobility and optimization Overview

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

9-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 167: Umts Optimization Lucent

Soft/Softer Handover

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

Objectives

After completing this section, you will be able to:

• Describe the basic handover process

• Describe Soft/Softer Handover failures in CELL DCH and non-CELL DCH states

• Recognize KPIs which reflect the Soft/Softer Handover procedures within theUMTS network.

Contents

Soft/Softer Handover failure classification 9-4

Soft/softer handover failures in non-CELL DCH state 9-5

Soft/softer handover failures in CELL DCH state 9-8

Poor RF conditions 9-10

Node B resource dry-up 9-11

Transport resources dry-up 9-12

No UE answer 9-13

UE reject 9-14

Hardware or link outage 9-16

Incorrect translation settings -Overview 9-17

Incorrect translations settings - measurement and reporting 9-18

Incorrect translation settings - Neighbor List Selection Algorithm 9-20

Incorrect translation settings - Active Set Update procedure 9-21

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-3

Page 168: Umts Optimization Lucent

Soft/Softer Handover failure classification.................................................................................................................................................................................................................................

Classification

Soft/Softer Handover failures are classified as follows:

• Failures in non-CELL DCH state:

– Random Access Detection Failure

– Call Admission Control Failure

– Radio Link Set-up Failure

– RRC Connection Set-up Failure

– Incorrect parameter settings.

• Failures in CELL DCH state:

– Poor RF Conditions

– Incorrect translations settings

– No NodeB resources available

– No transport resources available

– No UE answer

– UE Reject

– NodeB/RNC Outages

– Iub, Iur link Outages.

Call mobility and optimization

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

9-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 169: Umts Optimization Lucent

Soft/softer handover failures in non-CELL DCH state.................................................................................................................................................................................................................................

Introduction

If the UE is in a state other than CELL DCH and it is located in Soft/softer Handoverarea, then it is possible that - during the transition to CELL DCH state - the UE goesdirectly in Soft/softer Handover (S/SHO).

The non-CELL DCH state is applicable to the following scenarios of S/SHO:

• at Call Setup

• at Call Re-establishment

• for UL Data Transfer in URA PCH

• for DL Data Transfer in URA PCH

• for DL Data Transfer in CELL_FACH.

Important! Failures in S/SHO in non-CELL DCH state are not identifiable via anyspecific performance measurement or key performance indicator!

Scenarios

The following scenarios might apply to Soft/softer handover failures in non-CELLDCH state:

1. UE is in idle state and initiates the transition to CELL DCH state (S/SHO atCall Setup)

2. UE is in “forced” idle state due to unsupported URA PCH state (S/SHO at CallRe-establishment)

3. UE is in URA PCH state and the network needs to transmit data to the UE(S/SHO for DL Data Transfer in URA PCH)

4. UE is in URA PCH state and requests to transmit data to the network (S/SHOfor UL Data Transfer in URA PCH).

Process

In all four scenarios the UE sends intra-frequency measurements to the RNC withineitherRRC Connection Requestor RRC Cell Updatemessage.

Upon evaluating the UE measurements, the RNC decides whether the UE can enter theCELL DCH state already in soft/softer handover. When the SHO algorithm condition isfulfilled, the UTRAN allocates radio link resources before sending a confirmation

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-5

Page 170: Umts Optimization Lucent

message to the UEs. Afterwards, the UTRAN indicates to the UE to which links theUE has to be connected before sending back a completion message.

Scenario RNC messages for S/SHO scenarios in non-CELL DCH state

Step 1:Resource allocation message

Step 2:Link asignment indicationmessage

1 RRC Connection Setup RRC Connection Setup Complete

2

3 RRC Cell Update Confirm RRC RB ReconfigurationComplete4

Failures

The following failures are possible in non-CELL DCH state:

• Random Access Detection Failure

• Call Admission Control Failure

• Radio Link Set-up Failure

• RRC Connection Set-up Failure

• Incorrect parameter settings.

Failure symptoms

The following symptoms can be the root cause of S/SHO failures in non-CELL DCHstate:

• Random Access Detection Failure:

– RRC Connection Requestor RRC Cell Updatemessages are not successfullydecoded at the RNC

– Pilot candidates for S/SHO never getting the chance to be reported to theUTRAN.

• Call Admission Control Failure:Request to setup the call with more than one link is rejected due to overload

• Radio Link Setup Failure:Power resources available but NodeB fails in setting up more than one link

• RRC Connection Setup Failure:Resources successfully allocated at the NodeB butRRC Connection Setupprocedure fails.

• An additional failure may be due to incorrect setting of related parameters aslisted below:

– MaxNoReportedCellsOnRACH

(maximum number of cells to be reported on RACH)

– activeSetSizePS

Call mobility and optimization Soft/softer handover failures in non-CELL DCH state

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

9-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 171: Umts Optimization Lucent

(Maximum size of the active set for PS applications)

– activeSetSizeCS

(Maximum size of the active set for PS applications)

– AddThresholdSHO

(hysteresis to be subtracted for reported pilot candidate cells to be included inthe active set).

Note: Causes, identification techniques and fixes for these failures are covered in the“Call availability and optimization” part of this document.

Identification techniques

Evaluate success rate of S/SHO at call set-up:

• Retrieve from UE logs as well as from Iub traces theRRC Connection Requestmessages that include at least one reported pilot belonging to the Monitored Setin the Information Element measured results on RACH.

• Retrieve from UE logs as well as from Iub traces theRRC Connection SetupCompletemessage corresponding to the test calls.

If the percentage is lower than 100% the following steps are required:

• Evaluate theEc/Io measured on the best cell. Retrieve the relevantNBAPRadio Link Set-up (or Addition) Request/Response Connection Requestandidentify failure-related messages.

• Retrieve UE logs and from Iub traces the relevantRRC Connection Setupmessage and identify:

– either any failure-related message

– or any message not answered by the UE.

Improvement suggestions

If calls are set up with too many pilots requesting to be in the Active Set, this mayresult in failures caused by CAC algorithm or by unavailable NodeB resources.

• Proper settings of all parameters:

– MaxNoReportedCellsOnRACH

– activeSetSizePS

– activeSetSizeCS

– AddThresholdSHOshould be performed to limit this scenario.

Call mobility and optimization Soft/softer handover failures in non-CELL DCH state

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-7

Page 172: Umts Optimization Lucent

Soft/softer handover failures in CELL DCH state.................................................................................................................................................................................................................................

Introduction

If the UE is in CELL DCH state and it is located in Soft/softer Handover area, thereare three events for a soft/softer handover procedure:

• Addition of a pilot to the Active Set(i.e. event1A is included in Measurement Report message),performed as NBAP Radio Link Setup procedure for the first pilot or NBAPRadio Link Addition procedure for additional pilots.

• Removalof a pilot from the Active Set(i.e. event1B is included in Measurement Report message),performed as NBAP Radio Link Deletion procedure.

• Replacementof worse pilot in the Active Set by best candidate pilot(i.e. event1C is included in Measurement Report message),performed as NBAP Radio Link Setup or NBAP Radio Link Additionprocedure for the best candidate pilot, followed by NBAP Radio Link Deletionprocedure for worse pilot in Active Set.

Important! Soft/softer handovers can be executed as Intra-RNC as well asInter-RNC. In case of Inter-RNC soft/softer handover the two RNC involved aredefined as Serving RNC (S-RNC) and Drift RNC (D-RNC).

Process

If the UE is in CELL DCH state, the soft/softer handover can be summarized asfollows:

• RRC Measurement Report message reports a soft/softer handover triggeringevent to the UTRAN

• NBAP procedure sets up resources in the UTRAN (case of setup/addition orreplacement)

• RRC Active Set Update procedure executes the Soft/softer Handover

• NBAP procedure releases resources in the UTRAN (case of removal orreplacement)

• RRC Measurement Control message evaluates the Monitored Set update uponNeighbor List Selection Algorithm (NLSA).

Failures

The following failures are possible in CELL DCH state:

• Poor RF Conditions

• Incorrect translations settings

• No NodeB resources available

• No transport resources available

• No UE answer

• UE Reject

Call mobility and optimization

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

9-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 173: Umts Optimization Lucent

• NodeB/RNC Outages

• Iub, Iur link Outages.

Failure symptoms

The various failures and their symptoms, identification techniques, and improvementsuggestions for both Intra-RNC and Inter-RNC Soft handover are described in detail inthe following sections of this lesson.

Call mobility and optimization Soft/softer handover failures in CELL DCH state

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-9

Page 174: Umts Optimization Lucent

Poor RF conditions.................................................................................................................................................................................................................................

Introduction

Poor RF conditions may cause issues along SHO procedure as well as in general onmaintaining the call. Investigation techniques and suggested fixes for improvements arecovered with Radio Link Failures in the “Call reliability and optimization” lesson.

Call mobility and optimization

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

9-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 175: Umts Optimization Lucent

Node B resource dry-up.................................................................................................................................................................................................................................

Introduction

Upon successful decoding of Measurement Report message, the RNC allocates therequired resources at the NodeB over:

• either NBAP Radio Link Set-up for (soft handover) or

• NBAP Radio Link Addition procedure (for softer handover).

Failures

NodeB rejects the resource allocation request when no physical resources are available:

• NumRLSetupFail.NodeBResidentifies failure in the S-RNC on a per cell basis

• NumRLAddFail.NodeBResidentifies failure in the D-RNC on a per RNC basis.

Failure symptoms and identification techniques

Node B resource dry-up failures can be identified by the following symptoms:

• The NodeB rejects the resource allocation request

• Increased Pilot pollutionas the candidate pilot is not included in the Active Set

• Degradation of S/SHO Success Rate KPI’s.

Improvement suggestions

For Node B resource dry-up failures, the following improvement suggestions mayapply:

• Improve RF coverage

• Minimize Interference

• Minimize the impact of “round-the-corner” effect

• Adjust theuEActiveSetUpdateResponseTimer setting as best trade-offbetween:

– soft/softer handover delay minimization and

– UE response time requirements.

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-11

Page 176: Umts Optimization Lucent

Transport resources dry-up.................................................................................................................................................................................................................................

Introduction

If the maximum supported capacity of the Radio Link is reached, no transportresources (Iub links) are available.

Failures

The NBAP Radio Link setup or Radio Link Addition procedure may fail.

Failure symptoms

The dry-up of transport resources results in a degradation of Soft/softer HandoverSuccess Rate KPI’s

The degradation of Soft/softer Handover Success Rate KPI’s are tracked in thefollowing counters:

• NumRLSetupFail.TransReson a per cell basis in the S-RNC

• NumRLAddFail.TransReson a per RNC basis in the D-RNC.

Identification techniques

The relevant NBAP messagesRadio Link Setup Failure and Radio Link

Addition Failure triggering those counters can be retrieved via Iub traces.

Improvement suggestions

Capacity analysis focused on the Iub links traffic should provide recommendations foroptimized Iub links traffic distribution.

Call mobility and optimization

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

9-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 177: Umts Optimization Lucent

No UE answer.................................................................................................................................................................................................................................

Introduction

Upon successful resource allocation in the NodeB, the RNC sends the RRC Active SetUpdate message to the UE with the RRC Active Set Update procedure. A guard timeris started on the RNC to supervise the reception of the RRC Active Set UpdateComplete message from the UE.

The timeruEActiveSetUpdateResponseTimer defines the maximum value of theguard timer.

Failures

The Active Set Update procedure fails if the guard timer expires and no message isreceived from the UE or poor RF conditions exist due to poor coverage or highinterference.

Failure symptoms and identification techniques

All the allocated UTRAN resources are released.

Important! If the setting of timeruEActiveSetUpdateResponseTimer with respectto the UE response time is too low, this may also be a failure cause.

Improvement suggestions

• Improve RF coverage

• Minimize Interference

• Minimize the impact of “round-the-corner” effect

• Adjust uEActiveSetUpdateResponseTimer setting as best trade-off between

– soft/softer handover delay minimization and

– UE response time requirements.

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-13

Page 178: Umts Optimization Lucent

UE reject.................................................................................................................................................................................................................................

Introduction

Upon sending the Active Set Update message, the RNC receives Active Set UpdateFailure message from the UE due to:

• Invalid configuration,

• Incompatible simultaneous reconfiguration, or

• Protocol Error.

Normally these failures are expected to occur seldom as they indicate incorrectconfigurations in either the RNC or the UE due to RRC signaling issues like delaysor internal problems in UE or RNC.

Failures

If the Primary Scrambling Code (PSC) plan is not optimized and contiguous cells havesame PSC, the RNC may mix up the cells when receiving the Measurement Reportmessage from the UE.

The RNC then allocates resources to the wrong NodeB and sends an Active Set Updatemessage to the UE with an incorrect configuration.

Failure symptoms

The following failure symptoms will appear:

• Degradation of Soft/softer Handover Success Rate KPI’s

• NumIntraRNCSHOFail.UERejis triggered on receiving the Active Set UpdateFailure message at the UTRAN.

Identification techniques

The following techniques will help to to identify the specific failure cause:

• Trace test calls via a protocol analyzer

• Retrieve Active Set Update and Active Set Update Failure messages fromprotocol analyzer

Improvement suggestions

Reorganization or optimization of the Primary Scrambling Code planning stategy:

• Best trade-off between the processing load on the UE and the synchronisationtime

• Effectively the performance of synchronisation procedure

• Assign code groups to neighbouring cells/sectors which have smaller crosscorrelation values with other codes of the group so that during initial cellsearch, the UE will correctly identify the code in stage 3 of the cell searchprocess.

Call mobility and optimization

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

9-14 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 179: Umts Optimization Lucent

Important! The code groups which show poor cross correlation characteristicsshould be allocated as far away as possible.

Call mobility and optimization UE reject

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-15

Page 180: Umts Optimization Lucent

Hardware or link outage.................................................................................................................................................................................................................................

Introduction

At the OMC-U it can be checked whether alarms will be reported for this NodeB.

This is, however, in the area of Fault Management and not Call mobility optimization.

Failures

At the OMC-U Alarm specific reports are displayed for a particular Node B or RNC.

Failure symptoms

• NBAP procedure fails, for example due to:

– faulty Traffic Card in the NodeB

– broken or unstable Iub link NBAP ATM bearer configuration.

• Random Access Detection failure, for example a decoding failure in the UCUcard of the Node B

Identification techniques

• Alarm Entity at the OMC-U GUI

• Collect UCU trace taken directly from the NodeB (monitor the channelelements of the NodeB)

• Collect FMS traces (internal and external messages of the RNC) and TPUtraces (e.g., uplink power control testing) at the RNC.

Improvement suggestions

Detailed descriptions on the various alarms to be monitored are available in the RNCand NodeB OAM Manuals.

Call mobility and optimization

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

9-16 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 181: Umts Optimization Lucent

Incorrect translation settings -Overview.................................................................................................................................................................................................................................

Overview

In general, the handover translation parameters can be categorized into four mainthematic areas:

• Measurement and reporting

• Soft Handover algorithm

• NLSA algorithm

• Active Set Update procedure

Important! Depending on the thematic area, incorrect settings of handoverparameters may cause different problems. Therefore, it is strongly recommended torun a consistency check on these parameter settings before starting any detailedinvestigations.

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-17

Page 182: Umts Optimization Lucent

Incorrect translations settings - measurement and reporting.................................................................................................................................................................................................................................

Introduction

For specific issues, a number of parameters may need to be properly tuned in order toimprove the soft/softer handover performance:

• measQty.filterCoefficientdefines the length of the filtering period

• reportingCellStatus.reportedCelldefines which set of cells (i.e. Active, Monitored or Detected) can trigger theevent of adding a pilot to the Active Set and are being measured by the UE

• reportingCriteria1A.rcReportingInterval andreportingCriteria1C.rcReportingIntervaldefine the report periodicity for reporting eventsAdding a pilot (1A)to orReplacing a pilot (1C)in the Active set respectively

• NumUndeclHORejPerNcellis triggered when a detected cell not belonging to the neighbors list is reportedby the UE in order to be included in the Active Set.

Failure symptoms

The following failure symptoms will appear:

• Performance/quality degradation

• Decreased soft/softer handover success rate

• Further increase of dropped call rate.

Identification techniques

Drive tests including RF Call Trace will help to identify the specific failure cause:

• Total to Active Ec/Io Ratio helps to identify high interference areas

• Record of the time when Measurement Report messages are sent, that is, thesoft/softer handover has been triggered.

• The analysis of the UE measurements on the Monitored Set pilots beforesending the Measurement Report indicates whether the UE decision is fastenough compared to the specific RF scenario.

Improvement suggestions

The following suggestions will help to to improve the translation settings:

• Setting ofmeasQty.filterCoefficientto low values speeds up the handover decision

• Setting of parameterreportingCellStatus.reportedCellallows UE to measure and report also Detected Set pilots helps to identify thestrong interferers. If the strong interferer does not belong to the neighbors listthen the pilot is not added to the Active Set.

Call mobility and optimization

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

9-18 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 183: Umts Optimization Lucent

• Setting ofreportingCriteria1A.rcReportingInterval andreportingCriteria1C.rcReportingIntervalto low values increases the probability that Measurement Report messages aresuccessfully decoded at the UTRAN and helps to minimize the delay in thesoft/softer handover procedure

• Setting ofNumUndeclHORejPerNcellis part of the Handover matrix counters and can be imported in an UndeclaredNeighbor List tool for neighbor plan optimization purposes.

Call mobility and optimization Incorrect translations settings - measurement andreporting

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-19

Page 184: Umts Optimization Lucent

Incorrect translation settings - Neighbor List SelectionAlgorithm.................................................................................................................................................................................................................................

Introduction

The Neighbor List Selection Algorithm (NLSA) is used to set up a list of the mosteffective pilot neighbors to be monitored by the UE to reduce UE’s response time todetect new pilots. A subset of the neighbor list defined and optimized during RFplanning and optimization, located in the RNC. This sub-list provides the updatedmonitored set list to the UE via RRC Measurement Control message upon S/SHOsuccessful execution.

The NLSApriority setting within the attributeoutFDDAdjCells defines the searchpriority used in the NLSA. It is set on a per neighbor cell basis.

Failure symptoms and identification techniques

The following failure symptoms will appear:

• Poor performance/quality of the call

• High dropped call rate in the RAB establishment phase.

Improvement suggestions

The following suggestions may help to improve the performance with respect to theNeighbor List Selection Algorithm.

Correlate the results of drive test analysis with the ones from system performance,parameter settings and handover traffic:

• In order to identify which NLSA priority setting needs to be changedaccordingly:

– either increase the priority of strong detected pilots, or

– decrease the priority of weak monitored pilots.

• If several areas are showing a high number of detected pilots compared to themonitored list size:

– increase the value of parametercombinedNeighbourhoodListSize to minimizeinterference issues by including more pilots in the monitored set.

Call mobility and optimization

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

9-20 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 185: Umts Optimization Lucent

Incorrect translation settings - Active Set Update procedure.................................................................................................................................................................................................................................

Introduction

Upon successful resource allocation in the NodeB, the RNC sends the RRC Active SetUpdate message to the UE via the RRC Active Set Update procedure. A guard timer isstarted on the RNC to supervise the reception of the RRC Active Set Update Completemessage from the UE.

The attributeuEActiveSetUpdateResponseTimer defines the maximum value of theguard timer.

The Active Set Update procedure fails if:

• the guard timer expires and no message is received from the UE, or

• poor RF conditions exist due to:

– poor coverage or

– high interference.

Failure symptoms and identification techniques

If the Active Set Update procedure fails, all the allocated UTRAN resources arereleased simultaneously.

Important! If the setting of the timeruEActiveSetUpdateResponseTimer withrespect to the UE response time may is too low, this may also be a failure cause.

Improvement suggestions

The following suggestions may help to improve the performance with respect to theActive Set Update procedure:

• Improve RF coverage

• Minimize interference

• Minimize the impact of “round-the-corner” effect

• Adjust uEActiveSetUpdateResponseTimer setting as best trade-off between:soft/softer handover delay minimization and UE response time requirements.

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-21

Page 186: Umts Optimization Lucent

UMTS to GSM handover

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

Objectives

After completing this section, you will be able to:

• Describe failures in UMTS to GSM handover procedures

• Recognize KPIs which reflect the UMTS to GSM handover.

Contents

Inter-system handover failures - overview 9-23

Relocation failures 9-25

Handover procedure failures 9-26

Release procedure failures 9-30

Call mobility and optimization

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

9-22 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 187: Umts Optimization Lucent

Inter-system handover failures - overview.................................................................................................................................................................................................................................

Introduction

A handover to another network system or inter Radio Access Technology (inter RAT)handover is always a hard handover with MSC involvement.

The UTRAN initiates the Relocation Preparation Procedure at the Iu interface towardsthe MSC of the GSM network. The UE must have established at least a CircuitSwitched (CS) connection to the UMTS network.

The inter RAT-Handover can be performed for the following RAB combinations:

• One CS voice connection, or

• One CS voice connection and simultaneous PS connection.

For a UE, which is involved simultaneously in a CS connection and a PSconnection, the CS connection will be transferred to the target GSM cell first.When the CS handover is completed, the UE has to send a routing area updaterequest to the GSM network containing an indication that the GSM/GPRS networkneeds to continue an already established UTRAN CN context. Whether the UE isable to continue both the CS and PS connections in GSM/GPRS depends on itscapabilities.

Upon a handover failure the CS and PS connections are further served by theUMTS network if possible according to the radio conditions.

Handover decision

The inter-system handover algorithm for UMTS to GSM handover is developed forUMTS coverage islands, which are located within a GSM network providing fullcoverage within a certain area and for UMTS/GSM networks overlapping only in theirborder regions.

The Lucent inter-system handover feature supports various handover algorithms toprovide optimum solutions dependent on customer needs:

• DAHOHandover is triggered based on serving cell measurements. The target cellselection is solely performed on network configuration data without anymeasurements of the GSM frequency.

• MAHOHandover is triggered based on GSM measurements performed by the UE andserving cell measurements.

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-23

Page 188: Umts Optimization Lucent

• RRC RedirectionRRC redirection can be used to avoid call establishment in UMTS. If RRCredirection is active, UTRAN redirects the UE to GSM immediately on RRCconnection request.

• Directed RetryDirected Retry allows for early handover to GSM before Radio Access Bearer(RAB) resources are assigned in UMTS. At this time, the UE has a signallingconnection in UMTS only. On receipt of the RAB Assignment from the MSC,the UTRAN rejects the RAB Assignment with cause ’directed retry’ andinitiates the handover procedure to GSM.

Failure classes

The inter RAT handover procedures may fail due to the following reasons:

• UMTS to GSM handover:

– The Relocation Preparation procedure is not completed in time

– The overall Relocation procedure is not completed in time, i.e. the MSC doesnot initiate the Iu Release procedure.

– A failure is detected during the Relocation Preparation procedure.

– The UE fails to complete the requested handover.

– Receipt of an incorrect RELOCATION COMMAND message.

• GSM to UMTS handover:

– The GSM to UMTS handover feature is not enabled in UTRAN.The target cell id is not controlled by the RNC.

– The RNC fails to decode the″RRC container″ within the RELOCATIONREQUEST message.

– The UE does not support the target cell frequency band.

– The ciphering or integrity protection cannot be configured.

– No S-RNTI 2 can be allocated.

– No reduced range uplink scrambling code can be allocated.

– The requested radio resources cannot be established.

– The RNC does not receive a HANDOVER TO UTRAN COMPLETE messagefrom the UE.

– The MSC cancels the relocation by releasing the Iu connection.

Some of these failures are due to Network planning errors, others are the result offeatures that are not activated (yet). However, most of them are detected later in theoptimization process.

Call mobility and optimization Inter-system handover failures - overview

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

9-24 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 189: Umts Optimization Lucent

Relocation failures.................................................................................................................................................................................................................................

Failure symptoms and identification techniques

The following failure symptoms may appear:

• Continuous relocation failure and high signaling load -hoRelocGuardTimer toolowRNC will re-trigger a relocation very soon after the previous failed relocation.The probability is high that the relocation will fail again. Signaling andprocessing effort is increased.

• No relocation can be performed. -TRELOCprep too lowRNC will cancel the relocation procedure although the relocation request maybe still active in the MSC.

• Call drop -TRelocOverall too lowIf this parameter is set to a valuewhich is too low, the following can happen: Ifthe handover to GSM fails and the UE wants to return to its UMTS connection,the RNC may already have requested the Iu release and the UE is not able tocontinue its call.

Parameters

The following parameters apply for relocation failures:

• hoRelocGuardTimer

• TRELOCprep

• TRelocOverall

• TRELOCcomplete.

Improvement suggestions

The following suggestions for parameter values may help to improve the performancewith respect to the Relocation procedure:

• TRELOCcomplete < TRELOCprep < hoRelocGuardTimer

• TRELOCcomplete < TRelocOverall.

KPIs

The percentage of Handover Relocation procedures successfully completed is definedaccording to the following formula:

Total Relocation Preparation UMTS to GSM HO Success Rate=

[(NumAttRelocPrepUMTS-GSM

- NumFailRelocPrepUMTS-GSM.sum)

/ NumAttRelocPrepUMTS-GSM]

* 100

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-25

Page 190: Umts Optimization Lucent

Handover procedure failures.................................................................................................................................................................................................................................

Introduction

UMTS to GSM

The handover decision algorithm detects up to three potential GSM target cells, whichare used for successive handover attempts. If the handover procedure has failed for allsuitable GSM target cells, the handover decision algorithm is invoked again. If thehandover fails because the UE is not able to establish the call in the GSM system dueto insufficient radio conditions, successive handover attempts are not executed.

Handover algorithms

The following algorithms apply to UMTS to GSM handover.

DAHO

Database assisted handover (DAHO) is a terminology given to a handover where thedecision for executing the handover procedure is based solely on precise knowledge ofthe network topology.

MAHO

In certain networks or areas of a network it may not be possible to have a proper cellplanning that allows for the usage of DAHO. Therefore a second algorithm, which iscalled mobile assisted handover (MAHO) takes into account the received signalstrength of the GSM neighbor cells at the current location of the UE.

Failures

The failure causes specified within the message are as follows:

• Physical Channel Failurefor example loss of synchronization between UE and NodeB due to poor RFconditions.

• Unacceptable Configurationfor example blocking rate or timeouts

• Protocol Error.

The other two causes are expected to occur rarely and in general are not related toRF issues.

Failure Symptoms

The following failure symptoms may apply during the handover procedure:

• CS call drop

• GSM access blocking

• Call quality deterioration

• HO delay

• HO failure

Call mobility and optimization

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

9-26 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 191: Umts Optimization Lucent

• Frequent HO

• PS call drop.

Identification techniques and improvement suggestions

The inter RAT handover combines the handover between two independent networks,hence there is no KPI that can bridge this gap. The solution is to check and evaluatethe parameter and timer expiry settings according to the failure symptoms detected.

Cause Explanation Suggestion

CS call drop

RNC retriggeringinterval for HOattempt too long

When the previous relocation request gotlost, highhoRelocGuardTimer setting letsRNC wait a long time before re-triggeringthe relocation. The relocation needs a toolong time and, as the radio conditions getworse, the call may drop.

TRELOCprep <hoRelocGuardTimer

RNC cancellation ofactive relocation toolong

When the previous relocation request gotlost, highTRELOCprep setting lets the RNCwait a long time before it cancels the activerelocation procedure.

GSM fails and Iurelease request isperformed before UEcan return to UMTS

If the handover to GSM fails and the UEwants to return to its UMTS connection, lowTRelocOverall setting RNC may alreadyhave requested the Iu release.

TRELOCcomplete <TRelocOverall

HO to GSM triggeredtoo late and UEleaves the UMTScoverage area beforeit has received thehandover commandfrom the UMTS

High value ofumts2GsmQTriggerDAHO.timeToTriggersetting orumts2GsmQTriggerDAHO.timeToTriggersetting respectively delays the trigger for thehandover to GSM. With respect to the timefor the execution of the handover to GSM,the UE may have already moved out ofcoverage of the UMTS area and is not ableto receive the handover command from theUMTS network.

Adjust the time for whichthe triggering condition mustbe true before the UE sendsan event triggeredmeasurement report.

Physical channelfailure

Loss of synchronization between UE andNodeB due to poor RF conditions.

CheckIRATHO.FailOutCS-.PhyChnFail content

GSM access blocking

Physical channelsblocked

High value ofTRelocOverall setting letsthe RNC wait a long time before it requeststhe release of the Iu connection in case thatthe Iu release procedure is not initiated bythe MSC. The resources previously used bythe UE are blocked during this time.

Adjust TRelocOverall timersetting

Call mobility and optimization Handover procedure failures

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-27

Page 192: Umts Optimization Lucent

Cause Explanation Suggestion

Call quality deterioration

Call quality may getunacceptably bad

Low value ofumts2GsmQTriggerDAHO.threshold triggerinter-RAT DAHO too late when the actualquality dropsbelow the threshold specifiedfor the quality of the own system (UMTSfrequency).

Adjustumts2GsmQTriggerDAHO.threshold parameter setting

HO delay

selection from toolong Neigbor list size

High value ofumts2GsmHOMeas.combinedGsmNeighbourListSize causesthe UE to several attempts to determine thebest GSM target cell. The handover may getdelayed by some 100 milliseconds.

Adjust umts2GsmHOMeas.combinedGsmNeighbourL-istSize parameter setting

handover fromUTRANfailuremessage fromUE

UE does not support the handover scenario,or fails to establish the connection to thetarget RAT system, or receives anincorrecthandover from UTRAN commandmessage, or receives this message inCELL_FACH state.

Not related to UTRANoptimization, however, thefailure can be confused withunsuccessful relocationsymptoms.

HO failure (call retained in UMTS)

Relocationunsuccessful or notcompleted in time

timerTRELOCprep or TRelocOverallexpired, SRNC receives arelocationpreparation failurefrom the MSC orhandover from UTRAN failuremessage fromthe UE, UE receives an incorrectrelocationcommandmessage

refer to Relocationprocedures

No GSM cellavailable

Low value ofumts2GsmHOMeas.gsmQualityThresholdtriggers an inter-RAT handover although noGSM cell is available with sufficientcoverage.

Adjust umts2GsmHOMeas.gsmQualityThresholdparameter setting

Call mobility and optimization Handover procedure failures

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

9-28 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 193: Umts Optimization Lucent

Cause Explanation Suggestion

GSM cell qualitydeterioration

High valueumts2GsmHOMeas.gsmFilterCoefficientcauses a long delay before the changes intheGSM RSSI value have effect on thefiltered measurement result. An inter-RAThandover to GSM may get initiated but itwill not succeed because the GSM quality isno longer sufficient.

Another scenario is that the inter-RAThandover to GSM is not triggered and thecall may drop due to insufficient UMTSquality because it has not been recognizedthat a GSM cell has become good enoughmeanwhile.

Adjust umts2GsmHOMeas.gsmFilterCoefficientparameter setting

Frequent HO

Unnecessary handover High value ofumts2GsmQTriggerDAHO.threshold triggersthe handover to GSM although the quality ofthe UMTS signal is sufficient, that is, the UE isstill inside the UMTS area.

Adjustumts2GsmQTriggerDAHO.thresholdparameter setting

PS call drop

PS call is dropped insimultaneous CS/PScall

UMTS to GSM handover disconnects the CSbearer and signaling connection from theUMTS radio interface and re-establishes thisconnection on the GSM radio interface. As theservices by GSM are not 1:1 to those ofUMTS, the standard rules require that ahandover is always performed for the CSdomain. Hence the UE is required to attempt tore-establish the PS domain connectionseparately. If this function is not implemented,the PS call will be dropped.

This failure is UE specific.

KPIs

The percentage of UMTS to GSM Handover successfully completed is definedaccording to the following formula:

Total UMTS to GSM Handover Success Rate=

[(NumAttHoUMTS-GSM

- NumFailHoUMTS-GSM.sum)

/NumAttHoUMTS-GSM]

* 100

Call mobility and optimization Handover procedure failures

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-29

Page 194: Umts Optimization Lucent

Release procedure failures.................................................................................................................................................................................................................................

Introduction

Upon successful allocation of GSM resources in UE and GSM RAN, the 3G MSCinitiates the release of the UMTS resources in the UTRAN over theIu ReleaseCommandMessage.

Failures

In general, failures are not expected to occur at this stage. It is assumed that nooutages occur in the UTRAN. The only failure cause due to reasons other thanUTRAN outages is given at the expiry of 3G-MSC timerTrelocOverall.

Failure symptoms and identification techniques

A specific 3G-MSC counter is triggered when this failure cause occurs.

More information will be provided in the final version of this guideline.

Improvement suggestions

The setting of 3G-MSC timerTrelocOverall should should be checked against settingof the timershoRelocGuardTimer andTRELOCprep.

Call mobility and optimization

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

9-30 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 195: Umts Optimization Lucent

Location and Routing area update

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

Objectives

After completing this section, you will be able to:

• Describe failures in Location and Routing area update procedures

• Recognize KPIs which reflect the Location and Routing area update process.

Contents

Location update failure 9-32

Routing update failure 9-34

Call mobility and optimization

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-31

Page 196: Umts Optimization Lucent

Location update failure.................................................................................................................................................................................................................................

Introduction

A UE that has registered to the CS-CN-domain and it is in IDLE state, monitors theLocation Are Code (LAC) is broadcast over the Uu interface BCCH.

When the UE detects a change in LAC, it requests a Location Update (LU). Uponexpiry of the timerT3212 the UE performs a LU periodically. The timer will be resetat any Mobility Management communication. After a successful LU procedure theCS-CN stores the current Location Area per mobile in the VLR record of the UE.

Failures

The following Location update failures may apply:

• Location Update Rejectmessage is sent back to the UE

• UE timer T3120 expiry

• Radio Resources release before completion of the procedure.

Failure symptoms and identification techniques

The following symptoms may apply to Location update failures:

• In general, Location Update failures results in increased number of LU retriesand increased number of unsuccessful CS paging.

• LA Identifier inconsistency between UTRAN and CS-Core.

• Failure due to timer T3120 expiry is often caused by delayed response of theMSC

• Radio resource release issues require observation of the RF conditions

• Additionnally, Location Update failure can be recorded by tracing the Air, theIub and Iu-CS interfaces and retrieving the relevant messages.

Note: With respect to the periodical Location Update by Mobility Managementcommunication, a high number of LUs in particular areas may result in highsignaling traffic and call failures.

Improvement suggestions

The following suggestions may help to improve Location Update failure issues:

• Check inconsistencies of the Location Area identifier between LACs in theMSC and UTRAN.

• A high number of periodical Location Update in particular areas require acareful review of the LA plan.

• The setting of timer T3212 can be increased.

Call mobility and optimization

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

9-32 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 197: Umts Optimization Lucent

KPIs

The Location Update Success Rate can be evaluated by three separated KPIs:

• InterVLRGeolLUSuccRate=(succInterVLRGeoLocationUpdates/attInterVLRPerioLocationUpdates)*100%

• IntraVLRGeoLUSuccRate=(succIntraVLRGeoLocationUpdates/attIntraVLRGeoLocationUpdates)*100%

• IntraVLRPerioLUSuccRate= (succIntraVLRPerioLocationUpdates/attIntraVLRPerioLocationUpdates)*100%.

Call mobility and optimization Location update failure

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-33

Page 198: Umts Optimization Lucent

Routing update failure.................................................................................................................................................................................................................................

Introduction

Similar to the Location Update, the Routing Area (RA) Update keeps the PS CoreNetwork updated on the UE’s position.

A UE that has registered to the PS-CN domain and is either in IDLE state or in URAPCH state, monitors the Routing Are Code (RAC) that is broadcast over the Uuinterface BCCH.

When the UE detects a change in RAC, it requests a Location Area Update (RAU).Upon a geographical trigger or the expiry of the timerT3312 the UE performs a RAUperiodically. The timer will be reset at any GMM communication. After a successfulLU procedure the PS-CN stores the current Location Area per mobile in the SGSNrecord of the UE.

Failures

The following Routing Area Update failures may apply:

• Routing Update Rejectmessage is sent back to the UE

• UE timer T3330 expiry

• Radio Resources release before completion of the procedure.

Failure symptoms and identification techniques

The following symptoms may apply to Routing Area Update failures:

• In general, Routing Area Update failures results in increased number of RAUretries and increased number of unsuccessful PS paging.

• RA Identifier inconsistency between UTRAN and PS-Core.

• Failure due to timer T3330 expiry is often caused by delayed response of theSGSN

• Radio resource release issues require observation of the RF conditions

• Additionally, Routing Area Update failure can be recorded by tracing the Air,the Iub and Iu-PS interfaces and retrieving the relevant messages.

Note: With respect to the periodical Routing Area Update by Mobility Managementcommunication, a high number of RAUs in particular areas may result in highsignaling traffic and call failures.

Improvement suggestions

The following suggestions may help to improve Location Update failure issues:

• Check inconsistencies of the Routing Area identifier between RACs in theSGSN and UTRAN.

• A high number of periodical Routing Area Update in particular areas require acareful review of the RA plan.

• The setting of timer T3312 can be increased.

Call mobility and optimization

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

9-34 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 199: Umts Optimization Lucent

KPIs

There is no direct impact from Routing area design to the RAU failure rate. Anindirect impact is the evaluation of the volume of geographic RAUs that contributes tothe load on the resources used during RAU with the following related KPIs:

• SGSN initiated inter SGSN RA update success rate=(succInterSgsnRaUpdate/attInterSgsnRaUpdate)*100%

• SGSN initiated intra SGSN RA update success rate=(succIntraSgsnRaUpdate/attIntraSgsnRaUpdate)*100%

Call mobility and optimization Routing update failure

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

9-35

Page 200: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

1 Which of the following soft/softer handover failures can occur in CELL FACHstate? Select all that apply.

a Random Access Channel Procedure Failure

b Active Set Update Failure

c Radio Link Setup Failure

d Iub link outage

1, 3

2 Which failure symptoms can occur at a soft/softer handover? Select all that apply

a Radio Link Setup Failure

b Iur link outage

c GSM access blocking

d Increased Pilot pollution

1, 2, 4

3 What reasons would cause a call that should be handed over to GSM to be re-tained in UMTS?

a Relocation procedure unsuccessful or not completed on time

b No GSM cell available

c RNC retriggering interval for HO attempt too long

d PS call is dropped in simultaneous CS/PS call

1, 2

4 Which feature of the inter-system handover algorithm for UMTS to GSM han-dover is used to avoid call establishment in UMTS?

a Database assisted Handover

b Moblie assisted Handover

c RRC Redirection

d Directed Retry

3

Call mobility and optimization

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

9-36 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 201: Umts Optimization Lucent

10 10UTRAN end-to-end keyperformance indicators

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

Objectives

This lesson gives an overview over the key performance indicators (KPIs) forend-to-end call setup and Quality of Service (QoS) within the UTRAN cluster.

What are KPIs?

KPIs are summarized quality and performance indicators which display a generalizedoverall performance or quality status of the network.

KPIs can be subdivided into:

• Performance guarantee KPIs

• Network quality KPIs

• Operational KPIs

• End-to-End KPIs

• Quality of Service KPIs.

What are KPIs made of?

KPIs can be computed from a number of performance and control counters on cell,cluster and network level.

Which KPIs are described here?

The following KPIs are described in this lesson:

• KPIs for the Circuit Switched domain:

– KPIs for mobile-originated call setups

– KPIs for mobile-terminated call setups

– KPIs for call drops

• KPIs for the Packet Switched domain:

– KPIs for mobile-originated call setups

– KPIs for mobile-terminated call setups

– KPIs for call drops

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-1

Page 202: Umts Optimization Lucent

• KPIs for Quality of Service monitoring

– KPIs for Quality of Service monitoring in the Circuit Switched domain:

– KPIs for Quality of Service monitoring in the Packet Switched domain:

Contents

KPIs for the Circuit Switched domain 10-3

KPI for Mobile-originated end-to-end call setup in the Circuit Switcheddomain

10-4

KPI for Mobile-terminated end-to-end call setup in the Circuit Switcheddomain

10-9

KPI for end-to-end call drops in the Circuit Switched domain 10-14

KPIs for the Packet Switched domain 10-18

KPI for Mobile-originated end-to-end call setup in the Packet Switcheddomain

10-19

KPI for Mobile-terminated end-to-end call setup in the Packet Switcheddomain

10-24

KPI for end-to-end call drops in the Packet Switched domain 10-30

KPIs for Quality of Service monitoring 10-35

KPIs for Quality of Service monitoring in the CS domain 10-36

KPIs for Quality of Service monitoring in the PS domain 10-38

Exercises 10-40

UTRAN end-to-end key performance indicators Overview

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

10-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 203: Umts Optimization Lucent

KPIs for the Circuit Switched domain

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

Objectives

This lesson section gives an overview over the key performance indicators (KPIs) forend-to-end call setup and Quality of Service (QoS) within the Circuit Switched (CS)domain for the UTRAN cluster.

Contents

KPI for Mobile-originated end-to-end call setup in the Circuit Switcheddomain

10-4

KPI for Mobile-terminated end-to-end call setup in the Circuit Switcheddomain

10-9

KPI for end-to-end call drops in the Circuit Switched domain 10-14

UTRAN end-to-end key performance indicators

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-3

Page 204: Umts Optimization Lucent

KPI for Mobile-originated end-to-end call setup in the CircuitSwitched domain.................................................................................................................................................................................................................................

Overview

This gives an overview over the key performance indicators for the mobile-originatedend-to-end call setup in the Circuit Switched domain (CS MO E2E).

Definitions for CS MO E2E call setups

End-to-end perspectiveThe end-to-end perspective is defined as the data transferpathway from the User Equipment to the Circuit Core Network.

Mobile originated call A mobile originated call is defined when the first message hasbeen sent by the mobile.

In this case the first message is “RRC Connection Request”. It includes all UE RRCconnection repetitions as specified by N300 and T300 timers.

Call attempt A call attempt is defined when the mobile has sent the “RRCConnection Request” to the Radio Access Network.

Successful callA mobile originated call is defined successful when the last messagebefore the speech or data phase start has been sent towards the User Equipment.

In this case the last message is “CC Alerting”.

Call setup success ratioThe Call setup success ratio is defined as the number ofsuccessful calls divided by the number of call attempts.

Call setup accessibility ratio The Call setup accessibility ratio is defined as theremainder ratio from the number of successful calls divided by the number of callattempts.

Formula

The end-to-end Call setup success ratio is defined as follows:

E2E CS MO Accessibility Ratio =UE(part) + NodeB (part) + RNC(part) + CS_CN(part) + Others

RRC Connection Request1 -

E2E CS MO Call setup Success Ratio =CC Alerting

RRC Connection Request

UTRAN end-to-end key performance indicators

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

10-4 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 205: Umts Optimization Lucent

Signaling flow for CS MO E2E call setups

Figure 10-1 RRC connection establishment

RRC RRC

NBAPNBAP

NBAP NBAP

RRC RRC

RRC RRC

RRC connectionrequest (cause)

Radio Linksetup request

Radio Linksetup response

RRC connectionsetup

RRC connectionsetup complete

Measurementcontrol RRCRRC

UEUu Iub

Node B RNC CNIu-cs

RRCconnectionestablishment

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in theCircuit Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-5

Page 206: Umts Optimization Lucent

Figure 10-2 MM and authentication

RRC RRC

RRC RRC

RRC RRC

UEUu Iub

Node B RNC CNIu-cs

RANAPRANAP

RRCRRC

Directtransfer

Downlinkdirect transfer

Initial directtransfer

Directtransfer

Directtransfer

RANAPRANAPDirect

transfer

RRC RRC

RANAP RANAP

RANAP RANAPSecurity mode

command

Security modecommand

Security modecomplete

RANAP RANAPCommon

ID

RANAP RANAP

Downlinkdirect transfer

RRC RRC

Uplinkdirect transfer

RRC RRC

SCCP SCCP

SCCP SCCP

Initial directtransfer

Connectionrequest

Connectionconfirm

RANAPRANAPInitial UEmessage

MM CMservice request

MM authenticationand cipheringrequest

Securitymode

CC setup

RANAP RANAPSecurity mode

complete

MM authenticationand cipheringresponse

MM CMservice accept

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in theCircuit Switched domain

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

10-6 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 207: Umts Optimization Lucent

KPI parts for E2E call setups

Parts Counters

UE (part) RRC.FailConnEstab.SetupIncomplete

RAB.FailEstab.RBSetupFail

RABFailEstab.T3

Figure 10-3 RAB assignment and call connect

RRC RRC

Directtransfer

Radio Linkreconf.request

Radio Bearersetup request

RANAP RANAPRAB assignment

response

RANAP RANAP

Downlinkdirect transfer

RRC RRC

RANAP RANAP

RAB assignment

RAB assignmentrequest

Radio Linkreconf.response

NBAP

NBAP

NBAP

NBAP

Radio Bearersetup complete

RRC RRC

UEUu Iub

Node B RNC CNIu-cs

CC callproceeding

Directtransfer

RANAP RANAP

CC connect

Downlinkdirect transferRRC RRC

CC alerting

DirecttransferRANAP RANAP

Downlinkdirect transfer

RRC RRC

CC connectacknowledgement

RRC RRCUplink

direct transfer

DirecttransferRANAP RANAP

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in theCircuit Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-7

Page 208: Umts Optimization Lucent

Parts Counters

NodeB (part) SHO.FailRLSetupIubUTRANSide.NodeBRes

SHO.FailRLSetupIubUTRANSide.TransRes

RRC.FailConnEstab.RLSetupFailure

RRC.FailConnEstab.CAC

RRC.FailConnEstab.CAC

RABFailEstab.CodeStarv

RAB.FailEstabPSNoQueuing.DLIntfer

RNC (part) VS.RRC.FailConnEstab.ProcessorLoad

General KPI counters for end-to-end call setup

The following counters are valid for all end-to-end call setups:

Counter name Part Description

RRC.FailCon-nEstab.RLSetupFailure

Node B No response from NodeB for a signaling Radio linkallocation (Signaling Radio Bearer). This is the numberof T_RLS expiry.

SHO.FailRLSetupI-ubUTRANSide.NodeBRes

SHO.FailRLSetupI-ubUTRANSide.TransRes

Node B Radio link setup failure response from NodeB for allcauses except code and power shortage for SRBallocation

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more code are available

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more power is available

RRC.FailConnEstab.Setu-pIncomplete

UE Number of T_U300 expiry no response from UE forRRC connection establishment

- UE Number of RRC connection setup failure responded byUE

RABFailEstab.CodeStarv Node B Number of RAB establishment failure because of nomore code are available

RAB.FailEstabPSNoQueu-ing.DLIntfer

Node B Number of RAB establishment failure because of nomore power is available

RABFailEstab.T3 UE Number of T_RB expiry no response from UE for RBSetup

RAB.FailEstab.-RBSetupFail

UE Number of RB setup failure received from UE

VS.RRC.FailConnEstab-.ProcessorLoad

RNC Number of Call setup failed due to internal RNC reasons

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in theCircuit Switched domain

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

10-8 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 209: Umts Optimization Lucent

KPI for Mobile-terminated end-to-end call setup in the CircuitSwitched domain.................................................................................................................................................................................................................................

Overview

This gives an overview over the key performance indicators for the mobile-terminatedend-to-end call setup in the Circuit Switched domain (CS MT E2E).

Definitions for CS MT E2E call setups

End-to-end perspectiveThe end-to-end perspective is defined as the data transferpathway from the User Equipment to the Circuit Core Network.

Mobile terminated call A mobile terminated call is defined when the first messagehas been sent by the network towards the mobile.

In this case the first message is “RRC Paging Type 1”. It includes all pagingrepetitions as specified by UMSC counter and timer.

Call attempt A call attempt is defined when the network has sent the “RRC PagingType 1” to the User Equipment.

Successful callA mobile terminated call is defined successful when the last messagebefore the speech or data phase start has been received.

In this case the last message is “CC Alerting”.

Call setup success ratioThe Call setup success ratio is defined as the number ofsuccessful calls divided by the number of call attempts.

Call setup accessibility ratio The Call setup accessibility ratio is defined as theremainder ratio from the number of successful calls divided by the number of callattempts.

Formula

The end-to-end Call setup success ratio is defined as follows:

E2E CS MT Accessibility Ratio =UE(part) + NodeB (part) + RNC(part) + CS_CN(part) + Others

RRC Paging Type 11 -

E2E CS MT Call setup Success Ratio =CC Alerting

RRC Paging Type 1

UTRAN end-to-end key performance indicators

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-9

Page 210: Umts Optimization Lucent

Signaling flow for CS MT E2E call setups

Figure 10-4 RRC connection establishment

RRC RRC

NBAPNBAP

NBAP NBAP

RRC RRC

RRC RRC

RRC connectionrequest (cause)

Radio Linksetup request

Radio Linksetup response

RRC connectionsetup

RRC connectionsetup complete

Measurementcontrol RRCRRC

UEUu Iub

Node B RNC CNIu-cs

RRCconnectionestablishment

RANAPRANAP

RRCRRC

Paging

Paging

Paging Type 1

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in theCircuit Switched domain

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

10-10 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 211: Umts Optimization Lucent

Figure 10-5 MM and authentication

RRC RRC

RRC RRC

RRC RRC

UEUu Iub

Node B RNC CNIu-cs

RANAPRANAP

RRCRRC

Directtransfer

Downlinkdirect transfer

Initial directtransfer

Directtransfer

Directtransfer

RANAPRANAPDirect

transfer

RRC RRC

RANAP RANAP

RANAP RANAPSecurity mode

command

Security modecommand

Security modecomplete

RANAP RANAPCommon

ID

RANAP RANAP

Downlinkdirect transfer

RRC RRC

Uplinkdirect transfer

RRC RRC

SCCP SCCP

SCCP SCCP

Initial directtransfer

Connectionrequest

Connectionconfirm

RANAPRANAPInitial UEmessage

MM pagingresponse

MM authenticationand cipheringrequest

Securitymode

MM CMservice accept

RANAP RANAPSecurity mode

complete

MM authenticationand cipheringresponse

CC setup

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in theCircuit Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-11

Page 212: Umts Optimization Lucent

KPI parts for E2E call setups

Parts Counters

UE (part) RRC.FailConnEstab.SetupIncomplete

RAB.FailEstab.RBSetupFail

RABFailEstab.T3

Figure 10-6 RAB assignment and call connect

RRC RRC

Radio Linkreconf.request

Radio Bearersetup request

RANAP RANAPRAB assignment

response

RANAP RANAP

RAB assignment

RAB assignmentrequest

Radio Linkreconf.response

NBAP

NBAP

NBAP

NBAP

Radio Bearersetup complete

RRC RRC

UEUu Iub

Node B RNC CNIu-cs

CC callconfirm

CC connectacknowledgement

CC connect

CC alerting

Directtransfer

RANAP RANAP

Uplinkdirect transfer

RRC RRC

DirecttransferRANAP RANAP

Uplinkdirect transfer

RRC RRC

DirecttransferRANAP RANAP

Uplinkdirect transfer

RRC RRC

DirecttransferRANAP RANAP

Downlinkdirect transfer

RRC RRC

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in theCircuit Switched domain

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

10-12 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 213: Umts Optimization Lucent

Parts Counters

NodeB (part) SHO.FailRLSetupIubUTRANSide.NodeBRes

SHO.FailRLSetupIubUTRANSide.TransRes

RRC.FailConnEstab.RLSetupFailure

RRC.FailConnEstab.CAC

RRC.FailConnEstab.CAC

RABFailEstab.CodeStarv

RAB.FailEstabPSNoQueuing.DLIntfer

RNC (part) VS.RRC.FailConnEstab.ProcessorLoad

General KPI counters for end-to-end call setup

The following counters are valid for all end-to-end call setups:

Counter name Part Description

RRC.FailCon-nEstab.RLSetupFailure

Node B No response from NodeB for a signaling Radio linkallocation (Signaling Radio Bearer). This is the numberof T_RLS expiry.

SHO.FailRLSetupI-ubUTRANSide.NodeBRes

SHO.FailRLSetupI-ubUTRANSide.TransRes

Node B Radio link setup failure response from NodeB for allcauses except code and power shortage for SRBallocation

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more code are available

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more power is available

RRC.FailConnEstab.Setu-pIncomplete

UE Number of T_U300 expiry no response from UE forRRC connection establishment

- UE Number of RRC connection setup failure responded byUE

RABFailEstab.CodeStarv Node B Number of RAB establishment failure because of nomore code are available

RAB.FailEstabPSNoQueu-ing.DLIntfer

Node B Number of RAB establishment failure because of nomore power is available

RABFailEstab.T3 UE Number of T_RB expiry no response from UE for RBSetup

RAB.FailEstab.-RBSetupFail

UE Number of RB setup failure received from UE

VS.RRC.FailConnEstab-.ProcessorLoad

RNC Number of Call setup failed due to internal RNC reasons

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in theCircuit Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-13

Page 214: Umts Optimization Lucent

KPI for end-to-end call drops in the Circuit Switched domain.................................................................................................................................................................................................................................

Overview

This gives an overview over the key performance indicators for the end-to-end calldrops in the Circuit Switched domain (CS E2E).

Definitions for CS E2E call drops

End-to-end perspectiveThe end-to-end perspective is defined as the data transferpathway from the User Equipment to the Circuit Core Network.

Call drop A call is defined as dropped message when an Iu release procedure isperformed after the“CC Alerting” for abnormal call release with the “Iu Releasecomplete” message.

Successful callA call is defined successful when the last message before the speechor data phase start has been sent towards the User Equipment.

In this case the last message is “CC Alerting”.

Call retainability The Call retainability is defined as the number of call drops dividedby the number of call successful calls.

Formula

...

KPI for CS E2E call drops

The KPI for CS E2E comprise the following parts:

CS-E2E-call drop

KPI Parts

CS_MO_E2E_Call_Drop RF (part)

UE (part)

NodeB (part)

RNC (part)

CS_MO_E2E_Call_Success CC Alerting

UTRAN end-to-end key performance indicators

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

10-14 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 215: Umts Optimization Lucent

The KPI parts for CS E2E comprise the following counters:

CS E2E call drop

Parts Counters

RF (part) RAB.RelPS.Drop.DL_RLF

RAB.RelCS.Voice.CauseRLF

RAB.RelCS.Data.CauseRLF

No. of call drop during hard handover inter-frequency

IRATHO.TRelocOverall

UE (part) RAB.Rel.Drop.UESigConnRel

NodeB (part) RAB.Rel.Drop.OpInterv

RNC (part) RAB.Rel.Drop.UETransDrnc

RAB.Rel.Drop.UEInactivity

Signaling flow

Figure 10-7 Normal CS E2E call release, mobile-originated and mobile-terminated

Directtransfer

RANAP RANAP

Directtransfer

RANAP RANAP

CC Release

CC Releasecomplete

Iu Release

Uplinkdirect transfer

RRC RRC

RRC RRC

RRC RRC

Downlinkdirect transfer

Uplinkdirect transfer

CC Disconnect Directtransfer

RANAP RANAP

NBAPNBAP

NBAP NBAP

RRC RRC

RRC RRC

Radio Linkdeletion request

Radio Linkdeletion response

RRC Connectionrelelase

RRC Connectionrelease complete

UEUu Iub

Node B RNC CNIu-cs

Iu releasecommand

RANAP RANAP

Iu releasecomplete

RANAP RANAP

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Circuit Switcheddomain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-15

Page 216: Umts Optimization Lucent

General KPI counters for end-to-end call drop

The following counters are valid for all end-to-end call drop:

Counter name Part Description

RAB.RelPS.Drop.DL_RLF RF Number of call drop because of Downlink radio linkfailure

RAB.RelCS.Voice.CauseRLF,RAB.RelCS.Data.Cau-seRLF

RF Number of call drop because of Uplink radio link failure

(Calculated) RF Number of call drop during hard handoverinter-frequency.

RAB.Rel.Drop.UESigCon-nRel

UE Number of call drop initiated by the UE.

RAB.Rel.Drop.OpInterv NodeB Number of call drop for NodeB generated reasons

Figure 10-8 CS E2E uplink radio link failure detection

Radio Linkdeletion

Noresponse

RRC

SCCPrelease

RANAP RANAPIu releasecomplete

RANAP RANAP

Radio Linkdeletion responseNBAP NBAP

Iu releasecommand

Radio Linkfailure indication

RANAP RANAPIu releaserequest

RANAP RANAP

Radio Linkdeletion request

NBAP

NBAP

NBAP

NBAP

UEUu Iub

Node B RNC CNIu-cs

Iu release

Figure 10-9 CS E2E downlink radio link failure detection

RRC RRC

RRC RRC

Cell update(”RL Failure”)

Cell updateconfirm

UEUu Iub

Node B RNC CNIu-cs

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Circuit Switcheddomain

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

10-16 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 217: Umts Optimization Lucent

Counter name Part Description

RAB.Rel.Drop.UETransDrnc,RAB.Rel.Drop.UEInactivity,

RNC Number of call drop for RNC generated reasons.

Individual counters for CS E2E call drop

The following individual counters refer to the CS E2E call drop:

Counter name Part Description

IRATHO.TRelocOverall RF number of call drop during hardhandover inter RAT

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Circuit Switcheddomain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-17

Page 218: Umts Optimization Lucent

KPIs for the Packet Switched domain

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

Objectives

This lesson section gives an overview over the key performance indicators (KPIs) forend-to-end call setup and Quality of Service (QoS) within the Packet Switched (PS)domain for the UTRAN cluster.

Contents

KPI for Mobile-originated end-to-end call setup in the Packet Switcheddomain

10-19

KPI for Mobile-terminated end-to-end call setup in the Packet Switcheddomain

10-24

KPI for end-to-end call drops in the Packet Switched domain 10-30

UTRAN end-to-end key performance indicators

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

10-18 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 219: Umts Optimization Lucent

KPI for Mobile-originated end-to-end call setup in the PacketSwitched domain.................................................................................................................................................................................................................................

Overview

This gives an overview over the key performance indicators for the mobile-originatedend-to-end call setup in the Packet Switched domain (PS MO E2E).

Definitions for PS MO E2E call setups

End-to-end perspectiveThe end-to-end perspective is defined as the data transferpathway from the User Equipment to the Packet Core Network.

Mobile originated call A mobile originated call is defined when the first message hasbeen sent by the mobile.

In this case the first message is “RRC Connection Request”. It includes all UE RRCconnection repetitions as specified by N300 and T300 timers.

Call attempt A call attempt is defined when the mobile has sent the “RRCConnection Request” to the Radio Access Network.

Successful callA mobile originated call is defined successful when the last messagebefore the speech or data phase start has been sent towards the User Equipment.

In this case the last message is “SM Activate PDP Context Accept”.

Call setup success ratioThe Call setup success ratio is defined as the number ofsuccessful calls divided by the number of call attempts.

Call setup accessibility ratio The Call setup accessibility ratio is defined as theremainder ratio from the number of successful calls divided by the number of callattempts.

Formula

The end-to-end Call setup success ratio is defined as follows:

E2E PS MO Accessibility Ratio =UE(part) + NodeB (part) + RNC(part) + PS_CN(part) + Others

RRC Connection Request1 -

E2E PS MO Call setup Success Ratio =SM Activate PDP Contect Accept

RRC Connection Request

UTRAN end-to-end key performance indicators

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-19

Page 220: Umts Optimization Lucent

Signaling flow for PS MO E2E call setups

Figure 10-10 RRC connection establishment

RRC RRC

NBAPNBAP

NBAP NBAP

RRC RRC

RRC RRC

RRC connectionrequest (cause)

Radio Linksetup request

Radio Linksetup response

RRC Connectionsetup

RRC Connectionsetup complete

Measurementcontrol RRCRRC

UEUu Iub

Node B RNC CNIu-ps

RRCconnectionestablishment

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in thePacket Switched domain

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

10-20 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 221: Umts Optimization Lucent

Figure 10-11 GMM attach

RANAP RANAPSecurity mode

complete

RRC RRC

RRC RRC

RRC RRC

UEUu Iub

Node B RNC CNIu-ps

RANAPRANAP

RRCRRC

Directtransfer

Downlinkdirect transfer

Initial directtransfer

Directtransfer

Directtransfer

RANAPRANAPDirect

transfer

RRC RRC

RANAP RANAP

RANAP RANAPSecurity mode

command

Security modecommand

Security modecomplete

RANAP RANAPCommon

ID

RANAP RANAP

Downlinkdirect transfer

RRC RRC

Uplinkdirect transfer

RRC RRC

SCCP SCCP

SCCP SCCP

Initial directtransfer paging resp.

Connectionrequest

Connectionconfirm

RANAPRANAPInitial UEmessage

GMM attach(request)

GMM attach(authenticationand ciphering)

Securitymode

GMM attach(accept)

GMM attach(complete)

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in thePacket Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-21

Page 222: Umts Optimization Lucent

KPI for PS MO E2E call setups

PS-MO-E2E-call setup

KPI Parts

PS_MO_E2E_Call_Success SM Activate PDP Context Accept, comprising:

UE (part)

NodeB (part)

RNC (part)

PS_MO_E2E_Call_Attempts

RCC Connection Request

KPI parts for E2E call setups

Parts Counters

UE (part) RRC.FailConnEstab.SetupIncomplete

RAB.FailEstab.RBSetupFail

RABFailEstab.T3

Figure 10-12 RAB assignement and PDP context activation

RRC RRC

RRCRRCUplink

direct transfer

DirecttransferRANAP RANAP

Directtransfer

Radio Linkreconf.request

Radio Bearersetup

RANAP RANAPRAB assignment

response

RANAP RANAP

Downlinkdirect transfer

RRC RRC

RANAP RANAP

RAB assignment

RAB assignmentrequest

Radio Linkreconf.response

NBAP

NBAP

NBAP

NBAP

Radio Bearersetup complete

RRC RRC

UEUu Iub

Node B RNC CNIu-ps

SMPDP contextactivation(request)

SMPDP contextactivation(accept)

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in thePacket Switched domain

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

10-22 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 223: Umts Optimization Lucent

Parts Counters

NodeB (part) SHO.FailRLSetupIubUTRANSide.NodeBRes

SHO.FailRLSetupIubUTRANSide.TransRes

RRC.FailConnEstab.RLSetupFailure

RRC.FailConnEstab.CAC

RRC.FailConnEstab.CAC

RABFailEstab.CodeStarv

RAB.FailEstabPSNoQueuing.DLIntfer

RNC (part) VS.RRC.FailConnEstab.ProcessorLoad

General KPI counters for end-to-end call setup

The following counters are valid for all end-to-end call setups:

Counter name Part Description

RRC.FailCon-nEstab.RLSetupFailure

Node B No response from NodeB for a signaling Radio linkallocation (Signaling Radio Bearer). This is the numberof T_RLS expiry.

SHO.FailRLSetupI-ubUTRANSide.NodeBRes

SHO.FailRLSetupI-ubUTRANSide.TransRes

Node B Radio link setup failure response from NodeB for allcauses except code and power shortage for SRBallocation

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more code are available

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more power is available

RRC.FailConnEstab.Setu-pIncomplete

UE Number of T_U300 expiry no response from UE forRRC connection establishment

- UE Number of RRC connection setup failure responded byUE

RABFailEstab.CodeStarv Node B Number of RAB establishment failure because of nomore code are available

RAB.FailEstabPSNoQueu-ing.DLIntfer

Node B Number of RAB establishment failure because of nomore power is available

RABFailEstab.T3 UE Number of T_RB expiry no response from UE for RBSetup

RAB.FailEstab.-RBSetupFail

UE Number of RB setup failure received from UE

VS.RRC.FailConnEstab-.ProcessorLoad

RNC Number of Call setup failed due to internal RNC reasons

UTRAN end-to-end key performance indicators KPI for Mobile-originated end-to-end call setup in thePacket Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-23

Page 224: Umts Optimization Lucent

KPI for Mobile-terminated end-to-end call setup in the PacketSwitched domain.................................................................................................................................................................................................................................

Overview

This gives an overview over the key performance indicators for the mobile-terminatedend-to-end call setup in the Packet Switched domain (PS MT E2E).

Definitions for PS MT E2E call setups

End-to-end perspectiveThe end-to-end perspective is defined as the data transferpathway from the User Equipment to the Packet Core Network.

Mobile terminated call A mobile terminated call is defined when the first messagehas been sent by the network towards the mobile.

In this case the first message is “RRC Paging Type 1”. It includes all pagingrepetitions as specified by Packet Core Network counter and timer.

Call attempt A call attempt is defined when the network has sent the “RRC PagingType 1” to the User Equipment.

Successful callA mobile terminated call is defined successful when the last messagebefore the speech or data phase start has been received.

In this case the last message is “SM Activate PDP Context Accept”.

Call setup success ratioThe Call setup success ratio is defined as the number ofsuccessful calls divided by the number of call attempts.

Call setup accessibility ratio The Call setup accessibility ratio is defined as theremainder ratio from the number of successful calls divided by the number of callattempts.

Formula

The end-to-end Call setup success ratio is defined as follows:

E2E PS MT Accessibility Ratio =UE(part) + NodeB (part) + RNC(part) + PS_CN(part) + Others

RRC Paging Type 11 -

E2E PS MT Call setup Success Ratio =SM Activate PDP Contect Accept

RRC Paging Type 1

UTRAN end-to-end key performance indicators

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

10-24 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 225: Umts Optimization Lucent

Signaling flow for PS MT E2E call setups

Figure 10-13 Paging and RRC connection establishment

RRC RRC

NBAPNBAP

NBAP NBAP

RRC RRC

RRC RRC

RRC connectionrequest (cause)

Radio Linksetup request

Radio Linksetup response

RRC connectionsetup response

RRC connectionsetup complete

Measurementcontrol RRCRRC

UEUu Iub

Node B RNC CNIu-ps

RRCconnectionestablishment

RANAPRANAP

RRCRRC

Paging

Paging

Paging Type 1

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in thePacket Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-25

Page 226: Umts Optimization Lucent

Figure 10-14 GMM attach

GMM attach(request)

RRC RRC

RRC RRC

RRC RRC

UEUu Iub

Node B RNC CNIu-ps

RANAPRANAP

RRCRRC

Directtransfer

Downlinkdirect transfer

Initial directtransfer

Directtransfer

Directtransfer

RANAPRANAPDirect

transfer

RRC RRC

RANAP RANAP

RANAP RANAPSecurity mode

command

Security modecommand

Security modecomplete

RANAP RANAPCommon

ID

RANAP RANAP

Downlinkdirect transfer

RRC RRC

Uplinkdirect transfer

RRC RRC

SCCP SCCP

SCCP SCCP

Initial directtransfer paging resp.

Connectionrequest

Connectionconfirm

RANAPRANAPInitial UEmessage

GMM pagingresponse

GMM attach(authenticationand ciphering)

Securitymode

GMM attach(accept)

GMM attach(complete)

RANAP RANAPSecurity mode

complete

RRC RRCInitial direct

transfer

RANAP RANAPInitial UEmessage

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in thePacket Switched domain

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

10-26 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 227: Umts Optimization Lucent

KPI for PS MT E2E call setups

PS-MT-E2E-call setup

KPI Parts

PS_MT_E2E_Call_Success SM Activate PDP Context Accept, comprising:

UE (part)

NodeB (part)

RNC (part)

PS_CN (part)

Interfaces (part)

Others

PS_MT_E2E_Call_Attempts RCC Connection Request

PS-MT-E2E-call setup

Parts Counters

UE (part) RRC_Fail(T_u300) + RRC_Fail(from_UE) +RB_Fail(from_UE) + RB_Fail (T_RB) + Rel_PS(T3350)+ Rel_PS(T3360) + Rel_PS(T3385)

Figure 10-15 RAB assignment and PDP context activation

RRC RRC

RRCRRCUplink

direct transfer

DirecttransferRANAP RANAP

Directtransfer

Radio Linkreconf.request

Radio Bearersetup response

RANAP RANAPRAB assignment

response

RANAP RANAP

Downlinkdirect transfer

RRC RRC

RANAP RANAP

RAB assignment

RAB assignmentrequest

Radio Linkreconf.request

NBAP

NBAP

NBAP

NBAP

Radio Bearersetup complete

RRC RRC

UEUu Iub

Node B RNC CNIu-ps

SMPDP contextactivation(request)

SMPDP contextactivation(accept)

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in thePacket Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-27

Page 228: Umts Optimization Lucent

PS-MT-E2E-call setup

Parts Counters

NodeB (part) RRC_Fail(Err_NodeB) + RRC_Fail(T_RLS) +Reject_RNC(RRC_code) + Reject_RNC(RRC_pwr) +RAB_Fail (code) + RAB_Fail (Pwr) + RAB_Fail(Err_NodeB) + RAB_Fail(T_RL_R) + NodeB_Errors

RNC (part) Sccp_Fail(Timer) + RAB_Fail(TRabAssg) + RNC_Errors

PS_CN (part) Reject_PS_CN. + Sccp_Fail(blckg) + Abnormal_Release_before_PDP_accept

Interfaces (part) Iu (Fail) + Iub (Fail) + Iur (Fail)

Others Any other call setup failure which excludes the abovementioned but occurs after RACH and before PDPcontext accept

KPI parts for E2E call setups

Parts Counters

UE (part) RRC.FailConnEstab.SetupIncomplete

RAB.FailEstab.RBSetupFail

RABFailEstab.T3

NodeB (part) SHO.FailRLSetupIubUTRANSide.NodeBRes

SHO.FailRLSetupIubUTRANSide.TransRes

RRC.FailConnEstab.RLSetupFailure

RRC.FailConnEstab.CAC

RRC.FailConnEstab.CAC

RABFailEstab.CodeStarv

RAB.FailEstabPSNoQueuing.DLIntfer

RNC (part) VS.RRC.FailConnEstab.ProcessorLoad

General KPI counters for end-to-end call setup

The following counters are valid for all end-to-end call setups:

Counter name Part Description

RRC.FailCon-nEstab.RLSetupFailure

Node B No response from NodeB for a signaling Radio linkallocation (Signaling Radio Bearer). This is the numberof T_RLS expiry.

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in thePacket Switched domain

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

10-28 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 229: Umts Optimization Lucent

Counter name Part Description

SHO.FailRLSetupI-ubUTRANSide.NodeBRes

SHO.FailRLSetupI-ubUTRANSide.TransRes

Node B Radio link setup failure response from NodeB for allcauses except code and power shortage for SRBallocation

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more code are available

RRC.FailConnEstab.CAC Node B Number of RRC connection reject that RNC sends to themobile because of no more power is available

RRC.FailConnEstab.Setu-pIncomplete

UE Number of T_U300 expiry no response from UE forRRC connection establishment

- UE Number of RRC connection setup failure responded byUE

RABFailEstab.CodeStarv Node B Number of RAB establishment failure because of nomore code are available

RAB.FailEstabPSNoQueu-ing.DLIntfer

Node B Number of RAB establishment failure because of nomore power is available

RABFailEstab.T3 UE Number of T_RB expiry no response from UE for RBSetup

RAB.FailEstab.-RBSetupFail

UE Number of RB setup failure received from UE

VS.RRC.FailConnEstab-.ProcessorLoad

RNC Number of Call setup failed due to internal RNC reasons

UTRAN end-to-end key performance indicators KPI for Mobile-terminated end-to-end call setup in thePacket Switched domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-29

Page 230: Umts Optimization Lucent

KPI for end-to-end call drops in the Packet Switched domain.................................................................................................................................................................................................................................

Overview

This gives an overview over the key performance indicators for the end-to-end calldrops in the Packet Switched domain (PS E2E).

Definitions for PS E2E call drops

End-to-end perspectiveThe end-to-end perspective is defined as the data transferpathway from the User Equipment to the Packet Core Network.

Call drop A call is defined as dropped message when an Iu release procedure isperformed after the“SM Activate PDP Context Accept” for abnormal call releasewith the “Iu Release complete” message.

Successful callA call is defined successful when the last message before the speechor data phase start has been sent towards the User Equipment.

In this case the last message is “SM Activate PDP Context Accept”.

Call retainability The Call retainability is defined as the number of call drops dividedby the number of call successful calls.

Formula

KPI for PS E2E call drop

The KPI for PS E2E comprise the following parts:

PS E2E call drop

KPI Parts

PS_MO_E2E_Call_Drop RF (part)

UE (part)

NodeB (part)

RNC (part)

PS_CN (part)

PS_MO_E2E_Call_Success SM Activate PDP Context Accept

UTRAN end-to-end key performance indicators

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

10-30 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 231: Umts Optimization Lucent

The KPI parts for PS E2E comprise the following counters:

PS E2E call drop

Parts Counters

RF (part) RAB.RelPS.Drop.DL_RLF

No. of call drop during hard handover inter-frequency

VS.IRATHO.TimeoutOutPSUTRAN

UE (part) RAB.Rel.Drop.UESigConnRel

NodeB (part) RAB.Rel.Drop.OpInterv

RNC (part) RAB.Rel.Drop.UETransDrnc

RAB.Rel.Drop.UEInactivity

PS_CN (part) SM.AttDeactPdpContextSgsn.38

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switcheddomain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-31

Page 232: Umts Optimization Lucent

Signaling flow

Figure 10-16 Normal PS E2E call release, mobile-originated and mobile-terminated.

UEUu Iub

Node B RNC CNIu-cs

Request

Complete

Accept

Request

Accept

Complete

SM deactivatePDP context

Directtransfer

RANAP RANAP

Directtransfer

RANAP RANAP

Uplinkdirect transfer

RRC RRC

RRC RRC

RRC RRC

Downlinkdirect transfer

Uplinkdirect transfer

Directtransfer

RANAP RANAP

Directtransfer

RANAP RANAP

Directtransfer

RANAP RANAP

Uplinkdirect transfer

RRC RRC

RRC RRC

RRC RRC

Downlinkdirect transfer

Uplinkdirect transfer

GMM detach

Directtransfer

RANAP RANAP

Iu Release

NBAPNBAP

NBAP NBAP

RRC RRC

RRC RRC

Radio Linkdeletion request

Radio Linkdeletion response

RRC Connectionrelelase

RRC Connectionrelease complete

Iu releasecommand

RANAP RANAP

Iu releasecomplete

RANAP RANAP

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switcheddomain

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

10-32 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 233: Umts Optimization Lucent

General KPI counters for end-to-end call drop

The following counters are valid for all end-to-end call drop:

Counter name Part Description

RAB.RelPS.Drop.DL_RLF RF Number of call drop because of Downlink radio linkfailure

RAB.RelCS.Voice.CauseRLF,RAB.RelCS.Data.Cau-seRLF

RF Number of call drop because of Uplink radio link failure

(Calculated) RF Number of call drop during hard handoverinter-frequency.

RAB.Rel.Drop.UESigCon-nRel

UE Number of call drop initiated by the UE.

RAB.Rel.Drop.OpInterv NodeB Number of call drop for NodeB generated reasons

Figure 10-17 PS E2E uplink radio link failure detection

Radio Linkdeletion

Noresponse

RRC

SCCPrelease

RANAP RANAPIu releasecomplete

RANAP RANAP

Radio Linkdeletion responseNBAP NBAP

Iu releasecommand

Radio Linkfailure indication

RANAP RANAPIu releaserequest

RANAP RANAP

Radio Linkdeletion request

NBAP

NBAP

NBAP

NBAP

UEUu Iub

Node B RNC CNIu-ps

Iu release

Figure 10-18 PS E2E downlink radio link failure detection

RRC RRC

RRC RRC

Cell update(”RL Failure”)

Cell updateconfirm

UEUu Iub

Node B RNC CNIu-ps

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switcheddomain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-33

Page 234: Umts Optimization Lucent

Counter name Part Description

RAB.Rel.Drop.UETransDrnc,RAB.Rel.Drop.UEInactivity,

RNC Number of call drop for RNC generated reasons.

Individual counters for PS E2E call drop

The following individual counters refer to the PS E2E call drop:

Counter name Part Description

VS.IRATHO.TimeoutOutP-SUTRAN

RF Number of call drop duringhard handover inter RAT

SM.AttDeactPdpContextSgsn.38 PS_CN Number of call drop for PS CNgenerated reasons

UTRAN end-to-end key performance indicators KPI for end-to-end call drops in the Packet Switcheddomain

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

10-34 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 235: Umts Optimization Lucent

KPIs for Quality of Service monitoring

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

Objectives

This lesson gives an overview over the key performance indicators (KPIs) for Qualityof Service (QoS) monitoring within the UTRAN cluster.

Contents

KPIs for Quality of Service monitoring in the CS domain 10-36

KPIs for Quality of Service monitoring in the PS domain 10-38

UTRAN end-to-end key performance indicators

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-35

Page 236: Umts Optimization Lucent

KPIs for Quality of Service monitoring in the CS domain.................................................................................................................................................................................................................................

Quality of Service

Quality of Service (QoS) is used to measure a specified set of performance attributesthat are typically associated with a particular service.

There are four different QoS classes which must be considered:

• Conversational class (for example voice)

• Streaming class (for example video, audio)

• Interactive class (for example web browsing)

• Background class (for example file transfer).

The most important measurable parameters used are:

• DelayThe interval between transmitting and receiving packets between two referencepoints.In this case the delay is referred to as “RAB setup time”.

• Delay variationIn this case the delay variations are referred to as “Achieved Bitrate distribution”and “Transfer delay distribution”.

• Loss rateIn this case the loss rates are referred to as “SDU error ratio” and “Residual biterror ratio”.

KPIs for QoS monitoring on network level

KPIs for QoS monitoring in the CS domain

per RAB (i) Conver-sational

Stream-ing

Delay in sec < 1 ~ 1

RAB(i) setup time without queuing X X

RAB(i) setup time with queuing X X

Achieved Bitrate distribution X X

Transfer delay X X

SDU Error Ratio - X

Residual Bit Error Ratio - X

UTRAN end-to-end key performance indicators

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

10-36 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 237: Umts Optimization Lucent

Formula

When more than one cell is the active set, for each cell the following KPI must beavailable per traffic class:

CS RAB Assignment Success Rate (i) =CS RAB Assignment Success (i)

CS RAB Assignment Attempt (i)

i = Traffic_Class (conversational, streaming)

UTRAN end-to-end key performance indicators KPIs for Quality of Service monitoring in the CS domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-37

Page 238: Umts Optimization Lucent

KPIs for Quality of Service monitoring in the PS domain.................................................................................................................................................................................................................................

Quality of Service

Quality of Service (QoS) is used to measure a specified set of performance attributesthat are typically associated with a particular service.

There are four different QoS classes which must be considered:

• Conversational class (for example voice)

• Streaming class (for example video, audio)

• Interactive class (for example web browsing)

• Background class (for example file transfer).

The most important measurable parameters used are:

• DelayThe interval between transmitting and receiving packets between two referencepoints.In this case the delay is referred to as “RAB setup time”.

• Delay variationIn this case the delay variations are referred to as “Achieved Bitrate distribution”and “Transfer delay distribution”.

• Loss rateIn this case the loss rates are referred to as “SDU error ratio” and “Residual biterror ratio”.

KPIs for QoS monitoring on network level

KPIs for QoS monitoring in PS domain

per RAB (i) Conver-sational

Stream-ing

Inter-active

Back-ground

Delay in sec < 1 ~ 1 < 10 > 10

RAB(i) setup time without queuing X X X X

RAB(i) setup time with queuing X X X X

AchievedBitrate distribution X X - -

Transfer delay X X - -

SDU Error Ratio X1 X1 X1 X1

Residual Bit Error Ratio X1 X1 X1 X1

Notes:

1. Not guaranteed values

UTRAN end-to-end key performance indicators

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

10-38 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 239: Umts Optimization Lucent

Formula

When more than one cell is the active set, for each cell the following KPI must beavailable per traffic class:

PS RAB Assignment Success Rate (i) =PS RAB Assignment Success (i)

PS RAB Assignment Attempt (i)

i = Traffic_Class (conversational, streaming, interactive, background)

UTRAN end-to-end key performance indicators KPIs for Quality of Service monitoring in the PS domain

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

10-39

Page 240: Umts Optimization Lucent

Exercises.................................................................................................................................................................................................................................

Exercises

1 Give a possible reason for a poor success rate of the PS_MO_E2E_Call_SuccessKPI.

a High DL BLER values

b High number of call drops

c Cell reselection failures

d Iub links down

4

2 How is the CS_MT_E2E_Call_Success ratio calculated?

a SM Activate PDP Context Accept / RRC Connection Request

b SM Activate PDP Context Accept / RAB Failure Sum

c CC Alerting / RRC Paging Type 1

d CC Alerting / RRC Connection Request

3

UTRAN end-to-end key performance indicators

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

10-40 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005

Page 241: Umts Optimization Lucent

Index

A Around-the-corner problem,3-1

Average transmitted carrier power,6-20, 6-32

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

B BLER, 8-2

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

C Call availability, 6-4

Cell breathing problem,3-1

ChannelOccupRatePCH,6-26

ChannelOccupRateRACH,6-14

CSD Accessibility rate,6-6

CSV Accessibility rate,6-6

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

D Definition of optimization,1-2

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

F Forward power overload duration,6-20

Forward Power Overload Duration,6-32

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

H Handover problem,3-1

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

K KPI, 2-3

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

L Lucent Retainability KPI CSD,7-18

Lucent Retainability KPI CSV,7-18

Lucent Retainability KPI PSD,7-18

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

M Maximum received signal strength indicator,6-20,6-32

Maximum transmitted carrier power,6-32

Missing neighbors problem,3-1

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

N N300, 6-14

Near-far problem,3-1

Not optimizing

Consequences,1-4

NumBadRACHTransBlock,6-14

NumCellUpdateRequest.CellReselect,6-12

NumGoodRACHTransBlock,6-14

NumPageAttDiscard,6-26

NumRABEstFail.CodeStarv,6-36

NumRABEstFail.Load,6-32

NumRABEstFail.RBSetupFailure,6-34

NumRABEstFail.T3,6-34, 6-35

NumRLReconfigAtt,6-33

NumRLReconfigFail.sum,6-33

NumRRCConnAtt,6-14

NumRRCConnEstFail,6-18, 6-23

NumRRCConnRej,6-18, 6-20

NumUraUpdateRequest.UraChange,6-12

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

O Optimization costs,1-2

Optimization requirements,1-2

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

P Pilot pollution problem,3-1

PSD Accessibility rate,6-6

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

UM4801-IG.en.A4Issue a, October 2005

Lucent Technologies - ProprietarySee notice on first page

IN-1

Page 242: Umts Optimization Lucent

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

R RAB dropping rate for CS data,7-18

RAB dropping rate for CSV12,7-18

RAB dropping rate for PS,7-18

RAB establishment,6-29

Reasons for optimization,1-4

RF coverage problem,3-1

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

S successful RRC connections establishment rate,6-18

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

T T300, 6-14

Total number of RAB establishment failures,6-29

Total RAB dropping rate,7-2

Total RAB establishment success rate,6-29

T_RL_RESYNC,7-2

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

U uERadioBearerSetupResponse,6-34

UL transport block error rate CSD,8-2

UL transport block error rate CSV,8-2

UL transport block error rate PS,8-2

Index

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

IN-2 Lucent Technologies - ProprietarySee notice on first page

UM4801-IG.en.A4Issue a, October 2005