You are on page 1of 226

See notice on first age

PRELIMINARY

UMTS
UTRAN Optimization
UMTS-03.03

401-382-810R03.03
Issue 0.1
June 2006

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved

PRELIMINARY

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.

PRELIMINARY

See notice on first age

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

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

Every effort has been made to ensure that the information contained in this document was complete and accurate at the time of printing.
Nevertheless, the authors retain the right to modify the information. This customer document describes all the hardware units and functions
known at the present time. Descriptions may be included for units which are not present at the customer site. The exact scope of delivery is
described in the respective purchase contract.
Conformance statements

There are no in-country requirements that are applicable for this Information Product.
Ordering information

The order number for this information product is 401-382-810R03.03.


To order documentation from an order entry representative use one of the following numbers:
Within the United States, call 1-888-582-3688 or send email to cicorders@lucent.com (to fax an order, call 1-800-566-9568).
Within Canada, call 1-317-322-6616 or send email to cicorders@lucent.com.
International, call 1-317-322-6416 or send email to intlorders@lucent.com (to fax an order, call 1-317-322-6699).
Technical support

Contact your local Lucent Technologies Customer Service Organization representative if you wish to report errors or questions regarding the
product. If you are unable to locate a customer service center, contact Lucent Technologies at the following fax number:
GSM/UMTS Wireless Technical Support Center.
Telefax +49 911 526 3198
Information product support

Contact your local Lucent Technologies Customer Service Organization representative if you wish to report errors or questions regarding the
contents of this document. If you are unable to locate a customer service center, contact Lucent Technologies at the following fax number:
GSM/UMTS Wireless Technical Support Center.

PRELIMINARY

Telefax +49 911 526 3198

Lucent Technologies - Proprietary


See notice on first page

PRELIMINARY

Contents

About this information product


Purpose

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

Reason for reissue

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

xi
xi

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

xi

Conventions used

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

xi

Systems supported

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

xi

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

xi

How to use this information product

Related training

How to comment

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

xii

Part I: Optimization concepts


1

Introduction to optimization
Overview

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

What is optimization?

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

Why optimize a network ?

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

When to optimize a network ?


2

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

1-1
1-2
1-4
1-6

Information sources and tools


Gathering information
Overview

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

2-2

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

2-3

Customer complaints

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

2-6

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
iii
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

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

Key Performance Indicators


Drive test

2-1

PRELIMINARY

Contents

OMC-UPS tools

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

2-7

Analyzing information
Overview

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

Data analysis software

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

Lucent Technologies optimization and design tools


3

2-10
2-13

Common optimization problems and their solutions


Overview

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

RF coverage problem

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

3-1
3-2

Cell breathing problem

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

3-4

Pilot pollution problem

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

3-6

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

3-8

Near-far problem

Around-the-corner problem
Handover problem

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

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

Missing neighbors problem


4

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

2-9

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

3-9

3-10
3-11

UTRAN Signaling
Overview

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

4-1

Protocol architecture of the air interface


Overview

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

Protocols of the air interface

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

4-4

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

4-6

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

4-8

Radio interface protocol architecture


Service access points

4-3

Air interface channels

PRELIMINARY

Overview

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

Physical channels

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

4-12

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

4-18

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

4-20

Transport channels
Logical channels

4-11

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

iv

Air interface protocols


Overview

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

4-23

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

4-27

Medium Access Control


Radio Link Control

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

4-30

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

4-31

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

4-34

Packet Data Convergence Protocol (PDCP)


Radio Resource Control
RRC State Machine

4-22

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

4-35

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

4-36

RRC Connection and Signaling Connection


Signaling radio bearers

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

4-40

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

4-44

Radio bearer establishment

PRELIMINARY

Contents

UTRAN protocols
Overview

Iub protocol structure

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

4-47

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

4-50

Protocols of the Iub interface


Iur interface

4-45

Iu-cs interface

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

4-52

Part II: Optimization process


5

Drive testing
Overview

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

Drive test optimization process

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

5-4

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

5-6

Perform cluster optimization

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

5-8

5-11

Optimization process
Overview

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

6-1

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
v
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Perform system verification


6

5-2

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

Planning and preparation (site readiness)


Optimization planning

5-1

PRELIMINARY

Contents

Lifecycle

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

Optimization process phases

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

6-2
6-4

Planning and preparation (site readiness)

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

6-8

Drive test optimization before live traffic

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

6-9

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

6-11

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

6-12

Information gathering
Information analysis

Part III: Optimization and troubleshooting


7

UTRAN end-to-end key performance indicators


Overview

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

7-1

KPIs for the Circuit Switched domain


Overview

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

7-3
7-4

KPI for Mobile-originated end-to-end call setup in the Circuit Switched domain

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

KPI for Mobile-terminated end-to-end call setup in the Circuit Switched domain

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

7-10

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

7-16

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

7-21

KPI for end-to-end call drops in the Circuit Switched domain


KPIs for the Packet Switched domain
Overview

KPI for Mobile-originated end-to-end call setup in the Packet Switched domain

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

7-22

KPI for Mobile-terminated end-to-end call setup in the Packet Switched domain

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

7-28

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

7-34

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

7-39

KPI for end-to-end call drops in the Packet Switched domain


KPIs for Quality of Service monitoring

PRELIMINARY

Overview

KPIs for Quality of Service monitoring in the CS domain

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

7-40

KPIs for Quality of Service monitoring in the PS domain

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

7-42

Call availability and optimization


Overview

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

8-1

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

vi

Call availability
Overview

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

Call availability

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

8-2
8-3

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

8-5

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

8-6

Determination of accessibility problem

PRELIMINARY

Contents

Network level accessibility


Overview

Introduction

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

Cell re-selection failures

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

RACH access procedure failures

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

8-7
8-8
8-9

RRC connection establishment analysis


Overview

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

8-12

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

8-14

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

8-15

Introduction to RRC connection establishment


Call admission control failures
Radio link setup analysis

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

8-16

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

8-17

RRC connection setup failure


Paging failures

8-11

RAB establishment analysis


Overview

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

Introduction

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

Dynamic bearer control failures

8-19
8-22

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

8-23

Radio bearer establishment failures

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

8-24

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

8-25

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

8-26

Code starvation
Call reliability
Overview

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

9-1

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
vii
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Radio link reconfiguration failures

No answer from UE

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

8-18

PRELIMINARY

Contents

Call reliability
Overview

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

Dropped calls analysis

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

9-2
9-3

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

9-6

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

9-9

Radio link failures analysis due to synchronization issues


Network level retainability
Overview

Network level retainability KPIs


10

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

9-10

Call quality and optimization


Overview

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

10-1

Call quality
Overview

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

Network level quality KPIs

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

10-2
10-3

Glossary

PRELIMINARY

Index

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

viii

PRELIMINARY

List of figures

Part III: Optimization and troubleshooting


7

UTRAN end-to-end key performance indicators


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

7-5

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

7-5

RRC connection establishment

7-2

MM and authentication

7-3

RAB assignment and call connect

7-4

RRC connection establishment

7-5

MM and authentication

7-6

RAB assignment and call connect

7-7

Normal CS E2E call release, mobile-originated and mobile-terminated

7-8

CS E2E uplink radio link failure detection

7-9

CS E2E downlink radio link failure detection

7-10

RRC connection establishment

7-11

GMM attach

7-12

RAB assignement and PDP context activation

7-13

Paging and RRC connection establishment

7-14

GMM attach

7-15

RAB assignment and PDP context activation

7-16

Normal PS E2E call release, mobile-originated and mobile-terminated.

7-17

PS E2E uplink radio link failure detection

7-18

PS E2E downlink radio link failure detection

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

7-6

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

7-11

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

7-11

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

7-12

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

7-18

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

7-18

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

7-19

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

7-23

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

7-23

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

7-24

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

7-29

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

7-29

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

7-30

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

7-36

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

7-36

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

7-37

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
ix
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

7-1

PRELIMINARY

PRELIMINARY

About this information product

PRELIMINARY

About this information product

Purpose

This document describes the methods to perform an optimization of the UTRAN


Network based on performance indicators and drive tests. These include:

identification of sources of performance data,


description of drive testing equipment, methods and tool
identification of performance data and traffic measurements to locate trouble spots
solutions for improving the performance
evaluation of the effectiveness of counter measures.

Reason for reissue

This is the first issue of this document.


How to use this information product

Use this documentation as a guidance for the preparation of optimization tasks in the
UTRAN Network. Use it in combination with the latest user documentation.
Conventions used

Acronyms are explained on their first appearance in the text.


Systems supported

This document applies to Lucent Technologies UMTS System Release 03.03.


Related training

The following related courses are available:


UMTS System Introduction, UM1001
UMTS Hardware Overview, UM1911
UTRAN Signaling, UM4304

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
xi
Issue 0.1, June 2006
See notice on first page
,

PRELIMINARY

PRELIMINARY
PRELIMINARY

About this information product

UTRAN Processes and Parameter Settings, UM4305

UTRAN RF Cellular Engineering, UM4301.

How to comment

To comment on this information product, go to the Online Comment Form


(http://www.lucent-info.com/comments/enus/) or e-mail your comments to the
Comments Hotline (comments@lucent.com).

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006
,

xii

PRELIMINARY

Part I: Optimization concepts

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 1, Introduction to optimization

1-1

Chapter 2, Information sources and tools

2-1

Chapter 3, Common optimization problems and their solutions

3-1

Chapter 4, UTRAN Signaling

4-1

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
I-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

PRELIMINARY

I ntroduction to optimization
1

Overview
...................................................................................................................................................................................................................................
Purpose

This chapter provides an introduction to the concepts of optimization. It explains what


optimization is, why optimization is performed and when optimization must be
performed.
Contents
What is optimization?

1-2

Why optimize a network ?

1-4

When to optimize a network ?

1-6

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
1-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Introduction to optimization

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 operate
according 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 network
does not have many parameters or variables that can be changed to increase the
effectiveness of the network.
Requirements

By optimizing a network, an operator tries to find the best configuration and use of the
network. This strongly depends on the requirements that an operator has and the
priorities an operator assigns to these requirements.
Requirements can relate to:

Quality of service
Traffic expectations and predictions
Coverage area
Capacity
Current and future business strategies (network expansion, market shares,
profitability levels).

Requirements and costs

An operator weighs the requirements against the costs that are involved to meet the
requirements and the priorities of the requirements. An operator could probably meet
many requirements, but the costs involved would be very large.

PRELIMINARY

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.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

1-2

What is optimization?

Finding compromises

Requirements for a network often contradict each other. Improving a network to meet
one requirement can introduce a problem for another requirement. Optimization
therefore usually involves finding a compromise (or trade-off) between different
requirements. When an engineer makes a choice for implementing a solution, all
requirements an operator has must be kept in mind.

PRELIMINARY

Introduction to optimization

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 increases
interference. An operator must decide what is more important and implement a solution
that reflects that decision.
What is not optimization

Optimization does not include all actions that make a network work better. Fault
management 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. Before
starting the optimization of a network or trying to solve an optimization problem, an
engineer must ensure that a problem is not caused by an error or fault.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
1-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Introduction to optimization

Why
optimize a network ?
...................................................................................................................................................................................................................................
Goal of optimization

The goal of optimization is to fine-tune an existing network to meet the requirements


of an operator in the most efficient way.
Important! Optimization of an existing network must not be used to correct a bad
network design.
Reasons for optimization

Optimization is needed because a network is never perfect. It never fully complies to


the requirements of an operator.
Optimization is needed because of:
Reason

Example

Deviations from (planning) assumptions

Changes in subscriber behavior (increased


use of a service or a cell)

Changes in operator requirements

Increased market share, introduction of


new service

Changes in environment

New buildings, snowfall, trees

Most of these reasons can not be prevented or can only be prevented partially. Good
models (for example for traffic behavior and forecasts) can help predict changes and
thus help in designing and optimizing networks.
Consequences of not optimizing

Not optimizing a network means the goals of optimization are not met and the network
does 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 these
requirements in the most efficient way costs an operator money. By optimizing the
network, the same requirements could be met with fewer resources.
Not optimizing the network will cost money, related to:

PRELIMINARY

Subscribers, in missed revenue because of blocked calls or subscribers changing to


other operators
Operational and maintenance costs.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

1-4

Why optimize a network ?

Subscribers

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

Blocked calls
Dropped calls
Smaller RF coverage area
Lower voice quality
Lower data rates.

PRELIMINARY

Introduction to optimization

Blocked calls are a direct loss of revenue for an operator. Poor network quality can be
a reason for existing subscribers to change to another operator and for potential
customers to subscribe to competitors.
Operational costs

A network that is not optimized is more expensive to operate. The equipment is not
used effectively, so more equipment is needed. The extra equipment increases
maintenance and operational costs.
Also more errors and problems can be expected in a network that is not optimized.
This increases the costs of fault management.
Result of optimization

An optimized network increases network coverage and network capacity.


This directly translates into:

Lower operational and maintenance costs


Higher number of voice and data users
Higher average data throughputs
Higher Quality of Service for voice and data users.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
1-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Introduction to optimization

When
to optimize a network ?
...................................................................................................................................................................................................................................
Phases when optimization takes place

Optimization during the network life cycle:

Network design

Planning

Optimization

Implementation

Acceptance
criteria met?
Y

Network design
& implementation
Live network

In service
optimization

Optimization is performed:

Before a commercial network launch


In a live, operational network.

Before a commercial network launch, typical optimization includes:

Network design optimization


Optimization based on drive testing.

PRELIMINARY

This document covers in service optimization in a live, operational network, even


though optimization methods and tools are similar during both phases.
Always

The environment in which a network operates is always changing, so the network itself
must always change too, adapting to the changes that take place. There are always
reasons for optimization, therefore optimization in a live network never stops.
...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

1-6

When to optimize a network ?

Optimization is always needed because there are always:

Deviations from (planning) assumptions


Changes in subscriber behavior
Changes in operator requirements
Changes in environment.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
1-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Introduction to optimization

PRELIMINARY

PRELIMINARY

PRELIMINARY

I nformation sources and tools


2

Gathering information
Overview
...................................................................................................................................................................................................................................
Purpose

This section provides information on tools and information sources that are used to
gather information that is used in the optimization process.
This section describes the use of:

Customer complaints
Drive testing
Key Performance Indicators.

Other tools

Protocol analyzers can also be used to gather performance data. Protocol analyzers can
be used to monitor and count messages on interfaces in the network. Protocol analyzers
are available from many different vendors.
Contents
2-2

Drive test

2-3

Customer complaints

2-6

OMC-UPS tools

2-7

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Key Performance Indicators

PRELIMINARY

Information sources and tools

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

Key Performance Indicator (KPI) are calculated using measurements that are gathered
by the OMC-UPS. The KPIs are used to determine if the network complies to the
levels of performance that are needed.
Key Performance Indicator (KPI) play an important role in detecting (optimization)
problems. Changes in values of the key performance indicators, especially reaching
thresholds, are often the first indication of an optimization problem.
A KPI value can change suddenly, or gradually, but both types of change can be an
indication that optimization is needed.
Available KPIs

For detailed information on all the available KPIs, refer to UMTS Performance
Measurement Definitions Manual, 401-382-803-0103.
KPIs that can be indication of a performance problem, that needs optimization, are:

Handover failure rates


Channel occupancy rates
Dropped RRC connections rate
RAB failure rates
Radio link dropping rates.

Detected problems

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

PRELIMINARY

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.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-2

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)

PRELIMINARY

Information sources and tools

When to perform

Drive test are performed during network deployment and in a live network. During
network deployment drive tests are used to check basic cell operation and to ensure
clusters and the network meets customer requirements.
During optimization in a live network, drive tests recheck cell performance. During
these test, neighboring cells must be operational, so cell selection, interference
measurements and hand overs can be performed and tested.
After implementing a solution to correct an (optimization) problem, a drive test can be
performed to check if the problem is solved.
Regular drive tests are also a method for preventive maintenance to detect areas where
services are degrading.
Components

Components of a typical drive test system (picture provided courtesy of Agilent


Technologies):

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Information sources and tools

Drive test

Components of a drive test system are:

UMTS scanner/receiver
UMTS antenna
PC with software for logging the data
UMTS terminal
Vehicle with location/positioning equipment (for example GPS).

Detecting problems

PRELIMINARY

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.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-4

Drive test

Analyzing drive test data

Data that is gathered during a drive test can be displayed in real time or stored on the
PC for off-line analysis.
The information must be analyzed to check for performance problems, that can be
solved by network optimization.

PRELIMINARY

Information sources and tools

Automated tools are needed because a large volume of information is collected.


Automated tools help to sort out the information and draw conclusions from the
information.
Analysis tools can project the collected data on a map that includes characteristics of
the terrain. On the map, details are shown such as coverage strength, and locations
where handovers, cell reselections or dropped calls occur.
This information is used to identify problems and the locations where the problems
occur.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Information sources and tools

Customer
complaints
...................................................................................................................................................................................................................................
Use of customer complaints

Customer complaints can provide an indication of problems. Especially if multiple


complaints can be related to one source. Customer complaints can point to a problem
on a specific location, time or related to a resource.
A customer complaint can be the trigger for further investigation using KPIs or drive
testing.
Trouble tickets

Customer complaints are typically documented as trouble tickets. The form of trouble
tickets (electronic, paper) and the way trouble tickets are stored and handled differs
between operators.
Trouble ticket information

Trouble tickets typically contain the following information:

UE type and model


Type of problem (for example dropped call, poor quality)
Time and place of the problem.

Example

Customers complain regularly about dropped calls in a certain location. Dropped calls
can be an indication of an RF coverage gap or a neighboring cell list problem. So
further investigation of the problem is needed.
Further investigation can determine that the dropped calls always occur when there is a
lot of traffic in the cell. The problem can be the result of an RF coverage gap because
of cell breathing.
Detected problems

PRELIMINARY

Although customer complaints are often not very specific, they can be helpful to detect
all optimization problems.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-6

OMC-UPS
tools
...................................................................................................................................................................................................................................
OMC-UPS tools

The OMC-UPS offers the following tools that can be used in gathering information for
optimization:

PRELIMINARY

Information sources and tools

RF call trace
OCNS.

RF call trace

RF call trace gathers radio related information associated to one or more cells. RF call
trace collects signaling messages on the Uu, Iub and Iu interfaces.
When a RF call trace is activated for a UE, information about calls established by that
UE is collected, as long as the UE is connected to the tracing RNC. The information is
composed of measurements performed at the UE, the NodeB and the RNC. All
measurements are stored at the RNC until the OMC-UPS requests a transfer to the
OMC-UPS.
Use of RF call trace

The operator can use information from RF call traces to:

Verify call establishment


Check performance and maintenance of radio links
Check radio link quality and coverage.

OCNS

Orthogonal Channel Noise Simulator (OCNS) is a tool that simulates traffic on the
downlink. OCNS is activated on the OMC-UPS and generates downlink interference to
simulate traffic.
The OMC-UPS administrator can define characteristics of the simulated traffic such as
mode of operation (voice or data), number of users and average power of users.
Use of OCNS

OCNS is a tool that is normally used in a network without traffic. OCNS simulates
traffic during testing before a network is live.

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

OCNS can also be used to generate additional traffic in a live cell, simulating heavier
traffic loads.

PRELIMINARY
PRELIMINARY

Information sources and tools

OMC-UPS tools

Detected problems

RF Call trace can be useful to detect all optimization problems.


OCNS can be useful to detect:

Cell breathing.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-8

Analyzing information
Overview
...................................................................................................................................................................................................................................

PRELIMINARY

Information sources and tools

Purpose

This section provides information about tools that can be used during optimization.
Contents
Data analysis software

2-10

Lucent Technologies optimization and design tools

2-13

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Information sources and tools

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

Data analysis software is needed to process data, because a large volume of


information is collected. The software helps to sort out the information, present it to an
engineer and helps the engineer to draw conclusions.
The software also allows an operator to show the consequences of changes that are
made to the network.
Data analysis software is used in:

Network design optimization


Live network performance optimization.

Inputs for analysis software tools

Data analysis tools can project the collected data on a map that includes characteristics
of the terrain. On the map, details are shown such as coverage strength, and locations
where handovers, cell reselections or dropped calls occur.
To show and analyze information, inputs are needed such as:

Maps (with terrain features and roads)


Location and orientation of sites
Parameter settings for cells, antennas and sites (power, antenna tilts)
Drive test data
Performance measurements.

Benefits of data analysis software

Data analysis software helps an engineer to:

Identify and locate a problem


Determine the source of a problem
Find solutions
Predict the effects of implementing a solution.

PRELIMINARY

Predict effect of changes

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

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-10

Data analysis software

Output of analysis tools

Data analysis tools can provide output on performance in different forms, but most
commonly used are outputs in tables and graphical outputs. Especially graphical output
clearly shows problem areas in a network.
Typical output from data analysis software and illustrates a network before and after
optimization:

Before optimization

PRELIMINARY

Information sources and tools

Optimizated design

The dark lines indicate areas that have no coverage. Changes in the shade of the
antennas indicate changes in antenna tilt.

Many tools are available for analyzing information. The main input for many
commercially available analysis software tool is drive test data. But also other inputs
can be used.
....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Analysis tool availability

PRELIMINARY

Information sources and tools

Besides commercially availlable software tools also many proprietary tools.


Key capabilities

must have .
To be able to handle the large volumes of data from many sources with different
formats, data analysis tools must support key capabilities such as:

PRELIMINARY

Data analysis software

Interfaces to different vendors of drive test equipment, protocol analyzers and


measurement programs
Open interfaces
Multiple technologies
Interfaces to databases to retrieve and store data
Synchronization of data from different sources to remove timing variations
Database querying and filtering to reduce data volumes.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-12

Lucent
Technologies optimization and design tools
...................................................................................................................................................................................................................................
This topic gives an overview of tools, developed by Lucent Technologies, that are used
in optimization and design of 3G networks.
LCAT

PRELIMINARY

Information sources and tools

LCAT is the Lucent Cells Application Tool. It is a tools that allows an engineer to
define cells and sectors.
LCAT information as input for LDAT and SPAT3G.
LDAT3G

Lucent Data Analysis Tool for 3G (LDAT3G) is an application for performing RF


analysis of drive test data for IS-95, 3G CDMA, 1xEV-DO, and UMTS systems. Used
for initial optimization of deployed network.
Drive test data, RF Call Trace, Cell Diagnostic Monitor, Packrat, and WINDS are
supported.
SPAT3G

Service Performance Analysis Tool for 3G (SPAT3G) is a tool that can be used to
quickly troubleshoot and improve network performance. It gives you easy access to a
wealth of information at the system, cell, face, and carrier level that can be displayed
graphically or in tabular formats. SPAT3G is used to optimize a live network and not
during initial optimization.
SPAT3G:

Displays of performance metrics for all network entities at different report levels
(ECP, Cell, Face, Carrier, and IWF/PCF).
Provides data trending for a metric or multiple metrics in a single chart per system,
cell, face, and carrier. SPAT3G also provides peg trending at the system, cell, face,
and carrier levels, allowing more detailed analysis.
Provides ROP Analysis, Metric and Service Measurement Trending, or Service
Measurements data, as well as FCIAlert, Handoff Matrix, and UNL data by right
clicking on a cell site
Displays handoff matrix data on a map display showing handoff relationships
between sites.

AirPro is an RF planning tool that is used to design wireless systems. AirPro can be
used in the designs of new wireless networks, networks migrating from older
generation to newer generation and existing network optimization. AirPro includes RF
propagation analysis, interference prediction, RF optimization, and utilities that help
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
2-13
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

AirPro

PRELIMINARY

Information sources and tools

Lucent Technologies optimization and design tools

you create and manage system designs for mobile systems in diverse operating
environments
Ocelot

Ocelot is used to optimize tilt, azimuth and power levels of antennas in a scenario to
get best coverage and capacity from the network. The benefit of using Ocelot for
optimization is reduced dependence on drive testing required for calibrating the design
parameters and post deployment optimization using service measurements.
In post deployment optimization, Ocelot is used in:

PRELIMINARY

Moving traffic from heavily-loaded sectors to more lightly-loaded sectors (traffic


balancing)
Reducing the amount of soft- and softer-handoff traffic
Reducing the average power per user.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

2-14

3 ommon optimization problems


C
and their solutions

PRELIMINARY

Overview
...................................................................................................................................................................................................................................
Purpose

This lesson describes typical problem areas that can be addressed by optimization and
provides possible solutions for the problem.
For each problem, the topic provides:

Description and definition of the problem


How the problem shows itself in a network
Consequences for the network and the users
Useful tools and information sources
Possible solutions.

Since optimization usually is a trade-off, keep in mind that the possible solutions that
are given may solve that particular problem, but at the same time may introduce a
problem elsewhere.
Contents
RF coverage problem

3-2

Cell breathing problem

3-4

Pilot pollution problem

3-6

Near-far problem

3-8

Around-the-corner problem

3-9
3-10

Missing neighbors problem

3-11

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
3-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Handover problem

PRELIMINARY

Common optimization problems and their solutions

RF
coverage problem
...................................................................................................................................................................................................................................
Definition

The RF coverage area is the area where two conditions are met:

Pathloss < maximum allowed pathloss


Ec/Io > minimum signal-to-noise ratio.

Pathloss and Ec/Io depend on the services and quality that is defined for a network and
can be checked using drive tests. The user equipment receive power is not an accurate
measure of pathloss for spread spectrum technologies. The user equipment may have
strong receive power due to many overlapping sectors but no pilot fulfills the above
mentioned coverage conditions. Therefore the Ec/Io ratio and the Ec signal strength
(connected to the pathloss) of the Primary Common Pilot Channel are used as an
accurate measures for the RF coverage.
Optimization goal

The goal is to close RF coverage gaps and maximize RF coverage. Or to be more


precise, maximize RF coverage, while continuing to comply to other requirements.
Because increasing RF coverage must not mean other requirements such as interference
levels can not be met anymore.
If RF coverage gaps can not be closed, it may be possible to move an RF coverage
gap from an area with high traffic volumes to an area with low traffic volumes. This
does not solve the RF coverage problem itself, but lowers the impact of a gap.
Detection of the problem

There are several ways in which RF coverage problems show themselves in the
network.
These include:

Dropped calls
Failed handovers.

Information sources

PRELIMINARY

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

Drive test
Key performance indicators
Customer complaints.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

3-2

RF coverage problem

Possible solutions

Possible solutions for RF coverage problems are:

Antenna tilt or reorientation


Power increase
New antenna or new cell site.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
3-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Common optimization problems and their solutions

PRELIMINARY

Common optimization problems and their solutions

Cell
breathing problem
...................................................................................................................................................................................................................................
Definition

Cell breathing is the growing and shrinking of an RF coverage area, depending on the
network load.
An increase of the network load increases network interference. Higher interference
lowers the quality of service especially at the initial cell coverage border and thus the
coverage area shrinks. To remain connected, power levels must increase. When power
can not be increased further, a handover is needed.
A low network load leads to low network interference, which increases the cell
coverage. This can result in neighboring cells not being used because the mobiles stay
connected to the original cell and no handovers occur.
Cell breathing:

Cell at 30 % capacity
Cell at 60 % capacity

Traffic needed during optimization

PRELIMINARY

Cell breathing occurs when the network is loaded, so RF optimization must be


performed on a loaded network. The network can be loaded with live traffic or
simulated traffic.
To simulate (additional) traffic on the downlink, the Orthogonal Channel Noise
Simulator (OCNS) can be activated on the OMC_UPS to generate downlink
interference. On the uplink, an attenuator attached to the user equipment simulates the
loading.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

3-4

Cell breathing problem

Optimization goal

The goal is to ensure that high load situations do not lead to RF coverage gaps. At the
same time, low load situations should not create large overlaps in cell coverage, which
may lead to pilot pollution or unwanted handover behavior.
In both high and low load situations, the network must have sufficient coverage and
the network must be used efficiently.

PRELIMINARY

Common optimization problems and their solutions

Detection of the problem

There are several ways in which cell breathing problems show themselves in the
network.
These include:

Dropped calls
Poor quality, especially at cell edges (during high traffic loads)
Appearance of RF coverage gaps (during high traffic loads)
Failed handovers
No handover to neighboring cells (during low traffic loads)
Excessive or unexpected handovers (during high traffic loads)
Pilot pollution (during low traffic loads).

Information sources

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

Drive tests
Key performance indicators
Customer complaints.

Possible solutions

Possible solutions for cell breathing are:

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
3-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Increase coverage area:


Antenna downtilt or reorientation
Power increase.
New antenna or new cell site.
Change handover parameters
Change neighboring cell list.

PRELIMINARY

Common optimization problems and their solutions

Pilot
pollution problem
...................................................................................................................................................................................................................................
Definition

Pilot pollution is interference caused by overlapping pilots with similar signal


strengths.
The lack of a dominant pilot causes low Ec/Io ratios. Problem areas with low Ec/Io
ratios may be misinterpreted as pilot pollution areas and lead to iterative drive testing
and unnecessary parameter changes in attempts to establish a dominant pilot.
If a pilot has:

Insufficient Ec signal strength (extensive pathloss), the problem area is considered


as a RF coverage hole
Sufficient Ec signal strength (low pathloss), the problem area has pilot pollution.

An optimization engineer needs to determine whether the Ec/Io ratio is poor due to
excessive pathloss or pilot pollution.
Pilot pollution is also considered if the number of present pilots is greater than the
actual active set size of the user equipment. Present pilots which cannot be added into
the active set cause interference.
Another aspect for interference is multipath reception. Each received pilot is
accompanied by 2-3 strong multipaths. The user equipment uses a rake receiver to
exploit multipath reception. Since the rake receiver has a limited number of fingers,
unused multipaths act as interference. Consequently, a six-finger rake receiver is fully
occupied when receiving three pilots (each with 2 multipaths). Any additional pilots
and multipaths are interference. Common trouble spots are bridges, upper floors in
buildings, elevated highways, street intersections, and large bodies of water.
Optimization goal

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

PRELIMINARY

Detection of the problem

There are several ways in which pilot pollution problems show themselves in the
network.
These include:

Dropped calls
Handover failures

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

3-6

Increased interference

Decreased capacity.

Pilot pollution problem

Information sources

The following information sources are used to detect pilot pollution problems:

Drive tests.

PRELIMINARY

Common optimization problems and their solutions

Possible solutions

Possible solutions for pilot pollution problems are:

Antenna tilt and azimuth rotation


P-CPICH channel power changes
Change neighboring cell lists.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
3-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Common optimization problems and their solutions

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

Near-far problems occur when user equipment near the cell site transmits on high
power. This creates excessive interference for user equipment that is located far away
from the cell site.
Optimization goal

The goal of the cell site is to receive all user equipment at equal signal strengths.
Therefore power control must be tightly controlled. Fast closed loop power control is
needed to direct mobiles to power up or power down very quickly. The optimization
goal is to ensure that all power control algorithms are working properly. Power control
parameters are tuned only when there are obvious power control failures.
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:

PRELIMINARY

Changing power control parameters.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

3-8

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

Around-the-corner problems occur when user equipment travels beyond an obstruction


and if there is significant downlink interference from a new sector with low pathloss.
The downlink degrades momentarily until the handover is performed or the downlink
power control reacts to compensate the interference.

PRELIMINARY

Common optimization problems and their solutions

When the user equipment goes into handover with the new cell site, fast power control
is needed to quickly reduce cell site transmit power.
The around-the-corner problem is a continual and unavoidable issue. Known trouble
spots are elevated highways and street intersections.
Optimization goal

The goal is to optimize the power control mechanism.


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

There are several ways in which around-the-corner problems show themselves in the
network.
These include:

High interference
Unusual handover behavior.

Information sources

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

Drive tests
Key performance indicators.

Possible solutions

Possible solutions for around-the-corner problems are:

Changing power control parameters


Changing handover parameters.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
3-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Common optimization problems and their solutions

Handover
problem
...................................................................................................................................................................................................................................
Definition

Unnecessary delays in handovers may cause uplink/downlink interference. Quick


handovers are required when there are rapid changes in pathloss between the user
equipment and the sector due to fading. Also, unnecessary handovers due
non-contiguous UMTS coverage or pilot pollution lead to excessive handover activity.
Optimization goal

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


and timers.
Handovers require signaling resources, and increase downlink interference, so
excessive handover activity must be minimized. Time delays due to resource allocation
(channel units, transmission links to RNC, OVSF codes) degrade call quality and
reduce the throughput of data calls.
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:

PRELIMINARY

Adjust handover parameters


Change the neighboring cell list.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

3-10

Missing
neighbors problem
...................................................................................................................................................................................................................................
Definition

A neighboring cell list contains the cell identifiers to which a handover is allowed. The
list is kept in the RNC and is transmitted to the UE. The UE measures signals only
from the neighboring cell list and uses these measurement for power control and
handovers. A handover can therefor only occur to a cell that is in the neighboring cell
list of a UE, so setting up proper neighboring cell lists is very important.

PRELIMINARY

Common optimization problems and their solutions

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

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

There are several ways in which missing neighbor problems show themselves in the
network.
These include:

Dropped calls (when neighboring cell list is too short and UE can not handover to
another cell)
High interference levels (UE transmits at high power levels to serving cell, because
it can not handover to another cell)
Unusual handover behavior (no handovers are performed from on cell to another
cell).
Uneven traffic distribution (UE stay with a cell and are not handed over to a
neighboring cell).

Information sources

The following information sources are used to detect missing neighbors problem:
Drive test
Key performance indicators
Customer complaints.

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
3-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY
PRELIMINARY

Common optimization problems and their solutions

Missing neighbors problem

Possible solutions

Possible solutions for missing neighbor problems are:

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


Change RF coverage, so pilots are not received anymore or pilot reception is
improved:
Adjust power levels
Change antenna orientation or tilt.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

3-12

PRELIMINARY

U TRAN Signaling
4

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Protocol architecture of the air interface

4-3

Protocols of the air interface

4-4

Radio interface protocol architecture

4-6

Service access points

4-8
4-11

Physical channels

4-12

Transport channels

4-18

Logical channels

4-20

Air interface protocols

4-22

Medium Access Control

4-23

Radio Link Control

4-27

Packet Data Convergence Protocol (PDCP)

4-30

Radio Resource Control

4-31

RRC State Machine

4-34

RRC Connection and Signaling Connection

4-35

Signaling radio bearers

4-36

Radio bearer establishment

4-40

UTRAN protocols

4-44

Iub protocol structure

4-45

Protocols of the Iub interface

4-47

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Air interface channels

PRELIMINARY
PRELIMINARY

UTRAN Signaling

Overview

Iur interface

4-50

Iu-cs interface

4-52

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-2

Protocol architecture of the air interface


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

PRELIMINARY

UTRAN Signaling

Purpose

The purpose of this section is:

to describe of the protocols of the air interface


to match these protocols to their correct layer in the protocol architecture of the air
interface
to explain how the layers communicate with one another by the use of channels.

Contents
Protocols of the air interface

4-4

Radio interface protocol architecture

4-6

Service access points

4-8

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

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

The following illustration shows the UTRAN protocol architecture (for DCH) with the
protocols of the Uu highlighted.

IP

SM

SM

PMM

PMM

PDCP RRC

RRC

RLC

PDCPGTP-U

RLC

MAC

MAC

Phy -up

ALCAP

ALCAP

STC.2 NBAP
FP
PHY

PHY

SSCF-UNI

SSCOP

SSCOP

AAL5

AAL5

AAL2

Phy-up

NBAP STC.2

SSCF
-UNI

UDP

FP

IP

GTP-U
RANAP RANAP

SCCP

SCCP

MTP3-b

MTP3-b

SSCF
-N

SSCF
-N

UDP

IP

SSCOP SSCOP
AAL2

AAL5

AAL5

ATM

ATM

ATM

E1/ STM
-1

-1
STM

STM-1

Control plane
User plane
UE

Uu

Node B

Iub

RNC

Iu-ps

SGSN

Description

PRELIMINARY

The following table lists the protocols of the Uu and introduces the functions each
performs.
Part

Description

Radio Resource Control

The RRC controls the connection between UE and


UTRAN (setup, maintenance and teardown). Secondly,
RRC provides the means for the transmission of NAS
signaling. Finally, it is used by the Radio Resource
Management algorithms.

Packet Data Convergence


Protocol

The PDCP provides header compression and


decompression of IP data streams. It also transmits user
data from the non-access stratum to the RLC layer and
vice versa.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-4

Protocols of the air interface

Part

Description

Radio Link Control

The RLC provides functions related to data transfer, such


as segmentation and reassembly, in-sequence delivery,
error-correction and flow control. Three modes are
provided: transparent, acknowledged and
unacknowledged.

Medium Access Control

The MAC prepares transport blocks for most efficient


transfer over the air. The functions include scheduling,
multiplexing, channel type switching, UE identification
(on common channels) and transport format selection on
a frame-by-frame basis.

PRELIMINARY

UTRAN Signaling

The MAC is responsible for mapping logical channel


onto the appropriate transport channel.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Radio
interface protocol architecture
...................................................................................................................................................................................................................................
A layered architecture

The radio protocol architecture in the UTRAN is layered.

The top layer (layer 3) is the network layer and includes the RRC and the user
traffic
below that is layer 2 or the data link layer,
Layer 2 is split into the following sub-layers:
Medium-Access Control (MAC)
Radio Link Control (RLC)
Packet Data Convergence Protocol (PDCP)
Broadcast/Multicast Control (BMC).
the bottom layer is the physical layer (layer 1).

Layer 3 and the RLC are divided into Control (C) and User (U) planes. The PDCP and
the BMC exist in the U plane only.
In the C plane, Layer 3 is partitioned into sub-layers where the lowest sub-layer which
is called the Radio-Resource Control (RRC), interfaces with Layer 2 and terminates in
the UTRAN.
Higher-layer signaling, such as Session Management (SM)Mobility Management (MM)
and Call Control (CC), belongs to the non-access stratum, is not terminated in the
UTRAN and thus not discussed in this topic.
Structure of radio protocol architecture

PRELIMINARY

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

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-6

Radio interface protocol architecture

C-plane signaling
GC Nt DC

U-plane information

control
Layer 3

control Radio Resource Control


(RRC)
control

PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC
RLC RLC

RLC

Medium Access Control (MAC)

Physical Layer (PHY)

PRELIMINARY

UTRAN Signaling

L2/BMC

RLC
L2/RLC
Logical
Channels
L2/MAC
Transport
Channels
L1
Physical
Channels

Explanation of overall protocol structure

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

These interfaces allow the RRC to control the configuration of the lower layers. For
this purpose separate Control SAPs are defined between the RRC and each lower layer
(PDCP, RLC, MAC and L1).
....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

UTRAN Signaling

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

The layers provide services to the layer above, and use the services of the layer below.
These services are provided through Service Access Points, which provide different
kinds of channels for communications. The channels are divided into four broad
categories, depending on which layer interface provides them. These categories are:

Radio Bearers provided by the RLC


Logical Channels provided by the MAC to the RLC
Transport Channels provided by the PHY to the MAC
Physical Channels provided to the PHY.

The SAPs and their position between the layers are illustrated in the following figure.
L
a
y
e
r
M
a
n
a
g
e
m
e
n
t

Radio Resource
Control (RRC)
L3

SAPs

Radio Link Control (RLC)


L2

SAPs

Medium Access Control (MAC)


L2
SAPs
Physical Layer
L1
SAPs
Air

What are the different channels for?

The different channels provide the following different services.

PRELIMINARY

The logical channel service contains the type of information that is transferred over
the radio link. For example, the DTCH carries the actual user data; the BCCH
provides system information to all users in a cell.
The transport channel service defines how and with what characteristics (with
which QoS) data is transferred over the radio link. Every transport channel has a
transport format assigned to it which contains information such as channel coding,
interleaving and rate matching.
The physical channel service provides the means by which the UE is radio-linked
with the Node B.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-8

Service access points

Channel mapping

For each of the channel categories, there is a number of types, each with different
characteristics. The Radio Bearers map directly to the Logical Channels; the Logical
Channels map to the Transport Channels; and the Transport Channels map to the
Physical Channels.
The following illustration shows the relationships between channels linking different
protocol layers.

PRELIMINARY

UTRAN Signaling

Physical channels
Downlink
Uplink

P-SCH
S-SCH

Birirectional
P-CPICH
Logical channels

Transport channels

S-CPICH

BCCH

BCH

P-CCPCH

PCCH

PCH

PICH

CCCH

FACH

S-CCPCH

CTCH

RACH

PRACH

DCCH
DTCH

AICH
DCH

DPDCH
DPCH
DPCCH

DSCH

PDSCH

CPCH

PCPCH

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Transport channels are mapped to physical channels as shown in the illustration above.
There are many physical channels which do not carry higher-layer traffic; some are
associated with traffic-carrying channels, while others are necessary for cell discovery
by the UE and channel estimation.

PRELIMINARY

UTRAN Signaling

Service access points

Multiple transport channels can be multiplexed onto a single physical channel, or


conversely, one transport channel can be transferred over multiple physical channels
(multicode). PCH and FACH can be multiplexed onto the same S-CCPCH or can each
be transferred over separate S-CCPCHs.
Associated channels are used as follows:

PRELIMINARY

PICH indicates in an efficient manner that information for a mobile will shortly be
transferred on the PCH transport channel
AICH indicates that an access preamble has been received, and that the UE can
stop ramping up its power, or (for PCPCH) that a collision detect preamble has
been received and resolved
DPCCH carries power control information for associated channels as well as TFC
indication for DPDCH and PDSCH, and pilot and feedback information. The
shared channels are power controlled, so a UE which uses them must also have a
dedicated channel set up and associated with them. This DCH can be of very low
bandwidth compared to the shared channel, and may well carry the DCCH.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-10

Air interface channels


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

PRELIMINARY

UTRAN Signaling

Purpose
Contents
Physical channels

4-12

Transport channels

4-18

Logical channels

4-20

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Physical
channels
...................................................................................................................................................................................................................................
Overview

In this section, we will look at each of the physical channels that link the UE with the
Node B and consider their mapping relationships to the transport channels.
We shall consider the following groups of physical channels:

Dedicated downlink physical channels


Common downlink physical channels.
Dedicated uplink physical channels
Common uplink physical channels

Introduction

In the Node B, physical channels are created out of either related transport channels or
out of Node B control data. In the latter case, the information in the physical channel
does not carry higher-layer traffic but is pure layer 1 control data created by the Node
B, e.g. SCH or CPICH.
Multiple transport channels can be multiplexed onto a single physical channel, or
conversely, one transport channel can be transferred over multiple physical channels
(multicode). For example, PCH and FACH can be multiplexed onto the same
S-CCPCH or can each be transferred over separate S-CCPCHs.

PRELIMINARY

Transport channels are mapped to physical channels as shown in the illustration.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-12

Physical channels

Physical channels
Downlink

P-SCH

Uplink

S-SCH

PRELIMINARY

UTRAN Signaling

P-CPICH
Transport channels

S-CPICH

BCH

P-CCPCH

PCH

PICH

FACH

S-CCPCH

RACH

PRACH
AICH

DCH

DPDCH
DPCH
DPCCH

DSCH

PDSCH

CPCH

PCPCH

Channel mapping

The DCHs are coded and multiplexed and the resulting data stream is mapped
sequentially directly to the physical channel(s).

Also for the RACH, the coded and interleaved bits are sequentially mapped to the
physical channel, in this case the message part of the random access burst on the
PRACH.
....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-13
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

The mapping of BCH and FACH is equally straightforward where the data stream,
after coding and interleaving, is mapped sequentially to the Primary and Secondary
CCPCH respectively.

PRELIMINARY

UTRAN Signaling

Physical channels

The mapping of the PCH to the Secondary CCPCH is slightly more complicated to
allow for an efficient sleep mode.
The mapping of the DSCH to the PDSCH is done by mapping the data stream
sequentially directly to the physical channel.
Dedicated downlink physical channels

There is only one type of downlink dedicated physical channel, the Downlink
Dedicated Physical Channel (downlink DPCH).
Within one downlink DPCH, dedicated user data generated at layer 2 and above (from
MAC and above at the RNC) and control information generated at layer 1 (known
pilot bits, TPC commands, and an optional TFCI) are multiplexed at the Node B and
transmitted together over the Uu interface. The downlink DPCH can thus be seen as a
time multiplex of a downlink DPDCH and a downlink DPCCH.
In contrast, the uplink transmits the DPDCH and the DPCCH logically separate from
one another.
There may be zero, one, or several uplink DPCHs on each Layer 1 connection.
Common downlink physical channels

PRELIMINARY

The following is a list of the common downlink physical channels:


Common
downlink
physical
channels

Description

P-CCPCH

The Primary Common Control Physical Channel is a fixed rate (32


kbps, SF=256) downlink physical channels used to carry the BCH.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-14

Physical channels

Common
downlink
physical
channels

Description

S-CCPCH

The Secondary Common Control Physical Channel is used to carry


the FACH and PCH. It is of constant rate. However, in contrast to
the Primary CCPCH, the rate may be different for different
secondary CCPCH within one cell and between cells, in order to be
able to allocate different amount of FACH and PCH capacity to a
cell. The rate and spreading factor of each secondary CCPCH is
broadcast on the BCH. The set of possible rates is the same as for
the downlink DPCH.

PRELIMINARY

UTRAN Signaling

The FACH and PCH can be mapped to separate secondary


CCPCHs.
The main difference between the Primary and Secondary CCPCH is
that the Primary CCPCH has a fixed predefined rate while the
Secondary CCPCH has a constant rate that may be different for
different cells, depending on the capacity needed for FACH and
PCH.
P-SCH

The Synchronisation Channel (SCH) is a downlink signal used for


cell search. The SCH consists of two sub channels, the Primary and
Secondary SCH. Along with the CPICH, the SCH channels provide
information that enables the UE to camp on, search for and select a
cell.
During the first step of the initial cell search procedure, the UE
uses the Primary Synchronisation Channel (P-SCH) to acquire slot
synchronisation to the strongest cell. The Primary Synchronisation
Code in the P-SCH is the same for every cell in the system.

S-SCH

During the second step of the initial cell search procedure, the UE
uses the secondary SCH to find frame synchronisation and identify
the code group of the cell found in the first step.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-15
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Physical channels

Common
downlink
physical
channels

Description

CPICH

The Common Pilot Channel is a fixed rate (30 kbit/s, SF = 256)


downlink physical channel.
Because this channel is coded with the scrambling code of the cell
that it belongs to, the channel can be used by the UE to determine
the received signal strength of this particular cell. Furthermore the
CPICH is also used as a phase and power reference for the other
downlink physical channels.
The downlink common control channels have to reach all UEs in
the cell and should not be too loud to disturb other cells. As the
cell size is often adjusted, it may occur that the power level of all
control channels must be readjusted. To simplify this, the power
level of all control channels are expressed in relation to the power
that is used by the Pilot Channel (CPICH) of a cell. e.g. when the
power of CPICH is reduced, the power of all other common
channels is reduced by the same factor.

PICH

The Paging Indicator Channel informs the UE that paging


information will shortly be available for that mobile over the
S-CCPCH. This is an efficient process which saves the UE from
having to permanently listen in on the S-CCPCH.

AICH

The Acquisition Indicator Channel is a common downlink physical


channel which works closely together with the uplink PRACH.
Upon reception of an access preamble from a UE, the Node B uses
the AICH to acknowledge the success of the transmission and to
inform the UE that it can stop ramping up its power.

PDSCH

The Physical Downlink Shared Channel is shared by several users


based on code multiplexing.

Dedicated uplink physical channels

PRELIMINARY

In contrast to the one dedicated downlink physical channel, there are two dedicated
uplink physical channels: the Dedicated Physical Data CHannel (DPDCH) and the
Dedicated Physical Control CHannel (DPCCH).
The uplink DPDCH is used to carry dedicated user data generated at Layer 2 and
above, i.e. data taken from the dedicated transport channel (DCH). There may be zero,
one, or several uplink DPDCHs on each Layer 1 connection.
The uplink DPCCH is used to carry control information generated at Layer 1. There is
one and only one uplink DPCCH on each Layer 1 connection. The Layer 1 control
....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-16

Physical channels

information consists of the same control information as used in the downlink with the
addition of FBI bits:

Transmit Power Control (TPC) allows the UE to tell the Node B to either increase
or decrease its transmission power.
The TFCI is used in order to inform the receiving side of the currently valid
Transport Format Combination, and hence how to decode, de-multiplex and deliver
the received data on the appropriate Transport Channels.
Pilot bits support channel estimation for coherent detection.
By means of the FBI-Bits (FeedBack Information), the UE can have the Node B
regulate the phase and amplitude in the case of Closed Loop Transmit Diversity.

PRELIMINARY

UTRAN Signaling

Common uplink physical channels

There are two common uplink physical channels: PRACH and PCPCH.

The PRACH only exists in the uplink and enables the UE to send messages to the
UTRAN, without having a dedicated channel. Typically, the PRACH is used when
a mobile user wishes to initiate a call and requests radio resources.
Because all the users in a cell need to share the use of the PRACH, a mechanism
was devised (slotted Aloha) to regulate access to the PRACH and thus prevent
collisions. UEs receive information on what access slots are available in the current
cell over the broadcast channel (BCH). The access slots have time offsets that are
spaced 1.25 ms apart.
The Physical Common Packet CHannel (PCPCH) is a common uplink channel over
which multiple users can transmit data packets. The downlink counterpart to the
PCPCH is the Physical Downlink Shared CHannel (PDSCH)

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-17
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Transport
channels
...................................................................................................................................................................................................................................
Introduction

The transport channels convey data from the MAC layer to the physical layer and there
are mapped to physical channels.
The physical layer offers the transport channels different bitrates, depending on the
spreading factor used.
Several transport channels are multiplexed on one physical channel.
Dedicated and common transport channels

There are two types of transport channels: dedicated transport channels and common
transport channels. The dedicated transport channels, as the name suggests, are
channels dedicated to one single User Equipment. Whereas the common transport
channels may be used by multiple users.
There is only one dedicated transport channel: the Dedicated Channel or DCH. A
channel dedicated to one UE used in uplink or downlink.

PRELIMINARY

There are 6 common transport channels:


Common
transport
channels

Description

RACH

The Random Access Channel (RACH) is a contention based uplink


channel used for transmission of relatively small amounts of data, e.g.
for initial access or non-real-time dedicated control or traffic data.

FACH

The Forward Access Channel (FACH) is a common downlink channel


without closed-loop power control used for transmission of relatively
small amount of data.

BCH

The Broadcast Channel (BCH) is a downlink channel used for broadcast


of system information into an entire cell.

PCH

The Paging Channel (PCH) is a downlink channel used for broadcast of


control information into an entire cell allowing efficient UE sleep mode
procedures. Currently identified information types are paging and
notification. Another use could be UTRAN notification of change of
BCCH information.

CPCH

The Common Packet Channel (CPCH) is a contention based uplink


channel (FDD) used for transmission of bursty data traffic. This channel
is shared by the UEs in a cell

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-18

Transport channels

Common
transport
channels

Description

DSCH

The Downlink Shared Channel (DSCH) is a downlink channel shared by


several UEs carrying dedicated control or traffic data.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-19
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

PRELIMINARY

UTRAN Signaling

Logical
channels
...................................................................................................................................................................................................................................
Introduction

A set of logical channel types is defined for different kinds of data transfer services as
offered by MAC. Each logical channel type is defined by the type of information
transferred as opposed to transport channels which define how data is transported.
Broadcast Control Channel (BCCH)

A downlink channel for broadcasting system control information.


Paging Control Channel (PCCH)

A downlink channel that transfers paging information. This channel is used when the
network does not know the location cell of the UE, or, the UE is in the cell connected
state (utilising UE sleep mode procedures).
Common Control Channel (CCCH)

Bi-directional channel for transmitting control information between network and UEs.
This channel is commonly used by the UEs having no RRC connection with the
network and by the UEs using common transport channels when accessing a new cell
after cell reselection.
Common Traffic Channel (CTCH)

A point-to-multipoint unidirectional channel for transfer of dedicated user information


for all or a group of specified UEs.
Dedicated Control Channel (DCCH)

A point-to-point bi-directional channel that transmits dedicated control information


between a UE and the network. This channel is established through RRC connection
setup procedure.
Dedicated Traffic Channel (DTCH)

PRELIMINARY

A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE,


for the transfer of user information. A DTCH can exist in both uplink and downlink.
Channel mapping

The following figure illustrates the logical channels and their corresponding transport
channels that MAC is responsible for mapping:

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-20

Logical channels

Logical channels

Transport channels

BCCH

BCH

PCCH

PCH

CCCH

FACH

CTCH

RACH

PRELIMINARY

UTRAN Signaling

DCCH
DTCH

DCH

Downlink
Uplink
Birirectional

DSCH
CPCH

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-21
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Air interface protocols


Overview
...................................................................................................................................................................................................................................
Purpose

PRELIMINARY

Contents
Medium Access Control

4-23

Radio Link Control

4-27

Packet Data Convergence Protocol (PDCP)

4-30

Radio Resource Control

4-31

RRC State Machine

4-34

RRC Connection and Signaling Connection

4-35

Signaling radio bearers

4-36

Radio bearer establishment

4-40

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-22

Medium
Access Control
...................................................................................................................................................................................................................................
Medium Access Control

The MAC model maps the transport channels it receives from the physical layer to the
logical channels it passes on to the Radio Link Control protocol and vice versa.

PRELIMINARY

UTRAN Signaling

MAC takes each RLC PDU from the logical channel and constructs a MAC PDU (also
known as transport block) according to the Transport Format defined for the transport
channel. Each transport channel can have different bit rates. Thus, the MAC model is
responsible for transporting blocks of data according to the specified channel bit rate.
The illustration shows the position of the MAC protocol.
C-plane signaling
GC Nt DC

U-plane information

control
Layer 3

control Radio Resource Control


(RRC)
control

PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC
RLC RLC

RLC

Medium Access Control (MAC)

Physical Layer (PHY)

L2/BMC

RLC
L2/RLC
Logical
Channels
L2/MAC
Transport
Channels
L1
Physical
Channels

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-23
Issue 0.1, June 2006
See notice on first page

PRELIMINARY
PRELIMINARY

UTRAN Signaling

Medium Access Control

Functions and Services

The MAC sublayer provides the following functions and services:


Function and
service

Description

Mapping between
logical channels
and transport
channels.

The MAC is responsible for mapping logical channel(s) onto the


appropriate transport channel(s).

Selection of
appropriate
Transport Format
for each Transport
Channel depending
on instantaneous
source rate.

Given the Transport Format Combination Set assigned by RRC,


MAC selects the appropriate transport format within an assigned
transport format set for each active transport channel depending
on source rate. The control of transport formats ensures efficient
use of transport channels.

Priority handling
between data flows
of one UE.

When selecting between the Transport Format Combinations in


the given Transport Format Combination Set, priorities of the
data flows to be mapped onto the corresponding Transport
Channels can be taken into account. Priorities may be given
according to attributes of Radio Bearer services and RLC buffer
status. The priority handling is achieved by selecting a Transport
Format Combination for which high priority data is mapped onto
layer 1 with a high bit rate Transport Format, at the same time
letting lower priority data be mapped with a low bit rate (could
be zero bit rate) Transport Format. Transport format selection
may also take into account transmit power indication from layer
1.

Identification of
UEs on common
transport channels.

When a particular UE is addressed on a common downlink


channel, or when a UE is using the RACH, there is a need for
inband identification of the UE. Since the MAC layer handles the
access to, and multiplexing onto, the transport channels, the
identification functionality is naturally also placed in MAC.

Traffic volume
monitoring.

Measurement of traffic volume on logical channels and reporting


to RRC. Based on the reported traffic volume information, RRC
performs transport channel switching decisions.

Ciphering

This function prevents unauthorised acquisition of data. Ciphering


is performed in the MAC layer for transparent RLC mode.

Data transfer

This service provides unacknowledged transfer of MAC SDUs


between peer MAC entities. This service does not provide any
data segmentation. Therefore, segmentation/reassembly function
should be achieved by upper layer.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-24

Medium Access Control

Function and
service

Description

Reallocation of
radio resources and
MAC parameters.

This service performs on request of RRC execution of radio


resource reallocation and change of MAC parameters, i.e.
reconfiguration of MAC functions such as change of identity of
UE, change of transport format (combination) sets, change of
transport channel type.

PRELIMINARY

UTRAN Signaling

MAC entities

MAC is structured into the following dedicated MAC entities:

Dedicated MAC (MAC-d) terminates in the SRNC


Common MAC (MAC-c/sh) terminates in the CRNC
MAC-b is the entity that handles the broadcast channel (BCH). There is one
MAC-b entity in each UE and one MAC-b in the Node B.

Data transfer type

The MAC protocol can be one of two data transfer types:

transparent MAC
or non-transparent MAC.

The data transfer type depends on whether a MAC header is attached to the packet.
The case where no MAC header is required is referred to as transparent MAC
transmission.
Parameters of the MAC header

The following fields are defined for the MAC header:

The C/D field is a single-bit flag that provides identification of the logical channel
class on FACH and RACH transport channels, i.e. whether it carries CCCH or
dedicated logical channel information.
The C/T field provides identification of the logical channel instance when multiple
logical channels are carried on the same transport channel. The C/T field is used
also to provide identification of the logical channel type on dedicated transport
channels and on FACH and RACH when used for user data transmission.
The UE-Id field provides an identifier of the UE.

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-25
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Depending on the logical to transport mapping relationship, all, a selection or none of


the above parameters may be used.

PRELIMINARY
PRELIMINARY

UTRAN Signaling

Medium Access Control

Here are some examples:

DTCH or DCCH mapped to DCH, no multiplexing of dedicated channels on MAC:


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

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-26

Radio
Link Control
...................................................................................................................................................................................................................................
Introduction

The Radio Link Control (RLC) protocol is situated between the Medium Access
Control and the Radio Resource Control protocols.
C-plane signaling
GC Nt DC

PRELIMINARY

UTRAN Signaling

U-plane information

control
Layer 3

control Radio Resource Control


(RRC)
control

PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC
RLC RLC

RLC

Medium Access Control (MAC)

Physical Layer (PHY)

L2/BMC

RLC
L2/RLC
Logical
Channels
L2/MAC
Transport
Channels
L1
Physical
Channels

Radio Link Control

The Radio Link Control (RLC) protocol provides logical link control over the radio
interface.
There may be several simultaneous RLC links per User Equipment; each link is
identified by a bearer id.
RLC provides three types of Service Access Points (SAP), corresponding to three
different RLC data transfer modes:

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-27
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

1. In Transparent Mode (TM), RLC transmits upper layer protocol data units (PDUs)
without adding any protocol control information (no RLC header).
2. In Unacknowledged Mode (UM), RLC transmits upper layer PDUs without
guaranteeing delivery to the peer entity.
3. In Acknowledged Mode (AM), RLC transmits upper layer PDUs guaranteeing
delivery to the peer entity. AM RLC is used for the packet-switched RABs.

PRELIMINARY

UTRAN Signaling

Radio Link Control

The following illustration shows the three different RLC data transfer modes:

Radio Resource Control

Transparent
mode

Acknowledged
mode

Unacknowledged
mode

RLC
MAC
L1

Services offered by the 3 modes

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

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

Segmentation and reassembly


Transfer of user data.

Unacknowledged mode services

PRELIMINARY

RLC receives SDUs from the higher layers. If the SDU is too large it is segmented
into appropriate RLC PDUs. The SDU might also be concatenated with other SDUs.
RLC adds a header and the PDU is placed in the transmission buffer. The RLC then
decides which PDUs and when the PDUs are delivered to MAC.
The RLC also decides which logical channel should be used. The number of logical
channels that is needed is decided upon when the service is established. The type of
the logical channels depends on if the higher layer is located in the control plane
(DCCH) or in the user plane (DTCH).
....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-28

Radio Link Control

Unacknowledged mode services:

Segmentation and reassembly


Concatenation
Transfer of user data.

Acknowledged mode services

PRELIMINARY

UTRAN Signaling

RLC receives SDUs from the higher layers. For a packet switched service, the RLC
SDU is normally one IP packet. The SDUs are segmented and/or concatenated to
PDUs of fixed length. The length of the PDUs is decided upon when the service is
established. After that RLC adds a header and the PDU is placed in the retransmission
buffer and the transmission buffer.
The RLC then decides which PDUs and when the PDUs are delivered to MAC, e.g. it
could be useful to send RLC control PDUs on one logical channel and data PDUs on
another logical channel. The retransmission buffer also receives acknowledgements
from the receiving side, which are used to indicate retransmissions of PDUs and when
to delete a PDU from the retransmission buffer.
Acknowledged mode services

Segmentation and reassembly


Concatenation
Transfer of user data
Error correction
In-sequence delivery of higher layer PDUs
Duplicate detection
Flow Control
Protocol error detection
Recovery.

The Acknowledged Mode (AM) RLC toolbox includes various functions that allow
setting up different automatic repeat request (ARQ) schemes. An AM RLC entity is
configured by approximately 20 parameters. Proper setting and optimisation of these
parameters is vital to provide packet-switched RABs with the required quality of
service (QoS).

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-29
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Packet
Data Convergence Protocol (PDCP)
...................................................................................................................................................................................................................................
Introduction

PDCP is a layer2, user plane protocol, located above the Radio Link Control protocol.
C-plane signaling
GC Nt DC

U-plane information

control
Layer 3

control Radio Resource Control


(RRC)
control

PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC
RLC RLC

RLC

Medium Access Control (MAC)

Physical Layer (PHY)

L2/BMC

RLC
L2/RLC
Logical
Channels
L2/MAC
Transport
Channels
L1
Physical
Channels

Header compression and decompression

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

PRELIMINARY

Transmission of user data means that PDCP receives PDCP SDU from the NAS and
forwards it to the RLC layer and vice versa.
Data buffer

If the SRNC needs to be relocated and a delay ensues, the PDCP also has buffering
capabilities. Each PDCP SDU is numbered from 0 255 and buffered until the RLC
acknowledges the reception of transmitted PDCP PDPs. Once the acknowledgement
arrives, data flow can recommence.
...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-30

Radio
Resource Control
...................................................................................................................................................................................................................................
Introduction

Radio Resource Control (RRC) handles the control plane signaling of layer 3 between
the UEs and UTRAN

PRELIMINARY

UTRAN Signaling

The following illustration shows the position of the RRC protocol in the Radio
Interface Protocol architecture.
C-plane signaling
GC Nt DC

U-plane information

control
Layer 3

control Radio Resource Control


(RRC)
control

PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC
RLC RLC

RLC

Medium Access Control (MAC)

Physical Layer (PHY)

L2/BMC

RLC
L2/RLC
Logical
Channels
L2/MAC
Transport
Channels
L1
Physical
Channels

Interfaces

The RRC provides the signaling interface to the non-access stratum with the following
services (see illustration above):

General Control (GC): information broadcast service


Notification (Nt): paging and notification broadcast services
Dedicated Control (DC): connection management and message transfer.

The RRC manages the configuration of layer 2 and layer 1 protocols with direct links
to each of the lower layers.
The following illustration shows the lower layer interactions of the RRC.
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-31
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

The RRC connects to the RLC over any of its 3 connection modes.

PRELIMINARY

UTRAN Signaling

Radio Resource Control

The arrows going to the RRC show the RRC receiving measurement data from the
lower layers, the arrows going from the RRC show the RRC sending control messages
to the lower layers.

RRC

Radio Resource
Assignment
(mapping, TF set
frequency, code
TS, etc)

RRC

RLC

RLC transmission
control

RLC

MAC

MAC

L1

L1

UTRAN

UE

Functions

The RRC performs the following functions:

PRELIMINARY

Broadcast of information provided by the non-access stratum (Core Network): The


RRC layer performs system information broadcasting from the network to all UEs.
The system information is normally repeated on a regular basis.
Broadcast of information related to the access stratum.
Establishment, re-establishment, maintenance and release of RRC connections.
Establishment, reconfiguration and release of Radio Bearers: The establishment of
an RRC connection is initiated by a request from higher layers at the UE side to
establish the first Signalling Connection for the UE.
Assignment, reconfiguration and release of radio resources for the RRC connection:
The RRC layer can, on request from higher layers, perform the establishment,
reconfiguration and release of Radio Bearers in the user plane.
Paging/notification: The RRC layer can broadcast paging information from the
network to selected UEs. Higher layers on the network side can request paging and
notification. The RRC layer can also initiate paging during an established RRC
connection.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-32

Radio Resource Control

Control of requested QoS.

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-33
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

PRELIMINARY

UTRAN Signaling

RRC
State Machine
...................................................................................................................................................................................................................................
RRC state machine

The RRC state machine is a description model of how the UE and the UTRAN
co-operate regarding RRC functionality.
The RRC state machine exists as two peer entities (UE and UTRAN). The two peer
entities are synchronized.
There are two modes in the RRC state machine:

Idle mode
Connected mode.
UE position can be known on different levels:
URA level
Cell level

Idle mode

After power on, the UE stays in idle mode until it transmits a request to establish an
RRC connection. In idle mode, the UE is identified by non-access stratum identities
such as IMSI, P-TMSI and TMSI. In addition, the UTRAN has no information about
the individual idle mode UEs, and can only address either all UEs in a cell or all UEs
in a paging group. The UE receives paging messages on the PCH.
Connected mode

Connected mode is entered when the RRC connection is established. The UE is


assigned a radio network temporary identity (RNTI) to be used as UE identity on
common transport channels. The UE leaves connected mode and returns to idle mode
when the RRC connection is released or at RRC connection failure.
The connected mode of the UE can be known on different levels:

PRELIMINARY

URA level (UTRAN registration area): URA is a specified set of cells hich can be
identified on the BCCH. URA is only internally known in the UTRAN.
Cell level: different channel types can be used for data transfer such as Common
transport channels (RACH, FACH, CPCH, DSCH) or Dedicated transport channels
(DCH).

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-34

RRC
Connection and Signaling Connection
...................................................................................................................................................................................................................................
Definitions

RRC connection An RRC connection is a point-to-point bi-directional connection


between RRC peer entities on the UE and the UTRAN sides.

PRELIMINARY

UTRAN Signaling

Signaling connection An acknowledged-mode link between the UE and the CN to


transfer higher layer information between the entities in the non-access stratum.
The signaling connection is made up of an RRC and a RANAP connection.
Signaling connection

Consisting of an RRC (signaling) connection and a RANAP (signaling) connection, the


signaling connection provides the resources necessary for all signalling messages
between the UE and the core network (MSC or SGSN). Such signaling messages could
be for example, session management messages, such as a PDP context request; or
Mobility Management messages, such as those used in handover signaling.
The following illustration shows the RRC and the RANAP connections that make up
the signaling connection.
Signaling Connection
RANAP Connection

RRC Connection
Relay
RRC

Uu

Node B

Iub

RNC

RANAP

RANAP

Iu

SGSN\MSC

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-35
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UE

RRC

PRELIMINARY

UTRAN Signaling

Signaling
radio bearers
...................................................................................................................................................................................................................................
Definitions

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

PRELIMINARY

This example shows the steps taken during the establishment of an RRC connection in
DCH state.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-36

Signaling radio bearers

Node B
Serving RNS

UE

Serving RNC

1. CCCH: RRC Connection Request

PRELIMINARY

UTRAN Signaling

Select L1 +L2
parameters
2. Radio Link Setup Request

3. Radio Link Setup Response

4. ALCAP Iub Data Transport Bearer Setup

5. Downlink Synchronization

6. Uplink Synchronization

7. CCCH: RRC Connection Setup

8. DCCH: RRC Connection Setup Complete

Steps of the RRC connection establishment

The following is a description of the RRC connection establishment process:


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

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

After performing Call Admission Control (CAC), the SRNC decides to use a DCH for
this RRC connection, allocates RNTI and radio resources for the RRC connection.

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-37
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

The UE initiates the set-up of an RRC connection by sending an RRC message


Connection Request on the CCCH.

PRELIMINARY

UTRAN Signaling

Signaling radio bearers

When a DCH is to be set-up, an NBAP message Radio Link Setup Request is sent to
the Node B.
...................................................................................................................................................................................................

The Node B allocates resources, starts PHY reception, and responses with the NBAP
message Radio Link Setup Response.
...................................................................................................................................................................................................

The SRNC initiates the set-up of an Iub data transport bearer using the ALCAP
protocol. The request for the set-up of an Iub data transport bearer is acknowledged by
the Node B.
...................................................................................................................................................................................................

The Node B and the SRNC establish synchronism for the Iub and Iur data transport
bearer by means of exchange of the appropriate DCH frame protocol frames downlink
synchronization.
...................................................................................................................................................................................................

The Node B and the SRNC establish synchronism for the Iub and Iur data transport
bearer by means of exchange of the appropriate DCH frame protocol frames uplink
synchronization. Then the Node B starts downlink transmission.
...................................................................................................................................................................................................

The message RRC connection setup is sent on a CCCH from the SRNC to the UE.
...................................................................................................................................................................................................

The Message RRC connection setup complete is sent on a DCCH from the UE to the
SRNC.

Signaling radio bearers per RRC connection

4 signaling radio bearers are set up per RRC connection.

PRELIMINARY

2 signaling radio bearers for transport of RRC generated signaling messages.


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

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-38

Signaling radio bearers

Signaling radio bearer configuration at the UE

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

PRELIMINARY

UTRAN Signaling

U-plane information

Radio Resource Control


(RRC)

control

control
control

control

Signaling
Radio
Bearers

New RLC
entities
RLC
RLC

RLC

RLC

MAC
parameters
Medium Access Control (MAC)
L1
Parameters
Physical Layer (PHY)

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-39
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Radio
bearer establishment
...................................................................................................................................................................................................................................
Definitions

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

PRELIMINARY

This example shows the steps involved in the establishment of a Radio Access Bearer.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-40

Radio bearer establishment

UE

Node B

RNC

MSC
RANAP
RAB Assignment Request
ALCAP
ERQ (Establish Request)

PRELIMINARY

UTRAN Signaling

ALCAP
NBAP
RL Reconfigure Prepare

ECF (Establish Confirm)

NBAP
RL Reconfigure Ready
ALCAP
ERQ (Establish Request)
ALCAP
ECF (Establish Confirm)
FP DL Synchron.
FP UL Synchron.
NBAP
RL Reconfigure Commit
RRC RB Setup Request
DCCH
RRC RB Setup Complete
DCCH
RANAP
RAB Assignment Response

Radio Access Bearer establishment process

The following is a description of the Radio Access Bearer connection establishment


process:
...................................................................................................................................................................................................

The SGSN initiates the process by sending a RAB assignment request to the RNC
indicating the RAB configuration and also passing the UL GTP tunnel Paramaters.

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-41
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

UTRAN Signaling

Radio bearer establishment

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

The UE already has a Radio Link setup, this procedure requires that a DTCH be added
to the configuration, therefore the RNC sends a RL reconfigure request to the Node B.
The Node B confirms with RL Reconfigure Ready, but does not implement the changes
yet.
...................................................................................................................................................................................................

Once the RL has been reconfigured in the Node B, the RNC sets up the AAL2 bearer
to carry it. This is done via ALCAP Establish procedures and is followed by FP
synchronisation.
...................................................................................................................................................................................................

When the AAL2 connection is ready, the RNC instructs the Node B to commit the
changes it had prepared in the reconfiguration. The Commit message indicates the
Frame number at which the change should occur.
...................................................................................................................................................................................................

The UTRAN has been configured for the new DTCH, so the UE can now be instructed
to set up the Radio Bearer. The RNC does this via an RRC RB set-up request. This
includes the same CFN as indicated to the Node B.
...................................................................................................................................................................................................

Once the UE has configured the RB, it returns a confirmation message in the form of
an RRC RB set-up Complete.
...................................................................................................................................................................................................

Reception of the set-up complete message by the RNC indicates that RAB assignment
procedure is complete, it indicates this back to the SGSN via a RANAP RAB
assignment response, that also includes the DL addressing for the GTP-U connection.

Radio Access Bearer establishment

PRELIMINARY

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

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-42

Radio bearer establishment

C-plane signaling

U-plane information
New Radio
Bearer

Radio Resource Control


(RRC)
PDCP DCP

control

control

PRELIMINARY

UTRAN Signaling

BMC

RLC
RLC

RLC

RLC

RLC

New RLC
entity

MAC
parameters

Medium Access Control (MAC)


L1
Parameters

Physical Layer (PHY)

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-43
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

UTRAN protocols
Overview
...................................................................................................................................................................................................................................
Purpose

PRELIMINARY

Contents
Iub protocol structure

4-45

Protocols of the Iub interface

4-47

Iur interface

4-50

Iu-cs interface

4-52

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-44

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

The following illustration shows the protocol structure of the Iub interface.
Control Plane

Transport
Network
Layer

User Plane

ALCAP Q.2630.2

Transport Network
User plane

NBAP

Transport Network
User plane

CPCH FP
USCH FP
DSCH FP
PCH FP
FACH FP
RACH FP
DCH FP

Radio
Network
Layer

Transport Network
Control Plane

PRELIMINARY

UTRAN Signaling

STC Q.2150.2
SSCF-UNI
SSCOP

SSCF-UNI
SSCOP

AAL5

AAL5

AAL2

Physical
Layer

Two functional layers

The Iub interface protocol architecture consists of two functional layers:

The Radio Network Layer defines procedures related to the operation of Node B.
The radio network layer consists of a radio network control plane and a radio
network user plane.
The Transport Layer defines procedures for establishing physical connections
between Node B and the RNC.

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-45
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY
PRELIMINARY

UTRAN Signaling

Iub protocol structure

Functional Separation

In order to maintain a concise structure, on the Iub interface the radio network layer
and the transport layer are clearly separated. Therefore, the radio network signaling and
Iub data streams are separated from the data transport resource and traffic handling.
This resource and traffic handling is controlled by the transport signaling. The transport
signalling is carried by a signalling bearer over the Iub interface.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-46

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

The following illustration shows the UTRAN protocol architecture with the protocols
of the Iub highlighted.
SM

SM

PMM

IP
PDCP

PRELIMINARY

UTRAN Signaling

PMM

RRC

RRC

RLC

PDCP GTP
-U

RLC

MAC

MAC

Phy -up

ALCAP

ALCAP

STC.2 NBAP
FP
PHY

PHY

SSCF -UNI

SSCOP

SSCOP

AAL5

AAL5

AAL2

Phy -up

NBAP STC.2

SSCF -UNI

UDP

FP

GTP-U
RANAP RANAP

SCCP
IP

UDP

SCCP

MTP3-b MTP3-b

IP

SSCF-N SSCF-N
SSCOP SSCOP

AAL2

ATM

ATM

-1
E1/ STM

- 1
STM

AAL5

AAL5

ATM
STM-1

Control plane
User plane
UE

Uu

Node B

Iub

RNC

Iu-ps

SGSN

Overview of the Iub protocols

The following table lists the protocols of the Iub.

Access Link Control Application Part ALCAP


Node B Application Part NBAP
Service Specific Connection Oriented Protocol SSCOP
Framing protocols FP
ATM Adaptation Layer AAL
Asynchronous Transmission Mode ATM
The physical layer.

The Access Link Control Application Part ALCAP over SSCOP on AAL5 provides the
dynamic setup and teardown of data bearers over AAL2 links. ALCAP is not
responsible for signaling bearers, ensuring the separation of the two domains. The
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-47
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Access Link Control Application Part

PRELIMINARY

UTRAN Signaling

Protocols of the Iub interface

application protocol of the control plane, NBAP, requests ALCAP to create or tear
down a data bearer. User data is ultimately transmitted over these data bearers.
Node B Application Part

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

The SSCOP protocol stack provides the layer of processing between the AAL Type 5
and the NBAP and ALCAP processing entities.
The SSCF-UNI maps the requirements of the layer above to the requirements of
SSCOP. Also SAAL connection management, link status and remote processor status
mechanisms are provided. SSCOP provides mechanisms for the establishment and
release of connections and the reliable exchange of signaling information between
signaling entities. It adapts the upper layer protocol to the requirements of the Lower
ATM cells.
Framing protocols

The AAL2 links are used to carry user plane data which are encapsulated in various
Framing Protocols (DCHFP, FACHFP and RACHFP)
ATM Adaptation Layer

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

PRELIMINARY

ATM

ATM is used on the Iub interface for the transportation of packages using the ATM
backbone network.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-48

Protocols of the Iub interface

The physical layer

The PCM30 or PCM24 interface (E1 or T1) is used on the Iub interface as the physical
layer at the Node B. ATM concentrators are used to combine the PCM30/PCM24
carriers to STM-1 or OC-3 which is the physical interface at the RNC.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-49
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

PRELIMINARY

UTRAN Signaling

I...................................................................................................................................................................................................................................
ur interface
Introduction

Several different higher-layer protocols are used on the Iur interface. This topic
provides a short explanation for each of them.
Interface diagram

The following figure shows the location of the Iur interface in the UMTS network.

Core Network

VLR
SGSN

MSC

IuPS

IuCS
IuPS

Iur

RNC
Iub

IuCS

Iub

RNC
Iub

Iub

Node B

Node B

Node B

Node B

Cells

Cells

Cells

Cells

Physical layer

PRELIMINARY

The SDH STM-1 or the SONET OC-3 interface is used on the Iur interface as the
physical layer.
ATM

ATM is used on the Iur interface for the transportation of packages using the ATM
backbone network.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-50

Iur interface

RNSAP

The Radio Network Subsystem Application Part (RNSAP) protocol is used for all
control messages that are sent between the Serving RNC and the Drift RNC.
ALCAP

The Access Link Control Application Part (ALCAP) protocol is used for ATM control
of the circuit switched connections between the serving RNC and the drift RNC.

PRELIMINARY

UTRAN Signaling

User data

The user data (signaling/voice/data) sent between the serving RNC and the drift RNC.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-51
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

Iu-cs
interface
...................................................................................................................................................................................................................................
Key functions

Transport of data and control traffic for circuit-switched services, including:

Establishment and release of circuit-switched access bearers


Transfer of non-access stratum signaling messages between user equipment and the
core network

Transport layer

The transport layer supports Asynchronous Transfer Mode (ATM).


ATM Adaptation Layer 2 and ATM Adaptation Layer 5 are used.
Physical layer

The physical layer supports shared Synchronous Transport Module-1 (STM-1) optical
interfaces.
Protocols used

The WAG supports the following protocol stack for the Iu-cs interface:
Radio
Network
Control Plane

Radio
Network
Layer

Transport
Network
Control Plane

User Plane
User plane
protocol

RANAP

Q.2630.1

PRELIMINARY

Transport
Network
Layer

Q.2150.1

SCCP
MTP3-B

MTP3-B

SSCF-NNI

SSCF-NNI

SSCOP

SSCOP

AAL5

AAL5

AAL2

ATM
STM-1

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

4-52

Iu-cs interface

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
4-53
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN Signaling

PRELIMINARY

PRELIMINARY

PRELIMINARY

Part II: Optimization process

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 5, Drive testing

5-1

Chapter 6, Optimization process

6-1

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
II-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

PRELIMINARY

D rive testing
5

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Drive test optimization process

5-2

Planning and preparation (site readiness)

5-4

Optimization planning

5-6

Perform cluster optimization

5-8

Perform system verification

5-11

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
5-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Drive testing

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

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

The following is the optimization process that is performed prior to a network being
commercially deployed:
...................................................................................................................................................................................................

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

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

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.

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

PRELIMINARY

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

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

5-2

Drive test optimization process

Loaded cluster optimization,


to measure effects of cell breathing

Cluster performance verification,


to prove network meets customer criteria.

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

Perform system verification,

PRELIMINARY

Drive testing

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.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
5-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Drive testing

Planning
and preparation (site readiness)
...................................................................................................................................................................................................................................
Introduction

Before optimization is performed, site readiness checks should be performed. These


checks ensure that all cells are operating as required.
Important:
Site readiness checks are usually performed after a new network or new cells are
deployed and before the network goes operational. When they have been performed
and satisfactory performance can be guaranteed, the checks do not have to be made
anymore.
Checks

Site readiness checks include:

Spectrum clearance
Antenna check
Sector verification.

Spectrum clearance

Spectrum clearance ensures no external interference is present and sufficient guard


bands are obeyed.
Detection of interference can be very time-consuming and difficult once the UMTS
system is up and running. It is desirable to have a high degree of confidence that the
spectrum is cleared prior to any testing.
Antenna check

Antenna checks ensure that the antenna system is properly installed.


Proper installation must be checked with regard to:

PRELIMINARY

Type of antenna
Height of antenna
Tilt and azimuth of the antenna
Cabling.

Sector verification

Sector verification ensures the basic functionality of a sector. This includes basic call
processing and handovers. Measurements are made on UMTS signal levels to verify
that each sector is transmitting with the appropriate power levels and the correct
...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

5-4

Planning and preparation (site readiness)

scrambling code. The sector verification tests are used to detect hardware, software,
configuration and parameter errors.
The sector tests are performed using measurement software including a UMTS test
terminal. Once all data from the sector tests have beencollected, the measurement data
can be post-processed. If sector problems do occur, they need to be remedied and the
tests repeated until they are successful.

PRELIMINARY

Drive testing

Baseline existing system

The objective of baselining the existing system is to collect the RF performance


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

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
5-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Drive testing

Optimization
planning
...................................................................................................................................................................................................................................
Introduction

The optimization planning phase ensures system and tool readiness for RF optimization
before beginning the actual drive testing.
Perform RF parameter audit

At the beginning of the RF optimization process, RF parameters must be inspected for


consistency with the UMTS parameter catalogue.
Validate initial neighbor lists

An important step in the RF optimization planning phase is neighbor list verification.


The complete neighbor lists in the UMTS network are required to compare the
neighbor relations with network design plots. Neighbor relations need to be verified for
recent updates, validity and appropriateness. The recommended strategy is to have a
minimum number of neighbor relations in the neighbor lists.
Tool readiness

The drive test and post-processing tools need to be prepared for optimization.
Define clusters

Approximately 15-19 cell sites should be combined into one cluster. The actual number
used is based on network expansion as well as on the topographical environment. The
clusters are selected to provide a center cell site with two rings of surrounding cell
sites as shown in the figure below.
It may be worthwhile to utilize natural barriers such as hills and water bodies for
cluster separation to minimize overlap and influence between the clusters. A little cell
site overlap should remain between each cluster to ensure continuity across the
boundaries.

PRELIMINARY

The following figure shows

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

5-6

Optimization planning

B
1
2
A

9
3

4
5

11

10

PRELIMINARY

Drive testing

8
7

Drive route planning

Drive routes need to be defined for the following:

Sector Verification
Cluster Optimization
System Verification.

Planning drive routes for Sector Verification

Each cell site is driven approximately around the entire cell site. The selected drive
route should maintain a distance equal to 1/2 of the cell site radius. Sector drive routes
usually do not require customer approval.
Planning drive routes for Cluster Optimization

The routes for Cluster Optimization should consist of major roads, highways and
hotspots. Total time to drive all routes in a typical cluster should be approximately 6 to
8 hours.
One control route per cluster is chosen to verify system performance. A control route is
a subset of the optimization route and should be limited to about 1 to 2 hours.
Additional border routes are chosen to verify system performance on overlapping
cluster regions. A border route is chosen by the way it crosses the cluster borders
without going into the cluster areas.
Planning drive routes for System Verification.

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
5-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

The System Verification drive routes are used to collect the metrics for the Exit
Criteria. The routes are a combination of the cluster control routes and routes between
the individual clusters.

PRELIMINARY

Drive testing

Perform
cluster optimization
...................................................................................................................................................................................................................................
Introduction

RF optimization execution consists of drive tests, problem area identification,


verification drives, and final drives to ensure completion of exit criteria. The core
activity is to provide system tuning, as well as data collection and reporting. Design
changes relating to cell site layout modifications or adding a new cell site may be
considered if critical coverage holes are discovered during optimization.
Antennae corrective actions are more frequent for new deployments, such as Greenfield
or Overlay scenarios. They are uncommon in existing systems, such as Network
Expansion or Additional Carrier System. Fine tuning of the transmit powers is the most
effective procedure in already optimized networks.
Cluster size

Cluster optimization consists of procedures performed on geographical groupings of


cell sites that are large enough to have meaningful multi-cell site optimization. Several
factors make it worthwhile to optimize the system in manageable sized clusters. There
is a better focus on the area optimized, as smaller sector numbers make it easier to
track the parameter changes and the impact of their performance.
Another benefit to smaller cluster optimization is that multiple teams can optimize
different clusters simultaneously. Each team is able to maintain focus on its cluster
with minimal impact from other teams. In addition, smaller cluster optimization aids in
speeding up the system tests for commercial operation. Optimization in equipped
clusters can proceed simultaneously with installation of other clusters.
When to perform cluster optimization

PRELIMINARY

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

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

5-8

Perform cluster optimization

Multiple cluster testing

During multiple cluster testing the optimization teams working on neighbor clusters
must coordinate activities especially regarding neighbor relations, loading conditions or
possible overshooting sites.
Cluster optimization tools

PRELIMINARY

Drive testing

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

Cluster optimization consists of three phases:

Unloaded cluster optimization


Loaded cluster optimization
Cluster performance verification

Unloaded cluster optimization

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

Loaded testing produces a rise in the noise floor, which has the effect of shrinking the
coverage area (cell breathing). This causes an increase of negative Ec/Io values,
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
5-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

The second cluster optimization phase is performed under loaded conditions. The drive
routes for the loaded cluster optimization are exactly the same routes as those used for
the unloaded measurement drives.

PRELIMINARY

Drive testing

Perform cluster optimization

identify potential coverage holes, results in higher BLER, results in lower mobility
throughput, and more dropped calls.
The objective is to fix the problems observed by the field teams. This involves the
fine-tuning of RF parameters such as the transmit power or handover parameters.
Antenna re-adjustments (e.g. down-tilts, azimuths, patterns/types or heights) are also
occasionally performed.
Problem areas may be re-driven after implementing changes. It is not recommended to
drive a problem area more than three times. If the problem cannot be solved after three
test drives, either a root cause analysis is performed or cluster optimization proceeds
with the next cluster. It is generally not recommended to attempt resolution of
complex, time-intensive performance issues, such as location-specific problems like
cell site equipment failures. For such problems, it is advisable to report the behavior
and proceed with the next cluster. The problem cluster can be verified at a later stage.
Cluster performance verification

In the third phase, the cluster performance is measured against the cluster exit criteria.
The exit drives purpose is to verify and to confirm specific exit criteria demanded by
the customer.

PRELIMINARY

The final statistics from the cluster exit drive are presented to the customer for
approval. These statistics contain plots as well as data in tabular form. The approval to
exit the cluster is based on the terms of the contract. Approval with exceptions allows
the cluster to be exited under the condition that any problems will be resolved during
system wide optimization. If the cluster is not approved, loaded cluster optimization
must be continued until the troubles are resolved. A report specifying the reasons why
the exit drive did not pass the exit criteria is required.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

5-10

Perform
system verification
...................................................................................................................................................................................................................................
The final phase

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

PRELIMINARY

Drive testing

A comprehensive drive test

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

Specific problem areas identified by the system verification will be addressed on a


case-by-case basis after the entire drive has been completed. Individual Cluster
Optimization drives are used to fix existing coverage problems by adjusting transmit
powers and neighbor lists. In extreme situations, handover thresholds, channel power
parameters or other low tuning parameters may require modification. After any
parameter changes are made, another drive test must be completed to ensure the
surrounding regions are still performing properly.
Ready for live traffic

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
5-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

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

PRELIMINARY
PRELIMINARY

Drive testing

Perform system verification

uneven traffic conditions (e.g. traffic hot spots) and other dynamic effects which cannot
be modeled with simulated traffic loading.
It is possible for problem areas to remain after system verification is complete. An
example would be a coverage hole that will be fixed by a future cell site addition.
Such items must be well documented with alternative solutions proposed.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

5-12

PRELIMINARY

O ptimization process
6

Overview
...................................................................................................................................................................................................................................
Purpose

This lesson describes when optimization is performed during a network lifecycle and
the phases of the optimization process.
Contents
Lifecycle

6-2

Optimization process phases

6-4

Planning and preparation (site readiness)

6-8

Drive test optimization before live traffic

6-9

Information gathering

6-11

Information analysis

6-12

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
6-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Optimization process

Lifecycle
...................................................................................................................................................................................................................................
Network lifecycle

Stages of the lifecycle of a network:

Network design

Planning

Optimization

Implementation

Acceptance
criteria met?
Y

Network design
& implementation
Live network

In service
optimization

Network lifecycle stages

This shows the stages in the lifecycle of a network and the place of optimization in the
lifecycle:
...................................................................................................................................................................................................

Create a design for a UMTS network.


The design is typically created using (RF) design software.
...................................................................................................................................................................................................

PRELIMINARY

Optimize the design of the network.


The design is typically optimized for coverage or capacity using optimization software
that provides recommendations for:

Antenna tilt and orientation


Power levels.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

6-2

Lifecycle

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

Sites are planned and engineered according to the network design.


This translates the design in equipment in the real environment. This can mean that
there are differences between the design and the planned site.
The data from the planned site is used as input for optimization.

PRELIMINARY

Optimization process

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

During implementation the sites are built.


This can mean that there are differences between the planned site and the completed
site.
The data from the completed site is used as input for optimization.
...................................................................................................................................................................................................

When a site is completed, drive tests are usually started, to test basic operation. Data
from the drive tests, together with installation and parameter data from the site, is used
as input for optimization.
Refer to Drive test optimization before live traffic
...................................................................................................................................................................................................

When all sites are completed and tested, final (drive) tests are performed to check if
the network complies to the customer requirements.
If the customer accepts the network, the network goes live and commercial use can
begin.
...................................................................................................................................................................................................

In the live network, the continuous process of in service optimization now begins.
In service optimization can result in the need to update the network design to include
new cells, thus restarting this process.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
6-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Optimization process

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

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

PRELIMINARY

Optimization process flow:

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

6-4

Optimization process phases

Begin

Gather information

PRELIMINARY

Optimization process

Analyze information

Optimization
problem?

Sufficient
information?

Identify reason

Determine solution

Implement solution

Gather and analyze


information

Problem
solved?

Optimization process stages

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

Collect information.

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
6-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

The optimization process consists of the following stages:

PRELIMINARY

Optimization process

Optimization process phases

Result: Main information sources are:

Drive tests
Customer complaints
Performance measurements and KPIs.

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

Analyze information to determine if the network complies to requirements.


Result: Use automated (computer) tools to handle large quantities of complex data.
...................................................................................................................................................................................................

Determine if a problem is an optimization problem.


Result: For example, make sure the problem is not a fault.
...................................................................................................................................................................................................

If needed, gather additional information.


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

Identify the reason for the problem.


Result: For example:

Capacity
RF Coverage
Cell breathing.

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

Determine solutions for the problem.


Result: Typically there are multiple solutions to solve a problem. Choose the best
solution, for example based on:

Cost of implementation
Easy of implementation
Chance of success.

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

Implement the solution that was chosen.


Implement only one solution at a time.

PRELIMINARY

Result: Implementation can range from a simple change of a OMC-UPS parameter

to the entire process of design, planning, engineering and optimization and


commissioning of new cells and sites.
...................................................................................................................................................................................................

Gather and analyze information.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

6-6

Optimization process phases

Focus on the problem and the solution that was implemented.


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

When ...

then ...

the problem is solved,

go to Stage 1.

the problem is not solved,

Restore the original settings when parameters were


changed.

PRELIMINARY

Optimization process

go to Stage 6.

Continuous optimization

This process only has a Begin and not an End.


Optimization starts when a network goes live and never stops. Circumstances in a live
network always change and therefore optimization can not stop.
After an optimization problem has been solved, the optimization cycle continues,
detecting and solving other optimization problems.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
6-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Optimization process

Planning
and preparation (site readiness)
...................................................................................................................................................................................................................................
Before optimization is performed, site readiness checks should be performed. These
checks ensure that all cells are operating as required.
Important:
Site readiness checks are usually performed after a new network or new cells are
deployed and before the network goes operational. When they have been performed the
checks do not have to be made anymore.
Checks

Site readiness checks include:

Spectrum clearance

Antenna check
Sector verification.

Spectrum clearance

Spectrum clearance ensures no external interferences are present and sufficient guard
band are obeyed.
Antenna check

Antenna checks ensures that the antenna system is properly installed.


Proper installation must be checked with regard to:

Type of antenna
Tilt and azimuth of the antenna
Cabling.

Sector verification

PRELIMINARY

Sector verification ensures the basic functionality of a sector. This includes basic call
processing and hand overs. The sector verification tests are used to detect hardware,
software, configuration and parameter errors.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

6-8

Drive
test optimization before live traffic
...................................................................................................................................................................................................................................
Purpose

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

PRELIMINARY

Optimization process

Stages

This illustrates optimization steps that are performed before a network is commercially
deployed:
...................................................................................................................................................................................................

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

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

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.

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

Perform cluster optimization using drive tests.

Define clusters (group of cells)


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

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
6-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

This includes:

PRELIMINARY

Optimization process

Drive test optimization before live traffic

Loaded cluster optimization,


to measure effects of cell breathing

Cluster performance verification,


to prove network meets customer criteria.

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

Perform system verification,


to prove the entire network (all clusters) meets customer exit criteria.
Result

PRELIMINARY

The network is now ready for live traffic testing which leads into commercial service.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

6-10

Information
gathering
...................................................................................................................................................................................................................................
Information is needed to determine:

If there is an optimization problem


Optimization solutions
If the problem is solved.

PRELIMINARY

Optimization process

Information sources

As much information as possible should be used as input for optimization, so multiple


sources of information are needed.
The main information sources are:

Key performance indicators


Drive tests
Customer complaints.

Information from one of these sources, can trigger further investigation. During the
more detailed investigation information from other sources is gathered.
Key performance indicators

Key performance indicators (KPI) are used to determine if the network complies to the
levels of performance that are needed.
KPIs are calculated using measurements that are gathered by the OMC-UPS.
Changes in values of the key performance indicators, especially reaching thresholds are
often the first indication of an optimization problem.
Drive tests

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

Customer complaints can provide an indication of problems. Especially if multiple


complaints can be related to one source. Customer complaints can point to a problem
on a specific location, time or related to a resource.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
6-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Optimization process

Information
analysis
...................................................................................................................................................................................................................................
After information is collected, analysis of the information determines:
1.
2.
3.
4.

If there is an optimization problem


The source of the problem
Possible solutions for the problem
Consequences of implementing a solution.

Role of an engineer

The knowledge and experience of an engineer is an important tool in analyzing data.


An experienced optimization engineer has detailed knowledge of how processes and
protocols in a network work. This allows the engineer to link information and events to
a common source. An experienced engineer can even relate events to a single source,
that do not seem to relate to each other.
The engineer can identify possible sources of a problem, solutions that can solve the
problem and predict consequences of a solution (in a general way).
Data analysis software tools

Because of the scale and complexity of a network, engineers are not able to handle the
large volumes of detailed information that is available. Engineers can use software
tools to handle the information and determine if there are problems.
Software tools can also be used to determine the consequences of implementing a
solution in the network. Using models, software can simulate the impact on the
network of implementing a solution.

PRELIMINARY

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

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

6-12

PRELIMINARY

Part III: Optimization and


troubleshooting

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Chapter 7, UTRAN end-to-end key performance indicators

7-1

Chapter 8, Call availability and optimization

8-1

Chapter 9, Call reliability

9-1

Chapter 10, Call quality and optimization

10-1

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
III-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

7 TRAN end-to-end key


U
performance indicators

PRELIMINARY

Overview
...................................................................................................................................................................................................................................
Purpose

This lesson gives an overview over the key performance indicators (KPIs) for
end-to-end call setup and Quality of Service (QoS) within the UTRAN cluster.
What are KPIs?

KPIs are summarized quality and performance indicators which display a generalized
overall 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.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

Overview

Which KPIs are described here?

The following KPIs are described in this lesson:

KPIs for
KPIs
KPIs
KPIs
KPIs for
KPIs
KPIs
KPIs
KPIs for
KPIs

the Circuit Switched domain:


for mobile-originated call setups
for mobile-terminated call setups
for call drops
the Packet Switched domain:
for mobile-originated call setups
for mobile-terminated call setups
for call drops
Quality of Service monitoring
for Quality of Service monitoring in the Circuit Switched domain

KPIs for Quality of Service monitoring in the Packet Switched domain.

PRELIMINARY

Contents
KPIs for the Circuit Switched domain

7-3

KPI for Mobile-originated end-to-end call setup in the Circuit Switched


domain

7-4

KPI for Mobile-terminated end-to-end call setup in the Circuit Switched


domain

7-10

KPI for end-to-end call drops in the Circuit Switched domain

7-16

KPIs for the Packet Switched domain

7-21

KPI for Mobile-originated end-to-end call setup in the Packet Switched


domain

7-22

KPI for Mobile-terminated end-to-end call setup in the Packet Switched


domain

7-28

KPI for end-to-end call drops in the Packet Switched domain

7-34

KPIs for Quality of Service monitoring

7-39

KPIs for Quality of Service monitoring in the CS domain

7-40

KPIs for Quality of Service monitoring in the PS domain

7-42

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-2

KPIs for the Circuit Switched domain


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

PRELIMINARY

UTRAN end-to-end key performance indicators

Purpose

This lesson section gives an overview over the key performance indicators (KPIs) for
end-to-end call setup and Quality of Service (QoS) within the Circuit Switched (CS)
domain for the UTRAN cluster.
Contents
KPI for Mobile-originated end-to-end call setup in the Circuit Switched
domain

7-4

KPI for Mobile-terminated end-to-end call setup in the Circuit Switched


domain

7-10

KPI for end-to-end call drops in the Circuit Switched domain

7-16

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-originated end-to-end call setup in the Circuit


Switched
domain
...................................................................................................................................................................................................................................
Overview

This gives an overview over the key performance indicators for the mobile-originated
end-to-end call setup in the Circuit Switched domain (CS MO E2E).
Definitions for CS MO E2E call setups

End-to-end perspective The end-to-end perspective is defined as the data transfer


pathway from the User Equipment to the Circuit Core Network.
Mobile originated call A mobile originated call is defined when the first message has
been sent by the mobile.
In this case the first message is RRC Connection Request. It includes all UE RRC
connection repetitions as specified by N300 and T300 timers.
Call attempt A call attempt is defined when the mobile has sent the RRC
Connection Request to the Radio Access Network.
Successful call A mobile originated call is defined successful when the last message
before 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 ratio The Call setup success ratio is defined as the number of
successful calls divided by the number of call attempts.
Call setup accessibility ratio The Call setup accessibility ratio is defined as the
remainder ratio from the number of successful calls divided by the number of call
attempts.
Formula

The end-to-end Call setup success ratio is defined as follows:


E2E CS MO Call setup Success Ratio =

PRELIMINARY

E2E CS MO Accessibility Ratio =1 -

CC Alerting
RRC Connection Request

UE(part) + NodeB (part) + RNC(part) + CS_CN(part) + Others


RRC Connection Request

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-4

KPI for Mobile-originated end-to-end call setup in the


Circuit Switched domain

Signaling flow for CS MO E2E call setups


Figure 7-1 RRC connection establishment
UE

RRC

RRC
connection
establishment

Uu

Node B

Iub

RRC connection
request (cause)

RNC

Iu-cs

CN

PRELIMINARY

UTRAN end-to-end key performance indicators

RRC

NBAP

Radio Link
setup request

NBAP

NBAP

Radio Link
setup response

NBAP

RRC

RRC connection
setup

RRC

RRC

RRC connection
setup complete

RRC

RRC

Measurement
control

RRC

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-originated end-to-end call setup in the


Circuit Switched domain

Figure 7-2 MM and authentication


UE
RRC

Uu

Node B

Iub
Initial direct
transfer

MM CM
service request

MM authentication
and ciphering
request

MM authentication
and ciphering
response

Security
mode

MM CM
service accept
CC setup

RNC

CN

RRC
SCCP

Connection
request

SCCP

SCCP

Connection
confirm

SCCP

RANAP

Initial UE
message

RANAP

RANAP
RRC

Downlink
direct transfer

RRC

RRC

Initial direct
transfer

RRC

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Security mode
command

RANAP

RANAP

Security mode
complete

RANAP

RANAP

Common
ID

RANAP

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

RRC

Security mode
command

RRC

RRC

Security mode
complete

RRC

RRC

Downlink
direct transfer

RRC

RRC

Uplink
direct transfer

RRC
RANAP

PRELIMINARY

Iu-cs

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-6

KPI for Mobile-originated end-to-end call setup in the


Circuit Switched domain

Figure 7-3 RAB assignment and call connect


UE

Uu

Node B

Iub

RNC
RANAP

RAB assignment

NBAP

Radio Link
reconf.request

NBAP

NBAP

Radio Link
reconf.response

NBAP

RRC

Radio Bearer
setup request

RRC

RRC

Radio Bearer
setup complete

RRC
RANAP

CC call
proceeding

RANAP

RRC

Downlink
direct transfer

RRC

Downlink
direct transfer

CC connect
acknowledgement

RAB assignment
RANAP
request

RAB assignment
RANAP
response
Direct
transfer

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

RRC
RANAP

CC connect

CN

RRC
RANAP

CC alerting

Iu-cs

PRELIMINARY

UTRAN end-to-end key performance indicators

RRC

Downlink
direct transfer

RRC

RRC

Uplink
direct transfer

RRC

RANAP

KPI parts for E2E call setups


Parts

Counters

UE (part)

RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

RABFailEstab.T3

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-originated end-to-end call setup in the


Circuit Switched domain

Parts

Counters

NodeB (part)

SHO.FailRLSetupIubUTRANSide.NodeBRes
SHO.FailRLSetupIubUTRANSide.TransRes
RRC.FailConnEstab.RLSetupFailure
RRC.FailConnEstab.CAC
RRC.FailConnEstab.CAC
RABFailEstab.CodeStarv
RAB.FailEstabPSNoQueuing.DLIntfer

RNC (part)

VS.RRC.FailConnEstab.ProcessorLoad

General KPI counters for end-to-end call setup

The following counters are valid for all end-to-end call setups:
Counter name

Part

RRC.FailConnEstab.RLSetupFailure

Node B

No response from NodeB for a signaling Radio link


allocation (Signaling Radio Bearer). This is the number
of T_RLS expiry.

SHO.FailRLSetupIubUTRANSide.NodeBRes

Node B

Radio link setup failure response from NodeB for all


causes except code and power shortage for SRB
allocation

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more code are available

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more power is available

RRC.FailConnEstab.SetupIncomplete

UE

Number of T_U300 expiry no response from UE for


RRC connection establishment

UE

Number of RRC connection setup failure responded by


UE

RABFailEstab.CodeStarv

Node B

Number of RAB establishment failure because of no


more code are available

RAB.FailEstabPSNoQueuing.DLIntfer

Node B

Number of RAB establishment failure because of no


more power is available

RABFailEstab.T3

UE

Number of T_RB expiry no response from UE for RB


Setup

SHO.FailRLSetupIubUTRANSide.TransRes

PRELIMINARY

Description

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-8

Counter name

Part

KPI for Mobile-originated end-to-end call setup in the


Circuit Switched domain

Description

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-terminated end-to-end call setup in the Circuit


Switched
domain
...................................................................................................................................................................................................................................
Overview

This gives an overview over the key performance indicators for the mobile-terminated
end-to-end call setup in the Circuit Switched domain (CS MT E2E).
Definitions for CS MT E2E call setups

End-to-end perspective The end-to-end perspective is defined as the data transfer


pathway from the User Equipment to the Circuit Core Network.
Mobile terminated call A mobile terminated call is defined when the first message
has been sent by the network towards the mobile.
In this case the first message is RRC Paging Type 1. It includes all paging
repetitions as specified by UMSC counter and timer.
Call attempt A call attempt is defined when the network has sent the RRC Paging
Type 1 to the User Equipment.
Successful call A mobile terminated call is defined successful when the last message
before the speech or data phase start has been received.
In this case the last message is CC Alerting.
Call setup success ratio The Call setup success ratio is defined as the number of
successful calls divided by the number of call attempts.
Call setup accessibility ratio The Call setup accessibility ratio is defined as the
remainder ratio from the number of successful calls divided by the number of call
attempts.
Formula

The end-to-end Call setup success ratio is defined as follows:


E2E CS MT Call setup Success Ratio =

PRELIMINARY

E2E CS MT Accessibility Ratio =1 -

CC Alerting
RRC Paging Type 1

UE(part) + NodeB (part) + RNC(part) + CS_CN(part) + Others


RRC Paging Type 1

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-10

KPI for Mobile-terminated end-to-end call setup in the


Circuit Switched domain

Signaling flow for CS MT E2E call setups


Figure 7-4 RRC connection establishment
UE

Uu

Node B

Iub

RANAP

Paging Type 1
RRC

RRC

RRC
connection
establishment

RNC

Paging
RRC connection
request (cause)

Iu-cs
Paging

CN
RANAP

RRC

PRELIMINARY

UTRAN end-to-end key performance indicators

RRC

NBAP

Radio Link
setup request

NBAP

NBAP

Radio Link
setup response

NBAP

RRC

RRC connection
setup

RRC

RRC

RRC connection
setup complete

RRC

RRC

Measurement
control

RRC

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-terminated end-to-end call setup in the


Circuit Switched domain

Figure 7-5 MM and authentication


UE
RRC

Uu

Node B

Iub
Initial direct
transfer

MM paging
response

MM authentication
and ciphering
request
MM authentication
and ciphering
response

Security
mode

MM CM
service accept

CC setup

RNC

CN

RRC
SCCP

Connection
request

SCCP

SCCP

Connection
confirm

SCCP

RANAP

Initial UE
message

RANAP

RANAP
RRC

Downlink
direct transfer

RRC

RRC

Initial direct
transfer

RRC

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Security mode
command

RANAP

RANAP

Security mode
complete

RANAP

RANAP

Common
ID

RANAP

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

RRC

Security mode
command

RRC

RRC

Security mode
complete

RRC

RRC

Downlink
direct transfer

RRC

RRC

Uplink
direct transfer

RRC
RANAP

PRELIMINARY

Iu-cs

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-12

KPI for Mobile-terminated end-to-end call setup in the


Circuit Switched domain

Figure 7-6 RAB assignment and call connect


UE

Uu

Node B

Iub

RNC
RANAP

RAB assignment

NBAP

Radio Link
reconf.request

NBAP

NBAP

Radio Link
reconf.response

NBAP

RRC

Radio Bearer
setup request

RRC

RRC

Radio Bearer
setup complete

RRC
RANAP

CC call
confirm

RRC

Uplink
direct transfer

CC alerting

Uplink
direct transfer

CC connect

CC connect
acknowledgement

RRC

Uplink
direct transfer

Downlink
direct transfer

RAB assignment
RANAP
request

RAB assignment
RANAP
response

Direct
transfer

RANAP

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RRC
RANAP

RRC

CN

RRC
RANAP

RRC

Iu-cs

PRELIMINARY

UTRAN end-to-end key performance indicators

RRC

RRC

KPI parts for E2E call setups


Parts

Counters

UE (part)

RRC.FailConnEstab.SetupIncomplete
RAB.FailEstab.RBSetupFail

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-13
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

RABFailEstab.T3

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-terminated end-to-end call setup in the


Circuit Switched domain

Parts

Counters

NodeB (part)

SHO.FailRLSetupIubUTRANSide.NodeBRes
SHO.FailRLSetupIubUTRANSide.TransRes
RRC.FailConnEstab.RLSetupFailure
RRC.FailConnEstab.CAC
RRC.FailConnEstab.CAC
RABFailEstab.CodeStarv
RAB.FailEstabPSNoQueuing.DLIntfer

RNC (part)

VS.RRC.FailConnEstab.ProcessorLoad

General KPI counters for end-to-end call setup

The following counters are valid for all end-to-end call setups:
Counter name

Part

RRC.FailConnEstab.RLSetupFailure

Node B

No response from NodeB for a signaling Radio link


allocation (Signaling Radio Bearer). This is the number
of T_RLS expiry.

SHO.FailRLSetupIubUTRANSide.NodeBRes

Node B

Radio link setup failure response from NodeB for all


causes except code and power shortage for SRB
allocation

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more code are available

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more power is available

RRC.FailConnEstab.SetupIncomplete

UE

Number of T_U300 expiry no response from UE for


RRC connection establishment

UE

Number of RRC connection setup failure responded by


UE

RABFailEstab.CodeStarv

Node B

Number of RAB establishment failure because of no


more code are available

RAB.FailEstabPSNoQueuing.DLIntfer

Node B

Number of RAB establishment failure because of no


more power is available

RABFailEstab.T3

UE

Number of T_RB expiry no response from UE for RB


Setup

SHO.FailRLSetupIubUTRANSide.TransRes

PRELIMINARY

Description

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-14

Counter name

Part

KPI for Mobile-terminated end-to-end call setup in the


Circuit Switched domain

Description

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-15
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

PRELIMINARY

UTRAN end-to-end key performance indicators

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 call
drops in the Circuit Switched domain (CS E2E).
Definitions for CS E2E call drops

End-to-end perspective The end-to-end perspective is defined as the data transfer


pathway from the User Equipment to the Circuit Core Network.
Call drop A call is defined as dropped message when an Iu release procedure is
performed after theCC Alerting for abnormal call release with the Iu Release
complete message.
Successful call A call is defined successful when the last message before the speech
or 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 divided
by 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)

PRELIMINARY

CS_MO_E2E_Call_Success

CC Alerting

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-16

KPI for end-to-end call drops in the Circuit Switched


domain

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

PRELIMINARY

UTRAN end-to-end key performance indicators

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-17
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for end-to-end call drops in the Circuit Switched


domain

Signaling flow
Figure 7-7 Normal CS E2E call release, mobile-originated and mobile-terminated
UE
RRC

Uu

Node B

Iub
Uplink
direct transfer

CC Disconnect

CC Release

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Iu release
command

RANAP

Iu release
complete

RANAP

RRC

RRC

Uplink
direct transfer

RRC

RRC

RRC Connection
relelase

RRC

RRC

RRC Connection
release complete

RRC

Radio Link
deletion request

Radio Link
NBAP deletion response

NBAP
NBAP
RANAP

PRELIMINARY

CN

RANAP

Downlink
direct transfer

NBAP

Iu-cs

RRC

RRC

CC Release
complete

Iu Release

RNC

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-18

KPI for end-to-end call drops in the Circuit Switched


domain

Figure 7-8 CS E2E uplink radio link failure detection


UE
RRC

Uu

Node B

RNC

Iub

Iu-cs

CN

No
response
Radio Link
failure indication

NBAP

Iu release

Radio Link
deletion

NBAP
RANAP

Iu release
request

RANAP

RANAP

Iu release
command

RANAP

RANAP

Iu release
complete

RANAP

RANAP

SCCP
release

RANAP

NBAP

Radio Link
deletion request

NBAP

NBAP

Radio Link
deletion response

NBAP

PRELIMINARY

UTRAN end-to-end key performance indicators

Figure 7-9 CS E2E downlink radio link failure detection


UE

Uu

Node B

RNC

Iub

RRC

Cell update
(RL Failure)

RRC

RRC

Cell update
confirm

RRC

Iu-cs

CN

General KPI counters for end-to-end call drop

The following counters are valid for all end-to-end call drop:
Counter name
RAB.RelPS.Drop.DL_RLF

Part
RF

Description
Number of call drop because of Downlink radio link
failure
Number of call drop because of Uplink radio link failure

(Calculated)

Number of call drop during hard handover


inter-frequency.

RF

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-19
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

RAB.RelCS.Voice.CauseRLF, RF
RAB.RelCS.Data.CauseRLF

PRELIMINARY

UTRAN end-to-end key performance indicators

Counter name

Part

KPI for end-to-end call drops in the Circuit Switched


domain

Description

RAB.Rel.Drop.UESigConnRel

UE

Number of call drop initiated by the UE.

RAB.Rel.Drop.OpInterv

NodeB

Number of call drop for NodeB generated reasons

RAB.Rel.Drop.UETransDrnc, RNC
RAB.Rel.Drop.UEInactivity,

Number of call drop for RNC generated reasons.

Individual counters for CS E2E call drop

PRELIMINARY

The following individual counters refer to the CS E2E call drop:


Counter name

Part

Description

IRATHO.TRelocOverall

RF

number of call drop during hard


handover inter RAT

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-20

KPIs for the Packet Switched domain


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

PRELIMINARY

UTRAN end-to-end key performance indicators

Purpose

This lesson section gives an overview over the key performance indicators (KPIs) for
end-to-end call setup and Quality of Service (QoS) within the Packet Switched (PS)
domain for the UTRAN cluster.
Contents
KPI for Mobile-originated end-to-end call setup in the Packet Switched
domain

7-22

KPI for Mobile-terminated end-to-end call setup in the Packet Switched


domain

7-28

KPI for end-to-end call drops in the Packet Switched domain

7-34

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-21
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-originated end-to-end call setup in the Packet


Switched
domain
...................................................................................................................................................................................................................................
Overview

This gives an overview over the key performance indicators for the mobile-originated
end-to-end call setup in the Packet Switched domain (PS MO E2E).
Definitions for PS MO E2E call setups

End-to-end perspective The end-to-end perspective is defined as the data transfer


pathway from the User Equipment to the Packet Core Network.
Mobile originated call A mobile originated call is defined when the first message has
been sent by the mobile.
In this case the first message is RRC Connection Request. It includes all UE RRC
connection repetitions as specified by N300 and T300 timers.
Call attempt A call attempt is defined when the mobile has sent the RRC
Connection Request to the Radio Access Network.
Successful call A mobile originated call is defined successful when the last message
before 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 ratio The Call setup success ratio is defined as the number of
successful calls divided by the number of call attempts.
Call setup accessibility ratio The Call setup accessibility ratio is defined as the
remainder ratio from the number of successful calls divided by the number of call
attempts.
Formula

The end-to-end Call setup success ratio is defined as follows:


E2E PS MO Call setup Success Ratio =

PRELIMINARY

E2E PS MO Accessibility Ratio =1 -

SM Activate PDP Contect Accept


RRC Connection Request

UE(part) + NodeB (part) + RNC(part) + PS_CN(part) + Others


RRC Connection Request

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-22

KPI for Mobile-originated end-to-end call setup in the


Packet Switched domain

Signaling flow for PS MO E2E call setups


Figure 7-10 RRC connection establishment
UE

RRC

RRC
connection
establishment

Uu

Node B

Iub

RRC connection
request (cause)

RNC

Iu-ps

CN

PRELIMINARY

UTRAN end-to-end key performance indicators

RRC

NBAP

Radio Link
setup request

NBAP

NBAP

Radio Link
setup response

NBAP

RRC

RRC Connection
setup

RRC

RRC

RRC Connection
setup complete

RRC

RRC

Measurement
control

RRC

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-23
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-originated end-to-end call setup in the


Packet Switched domain

Figure 7-11 GMM attach


UE
RRC

Uu

Node B

Iub
Initial direct
transfer paging resp.

GMM attach
(request)

RNC

Security
mode

SCCP

Connection
request

SCCP

SCCP

Connection
confirm

SCCP

RANAP

Initial UE
message

RANAP

RRC

Downlink
direct transfer

RRC

RRC

Initial direct
transfer

RRC

PRELIMINARY

GMM attach
(complete)

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Security mode
command

RANAP

RANAP

Security mode
complete

RANAP

RANAP

Common
ID

RANAP

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

RRC

Security mode
command

RRC

RRC

Security mode
complete

RRC

GMM attach
(accept)

CN

RRC

RANAP

GMM attach
(authentication
and ciphering)

Iu-ps

RRC

Downlink
direct transfer

RRC

RRC

Uplink
direct transfer

RRC
RANAP

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-24

KPI for Mobile-originated end-to-end call setup in the


Packet Switched domain

Figure 7-12 RAB assignement and PDP context activation


UE

SM
PDP context
activation
(request)

Uu

Node B

Iub

RNC

Uplink
direct transfer

RRC

RRC
RANAP
RANAP

NBAP

Radio Link
reconf.request

NBAP

NBAP

Radio Link
reconf.response

NBAP

RAB assignment
RRC

Radio Bearer
setup

RRC

RRC

Radio Bearer
setup complete

RRC
RANAP

SM
PDP context
activation
(accept)

RANAP

Downlink
direct transfer

RRC

CN

Iu-ps

Direct
transfer

RANAP

RAB assignment
RANAP
request

PRELIMINARY

UTRAN end-to-end key performance indicators

RAB assignment
RANAP
response
Direct
transfer

RANAP

RRC

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-25
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-originated end-to-end call setup in the


Packet Switched domain

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

RRC.FailConnEstab.RLSetupFailure

Node B

No response from NodeB for a signaling Radio link


allocation (Signaling Radio Bearer). This is the number
of T_RLS expiry.

SHO.FailRLSetupIubUTRANSide.NodeBRes

Node B

Radio link setup failure response from NodeB for all


causes except code and power shortage for SRB
allocation

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more code are available

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more power is available

RRC.FailConnEstab.SetupIncomplete

UE

Number of T_U300 expiry no response from UE for


RRC connection establishment

UE

Number of RRC connection setup failure responded by


UE

RABFailEstab.CodeStarv

Node B

Number of RAB establishment failure because of no


more code are available

SHO.FailRLSetupIubUTRANSide.TransRes

PRELIMINARY

Description

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-26

Counter name

Part

KPI for Mobile-originated end-to-end call setup in the


Packet Switched domain

Description

RAB.FailEstabPSNoQueuing.DLIntfer

Node B

Number of RAB establishment failure because of no


more power is available

RABFailEstab.T3

UE

Number of T_RB expiry no response from UE for RB


Setup

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-27
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-terminated end-to-end call setup in the Packet


Switched
domain
...................................................................................................................................................................................................................................
Overview

This gives an overview over the key performance indicators for the mobile-terminated
end-to-end call setup in the Packet Switched domain (PS MT E2E).
Definitions for PS MT E2E call setups

End-to-end perspective The end-to-end perspective is defined as the data transfer


pathway from the User Equipment to the Packet Core Network.
Mobile terminated call A mobile terminated call is defined when the first message
has been sent by the network towards the mobile.
In this case the first message is RRC Paging Type 1. It includes all paging
repetitions as specified by Packet Core Network counter and timer.
Call attempt A call attempt is defined when the network has sent the RRC Paging
Type 1 to the User Equipment.
Successful call A mobile terminated call is defined successful when the last message
before the speech or data phase start has been received.
In this case the last message is SM Activate PDP Context Accept.
Call setup success ratio The Call setup success ratio is defined as the number of
successful calls divided by the number of call attempts.
Call setup accessibility ratio The Call setup accessibility ratio is defined as the
remainder ratio from the number of successful calls divided by the number of call
attempts.
Formula

The end-to-end Call setup success ratio is defined as follows:


E2E PS MT Call setup Success Ratio =

PRELIMINARY

E2E PS MT Accessibility Ratio = 1 -

SM Activate PDP Contect Accept


RRC Paging Type 1

UE(part) + NodeB (part) + RNC(part) + PS_CN(part) + Others


RRC Paging Type 1

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-28

KPI for Mobile-terminated end-to-end call setup in the


Packet Switched domain

Signaling flow for PS MT E2E call setups


Figure 7-13 Paging and RRC connection establishment
UE

Uu

Node B

Iub

RANAP

Paging Type 1
RRC

RRC

RRC
connection
establishment

RNC

Paging
RRC connection
request (cause)

Iu-ps
Paging

CN
RANAP

RRC

PRELIMINARY

UTRAN end-to-end key performance indicators

RRC

NBAP

Radio Link
setup request

NBAP

NBAP

Radio Link
setup response

NBAP

RRC

RRC connection
setup response

RRC

RRC

RRC connection
setup complete

RRC

RRC

Measurement
control

RRC

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-29
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-terminated end-to-end call setup in the


Packet Switched domain

Figure 7-14 GMM attach


UE
RRC

Uu

Node B

Iub
Initial direct
transfer paging resp.

GMM paging
response

RRC

GMM attach
(request)

Initial direct
transfer

RNC

Security
mode

SCCP

Connection
request

SCCP

SCCP

Connection
confirm

SCCP

RANAP

Initial UE
message

RANAP

Initial UE
message

RANAP

RRC
RANAP

RRC

Downlink
direct transfer

RRC

RRC

Initial direct
transfer

RRC

PRELIMINARY

GMM attach
(complete)

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Security mode
command

RANAP

RANAP

Security mode
complete

RANAP

RANAP

Common
ID

RANAP

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

RRC

Security mode
command

RRC

RRC

Security mode
complete

RRC

GMM attach
(accept)

CN

RRC

RANAP

GMM attach
(authentication
and ciphering)

Iu-ps

RRC

Downlink
direct transfer

RRC

RRC

Uplink
direct transfer

RRC
RANAP

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-30

KPI for Mobile-terminated end-to-end call setup in the


Packet Switched domain

Figure 7-15 RAB assignment and PDP context activation


UE

SM
PDP context
activation
(request)

Uu

RRC

Node B

Iub

Uplink
direct transfer

RNC

RANAP

NBAP

Radio Link
reconf.request

NBAP

NBAP

Radio Link
reconf.request

NBAP

RRC

Radio Bearer
setup response

RRC

RRC

Radio Bearer
setup complete

RRC
RANAP

SM
PDP context
activation
(accept)

RANAP

RRC

Downlink
direct transfer

CN

RRC
RANAP

RAB assignment

Iu-ps

Direct
transfer

RANAP

RAB assignment
RANAP
request

PRELIMINARY

UTRAN end-to-end key performance indicators

RAB assignment
RANAP
response
Direct
transfer

RANAP

RRC

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-31
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for Mobile-terminated end-to-end call setup in the


Packet Switched domain

PS-MT-E2E-call setup
Parts

Counters

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)

NodeB (part)

RRC_Fail(Err_NodeB) + RRC_Fail(T_RLS) +
Reject_RNC(RRC_code) + Reject_RNC(RRC_pwr) +
RAB_Fail (code) + RAB_Fail (Pwr) + RAB_Fail(Err_
NodeB) + RAB_Fail(T_RL_R) + NodeB_Errors

RNC (part)

Sccp_Fail(Timer) + RAB_Fail(TRabAssg) + RNC_Errors

PS_CN (part)

Reject_PS_CN. + Sccp_Fail(blckg) + Abnormal_Release_


before_PDP_accept

Interfaces (part)

Iu (Fail) + Iub (Fail) + Iur (Fail)

Others

Any other call setup failure which excludes the above


mentioned but occurs after RACH and before PDP
context accept

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

PRELIMINARY

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:
....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-32

Counter name

Part

KPI for Mobile-terminated end-to-end call setup in the


Packet Switched domain

Description

RRC.FailConnEstab.RLSetupFailure

Node B

No response from NodeB for a signaling Radio link


allocation (Signaling Radio Bearer). This is the number
of T_RLS expiry.

SHO.FailRLSetupIubUTRANSide.NodeBRes

Node B

Radio link setup failure response from NodeB for all


causes except code and power shortage for SRB
allocation

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more code are available

RRC.FailConnEstab.CAC

Node B

Number of RRC connection reject that RNC sends to the


mobile because of no more power is available

RRC.FailConnEstab.SetupIncomplete

UE

Number of T_U300 expiry no response from UE for


RRC connection establishment

UE

Number of RRC connection setup failure responded by


UE

RABFailEstab.CodeStarv

Node B

Number of RAB establishment failure because of no


more code are available

RAB.FailEstabPSNoQueuing.DLIntfer

Node B

Number of RAB establishment failure because of no


more power is available

RABFailEstab.T3

UE

Number of T_RB expiry no response from UE for RB


Setup

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

SHO.FailRLSetupIubUTRANSide.TransRes

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-33
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

PRELIMINARY

UTRAN end-to-end key performance indicators

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 call
drops in the Packet Switched domain (PS E2E).
Definitions for PS E2E call drops

End-to-end perspective The end-to-end perspective is defined as the data transfer


pathway from the User Equipment to the Packet Core Network.
Call drop A call is defined as dropped message when an Iu release procedure is
performed after theSM Activate PDP Context Accept for abnormal call release
with the Iu Release complete message.
Successful call A call is defined successful when the last message before 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 retainability The Call retainability is defined as the number of call drops divided
by 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)

PRELIMINARY

PS_MO_E2E_Call_Success

SM Activate PDP Context Accept

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-34

KPI for end-to-end call drops in the Packet Switched


domain

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

PRELIMINARY

UTRAN end-to-end key performance indicators

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

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-35
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

KPI for end-to-end call drops in the Packet Switched


domain

Signaling flow
Figure 7-16 Normal PS E2E call release, mobile-originated and mobileterminated.
UE
RRC

Uu

Node B

Iub
Uplink
direct transfer

Request
SM deactivate
PDP context
Accept

RANAP

Direct
transfer

RANAP

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Direct
transfer

RANAP

RANAP

Iu release
command

RANAP

Iu release
complete

RANAP

Uplink
direct transfer

RRC
RANAP

GMM detach

RRC

RRC

Downlink
direct transfer

RRC

RRC

Uplink
direct transfer

RRC

Complete

RRC

RRC Connection
relelase

RRC

RRC

RRC Connection
release complete

RRC

NBAP

Radio Link
deletion request

Radio Link
NBAP deletion response

PRELIMINARY

RANAP

RRC

Request

Iu Release

Direct
transfer

RRC

Uplink
direct transfer

CN

RANAP

Downlink
direct transfer

RRC

Iu-cs

RRC

RRC

Complete

Accept

RNC

NBAP
NBAP
RANAP

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-36

KPI for end-to-end call drops in the Packet Switched


domain

Figure 7-17 PS E2E uplink radio link failure detection


UE
RRC

Uu

Node B

RNC

Iub

Iu-ps

CN

No
response
Radio Link
failure indication

NBAP

Iu release

Radio Link
deletion

NBAP
RANAP

Iu release
request

RANAP

RANAP

Iu release
command

RANAP

RANAP

Iu release
complete

RANAP

RANAP

SCCP
release

RANAP

NBAP

Radio Link
deletion request

NBAP

NBAP

Radio Link
deletion response

NBAP

PRELIMINARY

UTRAN end-to-end key performance indicators

Figure 7-18 PS E2E downlink radio link failure detection


UE

Uu

Node B

RNC

Iub

RRC

Cell update
(RL Failure)

RRC

RRC

Cell update
confirm

RRC

Iu-ps

CN

General KPI counters for end-to-end call drop

The following counters are valid for all end-to-end call drop:
Counter name
RAB.RelPS.Drop.DL_RLF

Part
RF

Description
Number of call drop because of Downlink radio link
failure
Number of call drop because of Uplink radio link failure

(Calculated)

Number of call drop during hard handover


inter-frequency.

RF

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-37
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

RAB.RelCS.Voice.CauseRLF, RF
RAB.RelCS.Data.CauseRLF

PRELIMINARY

UTRAN end-to-end key performance indicators

Counter name

Part

KPI for end-to-end call drops in the Packet Switched


domain

Description

RAB.Rel.Drop.UESigConnRel

UE

Number of call drop initiated by the UE.

RAB.Rel.Drop.OpInterv

NodeB

Number of call drop for NodeB generated reasons

RAB.Rel.Drop.UETransDrnc, RNC
RAB.Rel.Drop.UEInactivity,

Number of call drop for RNC generated reasons.

Individual counters for PS E2E call drop

PRELIMINARY

The following individual counters refer to the PS E2E call drop:


Counter name

Part

Description

VS.IRATHO.TimeoutOutPSUTRAN

RF

Number of call drop during


hard handover inter RAT

SM.AttDeactPdpContextSgsn.38

PS_CN

Number of call drop for PS CN


generated reasons

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-38

KPIs for Quality of Service monitoring


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

PRELIMINARY

UTRAN end-to-end key performance indicators

Purpose

This lesson gives an overview over the key performance indicators (KPIs) for Quality
of Service (QoS) monitoring within the UTRAN cluster.
Contents
KPIs for Quality of Service monitoring in the CS domain

7-40

KPIs for Quality of Service monitoring in the PS domain

7-42

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-39
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

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 attributes


that are typically associated with a particular service.
There are four different QoS classes which must be considered:

Conversational class (for example voice)


Streaming class (for example video, audio)
Interactive class (for example web browsing)
Background class (for example file transfer).

The most important measurable parameters used are:

Delay
The interval between transmitting and receiving packets between two reference
points.
In this case the delay is referred to as RAB setup time.
Delay variation
In this case the delay variations are referred to as Achieved Bitrate distribution
and Transfer delay distribution.
Loss rate
In this case the loss rates are referred to as SDU error ratio and Residual bit
error ratio.

KPIs for QoS monitoring on network level

PRELIMINARY

KPIs for QoS monitoring in the CS domain


per RAB (i)

Conversational

Streaming

Delay in sec

<1

~1

RAB(i) setup time without queuing

RAB(i) setup time with queuing

Achieved Bitrate distribution

Transfer delay

SDU Error Ratio

Residual Bit Error Ratio

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-40

KPIs for Quality of Service monitoring in the CS domain

Formula

When more than one cell is the active set, for each cell the following KPI must be
available per traffic class:
CS RAB Assignment Success Rate (i) =

CS RAB Assignment Success (i)


CS RAB Assignment Attempt (i)

PRELIMINARY

UTRAN end-to-end key performance indicators

i = Traffic_Class (conversational, streaming)

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-41
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

UTRAN end-to-end key performance indicators

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 attributes


that are typically associated with a particular service.
There are four different QoS classes which must be considered:

Conversational class (for example voice)


Streaming class (for example video, audio)
Interactive class (for example web browsing)
Background class (for example file transfer).

The most important measurable parameters used are:

Delay
The interval between transmitting and receiving packets between two reference
points.
In this case the delay is referred to as RAB setup time.
Delay variation
In this case the delay variations are referred to as Achieved Bitrate distribution
and Transfer delay distribution.
Loss rate
In this case the loss rates are referred to as SDU error ratio and Residual bit
error ratio.

KPIs for QoS monitoring on network level

PRELIMINARY

KPIs for QoS monitoring in PS domain


per RAB (i)

Conversational

Streaming

Interactive

Background

Delay in sec

<1

~1

< 10

> 10

RAB(i) setup time without queuing

RAB(i) setup time with queuing

AchievedBitrate distribution

Transfer delay

SDU Error Ratio

X1

X1

X1

X1

Residual Bit Error Ratio

X1

X1

X1

X1

Notes:

1.

Not guaranteed values

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

7-42

KPIs for Quality of Service monitoring in the PS domain

Formula

When more than one cell is the active set, for each cell the following KPI must be
available per traffic class:
PS RAB Assignment Success Rate (i) =

PS RAB Assignment Success (i)


PS RAB Assignment Attempt (i)

PRELIMINARY

UTRAN end-to-end key performance indicators

i = Traffic_Class (conversational, streaming, interactive, background)

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
7-43
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

PRELIMINARY

8 all availability and


C
optimization

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Call availability

8-2

Call availability

8-3

Determination of accessibility problem

8-5

Network level accessibility

8-6

Introduction

8-7

Cell re-selection failures

8-8

RACH access procedure failures

8-9
8-11

Introduction to RRC connection establishment

8-12

Call admission control failures

8-14

Radio link setup analysis

8-15

RRC connection setup failure

8-16

Paging failures

8-17

RAB establishment analysis

8-18

Introduction

8-19

Dynamic bearer control failures

8-22

Radio link reconfiguration failures

8-23

Radio bearer establishment failures

8-24

No answer from UE

8-25

Code starvation

8-26

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

RRC connection establishment analysis

PRELIMINARY

Call availability and optimization

Call availability
Overview
...................................................................................................................................................................................................................................
Purpose

PRELIMINARY

Contents
Call availability

8-3

Determination of accessibility problem

8-5

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-2

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.

PRELIMINARY

Call availability and optimization

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

The call setup process consists of different procedures depending on what kind of
session/service type is required (for example CS or PS). RRC Connection
Establishment and RAB Establishment procedure are the main procedures on the
UTRAN side.
With the RRC Connection Establishment procedure, the UE requests resources from
the UTRAN and executes the transition from Idle to CELL_DCH state, entering the
UTRAN RRC Connected Mode. The UTRAN allocates resources in terms of radio
links.
With the RAB Establishment procedure, all the requested resources are allocated by the
Core Network and by the UTRAN in terms of Radio Access Bearers (RABs) while the
UE 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 pass
the following states:

From the power-off state to the Idle state


From the Idle state to the Cell_DCH state.

Call setup failures

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

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

PRELIMINARY

Call availability and optimization

Call availability

Network level access phase

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

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

PRELIMINARY

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

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-4

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, of
the UMTS mobile subscriber about the network accessibility.

PRELIMINARY

Call availability and optimization

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 specific RAB
Establishment Success Rate with 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 many
different issues. Therefore, it is advised to localize the issue by analyzing the
performance measurements and KPIs separated over the accessibility call phases:

Network level access phase


RRC connection establishment phase
RAB establishment phase.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

Network level accessibility


Overview
...................................................................................................................................................................................................................................
Purpose

PRELIMINARY

Contents
Introduction

8-7

Cell re-selection failures

8-8

RACH access procedure failures

8-9

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-6

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

In general any call-related procedure initiated via RRC messages sent by the UE to the
UTRAN is preceded by two preliminary procedures such as cell selection/re-selection
and Random Access Detection.

PRELIMINARY

Call availability and optimization

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


procedure.
Not visible for performance management

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

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

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

Once the UE is able to select a cell and attach to the network, it should continuously
perform the cell re-selection process.
If the parameters for cell re-selection have too much hysteresis, the UE will possibly
access a cell, which is not the optimal choice in terms of interference. On the other
hand, lower re-selection hysteresis values will make the effect of ping-pong
re-selections more likely.
In case the UE selects a cell within a different URA, the UE will start the URA update
procedure, pegging the PM counter NumUraUpdateRequest.UraChange.
Measurable using URA updates

An indication whether ping-ponging is occurring during the cell re-selection process


can be retrieved by looking at the number of URA update messages that are received
from the mobiles that are in the URA_PCH state.
PMs / KPIs indications

An increased number of RRC Connection Establishment failures in combination with


high hysteresis values for cell reselection can indicate cell reselection problems causing
this behavior. The parameters should be adapted.
In case the UE selects a cell within a different URA, the UE will start the URA update
procedure, pegging the PM counter NumUraUpdateRequest.UraChange. The number of
Cell Update requests due to reselection is pegged by NumCellUpdateRequest.CellReselect. Only if the reselection appears at the LA or RA boundaries in the phase where the
UE transitions out of URA_PCH and before the Cell Update Confirm message arrives.
This is considered as rather rare event.
Nevertheless these PMs should increase for hysteresis values that are set too low in
cells at a URA / LA / RA boundary when compared to a properly set cell with similar
traffic.
Related PMs / KPIs

PRELIMINARY

The related PMs / KPIs are:

NumCellUpdateRequest.CellReselect
NumUraUpdateRequest.UraChange.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-8

RACH
access procedure failures
...................................................................................................................................................................................................................................
Overview

The RACH Access Procedure is used in the following cases:

When
When
When
When

attaching to the network


setting up a call
answering to a page
performing a Location Update/Routing Area update.

PRELIMINARY

Call availability and optimization

The RACH procedure has been successfully performed when the RRC Connection
Request message is received by the RNC upon successful decoding at the Node B.
RACH procedure

The RACH is transmitted on the physical layer in two separated parts:


1. A certain number of RACH Preambles are sent. The power of the first RACH
Preamble is relatively low and is calculated using open loop power control.
2. Each of the following RACH Preambles are transmitted with an increased power
till an acknowledgment (ACK) is received on the AICH.
3. After receiving the AICH the UE transmits the RACH Message Part with an
embedded RRC Connection Request message.
The signaling flow of a basic RACH transmission procedure:
Ue

Uu

Node B

Iub

RNC

RACH Preamble
RACH Preamble

RACH Preamble

Access indication
(AICH)
RRC

RACH message
(RRC Connection Request)

RRC

NumBadRACHTransBlock
NumGoodRACHTransBlock

Guard timer T300 (determined by UTRAN parameter t300) and N300 (determined by
UTRAN parameter n300) is supervising the transmission of the RRC Connection
Request message on the UE side.
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Timer settings

PRELIMINARY

Call availability and optimization

RACH access procedure failures

Poor settings of timer n300 may result in insufficient retransmission of the RACH
message and poor settings for timer t300 may result in RACH messages being
retransmitted too early or too late and thus affecting the procedures that initiated the
RACH access (for example Call setup).
Upon reception of the RRC Connection Request message at the RNC, PM counter
NumRRCConnAtt is incremented by one. When the UE is not able to either
successfully attach to the network or successfully perform a Location Update, the Cell
Selection/Reselection procedures fails and the UE enters a limited service state.
Possible failing reasons

Possible reasons why the RACH access procedure could fail are:

The Node B does not successfully decode any of the RACH Preambles
The UE does not receive an ACK on the AICH
The UE is receiving a NACK on the AICH
The Node B does not successfully decode the RACH Message Part
Unsuccessful retransmission of the RACH Message Part.

PMs / KPIs indications

NumRRCConnAtt is triggered on the RNC after reception of the RRC Connection


Request message independent of the establishment cause. Low values at a specific
NodeB of NumRRCConnAtt are indicative of problems; nevertheless this counter
cannot prove that there are actually problems because e.g. NACKs sent by Node B on
AICH are not counted. It may be that at a particular cell low traffic is resulting in low
values of counter NumRRCConnAtt.
PM counter NumBadRACHTransBlock and NumGoodRACHTransBlock may be used to
arrive at the ratio between number of RACH TBs received with bad CRC to total
number of RACH TBs. A high value for this ratio may be indicative of problems with
the quality over the RACH.
PM counter ChannelOccupRateRACH is the ratio of total bits transferred on the RACH
to maximum bits available for RACH usage (service rate) per granularity period. If this
ratio is very high the resources on the RACH may not be sufficient.
Related PMs / KPIs

PRELIMINARY

The related PMs / KPIs are:

NumRRCConnAtt
NumBadRACHTransBlock
NumGoodRACHTransBlock
ChannelOccupRateRACH.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-10

RRC connection establishment analysis


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

PRELIMINARY

Call availability and optimization

Purpose
Contents
Introduction to RRC connection establishment

8-12

Call admission control failures

8-14

Radio link setup analysis

8-15

RRC connection setup failure

8-16

Paging failures

8-17

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-11
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

Introduction
to RRC connection establishment
...................................................................................................................................................................................................................................
RRC Connection establishment procedure

In general the RRC connection establishment procedure may occur in different


scenarios such as:

Network attach (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 the
RRC Connection Request message. This means that cell selection/re-selection as well
as Random Access Detection procedures have been successfully completed.
Call setup stages

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

Uu

Node B

Iub
RRC Connection Req
(RACH)

RRC

RNC

RRC
CAC

NBAP

RL Setup Request

1
NumRRCConRej

NBAP

2
NBAP

PRELIMINARY

RRC

RL Setup Response

RRC Connection Setup


(CCCH over FACH)

NBAP

RRC

3
RRC

RRC Connection Setup Complete


(DCCH over DCH)

NumRRCConEstFail

RRC

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-12

Introduction to RRC connection establishment

Related PMs / KPIs

The related PMs / KPIs are:

NumRRCConnEstFail
NumRRCConnRej
Successful RRC connections establishment rate.

PRELIMINARY

Call availability and optimization

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 RRC
Connections Failures occurring during other procedures such as Network Attach, SMS
and Location Update.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-13
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

Call
admission control failures
...................................................................................................................................................................................................................................
Introduction

Call admission control (CAC) is used to prevent overload of the system. Load
conditions for the downlink are based on the total transmit power of the cell. The
uplink load measure is the measured RSSI value relative to the typical noise floor that
was estimated using long term measurements.
If the defined load thresholds for CAC are exceeded the RRC connection establishment
request is denied and a RRC Connection Reject message with cause Congestion is sent
by the RNC to the UE.
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 counter


NumRRCConnRej that may be triggered not only in case of CAC but also in case of
RRC Connection Reject message sent to the UE with unspecified cause. If the values
of this counter indicate that overload situations have occurred over long periods of
time, CAC may be one reason for the call setup problems experienced.
Load measurements

PRELIMINARY

Other counters related to system load such as Forward Power Overload Duration,
Average Transmitted Carrier Power, Maximum Transmitted Carrier Power and
Maximum Received Signal Strength Indicator may be used to verify that the load in the
cell is fairly high, which would increase the probability for call setup failures.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-14

Radio
link setup analysis
...................................................................................................................................................................................................................................
Introduction

Once the RNC has verified that the requested resources have passed the Call
Admission Control check, the RNC requests the Node B to allocate these resources
through the NBAP Radio Link Setup procedure.

PRELIMINARY

Call availability and optimization

In general at least one radio link has to be set up. In the case where the UE is in a
soft/softer handover region during call setup more than one radio link has to be set up.
Note: A radio link is associated to one cell, while a RAB is associated to one UE per
service type.
Radio link setup failure

In order to allocate the requested resources the RNC sends the Radio Link Setup
Request message to the relevant Node B. Upon reception of Radio Link Setup Request
message, the Node B reserves the necessary resources and sends back the Radio Link
Setup Response message to the RNC. If the establishment of at least one radio link
fails then the Node B sends back the Radio Link Setup Failure message to the RNC.
Related PMs / KPIs

The related PMs / KPIs are:

NumRLSetupFail.NodeBRes
NumRLSetupFail.TransRes.

Abnormal NumRLSetupFail.NodeBRes values

High values of this counter indicate that there where RL failures due to missing Node
B resources. This indicates possible UMTS Channel Unit (UCU) outages or resource
shortages.
Specific Node B counters such as Total Channel Element Usage and Dedicated
Channel Element Usage provide important information on the Node B traffic and
indicate whether the Node B capacity in terms of the availability of physical resources
is close to the limit.
Abnormal NumRLSetupFail.TransRes values

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-15
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

High values of this counter indicate that there are failures due to missing Transport
Resource. This indicates that transport resource is unavailable due to missing binding
IDs for the transport bearer.

PRELIMINARY

Call availability and optimization

RRC
connection setup failure
...................................................................................................................................................................................................................................
Introduction

Once the NBAP radio link setup procedure has been successfully completed and the
transport bearer has been established and synchronized, the UTRAN initiates the RRC
connection setup procedure to complete the RRC connection establishment.
The performance measurement NumRRCConnEstFail is used to record failures
occurred during the RRC Connection Setup procedure.
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 attributes uERRCConnSetupResponseTimer and


maxRRCConnSetupRetries

PRELIMINARY

The RRC Connection Setup message is not successfully decoded due to poor
FACH coverage
The RNC cannot successfully decode the RRC Connection Setup Complete
message.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-16

Paging
failures
...................................................................................................................................................................................................................................
Paging procedure

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

PRELIMINARY

Call availability and optimization

In a successful case the UE receives and correctly decodes the paging message and
sends back the RRC Connection Request message with the relevant cause to the
UTRAN (this means Terminating High Priority Signaling for PS calls and Terminating
Conversational Call for Voice calls).
However it may occur that the UE either does not receive or does not correctly decode
the Paging message.
PMs / KPIs indications

The failure causes can be identified via UTRAN counter NumPageAttDiscard, PCH
Traffic can be evaluated via counter ChannelOccupRatePCH.
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 poor
PCH coverage.
Also issues on transport network may impact the Paging procedure as:

over Iu interfaces RANAP protocol takes care of transmitting the paging


over Iub interface, the PCH is carried by the AAL2 protocol
over RACH (paging response in uplink direction).
problems over the RACH (paging response in uplink direction).

In all these cases the MT call is not successfully completed.


...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-17
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Transport
messages
Transport
Transport
Transport

PRELIMINARY

Call availability and optimization

RAB establishment analysis


Overview
...................................................................................................................................................................................................................................
Purpose

PRELIMINARY

Contents
Introduction

8-19

Dynamic bearer control failures

8-22

Radio link reconfiguration failures

8-23

Radio bearer establishment failures

8-24

No answer from UE

8-25

Code starvation

8-26

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-18

Introduction
...................................................................................................................................................................................................................................
RAB establishment procedure

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

PRELIMINARY

Call availability and optimization

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 SGSN
for PS calls or 3G-MSC for CS calls, upon receipt of an RRC/RANAP Uplink Direct
Transfer message from the UE requesting either a Packet Data Protocol (PDP) Context
Activation (PS call) or a Call Setup (CS call). This procedure is successfully completed
upon receipt of RANAP RAB Assignment Response message at the core network.
RAB establishment call flow

An example RAB establishment call flow:

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-19
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

UE

Introduction

Node B
Uu

SRNC

Iu-ps

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

CN

RANAP Direct Transfer


(PS: PDP Context Request
CS: Call Setup Request)

RANAP Direct Transfer


(CS ONLY: Call Setup Request)

RRC DL Direct Transfer


(CS ONLY: Call Proceeding)

RANAP RAB
assignment request
2
ALCAP Iu transport bearer establishment

DBC

NumRABEstFail.Load

NumRLReconfigFail.sum

NBAP Radio link


reconfiguration prepare
NBAP Radio link
reconfiguration ready
ALCAP Iub transport bearer establishment
Node B RNC data transport bearer sync
Radio link reconfiguration
commit

RRC Radio bearer setup


(DCCH over DCH)

NumRABEstFail.RBSetupFail
NumRABEstFail.T3

RRC Radio bearer setup Comp


(DCCH over DCH)
RANAP RAB Assignment
Response

RANAP Direct Transfer


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

PRELIMINARY

RAB establishment stages

The RAB Establishment procedure for both PS and CS calls may be categorized into
the following basic stages:
1.
2.
3.
4.

PDP Context Activation (PS) or Call Setup (CS) Request by the UE


RANAP RAB Assignment Request
Dynamic Bearer Control at the RNC
NBAP Radio Link Reconfiguration

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-20

Introduction

5. RRC Radio Bearer Establishment


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 KPI Total RAB Establishment Success
Rate is affected due to total number of RAB establishment failures that incorporates all
the RAB Establishment Failure causes. Some of the failure causes listed above can be
identified via specific PM counters as depicted in the signaling flow.

PRELIMINARY

Call availability and optimization

The Total RAB Establishment Success Rate is the percentage of calls for all supported
service types that successful established a RAB, against the number of valid calls
requested. 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 as


follows:

Dynamic Bearer Control failure


Radio Link Reconfiguration failure
Radio Bearer Establishment failures
Miscellaneous failures, for example Code Starvation.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-21
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

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

During RAB establishment the Dynamic Bearer Control (DBC) procedure is triggered.
(See RAB establishment call flow (p. 8-20)). DBC failure will result in assignment
of a lower data rate. In case even the lowest data rate can not be assigned, the RAB
establishment is rejected incrementing NumRABEstFail.Load. If the value of this
counter indicates that an overload situation has occurred, then the root cause of this
overload situation should be investigated.
Average Transmitted Carrier Power, Maximum Transmitted Carrier Power and
Maximum Received Signal Strength Indicator may be used to verify that the load in the
cell is fairly high.
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 the
root cause of this overload situation should be investigated.
Other system load counters

PRELIMINARY

Other counters related to system load such as Forward Power Overload Duration,
Average Transmitted Carrier Power, Maximum Transmitted Carrier Power and
Maximum Received Signal Strength Indicator may be used to verify that the load in the
cell is fairly high.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-22

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

The NBAP radio link reconfiguration procedure is responsible for preparing a new
configuration of all existing radio links related to one RRC connection within a Node
B. (See RAB establishment call flow (p. 8-20)).

PRELIMINARY

Call availability and optimization

Radio link reconfiguration procedure

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

If the Node B cannot reserve the necessary resources then the procedure fails and an
NBAP Radio Link Reconfiguration Failure message is sent back to the RNC instead of
an NBAP Radio Link Reconfiguration Ready message.
PMs / KPIs indications

The RL Reconfiguration Successes can be derived as difference between attempts


counted by PM NumRLReconfigAtt and failure counted by PM NumRLReconfigFail.sum.
Related PMs / KPIs

The related PMs / KPIs are:

NumRLReconfigAtt
NumRLReconfigFail.sum.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-23
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

Radio
bearer establishment failures
...................................................................................................................................................................................................................................
Introduction

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

The RNC sends the Radio Bearer Setup message to the UE that sends back the Radio
Bearer Setup Complete message to the RNC upon successfully allocating resources for
the new Radio Bearer.
Radio bearer establishment failures from UE

Upon receiving the Radio Bearer Setup message the UE may not successfully allocate
the required resources to set-up the new Radio Bearer. In this case the UE sends back
the Radio Bearer Setup Failure message to the RNC and the Radio Bearer
Establishment procedure fails.
Possible reasons for Radio Bearer establishment failures are:

A 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 KPI RAB Establishment Success Rate. They can be
identified via PM counter NumRABEstFail.RBSetupFail triggered when Radio Bearer
Setup Failure message is received at the RNC.
Related PMs / KPIs

The related PMs / KPIs are:

PRELIMINARY

NumRABEstFail.RBSetupFailure

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-24

No
answer from UE
...................................................................................................................................................................................................................................
Introduction

Upon sending the RRC Radio Bearer Setup message to the UE, a guard timer is started
on the RNC in order to supervise the reception of the RRC Radio Bearer Setup
Complete message from the UE. The guard timer is configured by UTRAN parameter
uERadioBearerSetupResponseTimer. If the guard timer expires and no message is
received from the UE, then the Radio Bearer Establishment procedure fails and all the
allocated UTRAN resources are released.

PRELIMINARY

Call availability and optimization

No answer from UE failures

Normal reason for this failure scenario is due to poor RF conditions, which could
result because of poor coverage or high interference.
In addition, too low a setting of timer uERadioBearerSetupResponseTimer with respect
to the UE response time may be the failure cause.
PMs / KPIs indications

This failure causes degradation of KPI RAB Establishment Success Rate. The specific
UTRAN PM counter NumRABEstFail.T3 is triggered when the guard timer expires.
Related PMs / KPIs

The related PMs / KPIs are:

NumRABEstFail.T3.

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
8-25
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call availability and optimization

Code
starvation
...................................................................................................................................................................................................................................
Introduction

The number of times there is no channelization code available is counted using the PM
counter NumRABEstFail.CodeStarv. If this happens quite often it can contribute to an
increased number of failed RAB establishments. Chat applications are considered the
most important cause of code starvation issues.
Related PMs / KPIs

The related PMs / KPIs are:

PRELIMINARY

NumRABEstFail.CodeStarv.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

8-26

PRELIMINARY

C all reliability
9

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Call reliability

9-2

Dropped calls analysis

9-3

Radio link failures analysis due to synchronization issues

9-6

Network level retainability

9-9

Network level retainability KPIs

9-10

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
9-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call reliability

Call reliability
Overview
...................................................................................................................................................................................................................................
Purpose

PRELIMINARY

Contents
Dropped calls analysis

9-3

Radio link failures analysis due to synchronization issues

9-6

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

9-2

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

As soon as the call is successfully set up, the second factor influencing UMTS user
perception is the probability of maintaining the call, as opposed to the probability of
dropping the call.

PRELIMINARY

Call reliability

A call drop is defined as an abnormal termination of a voice/data session due to any


reason causing the user to re-initiate the session. Where a drop on a PS session will
still result in PDP context preservation, and the end user will be able to re-establish
seamlessly (with some delay). PS drops are generally not as severe for end users as CS
drops.
On the UTRAN side, KPI RAB Dropping Rate, defined as the percentage of dropped
RAB due to any reason against the total number of established RABs for all services,
can be calculated.
Signaling flow

The signaling flow of total RABs dropped:

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
9-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call reliability

Dropped calls analysis

UE

Uu

Node B

Iub

RNC

Iu-ps

SGSN

RAB 64 kbps UL and DL

RRC

RAB 64 kbps UL and DL

RRC

A dropped RAB connection


due to any kind of failure
Expiry of timer
T_RL_RESYNC
Cell_DCH
Iu release request
(UTRAN generated reason)
RANAP

RANAP

NumRABDrop.sum
Iu release command
(UTRAN generated reason)
RANAP

RANAP

RRC Connection release


(DCCH)
RRC Connection release complete
(DCCH)
NBAP RL Deletion procedure

ALCAP release procedure


RANAP Iu release complete
UE_Idle

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

PRELIMINARY

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

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

9-4

Dropped calls analysis

Possible failing reasons

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

Radio Link Failure, caused by:


poor RF coverage
poorly defined neighbor list
poor Primary Scrambling Code (PSC) plan
pilot pollution
DL power overload.
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.

PRELIMINARY

Call reliability

Related PMs / KPIs

The related PMs / KPIs are:

Total RAB dropping rate.

PRELIMINARY

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
9-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call reliability

Radio
link failures analysis due to synchronization issues
...................................................................................................................................................................................................................................
Introduction

Radio Link Failures (RLF) due to synchronization issues can take place in both the
downlink and uplink. The physical layer in the Node B and UE checks the
synchronization status of every radio frame.
Radio link states

The three states of the radio link are:

RL Restore

Initial
state
RL Failure
Out-of-sync
state

In-sync
state
RL Restore

RLF in the downlink

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

PRELIMINARY

In the Cell_DCH state the RLF and Radio Link Restore procedures in the uplink are
supervised in the Node B by the NBAP protocol.
As each UE may have more than one uplink radio link allocated in a given Node B,
this means a softer handover status. The Node B needs to monitor the complete radio
link sets to trigger RLF and Radio Link Restore procedures.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

9-6

Radio link failures analysis due to synchronization issues

Abnormal uplink RAB disconnects

Abnormal RAB disconnects, due to loss of uplink synchronization of the air interface
radio conditions, are:

the Node B sends an NBAP Radio Link Failure Indication with cause of
synchronization failure to the RNC upon detection of loss of uplink synchronization
on the air interface
the RNC starts timer T_RL_RESYNC
the radio link recovers, an NBAP RL Restore message is sent and timer
T_RL_RESYNC is stopped
the timer T_RL_RESYNC expires, the RNC removes the particular radio link in the
Node B via the NBAP Radio Link Deletion procedure incrementing the PM counter
NumRLFailSync. The following cases have to be distinguished:
The UE has more than one Radio Link, which will not lead to a dropped call
In case the dropped radio link is the last or only one the UE is connected to,
the call is dropped and the RNC releases the Iu connection. The PM counter
NumRABDrop.CauseRLF<service type> is incremented.

PRELIMINARY

Call reliability

Radio Link Failures due to synchronization issues can be identified via PM counter
RlFailSync that is triggered after expiration of the guard timer T_RL_RESYNCH.
In case RLF for an UE with one radio link only, the radio link loss results in a
dropped call. The Iu connection is abnormally released causing the RAB drop PMs to
be incremented.
Besides PM counter NumRABDrop.sum that includes all RAB Drops, there are also
counters RLF specific triggered per service such as:

NumRABDrop.causeRLFCSV12
NumRABDrop.causeRLFCSD
NumRABDrop.CauseRLFPS32
NumRABDrop.CauseRLFPS64
NumRABDrop.CauseRLFPS128
NumRABDrop.CauseRLFPS384

Related PMs / KPIs

The related PMs / KPIs are:


NumRLFailSync
NumRABDrop.CauseRLFCSD
NumRABDrop.CauseRLFCSV12
NumRABDrop.CauseRLFPS32
NumRABDrop.CauseRLFPS64

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
9-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY
PRELIMINARY

Call reliability

Radio link failures analysis due to synchronization issues

NumRABDrop.CauseRLFPS128

NumRABDrop.CauseRLFPS384

NumRABDrop.sum.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

9-8

Network level retainability


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

PRELIMINARY

Call reliability

Purpose
Contents
Network level retainability KPIs

9-10

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
9-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call reliability

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

The retainability KPIs (all service types) is derived from the relation of total dropped
RABs 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 for
CSV12).
Lucent Retainability KPI CSD, which is the same as (1 - RAB dropping rate for CS
data)
Lucent Retainability KPI PSD, which is the same as (1 - RAB dropping rate for
PS).

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 by
many different issues. Therefore it is advised to localize the issue by analyzing the
performance measurements and the possible failing reasons. There are several possible
failing reasons of abnormal RAB disconnects.
Some of the important reasons are:

PRELIMINARY

Radio Link Failure (RLF) due to RRC connection failures


Iu interface failures
Iub or Iur interface failures.

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

9-10

PRELIMINARY

10

Call quality and optimization


10

Overview
...................................................................................................................................................................................................................................
Purpose
Contents
Call quality

10-2

Network level quality KPIs

10-3

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
10-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call quality and optimization

Call quality
Overview
...................................................................................................................................................................................................................................
Purpose
Contents

PRELIMINARY

Network level quality KPIs

10-3

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

10-2

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

Although the call is successfully set up and maintained the user may perceive that the
quality of the call itself is poor. In case of a voice call this quality degradation can be
directly experienced during the conversation. In case of data call the poor quality may
cause throughput degradation.

PRELIMINARY

Call quality and optimization

Quality KPI

UL and DL Block Error Rate (BLER) are the KPIs providing an indication of the
quality of the UMTS call. The Lucent quality KPI capture the uplink failure on RNC
basis:
= 1- NumTransBlockErrUL 100 [%]
NumTransBlockTotUL

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 is
poor. Usually this also has an impact on the UL/DL throughput related KPIs.
In order to correctly identify the root cause of high UL/DL BLER values, the UE and
the Node B transmitted power should be checked respectively:

If the UE and/or the Node B transmitted power has reached the maximum allowed
value, then the most likely root cause is given by poor RF conditions that are
limiting either the downlink or the uplink, or both.
If the UE and/or the Node B transmitted power has not reached the maximum
allowed value, then the most likely root cause is given by respectively UL and/or
DL Closed Loop Power Control issues.

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

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
10-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Call quality and optimization

Network level quality KPIs

High UL/DL BLER

Poor RF
conditions

Yes

Max UE / Node B
transmitted power
reached?

No

UL/DL
power
control issues

Note: It should not be assumed that UL BLER issues will also result in DL BLER
issues and vice versa. In several scenarios the system may be either only uplink or
only downlink limited due to unbalanced loads.
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

PRELIMINARY

Other counters related to system load such as UL transport block error rate CSV, UL
transport block error rate CSD and UL transport block error rate PS may be used to
verify that the load in the cell is fairly high, which would increase the probability for
call setup failures.

....................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

10-4

PRELIMINARY

Glossary

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

Numerics
3GPP

3rd Generation Partnership Project


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

AAL

Asynchronous Transfer Mode Adaptation Layer


AICH

Acquisition Indicator Chanel


ALCAP

Access Link Control Application Protocol


AM

Acknowledged Mode
ARQ

Autromatic Repeat Request


ATM

Asynchronous Transmission Mode


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

BCCH

Broadcast Control Channel

Broadcast Channel
BLER

Blocking Error Rate

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
GL-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

BCH

PRELIMINARY

Glossary

BMC

Broadcast/Multicast Control
....................................................................................................................................................................................................................................

CAC

Call Admission Control


CC

Call Control
CCCH

Common Control Channel


CCPCH

Common Control Physical Channel


CDMA

Code Division Multiple Access


CFN

Connection Frame Number


CPCH

Common Packet Channel


CPICH

Common Pilot Channel


CRNC

Controlling Radio Network Controller


CS

Circuit Switched domain


CTCH

Common Traffic Channel


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

DBC

Dynamic Bearer Control

PRELIMINARY

DC

Dedicated Control
DCCH

Dedicated Control Channel

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

GL-2

DCH

Dedicated Channel
DL

DownLink
DPCCH

PRELIMINARY

Glossary

Dedicated Physical Control Channel


DPCH

Dedicated Physical Channel


DPDCH

Dedicated Physical Data Channel


DRNC

Drift Radio Network Controller


DSCH

Downlink Shared Channel


DTCH

Dedicated Traffic Channel


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

E2E

End-to-End
Ec/Io

Signal to Noise ratio


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

FACH

Forward Access Channel


FBI

FeedBack Information
FDD

Frequency Division Duplex


FP

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

GC

General Control
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
GL-3
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

Frame Protocol

PRELIMINARY

Glossary

GPRS

General Packet Radio Service


GPS

Global Positioning System


GSM

Global System for Mobile communications


GTP

GPRS Tunnelling Protocol


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

IP

Internet Protocol
IRAT

Inter-Radio Access Technology


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

KPI

Key Performance Indicator


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

LA

Location Area
LCAT

Lucent Cells Application Tool


LDAT3G

Lucent Data Analysis Tool for 3G


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

MAC

Medium Access Control


MAC-b

Broadcast Medium Access Control

PRELIMINARY

MAC-c/sh

Common Medium Access Control


MAC-d

Dedicated Medium Access Control

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

GL-4

MM

Mobility Management
MO

Mobile Originated call


MSC

PRELIMINARY

Glossary

Mobile Switching Center


MT

Mobile Terminated call


MTP3

Message Transfer Protocol 3


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

NAS

Network Access Server


NBAP

Node B Application Part


Nt

Notification
....................................................................................................................................................................................................................................

OCNS

Orthogonal Channel Noise Simulation


OMC

Operation and Maintenance Center


OMC-UPS

OMC for the UTRAN and the Packet Core cluster


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

P-CCPCH

Primary Common Control Physical Channel


P-CPICH

Primary Common Pilot Channel

Primary Synchronization Channel


PC

Personal Computer
...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
GL-5
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

P-SCH

PRELIMINARY

Glossary

PCCH

Paging Control Channel


PCH

Paging Channel
PCPCH

Physical Common Packet Channel


PDCP

Packet Data Convergence Protocol


PDP

Packet Data Protocol


PDSCH

Physical Downlink Shared Channel


PDU

Packet Data Unit


PICH

Paging Indication Channel


PM

Performance Management
PMM

Packet Mobility Management


PRACH

Physical Random Access Channel


PS

Packet Switched domain


PSC

Primary Scrambling Code


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

QoS

PRELIMINARY

Quality of Service
....................................................................................................................................................................................................................................

RA

Routing Area

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

GL-6

RAB

Radio Access Bearer


RACH

Random Access Channel


RANAP

PRELIMINARY

Glossary

Radio Access Network Application Protocol


RB

Radio Bearer
RF

Radio Frequency
RLC

Radio Link Control


RLF

Radio Link Failure


RNC

Radio Network Controller


RNSAP

Radio Network Subsystem Application Part


RNTI

Radio Network Temporary Identity


RRC

Radio Resource Control


RTP

Real-Time Protocol
....................................................................................................................................................................................................................................

S-CCPCH

Secondary Common Control Physical Channel


S-CPICH

Secondary Common Pilot Channel

Secondary Synchronization Channel


SAAL

Signaling ATM Adaptation Layer


...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
GL-7
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

S-SCH

PRELIMINARY

Glossary

SAP

Service Access Point


SCH

Synchronization Channel
SDU

Service Data Unit


SF

Spreading Factor
SGSN

Serving GPRS Support Node


SM

Session Management
SPAT3G

Service Performance Analysis Tool for 3G


SRNC

Serving Radio Network Controller


SSCF

Service Specific Coordination Function


SSCOP

Service Specific Connection Oriented Protocol


STM

Synchronous Transport Module


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

TFC

Traffic Format Combination


TM

TRansparent Mode
TPC

PRELIMINARY

Transmit Power Control


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

UCU

UMTS Channel Unit

...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

GL-8

UDP

User DAtagram Protocol


UE

User Equipment
UL

PRELIMINARY

Glossary

UpLink
UM

Unacknowledged Mode
UMSC

UMTS Mobile Switching Center


UMTS

Universal Mobile Telecommunication System


UNI

User-Network Interface
URA

UTRAN REgistration Area


USCH

Uplink Shared Channel


UTRAN

UMTS Terrestrial Radio Access Network


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

VLR

Visitor Location Register


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

WAG

Wireless Application Gateway

PRELIMINARY

...................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
GL-9
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

PRELIMINARY

PRELIMINARY

Index

A Average transmitted carrier power, 8-14, 8-22

Lucent Retainability KPI CSD, 9-10

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

Lucent Retainability KPI CSV, 9-10

B BLER, 10-3

Lucent Retainability KPI PSD, 9-10

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

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

C Call availability, 8-3

M MAC, 4-27

ChannelOccupRatePCH, 8-17

Maximum received signal strength indicator, 8-14,


8-22

ChannelOccupRateRACH, 8-9
Maximum transmitted carrier power, 8-22
Connected mode, 4-34
Medium Access Control, 4-23
CSD Accessibility rate, 8-5
................................................................................................

CSV Accessibility rate, 8-5


................................................................................................
D Definition of optimization, 1-2
................................................................................................

N N300, 8-9

N315, 9-6
Network layer, 4-31
Not optimizing

F Forward power overload duration, 8-14

Forward Power Overload Duration, 8-22


................................................................................................
I

Consequences, 1-4
NumBadRACHTransBlock, 8-9
NumCellUpdateRequest.CellReselect, 8-8

Idle mode, 4-34

NumGoodRACHTransBlock, 8-9

Interfaces

NumPageAttDiscard, 8-17

Iu-cs, 4-52
Iu-cs interface, 4-52
................................................................................................

NumRABDrop.<service type>, 9-6


NumRABEstFail.CodeStarv, 8-26

K KPI, 2-2

NumRABEstFail.RBSetupFailure, 8-24

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

NumRABEstFail.T3, 8-24, 8-25

L Logical channels, 4-20

NumRLFailSync, 9-6

....................................................................................................................................................................................................................................
401-382-810R03.03
Lucent Technologies - Proprietary
IN-1
Issue 0.1, June 2006
See notice on first page

PRELIMINARY

NumRABEstFail.Load, 8-22

PRELIMINARY

Index

NumRLReconfigAtt, 8-23

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

NumRLReconfigFail.sum, 8-23

U uERadioBearerSetupResponse, 8-24

NumRLSetupFail.NodeBRes, 8-15

UL transport block error rate CSD, 10-3

NumRLSetupFail.TransRes, 8-15

UL transport block error rate CSV, 10-3

NumRRCConnAtt, 8-9

UL transport block error rate PS, 10-3

NumRRCConnEstFail, 8-12, 8-16


NumRRCConnRej, 8-12, 8-14
NumUraUpdateRequest.UraChange, 8-8
................................................................................................
O Optimization costs, 1-2

Optimization requirements, 1-2


................................................................................................
P Physical channels, 4-12

PSD Accessibility rate, 8-5


................................................................................................
R RAB dropping rate for CS data, 9-10

RAB dropping rate for CSV12, 9-10


RAB dropping rate for PS, 9-10
RAB establishment, 8-19
Reasons for optimization, 1-4
RLC, 4-27
RRC, 4-34
................................................................................................
S successful RRC connections establishment rate,

8-12
................................................................................................
T T300, 8-9

T313, 9-6

PRELIMINARY

Total number of RAB establishment failures, 8-19


Total RAB dropping rate, 9-3
Total RAB establishment success rate, 8-19
Transport channels, 4-18
T_RL_RESYNC, 9-3, 9-6
...................................................................................................................................................................................................................................
Lucent Technologies - Proprietary
401-382-810R03.03
See notice on first page
Issue 0.1, June 2006

IN-2