UMTS Basics

See notice on first age

UMTS UTRAN Optimization UMTS-04.03

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

Alcatel-Lucent - Proprietary This document contains proprietary information of Alcatel-Lucent and is not to be disclosed or used except in accordance with applicable agreements. Copyright © 2007 Alcatel-Lucent Unpublished and Not for Publication All Rights Reserved

See notice on first age

Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein. Copyright © 2007 Alcatel-Lucent. All Rights Reserved. Notice

Every effort was made to ensure that the information in this Information Product (IP) was complete and accurate at the time of printing. However, information is subject to change. Ordering information

The order number for this information product is 401-382-940R04.03. To order documentation from an order entry representative, use one of the following numbers: Within the United States, call +1-888-582-3688, or send email to cicorders@alcatel-lucent.com (to fax an order, call 1-800-566-9568). Within Canada, call +1 317 322 6616, or send email to cicorders@alcatel-lucent.com. International, call +1 317 322 6616, or send email to intlorders@alcatel-lucent.com (to fax an order, call +1 317 322 6699). Technical support

For initial technical assistance, please call one of the following numbers: North America, Central and Latin America and Asia Pacific regions: Customer Technical Assistance Management (CTAM) center: +1 630 713 0488 Europe, Middle East and African regions: International Customer Management Center (ICMC): +353 1692 4579 Information product support

For non-technical questions or comments regarding this information product, please call one of the following numbers: North America, Central and Latin America and Asia Pacific regions: Customer Technical Assistance Management (CTAM) center: +1 630 713 0488 Europe, Middle East and African regions: International Customer Management Center (ICMC): +353 1692 4579

Alcatel-Lucent - Proprietary See notice on first page

Contents

About this information product Purpose

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

xi

Reason for reissue

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

xi

Intended audience

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

xii

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

xii

Conventions used

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

xii

Systems supported

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

xii

How to use this information product

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

xii

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

xii

Related documentation Related training

How to comment

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

xiii

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

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

Key Performance Indicators

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

2-1 2-2

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary iii Issue 1, August 2007 See notice on first page

Contents

Drive test

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

2-6

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

2-7

Customer complaints OMC-UPS tools

2-3

Analyzing information Overview

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

Data analysis software

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

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 Overview

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

Physical channels

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

4-12 4-13

................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

iv

Contents

Transport channels Logical channels

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

4-20

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

4-24

Air interface protocols Overview

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

4-27

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

4-31

Medium Access Control Radio Link Control

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

4-34

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

4-35

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

4-38

Packet Data Convergence Protocol (PDCP) Radio Resource Control RRC State Machine

4-26

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

4-39

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

4-40

RRC Connection and Signaling Connection Signaling radio bearers

Radio bearer establishment

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

4-44

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

4-48

UTRAN protocols Overview

Iub protocol structure

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

4-51

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

4-54

Protocols of the Iub interface Iur interface

4-49

Iu-cs interface

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

4-56

Part II: Optimization process 5

Optimization process Overview

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

Network lifecycle

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

Optimization process phases

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

5-1 5-2 5-4

Planning and preparation (site readiness)

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

5-7

Drive test optimization before live traffic

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

5-9

Information gathering

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

5-11

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary v Issue 1, August 2007 See notice on first page

Contents

Information analysis 6

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

5-12

Drive testing Overview

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

Drive test optimization process

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

Planning and preparation (site readiness) Optimization planning

6-1 6-2

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

6-4

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

6-6

Perform cluster optimization Perform system verification

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

6-8

6-11

Part III: Optimization and troubleshooting 7

UTRAN key performance indicators Overview

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

Performance Counters and Key Performance Indicators

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

7-6

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

7-7

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

7-8

CS IRAT HO success rate (UMTS -> GSM)

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

7-10

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

7-12

Parameter trigger event basis Parameter setting

Parameter discussion 8

7-2

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

KPI example - CS IRAT HO success rate (UMTS -> GSM)

Performance counter trigger event basis

7-1

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

7-13

Call availability optimization and troubleshooting Overview

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

8-1

Call availability Overview

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

Call availability

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

Determination of accessibility problem

8-3 8-4

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

8-6

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

8-7

Accessibility Overview


vi

Contents

Access preliminary procedures Cell re-selection failures

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

8-8

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

8-9

RACH access procedure failures

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

8-11

RRC connection establishment analysis Overview

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

8-16

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

8-19

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

8-21

Introduction to RRC connection establishment Call admission control failures Radio link setup analysis

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

8-23

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

8-24

RRC connection setup failure Paging failures

8-15

RAB establishment analysis Overview

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

RAB establishment

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

Dynamic bearer control failures

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

9

8-32

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

8-33

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

Dropped calls analysis

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

Dropped RAB analysis due to congestion

9-1 9-2

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

9-6

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

9-9

Radio link failures analysis due to synchronization issues

Call quality optimization and troubleshooting Overview

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

Quality KPIs 11

8-30

Call reliability optimization and troubleshooting Overview

10

8-27

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

Radio bearer establishment failures No answer from UE

8-26

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

10-1 10-2

Call mobility optimization and troubleshooting Overview

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

11-1

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary vii Issue 1, August 2007 See notice on first page

Contents

Soft/Softer handover and troubleshooting Overview

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

11-4

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

11-7

Soft/softer handover procedure Average active set size

11-3

Soft handover troubleshooting

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

11-9

No Node B resources available

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

11-12

No transport resources available

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

11-13

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

11-14

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

11-15

No UE answer UE reject

Unlisted set cells

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

11-16

CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting Overview

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

11-18

CS Voice UMTS to GSM (inter-RAT) handover procedure

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

11-19

CS Voice relocation preparation procedure troubleshooting

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

11-23

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

11-25

CS Voice IRAT handover procedure troubleshooting

CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting Overview

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

11-27

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

11-30

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

11-32

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

11-26

PS UMTS to GSM (inter-RAT) Cell Change Order and troubleshooting Overview

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

PS UMTS to GSM (inter-RAT) Cell Change Order procedure

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

11-33 11-34

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

11-37

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

11-39

PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting Serving HS-DSCH Cell Change Overview


viii

Contents

Serving HS-DSCH Cell Change procedure

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

Serving HS-DSCH Cell Change troubleshooting

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

11-40 11-43

Inter-frequency hard handover and troubleshooting Overview

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

11-44

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

11-45

Hard handover troubleshooting

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

11-50


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

11-53


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

11-54

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

11-55

Inter-frequency hard handover procedure

UE reject

Inter-system directed retry Overview

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

Inter-system directed retry procedure

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

Inter-system directed retry troubleshooting 12

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

11-56 11-57 11-60

Throughput optimization and troubleshooting Overview

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

Throughput optimization

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

12-1 12-2

Glossary Index

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary ix Issue 1, August 2007 See notice on first page

About this information product 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 solution proposals for improving the performance evaluation of the effectiveness of counter measures.

Use of this document, or the information it contains, with any configuration other than the ones above may not be valid. The UMTS UTRAN optimization manual is specific to the optimization of UMTS networks and does not cover other aspects of network management or network engineering. Reason for reissue

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

Reason for reissue

0.1

Preliminary version for FOA

1

Final version for GA

.................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary xi Issue 1, August 2007 See notice on first page ,

About this information product

Intended audience

Alcatel-Lucent assumes that anyone using the information in this manual has a general familiarity with UMTS networks, and has specific experience working with, and operating, the Alcatel-Lucent UMTS system. Therefore, the audience for this manual consists of: • • • • •

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

How to use this information product

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

The term “FIMS-UT” is a generic term to describe any local maintenance terminal (LMT) for any UTRAN network element. The terms “RMT” and “Node B RMT” are used to describe the Node B Remote Maintenance Tool application. The term “OMC” is a generic term to describe the Operation and Maintenance Center entities which control the UTRAN network elements. Acronyms are explained on their first appearance in the text. Systems supported

This document applies to the Alcatel-Lucent UMTS System Release 04.03. Related documentation

The following related documentation is available: •

Performance Measurements Definitions Manual, UMTS-04.03/IMS 5.0, 401-382-803R04.03

Related training

The following related courses are available: • •

UMTS System Introduction, UM1001 UMTS Hardware Overview, UM1911

................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007 ,

xii

About this information product

•

UMTS UTRAN Signaling and Parameters, UM4302

•

UTRAN Processes and Parameters, UM4305

•

UTRAN Optimization, UM4801.

How to comment

To comment on this information product, go to the Online Comment Form (http://www.lucent-info.com/comments/enus/) or e-mail your comments to the Comments Hotline (comments@alcatel-lucent.com).

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary xiii Issue 1, August 2007 See notice on first page ,

Part I: Optimization concepts

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

This document part provides an introduction to the concepts of UTRAN optimization, information on tools and sources that are used to gather the information for the optimization process, a short description of typical areas for optimization problems, and an overview over UTRAN signaling. Contents Chapter 1, Introduction to optimization

1-1

Chapter 2, Information sources and tools

2-1

Chapter 3, Common optimization problems and their solutions

3-1

Chapter 4, UTRAN Signaling

4-1

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary I-1 Issue 1, August 2007 See notice on first page

1

I ntroduction to optimization 1


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


1-4

When to optimize a network ?

1-6

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 1-1 Issue 1, August 2007 See notice on first page

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


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



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

Subscribers, in missed revenue because of blocked calls or subscribers changing to other operators Operational and maintenance costs.


1-4



Subscribers

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

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

Blocked calls are a direct loss of revenue for an operator. Poor network quality can 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.



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

Optimization during the network life cycle:

Network design

Planning

Optimization

Implementation

N

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.

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. ................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

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.


2

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 Key Performance Indicators

2-2

Drive test

2-3

Customer complaints

2-6

OMC-UPS tools

2-7


Information sources and tools

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

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

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

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

For detailed information on all the available KPIs, refer to UMTS Performance Measurement Definitions Manual, 401-382-803R04.03. Detected problems

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

RF coverage gaps Cell breathing Pilot pollution Near-far problems Around-the-corner problems Handover problems (failures or ping-ponging) Missing neighbor cells in the neighboring cell list.


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)

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



Drive test

Components of a drive test system are: • • • • •

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

Detecting problems

Drive testing can be useful in detecting most problems that occur: • • • • • • •

RF coverage gaps Cell breathing Pilot pollution Near-far problems Around-the-corner problems Hand over problems (failures or ping-ponging) Missing neighbors in a neighboring cell list.

Drive testing can also detect: • •

Poor voice reception quality Poor data rates.

.................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

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

.................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 2-5 Issue 1, August 2007 See notice on first page


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

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

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

Trouble tickets typically contain the following information: • • •

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

Example

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

Although customer complaints are often not very specific, they can be helpful to detect problems that may be an issue for optimization.


2-6


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

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

RF call trace OCNS.

RF call trace

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

The operator can use information from RF call traces to: • • •

Verify call establishment Check performance and maintenance of radio links Check radio link quality and coverage.

OCNS

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

OCNS is a tool that is normally used in a network without traffic. OCNS simulates traffic during testing before a network is live. OCNS can also be used to generate additional traffic in a live cell, simulating heavier traffic loads. Detected problems

RF Call trace can be useful to detect all problems that may be an issue for optimization. ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 2-7 Issue 1, August 2007 See notice on first page


OMC-UPS tools

OCNS can be useful to detect Cell breathing.


2-8


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

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

2-10

Optimization and design tools

2-13



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

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

Network design optimization Live network performance optimization.

Inputs for analysis software tools

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

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

Benefits of data analysis software

Data analysis software helps an engineer to: • • • •

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

Predict effect of changes

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


2-10



Output of analysis tools

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

Before optimization

Optimizated design

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

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



Besides commercially available software tools also many proprietary tools are available. Key capabilities

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

Interfaces to different vendors of drive test equipment, protocol analyzers and measurement programs Open interfaces Multiple technologies Interfaces to databases to retrieve and store data Synchronization of data from different sources to remove timing variations Database querying and filtering to reduce data volumes.


2-12


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

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

Lucent Data Analysis Tool for 3G (LDAT3G) is an application for performing RF analysis of drive test data for IS-95, 3G CDMA, 1xEV-DO, and UMTS systems. Used for initial optimization of deployed network. Drive test data, RF Call Trace, Cell Diagnostic Monitor, Packrat, and WINDS are supported. SPAT3G

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

•

•

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

AirPro

AirPro is an RF planning tool that is used to design wireless systems. AirPro can be used in the designs of new wireless networks, networks migrating from older generation to newer generation and existing network optimization. AirPro includes RF ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 2-13 Issue 1, August 2007 See notice on first page


Optimization and design tools

propagation analysis, interference prediction, RF optimization, and utilities that help you create and manage system designs for mobile systems in diverse operating environments Ocelot ®

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

Moving traffic from heavily-loaded sectors to more lightly-loaded sectors (“traffic balancing”) Reducing the amount of soft- and softer-handoff traffic Reducing the average power per user.


2-14

3

3 ommon optimization problems C and their solutions


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

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

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

3-2


3-4


3-6

Near-far problem

3-8

Around-the-corner problem

3-9

Handover problem

3-10

Missing neighbors problem

3-11


Common optimization problems and their solutions

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

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

Pathloss < maximum allowed pathloss Ec/Io > minimum signal-to-noise ratio.

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

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

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

Dropped calls Failed handovers.

Information sources

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

Drive test Key performance indicators Customer complaints.


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.



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

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

Cell at 30 % capacity Cell at 60 % capacity

Traffic needed during optimization

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


3-4



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

• •

Increase coverage area: – Antenna downtilt or reorientation – Power increase. – New antenna or new cell site. Change handover parameters Change neighboring cell list.



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

Pilot pollution is interference caused by overlapping pilots with similar signal strengths. The lack of a dominant pilot causes low Ec/Io ratios. Problem areas with low Ec/Io ratios may be misinterpreted as pilot pollution areas and lead to iterative drive testing and unnecessary parameter changes in attempts to establish a dominant pilot. If a pilot has: • •

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

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

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

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

Dropped calls Handover failures


3-6


•

Increased interference

•

Decreased capacity.


Information sources

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

Drive tests.

Possible solutions

Possible solutions for pilot pollution problems are: • • •

Antenna tilt and azimuth rotation P-CPICH channel power changes Change neighboring cell lists.



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

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

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


Possible solutions

Possible solutions for near-far problems are: •

Changing power control parameters.


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



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

Adjust handover parameters Change the neighboring cell list.


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




Missing neighbors problem

Possible solutions

Possible solutions for missing neighbor problems are: • •

Updating the neighboring cell list to include or exclude a pilot. Change RF coverage, so pilots are not received anymore or pilot reception is improved: – Adjust power levels – Change antenna orientation or tilt.


3-12

4

U TRAN Signaling 4

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

4-3


4-4

Radio interface protocol architecture

4-6

Service access points

4-8

Air interface channels

4-12

Physical channels

4-13

Transport channels

4-20

Logical channels

4-24

Air interface protocols

4-26

Medium Access Control

4-27

Radio Link Control

4-31

Packet Data Convergence Protocol (PDCP)

4-34

Radio Resource Control

4-35

RRC State Machine

4-38

RRC Connection and Signaling Connection

4-39

Signaling radio bearers

4-40


4-44

UTRAN protocols

4-48


4-49

Protocols of the Iub interface

4-51


UTRAN Signaling

Overview

Iur interface

4-54

Iu-cs interface

4-56


4-2

UTRAN Signaling

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

The purpose of this section is: • • •

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

Contents Protocols of the air interface

4-4


4-6


4-8


UTRAN Signaling

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

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

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

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

Description


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.


4-4

UTRAN Signaling


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.


The MAC prepares transport blocks for most efficient transfer over the air. The functions include scheduling, multiplexing, channel type switching, UE identification (on common channels) and transport format selection on a frame-by-frame basis. The MAC is responsible for mapping logical channel onto the appropriate transport channel.


UTRAN Signaling

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

The radio protocol architecture in the UTRAN is layered. • •

•

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

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

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


4-6

UTRAN Signaling


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

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-810R04.03 Alcatel-Lucent - Proprietary 4-7 Issue 1, August 2007 See notice on first page

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

•

•

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.


4-8

UTRAN Signaling


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.


UTRAN Signaling


Physical channels Uplink Downlink Bidirectional Data transfer Association

P-SCH S-SCH

Fixed channels

P-CPICH Logical channels

Transport channels

BCCH

BCH

P-CCPCH

PCCH

PCH

PICH

CCCH

FACH

S-CCPCH

CTCH

RACH

PRACH

DCCH DTCH

S-CPICH

AICH DCH

DPDCH DPCH DPCCH HS-DPCCH

HS-DSCH

HS-PDSCH HS-SCCH

E-DCH

E-DPDCH E-DPCCH E-HICH E-AGCH

E-RGCH

Transport channels are mapped to physical channels as shown in the illustration above. There are many physical channels which do not carry higher-layer traffic; some are associated with traffic-carrying channels, while others are necessary for cell discovery by the UE and channel estimation. .................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

4-10

UTRAN Signaling


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

•

•

•

PICH indicates in an efficient manner that information for a mobile will shortly be transferred on the PCH transport channel AICH indicates that an access preamble has been received, and that the UE can stop ramping up its power, or (for PCPCH) that a collision detect preamble has been received and resolved DPCCH carries power control information for associated channels as well as TFC indication for DPDCH and PDSCH, and pilot and feedback information. The shared channels are power controlled, so a UE which uses them must also have a dedicated channel set up and associated with them. This DCH can be of very low bandwidth compared to the shared channel, and may well carry the DCCH. HS-SCCH is used for UE addressing for HSDPA, that is, indicating a specific UE that data packets are being sent on the HS-PDSCH, and provides the UE with necessary information to decode the data packets. The HS-DPCCH carries the UE feedback information used for link adaptation and the Hybrid Automated Repeat request (HARQ) process.


UTRAN Signaling

Air interface channels Overview ................................................................................................................................................................................................................................... Purpose


to describe the channels of the air interface to map these channels to their layer of the air interface to explain the function of the channels.

Contents Physical channels

4-13

Transport channels

4-20

Logical channels

4-24


4-12

UTRAN Signaling

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

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

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

Introduction

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


UTRAN Signaling

Physical channels


P-SCH S-SCH

Fixed channels


Transport channels

BCCH

BCH

P-CCPCH

PCCH

PCH

PICH

CCCH

FACH

S-CCPCH

CTCH

RACH

PRACH

DCCH DTCH

S-CPICH

AICH DCH


HS-DSCH

HS-PDSCH HS-SCCH

E-DCH


E-RGCH

Channel mapping

The DCHs are coded and multiplexed and the resulting data stream is mapped sequentially directly to the physical channel(s). .................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

4-14

UTRAN Signaling

Physical channels

The mapping of BCH and FACH is equally straightforward where the data stream, after coding and interleaving, is mapped sequentially to the Primary and Secondary CCPCH respectively. Also for the RACH, the coded and interleaved bits are sequentially mapped to the physical channel, in this case the message part of the random access burst on the PRACH. The mapping of the PCH to the Secondary CCPCH is more complex to allow for an efficient sleep mode. The mapping of the HS-DSCH to the HS-PDSCH is done by mapping the data stream sequentially directly to the physical channel. Common downlink physical channels

The following is a list of the common downlink physical channels: Common 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.

S-CCPCH

The Secondary Common Control Physical Channel is used to carry the FACH and PCH. It is of constant rate. However, in contrast to the Primary CCPCH, the rate may be different for different secondary CCPCH within one cell and between cells, in order to be able to allocate different amount of FACH and PCH capacity to a cell. The rate and spreading factor of each secondary CCPCH is broadcast on the BCH. The set of possible rates is the same as for the downlink DPCH. The FACH and PCH can be mapped to separate secondary CCPCHs. The main difference between the Primary and Secondary CCPCH is that the Primary CCPCH has a fixed predefined rate while the Secondary CCPCH has a constant rate that may be different for different cells, depending on the capacity needed for FACH and PCH.


UTRAN Signaling

Physical channels

Common downlink physical channels

Description

P-SCH

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

S-SCH

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

P-CPICH

The Primary Common Pilot Channel is a fixed rate (30 kbit/s, SF = 256) downlink physical channel. This channel is coded with the scrambling code of the cell that it belongs to, therefore the UE can use this channel to determine the received signal strength of this particular cell. Furthermore the P-CPICH is also used as a phase and power reference for the other downlink physical channels. The downlink common control channels have to reach all UEs in the cell and should not be too loud to disturb other cells. As the cell size is often adjusted, it may occur that the power level of all control channels must be readjusted. To simplify this, the power level of all control channels are expressed in relation to the power that is used by the Pilot Channel of a cell. That is, when the power of P-CPICH is reduced, the power of all other common channels is reduced by the same factor.

S-CPICH

The Secondary Common pilot Channel may be transmitted over the entire cell or a part of the cell. There may be zero, one or several S-CPICH per cell. An S-CPICH may be the phase reference for the secondary CCPCH and the downlink DPCH. If this is the case, the UE is informed about this by higher layer signaling.

PICH

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


4-16

UTRAN Signaling

Physical channels

Common downlink physical channels

Description

AICH

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

PDSCH

The Physical Downlink Shared Channel is shared by several users based on code multiplexing.

HS-PDSCH

The High Speed Physical Downlink Shared Channel (HS-PDSCH) carries the data traffic in the form of MAC-hs Packet Data Units (PDUs). It has a fixed spreading factor of 16. This allows for up to 15 parallel channels. The transmit power is set by the scheduler, that is, it is constant during one transmit time interval.

HS-SCCH

The High Speed Shared Control Channel (HS-SCCH) transmits the information about the configuration to be used next on the HS-PDSCH channel. It has a fixed spreading factor of 128. The UE can monitor up to four HS-SCCH channels.

Dedicated downlink physical channels

The following is a list of the dedicated downlink physical channels: Dedicated downlink physical channels

Description

DPCH

There is only one type of downlink dedicated physical channel, the Downlink Dedicated Physical Channel (downlink DPCH). Within one downlink DPCH, dedicated user data generated at layer 2 and above (from MAC and above at the RNC) and control information generated at layer 1 (known pilot bits, TPC commands, and an optional TFCI) are multiplexed at the Node B and transmitted together over the U u interface. The downlink DPCH can thus be seen as a time multiplex of a downlink DPDCH and a downlink DPCCH.

E-HICH

The E-DCH HARQ Indication Channel (E-HICH) carries the ACK/NACK information from the E-DCH Active Set cells that a packet was received and retrieved successfully. This channel uses a spreading factor of 128.


UTRAN Signaling

Physical channels

Dedicated downlink physical channels

Description

E-AGCH

The E-DCH Absolute Grant Channel carries the E-DCH Radio Network Temporary Identifier, the HARQ Process Activation flag, and the maximum power ratio the UEs may use for E-DCH transmission. This channel uses a spreading factor of 256.

E-RGCH

The E-DCH Relative Grant Channel (E-RGCH) With this, the radio resource limitations established on particular UEs can be changed. This channel uses a spreading factor of 128.

Common uplink physical channels

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

Description

PRACH

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

Dedicated uplink physical channels

In contrast to the one dedicated downlink physical channel, there are two dedicated uplink physical channels: the Dedicated Physical Data CHannel (DPDCH) and the Dedicated Physical Control CHannel (DPCCH). The uplink transmits the DPDCH and the DPCCH logically separate from one another. There may be zero, one, or several uplink DPCHs on each Layer 1 connection.


4-18

UTRAN Signaling

Physical channels

The following is a list of the dedicated uplink physical channels: Dedicated uplink physical channels

Description

DPDCH

The uplink DPDCH is used to carry dedicated user data generated at Layer 2 and above, i.e. data taken from the dedicated transport channel (DCH). There may be zero, one, or several uplink DPDCHs on each Layer 1 connection.

DPCCH

UE-specific uplink channel that feedbacks the ACK/NACK for HARQ, and channel quality information for the scheduler. It has a fixed spreading factor of 256. This channel is code multiplexed to the uplink DPCCH. The Layer 1 control information consists of the same control information as used in the downlink with the addition of FBI bits: •

Transmit Power Control (TPC) allows the UE to tell the Node B to either increase or decrease its transmission power.

•

The TFCI is used in order to inform the receiving side of the currently valid Transport Format Combination, and hence how to decode, de-multiplex and deliver the received data on the appropriate Transport Channels.

•

Pilot bits support channel estimation for coherent detection.

•

By means of the FBI-Bits (FeedBack Information), the UE can have the Node B regulate the phase and amplitude in the case of Closed Loop Transmit Diversity.

HS-DPCCH

The High Speed Dedicated Physical Control Channel is a UE-specific uplink channel that feedbacks the ACK/NACK messages for Hybrid Automatic Repeat Requests (HARQ), and channel quality information for the scheduler. It has a fixed spreading factor of 256. This channel is code multiplexed to the uplink DPCCH.

E-DPDCH

The Enhanced Dedicated Physical Data Channel (E-DPDCH) carries the user traffic from the UE and uses a range of spreading factors, depending on the data traffic rate. E-DPDCH supports the 2 ms TTI and the 10 ms TTI.

E-DPCCH

The Enhanced Dedicated Physical Data Channel (E-DPDCH) carries control information on the E-DCH associated physical layer signaling channel transmitted by the UE. This channel uses a spreading factor of 256 to forward the Transport Format Combination Indicator used on E-DCH (E-TFCI), the HARQ related Retransmission Sequence Number (RSN), and a “happy bit” as a feedback to the Node B.


UTRAN Signaling

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

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


4-20

UTRAN Signaling

Transport channels


P-SCH S-SCH

Fixed channels


Transport channels

BCCH

BCH

P-CCPCH

PCCH

PCH

PICH

CCCH

FACH

S-CCPCH

CTCH

RACH

PRACH

DCCH DTCH

S-CPICH

AICH DCH


HS-DSCH

HS-PDSCH HS-SCCH

E-DCH


E-RGCH


UTRAN Signaling

Transport channels

Dedicated and common transport channels

There are two types of transport channels: dedicated transport channels and common transport channels. The common transport channels may be used by multiple users, the dedicated transport channel to one single UE only. There are three dedicated transport channels: Dedicated transport channels

Description

DCH

The Dedicated Channel (DCH) is a channel dedicated to one particular UE used in uplink or downlink direction.

E-DCH

The Enhanced Dedicated Channel (E-DCH) is the uplink transport channel that carries the E-DPDCH and the other E-DCH physical channels as associated channels. E-DCH uses fixed coding and modulation codes, and multiple HARQ processes to enhance the uplink performance. The Node B has the power control for this channel to minimize uplink interference levels.

There are six common transport channels: Common 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.


4-22

UTRAN Signaling

Transport channels

Common transport channels

Description

CPCH

The Common Packet Channel (CPCH) is a contention based uplink channel (FDD) used for transmission of bursty data traffic. This channel is shared by the UEs in a cell

DSCH

The Downlink Shared Channel (DSCH) is a downlink channel shared by several UEs carrying dedicated control or traffic data.

HS-DSCH

The High Speed Downlink Shared Channel (HS-DSCH) is the transport channel that carries the Physical Downlink Shared Channel (HS-PDSCH) and the Shared Control Channel HS-SCCH) for HSDPA.


UTRAN Signaling

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

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

The following is a list of the logical channels: Logical channels

Description

BCCH

Broadcast Control Channel (BCCH) is a downlink channel for broadcasting system control information.

PCCH

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

CCCH

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

CTCH

The Common Traffic Channel (CTCH) is a point-to-multipoint unidirectional channel for transfer of dedicated user information for all or a group of specified UEs.

DCCH

The Dedicated Control Channel (DCCH) is a point-to-point bi-directional channel that transmits dedicated control information between a UE and the network. This channel is established through RRC connection setup procedure.

DTCH

The Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user information. A DTCH can exist in both uplink and downlink.

Channel mapping

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


4-24

UTRAN Signaling

Logical channels


P-SCH S-SCH

Fixed channels


Transport channels

BCCH

BCH

P-CCPCH

PCCH

PCH

PICH

CCCH

FACH

S-CCPCH

CTCH

RACH

PRACH

DCCH DTCH

S-CPICH

AICH DCH


HS-DSCH

HS-PDSCH HS-SCCH

E-DCH


E-RGCH


UTRAN Signaling

Air interface protocols Overview ................................................................................................................................................................................................................................... Purpose


to describe the protocols of the air interface to map these protocols to their layer and sublayer of the protocol stack to explain the function of the air interface protocols.

Contents Medium Access Control

4-27

Radio Link Control

4-31

Packet Data Convergence Protocol (PDCP)

4-34


4-35

RRC State Machine

4-38

RRC Connection and Signaling Connection

4-39


4-40


4-44


4-26

UTRAN Signaling

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


PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC RLC RLC

RLC



L2/BMC



UTRAN Signaling


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.


4-28

UTRAN Signaling


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.

MAC entities

MAC is structured into the following dedicated MAC entities: • • •

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

Data transfer type

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

transparent MAC or non-transparent MAC.

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

The following fields are defined for the MAC header: •

•

•

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

Depending on the logical to transport mapping relationship, all, a selection or none of the above parameters may be used.


UTRAN Signaling


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.


4-30

UTRAN Signaling

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

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

U-plane information

control Layer 3


PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC RLC RLC

RLC



L2/BMC


Radio Link Control

The Radio Link Control (RLC) protocol provides logical link control over the radio interface. There may be several simultaneous RLC links per User Equipment; each link is identified by a bearer id. RLC provides three types of Service Access Points (SAP), corresponding to three different RLC data transfer modes: 1. In Transparent Mode (TM), RLC transmits upper layer protocol data units (PDUs) without adding any protocol control information (no RLC header). 2. In Unacknowledged Mode (UM), RLC transmits upper layer PDUs without guaranteeing delivery to the peer entity. 3. In Acknowledged Mode (AM), RLC transmits upper layer PDUs guaranteeing delivery to the peer entity. AM RLC is used for the packet-switched RABs. ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 4-31 Issue 1, August 2007 See notice on first page

UTRAN Signaling

Radio Link Control

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


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

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). .................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

4-32

UTRAN Signaling

Radio Link Control

Unacknowledged mode services: • • •

Segmentation and reassembly Concatenation Transfer of user data.

Acknowledged mode services

RLC receives SDUs from the higher layers. For a packet switched service, the 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).


UTRAN Signaling

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

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

U-plane information

control Layer 3


PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC RLC RLC

RLC



L2/BMC


Header compression and decompression

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

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

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

4-34

UTRAN Signaling

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

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

U-plane information

control Layer 3


PDCP

L2/PDCP

DCP

BMC

RLC RLC

RLC

RLC RLC RLC

RLC



L2/BMC


Interfaces

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

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

The RRC connects to the RLC over any of its 3 connection modes. The RRC manages the configuration of layer 2 and layer 1 protocols with direct links to each of the lower layers. The following illustration shows the lower layer interactions of the RRC. ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 4-35 Issue 1, August 2007 See notice on first page

UTRAN Signaling


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

• • •

•

•

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.


4-36

UTRAN Signaling


•

Control of requested QoS.

•

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

• •


UTRAN Signaling

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

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

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

Idle mode

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

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

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


4-38

UTRAN Signaling

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

RRC connection An RRC connection is a point-to-point bi-directional connection between RRC peer entities on the UE and the UTRAN sides. Signaling connection An acknowledged-mode link between the UE and the CN to transfer higher layer information between the entities in the non-access stratum. The signaling connection is made up of an RRC and a RANAP connection. Signaling connection

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

RRC Connection Relay RRC

UE

RRC

Uu

Node B

Iub

RNC

RANAP

RANAP

Iu

SGSN\MSC


UTRAN Signaling

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

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

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


4-40

UTRAN Signaling


Node B Serving RNS

UE

Serving RNC

1. CCCH: RRC Connection Request Select L1 +L2 parameters 2. Radio Link Setup Request

3. Radio Link Setup Response

4. ALCAP Iub Data Transport Bearer Setup

5. Downlink Synchronization

6. Uplink Synchronization

7. CCCH: RRC Connection Setup

8. DCCH: RRC Connection Setup Complete

Steps of the RRC connection establishment

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

1

The UE initiates the set-up of an RRC connection by sending an RRC message Connection Request on the CCCH.


UTRAN Signaling


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

2

After performing Call Admission Control (CAC), the SRNC decides to use a DCH for this RRC connection, allocates RNTI and radio resources for the RRC connection. When a DCH is to be set-up, an NBAP message Radio Link Setup Request is sent to the Node B. ...................................................................................................................................................................................................

3

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

4

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

5

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

6

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

7

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

8

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

Signaling radio bearers per RRC connection

4 signaling radio bearers are set up per RRC connection. •

•

2 signaling radio bearers for transport of RRC generated signaling messages. The 2 signaling radio bearers are for transferring messages thus: – 1 for transferring messages through an RLC UM entity and – 1 for transferring messages through an RLC AM entity. 1 signaling radio bearer for transferring NAS messages set to ″high priority″ by the higher layers (RLC AM)


4-42

UTRAN Signaling


•

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

•

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

Signaling radio bearer configuration at the UE

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


UTRAN Signaling

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

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

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


4-44

UTRAN Signaling


UE

Node B

RNC

MSC RANAP RAB Assignment Request ALCAP ERQ (Establish Request) 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: ...................................................................................................................................................................................................

1

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


UTRAN Signaling


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

2

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

3

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

4

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

5

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

6

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

7

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

Radio Access Bearer establishment

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


4-46

UTRAN Signaling


C-plane signaling

U-plane information New Radio Bearer

Radio Resource Control (RRC) PDCP DCP

control

control

BMC

RLC RLC

RLC

RLC

RLC

New RLC entity

MAC parameters

Medium Access Control (MAC) L1 Parameters



UTRAN Signaling

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


to describe the protocol structure of the UTRAN interfaces to map the UTRAN protocols to their specific layers on the Control Plane and User Plane to explain the function of the UTRAN protocols.

Contents Iub protocol structure

4-49


4-51

Iur interface

4-54

Iu-cs interface

4-56


4-48

UTRAN Signaling

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

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.


UTRAN Signaling


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.


4-50

UTRAN Signaling

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

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

SM

PMM

IP PDCP

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.


UTRAN Signaling


Access Link Control Application Part

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

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

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

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

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

ATM is used on the Iub interface for the transportation of packages using the ATM backbone network. .................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

4-52

UTRAN Signaling


The physical layer

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


UTRAN Signaling

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

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

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

Core Network

VLR 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

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.


4-54

UTRAN Signaling

Iur interface

RNSAP

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

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

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


UTRAN Signaling

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

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

Establishment and release of circuit-switched access bearers Transfer of non-access stratum signaling messages between user equipment and the core network

Transport layer

The transport layer supports Asynchronous Transfer Mode (ATM). ATM Adaptation Layer 2 and ATM Adaptation Layer 5 are used. Physical layer

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

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

Radio Network Layer

Transport Network Control Plane

User Plane User plane protocol

RANAP

Q.2630.1 Transport Network Layer

Q.2150.1

SCCP MTP3-B

MTP3-B

SSCF-NNI

SSCF-NNI

SSCOP

SSCOP

AAL5

AAL5

AAL2

ATM STM-1


4-56

UTRAN Signaling

Iu-cs interface


Part II: Optimization process

Overview ................................................................................................................................................................................................................................... Purpose Contents Chapter 5, Optimization process

5-1

Chapter 6, Drive testing

6-1

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary II-1 Issue 1, August 2007 See notice on first page

5

O ptimization process 5


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

5-2


5-4


5-7


5-9

Information gathering

5-11

Information analysis

5-12


Optimization process

Network lifecycle ................................................................................................................................................................................................................................... Network lifecycle

Stages of the lifecycle of a network:

Network design

Planning

Optimization

Implementation

N

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

1

Create a design for a UMTS network. The design is typically created using (RF) design software. ...................................................................................................................................................................................................

2

Optimize the design of the network. The design is typically optimized for coverage or capacity using optimization software that provides recommendations for: • •

Antenna tilt and orientation Power levels.


5-2


Network lifecycle

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

3

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

4

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

5

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

6

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

7

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



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

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

Optimization process flow: Begin Gather information Analyze information

Optimization problem?

N

Y

Sufficient information?

N

Y

Identify reason Determine solution Implement solution Gather and analyze information Y

Problem solved?

N


5-4



Optimization process stages

The optimization process consists of the following stages: ...................................................................................................................................................................................................

1

Collect information. Result: Main information sources are:

• • •

Drive tests Customer complaints Performance measurements and Key Performance Indicators (KPIs).

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

2

Analyze information to determine if the network complies to requirements. Result: Use automated (computer) tools to handle large quantities of complex data. ...................................................................................................................................................................................................

3

Determine if a problem is an optimization problem. Result: For example, make sure the problem is not a fault. ...................................................................................................................................................................................................

4

If needed, gather additional information. ...................................................................................................................................................................................................

5

Identify the reason for the problem. Result: For example:

• • •

Capacity RF Coverage Cell breathing.

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

6

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

• • •

Cost of implementation Easy of implementation Chance of success.

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

7

Implement the solution that was chosen. Implement only one solution at a time.




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

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

8

Gather and analyze information. Focus on the problem and the solution that was implemented. ...................................................................................................................................................................................................

9

When ...

then ...

the problem is solved,

go to Stage 1.

the problem is not solved,

Restore the original settings when parameters were changed. go to Stage 6.

Continuous optimization

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


5-6


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

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

Site readiness checks include: • • •

Spectrum clearance Antenna check Sector verification.

Spectrum clearance

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

Antenna checks ensure that the antenna system is properly installed. Proper installation must be checked with regard to: • • • •

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




Sector verification

Sector verification ensures the basic functionality of a sector. This includes basic call processing and handovers. Measurements are made on UMTS signal levels to verify that each sector is transmitting with the appropriate power levels and the correct scrambling code. The sector verification tests are used to detect hardware, software, configuration and parameter errors. The sector tests are performed using measurement software including a UMTS test terminal. Once all data from the sector tests have beencollected, the measurement data can be post-processed. If sector problems do occur, they need to be remedied and the tests repeated until they are successful. Baseline existing system

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


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

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

1

Perform site readiness checks. This ensures all cells are operating as required. Site readiness checks include: • • •

Spectrum clearance, to ensure no external interferences are present and sufficient guard band are obeyed Antenna checks, to ensure that the antenna system is properly installed (tilt, azimuth, cabling) Sector verification, to ensure basic functionality of a sector (call processing, hand overs).

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

2

Plan optimization. Ensure the system and tools are ready and available for drive test optimization. This includes: • • • • •

Check proper RF parameter settings Check proper initial neighboring cell list settings Check availability of tools, equipment and personnel Define clusters Plan routes for drive testing.

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

3

Perform cluster optimization using drive tests. This includes: • •

Define clusters (group of cells) Unloaded cluster optimization, to identify RF coverage holes, hand over regions and pilot coverage areas




•

Loaded cluster optimization, to measure effects of cell breathing

•

Cluster performance verification, to prove network meets customer criteria.

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

4

Perform system verification, to prove the entire network (all clusters) meets customer exit criteria. Result

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


5-10


Information gathering ................................................................................................................................................................................................................................... Purpose

Information is needed to determine: • • •

If there is an optimization problem Optimization solutions If the problem is solved.

Information sources

As much information as possible should be used as input for optimization, so multiple sources of information are needed. The main information sources are: • • •

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.



Information analysis ................................................................................................................................................................................................................................... Purpose

Analysis of the information determines: 1. 2. 3. 4.

Whether 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. Commercially available and proprietary tools are available to analyze information and determine impacts.


5-12

6

D rive testing 6

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

6-2


6-4

Optimization planning

6-6

Perform cluster optimization

6-8

Perform system verification

6-11


Drive testing

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

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

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

1

Perform site readiness checks. This ensures all cells are operating as required. Site readiness checks include: • • •

Spectrum clearance, to ensure no external interferences are present and sufficient guard band are obeyed Antenna checks, to ensure that the antenna system is properly installed (tilt, azimuth, cabling) Sector verification, to ensure basic functionality of a sector (call processing, hand overs).

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

2

Plan optimization. Ensure the system and tools are ready and available for drive test optimization. This includes: • • • • •

Check proper RF parameter settings Check proper initial neighboring cell list settings Check availability of tools, equipment and personnel Define clusters Plan routes for drive testing.

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

3

Perform cluster optimization using drive tests. This includes: • •

Define clusters (group of cells) Unloaded cluster optimization, to identify RF coverage holes, hand over regions and pilot coverage areas


6-2

Drive testing

Drive test optimization process

•

Loaded cluster optimization, to measure effects of cell breathing

•

Cluster performance verification, to prove network meets customer criteria.

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

4

Perform system verification, to prove the entire network (all clusters) meets customer exit criteria. Result

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


Drive testing

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

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

Site readiness checks include: • • •

Spectrum clearance Antenna check Sector verification.

Spectrum clearance

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

Antenna checks ensure that the antenna system is properly installed. Proper installation must be checked with regard to: • • • •

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


6-4

Drive testing


Sector verification

Sector verification ensures the basic functionality of a sector. This includes basic call processing and handovers. Measurements are made on UMTS signal levels to verify that each sector is transmitting with the appropriate power levels and the correct scrambling code. The sector verification tests are used to detect hardware, software, configuration and parameter errors. The sector tests are performed using measurement software including a UMTS test terminal. Once all data from the sector tests have beencollected, the measurement data can be post-processed. If sector problems do occur, they need to be remedied and the tests repeated until they are successful. Baseline existing system

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


Drive testing

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

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

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

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

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

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


6-6

Drive testing

Optimization planning

B 1 2 A

9 3

4 5

11

10 8

7 6

C

Drive route planning

Drive routes need to be defined for the following: • • •

Sector Verification Cluster Optimization System Verification.

Planning drive routes for Sector Verification

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

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

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


Drive testing

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

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

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

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


6-8

Drive testing


Multiple cluster testing

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

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

Cluster optimization consists of three phases: • • •

Unloaded cluster optimization Loaded cluster optimization Cluster performance verification

Unloaded cluster optimization

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

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


Drive testing


Loaded testing produces a rise in the noise floor, which has the effect of shrinking the coverage area (cell breathing). This causes an increase of negative Ec/Io values, identify potential coverage holes, results in higher BLER, results in lower mobility throughput, and more dropped calls. The objective is to fix the problems observed by the field teams. This involves the fine-tuning of RF parameters such as the transmit power or handover parameters. Antenna re-adjustments (e.g. down-tilts, azimuths, patterns/types or heights) are also occasionally performed. Problematic cluster

Problem areas may be re-driven after implementing changes. It is not recommended to drive a problem area more than three times. If the problem cannot be solved after three test drives, either a root cause analysis is performed or cluster optimization proceeds with the next cluster. It is generally not recommended to attempt resolution of complex, time-intensive performance issues, such as location-specific problems like cell site equipment failures. For such problems, it is advisable to report the behavior and proceed with the next cluster. The problem cluster can be verified at a later stage. Cluster performance verification

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


6-10

Drive testing

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

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

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

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

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


Drive testing

Perform system verification

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


6-12

Part III: Optimization and troubleshooting

Overview ................................................................................................................................................................................................................................... Purpose Contents Chapter 7, UTRAN key performance indicators

7-1

Chapter 8, Call availability optimization and troubleshooting

8-1

Chapter 9, Call reliability optimization and troubleshooting

9-1

Chapter 10, Call quality optimization and troubleshooting

10-1

Chapter 11, Call mobility optimization and troubleshooting

11-1

Chapter 12, Throughput optimization and troubleshooting

12-1

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary III-1 Issue 1, August 2007 See notice on first page

7

7 TRAN key performance U indicators


This chapter gives an overview over the use of key performance indicators (KPIs) within the UTRAN cluster. Contents Performance Counters and Key Performance Indicators

7-2

KPI example - CS IRAT HO success rate (UMTS -> GSM)

7-6

CS IRAT HO success rate (UMTS -> GSM)

7-7


7-8

Parameter trigger event basis

7-10

Parameter setting

7-12

Parameter discussion

7-13


UTRAN key performance indicators

Performance Counters and Key Performance Indicators ................................................................................................................................................................................................................................... What are Performance Counters?

The Performance Counters are metrics that may be used to assess the performance of process steps within a UMTS network. The 3GPP standards define four types of measurement counters: • • • •

Cumulative counter pegging Discrete event notification Gauge (dynamic variable) Status inspection counter pegging.

Performance Management

Performance Management (PM) is used to schedule the collection and transfer of performance data. The data collected is used to verify the following • • • •

Grade and quality of service RF planning & optimization Network load For example, call processing flow.

Performance Measurement scheduling

The measurement schedule specifies the time frames during which the measurement job will be active. The amount of data that is collected by a network element is determined by the settings of: • • • •

The The The The

data aggregation interval reporting period recording interval measurement schedule

The diagram shows the relation between these values:


7-2



12:00

Full Hour

Recording Interval

Reporting Period

14:00

Results transferred

Results computed

Time

Aggregation Interval Measurement collection start Create or Resume measurement Job

Measurement collection stop

Available PM counters

In UMTS PM counters are available on logical network element level, for example: • •

RNC, NodeB, SGSN, GGSN, HLR, ATM, { and/or RACH/PACH/PCH/DCH, LAC/RAC, Iur, {

For detailed information refer to the relevant chapters in the Performance Measurements Definitions Manual, UMTS-04.03/IMS 5.0, 401-382-803R04.03. What are Key Performance Indicators?

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

Key Performance Indicators are available within the UTRAN in following areas: • •

Accessibility performance indicators Reliability (call drop) performance indicators




•

Quality performance indicators

•

Throughput and rate performance indicators:

•

•

•

•

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


7-4



•

Common control channel / load performance indicators

•

Location services performance indicators.

For detailed information refer to the relevant chapters in the Performance Measurements Definitions Manual, UMTS-04.03/IMS 5.0, 401-382-803R04.03. Difference between Drive Test data and KPI data

PM counters and KPIs reflect the network viewpoint, whereas Drive Test data reflect the subscriber’s viewpoint.



KPI example - CS IRAT HO success rate (UMTS -> GSM) ................................................................................................................................................................................................................................... KPI definition

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


7-6


CS IRAT HO success rate (UMTS -> GSM) ................................................................................................................................................................................................................................... Description

This KPI indicates the overall hard handover inter RAT performance towards GSM network for CS calls starting from the relocation attempt. Relocation attempts are triggered by transmission of a RANAP message RELOCATION REQUIRED from the SRNC to the MSC, indicating an attempted relocation preparation of a UMTS to GSM handover. Note: Normally released calls during IRAT should not be considered for this success ratio. They are subtracted from the attempts. Formula

The formula to calculate the CS IRAT HO success rate (UMTS -> GSM): IRATHO.SuccOutCS

=

x 100 IRATHO.AttRelocPrepOutCS - IRATHO.FailRelocPrepOutCS.RelocCanc

Related performance measurements

The related performance measurements are: • • •

IRATHO.AttRelocPrepOutCS IRATHO.SuccOutCS IRATHO.FailRelocPrepOutCS.RelocCanc

Reporting range

The performance indicator report can be generated per: • •

Cell (SRNC) PRNC(DRNC)

Class

This is a class 1 KPI.



Performance counter trigger event basis ................................................................................................................................................................................................................................... Performance counter trigger conditions

The following trigger conditions apply for the performance counters of this KPI: •

IRATHO.AttRelocPrepOutCS

The counter is incremented on transmission of a RANAP message RELOCATION REQUIRED from the SRNC to the MSC, indicating an attempted relocation preparation of a UMTS to GSM handover. •

IRATHO.SuccOutCS

The counter is incremented on receipt of a RANAP message IU RELEASE COMMAND sent from the CS CN to the serving RNC, indicating a successful inter-RAT handover with cause IE set to “Successful Relocation (11)” or “Normal Release (83)”. •

IRATHO.FailRelocPrepOutCS.RelocCanc

The counter is incremented on receipt of a RANAP message RELOCATION PREPARATION FAILURE containing the cause, “Relocation Cancelled (10)”, sent from the MSC to the SRNC indicating a failed relocation preparation for UMTS to GSM. In case the best cell is on the SRNC, the cell MO representing the best cell is incremented. In case the best cell is on the DRNC, the PRNC MO representing the best cell is incremented. Note: Normally released calls during IRAT should not be considered for this success ratio. They are subtracted from the attempts. Flow diagram

The following flow chart shows the sequence of events for CS (Circuit Switched) inter-RAT UMTS to GSM handover. The performance counters IRATHO.AttRelocPrepOutCS, IRATHO.AttRelocPrepOutCS.RelocCancand IRATHO.SuccOutCS are used in the KPI formula.


7-8



Ongoing CS Voice CallInter-RAT UMTS to GSM HO has been triggered

Additional failures causing inc. of: IRATHO.FailRelocPrepOutCS.sum - Receive a RANAP Relocation Command containing RABs to be deleted - Receive a RANAP Relocation Command which does not contain L3 information - Lost communication with the UE due to all Radio Links failing.

RNC sends RANAP “Relocation Required” to the MSC Inc: IRATHO.AttRelocPrepOutCS

Relocation Command received?

N

Relocation Preparation Failure received?

N

RNC sends RRC “Handover from UTRAN Command” to the UE Increment: IRATHO.AttOutCS Increment: NumUMTS-GSM_HOPerNCell.Att If trigger was based on RSCP: Increment: IRATHO.AttOutCS.RSCP

Inc: IRATHO.FailRelocPrepOutCS.sum and depending on the cause received from MSC Increment the following sub counters of: IRATHO.FailRelocPrepOutCS: .FailTarSys .NotSupTarSys .TarNotAllowed .NoRRTarSys

Retry with another GSM target cell?

N

Y

Y

Y

TRELOCprep expired?

The RNC initiates the RANAP Relocation Cancel procedure. The call is continued in UMTS. Increment following sub counters of: IRATHO.FailRelocPrepOutCS: .sum .T_RELOCprep_exp

END Y

N The call is continued in UMTS

END

Iu Release Command received?

N

Y RNC releases resources and sends Iu Release Complete If cause is set to 'Successful Relocation' or 'Normal Release': Inc: IRATHO.SuccOutCS If trigger was based on RSCP: Inc: IRATHO.SuccOutCS.RSCP

END

Handover from UTRAN Failure received?

N

Y The call is continued in UMTS Inc: NumUMTS-GSM_HOPerNCell.Fail Inc: IRATHO.FailOutCS.sum Depending on the cause received from the UE increment either: IRATHO.FailOutCS.PhyChnFail IRATHO.FailOutCS.ConfUnaccept IRATHO.FailOutCS.ProtErr

TRELOCOverall expired?

N

Y RNC issues an Iu Release Request to the MSC. Inc: IRATHO.TRelocOverall

END

END



Parameter trigger event basis ................................................................................................................................................................................................................................... Parameter trigger conditions

The most relevant parameters and their setting for this process are: •

•

•

•

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


7-10


Parameter trigger event basis

IRAT handover events 2D and 3C

The following graphic shows the Inter-RAT handover events 2D and 3C for the UMTS to GSM handover service “should”. Measurement Quantity

Event 2D threshold used system below

DT

DT

CPICH (UTRAN)

umts2GsmQActCM2D

IRATHO.AttRelocPrepOutCS

umts2GsmQTriggerMAHO IRATHO.SuccOutCS

Event 3C threshold GSM above

RSSI (GSM)

Time UTRAN Cell Connected

Event 2D Start compressed mode measurements

Event 3C Relocate to GSM

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



Parameter setting ................................................................................................................................................................................................................................... Parameters and initial value settings

The actions for the Inter-RAT handover considered depend on values of parameters which trigger the Mobile Assisted Handover Process (MAHO) from UMTS to GSM. The most relevant parameters and their setting for this process are: • •

•

•

Measurement quantity for Inter-RAT HO trigger condition: Parameter: measurementQuantityInterRATHHO: RSCP_ECN0 Compressed Mode Activation: Parameter: umts2GsmQActCM2D – .rSCPThreshold: -111 dBm – .eCN0Threshold: -16 dB – .timeToTrigger: 320 ms Compressed Mode Deactivation: Parameter: umts2GsmQDeactCM2F – .rSCPThreshold: -108 dBm – .eCN0Threshold: -13 dB – .timeToTrigger: 5000 ms MAHO Trigger Condition: Parameter: umts2GsmQTriggerMAHO – .rSCPThreshold: -108 dBm – .eCN0Threshold: -13.0 dB – .timeToTrigger: 120 ms – .weight: 1.0


7-12


Parameter discussion ................................................................................................................................................................................................................................... Purpose

The following tables display and discuss the parameter settings that are relevant for the Inter-RAT Handover of a Circuit Switched call from UMTS to GSM. measurementQuantityInterRATHHO

The following table displays the settings for the parameter “Measurement quantity for Inter-RAT HO trigger condition”: Subparameters

Recommendation

Explanation

RSCP

Boundary cells

When going away from the center of the UMTS cell, the RSCP level may lower, whereas the Ec/No may stay constant. In this situation, Ec/No measurements will not be a suitable basis for Inter-RAT trigger conditions.

ECN0

Central cells

When going towards the center of the UMTS cell, the RSCP level may stay constant, whereas the noise level may change significantly. In this situation, RSCP measurements will not be a suitable basis for Inter-RAT trigger conditions.

RSCP_ECN0

Default setting

In most cases, the measurements of both, RSCP and Ec/No measurements will be a suitable basis for Inter-RAT trigger conditions.

umts2GsmQTriggerMAHO

The following table displays the settings for the parameter “MAHO Trigger Condition”: Subparameters

Too low values

Too high values

rSCPThreshold/ eCN0Threshold

Handover is triggered too late.

Handover is triggered too early.

Call quality may get unacceptably bad.

A handover to GSM is performed although the quality of the UMTS signal is sufficient, i.e. the UE is still inside the UMTS area.

Call may drop. The value should be chosen higher than required for minimal call quality of a static call. This is necessary to regard for the time that is required to execute the handover to GSM and the movement of the UE.




Subparameters

Too low values

Too high values

timeToTrigger

Handover is triggered too early.

Handover is triggered too late.

Measurement report is sent even if the trigger condition is only fulfilled for a very short time. Such fast time fading may be caused for example by interference and should not cause a handover to GSM.

Call will drop

Quality of the strongest cell has higher influence than the estimated quality of the active set.

Quality of the strongest cell has less influence than the estimated quality of the active set.

weight: 0 means that the strongest cell of the Active Set is taken into account, only.

weight: 1 means that all cells of the Active Set are taken account with the same preference.

weight: <1 means that the quality of

weight: >1 means that the quality of

the strongest cell is taken into account with higher preference than the other cells of the Active Set.

the strongest cell is taken into account with lower preference than the other cells of the Active Set.

weight

In case of bad quality the UE has to wait for the time to trigger before sending the measurement report. This time in conjunction with the time for the execution of the handover to GSM, the UE may have already moved out of coverage of the UMTS area and is not able to receive the handover command from the UMTS network.

umts2GsmQActCM2D

The following table displays the settings for the parameter “Compressed Mode Activation”:


7-14



Subparameters

Too low values

Too high values


Compressed mode will be activated too late.

Compressed mode is activated earlier than required.

Call may drop before IRAT PMs can be performed.

CM active although quality of UMTS signal is sufficient, IRAT HO not to be considered at this time.

Call may drop before HO to GSM is initiated. Set value to the same or higher value than the HO threshold (umts2GsmQTriggerMAHO.threshold).

CM has negative impact on throughput and/or cell capacity and it should be avoided to activate compressed mode if not required,

The time of activated CM is reduced to a minimum if both thresholds are equal at a constant TTT. A higher threshold for CM activation may be required to regard for further quality degradation during the time the UE performs IRAT PMs. timeToTrigger

Compressed mode will be activated earlier than required.

Compressed mode will be activated too late.

Measurement report is sent even if the trigger condition is only fulfilled for a very short time.

Call may drop due to following scenario: In case of bad quality UE has to wait for the time to trigger before sending the PM report. Further time is required to activate CM, perform IRAT PMs and execute the HO to GSM. During this time the UE may already have moved out of UMTS coverage area, and the call drops.

Fast time fading may be caused due to interference and should not trigger the activation of CM.

umts2GsmQDeactCM2F

The following table displays the settings for the parameter “Compressed Mode Deactivation”:




Subparameters

Too low values

Too high values


Frequent toggling of the compressed mode

Compressed mode is kept activated very long.

Compressed mode is deactivated after a previous activation if the UMTS quality raises only by a small amount.

CM active although quality of UMTS signal is sufficient, IRAT HO not to be considered at this time.

High signalling load Negative effect on the call quality.

CM has negative impact on throughput and/or cell capacity and it should be avoided to keep CM activated if not required.

Compressed mode will be deactivated earlier than required.

Compressed mode will be deactivated too late.

timeToTrigger

Measurement report is sent even if the trigger condition is only fulfilled for a very short time. Fast time fading may be caused due to interference and should not trigger the deactivation of CM.


7-16

8

8 all availability optimization C and troubleshooting


This chapter describes the UTRAN measurements and performance indicators that can be used to localize problems and to optimize issues related to setting up mobile originating and mobile terminating calls. Contents Call availability

8-3

Call availability

8-4


8-6

Accessibility

8-7

Access preliminary procedures

8-8

Cell re-selection failures

8-9


8-11

RRC connection establishment analysis

8-15

Introduction to RRC connection establishment

8-16

Call admission control failures

8-19

Radio link setup analysis

8-21

RRC connection setup failure

8-23

Paging failures

8-24

RAB establishment analysis

8-26

RAB establishment

8-27


8-30

Radio bearer establishment failures

8-32


Call availability optimization and troubleshooting

No answer from UE

Overview

8-33


8-2


Call availability Overview ................................................................................................................................................................................................................................... Purpose

This section describes the performance indicators that can be used to retrieve information about the overall network accessibility. Contents Call availability

8-4


8-6



Call availability ................................................................................................................................................................................................................................... Introduction

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

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

In order to allow the user to originate or receive a call, the UE has to perform: • • •

Cell (re)-selection and random access procedure UE registration with CN Reception of paging if receiving a call.

Call setup failures

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

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


8-4


Call availability

RRC connection establishment phase

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

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



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

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

The related PMs / KPIs are: • • • • • •

CS Data call success rate CS Speech call success rate PS call success rate E-DCH call success rate HSDPA call success rate DCH call success rate

Each of the KPIs above is derived from multiplying the service type specific RAB establishment success rate, the successful RRC connection establishment rate and the relevant Standalone Radio Bearer drop rate. Abnormal accessibility rate values

When one of the accessibility rate values is very low, the reason can be caused by many different issues. Therefore it is advised to localize the issue by analyzing the performance measurements and KPIs separated over the accessibility call phases: • • • •

Network level access phase RRC connection establishment phase Signaling Radio Bearer (SRB) drop RAB establishment phase.


8-6


Accessibility Overview ................................................................................................................................................................................................................................... Purpose

This section describes which performance measurements and performance indicators can be used to analyze the network performance during the access phase. Note: This procedure is often also referred to as the preliminary procedure, which should be performed before the UE can gain network access. Contents Access preliminary procedures

8-8


8-9


8-11



Access preliminary procedures ................................................................................................................................................................................................................................... Preliminary procedures failures

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

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


8-8


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

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

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




Related PMs / KPIs

The related PMs are: • • • • • • • •

VS.MM.CellUpdateReq.CellReselect VS.MM.RRCConnDrop.CellResel_CellUp VS.MM.RRCConnDrop.Period_UraUpdate VS.MM.UraUpdateReq.UraChange VS.MM.UraUpdateReq.PeriodUpdate VS.SS7LocUpdateAttSucc MM.AttInterSgsnRaUpdate.U MM.AttIntraSgsnRaUpdate.U

The related KPIs are: •

Cell update request rate due to cell reselection


8-10


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.

The RACH procedure has been successfully performed when the RRC connection request message is received by the RNC upon successful decoding at the Node B. RACH procedure

The RACH is transmitted on the physical layer in two separated parts: 1. A certain number of RACH preambles are sent. The power of the first RACH preamble is relatively low and is calculated using open loop power control 2. Each of the following RACH preambles are transmitted with an increased power till an acknowledgment (ACK) is received on the AICH 3. After receiving the ACK on the AICH the UE transmits the RACH message part with an embedded RRCconnection request message. UE

Node B

Uu

Iub

RNC

RACH Preamble

RACH Preamble

RACH Preamble

Access indication (AICH) RACH message RRC

RRC (RRC Connection Request)

VS.RACHTransBlock.Bad VS.RACHTransBlock.Good




Timer settings

Guard timer T300 (determined by UTRAN parameter t300) and N300 (determined by UTRAN parameter n300) is supervising the transmission of the RRC Connection Request message on the UE side. Poor settings of timer n300 may result in insufficient retransmission of the RACH message and poor settings for timer t300 may result in RACH messages being retransmitted too early or too late and thus affecting the procedures that initiated the RACH access (for example Call setup). If the RACH Preamble is acknowledged at a very low Eb/N0 and parameter powerOffsetPpm is set relatively small, this will increase the probability that the RACH Message Part would be sent at a power that is too low to be decoded correctly (bad CRC) by the NodeB. If powerOffsetPpm is set above the recommended value, the success rate of RACH will improve (the rate of RACH Message Part received with good CRC increases). However, this increase of the power of the RACH Message Part will cause additional uplink interference to the system. Possible failing reasons

Possible reasons why the RACH access procedure could fail are: • • • • •

The Node B does not successfully decode any of the RACH preambles The UE does not receive an ACK on the AICH (Acquisition Indicator Channel) The UE is receiving a NACK on the AICH The Node B does not successfully decode the RACH message part Unsuccessful retransmission of the RACH message part.

There could also be reasons of large cell/sector size and UEs with lower power than the designed value (UE power class) which could cause unsuccessful decoding or acknowledgement of RACH preambles and messages. PMs / KPIs indications

RRC.AttConnEstab.sum is triggered on the RNC after reception of the RRC connection request message independent of the establishment cause. Low values at a specific NodeB of RRC.AttConnEstab.sum are indicative of problems. Nevertheless this counter cannot prove that there are actually problems because, for example, NACKs sent by Node B on AICH are not counted. It may be that at a particular cell low traffic is resulting in low values of counter RRC.AttConnEstab.sum. However the KPI - Successful RRC connection establishment rate (including repeated attempts) calculates the RRC Connection establishments with repeated attempts which can be used to assess the Access issue from the network perspective. Low values show that the access process may need to be optimized and there could be RACH access failures. It must be noted that though this KPI is low, it does not mean that the .................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

8-12



subscriber faces an issue in access since there would be several retries of the RRC attempt before it is a failed RRC connection attempt which requires the subscriber to try again. The number of retries is set by the parameter n300 in the OMC. The PM counters VS.RACHTransBlock.Bad and VS.RACHTransBlock.Good may be used to arrive at the ratio between number of RACH TBs received with bad CRC to total number of RACH TBs. A high value for this ratio may be indicative of problems with the quality over the RACH. The KPI - RACH transport block good CRC rate can be used to obtain the percentage of Transport Blocks with good CRC and low values are indicative of issues of reduced power of the RACH message part (causing bad CRC) and may be related to settings of powerOffsetPpm. The PM counter VS.ChannelOccupRateRACH is the ratio of total bits transferred on the RACH to maximum bits available for RACH usage (service rate) per granularity period. If this ratio is very high the resources on the RACH may not be sufficient. The PM counter VS.RACHcongestion provides the percentage of time the RACH is in congested state. This helps to determine the overload status for the RACH and is useful for field diagnostics. The following PM counters maybe used to study failures in the Access procedure: •

•

•

•

RRC.FailConnEstab.SetupIncomplete Number of RRC connection attempt failures, when RNC does not receive the “RRC Connection Setup Complete” message from the UE. Includes failures for repeated RRC connection attempts from the same UE. RRC.FailConnEstab.sum This measurement provides the total number of failed RRC connection establishments. Includes rejects for repeated RRC connection attempts from the same UE RRC.FailConnEstab.CAC This counter is incremented whenever the RNC sends an “RRC Connection Reject” message with cause “Congestion”. Congestion will occur due to Call Admission Control (CAC). RRC.FailConnEstab.RLSetupFailure This counter is incremented whenever the RNC sends an “RRC Connection Reject” message with cause “unspecified” for the case where the SRNC receives a “Radio Link Setup Failure” message.

Related PMs / KPIs

The related PMs / KPIs are: • •

VS.RACHTransBlock.Bad VS.RACHTransBlock.Good



•

VS.ChannelOccupRateRACH

•

VS.RACHcongestion

• • • • •

RACH transport block good CRC rate RRC.FailConnEstab.SetupIncomplete RRC.FailConnEstab.sum: RRC.FailConnEstab.CAC RRC.FailConnEstab.RLSetupFailure



8-14


RRC connection establishment analysis Overview ................................................................................................................................................................................................................................... Purpose

This section describes the performance measurements and performance indicators can be used to localize problems and to optimize issues related to the RRC connection establishment. Contents Introduction to RRC connection establishment

8-16


8-19


8-21

RRC connection setup failure

8-23

Paging failures

8-24



Introduction to RRC connection establishment ................................................................................................................................................................................................................................... RRC Connection establishment procedure

In general the RRC connection establishment procedure may occur in different scenarios such as: • • •

Network attach Location and Routing Area Update MO/MT call setup.

RRC connection establishment starts with the successful receipt at the RNC of the RRC connection request message. This means that cell selection/re-selection as well as random access procedures have been successfully completed. Call setup stages

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


8-16


UE

Node B

Uu RRC


Iub

RRC Connection Request

RNC RRC

(RACH) CAC NBAP

NBAP

RL Setup Request

RL Setup Response

1

RRC.FailConnEstab.CAC

2

RRC.FailConnEstab.RLSetupFailure

NBAP

NBAP

ALCAP Iub transport bearer

DCH-FP: UL/DL synchronization

RRC

RRC Connection Setup

RRC

(CCCH over FACH)

3 RRC.FailConnEstab.SetupIncomplete RRC

RRC Connection Setup Complete

RRC

(DCCH over DCH)

Connection establishment failures

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

Call admission control failures Radio link setup failures RRC connection setup failures Paging failures Soft/softer handover failures at call setup RNC Processor Overload. Iub congestion

Most of these failure causes are normally associated with poor RF conditions and can be seen from measurements RRC.FailConnEstab.SetupIncomplete and RRC.FailConnEstab.RLSetupFailure. Congestion in the NodeB/RNC can cause RRC Connection failures and will be seen from the measurement RRC.FailConnEstab.CAC. Overload of the RNC processor can cause discards of RRC Connection requests which can consequently affect the Successful RRC Connection Establishment rate (included




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

The related PMs / KPIs are: • • • • • • • • • • • • • • •

RRC.FailConnEstab.SetupIncomplete RRC.FailConnEstab.CAC RRC.FailConnEstab.RLSetupFailure Successful RRC connections establishment rate (including repeated attempts) RRC establishment success rate (UE perspective) RRC.FailConnEstab.ProcessorLoad RRC.FailConnEstab.CongOrigConvCall RRC.FailConnEstab.CongTermConvCall RRC.FailConnEstab.CongOrigStrmCall RRC.FailConnEstab.CongTermStrmCall RRC.FailConnEstab.CongOrigIntactCall RRC.FailConnEstab.CongTermIntactCall RRC.FailConnEstab.CongOrigBgrdCall RRC.FailConnEstab.CongTermBgrdCall RRC.FailConnEstab.CongOrigHighPrioSig


8-18


Call admission control failures ................................................................................................................................................................................................................................... Introduction

Call Admission Control (CAC) is used to prevent overload of the system. Load conditions for the downlink are based on the total transmit power of the cell. The uplink load measure is the measured RSSI value relative to the typical noise floor that was estimated using long term measurements. If the defined load thresholds for CAC are exceeded the RRC connection establishment request is denied and a RRC Connection Reject message with cause, “Congestion” is sent by the RNC to the UE. Abnormal value

The triggering of CAC can be partly monitored using the PM counter, RRC.FailConnEstab.CAC that is triggered in case of CAC. If the values of this counter indicate that overload situations have occurred over long periods of time, CAC should be the reason for the experienced call setup problems. The KPI, Failed RRC connection establishment rate - congestion (conv Call) can be used to find issues related to conversation calls. The KPI, Failed PS RRC connection establishment rate - Congestion will help identify cells where the RRC Connections have failed to establish for Packet calls due to congestion. Load measurements

Other counters related to system load such as VS.RF.ForwrdTrafficChn.Overload, which provides the percentage of time the carrier was in power control overload, VS.RF.ChanElementUsage.Total, and related counts that provide the percentage of Channel Element usage in the NodeB, Transmitted Carrier Power - VS.RF.TxPwr.AllCodes.Max, VS.RF.TxPwrMean.AllCodes, Received total wideband power VS.RF.RTWP.Max, VS.RF.RTWP.Mean and Channel Code Utilization which provides the percentage of Code utilization. All of these may be used to verify whether the load in the cell is fairly high, which would increase the probability for call setup failures. Related PMs / KPIs

The related PMs / KPIs are: • • • • •

RRC.FailConnEstab.CAC VS.RF.ForwrdTrafficChn.Overload VS.RF.ChanElementUsage.Total VS.ChanCodeUtil VS.RF.ChanElementUsage.Dedicated



•

VS.RF.ChanElementUsage.DCH.Mean

•

VS.RF.ChanElementUsage.DCH.Max

• • • • • • • • • • • • • • • • • •

VS.RF.ChanElementUsage.EDCH.Mean VS.RF.ChanElementUsage.EDCH.Max VS.RF.ChanElementUsage.HSDPA.Mean VS.RF.ChanElementUsage.HSDPA.Max VS.FP.UL.CongTime VS.RF.TxPwr.AllCodes.Max VS.RF.TxPwrMean.AllCodes VS.RF.RTWP.Max VS.RF.RTWP.Mean RRC.FailConnEstab.CongOrigConvCall RRC.FailConnEstab.CongTermConvCall RRC.FailConnEstab.CongOrigStrmCall RRC.FailConnEstab.CongTermStrmCall RRC.FailConnEstab.CongOrigIntactCall RRC.FailConnEstab.CongTermIntactCall RRC.FailConnEstab.CongOrigBgrdCall RRC.FailConnEstab.CongTermBgrdCall RRC.FailConnEstab.CongOrigHighPrioSig



8-20


Radio link setup analysis ................................................................................................................................................................................................................................... Introduction

Once the RNC has verified that the requested resources have passed the call admission control check, the RNC requests the Node B to allocate these resources through the NBAP radio link setup procedure. In general at least one radio link has to be set up. In the case where the UE is in a soft/softer handover region during call setup more than one radio link has to be set up. Note: A radio link is associated to one cell, while a RAB is associated to one UE per service type. Radio link setup failure

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

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

The measurements RLM.FailRLSetupIub.TransRes.CSV, RLM.FailRLSetupIub.TransRes.PSD, RLM.FailRLSetupIub.TransRes.CSD and RLM.FailRLSetupIur.TransRes record failures in Radio Link setup procedure. High values for these counters indicate that there are failures due to missing transport resource. This indicates that transport resource is unavailable due to missing binding IDs for the transport bearer.




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

The related PMs / KPIs are: • • • • • • • • • • •

RLM.FailRLSetupIur.sum RLM.FailRLSetupIub.NodeBRes.CSV RLM.FailRLSetupIub.NodeBRes.CSD RLM.FailRLSetupIub.NodeBRes.PSD RLM.FailRLSetupIub.TransRes.CSV RLM.FailRLSetupIub.TransRes.CSD RLM.FailRLSetupIub.TransRes.PSD RLM.FailRLSetupIur.TransRes VS.RF.ChanElementUsage.Total VS.RF.ChanElementUsage.Dedicated RRC.FailConnEstab.RLSetupFailure


8-22


RRC connection setup failure ................................................................................................................................................................................................................................... Introduction

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

The related PMs / KPIs are: •

RRC.FailConnEstab.SetupIncomplete Abnormally high values of the above mostly point to RF related issues like coverage/interference or parameter settings

Possible reasons for high values are: 1. Optimal settings of the UTRAN attributes uERRCConnSetup-ResponseTimer and maxRRCConnSetupRetries are not correct 2. The RRC connection setup message is not successfully decoded due to poor FACH coverage 3. The RNC cannot successfully decode the RRC connection setup complete message.



Paging failures ................................................................................................................................................................................................................................... Paging procedure

In case of an MT call the UE in Idle state has to be paged before sending the RRC Connection Request message. The RRC paging Type 1 message is sent on the Paging Channel (PCH) by the core network (this means 3G-MSC for circuit-switched calls or SGSN for packet-switched calls) to all the UEs belonging to the same Location Area (LA), in case of a CS MT call or to the same Routing Area (RA), in case of a PS MT call. In a successful case the UE receives, and correctly decodes, the paging message and sends back the RRC Connection Request message with the relevant cause to the UTRAN (this means Terminating High Priority Signaling for PS calls and Terminating Conversational Call for Voice calls). However it may occur that the UE either does not receive or does not correctly decode the Paging message. PMs / KPIs indications

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

In general, the possible failure causes are Paging Channel (PCH) congestion or poor PCH coverage. Also issues on the transport network may impact the Paging procedure, for example: • • • •

Transport messages Transport Transport Transport

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. Processor overload in the RNC can also cause Paging messages to be discarded. RRC Connections are dropped when the UE does not respond to Paging messages possibly due to coverage or UE issues. This is recorded by the measurement, VS.MM.RRCConnDrop.UTRANPagingFailure.


8-24


Paging failures

Related PMs / KPIs

The related PMs / KPIs are: • • • •

VS.MM.NumPageAttDiscard VS.MM.PagAttDiscard.ProcessorLoad VS.ChannelOccupRatePCH VS.MM.RRCConnDrop.UTRANPagingFailure.

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



RAB establishment analysis Overview ................................................................................................................................................................................................................................... Purpose

This section describes the performance measurements and performance indicators can be used to localize problems and to optimize issues related to the RAB establishment. Contents RAB establishment

8-27


8-30

Radio bearer establishment failures

8-32

No answer from UE

8-33


8-26


RAB establishment ................................................................................................................................................................................................................................... RAB establishment procedure

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

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

An example RAB establishment call flow:



UE

RAB establishment

Node B

SRNC

Uu

Iu-ps/cs

Iub

MSC/SGSN

RRC UL Direct Transfer RANAP Direct Transfer

(PS: PDP Context Request CS: Call Setup Request)

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

RRC DL Direct Transfer (CS ONLY: Call Proceeding) RANAP RAB assignment request

ALCAP Iu transport bearer establishment (Only for CS domain)

DBC NBAP Radio link reconfiguration prepare NBAP Radio link reconfiguration ready

RAB.FailEstabCSNoQueuing.ULIntfer RAB.FailEstabPSNoQueuing.ULIntfer RAB.FailEstabCSNoQueuing.DLPwr RAB.FailEstabPSNoQueuing.DLPwr RAB.FailEstabCSNoQueuing.CodeStarv RAB.FailEstabPSNoQueuing.CodeStarv

ALCAP Iub transport bearer establishment Node B RNC data transport bearer sync Radio link reconfiguration commit

RAB.FailEstabCSNoQueuing.RBSetupFail RAB.FailEstabPSNoQueuing.RBSetupFail RRC Radio bearer setup (DCCH over DCH)

RAB.FailEstabCSNoQueuing.T3exp RAB.FailEstabPSNoQueuing.T3exp

RRC Radio bearer setup complete (DCCH over DCH)

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

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


8-28


RAB establishment

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

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 RRC Radio Bearer Establishment RANAP RAB Assignment Response PDP Context Accept (PS) or Call Alerting and Connect Procedures

RAB establishment attempt failures

The major RAB establishment attempt failure components may be classified as follows: • • •

Dynamic bearer control failure Radio bearer establishment failures Miscellaneous failures, for example code starvation.

PMs / KPIs indications


RAB establishment success rate CSV RAB establishment success rate PS RAB establishment success rate CSD RAB establishment success rate E-DCH PS RAB Establishment Success Rate

• •

HSDPA PS RAB establishment success rate DCH PS RAB establishment success rate



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

During RAB establishment the Dynamic Bearer Control (DBC) procedure is triggered (see “RAB establishment call flow” (p. 8-27)). During the DBC check if the Uplink, Downlink or Code resources are not available (this is checked against the DBC threshold), then the DBC failure occurs and the RAB establishment process is discontinued. Uplink Interference

When the DBC threshold for Uplink Interference is crossed, a DBC failure occurs and a RAB Assignment response failure is sent by the RNC causing the measurements RAB.FailEstabCSNoQueuing.ULIntfer and RAB.FailEstabPSNoQueuing.ULIntfer for CS or PS RAB assignment respectively to be pegged. This maybe due to interference from other mobiles or related to antenna or cable issues. Downlink Power

When the DBC threshold for Downlink power is crossed, a DBC failure occurs and a RAB Assignment response failure is sent by the RNC causing the measurements RAB.FailEstabCSNoQueuing.DLPwr and RAB.FailEstabPSNoQueuing.DLPwr for CS or PS RAB assignment respectively to be pegged. This is related to unavailability of Downlink power resource in the NodeB to establish the new RAB connection. This maybe due to a large number of voice or low speed calls or few high speed calls that have consumed NodeB power resources. Code Starvation

When a DBC failure occurs due to lack of Code resources, a RAB Assignment response failure is sent by the RNC causing the measurements RAB.FailEstabCSNoQueuing.CodeStarv and RAB.FailEstabPSNoQueuing.CodeStarv for CS or PS RAB assignment respectively to be pegged. The measurement VS.ChanCodeUtil can be monitored for code usage in conjunction with this RAB failure measurement. System load counters

Counters related to system load such as VS.RF.ForwrdTrafficChn.Overload, VS.RF.TxCodePwr.Max, VS.RF.TxCodePwr.Mean and VS.RF.RTWP.Max, VS.RF.RTWP.Mean may be used to verify that the load in the cell or NodeB is fairly high.


8-30



Other counters

Issues in the NodeB that causes RAB Establishment failure due to NodeB specific errors or time expiries, but not due to lack of resources are captured by the counters: • •

RAB.FailEstabCSNoQueuing.RLReconfFail.NodeBErr RAB.FailEstabPSNoQueuing.RLReconfFail.NodeBErr

Related PMs / KPIs

The related PMs / KPIs are: • • • • • • • • •

VS.RF.ForwrdTrafficChn.Overload VS.RF.TxCodePwr.Max VS.RF.TxCodePwr.Mean VS.RF.RTWP.Max VS.RF.RTWP.Mean VS.ChanCodeUtil VS.FwdPowerOvldDuration RAB.FailEstabCSNoQueuing.RLReconfFail.NodeBErr RAB.FailEstabPSNoQueuing.RLReconfFail.NodeBErr



Radio bearer establishment failures ................................................................................................................................................................................................................................... Introduction

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

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

Upon receiving the radio bearer setup message the UE may not successfully allocate the required resources to setup the new radio bearer. In this case the UE sends back the radio bearer setup failure message to the RNC and the radio bearer establishment procedure fails. Possible reasons for Radio Bearer establishment failures are: • •

A radio bearer failure from the UE No answer from UE

This is mainly caused by poor RF conditions. All RB failures impact the value of the KPI RAB Establishment Success Rate. They can be identified via the PM counters RAB.FailEstabCSNoQueuing.RBSetupFail and RAB.FailEstabCSNoQueuing.RBSetupFail, triggered when radio bearer setup failure message is received at the RNC.


8-32


No answer from UE ................................................................................................................................................................................................................................... Introduction

Upon sending the RRC radio bearer setup message to the UE, a guard timer is started on the RNC in order to supervise the reception of the RRC radio bearer setup complete message from the UE. The guard timer is configured by UTRAN parameter uERadioBearerSetup-ResponseTimer. If the guard timer expires and no message is received from the UE, then the radio bearer establishment procedure fails and all the allocated UTRAN resources are released. No answer from UE failures

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

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


RAB.FailEstabCSNoQueuing.T3exp RAB.FailEstabPSNoQueuing.T3exp RAB.FailEstabPSNoQueuing.T3exp.DCH_DCH RAB.FailEstabPSNoQueuing.T3exp.DCH_HSDSCH RAB.FailEstabPSNoQueuing.T3exp.EDCH_HSDSCH


9

9 all reliability optimization and C troubleshooting


This chapter describes the UTRAN measurements and performance indicators that can be used to localize problems and to optimize issues related to maintaining the call. Contents Dropped calls analysis

9-2


9-6


9-9


Call reliability optimization and troubleshooting

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

As soon as the call is successfully set-up, the second factor of the UMTS user perception is the probability of maintaining the call, as opposed to the probability of dropping the call. A call drop is defined as an abnormal termination of a voice/data session due to any reason causing the user to re-initiate the session. A drop on a PS session will still result in PDP context preservation, and the end user will be able to re-establish seamlessly (with some delay). PS drops are generally not as severe for end users as CS drops. On the UTRAN side the KPIs, CS Speech RAB Drop Rate PS Data, RAB Drop Rate and CS Data RAB drop rate, which are defined as the percentage of dropped RAB due to any UTRAN generated reason against the total number of established RABs for the different type of services, can be calculated. Signalling flow

The signaling flow of total RABs dropped (all service types):


9-2


UE

Uu


Node B

RNC

Iub

Iu-ps

SGSN

RRC

RRC RAB 64 kbps UL and DL

A dropped RAB connection due to any kind of failure

Note: RNC decides to drop RAB due to an unrecoverable failure

Cell_DCH

Iu release request (UTRAN generated reason) RANAP

RANAP

RAB.Rel.Drop.sum Iu release command (Release cause: as per TS 25.413) RANAP

RANAP

RRC Connection release (Note: message sent if RRC connection still exists) (DCCH) RRC Connection release complete (Release cause: as per TS 25.331) (DCCH) NBAP RL Deletion procedure

ALCAP release procedure RANAP Iu release complete UE_Idle

On the UTRAN call handling procedures the dropped RABs are identified by the following: • • • •

RANAP Iu Release Request procedure RANAP Iu RAB Release Request procedure RANAP Reset procedure RANAP Reset Resource procedure

In case of an Iu Release Request message the resources on the UTRAN and core network are released. ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 9-3 Issue 1, August 2007 See notice on first page



Note: For PS calls the PDP context will not be released in the SGSN and the context will move into the preserved state. Possible failing reasons

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

• • • • • • • •

Radio Link Failure, caused by: – poor RF coverage – poorly defined neighbor list – poor Primary Scrambling Code (PSC) plan-pilot pollution – DL power overload. – UL Interference Operator intervention (for example reset, lock action) Inter-RAT handover due to supervision timer expiry (UMTS to GSM) URA_PCH time-out (due to the UE not performing a periodical URA update) Iu, Iub and Iur link failure RRC signal connection release Indication sent by the UE. Failures during SRNS Relocation procedure Unsuccessful termination of the Iu Rate control procedure UE Inactivity.

There are several PM counts listed in the UMTS Performance Measurements Definition Manual, 401-382-803 that list the RAB Drop counter for the different causes stated above. These can be studied with respect to the number of established RABs to obtain a ratio for the specific issue and studied on a cell by cell basis to find out high runner cells. Related PMs / KPIs


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


9-4


•

UTRAN HSDPA RAB drop rate - HSDPA traffic

•

DCH RAB drop rate - DCH traffic

• • • •

UTRAN DCH RAB drop rate - DCH traffic Cell_FACH RAB drop rate - Cell_FACH traffic UTRAN Cell_FACH RAB drop rate - Cell_FACH traffic VS.RAB.Drop.




Radio link failures analysis due to synchronization issues ................................................................................................................................................................................................................................... Introduction

Radio Link Failures (RLF) due to synchronization issues can take place in both the downlink and uplink direction. The physical layer in the Node B and UE checks the synchronization status of every radio frame.

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 3GPP 25.331. As a downlink RLF typically ends up causing an uplink RLF, it is assumed that the PM counters for the uplink RLF usually covers all RLF. RLF and radio link restore in the uplink

In the Cell_DCH state the RLF and Radio Link Restore procedures in the uplink are supervised in the Node B by the NBAP protocol. As each UE may have more than one uplink radio link allocated in a given Node B, this means a softer handover status. The Node B needs to monitor the complete radio link sets to trigger RLF and radio link restore procedures.


9-6



Abnormal uplink RAB disconnects

When loss of uplink synchronization of the air interface radio conditions occurs: •

• • •

The Node B sends an NBAP Radio Link Failure Indication with cause “synchronization failure” to the RNC upon detection of loss of uplink synchronization on the air interface The RNC then starts the timer: T_RL_RESYNC If the radio link recovers, an NBAP RL Restore message is sent and timer, T_RL_RESYNC is stopped. If the timer T_RL_RESYNC expires, the RNC removes the particular radio link in the Node B via the NBAP radio link deletion procedure incrementing the PM counter VS.RLM.DropRL.ULRLFLossSync. The following cases have to be distinguished: – The UE has more than one radio link, which will not lead to a dropped call – In case the dropped radio link is the last or only one the UE is connected to, the call is dropped and the RNC releases the Iu connection. The PM counter VS.RAB.DROP..Cause
RLF is incremented.

Radio link failures due to synchronization issues can be identified via PM counter VS.RLM.DropRL.ULRLFLossSync that is triggered after expiration of the guard timer T_RL_RESYNCH. In case of Radio link failures NOT due to synchronization issues, the PM counter VS.RLM.DropRL.ULRLFNoLossSync records the results. In case RLF for a UE with one radio link only occurs, the radio link loss results in a dropped call. The Iu connection is then abnormally released causing the RAB drop PMs to be incremented. The RLF specific counters triggered per service are: • • • • • • •

VS.RAB.Drop.CSV.CauseULRLF VS.RAB.Drop.CSD.CauseULRLF VS.RAB.Drop.PS.DCH.CauseULRLF VS.RAB.Drop.PS.HSDSCH.CauseULRLF VS.RAB.Drop.PS.HSDSCH.CauseULRLF.ReconfFail VS.RAB.Drop.CS.DL_RLF VS.RAB.Drop.PS.DL_RLF

Related PMs / KPIs


CS RAB Drop Rate due to DL RLF CS RAB Drop Rate due to UL RLF




•

PS RAB Drop Rate due to DL RLF

•

PS RAB Drop Rate due to UL RLF

•

Total PS Dropped RABs cause UL RLF


9-8


Dropped RAB analysis due to congestion ................................................................................................................................................................................................................................... Introduction

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

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

VS.RAB.Drop.CS.DLPwr VS.RF.TxCodePwr.Max VS.RF.TxCodePwr.Mean VS.RF.TxCodePwr.LEminus9 to VS.RF.TxCodePwr.LEplus46 VS.RF.TxPwr.HsPdschCodes.Max VS.RF.TxPwr.HsPdschCodes.Mean VS.RF.TxPwr.HsScchCodes.Max VS.RF.TxPwr.HsScchCodes.Mean VS.RF.TxPwr.AllCodes.Max VS.RF.TxPwrMean.AllCodes VS.RF.TxPwr.AllCodes.LE10 to VS.RF.TxPwr.AllCodes.LE100

RAB Drops due to Uplink Interference

Established RABs could be dropped when the uplink interference received by the NodeB is so high that the call cannot be maintained and is terminated. This could happen due to a large number of UEs handled by the NodeB or in nearby NodeBs causing high uplink interference. Geographical terrain and presence of water bodies could also increase uplink interference as the NodeB might have a Line of Sight ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 9-9 Issue 1, August 2007 See notice on first page



visibility to distant UEs. With proper design and parameter settings in the network, the uplink interference can be reduced, but if high uplink interference is seen, the RAB will be dropped with the RNC initiating an Iu Release procedure with cause “no resource available” and event “uplink interference” occurred in the RNC. The counters VS.RAB.Drop.CS.ULIntfer and VS.RAB.Drop.PS.ULIntfer will be pegged for CS or PS calls respectively. The following counters can be observed to further understand the interference conditions in the NodeB: • • • • • • • • • • •

VS.RF.RTWP.Max VS.RF.RTWP.Mean VS.RF.RTWP.LE110 to VS.RF.RTWP.GT90 VS.RF.SIR.Max VS.RF.SIR.Mean VS.RF.SIRerror.Max VS.RF.SIRerror.Mean VS.RF.SIR.LEminus11 to VS.RF.SIR.LEplus20 VS.RF.SIRerror.LEminus30 to VS.RF.SIRerror.LEplus31 VS.RF.TxPwrMean.AllCodes VS.RF.TxPwr.AllCodes.LE10 to VS.RF.TxPwr.AllCodes.LE100

RAB Drops due to UE inactivity

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

Active calls could be dropped when the operator issues a LOCK or RESET command to any of the following Managed Objects: • • • • • •

IuR IuPS IuCS IuB Lcell HSDPA


9-10


•

LRNC

•

LNodeB


This could happen due to parameter changes or when operations work is carried out on the network. This can be minimized by observing traffic patterns in the area of impact and scheduling operator intervention activities when the subscriber traffic is at its least. PS Data RAB Drop Rate due to UE Poor Quality and Minimum rate

When an active Packet call is in progress at the minimum rate with the UE reporting poor quality and power (5A/6A) and the parameter rABreleaseMinRateGbrRab is configured to “TRUE” , then the PS RAB maybe dropped. The percentage of such drops can be obtained by the KPI, PS Data RAB Drop Rate due to UE Poor Quality & Minimum Rate. It must be noted that these PS RAB drops will occur for QoS Class “streaming” only. This KPI can be studied in conjunction with KPIs, CS RAB Drop Rate due to DL Power, PS RAB Drop Rate due to DL Power, CS RAB Drop Rate due to UL Interference and PS RAB Drop Rate due to UL Interference and a comprehensive picture of the power and interference issues in the cell can be inferred and steps to improve power and decrease interference can be taken. RAB Drops due to Radio Link Control (RLC) errors

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

• • • • • •

VS.RAB.Drop.CS.ULRLCFail.DCCH VS.RAB.Drop.CS.DLRLCFail.DCCH VS.RAB.Drop.PS.ULRLCFail.DCCH VS.RAB.Drop.PS.ULRLCFail.DTCH VS.RAB.Drop.PS.DLRLCFail.DCCH VS.RAB.Drop.PS.DLRLCFail.DTCH

RAB Drops initiated by the Core Network

RAB drops can be initiated by the Packet or Circuit Core network due to several reasons such as authentication errors, unsupported Integrity protection algorithm, O&M intervention among others causes. Performance measurements for Circuit and Packet core network related drops are pegged as listed below. Further analysis can be done by isolating the Core network element that is common to the RNCs where these counts




are seen to be high. Corresponding Core Network initiated drop measurements from the 3G MSC and 3G SGSN will need to be analyzed for obtaining the root cause of the problem. Related PMs/KPIs

• • • • • •

VS.RAB.Drop.CN_Init.CS VS.RAB.Drop.CN_Init.PS.Cell_DCH.DCH_DCH VS.RAB.Drop.CN_Init.PS.Cell_DCH.DCH_HSDSCH VS.RAB.Drop.CN_Init.PS.Cell_DCH.EDCH_HSDSCH VS.RAB.Drop.CN_Init.PS.Cell_FACH VS.RAB.Drop.CN_Init.PS.URA_PCH

RAB Drops during reconfiguration

RAB drops occur when the radio bearers are reconfigured from DCH to HSDSCH or vice versa. This can occur due to poor coverage or interference issues leading to timer DchHsDSCH expiry while waiting for a Radio Bearer reconfiguration complete message from the UE. The RAB is also dropped when a Radio Bearer reconfiguration failure message is sent by the UE. Related PMs/KPIs

• •

VS.RAB.Drop.Reconf.DCH_HSDSCH VS.RAB.Drop.Reconf.HSDSCH_DCH


9-12

10

10 quality optimization and Call troubleshooting


This chapter describes the performance indicators that can be used to retrieve information about the call quality. Quality is defined as the quality of the connection as perceived by the subscriber. The intention of the metrics are to measure, as closely as possible, the customers’ perception of the network performance in terms of service quality. Contents Quality KPIs

10-2


Call quality optimization and troubleshooting

Quality KPIs ................................................................................................................................................................................................................................... Introduction

Although a call is successfully set up and maintained the user may perceive that the quality of the call itself is poor. In case of a voice call this quality degradation can be directly experienced during the conversation. In case of a data call the poor quality may cause throughput degradation. There are several aspects that determine the call quality, such as delay, jitter and BLER, where, in this release, measurements are available for the UL Block Error Rate. Quality KPI

UL Block Error Rate (BLER) is the KPI providing an indication of the quality of the UMTS call. The quality KPIs capture the uplink failure on RNC basis: (A / B) × 100 Where: A = The number of errored Transport Blocks per service type B = The total number of Transport Blocks per service type The quality KPIs on Uplink Block Error Rate can be calculated for services CSD, CSV 4.75, PS. Poor quality reasons

High values of the quality KPIs indicate that the perceived uplink quality of the call is poor. Usually this also has an impact on the UL/DL throughput related KPIs. In order to correctly identify the root cause of high UL/DL BLER values, the UE and the Node B transmitted power should be checked respectively: •

•

If the UE and/or the Node B transmitted power has reached the maximum allowed value, then the most likely root cause is given by poor RF conditions that are limiting either the downlink or the uplink, or both. If the UE and/or the Node B transmitted power has not reached the maximum allowed value, then the most likely root cause is given by respectively UL and/or DL closed loop power control issues.

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


10-2


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. Other abnormal values

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

• • • • • • • •

VS.RF.RTWP.xx VS.RF.TxCodePwr.xx VS.RF.SIRerror.xx VS.FwdPowerOvldDuration CS Data UL Transport Block Error Rate CS Voice UL Transport Block Error Rate CSV 4.75 UL Transport BLER CSV 5.9 UL Transport BLER



•

CSV 7.95 UL Transport BLER

•

CSV 12.2 UL Transport BLER

• • • • • • • • • • • •

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

Quality KPIs

RAB Modification failures affecting subscriber

The poor quality of the subscriber experience can also be studied by analyzing RAB modification attempts and failures due to various causes such as BLER, congestion, UE Transmit power etc. RAB modifications could be SGSN initiated or RNC initiated. By observing the number of RAB modifications and their reasons in a particular cell/area/RNC, the quality issues that may be faced by the subscriber can be assessed. Related PMs / KPIs

• • • • • • • • • • • •

RAB.AttModPS.Strm RAB.FailModPSNoQueuing.Strm RAB.FailModPSNoQueuing.Incr RAB.FailModPSNoQueuing.IncompReq RAB.FailModPSNoQueuing.ProcFail VS.RAB.AttModPSRNCini.BLER.Strm VS.RAB.AttModPSRNCini.UEtxPwr.Strm VS.RAB.AttModPSRNCini.ULConC.Strm VS.RAB.AttModPSRNCini.DLConC.Strm VS.DataRateFail.Dec.RABMod VS.DataRateFail.Timeout VS.DataRateFail.FailMsg


10-4

11

11 mobility optimization and Call troubleshooting


This chapter describes the UTRAN measurements and performance indicators that can be used to localize problems and to optimize issues related to call mobility. Contents Soft/Softer handover and troubleshooting

11-3

Soft/softer handover procedure

11-4

Average active set size

11-7


11-9


11-12


11-13

No UE answer

11-14

UE reject

11-15

Unlisted set cells

11-16

CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting

11-18


11-19


11-23


11-25

CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting

11-26

CS Voice GSM to UMTS (inter-RAT) handover procedure

11-27

Relocation resource allocation procedure troubleshooting

11-30

Handover procedure troubleshooting

11-32


Call mobility optimization and troubleshooting

Overview

PS UMTS to GSM (inter-RAT) Cell Change Order and troubleshooting

11-33


11-34

PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting

11-37

Serving HS-DSCH Cell Change

11-39


11-40


11-43

Inter-frequency hard handover and troubleshooting

11-44


11-45


11-50


11-53


11-54

UE reject

11-55

Inter-system directed retry

11-56


11-57

Inter-system directed retry troubleshooting

11-60


11-2


Soft/Softer handover and troubleshooting Overview ................................................................................................................................................................................................................................... Purpose

This section provides soft/softer handover optimization and troubleshooting information. Contents Soft/softer handover procedure

11-4


11-7


11-9


11-12


11-13

No UE answer

11-14

UE reject

11-15

Unlisted set cells

11-16



Soft/softer handover procedure ................................................................................................................................................................................................................................... Introduction

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

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

Node B - 1

Node B - 2

SRNC

RRC Measurement Report (Event 1A)

RRC

(DCCH over DCH) NBAP

NBAP

RRC

RL Setup Request

RL Setup Response

Active Set Update

1

NBAP

2 PM-A PM-B

NBAP

RRC

(Radio Link addition)

RRC

Active Set Update Complete

NBAP

RL Deletion Request

PM-C

3 PM-D RRC

NBAP

4 RL Deletion Response NBAP

RRC

RCC Measurement Control (DCCH over DCH)

NBAP

RRC

5

PM-A = RLM.AttRLSetupIub RLM.AttRLSetupIub.CSV RLM.AttRLSetupIub.CSD RLM.AttRLSetupIub.PSD

PM-C = SHO.AttRLAddUESide

PM-B = RLM.SuccRLSetupIub RLM.FailRLSetupIub.NodeBRes.CSV RLM.FailRLSetupIub.NodeBRes.CSD RLM.FailRLSetupIub.NodeBRes.PSD RLM.FailRLSetupIub.TransRes.CSV RLM.FailRLSetupIub.TransRes.CSD RLM.FailRLSetupIub.TransRes.PSD

PM-D = SHO.SuccRLAddUESide SHO.FailRLAddUESide.InvalidConfig SHO.FailRLAddUESide.IncompSimultReconf SHO.FailRLAddUESide.ProtErr SHO.FailRLAddUESide.ConfigUnsupport SHO.FailRLAddUESide.NoReply


11-4



Soft/softer handover procedure steps

The soft/softer handover procedure steps for UE in Cell_DCH state are: 1. Reporting of soft/softer handover triggering event to the UTRAN via an RRC measurement report message 2. Set up resources in the UTRAN via NBAP procedure (in case of addition or replacement) 3. Soft/softer handover execution via RRC active set update procedure. Soft/softer handover procedure is successfully executed on receipt of an RRC active set update complete message at the RNC 4. Clear resources in the UTRAN via NBAP procedure (case of removal or replacement) 5. Monitored Set update upon Neighbor List Selection Algorithm (NLSA) evaluation via an RRC measurement control message. Handover scenarios

Soft/softer handovers can be executed as Intra-RNC as well as Inter-RNC. In case of Inter-RNC soft/softer handover, the RNCs involved are defined as Serving RNC (SRNC) and one or several Drift RNCs (DRNC). Soft handover event 1A

In case of soft handover with event 1A triggered, other procedures via ALCAP and DCH Framing Protocols are executed on the Iub interface in between Radio Link Set-up (step 2) and Active Set Update (step 3) procedures. Softer handover

In case of softer handover, the NBAP Radio Link Addition is executed within the same Node B instead of NBAP Radio Link Setup. Inter-RNC soft handover

In case of Inter-RNC soft handover the procedure is executed in the same way as where SRNC is executing Active Set Update procedure (step 3) while DRNC is taking care of the NBAP procedures (steps 2 and 4) initiated by the SRNC through the Iur interface via corresponding Radio Network Subsystem Application Part (RNSAP) procedures. This means that, for example, in case of event 1A triggered in one Node B belonging to the DRNC then the SRNC initiates the setup of the resources at the DRNC via the RNSAP Radio Link Setup procedure. Afterwards the DRNC allocates the required resources at the relevant Node B via the NBAP Radio Link Setup procedure. This example is valid when no soft handover context exists at the Node B, otherwise RNSAP and NBAP Radio Link Addition procedures are executed instead. .................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 11-5 Issue 1, August 2007 See notice on first page



Soft/softer handover procedure is successfully executed on receipt of RRC Active Set Update Complete message at the RNC.


11-6


Average active set size ................................................................................................................................................................................................................................... Description

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

The Active Set Size Distribution KPI provides the RL active set size distribution in percent. The active set size per UE is in the range one to six. Per active set size (1 to 6), the percentage how often the relevant active set size is used will be provided on a per cell basis. KPI formula

Percentage Active Set Size 1 = 100 × (VS.RLSetAct.Size1 / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)) Percentage Active Set Size 2 = 100 × (VS.RLSetAct.Size2 / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)) Percentage Active Set Size 3 = 100 × (VS.RLSetAct.Size3 / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)) Percentage Active Set Size 4 = 100 × (VS.RLSetAct.Size4 / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)) Percentage Active Set Size 5 = 100 × (VS.RLSetAct.Size5 / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)) Percentage Active Set Size 6 = 100 × (VS.RLSetAct.Size6 / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)) Average Active Set Size

The KPI Average Active Set Size provides the “overhead” due to SHO radio links, that is the number of radio links established per active UE. It is derived from the sum of all RLs active in the cell divided by the sum of active sets on a per cell basis.




KPI formula

Average Active Set Size = ((VS.RLSetAct.Size1 × 1) + (VS.RLSetAct.Size2 × 2) + (VS.RLSetAct.Size3 × 3) + (VS.RLSetAct.Size4 × 4) + (VS.RLSetAct.Size5 × 5) + (VS.RLSetAct.Size6 × 6)) / (VS.RLSetAct.Size1 + VS.RLSetAct.Size2 + VS.RLSetAct.Size3 + VS.RLSetAct.Size4 + VS.RLSetAct.Size5 + VS.RLSetAct.Size6)


11-8


Soft handover troubleshooting ................................................................................................................................................................................................................................... Introduction

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

The major components that constitute failures of both Intra-RNC and Inter-RNC Soft handover are: • • • • • • • • •

Poor RF conditions Incorrect translations settings No Node B resources available No transport resources available No UE answer UE Reject Node B / RNC outages Iub, Iur link outages Iur configuration to drift RNC.

Intra- / Inter-SHO PMs / KPIs

Regarding any SHO PM counters, Intra-RNC SHO is defined as SHO within cells of the SRNC. These PMs are all provided on a per target cell basis. The identical set of PM counters exist for the so-called Inter-RNC SHO, where SHO is performed for cells on the DRNC. These PMs are provided on a per target DRNC basis. Counter in the context of SHO are based on the “Active Set Update” message being sent to the UE. The PM counters are split up per RL type: • • • • •

Signaling PS CS Voice CS Data PS and CS combinations

In addition there are separate counters for: • • •

Add / replace RLs from active set Delete RL from active set Per failure cause on RL addition / replacement




Related PMs / KPIs

The related PMs / KPIs are: • • • • • • • • • •

SHO.AttRLAddUESide SHO.SuccRLAddUESide SHO.FailRLAddUESide.InvalidConfig SHO.FailRLAddUESide.IncompSimultReconf SHO.FailRLAddUESide.ProtErr SHO.FailRLAddUESide.ConfigUnsupport SHO.FailRLAddUESide.NoReply SHO.AttRLDelUESide SHO.SuccRLDelUESide SHO.AttRLAddUESide.IntraRNC.CSV

• • • • • • • • • • • • • • • • • •

SHO.AttRLAddUESide.IntraRNC.PSLowData SHO.AttRLAddUESide.IntraRNC.PSHighData SHO.AttRLAddUESide.IntraRNC.Signalling SHO.AttRLAddUESide.IntraRNC.CSD SHO.AttRLAddUESide.IntraRNC.CSDandPS SHO.AttRLAddUESide.IntraRNC.CSVandPS SHO.FailRLAddUESide.IntraRNC.CSV SHO.FailRLAddUESide.IntraRNC.PSLowData SHO.FailRLAddUESide.IntraRNC.PSHighData SHO.FailRLAddUESide.IntraRNC.Signalling SHO.FailRLAddUESide.IntraRNC.CSD SHO.FailRLAddUESide.IntraRNC.CSDandPS SHO.FailRLAddUESide.IntraRNC.CSVandPS SHO.AttRLAddUESide.InterRNC.CSV SHO.AttRLAddUESide.InterRNC.PSLowData SHO.AttRLAddUESide.InterRNC.PSHighData SHO.AttRLAddUESide.InterRNC.Signalling SHO.AttRLAddUESide.InterRNC.CSD

• • • • •

SHO.AttRLAddUESide.InterRNC.CSDandPS SHO.AttRLAddUESide.InterRNC.CSVandPS SHO.FailRLAddUESide.InterRNC.CSV SHO.FailRLAddUESide.InterRNC.PSLowData SHO.FailRLAddUESide.InterRNC.PSHighData


11-10


•

SHO.FailRLAddUESide.InterRNC.Signalling

•

SHO.FailRLAddUESide.InterRNC.CSD

• •

SHO.FailRLAddUESide.InterRNC.CSDandPS SHO.FailRLAddUESide.InterRNC.CSVandPS




No Node B resources available ................................................................................................................................................................................................................................... Introduction

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

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


RLM.FailRLSetupIub.NodeBRes. VS.RLM.MeanActiveRL VS.RLM.MaxActiveRL Successful Active Set Update Addition Rate


11-12


No transport resources available ................................................................................................................................................................................................................................... Introduction

The NBAP radio link setup procedure may fail due to no transport resources available, this means no Iub links are available due to maximum supported capacity reached. This failure causes degradation of Soft/softer Handover Success Rate KPIs. The UTRAN PM counter RLM.FailRLSetupIub.TransRes. identifies these failure causes either on a per cell basis or on a per RNC basis in case the failure occurs in the SRNC or in the DRNC respectively. Abnormal SHO.FailRLSetupIubUTRANSide.TransRes values

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


RLM.FailRLSetupIub.TransRes.



No UE answer ................................................................................................................................................................................................................................... Introduction

Upon successful resource allocation in the NodeB the RNC executes the soft/softer handover via the RRC active set update procedure by sending to the UE the RRC active set update message (see “Soft/softer handover signaling flow” (p. 11-4)). If the guard timer expires and no message is received from the UE then the active set update procedure fails and all the allocated UTRAN resources are released. The normal reason for this failure scenario is given by poor RF conditions either due to poor coverage or high interference. This failure causes degradation of Soft/softer Handover Success Rate KPIs. The UTRAN PM counter SHO.FailRLAddUESide.NoReply is triggered when the guard timer expires. Abnormal soft/softer handover success rate KPI values

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


SHO.FailRLAddUESide.NoReply


11-14


UE reject ................................................................................................................................................................................................................................... Introduction

Upon sending the Active Set Update message, in the case of failure the RNC receives the Active Set Update Failure message from the UE. UE reject

The UE reject failure causes are: •

• •

Invalid configuration: – scrambling codes inconsistencies – same radio links to be added and deleted – radio link deletion required for the only link/links currently in the Active Set Incompatible simultaneous re-configuration Protocol Error.

The failure causes result in degradation of Soft/softer handover success rate KPIs. The following UTRAN PM counters are triggered on receiving the Active Set Update Failure message depending on the failure cause included at the UTRAN: • • • •

SHO.FailRLAddUESide.InvalidConfig (in case of invalid configuration) SHO.FailRLAddUESide.IncompSimultReconf (in case of incompatible simultaneous re-configuration) SHO.FailRLAddUESide.ProtErr (in case of protocol error) SHO.FailRLAddUESide.ConfigUnsupport (in case of configuration unsupported)

Related PMs / KPIs


SHO.FailRLAddUESide.InvalidConfig SHO.FailRLAddUESide.IncompSimultReconf SHO.FailRLAddUESide.ProtErr SHO.FailRLAddUESide.ConfigUnsupport



Unlisted set cells ................................................................................................................................................................................................................................... Introduction

For the intra-frequency (soft / softer) handover procedure, the RNC sends a list of cells to the UE. This list is called Cell_Info_List and it contains all cells that the UE will measure for intra-frequency mobility purposes. It contains all active set cells and also the monitored set cells (i.e. the so called neighbor cells). In addition to the active set and the monitored set there is a third set of cells called the “unlisted” or “detected” set. For a UE, all cells of the network not belonging to the active or monitored set, belong to the unlisted set. detectedSetCellReporting

For the purpose of intra-frequency measurements the 3GPP standard allows to which cells the UE will measure to be specified, i.e. it is possible to specify if the UE will or will not search for unlisted set cells. In the Alcatel-Lucent UTRAN the operator has the possibility to switch ON or OFF measurements and reporting of unlisted set cells by means of the parameter detectedSetCellReporting (parameter can be set to True or False). If the UE also searches for unlisted set cells, this will somehow slow down the measurement process for the cells in the Cell_Info_List, but on the other hand such measurements are very useful for network optimization. By means of these measurements the operator is able to recognize if some cells are missing in the neighbor list, i.e. the operator is able to optimize the neighbor cell relationship by adding missing neighbor cells to the monitored set. Neighboring cells

Each UMTS cell has its specific list of neighboring cells, which is used to derive the monitored set and the Cell_Info_List. For a UE in soft handover, there are now two or more active set cells, which each have their individual neighbor lists. In this case the Alcatel-Lucent UTRAN generates a Cell_Info_List with all relevant monitored set cells by invoking the Neighbor List Selection Algorithm (NLSA). The NLSA makes use of several criteria, including the priority given to each cell in the neighbor lists, i.e. the higher the priority given to a specific cell in the neighbor list, the higher the probability that this cell is included in the Cell_Info_List. In case some relevant cell is missing in the Cell_Info_List, the operator may consider to increase the priority given to that particular neighbor cell. If the cell is not included in the neighbor list at all it should be added. Handling of measurement reports in soft handover

In the case where reporting of unlisted set cells has been enabled, the UE will also continuously search for cells not included in the Cell_Info_List. It will send a measurement report to the RNC as soon as the reporting criteria for the unlisted set ................................................................................................................................................................................................................................... Alcatel-Lucent - Proprietary 401-382-810R04.03 See notice on first page Issue 1, August 2007

11-16


Unlisted set cells

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

The related PMs / KPIs are: Number of Unlisted Neighbour Cells per Current Best Cell Per unlisted neighbour cell the following measurement types is added: • •

NumUnlistHORejPerNcell.PrimScrCode Identification of unlisted neighbour cell using the primary scrambling code NumUnlistHORejPerNcell.RejHO Number of rejected HO for the previously specified unlisted neighbour cell



CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting Overview ................................................................................................................................................................................................................................... Purpose

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

11-19


11-23


11-25


11-18


CS Voice UMTS to GSM (inter-RAT) handover procedure ................................................................................................................................................................................................................................... Introduction

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

CS Voice UMTS to GSM (inter-RAT) handover is always a hard handover with 3G-MSC involvement. The UE must have established at least a circuit-switched (CS) connection to the UMTS network. CS Voice UMTS to GSM Handover can be performed for the following RAB combinations: • •

One CS voice connection, or One CS voice connection and simultaneous PS connection(s)

For a UE, which is involved simultaneously in a CS connection and a PS connection, the CS connection will be transferred to the target GSM cell first. When the CS handover is completed, the UE has to send a routing area update request message to the GSM network containing an indication that the GSM/GPRS network needs to continue an already established UTRAN CN context. Whether the UE is able to continue both the CS and PS connections in GSM/GPRS depends on its capabilities. CS Voice UMTS to GSM handover procedure

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

CS Voice UMTS to GSM handover call signaling flow:




Radio Access Network UE

Node B

BTS

Core Network

SRNC

Inter-RAT HO triggered within the SRNC

BSC

3G-MSC

2G-MSC

Relocation Required Map-prepHandover req. Handover request

Channel activation procedure (with HO Reference No.) Channel activation Ack. HO Rrequest Ack. (with HO Command)

1

Map-prepHandover resp.

T_interRatGuard

IAM ACM Relocation Command (including GSM HO Command) Handover from UTRAN Command (including GSM HO Command) HO Access (with HO Reference No.) Handover Detect Handover Detect Physical Information

2 Map-ProcessAccess-Sig req.

SABM Establish Indication UA Handover Complete

Handover Complete Map-SendAccess-Sig req. IU Release Command Answer Radio Link Deletion Request

3 Radio Link Deletion Response IU Release Complete


11-20



Success rate KPIs

The following KPIs provide an indication of the success rate for CS Voice UMTS to GSM handover: •

•

•

•

Relocation Preparation for CS UMTS to GSM HHO Success Rate This KPI indicates the relocation preparation performance for UMTS to GSM HHO for CS calls. CS IRAT HO Success Rate (UMTS -> GSM) This KPI indicates the overall hard handover inter RAT performance towards GSM network for CS calls starting from the relocation attempt. CS UMTS to GSM HHO Inter RAT Success Rate This KPI indicates the hard handover inter RAT performance towards GSM network for CS calls based on Ec/No and RSCP measurements. CS UMTS to GSM HHO Inter RAT Success Rate - RSCP only This KPI indicates the hard handover inter RAT performance towards GSM network for CS calls based on RSCP measurement only.

Matrix KPIs

For UMTS to GSM optimization, but also for specific troubleshooting, there are special handover Matrix PM counters available. Different to other PMs, these Matrix PM counters are provided on a per originating UMTS cell to relevant terminating GSM target cell basis. The UMTS to- GSM Handover Matrix PMs > CS UMTS to GSM Handover Success Rate per GSM Neighbour Cell help to locate problems between UMTS and GSM cells by providing the number of handover attempts and failures from the UMTS originating cell to relevant GSM target cells. The counter is only available for those GSM cells that are a target for handover in the reporting period and are reported on a daily basis. UMTS to GSM handover failures

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


CS UMTS to GSM Handover Success Rate per GSM Neighbour Cell - Att CS UMTS to GSM Handover Success Rate per GSM Neighbour Cell - Fail Relocation Preparation for CS UMTS to GSM HHO Success Rate Relocation Preparation UMTS to GSM Failure Rate -




•

CS IRAT HO Success Rate (UMTS -> GSM)

•

CS UMTS to GSM HHO Inter RAT Success Rate

• • •

CS UMTS to GSM HHO Failure Rate - Likely Dropped Call Rate in Target System due to CS UMTS to GSM HHO CS UMTS to GSM HHO Inter RAT Success Rate - RSCP only


11-22


CS Voice relocation preparation procedure troubleshooting ................................................................................................................................................................................................................................... Introduction

Relocation preparation failures occur during the RANAP relocation preparation procedure, for example GSM handover resource allocation fails or the core network rejects the UMTS to GSM handover request. Failure causes

A failure occurs due to the following causes: • •

Timer T_RELOCprep expiry at the SRNC Relocation preparation failure.

Timer T_RELOCprep expiry at the SRNC

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

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

IRATHO.FailRelocPrepOutCS.RelocCanc IRATHO.FailRelocPrepOutCS.ReqCiphNotSupp IRATHO.FailRelocPrepOutCS.FailTarSys IRATHO.FailRelocPrepOutCS.NotSupTarSys IRATHO.FailRelocPrepOutCS.TarNotAllowed IRATHO.FailRelocPrepOutCS.NoRRTarCell IRATHO.FailRelocPrepOutCS.TrLdHighTarCell




•

IRATHO.FailRelocPrepOutCS.AbstSyntErr

•

IRATHO.FailRelocPrepOutCS.OmInt

• • •

IRATHO.FailRelocPrepOutCS.NoResAv IRATHO.FailRelocPrepOutCS.UnspecFail IRATHO.FailRelocPrepOutCS.T_RELOCprep_exp


11-24


CS Voice IRAT handover procedure troubleshooting ................................................................................................................................................................................................................................... Introduction

Upon successful completion of relocation preparation procedure, the SRNC sends the handover from UTRAN command including the GSM handover command to the UE. If the UE fails to complete the requested handover then the SRNC receives a handover from UTRAN command failure message from the UE. Failure causes

The failure causes specified within the message are as follows: • • •

Physical channel failure Unacceptable configuration Protocol error.

Physical channel failure

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

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

The related PMs / KPIs are: • • •

IRATHO.FailOutCS.PhyChnFail IRATHO.FailOutCS.ConfUnaccept IRATHO.FailOutCS.ProtErr



CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting Overview ................................................................................................................................................................................................................................... Purpose

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

11-27


11-30

Handover procedure troubleshooting

11-32


11-26


CS Voice GSM to UMTS (inter-RAT) handover procedure ................................................................................................................................................................................................................................... Introduction

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

CS Voice GSM to UMTS handover can be performed for the following RAB combinations: • •

CS signaling only, or One CS voice RAB + CS signaling


In general CS Voice GSM to UMTS handover can be separated into the following steps: 1. Handover relocation preparation within the GSM RAN/CN and UMTS RAN/CN 2. Handover execution involving also the UE 3. Release of GSM resources




CS Voice GSM to UMTS handover signaling flows Radio Access Network UE

Node B

BTS

Core Network

SRNC

BSC

3G-MSC

2G-MSC

Handover Required Map-prepHandover req. Relocation Request ALCAP Iu Transport Bearer Setup Radio Link Setup Request Radio Link Setup Response

1 ALCAP Iu Transport Bearer Setup + Frame Protocol Sync. Relocation Request Ack. (Including HO to UTRAN Command) Map-prepHandover resp. IAM ACM

Handover Command (including HO to UTRAN Command)

Handover Command (including HO to UTRAN Command)

In Sync. Detection Radio Link Restore Indication Relocation Detect

Map-ProcessAccess-Sig req.

2

Handover to UTRAN Complete Relocation Complete Map-SendAccess-Sig req. Answer Clear Command Radio Link Release Clear Complete

3


11-28



Success rate KPIs

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

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


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



Relocation resource allocation procedure troubleshooting ................................................................................................................................................................................................................................... Introduction

Relocation failures occur during the RANAP relocation resource allocation procedure, for example the GSM to UMTS handover is disabled in the target cell, or the resource allocation fails in the target cell. Failure causes


GSM to UMTS handover is not enabled in the target cell The resource allocation fails due to any other reason.

GSM to UMTS handover is not enabled in the target cell

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

If the handover resource allocation procedure fails due to any other reason then only the PM counter IRATHO.FailIncCS.sum is incremented. This can happen in case of following failures: • • • • • • •

The target cell id is not controlled by the RNC The RNC fails to decode the “RRC container” within the Relocation Request message The UE does not support the target cell frequency band The ciphering or integrity protection cannot be configured because the UE Security Capability is not present in the Relocation Request message No S-RNTI 2 can be allocated No reduced range uplink scrambling code can be allocated The requested radio resources cannot be established, for example, radio link setup fails on Iub or the ALCAP Iu transport bearer cannot be established.


11-30



Related PMs/KPIs


IRATHO.FailIncCS.sum IRATHO.FailIncCS.HoNotEnabled



Handover procedure troubleshooting ................................................................................................................................................................................................................................... Introduction

Relocation failures occur during the handover procedure, when the UE does not access the target cell or the MSC cancels the relocation before the UE has accessed the target cell. Failure causes


Timer expiry Relocation cancel.

Timer expiry

After the relocation resource allocation procedure the UTRAN waits for the UE to access the target cell and to send the RRC message HANDOVER TO UTRAN COMPLETE. If this message is not received the PM counters IRATHO.FailIncCS.sum and IRATHO.FailIncCS.T_hoToUtranComplete are incremented. Probable causes for this failure are: •

•

The UE has moved out of GSM coverage and the call has dropped before the handover command was sent to the UE by the GSM network. If this occurs, then the handover should be initiated earlier in GSM The UE cannot access the UMTS cell due to insufficient radio conditions. In case of measurement based handover the threshold values for the UMTS system should be increased to ensure that the UMTS quality is sufficient before a handover is initiated. In case of blind handover the network configuration should be checked if the UMTS cell is a acceptable target for the complete coverage area of the GSM source cell.

Relocation cancel

The GSM network has cancelled the relocation due to any reason that is outside of the scope of UTRAN. Related PMs/KPIs

The related PMs / KPIs are: • • •

IRATHO.FailIncCS.sum IRATHO.FailIncCS.T_hoToUtranComplete IRATHO.FailIncCS.RelocCancel


11-32


PS UMTS to GSM (inter-RAT) Cell Change Order and troubleshooting Overview ................................................................................................................................................................................................................................... Purpose

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

11-34


11-37



PS UMTS to GSM (inter-RAT) Cell Change Order procedure ................................................................................................................................................................................................................................... Introduction

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

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


11-34



PS UMTS to GSM Cell Change Order signaling flow Serving RNC

UE

SGSN

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

2. Cell Change Order from UTRAN RRC

RRC

3. The UE accesses the GSM system and initiates routing area update. The packet context is transferred to the new SGSN

4. SRNS Context Request RANAP

RANAP

5. SRNS Context Response RANAP

RANAP

RANAP

RANAP

6. Iu Release Command RANAP

7. Iu Release Complete RANAP

Success rate KPIs

The following KPIs provide an indication of the success rate for UMTS to GSM handover: •

•

PS IRAT HO Success Rate (UMTS -> GSM) This KPI measures the percentage of Cell Change Order from UTRAN procedures successfully completed. PS UMTS to GSM HHO Inter RAT Success Rate - RSCP only This KPI indicates the percentage of Cell Change Order from UTRAN procedures successfully completed based on RSCP measurement only.




Matrix KPIs

For UMTS to GSM optimization, but also for specific troubleshooting, there are special handover Matrix PM counters available. Different to other PMs, these Matrix PM counters are provided on a per originating UMTS cell to relevant terminating GSM target cell basis. The UMTS to GSM Handover Matrix PMs VS.MX.IRATHO.OutPSUTRAN. PS Hard Handover Inter RAT Success Rate per GSM Neighbour Cell help to locate problems between UMTS and GSM cells by providing the number of handover attempts and failures from the UMTS originating cell to relevant GSM target cells. The counter is only available for those GSM cells that are a target for handover in the reporting period and are reported on a daily basis. UMTS to GSM Cell Change Order failures

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


• • •

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


11-36


PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting ................................................................................................................................................................................................................................... Introduction

Cell Change Order from UTRAN failures occur when the Cell Change Order from UTRAN command was sent to the UE and the UE either returns with a failure message to UMTS or the procedures times out. Failure causes


Expiry of the cell change order procedure supervision timer Cell Change Order from UTRAN Failure.

Expiry of the Cell Change Order procedure supervision timer

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




The most likely failure cause is that there are network configuration issues in the core network between GSM and 3G SGSN. Typical causes are: • • •

the trunks between the SGSNs are not configured correctly the 2G SGSN does not know which 3G SGSN to contact, or security procedure issues within the GSM system

Cell Change Order from UTRAN Failure

On receipt of a Cell Change from UTRAN Failure message from the UE, the RNC maintains the call in UMTS. The next Cell Change Order is attempted after cellChangeOrderFromUTRANRepetitionTime if the conditions for a Cell Change to GSM are still fulfilled. Failure causes

The failure causes that are pegged separately are as follows: • • •

Physical channel failure Unacceptable configuration Protocol error.

The counter IRATHO.FailOutPSUTRAN.sum includes all the failure causes occurred along the receipt of Cell Change Order from UTRAN Failure message from the UE. Physical channel failure

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

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


IRATHO.FailOutPSUTRAN.sum IRATHO.FailOutPSUTRAN.ConfUnaccept IRATHO.FailOutPSUTRAN.PhyChnFail IRATHO.FailOutPSUTRAN.ProtErr VS.IRATHO.TimeoutOutPSUTRAN


11-38


Serving HS-DSCH Cell Change Overview ................................................................................................................................................................................................................................... Purpose

This section provides Serving HS-DSCH Cell Change procedure and troubleshooting information. Contents Serving HS-DSCH Cell Change procedure

11-40


11-43



Serving HS-DSCH Cell Change procedure ................................................................................................................................................................................................................................... Introduction

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

In case of Serving HS-DSCH Cell Change UTRAN and UE switch synchronously the HS-DSCH channel from the old best cell to the new best cell while keeping the active set unchanged. The procedure is triggered by the receipt of a event 1d or receipt of event 1b or 1c where the serving HS-DSCH link is to be removed from the active set. Upon a Serving HS-DSCH Cell Change failure the call is reconfigured to DCH (R99), if possible, to further maintain the call in UMTS.


11-40



Serving HS-DSCH Cell Change signaling flows (example for inter-NodeB serving cell change) Target HS-DSCH cell

UE

S-RNC = C-RNC

Source HS-DSCH cell

Serving HS-DSCH cell change decision

For example, Event 1D

RL Reconfig Prepare

RL Reconfig Prepare

RL Reconfig Ready RL Reconfig Ready

ALCAP Iub HS-DSCH Data Transport Bearer Setup

Transport Channel Reconfiguration

New NodeB

Synchronous Reconfigure RL Reconfig Commit

RL Reconfig Commit

Transport Channel Reconfiguration

Reset MAC-hs entity

DATA

ALCAP Iub HS-DSCH Data Transfer Bearer Release

Success rate KPIs

Following KPI provides an indication of the success rate for Serving HS-DSCH Cell Change: •

HS-DSCH Cell Change Success Rate This KPI measures the percentage of Serving HS-DSCH Cell Change procedures successfully completed.




Serving HS-DSCH Cell Change failures

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


HS-DSCH Cell Change Success Rate


11-42


Serving HS-DSCH Cell Change troubleshooting ................................................................................................................................................................................................................................... Introduction

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


Expiry of the Serving HS-DSCH Cell Change supervision timer RRC Reconfiguration Failure

Expiry of the Serving HS-DSCH Cell Change supervision timer

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

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


VS.AttServCellChangeHSDSCH VS.FailServCellChangeHSDSCH.sum VS.FailServCellChangeHSDSCH.TransChnReconfigFail VS.FailServCellChangeHSDSCH.TransChnReconfigTout Successful Serving HS-DSCH Cell Changes



Inter-frequency hard handover and troubleshooting Overview ................................................................................................................................................................................................................................... Purpose

This section provides Inter-frequency hard handover and hard handover troubleshooting information. Contents Inter-frequency hard handover procedure

11-45


11-50


11-53


11-54

UE reject

11-55


11-44


Inter-frequency hard handover procedure ................................................................................................................................................................................................................................... Introduction

Inter-frequency hard handover (HHO) is particularly needed to change frequencies within a UMTS network. Generally, changing of frequencies cannot be done seamlessly due to limitations in the mobile and in the radio access network. Thus a break in the bearer occurs whenever an inter-frequency HHO is performed. In the current release Inter-frequency HHO is triggered due to quality and due to load. If the signal quality in inter-frequency HHO border cells becomes too low, quality based inter-frequency HHO may be used to transfer the call to another UMTS frequency providing better quality. If the load in an UMTS cell becomes too high, load based inter-frequency HHO may be used to transfer the call to another UMTS cell on another frequency with less load. The handover algorithms are: • •

mobile assisted handover (MAHO), i.e. based on measurements and data base assisted handover, and data base assisted handover (DAHO), i.e. based on configuration data

They are used for quality and load based inter-frequency HHO. If both, MAHO and DAHO are applicable, preference is given to MAHO. Inter-frequency HHO is performed for circuit switched calls, packet switched calls as well as for the combination of both. Inter-frequency HHO measurements

One or more of the inter-frequency measurement events 2B, 2C, 2D and 2F are setup in the UE dependent on the used inter-frequency HHO algorithm. Quality based inter-frequency HHO (MAHO) w/o compressed mode

1. Measurement 2B is setup in the UE. On receipt of measurement 2B from the UE, inter-frequency HHO procedure is triggered. Quality based inter-frequency HHO (MAHO) w/ compressed mode

1. Measurement 2D is setup in the UE to determine the signal quality 2. On receipt of measurement 2D, if the signal quality is weak, measurement 2D is stopped and measurement 2B and 2F are setup 3. On receipt of measurement 2F, if the signal quality is strong again, measurement 2B and 2F are stopped and measurement 2D is setup again 4. On receipt of measurement 2B from the UE, inter-frequency HHO procedure is triggered.




Quality based inter-frequency HHO (DAHO)

1. Measurement 2D is setup in the UE. On receipt of measurement 2D from the UE, inter-frequency HHO procedure is triggered. Load based inter-frequency HHO (MAHO)

1. Measurement 2C is setup in the UE. On receipt of measurement 2C from the UE, inter-frequency HHO procedure is triggered. Load based inter-frequency HHO (DAHO)

1. No Measurements are setup in the UE. If the load in the cell on current used frequency is too high, inter-frequency HHO procedure is triggered Inter-frequency hard handover signaling flow UE

old Node B

new Node B

SRNC

Measurement Report Event 2B

1 1. Radio Link Setup Request


2

3. ALCAP Iub Transport Bearer Setup 4. Physical Channel Reconfiguration

5. UE Detected

3

6. Physical Channel Reconfiguration Complete

7. Radio Link Deletion Request

8. Radio Link Deletion Response

4

9. ALCAP Iub Transport Bearer Release

The hard handover procedure steps for UE in Cell_DCH state are: 1. Initiate hard handover when any trigger condition described above applies 2. Set up resources on the new frequency in the UTRAN via NBAP procedure


11-46



3. Execute hard handover towards UE: •

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

In the current release, Inter-Frequency hard handovers can be executed for following configurations: • • •

Intra Node B handover Inter Node B / Intra-RNC handover Inter-RNC handover (quality based only and DCH to DCH only).

In case of more than one RNC being involved a functional split leading to different RNC roles is applied as follows: • •

•

The controlling RNC (CRNC) provides the Iub Interface towards Node B and controls the setup, addition and release of radio links with NBAP signalling The serving RNC (SRNC) provides the Iu Interface towards core network (CN) and the Uu Interface towards UE for the actual connection. Depending on the actual configuration the SRNC provides the Iur interface(s) towards drift RNC(s) and/or the Iub Interface(s) towards Node B(s). The SRNC controls the measurements to be performed by the UE. On reception of measurement reports the SRNC initiates and controls the handover protocol with RRC, RNSAP and NBAP signalling. It acts as CRNC for Node B(s) directly connected and controls the CRNC functions at a drift RNC for Node B(s) not directly connected. The drift RNC (DRNC) acts as CRNC. It performs the CRNC functions in accordance to requests of the SRNC and reports the results.

Note: Intra Node B handover or Inter Node B / Intra-RNC handover may take place either within the SRNC or within a DRNC Hard handover over Iur

In case of Inter-RNC hard handover or in case of Intra Node B - or Inter Node B handover within a DRNC the procedure is executed in the same way as where SRNC is executing physical channel or transport channel reconfiguration procedure (step 3) .................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 11-47 Issue 1, August 2007 See notice on first page



while DRNC is taking care of the NBAP procedures (steps 2 and 4) initiated by the SRNC through the Iur interface via corresponding Radio Network Subsystem Application Part (RNSAP) procedures. Inter-frequency hard handover towards a target cell which is controlled by a DRNC is only applicable for quality based DCH to DCH handover. The figure below shows the all-embracing successful inter-frequency handover procedure (DCH to DCH) for inter Node B, Inter-RNC case. Two DRNCs and the SRNC are involved. The description can be reduced to the various network scenarios given above by allocating the CRNC to the SRNC or to the DRNC respectively. If the CRNC is at the SRNC, then the RNSAP procedures 1, 5, 6 and/or 10, 14, 15 can be omitted.


11-48


UE

Node B old


Node B new

DRNC old

DRNC new

SRNC

Measurements and Handover Decision

1. Radio Link 2. Radio Link Setup Request

Setup Request


4. ALCAP Iub Transport Bearer Setup

5. Radio Link Setup

6. ALCAP Iur Transport Bearer Setup 7. Physical Channel Reconfiguration

8. UE Detected

9. Physical Channel Reconfiguration Complete

10. Radio Link Deletion Request 11. Radio Link Deletion Request


13. ALCAP Iub Transport Bearer Release 14. Radio Link Deletion Response

15. ALCAP Iur Transport Bearer Release



Hard handover troubleshooting ................................................................................................................................................................................................................................... Introduction

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

The major components that constitute failures of both Intra-RNC and Inter-RNC Hard handover are: • • • • • • • • •

Poor RF conditions Incorrect translations settings No Node B resources available No transport resources available No UE answer UE Reject Node B / RNC outages Iub, Iur link outages Iur configuration to drift RNC.

Intra/Inter RNC HHO PMs/KPIs

Intra RNC HHO is defined as HHO between cells controlled by the same RNC. Inter RNC HHO involves a DRNC and may be performed between SRNC and DRNC or between two DRNCs. With respect to setting up the resources in UTRAN (step 2 of the interworking inter-frequency HHO procedure) the counters which are already defined for soft handover radio link performance measurement are reused for hard handover. In detail the following are reused: Attempted, successful and failed radio link setups on Iub: • • • • • • •

RLM.AttRLSetupIub RLM.AttRLSetupIub.CSV RLM.AttRLSetupIub.CSD RLM.AttRLSetupIub.PSD RLM.SuccRLSetupIub RLM.FailRLSetupIub.NodeBRes.CSV RLM.FailRLSetupIub.NodeBRes.CSD


11-50


•

RLM.FailRLSetupIub.NodeBRes.PSD

•

RLM.FailRLSetupIub.TransRes.CSV

• •

RLM.FailRLSetupIub.TransRes.CSD RLM.FailRLSetupIub.TransRes.PSD


Attempted and failed radio link additions on Iub: • • • • • •

RLM.AttRLAddIub RLM.AttRLAddIub.CSV RLM.AttRLAddIub.CSD RLM.AttRLAddIub.PSD RLM.SuccRLAddIub RLM.FailRLAddIub.NodeBRes.CSV

• • • • •

RLM.FailRLAddIub.NodeBRes.CSD RLM.FailRLAddIub.NodeBRes.PSD RLM.FailRLAddIub.TransRes.CSV RLM.FailRLAddIub.TransRes.CSD RLM.FailRLAddIub.TransRes.PSD

Attempted and failed radio link setups on Iur: • • •

RLM.AttRLSetupIur RLM.FailRLSetupIur.sum RLM.FailRLSetupIur.TransRes

Attempted and failed radio link additions on Iur: • • •

RLM.AttRLAddIur RLM.FailRLAddIur.sum RLM.FailRLAddIur.TransRes

Note: The latter counters are used when both source and target cell are located at the DRNC. In this case a radio link addition procedure is performed on the Iur Interface. Furthermore the following hard handover specific counters are used in step 2: • •

VS.HHO.AttPrepOutInterFreq.Qual Attempted preparations for outgoing inter-frequency hard handovers due to quality VS.HHO.AttPrepOutInterFreq.Load Attempted preparations for outgoing inter-frequency hard handovers due to load




With respect to hard handover execution (step 3 of the interworking inter-frequency HHO procedure) the following hard handover specific counters are used: • • •

• • •

HHO.AttOutInterFreq.Qual Attempted outgoing inter-frequency hard handovers due to quality HHO.SuccOutInterFreq.Qual Successful outgoing inter-frequency hard handovers due to quality Failed outgoing inter-frequency hard handovers due to quality: – HHO.FailOutInterFreq.Qual.ConfigUnsupported – HHO.FailOutInterFreq.Qual.PhysChanFail – HHO.FailOutInterFreq.Qual.ProtErr HHO.AttOutInterFreq.Load Attempted outgoing inter-frequency hard handovers due to load HHO.SuccOutInterFreq.Load Successful outgoing inter-frequency hard handovers due to load Failed inter-frequency hard handovers due to load: – HHO.FailOutInterFreq.Load.ConfigUnsupported – HHO.FailOutInterFreq.Load.PhysChanFail – HHO.FailOutInterFreq.Load.ProtErr

These quality related counters (*.Qual) are applied on per cell basis in case of intra RNC handover and on per PRNC basis in case of inter RNC handover. The load related counters (*.Load) are applied on per cell basis only. If the inter-frequency hard handover procedure timer expires while step 3 is in progress, then the following hard handover specific counters are used for CS- or PS RABs respectively: • •

VS.RAB.Drop.CS.InterFreqHHO Number of dropped CS RABs due to inter-frequency hard handover VS.RAB.Drop.PS.InterFreqHHO Number of dropped PS RABs due to inter-frequency hard handover

In order to be able to analyze the handover performance with respect to neighbor cell relations the following matrix counters are used. The number of attempted and successful inter-frequency hard handover per neighbor cell from the current best cell: • • • • • •

HHO.InterFreqPerNCell.Ncell_MCC HHO.InterFreqPerNCell.Ncell_MNC HHO.InterFreqPerNCell.Ncell_LAC HHO.InterFreqPerNCell.Ncell_CI HHO.InterFreqPerNCell.Att HHO.InterFreqPerNCell.Succ


11-52


No Node B resources available ................................................................................................................................................................................................................................... No Node B resources available

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



No transport resources available ................................................................................................................................................................................................................................... Introduction

The NBAP / RNSAP radio link setup and radio link addition procedure may fail due to no transport resources available, this means no Iub/Iur links are available due to maximum supported capacity reached.


11-54


UE reject ................................................................................................................................................................................................................................... Introduction

Upon sending the physical channel reconfiguration or transport channel reconfiguration message in the case of failure the RNC receives the physical channel reconfiguration failure or transport channel reconfiguration failure message from the UE respectively. In this case the UE returns to the old channel configuration. Failure causes

The UE Failure causes are: • • •

Configuration unsupported Physical channel failure Protocol error.

Related PMs / KPIs

The related PMs / KPIs due to quality based handover are: • • •

HHO.FailInterFreq.Qual.ConfigUnsupported HHO.FailInterFreq.Qual.PhysChanFail HHO.FailInterFreq.Qual.ProtErr

The related PMs/KPIs due to load based handover are: • • •

HHO.FailInterFreq.Load.ConfigUnsupported HHO.FailInterFreq.Load.PhysChanFail HHO.FailInterFreq.Load.ProtErr



Inter-system directed retry Overview ................................................................................................................................................................................................................................... Purpose

This section provides inter-system directed retry optimization and troubleshooting information Contents Inter-system directed retry procedure

11-57

Inter-system directed retry troubleshooting

11-60


11-56


Inter-system directed retry procedure ................................................................................................................................................................................................................................... Introduction

Directed retry combines RAB assignment with hard handover. The RAB assignment during call setup is avoided in UMTS and shifted to GSM instead. The original RAB assignment procedure only provides the trigger for the UMTS-to-GSM handover and will not be executed. The subsequent handover procedure implicitly performs the traffic channel assignment functions within GSM. In the current release inter-system directed retry is supported for emergency calls. Furthermore it is supported for WPS calls in case of congestion.




Inter-system directed retry signaling flow UE

Node B

BTS

DRNC

SRNC

BSC

3G-MSC

2G-MSC

1. Rab Assignment Request Decision for Directed Retry

1

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

2

Map Prep Handover resp. IAM ACM

Relocation Command (incl. GSM HO Command) Handover from UTRAN Command (incl. GSM HO Command) Handover Access Handover Detect Handover Detect

Physical Information SABM

3

UA Establish Indication Map-PrAcc Signal Handover Complete Handover Complete Radio Link Failure Indication

Map Send End Signal 6. IU Release Command 7. ALCAP Iu Transport B Release

8. RL Delete Request 9. Radio Link Deletion Request

ANM


4

11. ALCAP Iub Transport B Release 8. RL Delete Response

14. IU Release Complete

13. ALCAP Iur Transport B Release


11-58




The inter-system directed retry procedure steps are: 1. 2. 3. 4.

Decision to perform directed retry Relocation preparation procedure with setup of resources in GSM Handover execution via handover to UTRAN procedure Clear resources in the UTRAN via NBAP procedure.



Inter-system directed retry troubleshooting ................................................................................................................................................................................................................................... Introduction

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

During the relocation preparation procedure the following specific directed retry PMs are used: • • •

VS.IRATHO.AttRelocPrep.DirRetry Attempted relocation preparations for inter-system directed retry VS.IRATHO.SuccRelocPrep.DirRetry Successful relocation preparations for inter-system directed retry Failed relocation preparation for inter-system directed retry for the following causes from network point of view: – VS.IRATHO.FailRelocPrep.DirRetry.T_RELOCprep_exp (For the cause, “T_RELOCprep expiry” – VS.IRATHO.FailRelocPrep.DirRetry.FailTarSys (For the cause, “relocation failure in target system”) – VS.IRATHO.FailRelocPrep.DirRetry.NotSupTarSys (For the cause, “relocation not supported in target system”) – VS.IRATHO.FailRelocPrep.DirRetry.TarNotAllowed (For the cause, “relocation target not allowed”) – VS.IRATHO.FailRelocPrep.DirRetry.NoRRTarSys (For the cause, “no radio resources available in target cell”) – VS.IRATHO.FailRelocPrep.DirRetry.IncompRxState (For the cause, “ message not compatible with receiver state”)

When the directed retry procedure is completed successfully then the following specific directed retry PM is used: •

VS.IRATHO.SuccOutCS.DirRetry Successful Inter-System UMTS to GSM Directed Retry


11-60

12

12 Throughput optimization and troubleshooting


This chapter describes the UTRAN measurements and performance indicators that can be used to measure the throughput for the various uplink and downlink speeds and can provide an analysis to optimization related issues. Contents Throughput optimization

12-2


Throughput optimization and troubleshooting

Throughput optimization ................................................................................................................................................................................................................................... RLC SDU Throughput and Data volume

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

• • •

Total DL - data volume on RLC SDU DL non-HSDPA - data volume on RLC SDU HSDPA - data volume on RLC SDU


12-2


•

DL 64 kbps - data volume on RLC SDU

•

DL 128kbps - data volume on RLC SDU

• • • • • •

DL 384kbps - data volume on RLC SDU Total UL - data volume on RLC SDU UL E-DCH - data volume on RLC SDU UL 64 kbps - data volume on RLC SDU UL 128 kbps - data volume on RLC SDU UL 384 kbps - data volume on RLC SDU


QoS Based Throughput

Downlink throughput at the RLC SDU layer based on QoS type can be measured by the following PMs on a per RNC basis: • • • • •

VS.DataRate.PSDLIntact.DCH VS.DataRate.PSDLBgrd.DCH VS.DataRate.PSDLStrm.DCH VS.DataRate.PSDLIntact.HSDSCH VS.DataRate.PSDLBgrd.HSDSCH

Similar PMs are available in the uplink for the RNC: • • • • •

VS.DataRate.PSULStrm VS.DataRate.PSULIntact.DCH VS.DataRate.PSULBgrd.DCH VS.DataRate.PSULIntact.EDCH VS.DataRate.PSULBgrd.EDCH

If lower throughput is observed from these indicators then the user profile settings for the various QoS classes may need to be optimized at the core network. However a study of the radio conditions, RLC, DBC, Power control parameters and value of other throughput indicators will need to be investigated in tandem to derive an accurate analysis of the possible reasons. Weighted Random Early Discard throughput measurements

Throughput is regulated through the Weighted Random Early Discard (WRED) mechanism when the RNC processors are congested. Random packets are discarded to reduce the load on the RNC and as a consequence the throughput experienced by the subscriber will be affected. The total number of payload bits in the PDU discarded are aggregated and divided by the number of seconds in the granularity period and the lost throughput is reported through these counters. A large value for these PMs will require detailed planning steps to alleviate load on the RNCs. The counters are pegged for the ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary 12-3 Issue 1, August 2007 See notice on first page



throughput lost for the different QoS classes for uplink and downlink packet calls. These measurements can be studied with the RNC processor load measurements to get a good picture of the situation. Related measurements

• • • • • • • • • • • • •

VS.DataRate.PSDL.IntAct.DiscardWRED VS.DataRate.PSDL.Bgrd.DiscardWRED VS.DataRate.PSDL.Strm.DiscardWRED VS.DataRate.PSUL.IntAct.DiscardWRED VS.DataRate.PSUL.Bgrd.DiscardWRED VS.DataRate.PSUL.Strm.DiscardWRED VS.PO.BSCCP.Mean VS.PO.BSCOAM.Mean VS.PO.TPUCP.Mean VS.PO.TPUSP.Mean VS.PO.TPUTP.Mean VS.PO.TPUGICCP1.Mean VS.PO.TPUGICCP2.Mean

PS Data Throughput (Iu Interface)

The Mean Downlink Packet user data throughput on the IuPS interface can be calculated by the KPI, DL mean user data rate received on PS CN. The data rate of discarded DL user bits on the IuPS is calculated by recording the discarded Traffic PDUs and can be measured using DL discarded data rate received on PS CN. Related PMs / KPIs

•

DL mean user data rate received on PS CN

•

DL discarded data rate received on PS CN


12-4

Glossary

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

Numerics 3GPP

3rd Generation Partnership Project ....................................................................................................................................................................................................................................

A

AAL

Asynchronous Transfer Mode Adaptation Layer AICH

Acquisition Indicator Chanel ALCAP

Access Link Control Application Protocol AM

Acknowledged Mode ARQ

Autromatic Repeat Request ATM

Asynchronous Transmission Mode ....................................................................................................................................................................................................................................

B

BCCH

Broadcast Control Channel BCH

Broadcast Channel BLER

Blocking Error Rate

.................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary GL-1 Issue 1, August 2007 See notice on first page

Glossary

BMC

Broadcast/Multicast Control ....................................................................................................................................................................................................................................

C

CAC

Call Admission Control CC

Call Control CCCH

Common Control Channel CCPCH

Common Control Physical Channel CDMA

Code Division Multiple Access CFN

Connection Frame Number CPCH

Common Packet Channel CPICH

Common Pilot Channel CRNC

Controlling Radio Network Controller CS

Circuit Switched domain CTCH

Common Traffic Channel ....................................................................................................................................................................................................................................

D

DBC

Dynamic Bearer Control DC

Dedicated Control DCCH

Dedicated Control Channel


GL-2

Glossary

DCH

Dedicated Channel DL

DownLink DPCCH

Dedicated Physical Control Channel DPCH

Dedicated Physical Channel DPDCH

Dedicated Physical Data Channel DRNC

Drift Radio Network Controller DSCH

Downlink Shared Channel DTCH

Dedicated Traffic Channel ....................................................................................................................................................................................................................................

E

E2E

End-to-End Ec/Io

Signal to Noise ratio ....................................................................................................................................................................................................................................

F

FACH

Forward Access Channel FBI

FeedBack Information FDD

Frequency Division Duplex FP

Frame Protocol ....................................................................................................................................................................................................................................

G

GC

General Control ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary GL-3 Issue 1, August 2007 See notice on first page

Glossary

GPRS

General Packet Radio Service GPS

Global Positioning System GSM

Global System for Mobile communications GTP

GPRS Tunnelling Protocol ....................................................................................................................................................................................................................................

I

IP

Internet Protocol IRAT

Inter-Radio Access Technology ....................................................................................................................................................................................................................................

K

KPI

Key Performance Indicator ....................................................................................................................................................................................................................................

L

LA

Location Area LCAT

Lucent Cells Application Tool LDAT3G

Lucent Data Analysis Tool for 3G ....................................................................................................................................................................................................................................

M

MAC

Medium Access Control MAC-b

Broadcast Medium Access Control MAC-c/sh

Common Medium Access Control MAC-d

Dedicated Medium Access Control


GL-4

Glossary

MM

Mobility Management MO

Mobile Originated call MSC

Mobile Switching Center MT

Mobile Terminated call MTP3

Message Transfer Protocol 3 ....................................................................................................................................................................................................................................

N

NAS

Network Access Server NBAP

Node B Application Part Nt

Notification ....................................................................................................................................................................................................................................

O

OCNS

Orthogonal Channel Noise Simulation OMC

Operation and Maintenance Center OMC-UPS

OMC for the UTRAN and the Packet Core cluster ....................................................................................................................................................................................................................................

P

P-CCPCH

Primary Common Control Physical Channel P-CPICH

Primary Common Pilot Channel P-SCH

Primary Synchronization Channel PC

Personal Computer ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary GL-5 Issue 1, August 2007 See notice on first page

Glossary

PCCH

Paging Control Channel PCH

Paging Channel PCPCH

Physical Common Packet Channel PDCP

Packet Data Convergence Protocol PDP

Packet Data Protocol PDSCH

Physical Downlink Shared Channel PDU

Packet Data Unit PICH

Paging Indication Channel PM

Performance Management PMM

Packet Mobility Management PRACH

Physical Random Access Channel PS

Packet Switched domain PSC

Primary Scrambling Code ....................................................................................................................................................................................................................................

Q

QoS

Quality of Service ....................................................................................................................................................................................................................................

R

RA

Routing Area


GL-6

Glossary

RAB

Radio Access Bearer RACH

Random Access Channel RANAP

Radio Access Network Application Protocol RB

Radio Bearer RF

Radio Frequency RLC

Radio Link Control RLF

Radio Link Failure RNC

Radio Network Controller RNSAP

Radio Network Subsystem Application Part RNTI

Radio Network Temporary Identity RRC

Radio Resource Control RTP

Real-Time Protocol ....................................................................................................................................................................................................................................

S

S-CCPCH

Secondary Common Control Physical Channel S-CPICH

Secondary Common Pilot Channel S-SCH

Secondary Synchronization Channel SAAL

Signaling ATM Adaptation Layer ................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary GL-7 Issue 1, August 2007 See notice on first page

Glossary

SAP

Service Access Point SCH

Synchronization Channel SDU

Service Data Unit SF

Spreading Factor SGSN

Serving GPRS Support Node SM

Session Management SPAT3G

Service Performance Analysis Tool for 3G SRNC

Serving Radio Network Controller SSCF

Service Specific Coordination Function SSCOP

Service Specific Connection Oriented Protocol STM

Synchronous Transport Module ....................................................................................................................................................................................................................................

T

TFC

Traffic Format Combination TM

TRansparent Mode TPC

Transmit Power Control ....................................................................................................................................................................................................................................

U

UCU

UMTS Channel Unit


GL-8

Glossary

UDP

User DAtagram Protocol UE

User Equipment UL

UpLink UM

Unacknowledged Mode UMSC

UMTS Mobile Switching Center UMTS

Universal Mobile Telecommunication System UNI

User-Network Interface URA

UTRAN REgistration Area USCH

Uplink Shared Channel UTRAN

UMTS Terrestrial Radio Access Network ....................................................................................................................................................................................................................................

V

VLR

Visitor Location Register ....................................................................................................................................................................................................................................

W

WAG

Wireless Application Gateway

................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary GL-9 Issue 1, August 2007 See notice on first page

Index

A Access preliminary procedures, 8-8

Determination of accessibility problem, 8-6 Dropped calls analysis, 9-2

Average active set size, 11-7 ................................................................................................

Dropped RAB analysis due to congestion, 9-9

C Call admission control failures, 8-19

Dynamic bearer control failures, 8-30

Call availability, 8-4

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


H Handover procedure troubleshooting, 11-32

CS Voice GSM to UMTS (inter-RAT) handover and troubleshooting, 11-26 CS Voice UMTS to GSM (inter-RAT) handover and troubleshooting, 11-18 PS UMTS to GSM (inter-RAT) Cell Change Order and troubleshooting, 11-33 Serving HS-DSCH Cell Change, 11-39 Soft/Softer handover and troubleshooting, 11-3 Cell re-selection failures, 8-9

................................................................................................ I

Idle mode, 4-38 Inter-frequency hard handover procedure, 11-45 Inter-system directed retry troubleshooting, 11-60 Interfaces Iu-cs, 4-56 Introduction to RRC connection establishment, 8-16 Iu-cs interface, 4-56

Connected mode, 4-38

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

CS IRAT HO success rate (UMTS -> GSM), 7-7

K Key performance indicators for UTRAN

CS Voice GSM to UMTS (inter-RAT) handover procedure, 11-27 CS Voice IRAT handover procedure troubleshooting, 11-25 CS Voice relocation preparation procedure troubleshooting, 11-23 CS Voice UMTS to GSM (inter-RAT) handover procedure, 11-19 ................................................................................................ D Definition of optimization, 1-2

CS IRAT HO success rate (UMTS -> GSM), 7-7 KPI, 2-2 ................................................................................................ L Logical channels, 4-24 ................................................................................................ M MAC, 4-31

Medium Access Control, 4-27 ................................................................................................ N Network layer, 4-35

.................................................................................................................................................................................................................................... 401-382-810R04.03 Alcatel-Lucent - Proprietary IN-1 Issue 1, August 2007 See notice on first page

Index

No answer from UE, 8-33 No Node B resources available, 11-12, 11-53 No transport resources available, 11-13, 11-54 No UE answer, 11-14 Not optimizing Consequences, 1-4 ................................................................................................ O Optimization costs, 1-2

Optimization requirements, 1-2 ................................................................................................

Serving HS-DSCH Cell Change troubleshooting, 11-43 Soft handover troubleshooting, 11-9 Soft/softer handover procedure, 11-4 ................................................................................................ T Throughput optimization, 12-2

Transport channels, 4-20 ................................................................................................ U UE reject, 11-15, 11-55

Unlisted Set Cells, 11-16

P Paging failures, 8-24

Physical channels, 4-13 PS UMTS to GSM (inter-RAT) Cell Change Order procedure, 11-34 PS UMTS to GSM (inter-RAT) Cell Change Order troubleshooting, 11-37 ................................................................................................ Q Quality KPIs, 10-2 ................................................................................................ R RAB establishment, 8-27

RACH access procedure failures, 8-11 Radio bearer establishment failures, 8-32 Radio link failures analysis due to synchronization issues, 9-6 Radio link setup analysis, 8-21 Reasons for optimization, 1-4 Relocation resource allocation procedure troubleshooting, 11-30 RLC, 4-31 RRC, 4-38 RRC connection setup failure, 8-23 ................................................................................................ S Serving HS-DSCH Cell Change procedure, 11-40


IN-2

UMTS Basics

Recommend Documents