Vous êtes sur la page 1sur 89

UMTS RF

Optimization Guideline

Issue 3.1
November 2006

Lucent Technologies - Proprietary


This document contains proprietary information
of Lucent Technologies and is not to be disclosed or used
except in accordance with applicable agreements
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved

The copyright laws of the United States and other countries protect this guideline. It may not
be reproduced, distributed, or altered in any fashion by any entity (either internal or external
to Lucent Technologies), except in accordance with applicable agreements, contracts, or
licensing, without the express written consent of the Author.

For any information or permission to reproduce or distribute, please contact:


Lucent Technologies Network Systems GmbH
Thurn und Taxis Strasse 10
90411 Nuremberg, Germany
Contact: Andreas Conradi (aconradi@lucent.com)

Notice
Every effort was made to ensure that the information provided in this document was accurate
at the time of printing, but this information is subject to change.

Lucent Technologies - Proprietary


This document contains proprietary information
of Lucent Technologies and is not to be disclosed or used
except in accordance with applicable agreements
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved

Table of Contents
1. Introduction...............................................................................................................5
2. Pre-Requisites............................................................................................................6
3. RF Optimization Process..........................................................................................9
4. RF Optimization Tools ...........................................................................................35
5. Application Tests for Network Performance Verification ....................................44
6. UMTS Performance Metrics..................................................................................49
7. UMTS RF Parameters............................................................................................52
8. RF Optimization Aspects........................................................................................59
9. Definitions of Terms...............................................................................................71
10. Definitions Equations...........................................................................................80
11. Abbreviations.........................................................................................................84

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 3 of 89

Version History
Version
0.1
0.9
1.0
2.0
3.0
3.1

Changes
First draft version
Preliminary Version ready for review
Preliminary Released Version
Review Version
Revised Version ready for review
Major Change: Rewrite entire document, update according market
experiences
Review Version

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 4 of 89

1
1. Introduction
This document presents a set of procedures and guidelines for RF Optimization of a UMTS
network independent of the equipment vendor. RF Optimization consists of assessing and
improving the network performance so that it meets contractual and technical objectives. RF
Optimization is primarily used during new UMTS deployments prior to a commercial launch.
It is also a continuous process as there are network configuration changes due to the
addition of a new cells and/or increased traffic load or introduction of new features.
The primary target audience for this document is the Lucent RF personnel responsible for
preparation and execution of the RF Optimization tasks. This document is also intended to
assist the local technical staff during maintenance and operation of the system as well as the
post deployment teams delivering services to the customer.
The user of this guideline will gain a fundamental understanding of all major tasks performed
during RF Optimization. Insights into RF Optimization aspects are given and relevant RF
Parameters and Performance Metrics will be addressed. With this guideline the users will be
able to perform all necessary steps to improve the RF performance of the network.
The focus of this guideline is on optimization of networks deployed with Lucent Technologies
equipment. However, the described optimization methods and procedures shall be applicable
for any vendors UTRAN networks (multi Vendor).
In order to avoid duplicated documentation and outdated information, references to proper
documents will be included. This applies to the individual RF optimization procedures, for
which detailed information is provided by Lucents Method and Procedure (M&P) documents.
Other target documents are Lucents UMTS Translation Application Notes or the RF
Engineering Guideline.
It should be noted that the RF optimization guideline is coordinated with the UMTS RF
Performance Analysis and Troubleshooting Guideline. The focus of the RF optimization
guideline is primary on describing procedures for the optimization execution. Details for
specifics such as RF parameters, performance metrics, network failures as well as individual
troubleshooting methods are found in the complementary <UMTS RF Performance Analysis
and Troubleshooting Guideline>.
It is strongly recommended to read Section 2 on Pre-Requisites before attempting to use
this document. This section provides the overall structure of the guideline in order to best
apply optimization methods.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 5 of 89

2
2. PreRequisites
Although this document describes the optimization process, its straight application is rarely
found in the markets due to different planning strategies or contractual obligations (Scope of
Work). This document should be seen as a reference book guiding the RF engineers through
each of the individual work assignments.
This Guide is written to provide engineers with the necessary methods and procedures for
optimizing a UMTS network. References to complementary documentation such as Lucent
Methods & Procedures or optimization tool descriptions are provided throughout this
document.
The Global RF Methods and Procedures / Tool Support web portal provides Lucent
personnel with an extensive knowledge base that is stored in technical method and
procedure documents. The document structure is divided into the Layer C, D, and E. Layer
C documents are high-level processes and refer to an associated Layer D document that
describes the process in more detail - including inputs/outputs/quality records. Layer E
documents include reference information, how-to and forms.
The UMTS RF Optimization Guideline should be used in conjunction with the <UMTS RF
Performance Analysis and Troubleshooting Guideline> [Available on Global RF Methods and
Procedures / Tool Support -> RF Guidelines]. This guideline is based on the UMTS
optimization process and is used for the identification, classification and resolution of
problems, failures and performance degradations. These activities comprise of the following
items:

Drive test data (Uu trace files and 2G/3G scanner measurements)

Network Interface tracing (e.g. Iu, Iur and Iub interface tracing)

PM KPI analysis

Failure investigation

For optimization procedures concerning the general RF topics such as UMTS network
design, UMTS link budget, neighbor lists, and scrambling code planning refer to the RF
Engineering Guideline. The scope of this guideline is listed below:

Covers the basic principles of UMTS RF engineering design and optimization

Provide guidelines on design and optimization of UMTS RF networks

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 6 of 89

Pre-requisites for understanding the content of this Guide include knowledge of the UMTS
network architecture and UMTS principal functionalities. The list below provides an overview
of the required UMTS knowledge.

UMTS system architecture and components


o

Access network

UTRAN

Core network

GSM and UMTS Interworking

UMTS radio link and radio resource management


o

Spreading

Orthogonal variable spreading factor

Scrambling codes

Multi-path signals

Definitions of channel types

Physical channels

Channel coding, multiplexing, and rate matching

Transport channels

Logical channels

Mobility and Call Management: location updates, call processing


o

Power Control

Handover

UMTS system services


o

UTRAN Signaling (Call Flow)

Interworking between UMTS and GSM

The UMTS Introduction Course UM1001W covers the aforementioned items. This course
can be accessed at Lucent Technologies Wireless University via UMTS Product Training.
Pre-requisites for RF optimization are also listed in Lucents Translation and Application
Notes. These documents address the RF parameters and algorithm (Lucent specific) in detail
and cover the following topics:

Cell Selection and Reselection

Access Procedures

Handover

Inter-RAT Handover UMTS-GSM

Power Control

Load Control Algorithms

High Speed Downlink Packet Access (HSDPA)


Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 7 of 89

Orthogonal Channel Noise Simulator (OCNS)

RF Call Trace

Radio Link Control (RLC)

High Level Protocol Stack Parameter

The Figure 1 below provides the overall structure of this guideline in order to best apply
optimization methods (yellow = guideline topics, green = references):

PreOptimization
Site Readiness
M&P Documents

Optimization
Planning
Optimization
Execution

RF Tools Lab
Global RF Core Support Homepage
Navigator Portal

U
MT
S
RF
Op
tim
izat
ion

RF Tools

M&P Documents

Test
Applications

Performance
Metric
RF
Parameters

Optimization
Aspects

Scope of Work /
Acceptance Test Plan
(ATP)

UMTS RF Performance Analysis and Troubleshooting Guideline

Translation and Application Notes

UMTS RF Performance Analysis and Troubleshooting Guideline

Translation and Application Notes

UMTS
Knowledge

UM1001W
UMTS Product Training.

Figure 1 Overall Guideline Structure


Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 8 of 89

3. RFOptimizationProcess
3.1.

RFOptimizationProcessOverview

This Chapter shall provide the RF optimization engineer with a general RF optimization
methodology. An overview of the different optimization tasks and references to detailed M&P
documentation is provided so the RF optimization engineer can assemble a process
according to the market situation.
The overall UMTS RF Optimization process can be divided into the following three phases:
Pre-Optimization, Drive Test Based Optimization and Service Measurement Based
Optimization. The entire process is dependent on the market situation, network deployment
type and eventually also on the contractual obligations (Scope of Work). As indicated by
Figure 2 below, Pre-Optimization is an optional phase and might be required especially for
new network deployment or network extensions. This phase might incorporate tasks such as
hardware functionality checks (proper integration), coverage verification, adjustments for
initial antenna tilts, creation of initial neighbor lists, and RF parameter declaration. Other
optional tasks in this phase may include initial scanner drive test for coverage and neighbor
list verifications.
Pre-Optimization
(optional)
Service Measurement Based
Optimization

RF
Optimization
Start

Drive Test Based Optimization

Figure 2 Overall Optimization Process

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 9 of 89

The objectives of the Service Measurement Based Optimization and the Drive Test Based
Optimization are to assess and improve network performance and quality. Both optimization
phases are independent of each other, but can be performed in the same phase depending
on market situation and contractual obligation. It is recommended to perform the service
measurement based optimization prior to drive test based optimization because major
network issues can be eliminated during this optimization phase, thus reducing costs. This
allows the drive test based optimization to focus on the RF optimization or performance.
However, the Service Measurement Based Optimization is primary performed during
commercial network operation with live traffic. The focus during the Service Measurement
Based Optimization is in assessing the network performance and quality using appropriate
network performance counters (PM) together with dedicated tools. It allows a comprehensive
analysis from network to the individual UMTS cell or call, with conclusions on the
performance of network elements such as air interface, cell operation or core network. PM
counter and Key Performance Indicators (KPI) reflect the network viewpoint whereas drive
test data the subscriber viewpoint.
Network performance counters play a more and more significant rule for the network
optimization. PM counters are available per logical network element such as RNC, lur,
NodeB, or per network channel such as RACH, DCH and PCH. Together with powerful tools
such as Lucents SPAT3G/LUNAR, comprehensive and detailed performance evaluation is
ensured. Specific optimization techniques allow intensive and effective network
troubleshooting and hence network issues can be resolved without performing extensive
drive tests.
Network performance counters, as well several troubleshooting techniques, are in detail
described by the <UMTS RF Performance Analysis and Troubleshooting Guideline>.
Assessing the UTRAN air interface by performing field drive tests will remain one of the
major tasks during UMTS RF Optimization. Although there is the consideration of other
network assessments and optimization techniques, the performance of the network is still
verified and reported based on drive tests (end user experience). The RF Drive Test Based
Optimization is the primary optimization phase and is the focus of this document.
The primary RF Optimization objectives are:

Minimize Call Setup Failures

Minimize Drop Calls

Maximize Voice Quality

Maximize Data Throughput

Minimize Packet Data Latency

Maximize System Capacity

Ensure defined system service coverage

Maximize reliability of ISHO handover

Strike a balance between reliability, coverage & capacity

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 10 of 89

Figure 3 provides an overview of the optimization process including the individual tasks. As
mentioned previously, the actual process used in the field is dependent on the scope of work
(contractual obligations) as well as on the market situation. Prior to starting optimization, an
appropriate optimization package is defined assembling all the necessary tasks.

Pre-Optimization using

RF Design
Verification

Ocelot

New Cell
Deployment

Optimization
Process

RF Parameter
Definition

PreOptimization

Neighbor List
Definitions
Scrambling Code
Assignments

Service
Measurement
Based
Optimization
Refer to RF
Troubleshooting Guideline

Drive Test
Based
Optimization

Site Readiness

Spectrum Clearance
Antenna Audit

Baseline Existing
System

Optimization
Planning

Sector Verification

RF Parameter Audit
Scrambling Code
Plan Audit

Cluster Definition

Neighbor List
Plan Audit

Drive Route Planning

Antenna Audit

Optimization
Execution

Cluster Optimization
System Verification

Figure 3 Optimization Process

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 11 of 89

3.2.

NetworkDeploymentScenarios

Each of the aforementioned optimization phases is found in various network deployment


scenarios. The main network deployment scenarios are listed below:

Greenfield scenario, where a brand new network is deployed with no history of 2G


wireless systems. One of the challenges during RF optimization will be to ensure
seamless UMTS coverage for the defined service area, assumed no Inter System
Handover (ISHO) capabilities are given.

Overlay scenario, where a new UMTS network is built over an existing system of a
different air interface technology (e.g. 2G GSM).
The Overlay scenario differs from the Greenfield scenario only by having the existing
underlay 2G PCS, GSM and/or DCS network(s). In general the same RF
optimization procedures are applicable, with minor changes to the tasks. For
example the RF network design at the Overlay scenario is usually given by the
underlying network, e.g. antenna heights, cell site locations, mechanical tilts (for
dual/tri band antennas). UMTS coverage holes are more or less inevitable and
should not affect the overall designated service coverage area due to the Inter
System Handovers (ISHO). Therefore one of the major focuses is to ensure the
seamless service coverage (ISHO parameters, 3G-2G neighbors).

Network Expansion, where new UMTS cell sites are deployed in addition to an
existing UMTS network (or UMTS overlay) to enhance coverage and capacity.
Since in major regions, such as in Europe or northern America, UMTS networks are
already deployed as well are overlay networks on GSM 900/1800/1900, the most
common scenario is the Network Expansion scenario. In this scenario additional cell
sites are integrated in order to improve or extend the UMTS service coverage.
Another reason for integrating new cell sites is due capacity expansions. The major
focus is to ensure faultless and smooth integration of the new cell site(s) into to
operating system that is serving already a high amount of customers. The second
focus is verification of the target coverage area as well as seamless service
coverage within the vicinity of the new cell site(s).

Swapout scenario, where a new UMTS network is replacing an existing system of


the same air interface technology.
The Swapout scenario describes equipment replacement by a new UTRAN system.
This scenarios is similar to the Greenfield and Overlay scenario, but the difference is
that it is essential prior to any integration or optimization activity, to base line (i.e.
record the performance of) the existing system. RF network performance
measurements must be collected, analyzed and documented prior to the swapout.

Additional Carrier scenario, where additional carriers are integrated to an existing


UMTS network. Specific RF Optimization scenarios, such as the Additional Carrier,
Hierarchical Cell Structure or Micro Cell implementation are individual addressed.

Each new deployment require RF parameter model(s) assignments, scrambling code


and neighbor plans that need to be set up prior to any cell site operation. Tasks like RF
service coverage examinations, spectrum clearance tests, antenna audits or cell
verification tests should be considered as primary tasks prior to the RF optimization.
Both Service-Based Optimization and RF Drive Test Based Optimization are especially
applicable for any existing commercial network.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 12 of 89

3.3.

PreOptimization

3.3.1. PreOptimizationOverview
The Pre-Optimization process starts with the plan for a new cell sites ready to be integrated.
Once they are integrated (hardware is installed), the RF parameters such as neighbor lists,
scrambling codes and RF translations need to be assigned. If not done by the RF
department, the RF coverage would need to be verified especially concerning the antenna
tilts of the new and surrounding commercial cell sites.
After completion, the new cell site(s) can become operational ready to be drive tested.
During this phase also network counters need to be observed (if live network). If there are
alarms or not acceptable performance caused by the new cell site, the cell site must be
switched off and further investigations are required.
Pre-optimization is particularly important when integrating new sites in an area where UMTS
coverage is already provided. The negative impact that could be caused by the integration of
new sites must be minimized. Proper pre-optimization ensures less costly RF optimization,
as a less extensive drive tests are needed.
The following sections will address each of the above-mentioned pre-optimization tasks.
Since the local RF engineering department mainly performs these tasks, only significant
aspects are addressed here.
3.3.2. RFDesignVerification
Prior to any successful RF Optimization, an adequate UMTS network design is necessary.
The RF design of new deployed cell sites need to be verified, preferably using a RF
planning / prediction tool (e.g. Lucent Airpro). The goal is to ensure efficient coverage for the
target area, usually called a market area. The definition of the overage levels is required,
e.g. Ec and Ec/Io for Voice and PS 384kbps (indoor/outdoor etc.). In addition, the best
serving cell and pilot pollution plots will be analyzed.
The set of new cell sites as well as surrounding cell sites (1st tier) require the verification of
the electrical antenna tilts. The footprints of the surrounding cell sites might become
excessive and thus need to be limited. The optimum antenna tilts can be achieved by
examining the terrain and clutter profile as well as the coverage footprints. If cell sites are colocated and multiple band antennas are used (common), the mechanical antenna tilts are
often fixed to the underlying technology. Often mechanical tilts of 0 are implemented to
avoid strong antenna back lobes and there is no permission for modifying. Below a summary
of important steps during this RF design verification:
1. Assess coverage footprints of new cell site(s) and 1st cell tier.
2. Ensure adequate cell overlapping
3. Minimize possible cell overshooting
4. Assess pilot pollution and dominant server plots
5. Ensure efficient service coverage for the designated area. Lack of coverage or
coverage holes close to the new cell site should be addressed to the customer
When new cell sites are deployed, antennas are mounted with tilts derived from the latest RF
design. The installed antenna tilts might not be the optimized. Effort should be taken to
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 13 of 89

ensure proper tilt planning since its implementation is usually very costly. Tilt modifications
should be considered prior to RF optimization and hence drive tests. For any unclear
situations during the design verification, current tilts should be used and the area must first
be driven in order to prevent multiple antenna tilt modifications.
Any recommendation for modifications of the RF design (antenna tilts) must be documented
and addressed to customer. After any modification is implemented, the network maintenance
tool (OMC-U) as well as the RF database should be updated accordingly.
3.3.3. NewCellDeployment
A common scenario is the deployment of single cell sites into an existing commercial cell site
cluster as well as the deployment of island cell sites in rural areas.
A plan is required when deploying several cell sites that are connected to each other. This
will ensure the entire cell sites are integrated within the same timeframe. The integration of
new cell sites within the same vicinity at different times would create different neighbor lists
each time and will double drive test time. Performing repeated RF Optimization should be
avoided to minimize expense and labour.
When deploying a cluster cell sites for a new area, cell sites should be integrated cluster by
cluster. This method should also be applied for the Greenfield and New Deployment
scenario.
Under common circumstances in commercial networks, pre-optimized cell sites will be turned
on before completing the RF optimization. During this stage, network alarms must be
watched as faults can be expected. In case of network alarms, (faulty hardware), relevant
cell sites must switched off and further investigations are required.
Performance counter verification is a possibility for performance testing after the preoptimization phase and before the RF optimization phase. If specific counters (e.g. RAB
setup failure, RRC connection failure, UL interference) indicate measurements high above
targets, immediate investigations are required (e.g. neighbor lists). Performance counters are
discussed in detail in the <UMTS RF Performance Analysis and Troubleshooting Guideline>.
3.3.4. RFParameterDefinition
The RF parameter assignment must be completed prior to the operational stage of the new
cell site(s) (unlocked in OMC-U). During the pre-optimization phase the RF parameter
assignment should be a minor task as parameter models are usually already defined. For
new cell sites just the appropriate parameter model needs to be assigned and done using the
appropriate network maintenance tools (OMC-U). Those models might be dedicated to the
network release, cell type or network area (e.g. urban / rural). Each model e.g. MICRO,
MACRO DEFAULT or MACRO DENSE consists of a set of default RF parameters. The
network operator usually provides these parameter models / parameter sets or access to
appropriate network tools.
For Lucent deployed markets the parameter sets for new the cell sites can either be
assigned on the NDP Web Portal project database or directly in the network maintenance
tool OMC-U. Default parameter sets as well as the parameter catalogue (PARKAT) are
available on this portal. Details about RF parameter, its definitions and recommendations are
provided by the Translation and Application Notes.
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 14 of 89

3.3.5. NeighborListDefinition
The neighbor list assignment must be completed prior to the operational stage of the new cell
site(s) (unlocked in OMC-U). Neighbor lists are assigned in the network maintenance tool
(OMC-U).
Proper neighbor list planning ensures smooth optimization drive tests by avoiding simple RF
failures due to missing neighbor relations and minimizes the amount of drive testing.
Neighbor list assignment during pre-optimization is required for network expansions since
new cell sites will be integrated into commercials networks. The neighbor assignments
include the neighbor list verification of the 1 st, 2nd and 3rd tier cell sites. The 3G-2G neighbor
relations must be declared for overlay networks (refer to UMTS IRAT Optimization
Guidelines)
If the neighbor planning is a task of the RF optimization team, planning strategies and rules
of the market must be followed.
When declaring the neighbor lists, the following handover types between source cell site and
target cell need to be considered:

Intra frequency handover [3G source cell towards a target cell 3G of the same
frequency]

Inter frequency handover [3G source cell towards a target cell 3G of a different
frequency]

Inter system handover [3G source cell towards a target cell of different RAT (e.g.
GSM). Also called InterRAT handover (IRAT)

Neighbor relations are usually being declared bi-directionally. Table 1 below presents one
possible strategy for a UMTS / GSM900 / DCS1800 network. The strategy here is to use the
DCS 1800 cell sites only as capacity expansion for GSM 900, therefore the 3G / DCS1800
handover is declared one way.
Sector Cell Source

3G UMTS Cell Site

3G UMTS Cell Site


3G UMTS Cell Site

Target Sector Cell


Co-located GSM 900
Cell Site
Neighbor located
GSM 900 Cell Site
Co-located DCS
1800
Cell Site
Neighbor located
DCS 1800 Cell Site
2G Micro Cell Site
(Capacity)
2G Micro Cell Site
(Coverage)

3G->2G Declaration

2G->3G Declaration

YES

YES

YES

YES

NO

Only if 2G cell site is inside 3G coverage of


e.g. Ec/No > -9 dB

NO
NO

Only if 2G cell site is inside 3G coverage of


e.g. Ec/No > -9 dB
Only if 2G cell site is inside 3G coverage of
e.g. Ec/No > -9 dB

YES

YES

Table 1 - Handover Relation Scenarios


Neighbor planning requires planning tools but for network expansion individual neighbor
planning might be performed manually. Signal level plots (e.g. for voice in-car) and best
server plots of each deployed RAT network will help to discover the required handover
relations. UMTS overlay networks are common in the markets and usually customer
guarantee >=95% coverage probably of the underlying network, e.g. for 2G GSM900.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 15 of 89

If prediction tools are not available, a visualization tool such as MapInfo (preferably in
combination with Google Earth) can be used for neighbor planning. Hereby following basic
rules can be applied, refer to Figure 4.
The neighbor list for cell <green> shall include neighbor relation to:
1. Co-located cells (red)
2. 1st tier cells within the horizontal antenna azimuth
3. Facing toward cells of 1st tier cell sites (yellow)
4. Facing toward cells of 2nd tier cell sites (blue)
5. Depending on antenna height and terrain condition, facing toward cell sectors of 3rd
tier cells (purple)

Figure 4 - General Neighbor Relation Rules

Antennas heights, terrain conditions as well cell site distances are essential during neighbor
planning and must be considered for verifications of neighbor relations.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 16 of 89

Another method of neighbor list planning is the usage of the 2G / 2G handover matrix usually
provided by the GSM OMC. These matrixes provide the distribution for each GSM cell sector
in all performed handovers. Taking all 2G / 2G handover relations into account for
occurrences e.g. >=10%, those neighbor relations can be translated one to one into the 3G /
3G and 3G / 2G neighbor relations. This method is only applicable for 3G / 2G co-located cell
sites.
Neighbor lists are declared on a per cell basis at the OMC-U. The recommended strategy is
to limit neighbor relations per cell site to an acceptable minimum. The general rule is that the
number of neighbor relations per handover type shall not exceed 15. An optimum is to
achieve 10 to 12 neighbor relations per cell site and per handover type. (e.g. 12x 3G<->3G
and 12x 3G<->2G relations). It should be noted that there is a limitation on the RNC level
regarding the amount of neighbor relation for the combined neighbor lists (UE is in soft /
softer handover). This limitation is UTRAN vendor dependent, for Lucent equipment the
combined lists per handover type are limited to 32.
Aside from any neighbor planning method, neighbor relations will need to be verified during
the drive test optimization. As mentioned before, proper neighbor planning drastically
minimizes the amount of drive testing. Please refer to Chapter 3.4.3.3 that provides some
additional information regarding neighbor relation aspects.
3.3.6. ScramblingCodeAssignment
The scrambling code assignment must be completed prior to the operational stage of the
new cell site(s) (unlocked in OMC-U). Scrambling codes are assigned in the OMC-U.
Similar to the neighbor list assignment, the scrambling code assignment is explicitly required
for network expansions. For new network deployments new scrambling code plans are
usually in place. If the scrambling code planning is task of the RF optimization team, planning
strategies and rules of the market must be followed.
There are 512 possible scrambling codes in the UMTS-FDD, divided in 64 groups of 8 codes.
The primary goal is to maximize the separation of two cells assigned with the same
scrambling code. Also cells declared as neighbors 1st and 2nd order must not use the same
scrambling code. The UE must not receive similar scrambling code power of the same
primary code from different cell sites.
During initial cell search, the UE performs the three-step cell search procedure to determine
the used scrambling code by the detected cell. In the first stage the UE detects the cell (PSCH), in the second stage the scrambling code group (S-SCH) and finally in the third stage
the UE acquires the primary scrambling code (out of 8).
The different code planning strategies are consequences of the above mentioned cell search
stages. One way of planning would be to assign different primary codes (0-7) to neighboring
cells belonging to the same code group. This would minimize the processing time used for
the second stage. The second way is to assign different scrambling codes to the neighboring
cells using the same primary code (0-7). This would minimize the processing time used for
the third stage of cell search. The optimum code plan might be a trade between optimizing
the second and third cell search stage. The algorithms used during the cell search are UE
vendor dependent and its performance might differ from UE to UE.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 17 of 89

The common code planning strategy is to assign different scrambling groups to the
neighboring cells using the same primary codes (0-7). This guarantees a maximal distance
between cells using the same primary scrambling codes and simplifies the code planning.
The general method is to define clusters of up to 64 cells. Usually those clusters should be
limited to 60 or less cells in order to have some spare code groups for network expansion.
Furthermore each defined cluster will be assigned with same primary code (0-7). Figure 5
below shows an example of this method. The clusters consist of 57 cells (19 cell sites). The
scrambling code groups are assigned clockwise from 1-57, starting with the cell in the middle
of the cluster. Each cluster will utilize the same primary code (0-7), e.g. the green cluster will
utilize 0, yellow 1 and blue 2.

Figure 5 Scrambling Code Group Assignment

Scrambling code for new cell sites should be assigned according the scrambling code plans
defined in the network. Usually in practice the clusters are not regular as shown in the picture
above and therefore appropriate tools are required. A prediction tool such as Lucent Airpro
cold verify the overlap between cells using the same primary scrambling code, or
visualization tools such as MapInfo can help to ensure proper code planning. The prediction
tool Airpro provides the automatic scrambling code assignment feature.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 18 of 89

Assigning manual scrambling codes for new cell sites


noted. The final distance between scrambling code
consideration of e.g. best server plots of the cells using
scrambling code reuse conflicts caused by 2 ways
considered, see Figure 6.

the following aspect should also be


reused must not only depend an
the same scrambling code. Possible
handover scenarios must also be

SC 300^2
NB

SC 200

NB
SC 100

SC 300^1

NB

Mobile

Figure 6 Scrambling code reuse conflict

The mobile moves into soft handover of SC300^1 and SC200. The new combined neighbor
list includes SC100 (SC100 is neighbor of SC200). Assuming the unfavourable situation,
SC100 becomes stronger and is added into the active set (3 way soft HO), the new
combined neighbor list has a conflict with SC300 referring to two cells.
Even the service coverage of SC300^1 and SC300^2 is not overlapping, the SC reuse
conflict is given for SC300 via 2 way handover relations.
3.3.7. PreOptimizationusingOcelot
Pre-Optimization can also be performed using Lucent Technologies optimization tool
Ocelot. Ocelot performs evaluation and modifications of the RF design by adjusting
antenna tilts, azimuths or power settings in order to improve coverage, capacity, or to
achieve a user selected balance of the two.
Using Ocelot is usually an entirely independent process that is intended to perform RF
optimization system wide on commercial networks. This process is complex and propagation
data, as well as traffic models and can process scanner measurement data. In spite of the
complexity in using Ocelot, Ocelot can be an essential tool during the Pre-Optimization
phase. It ensures a balanced network or cluster in advance and might minimize the amount
of drive testing required for the primary RF Optimization phase. For detailed information
please refer to the M&P documents on Global RF Methods and Procedures / Tool Support

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 19 of 89

3.4.

RFDriveTestBasedOptimization

3.4.1. Overview
RF Drive Test Based Optimization is the primary phase of the RF optimization and consists
of three stages encompassing the following activities:

Site Readiness
o

Spectrum Clearance

Antenna Audit

Sector Verification

Baseline Existing System

RF Optimization Planning
o

Perform Parameter Audit

Neighbor List Audit

Scrambling Code Plan Audit

Tool Readiness

Define Clusters

Drive Route Planning

RF Optimization Execution
o

Cluster Optimization

System Verification

RF Drive Test Based Optimization is in detail described by the M&P RF Optimization Using
Drive Tests Process. Also specifics of each task are provided by the individual M&P sub
layer documents. The following Chapters shall provide the RF engineer with the essential
steps and hints for performing the RF drive test optimization.
3.4.2. SiteReadiness
3.4.2.1. Overview

The Site Readiness procedures are health checks that ensure satisfactory performance of
cell sites. These health checks are mainly performed after deploying new networks or cell
sites and should be usually covered by the integration team, e.g. antenna audit or sector
verifications. In general it is not part of the RF optimization except when it is required by
contractual obligation.
There are specific situations that require heath checks to be performed even when not
required by the contractual obligation. For example base lining the existing network is
essential during the network swapout scenario. Specific network issues found during the RF
optimization might require spectrum clearance tests or individual cell site verifications tests.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 20 of 89

3.4.2.2. SpectrumClearanceVerification

The spectrum clearance assures that no external interference is present and sufficient guard
bands are obeyed. This task is only performed if requested by contractual obligation.
Spectrum audits might be essential for specific deployment markets or required at individual
troubleshooting scenarios.
Provided that guard bands matching the receivers selectivity have been used, adjacent
channel or inter operator interference can often be neglected during spectrum clearance
verification. The focus is usually on external interference deriving from different technologies
such as private radio, radar and faulty or unlicensed equipment, e.g. cordless telephones. In
addition, at shared antenna sites locally generated interference (e.g. intermodulation & crossmodulation e.g. due to insufficient guard bands) can be found, even when all the equipment
is compliant with the relevant standards. Indications of external interference can result into
high BLER or Tx power in either UL or DL at good coverage conditions or high (er) UL
interference levels at the NodeB.
The detection of interferences can be a very time consuming and a difficult task once the
UMTS system is up and running. It is desirable to have a very high degree of confidence that
the spectrum (downlink and uplink) is cleared prior to any commercial operation.
3.4.2.3. AntennaAudit

This phase ensures proper installation of the antenna system. This task is also only
performed if requested by contractual obligation or becomes required due to poor
performance results (e.g. alarms at the OMC-U, poor coverage and strong signal reflections).
The audit process consists of various antenna inspections regarding mounting height,
azimuth, antenna type, antenna tilts or cable inspections. Antenna audits are performed
exclusively by professional antenna crew teams.
There must be a high degree of confidence in proper antenna installation within the entire
network. If several antenna configuration faults (e.g. antenna tilts) are reported, an antenna
audit should be considered. A rule is to audit 10% of arbitrary cell sites within the entire
network. If these audits show satisfactory results, then further audits are only required for
individual cells sites that show indications of faulty antenna system.
It should also be considered that the actual antenna tilt (mainly electrical tilt) sometimes
differs from the one in the network database (planning tool or OMC-U). This results in
confusion if new tilt modifications are requested and ends up in sending the antenna teams
into the field several times. A possible wrong tilt implementation should always be taken into
account during network analysis or design review. In case there are doubts concerning
coverage versus implemented tilt, the antenna team should first check the current tilt and
then modify accordingly.
3.4.2.4. SectorVerification

This phase ensures proper functionality of a cell site(s) and is only performed by the RF
optimization team if requested by contractual obligation. Sector verification is required for
new cell deployments as well as if operational cells show poor coverage, mixed up SCs or
alarms at the OMC-U. It is intended to detect hardware or configuration errors prior to cluster
drive testing.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 21 of 89

Sector tests are usually part of the cell site deployment performed by the integration team. It
includes a set of function tests in order to verify that each sector is transmitting with the
appropriate performance and the correct scrambling code.
Function tests must include all cells are transmitting with reasonable scrambling code power
(RSCP of Primary CPICH) as well with the correct assigned SC. This can be done by
performing short drive tests around the cell site. It is also desirable to perform performance
tests such as call setup for CS (Voice/Video) and PS (FTP). Additional tests might be the
verification of voice quality, FTP throughput tests and intra cell handover tests.
The sector tests are performed using a measurement drive test system such as Couei XCAL,
Qualcomm CAIT3G, or Agilent Nitro systems including UMTS test terminals Basic functional
tests such as transmit power or SC verification can also be performed using a 3G scanner
(Agilent). It is important to use both a scanner & a test phone.
Usually all the functionalities are verified in the field, but drive test teams may collect the
data, which are then post-processed by the RF engineering team using Lucent LDAT3G or
Couei XCAP. If sector problems exist, appropriate actions need to be taken. The sector test
should be repeated until all tests succeed.
Note: It is common during network deployments that the Integration Team performs only a
voice test call from the site. In this case it needs to be decided by the project team weather
complete sector verification tests are required.
3.4.2.5. BaselineExistingSystem

The primary objective for the Baseline Existing System task is to collect and document Key
Performance Indicators (KPIs) of the existing system prior to any RF Optimization activity.
During the Swapout scenario, base lining should be a necessity. Base lining during common
RF optimization activities is not explicitly requested, but performance data are collected
during the first optimization drives that represent the existing systems performance. For
performance comparison purposes, it is important to keep the drive routes and metrics
identical. Drive routes and KPIs must be agreed upon with the customer.
3.4.3. OptimizationPlanning
3.4.3.1. Overview

The Optimization Planning phase emphasizes all tasks necessary to ensure readiness for RF
Optimization. Some tasks such as neighbor list validation or parameter audit might have
been completed during the pre-optimization phase and are thus not required in this phase.
Tasks such as drive route and cluster planning are essential to ensure high optimization
efficiency.
Prior to any network modification it has to be ensured the latest network configuration
database is complete and up to date, especially concerning design parameter such as an
antenna height, tilt and azimuths.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 22 of 89

3.4.3.2. PerformRFParameterAudit

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


consistency with the UMTS parameter catalogue. The parameter catalogues should be
provided by the customer (vendor dependent) and contain the network parameter definitions
including recommended (default) settings. In any case the RF parameter setting lists and
possible parameter model definitions used in the network should be obtained. At this
optimization stage all RF parameter are already assigned, for new parameter assignments
please refer also to Chapter 3.3.4.
The RF parameter audit mainly ensures that the correct parameter settings are used.
Random checks of RF parameter can uncover incorrect parameter assignments or incorrect
model definitions in the entire network. If the investigated parameters show high deviation
from the recommendation settings, then the customer should be informed. Any parameter
modification in order to improve network performance (e.g. IRAT parameters) should be
performed at a later step during the RF optimization.
The RF parameter audit can also provide the optimization engineer general views regarding
the network settings and its general behavior regarding network access (cell selection) or
handover conditions. This information can be very helpful during the network analysis later
on.
In case parameter-setting lists are unavailable in the beginning, important RF parameter can
also be verified within the system information blocks (SIB).
RF parameter settings and parameter models for Lucent deployed networks are obtained
either from the NDP Web Portal project database or directly from the OMC-U. The parameter
catalogue (ParCat) is also available on this web portal. Detailed descriptions of all RF
parameter including recommendation settings are provided by the Translation and
Application Notes.
3.4.3.3. NeighborListPlanAudit

A correct neighbor list is one of the most important demands for ensuring reliable network
performance. Missing neighbor relations would not only cause severe call failures (drop calls)
but extensive drive tests during RF drive test optimization, therefore neighbor list verification
prior to the drive testing is highly desired.
The complete neighbor list verification is a very time-consuming process. If it is not part of
contractual obligation, then an estimate of the extent of this verification shall be performed in
advance. Arbitrary neighbor relation checks can help to obtain an overview of the neighbor
list. These checks should be performed using tools like Lucent Airpro or LDAT3G. Also tools
such as MapInfo in combination with GoogleEarth can help assess the neighbor lists. More
information regarding neighbor planning are provided by Chapter 3.3.5. The neighbor list
checks should include:

Verification of consistency in implemented neighbor lists with neighbor list plan (RF
department).

Verification of the amount of neighbor relations (<15 per frequency and RAT).

Verification of the necessity of each relation (evaluate best server / signal plots in the
prediction tool, or verification by visualization using e.g. MapInfo and GoogleEarth).

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 23 of 89

Searching for any obvious missing neighbor relation (NB lists with entries of only 35).

Searching for any obvious neighbor relation that is not required. (NB lists with entries
of higher 28).

Consistency of neighbor plan with implementation.

If these arbitrary checks are satisfied and a correct neighbor plan implementation is
indicated, then the neighbor list verification is completed. Further verifications will be
performed during the RF drive test optimization. If the checks indicate a poor neighbor plan,
it must be decided if each neighbor list requires verification. Also the assignment of an entire
new neighbor plan can be considered.
The implemented neighbor lists can be verified in the OMC-U, in appropriate network
maintenance tools or even from the prediction tools if in sync with the OMC-U. For Lucent
UTRA deployed networks the neighbor lists can be obtained from either the NDP Web Portal
project database or directly from the OMC-U.
3.4.3.4. ScramblingCodePlanAudit

The scrambling code verification is a minor task and necessary for the RF drive test
optimization. This activity shall verify that a proper scrambling code plan is implemented.
Displaying the usages of single arbitrary chosen primary scrambling codes is one example in
verifying a meaningful code plan. If a poor code plan is observed, appropriate action must be
taken (address to RF department). The primary code planning is addressed in further detail
in Chapter 3.3.6.
A fast and very useful scrambling code plan check can be performed by using MapInfo.
Displaying each SC, SC reuse and distance easily can be assessed. For example Figure 7
below display the reuse of SC300 (red) and hence a conflict of the scrambling code plan
(reuse distance of SC300 too low).

SC300

Figure 7 Scrambling code reuse conflict


Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 24 of 89

3.4.4. ToolReadiness
Appropriate drive test tools and post-processing tools need to be prepared for optimization.
Tool types as well measurement procedures are defined in the scope of work (contractual
obligation). It is strongly recommended to perform test drives prior to any network
performance drive to verify the accuracy of the measurement tools. Faulty tool performance
and unusable measurement results can drastically increase the measurement time.
It is also essential to define an accurate tool setup that is approved by the customer. The tool
setup would include the following definitions:

Antenna types and antenna cables types if external car antenna are used

Positions of antennas, in car or roof top

Usage of attenuators

Network performance drives are performed within the network coverage area. The driving
routes are usually defined according the coverage plots, which are determined by the
prediction tool. The definitions of these prediction plots (e.g. in-car penetration factor) must
be considered for any comparisons with drive test measurement results. This is essential
when using in-car test mobiles and external car antennas for wide band scanner. The usage
of additional attenuators for the scanner antenna should be considered, but in general it is
recommended to use external antennas to obtain reliable measurement results. In any case
it is recommended to use fixed positions for the test mobile inside the car.
The aforementioned items are examples to demonstrate the importance of proper tool setup.
The tool setup must be completed prior to any network performance drive.
Another important matter to consider is the driving team. Usually 3rd party companies carry
out the drive tests. Those teams require extensive trainings on handling all utilized tools and
those teams should be familiar with troubleshooting common scenarios, e.g. FTP server is
down, no call possible, drive test system reboot etc. The lack of knowledge in regard to the
drive test system as well as UMTS principles can easily increase costs due to extensive redrives.
Tool types, setup and measurement methods are discussed in more detail in Chapter 4.2.
3.4.5. DefineClusters
3.4.5.1. Overview

When RF optimization is performed, the network is subdivided into regions for logistical
reasons. In each region, the cell sites are grouped into clusters. It is important to select the
correct cluster size as it impacts the resources and time-line for the optimization project. It is
also important to consider the availability of all cells as it is essential to optimize clusters with
all the cells operating.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 25 of 89

It is generally recommended to choose a 2-tier configuration with approximately 19 cell sites.


Actual cluster sizes may vary due to contractual agreements regarding desired region and
cluster size, as well as customer preferences regarding cell readiness and priority.
Cluster sizes are also dependent on the network scenario. Small networks or regions less
than 20 cell sites should be determined as a single cluster. Networks of 20 to 40 cell sites
should be divided into 1 to 3 clusters. For larger networks, each cluster should range in size
from 12 to 19 cell size.
Some examples of cluster definitions are provided in the following Chapters. Cluster
definition is especially important for the optimization of new network deployments.
3.4.5.2. ClusterDefinitionforNewNetworkDeployment

[New network deployment for an entire area, no existing optimized cell sites]
The actual number used is based on the network layout as well as the topographical
environment. The clusters are selected to provide a centre cell site with two rings of
surrounding cell sites as shown below in Figure 8. It is advisable to utilize natural barriers
such as hills, rivers, RNC borders, etc. for cluster separation to minimize overlap and
influence between the clusters. Some cell site overlap should remain between each cluster to
ensure seamless coverage across the boundaries. Special attention is required for the
border areas of the UMTS clusters. The border between two clusters should be as small as
possible to minimize the possible influence between the clusters. These cluster scenarios
can mainly be found in urban areas with large cell site deployments (>70 cell sites).

Cluster1

Cluster 2

Cluster 3

Figure 8 - Cluster Definition for New Deployments

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 26 of 89

water

3.4.5.3. ClusterDefinitionforaSmallNewDeployment

[No existing optimized cell sites and region might be border of existing optimized cell sites]
These cluster scenarios are mainly found in rural areas such as smaller cities or villages (cell
sites 1<>10). For the cluster definitions, the same rules are applicable. It is preferable to
define just one cluster in this area. Existing cell sites of the same RAT close to the cluster,
e.g. highway cell sites, should be included into the performance drives. If ISHO is supported,
driving routes must cover ISHO verification tests.
Existing
Border Cell Sites

Cluster X

Highway

Figure 9 - Cluster Definition New Deployment (region)


3.4.5.4. ClusterDefinitionforNetworkExpansion

[Deployment of one or more cell sites into area of existing (commercial) optimized cell sites]
These scenarios are mainly found in urban areas where one or more additional cell sites are
being added for coverage or capacity purposes. New cell sites are only grouped to one
cluster if they are connected to each other within 1st or 2nd cell tier. Figure 10 below is an
example where two new cell sites are integrated into a commercial network area. The cluster
shall include all cell sites of 1st and 2nd tier as well as all cell sites that might influence the
optimization work and hence the performance verification later on.

Cluster X
Figure 10 - Cluster Definition for network Expansion
3.4.5.5. ClusterDefinitionforIslandSiteDeployment

[New deployment of island cell site(s) into area of non-existing cell sites of same RAT]
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 27 of 89

These cluster scenarios are mainly found in rural areas for deployments such as in village or
on highway. Clusters are mainly aligned to the driving routes. Existing cell sites close to the
cluster should be included into the cluster drive, e.g. for highway cell sites. If ISHO is
supported, driving routes must cover ISHO verification tests.

Existing
Cell Site

Cluster
X

Highway
Figure 11 - Deployment of Island Cell Site
3.4.5.6. ClusterDefinitionforExistingNetwork

[Existing, commercial network]


RF optimization for an existing, commercial network might not require specific cluster
definitions. Clusters might be defined according optimization purposes (hot spot, customer
complaint areas), driving routes, contractual obligations and resources as well time-line. A
common scenario for urban areas may define clusters as north, west, south, east and center.
For smaller existing networks, clusters are defined according to regional or island
deployments.

C2

C1

C4
C3
Figure 12 - Cluster Definition for existing network, now new deployments

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 28 of 89

3.4.6. DriveRoutePlanning
Proper and thorough drive route planning is essential in order to gain high optimization
results and hence network performance improvements. Drive routes are defined according to
the contractual obligations, customer demands and network scenario. Driving routes for
network performance verifications should always be determined within the service coverage
of the network utilizing coverage prediction plots or signal strength surveys.
It is recommended to plan all driving routes with appropriate visualization tools similar to
MapInfo. After determining the routes, drive route data are imported into the navigation
system used by the drive test vehicles. The drive route planning is a very time consuming
process and should not be underestimated.
Driving routes are classified according to its objectives and can be classified as verification
routes, optimization routes, border routes, system verification routes, outer coverage routes
and cluster border routes, refer to Figure 13. The drive route for a typical cluster should not
exceed 6 hours. Longer routes (e.g. for optimization purposes) are driven over the course of
two or more days, based on a 6-hour drive per day.

Underlying System
Cell Sites

C1
C2
C3

Water

Optimization Route
Verification Route

Outer Coverage Route

System Verification Route

Cluster Border Route

Figure 13 - Types of Driving Routes

Verification Drive Route

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 29 of 89

Verification routes are defined for cluster performance verification. These drives are used to
demonstrate reliable network performance in order to obtain customer approval for RF
optimization completion. Verification routes must have customer approval.
The routes for cluster verification should consist of major roads, highways, bridges and
hotspots, but the customer determines actual routes. The lengths of the routes are also
dependent on the number of required samples per verification test (e.g. number of voice
calls). If the clusters are too small for efficient drive tests, then a few stationary tests might be
considered.

System Verification Route

System routes are verification routes that are defined for global network performance
verifications and include usually several clusters. Similar planning aspects are applicable for
the verification routes and are planned according to contractual obligations.

Optimization Route

Optimization Routes are individually defined by the RF optimization team and are determined
according optimization objectives. Extensive drive tests are required for neighbor list or
coverage verifications (scanner analyses). Problem areas showing high failures rates or pilot
pollution require special investigations and individual drive tests. An optimization route does
not require customer approval.
Optimization routes are required for large clusters sizes (urban areas) in particular. Smaller
clusters have optimization routes that are usually identical with the verification routes.

Cluster Border Route

Additional border routes are chosen to verify existing overlapping cluster regions. A border
route is chosen by the way it crosses the cluster borders. Border drives are mainly used for
neighbor relation verifications. Border verification drives may be required depending on
contractual obligations and must have customer approval.
Cluster border routes are found in new network deployments consisting of several clusters.
During optimization of existing commercial networks cluster border routes are usually
included in the optimization drives.

Outer Coverage Route

The Customer may request a drive route in an area outside of the designed coverage area to
determine the extent of coverage in these areas or to verify seamless inter system handover
to the underlying network. Major roads or highways are generally chosen for these routes
and these routes should not be included in verification routes (exit drives). Outer coverage
routes may be required for smaller network deployments in rural areas. Outer coverage
routes are used in addition for inter system Handover verifications.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 30 of 89

3.5.

RFOptimizationExecution

3.5.1. Overview
The RF Optimization Execution consists of optimization drives, problem area identification
and clearance, and finally verification drives to ensure completion of Exit Criteria (see
chapter 6).
The primary activities are to provide system tuning, 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.
The quality and performance of a network depends on the actual load in the system.
Unloaded network conditions can skew acceptance tests, since there is less interference
present. If traffic increases and the load rise, the network performance will be diminished and
previous acceptance tests become invalid. The performance should always be verified and
modified under loaded conditions for new network or cell site(s) deployments.
Optimizing the system in manageable sized clusters is beneficial for several reasons.
Smaller cell numbers make it easier to focus on optimized areas. Smaller cell numbers make
it easier to track the parameter changes and the impact on 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. Additionally, smaller cluster optimization aids in speeding up system tests for
commercial operation. Optimization in equipped clusters can proceed simultaneously with
installation of other clusters.
System Verification is the final phase of the RF Drive Test Based Optimization activity and it
focuses specifically on collecting overall performance statistics for customer acceptance
approval. System Verification will begin after all clusters in the UMTS network have been
tested.
3.5.2. ClusterOptimization
3.5.2.1. ClusterOptimizationforNewNetworkDeployments

Cluster optimization should be performed on fully deployed network sections. This avoids retesting of previously optimized clusters in case the cell sites are integrated later. All cell sites
in the network (or a network section) are switched on. It is recommended to test each cluster
under unloaded and loaded (e.g. OCNS) conditions. If live traffic already exists, unloaded
tests should be performed during the non-peaks hours, while a combination artificial load
(OCNS) & live traffic can be utilized for loaded tests.
Optimization teams working on multiple cluster testing must coordinate activities especially
regarding neighbor relations, loading conditions or excessive coverage cells. 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
should be performed under loaded conditions in order to verify and confirm the Exit Criteria
at the borders of the clusters.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 31 of 89

Verification drives in areas outside of the designed coverage area (outside the clusters) may
be required to mitigate excessive coverage and scattered coverage footprints. Verification of
seamless service coverage by inter system handovers is required for overlay networks.
For each drive test an analysis is performed including failure analysis, Key Performance
Indicator verification as well individual network investigations regarding optimization aspects.
Appropriate reports must be produced according to customer requirements. The reports must
be clear and concise since each network modification requires customer approval. In addition
it is essential to carefully track any recommendations for network modifications and its
implementation status.
The required data collection, processing and analysis tools for Cluster Optimization are a
phone-based data collection tool kit including e.g. XCAL, CAIT3G, UMTS terminal(s) as well
as post-processing tools like XCAP, or LDAT3G. In addition to the phone-based tool kit, a
scanner-based tool Agilent is used for power measurements on the physical UMTS
channels. The scanner is an important tool because it is capable of multiple pilot
measurements. This is useful depth coverage analysis (e.g. pilot pollution, missing
neighbors) in challenging RF environments (e.g. large water-bodies, bridges, un-even terrain,
etc.).
The cluster optimization for new network deployments consists of three phases:

Unloaded Cluster Optimization

During this first phase, a measurement drive is performed under unloaded network
conditions using the optimization route. Verification drives at the beginning for performance
comparison reasons (base lining) are not usually required for new network deployments.
Once the data from the first phase are collected, problem spots are identified and optimized.
The unloaded drive test shall identify missing neighbor relations and overshooting cells. The
first pass might lead to correction of neighbor lists and adjustments of the fundamental RF
parameters such as transmit powers, antenna azimuths, and antenna tilts. The drive test
information highlights fundamental flaws in the RF design under best-case conditions. For
large cell site deployments in urban areas it is recommended to perform a scanner analysis
to clean up the network coverage by mitigating overshooting cells.

Loaded Cluster Optimization

The second phase is performed under loaded conditions. The drive routes are exactly the
same routes as those used for the unloaded measurement drives. Loaded testing produces a
rise in the noise floor, which has the effect of shrinking the coverage area (cell breathing).
This may results in higher BLER, lower mobility throughput, and more call failures.
The major focus of loaded tests is to fix problems such as pilot pollution or around the corner
effects by fine-tuning the RF parameters such as the transmit power or handover
parameters. Antenna re-adjustments (e.g. down-tilts, azimuths, patterns/types or heights) are
occasionally performed.
Problem areas are normally re-driven after implementing changes. If the problem cannot be
resolved after a certain amount of time, then a root cause analysis is performed. It is
generally not recommended to attempt resolution of complex time-intensive performance
issues. For such problems, it is advisable to report the behaviour and proceed with the next
cluster.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 32 of 89

Cluster Performance Verification

The cluster performance is verified in the third phase. The primary objective of this
verification drive, also called exit drive, is to confirm specific Exit Criteria demanded by the
customer.
In general Optimization routes can be utilized for the verification drives after customer
approval. This is applicable for smaller network deployments with less extensive clusters.
The final report from the verification drive is presented to the customer for approval.
Contractual obligations define the contents of the report. The reports usually contain the
analysis of remaining network failures, coverage plots based on scanner data and tables of
KPIs.
Measurement statistics from out of coverage areas (coverage holes) should not be
considered part of the performance test results. This data should be manually removed from
the KPIs unless Inter System Handovers are desired and are part of the performance tests.
Out of coverage areas should explicitly addressed to the customer.
The approval to exit the cluster is based on the terms of the contract. If the cluster is not
approved, loaded cluster optimization must be continued until the troubles are resolved. A
report specifying the reasons the verification drive did not pass the Exit Criteria is required.
Exit criteria, optimization aspects, as well as tools utilized during cluster optimization will be
addressed later in this document. For specific troubleshooting scenarios such as for call
setup failures, drop calls for both CS and PS, refer to the <UMTS RF Performance Analysis
and Troubleshooting Guideline>.
3.5.2.2. ClusterOptimizationforNetworksdifferenttoNewNetworkDeployments

The previously described cluster optimization procedures for new network deployments are
applicable for all network scenario types. Small variations for other network scenarios shall
be addressed in this Chapter.

Cluster Optimization for a Small New Deployment

Small new deployments are found in rural areas with no overlap to border cell clusters.
Therefore more attention is required on outer coverage drives to ensure smooth inter system
handovers. The coverage extension needs to be verified, scattered coverage should be
mitigated to provide sharp coverage borders between UMTS and e.g. GSM. Intra system
handover to cells close to the new deployment cluster (e.g. highway cells) need to be
considered for performance verification. The cluster areas are usually not large. Therefore
for cluster optimization and verification the same routes are used.
Performance data collected in out of coverage areas are usually excluded from the
performance verification during the exit drives, depends on contractual obligations. This
applies for performance data such as PS data and CS Video data. CS voice performance
data are usually used to demonstrate reliable inter system handovers.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 33 of 89

Cluster Optimization for Network Expansion

The focus for optimizing new cell sites deployed into existing cell site clusters is on neighbor
lists and coverage footprints. Reliable network performance of both, the new deployed cell
site(s) and the existing commercial cell sites in the vicinity must be ensured.

Cluster Optimization for Island Site Deployment

Please refer to Cluster Optimization for a Small New Deployment.

Cluster Optimization for Existing Network

The optimization activities for existing commercial networks require base lining. The first
verification drive is used for the performance starting point. After the optimization is
completed the cluster performance can be compared with the starting point to demonstrate
improvements.
The procedures used for optimizing existing networks are similar to cluster optimization for
new network deployments. Variations in the procedures are:

Base lining the existing system prior to any optimization activity is required.

Tests are performed under live traffic since network is commercial. (Peak hour may
need to be considered).
An extensive optimization drive is recommended to perform deep scanner analysis.
The network should be cleaned up regarding excessive cell coverage and pilot
pollution.
3.5.3. SystemVerification
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 will begin
after all clusters in the UMTS network have been tested, and are performed under loaded
conditions with all cells activated. System verification involves fusion of the previously
optimized clusters and is required to demonstrate that Exit Criteria are met system-wide. The
exact system test requirements are defined in the customer contract.
The system verification route covers major highways and primary roads in the defined
coverage area. The focus is on the problem areas identified during cluster optimization. The
procedures and analysis are identical to those used in cluster performance verification. It is
possible for problem areas to remain after System Verification is completed, such as a
coverage hole that will be fixed by a future cell site addition. These items should be well
documented with solutions agreed upon by the customer.
The final statistics from the System Verification are presented to the customer for approval.
The RF Optimization procedure is considered completed at the end of the system-wide drive
test. The UMTS network is ready for live traffic testing, which will lead into commercial
service (in case of a new network deployment). Once significant loading with live traffic is
present on the 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 model with a simulated traffic loading.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 34 of 89

4
4. RFOptimizationTools
4.1.

General

The tools used for RF Optimization can be classified into data collection tools, data analysis
tools, optimization UTRAN network features and data application tools.
Figure 14 below dislpays an overview of tool classification in the field.

Analysis Tool
(Post-processing)
tool)
Network
Performance Data
(Network Counter)

Field Measurement
Collection Tool
&
Data Application
Tools (WINDS)

RNC

GPS

UMTS Core

UE(s)
UMTS
Scanner
Node B

Drive Test
Log File

Analysis Tool
(Post-processing)
tool)

Figure 14 Drive Test Based Tool Classification


Detailed information about tools and components are found under:
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 35 of 89

UTRAN Optimization
Features
(OCNS, RF Call Trace)

RF Tools Lab (Hardware, toolkits)

Global RF Core Support Homepage (Optimization tools and software)

Navigator Portal (Lucents tool portal)

Detailed description for set-up and handling tools utilized by Lucents personnel are provided
by several individual documents available on the M&P portal.

4.2.

DriveTestBasedOptimizationTools

This Chapter shall provide an overview of the different tool types used for RF drive test
optimization. For detailed tool descriptions, refer to the corresponding tool portals.
Field measurement tools can be classified into:

Measurement Collection Tools

Measurement Scanner Tools

UMTS Test Terminals

RF Drive Test Kit

Measurement Collection Tools are diagnostic driving and collection tools. They log and
analyze using real time displays both UL/DL air interface messages (Layer 1-3) and DL
performance measurements (e.g. DL BLER) from UMTS test terminals (UEs). Air interface
messages and performance data are collected by test mobiles. Several test mobiles can be
used in combination with the measurement tools, e.g. one mobile for each service, PS FTP
(R99 / HSDPA), CS VIDEO, and CS VOICE.
The collection tools should provide the following key features:

Support efficient number of UE interfaces

Support L1-L3 messages as well as all types of log parameters

Simultaneous measurement of voice/data

Supports auto call and all call types

Support of a scanning receiver

Some of the common measurement collection tools are:

Agilent E6474A (Nitro)

Couei (X-CAL-W)

SwissQual

Qualcomm (CAIT3G)

Focus Infocom (3GMA)

Ascom Qvoice

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 36 of 89

Measurement collection tools are usually entire optimization platforms consisting of both the
measurement collection software tool and the analyzing software tool for post-processing.
Optimization platforms as from Ascom, Focus, Couei and SwissQual consist of a stationary
tests system in addition to the mobile drive test system, allowing auto voice calls in both
directions (mobile originated and mobile terminated calls). Audio files are exchanged
between the mobile and stationary system, proving an evaluation of the voice quality based
on Mean Opinion Score (MOS) [EG ITU-T 862 / 862.1]. However, usually the mobile drive
test system platform is in general efficient for basic RF optimization.
Scanner Measurement Tools measure the UMTS physical layer. The system performs
absolute and relative channel power measurements of the Primary Synchronization Channel
(PSCH), Secondary Synchronization Channel (SSCH) and the Primary Common Pilot
Channel (P-CPICH). These three channel measurements can be performed simultaneously
for multiple scrambling codes. Dual and tri band scanners are able to perform similar power
measurements on the GSM DCS or PCS bands. The UMTS and/or GSM channel power
measurements are executed without using a UMTS/GSM terminal and hence SIM cards.
Required key measurement capabilities are:

Scrambling Code Power Ec and Ec/Io (CPICH)

Scrambling Code Group and Scrambling Code Number

RSSI (Io)

Power measurements on GSM, DCS or PCS channels

Scanner measurement tools are used for pilot coverage surveys to analyze pilot coverage,
best server and pilot pollution, and to identify missing neighbors and non-UMTS interference.
Some of the common scanner manufactures are Agilent, DTI/PCtel, Panasonic, and Anritsu.
The customer or contractual obligations specify UMTS Test Terminal types used during the
RF Optimization. Terminals are considered by their commercial availability, compatibly to the
measurement collection tools, and area of application (e.g. HSDPA, dual mode operation,
Video). Utilized UMTS test terminals should also have the availability of charging during
operation and should support external car roof antennas.
Readers should note that the at this relatively early stage in UMTS UE development, the
performance of the UEs has been found to vary considerably. Consequently the type of UE
used for the measurements can have a significant effect on the results that are obtained. It is
recommended that wherever possible a range of different UEs should be available, and their
performance compared. Before using the UEs for drive testing, static measurements in good
RF conditions should be performed in order to confirm that under ideal conditions, the UE is
providing good results.
Some of the common test terminals are:

Samsung Test Mobile SGH-Z series

Qualcomm TM6200 series

Motorola Test Mobile

Novatel Merlin TU520B (data card)

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 37 of 89

Required RF Optimization equipment for Lucent personnel will be shipped as RF Tool Kits.
Each RF tool kit includes all the equipment needed to fit out one vehicle. show examples of
such a RF Tool Kits.
The tool kit may include a scanner based measurement system (e.g. Agilent) and a phone
based measurement system (e.g. CAIT3G) including supplementary devices.
The drive test kit is usually equipped with the following components:

Measurement Collection Software

Measurement Scanner Tools

UMTS Test Terminals

Laptop for for data recording)

Separate Attenuation boxes for uplink and downlink (used to compensate for vehicle
penetration loss and for introducing simulated uplink load)

Test mobile isolation box to provide RF isolation

GPS unit

Power supply power box for toolkit components

External car roof antenna

Figure 15 RF Tool Kits

Attenuators are used to simulate indoor/in-car conditions of a phone. The attenuation box of
the RF tool kit provides two attenuators, one in the transmit path and one in the receive path.
Uplink and downlink attenuation is added to compensate / simulate cable losses, external
mobile antenna gain or penetration losses. Additional uplink attenuation may be added to
simulate uplink loading.
Analyses Tools can be classified into:
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 38 of 89

Analysis Tools

Supplementary Tools

Analysis Tools are used to post process the drive test data to aid in performance analysis
by providing several metrics. Consequently the tools help to evaluate and determine the low
performance areas in a UMTS network.
Support of Key Features:

Geographical mapping

Time series plots

Histograms

Air Interface Message Window

Support of Log Parameter:

Layer 1 Information (CPICH RSCP, CPICH Ec/No, RSSI, UE Tx power,


Searcher Ec/No, SIR, UL/DL Power Control Information, etc)

Layer 2 Information (BLER, Transport CH Information, RLC Throughput, etc)

Layer 3 Information (RRC Signaling Messages, RRC state, etc.)

Layer 1-3 Information for GSM/DSC/PCS if dual mode test mobiles are used

NAS Layer Information (RRC Signaling Messages, RRC State, NAS Messages,
GMM, MM, REG State, etc.)

FTP/PPP Information (FTP Throughput, PPP&TCP/IP Messages, etc)

Scanner Information (RSCP, Ec/No, physical channel measurements on


GSM/DCS/PSC if dual/tri band scanner is used, etc)

Call statistics (Call/Session Drop Rate, Call/PPP Context Setup Failure Rate,
etc)

Some of the common analysis tools are:

Lucent Technologies (LDAT 3G)

Couei (X-CAP-W)

SwissQual (NQDI)

Focus Infocom (3GMA)

In addition to the analysis s/w available from the manufacturers of the collection tools,
Lucents LDAT3g analysis s/w can used to analyze the data recorded by in combination with
the measurement collection tools from Agilent Nitro and or Qualcomm CAIT3G.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 39 of 89

4.3. ServiceMeasurementBasedOptimization
Tools
Service measurement tools must be utilized during the Service Measurement Based
Optimization. These tools are used primary after network launch when live traffic exists.
Network performance counters are installed at the OMC-U in order to collect network
performance data (KPIs). Appropriate post-processing tools are used to evaluate these
performance data. Such tools, like Lucents SPAT3G / LUNAR are used to generate service
measurement metrics based on the data received from the OMC-U. Thus, a rapid
identification of trouble spots is ensured.
SPAT3G (System Performance Analysis Tool) and LUNAR (Lucent Network Analysis
Reality) for 3G networks are Windows-based PC tool used to troubleshoot and analyze the
performance of a live network using data sources including Service Measurements, Per Call
Measurement Data (PCMD), ROP, Translations, Neighbor list data (Handoff Matrix,
Undeclared Neighbor List). Focus is radio access network (RA
Analysis reports in SPAT3G/LUNAR are:

Root cause analysis of drop calls and access failures by correlating PCMD data with
configuration data

Geographical maps of estimated locations of drop calls and access failures by correlating
PCMD data and cells locations information

Expedited analysis of group of cells by creating subsets by correlating configuration data


with service measurements data

Optimization of configuration parameters by comparing and flagging existing parameter


settings against Lucent or service provider recommended values as well as based on
pre-defined rules

Optimization of neighbor lists by correlating Handoff Matrix data and Undeclared


Neighbor List data with configuration and cells location information

Optimization of inter-frequency handoff performance and drop call rate by correlating


directed handoff parameters with Handoff Matrix data and cells location information

High runner cells/sectors root cause analysis reports correlating Service Measurements,
PCMD, Configuration, and Fault Management data

4.4.

SupplementaryTools

Supplementary Tools are helpful or required during the optimization process.

WIND is an UDP-based application that acts as a constant configurable data source and
receiver. The key characteristic of the User Datagram Protocol (UDP) is that retransmissions
on the user protocol are not performed. Use of these UDP test data transfers is preferred to
test and characterize the air interface performance.
WINDS runs on a Server connected to the fixed (core) network, and will communicate with
any number of WINDS applications installed on wireless terminals.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 40 of 89

An extension of the LDAT3G post-processing tool is the ability to read and process WINDS
log files. LDAT3G will be able to plot application layer statistics such as throughput and
packet error rate. This may be used to troubleshoot application layer performance problems
through correlating these application layer plots with Layer 1 to 3 plots and events.
MapInfo is used in parallel with the analysis tools. MapInfo is a very effective tool that can
help to assess the network performance with regard to the network design by using scanner
measurement data.
The Key Procedures are:

Display of topographical maps (e.g. street maps using plug-in MapInTheBox)

Display of Cell Database (export from planning tool)

Display of Scanner Measurement Data

This enables investigations into the network excessive cell coverage, pilot pollution,
scrambling code plan, neighbor lists, coverage holes, etc. Figure 16 below shows an
example of a MapInfo plot.

Figure 16 - MapInfo Plot Example


GoogleEarth is a Internet tool displaying detailed satellite images of urban areas. This
efficient tool is used to perform network investigations regarding terrain conditions. It helps to
judge on excessive cell coverage and neighbor relations.
GoogleEarth can be used together with MapInfo. MapInfo version 8.0 is required. A special
plug-in provided by GoogleEarth allows MapInfo to export the cell data information to
GoogleEarth. Figure 17 on the next page shows an example of a GoogleEarth output.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 41 of 89

Figure 17 - GoogleEarth with cell data from MapInfo

UTRAN Optimization Features are:

OCNS

RF Call Trace

The Orthogonal Channel Noise Simulator (OCNS) is a feature of Lucents UTRAN to


simulate live traffic in the network in order to test the system performance, and only applies
to the DL. OCNS is primarily used to test network capacity and to verify performance
parameters of the network. This is particularly necessary in the optimization phase after
deployment, when the network is initially installed, where cluster testing and complete
system wide testing is required.
For more details about simulated download refer to Translation Application Note OCNS.
Uplink loading can be simulated by implementation of attenuators at the mobile (UE) in the
uplink path. The attenuation must be equivalent to the noise rise (cell load) specified in the
link budgets and agreed upon by the customer. For example, 5dB attenuation should be
employed in the uplink to correspond to 68% uplink loading. The exact attenuation used is
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 42 of 89

given in the ATP (Acceptance Test Plan) that is written by SAE (System & Architecture
Engineering).
The RF Call Trace capability is a feature of Lucents UTRAN, which allows the operator to
gather radio related information associated to one or more UEs within the cells. This data is
principally derived from uplink measurements by the Node-B, but can also include downlink
measurements that are performed by the UE, and subsequently reported in the uplink. The
extent of this data is dependent on capabilities of the UE.
RF Call Trace should be used sparsely and with extreme care, as its activation can alter the
performance of the network and measurement UEs.
The data and information collected is used by the network operator to manage and support:

Network optimization

Performance Troubleshooting (RF as well as data performance)

Warranty and exit criteria for customer contracts

The tracing functionality within the RNC is performed by the collection of signaling messages
on the Uu, Iub and Iu interfaces. RF Call Trace logging files can be analyzed by LDAT3G.
LDAT3G can correlate RF Call Trace data with measurement drive test data (if compatible
drive test data collection s/w is used).
For more details about simulated download refer to Translation Application Note RFCT

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 43 of 89

5
5. ApplicationTestsforNetwork
PerformanceVerification
5.1.

General

An UMTS system requires various data and voice tests to verify network performance. It is
always preferable to perform these tests under loaded conditions, having either artificial load
or live traffic conditions. This Chapter discusses the generics of the different applications.
Refer also to UMTS Performance Expectations.
The majority of application tests are performed automatically by the measurement system
tools, e.g. auto Voice Calls and auto Data (FTP) Sessions. It should be ensured that network
elements dont have an impact on the performance of the application tests. FTP server/LAN,
or ISDN lines must not be the limitation factor regarding latency, throughput or quality. The
primary applications tests currently used for network performance verifications during RF
optimization are displayed by Figure 18 below.

CS Voice Calls
CS Video Calls
Application Test

PS Data Sessions
HSDPA Sessions

Figure 18 - Primary Application Tests

Additional specific tests may be performed in to verify the UTRAN performance, depending
on the contractual obligations. These tests may include latency tests (using ping application
scripts) or air interface performance tests utilizing the UDP application protocol (WINDS tool).
Application tests and measurement procedures for Lucent UTRAN deployed networks will be
obtained from the ATP (Acceptance Test Plan) that is committed by SAE (System &
Architecture Engineering). For non Lucent UTRAN equipment the application tests are
determined by the contractual obligations.
Quality of service parameters and their computations based on field measurements and
made from customers point of view is in detail addressed by ETSI TS 102 250-2 V1.3.1
(2005-07).
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 44 of 89

below displays a typical configuration scenario for running application tests.

The Drive test kit consists usually of two Laptops, each running two applications
in parallel (e.g. FTP and VOICE 3G, CS VIDEO and VOICE 2G or 3G single
mode). All applications run automatically. The VIDEO application may need to be
performed manually.

Counterpart (i.e. fixed test equipment connected by cable to the network) for the
PS data application is a FTP server is available via IP network.

Counterpart for the Video application is a stationary team. MTC and MOC calls
as well as video quality verifications (visual & audio/video sync) can be
performed.

Counterpart for the Voice application(s) are either:


o

A stationary team (MTC calls are performed manual)

A auto answering test number (only MTC calls can be performed)

A measurement system (automated MTC and MOC calls, Voice quality is


verified based Mean Opinion Scare [EG ITU-T 862, 862.1)

Figure 19 - Test application Scenario

5.2.

CSVoiceCall

Voice measurement tests are based on Mobile Originated Calls (MOC) and Mobile
Terminated Calls (MTC). Primary targets are the network performance regarding call setup
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 45 of 89

success rate and call completion rate. Voice calls are automatically executed by the drive
test systems. Call duration and idle times need to be chosen carefully to avoid call failures
due to overlapping of mobile originated and mobile terminated calls, and sufficient idle time
must be allowed for UE Registration & Location Update procedures.
The Voice Quality is measured by several drive test systems based on Mean Opinion Score
(MOS) standardized by EG ITU-T 862 and 862.1. The Voice Quality Testing (VQT) utilizes
several industry standard ITU algorithms in order to measure the speech quality of a
transmitted voice file. VQT compares the original unprocessed signal with the degraded
version (Figure 20).

Figure 20 - Voice Quality Test Specification


PESQ result is PESQ-LQ. PESQ-LQ scores are closer to the listening quality subjective
opinion scale, which is standard in the industry and is defined in ITU-T P.800. Listening
quality scores lie between 1 and 4.5. PESQ-LQ score lie between 1.0 and 4.5. This is
because 4.5 is usually the maximum obtained in a subjective test.
The score gives a measure of customers' perception of quality. The highest score (4.5)
means that no distortion is measured. As the amount of distortion increases the quality falls.
It is recommended to run two voice applications for overlay network scenarios. One mobile is
configured in dual mode, performs 3G / 2G voice calls (ISHO enabled). The second mobile is
alternate configured as 2G or 3G only. This method gives the opportunity to verify the single
networks more efficiently since an ISHO in weak coverage areas is disabled.

5.3.

CSVideoCall

Video calls are performed similarly to the Voice calls. The application runs automatically, but
the MTC calls need to be performed manually. The Video quality is currently measured
manually by visual assessment.

5.4.

PSDataSessions

For PS data sessions, FTP transfers are normally used by performing simple down - and
upload of data files (alternatively the WINDS tool can be used).
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 46 of 89

Essential for any FTP-based testing is the correct setting of TCP and PPP parameters at the
laptop. In addition to the appropriate permissions at the FTP server, another prerequisite for
FTP testing is to have several data files available at the network side for downloads, as well
as at the laptop for uploads. On the server side a file of around 10Mbytes should be
prepared. On the laptop, a file of around 1Mbytes should be prepared in a similar manner.
While 10MB and 1MB files cover most drive testing needs during optimization, in practice it is
often convenient to prepare a series of files on both sides with different sizes, i.e. 1MB, 3MB,
10MB and 30MB on the server side, and 100kB, 300kB, 1MB and 3MB on the terminal side.
As a rule of thumb, the file size should be chosen in such a manner that downloads last at
least one minute but not more than five minutes.

5.5.

HSDPASessions

HSDPA sessions are similarly performed as the PS data sessions. The HSDPA feature
needs to be supported by the test mobiles and the UTRAN. Higher data rates need to be
enabled in the test mobile (U-SIM).

5.6.

ExampleofTestScenario.

Test Case Example Circuit Switched Voice


RF Toolkit Configuration: three User Equipment (UE) + Scanner

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 47 of 89

Figure 21 below shows a possible test configuration in detail.

Figure 21 Test Configuration

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 48 of 89

6
6. UMTSPerformanceMetrics
6.1.

General

Specific quality and performance criteria within a UMTS network are assessed by certain
measures and events. Such assessments that may be used as a general health check on a
network or in warranty situations where it is important to ascertain whether the deployed
network is achieving a level of performance consistent with customer design requirements.
These specific measures and events are performance metrics that are composed of a series
of quality indicators. Since there is a large amount of quality indicators used for function and
performance tests, a subset of key indicators is chosen that best can represent the quality
and performance of a UMTS network. These Key Performance Indicators (KPIs) are utilized
for RF Optimization.
The exact warranty targets, also called Exit Criteria used in the RF Optimization are
customer and market specific. It is expected that values will be defined based on the design
criteria for the market prior to the actual RF Optimization. For this reason, specific Exit
Criteria cannot be provided in this guideline. Final acceptance values and precise
measurement procedures for Lucent UTRAN deployed networks will be obtained from the
ATP (Acceptance Test Plan) that is written by SAE (System & Architecture Engineering).
The following Chapter describes the Key Performance Indicators, the associated methods of
measurement and warranty targets generally used during the optimization process of both
voice and data. Metrics vary depending on the contract and additional unlisted metrics may
be necessary.
The network performance is in general verified by the following factors:

Call Availability (i.e. successful Set-up of the Call)

Call Reliability (i.e. Successful Maintenance of the Call as opposed to Dropped Call)

Call Quality

Call Mobility

A Call refers to both Circuit Switched Calls and Packet Switched Calls (Sessions).
Each of the classes listed above can be measured by specific KPIs as following:

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 49 of 89

Call Availability: Successful Radio Resource Control (RRC) Connections


Establishment Rate, Dropped RRC Connections Rate and Total Radio Access
Bearer (RAB) Establishment Success Rate.

Call Reliability: Total RAB Dropping Rate.

Call Quality: Uplink and Downlink Block Error Rate (BLER).

Call Mobility: Intra and Inter RNC Soft Handover Success Rate, Relocation
Preparation (for UMTS to GSM HO) and UMTS to GSM Handover Success
Rate, Location Area (LA) Update Success Rate, and Routing Area (RA) Update
Success Rate.

This Chapter will address the general usage of Key Performance Metrics during RF
optimization. The UMTS Performance Metrics are in detail described by the <UMTS RF
Performance Analysis and Troubleshooting Guideline>. A summary of Performance Metrics
currently utilized for RF optimization is given below. For each one a target (Exit criteria) is
set.
Voice:

Drop Call Rate

Call Success Rate (originations and terminations)

Voice Quality

Data Session Success Rate

Data Session Drop Rate

Data:

6.2.

CollectingKeyPerformanceData

Key performance data needs to be collected during drive tests so they can be evaluated
against Exit Criteria. Final acceptance drives are usually conducted on a per-cluster basis
and on a per-system basis and are referred to as cluster exit drive and system exit drive
respectively.
The performance data should be collected within the design coverage area that is agreed
upon by with the customer. The design coverage area consists of those locations where
coverage exists as determined and provided by the design prediction. Coverage plots for the
clusters and the system shall be available prior to any test drive. In-building coverage via
external UMTS infrastructure shall not be tested as part of acceptance; however, any
building penetration margins specified in the design (i.e., in the link budget) may be verified
at the street level by adjusting the attenuation in the test van setup.
For purposes of data collection and analysis the routes shall be divided into spatial
subdivisions called geographic bins. Bin sizes shall be agreed upon with the customer.
During data collection test routes shall be driven or sampled at speeds agreed with the
customer to be representative for subscriber behaviour.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 50 of 89

6.3.

KeyPerformanceIndicators

This section presents examples of major KPIs for Voice and Data used during RF
optimization. They are applicable for both Packet Switched (PS) and Circuit Switched (CS)
services. As mentioned before, the UMTS Performance Metrics are in detail described by the
<UMTS RF Performance Analysis and Troubleshooting Guideline>, precise measurement
procedures will be obtained from the ATP (Acceptance Test Plan).
Drop Call (CS Voice and PS Data)
The drop call rate shall be the ratio of drop calls to the total number of calls that entered a
connected state.
Total RAB Drop Rate =

100 * (NumRABDrop.sum)
(Total Number of RAB Attempts - Total Number of RAB Establishment

Failures)

For acceptance the drop call rate shall be x% or less. (Common value is 2%)

Call Success Rate (CS Voice and PS Data)


The all Success Rate for call originations and terminations are defined as follows.
Call Success Rate =

Successful Originations + Termination


Attempted Originations + Termination *100

For acceptance the origination success rate shall meet or exceed x%. (Common value is
95%)

Voice Quality
Refer to Chapter 5.2.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 51 of 89

7
7. UMTSRFParameters
7.1.

General

RF Optimization may require the adjustment of various RF parameters. Some of those have
complex interactions with one another affecting the system in terms of coverage, capacity
and call quality. Therefore, it is important to prioritize the parameters depending on their
ability to improve performance with minimal complexity and trade-offs.
Some of parameters require frequent tuning depending on the local RF environment and
thus have variable final values. Certain parameters need very infrequent adjustments to
influence performance on a system wide basis.
Regarding their tuning occurrence the RF parameters can be classified into three classes.
The three classes are Primary, Secondary and Fixed parameters.
The fixed parameters are not discussed here. The primary and secondary parameters are
generally specified by 3GPP (3GPP TS 25.331). The individual operator may use additional
parameters for RF Optimization.
It is important to be familiar with the UMTS algorithms specified in 3GPP, e.g. for Handover,
Cell Selection / Re-Selection, InterRAT. These algorithms are not discussed in this
document. Refer also to Lucents Translation and Application Notes, where UMTS algorithms
are discussed in detail.
Primary Parameters
These parameters may require frequent adjustments, often from one cell site to another.
These include:

Neighbor Lists

Antenna Parameter (antenna tilt, azimuth, height and type)

Pilot Channel Power

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 52 of 89

Secondary Parameters
The secondary parameters can be used for further fine-tuning, especially in specific problem
areas and includes:

Handover parameters (inter + intra InterRAT)

Access parameters

Cell Selection / Re-selection parameters

HSDPA parameters

Fixed Parameters
The fixed parameters are not typically adjusted during the RF Optimization. Changing those
parameters can create complex interactions in key system performance such as coverage,
capacity, voice quality, data throughput, etc. The impact is not easily characterized or
predictable, and can vary from network to network or within a network. These parameters
should be adjusted only after consulting the subject matter experts, e.g. system engineering
(SAE). These parameters include:

7.2.

Power Control parameters

Load Control parameters

Common Channel powers (e.g. AICH, P+SSCH, BCH)

Access parameters which are not part of the secondary parameters

Handover parameters that are not part of the secondary parameters

PrimaryParameters

7.2.1. NeighborLists

The optimization of neighbor list is one of the primary measures during RF optimization.
Neighbor lists are defined both for Inter and Intra System handovers. Neighbor relations have
a direct impact on system reliability. The general approach is to keep the neighbor relations
to an optimum minimum value (<=15), as well as guarantee an efficient mobility in the
network (seamless service coverage).
7.2.2. AntennaParameter
Antenna Parameter configuration can be adjusted for reasons such as coverage
adjustments, pilot pollution or interference. Antenna configuration modifications should be
considered before CPICH power parameter adjustments.
Antenna configuration changes include mainly adjustments on electrical tilt. If not sufficient,
modification on mechanical tilt, azimuth or antenna height might be considered.
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 53 of 89

7.2.3. PilotChannelPower
The pilot transmit power can be adjusted to cope with certain coverage overshoot problems
and multiple pilot coverage regions (pilot pollution). In some cases, transmit powers can be
adjusted to provide fill-in coverage for weak signal strength areas.
Pilot transmit power adjustments should be considered where antenna parameter changes
are not sufficient to eliminate a problem in a particular area.

7.3.

SecondaryParameters

The secondary RF Optimization parameters can have system wider performance impact and
should be adjusted with caution, especially ones that are definable per RNC and not per cell.
For example, small changes in soft handover parameters can impact overall system capacity
and channel element utilization.
7.3.1. CellSelection/ReSelection
When the UE is switched on, it searches for a suitable cell. When the UE is in idle mode, it
continuously compares the strength of the current pilot with all other available pilots. When
the mobile finds another sector with sufficiently greater signal strength, it will perform a reselection. The reselection can be within the same system and to another cell or carrier, but it
can also occur to the different underlay system, for example like GSM.
The parameters given below are used to change the requirements for a mobile to perform
cell selection or re-selection. Special network conditions might require special settings for
these parameters. For example, in dense networks (multiple pilots) mobiles shall meet high
requirements for re-selection to avoid ping-pong effects and unnecessary signaling
(interference). On the other hand, in loose networks (rural) the requirements for cell selection
/ re-selection shall be low to allow mobiles network access that experience higher pathloss.

Cell Selection
Qqualmin (dB)
Qrxlevmin (dBm)

Minimum required quality level (Ec/No) a cell must have for selection in idle
mode.
Minimum required RX level (RSCP) a cell must have for selection in idle
mode.

Cell Reselection
When the UE is in idle mode, it constantly compares the signal strength of the current pilot
with all other available pilots. When the mobile finds another sector of sufficiently greater
signal strength, it will perform a reselection.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 54 of 89

Cell Select Reselection


Measurement
Qoffset1s,n (dB)

Qoffset2s,n (dB)
Qhyst1s (dB)
Qhyst2s (dB)
Qqualmin (dB)
Qrxlevmin (dBm)
Treselections (time)
sIB3SintraSearch
sIB3SinterSearch
sIB3RATSearch

Defines whether CPICH RSCP (1) or CPICH Ec/No (0) is used as the cell reselection
quality measure. This value is consolidated. Recommended is CPICH Ec/No (0), so
Qhyst2 and Qoffset2 are used.
This specifies the offset between the two cells (Hysteresis value prioritizing the ranking of
the serving cell). It is used for TDD and GSM cells and for FDD cells in case the quality
measure for cell selection and re-selection is set to CPICH RSCP.
This specifies the offset between the two cells (Hysteresis value prioritizing the ranking of
the serving cell). It is used for FDD cells in case the quality measure for cell selection and
re-selection is set to CPICH Ec/No.
Hysteresis value prioritizing the ranking of the serving cell (dB) if CPICH RSCP is used as
quality measure. Value is not used if the recommended Ec/No quality measure is used.
Hysteresis value prioritizing the ranking of the serving cell (dB) if CPICH Ec/No is used as
quality measure. This value should be increased if ping-pong reselections are experienced.
This specifies the minimum required Pilot quality level in the cell in dB.
This specifies the minimum required Pilot RX level in the cell in dBm.
Time value [sec] which defines how long a neighbor cell must be
ranked higher than the serving cell before this cell is selected. A
longer time will make ping-pong reselections unlikely but also
delay the reselection of a new sector.
Defines a threshold for the quality value Squal above which the UE stop performing intrafrequency FDD measurements.
Defines a threshold for the quality value Squal above which the UE stop performing interfrequency FDD measurements.
Defines a threshold for the quality value Squal above which the UE stop performing
measurements for reselection towards this RAT type.

7.3.2. AccessProcedure
The mobile goes into the network access stage when a call is originated. The mobile selects
the initial transmit power probe based on the received signal strength and some adjustment
factors. The mobile subsequently ramps up the power on successive probe attempts for
every unacknowledged probe. The purpose of the access parameters is to minimize the
power transmitted while maximizing the access success rate and minimizing the access
delay.

PowerOffsetPpm (dB)

PRACH constant Val


(dB)
Power Ramp Step

The Power offset P p-m = Pmessage control Ppreamble, measured in dB Its setting
has to be considered along with setting of parameter PRACH constant Val since low
values of PRACH constant Val lead RACH preamble to be detected at a very low Eb/N0,
thus to send the RACH message part at a power level too low to be decoded correctly by
the NodeB. High values improve the RACH success rate of RACH but also increase of UL
interference.
Too low values may cause RACH Preambles to be detected at very low Eb/N0. Otherwise
with too high values, RACH Preambles may be transmitted with more power than is
necessary to be detected, thus increasing the uplink interference.
The power-ramping factor Power Ramp Step [integer > 0]. Trade-off between minimizing
UL interference and speed up the successful UE access to the network.

Please refer to 3GPP TS 25.303 v3.x.0 Interlayer Procedures in Connected Mode.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 55 of 89

7.3.3. Soft/SofterHandover
The tuning of Handover parameters has the following goals (Please refer to 3GPP UMTS TS
25.331 RRC Protocol Specification, Release 99):

Ensure a smooth coverage area (ensure HO when required)

Use the advantage of Handover gain (find best trade-off between handover gain and
network capacity)

Coordinate traffic distribution, e.g. for bridges or city highways

Handover Measurement Reporting


Reporting Interval
Filter Coefficient

Periodicity of reporting handover events (1A&1C) from the UE to the UTRAN. This
parameter affects the speed of the handover procedure.
Average window of the event measurements by the UE, means for which period an handover
event is fulfilled before sending a measurement report to the UTRAN. A narrow window will
speed up the handover procedure, but would also cause ping-pong effect.

Handover Algorithm
Deactivation Threshold

Activation Threshold

Reporting Range (dB)

Hysteresis (dB)

Time To Trigger (dB)

Cell Individual Offset

The parameter set the maximum active set size for which event 1A can be reported. The
optimized value should consist in a good trade-off between uplink-limited scenarios (where
better performances are achieved with higher number of active set cells) and downlinklimited scenarios (vice versa). The optimum point is also different for different data rates.
The parameter set the minimum active set size for event 1C to be reported. This parameter
should be always set to a value greater than parameter Deactivation Threshold in order to
allow Event 1C to be reported
The parameter set the reporting range for a candidate pilot to be able to trigger event 1A and
1B. The smaller the value of this parameter, the less restrictive it is. The optimized value
should consist in a good trade-off between uplink limited and downlink limited scenarios. The
value of this parameter must be considered along with parameter Hysteresis.
In case of for event 1A the given value decreases the global hysteresis factor for event 1A
making the triggering condition less restrictive. In case of event 1B the given value increases
the global hysteresis factor for event 1B making the triggering condition less restrictive. In
case of event 1C this hysteresis parameter is the only one that controls the range for
triggering condition and the given value means that the new candidate cell will have to be by
the individual setting better than the worst pilot included in the active set for event 1C to be
triggered.
This parameter is used to limit the measurement signaling load avoiding Measurement
Report message to be sent by the UE for a defined period of time during which the triggering
conditions for the related event have existed. For event 1A and 1C it is not recommended to
delay the occurrence of the event, whereas for event 1B delaying the occurrence is important
in order to ensure that no link is dropped from the active set due to a short fade in the
received signal.
The offset on a cell basis can be either positive or negative. In case of events 1A or 1B the
offset is added to the measurement quantity of the cell candidate to enter or leave the active
set respectively. In case of event 1C one offset is added to the measurement quantity of the
new candidate cell to enter the active set and one offset is added to the measurement
quantity of the worst cell included in the active set.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 56 of 89

7.3.4. InterRAT
Below is list of some typical Inter-RAT HO parameters, changeable on the cell basis:

measurementQuantityInte
rRATHHO

mahoByGsmMeasureme
nts

Umts2GsmHOMeas

umts2GsmQActCM2D

umts2GsmQDeactCM2F

umts2GsmQTriggerMAH
O

This parameter is used for Inter-RAT hard handover from UTRAN to GSM. It determines
the quantity to be used for measurements of the UMTS frequency. Following options are
typically available:
a) RSCP
b) Ec/No
c) RSCP and Ec/No
This parameter enables/disables the mobile assisted handover algorithm (MAHO) for
triggering the UMTS to GSM handover procedure. The MAHO algorithm is based on
measurements of the GSM cells. Typically, MAHO algorithm is always enabled.
Defines GSM measurements criteria for inter-RAT HO from UMTS to GSM with following
sub-parameters (MAHO):
a) gsmQualityThreshold: Specifies a value for the quality of GSM system for triggering
event 3A and 3C (actual quality is above specified threshold)
b) gsmFilterCoefficient: low pass filter for GSM measurements (3A & 3C)
c) combinedGsmNeighbourListSize: Maximum number of GSM neighbour cells related
to the active set which should be measured by the UE
Defines the measurements criteria for activation of compressed mode for UMTS to GSM
HO with following sub-parameters:
a) rSCPThresholdeCN0Threshold: Specifies a value for the quality of the own system
(UMTS frequency) for triggering event 2D (actual quality drops below specified
thresholds). This event is used to start inter-RAT measurements for a UE that
requires CM.
b) timeToTrigger: Specifies the time for which the triggering conditions must be true
before the UE sends an event triggered measurements report to the UTRAN.
Defines the measurements criteria for deactivation of compressed mode for UMTS to
GSM HO with following sub-parameters:
a) rSCPThresholdeCN0Threshold: Specifies a value for the quality of the own system
(UMTS frequency) for triggering event 2F (actual quality rises above specified
thresholds). This event is used to stop inter-RAT measurements for a UE that
requires CM.
b) timeToTrigger: Specifies the time for which the triggering conditions must be true
before the UE sends an event triggered measurements report to the UTRAN.
Defines the measurements criteria to trigger UMTS to GSM HO (MAHO) with following
sub-parameters:
a) rSCPThresholdeCN0Threshold: Specifies 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 thresholds).
b) timeToTrigger: Specifies the time for which the triggering conditions must be true
before the UE sends an event triggered measurements report to the UTRAN.
c) Weight: Specifies weighting between strongest link and remaining active links for
computing the quality of the own system (UMTS system).

(refer to UMTS IRAT Optimization Guidelines).

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 57 of 89

7.3.5. HSDPA
Below are listed some typical HSDPA parameters:
hSDPASrvCellChgCri
t.hysteresis
hSDPASrvCellChgCri
t.timeToTrigger
hSDPASrvCellChgCri
t.useCIO
outFDDAdjCells.cellO
ffset

Hysteresis value for triggering the change of the best cell within the active
set.
Time to trigger before a event 1D is sent.
Indicator whether a cell specific offset is used for event 1D evaluation.
Setting of the cell specific offset.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 58 of 89

8
8. RFOptimizationAspects
The most common challenges of RF Optimization are Coverage, Pilot Pollution/Interference,
Around-the-Corner-Problem and Missing Neighbors. Additional aspects for Cell Breathing,
Inter/Intra System Handover, Near Far Problem and HSDPA are addressed in this Chapter.
At the end, some hints about access failures are provided.

8.1.

RadioCoverage

Radio coverage is defined as an area where the Link Budget condition, in particular the
limited traffic channel path loss (UL or DL) for a service type, is met:

Pathloss (RSCP based) < maximum allowed pathloss (e.g. 145dB)

The key parameters that define a UMTS service type considering the coverage and capacity
issues are (refer to UMTS RF Engineering Guidelines):

Type of connection

Bit rate

Current traffic load

Type of environment

Eb/No requirement (SIR target)

In conjunction with a pathloss the required Ec/Io is utilized for coverage verifications. Ec/Io
values are used for cell selection/reselection, handover criteria and are, in addition, the
quality indicators for a coverage conditions. Ec/Io value is very fluctuating and should always
be understood as the average value (~2 seconds). There is no relation between the Ec/Io
and the required Eb/No for DTCH (SIR), therefore Ec/Io requirements should be stated only
together with the target RSSI, max DL power, target BLER and the channel model.
Poor RF coverage is typically characterized as:

Coverage Hole or Outer Coverage Area Area with insufficient pilot RSCP signal
strength

No Dominant Pilot Area Area with sufficient pilot RSCP signal strength but no
dominant Ec/Io pilot. Usually the case when many equal pilots are measured that
lower the signal-to-interference distance.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 59 of 89

The UE receive power (RSSI) is not an accurate measure of a pathloss for spread spectrum
technologies because it contains everything measured in the frequency band. UE may have
strong received power due to the many overlapping sectors but no pilot who fulfils the above
mentioned coverage conditions. Nevertheless, low RSSI values (below 100dBm) are
typically indicator of a weak or poor coverage area.
8.1.1. CoverageHoleorOuterCoverageArea
Coverage improvements for areas with insufficient RSCP signal strengths are less achieved
by changing RF parameters, antenna tilts or channel power. For the majority of poor
coverage areas these modifications will be insufficient. The focus for those areas is rather on
defining a sharp UMTS coverage borders in order to ensure smooth Inter RAT Handover
(IRAT HO) to the underlying network.
Effective measure to improve coverage on a long-term approach is to modify the radio
network design by:

implementation of new sites

implementation of repeaters or cell extenders for specific areas such as for example
tunnels

implementation of in-house solutions

antenna configuration changes (re-location, type, azimuth, or height)

8.1.2. OvershootingSectorCellCoverage
Sector cell coverage is overshooting if the desired cell service coverage is exceeded. The
cell coverage is primarily evaluated by the pilot RSCP signal strength. Overshooting is usual
given if the cell signal strength is present beyond the 1st tier of neighboring cells sites. (Refer
to Figure 22).
Even in some cases the overshooting cell is the dominant cell and hence desired cell,
overshooting coverage should be eliminated and exceptions should be seen only as
temporary solution until modification on the RF design is undertaken.
Often are overshooting cells present due to unfavourable terrain conditions (hill / valley) or
antenna mounting elevations. Antenna configuration changes (re-location, type, azimuth, or
height) must be considered.
If an overshooting cell is present, the following aspects should be considered:

Call failures due to missing neighbor relations (inter / intra RAT)

Excessive neighbor lists (inter / intra RAT)

Call failures due to scattered coverage (deep fading holes)

Call failures due to pilot pollution

Excessive handover amount (ping pong, e.g. mitigate HSDPA performance)

Capacity issues
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 60 of 89

Overshooting
Cell Coverage

Neighbor Cells

Scattered
Coverage

Figure 22 Around the Corner Problem

Modification the electrical antenna tilt will be one of the primarily measures mitigating
overshooting cell sectors. The antenna tilt must be careful chosen using preferable a
prediction tool as well as requires an evaluation of the antenna pattern versus antenna height
and cell distance. Figure 23 shows an example of an overshooting cell sector (upper 3dB
mean must be considered). In the case below even an increased tilt of 4 might not be
efficient since the upper 3dB antenna bean is still over horizon.
Such tools such as the antenna bean visualization tool from Kathrein should be used only in
conjunction with the prediction tool and real scanner measurement data.

Figure 23 Antenna Pattern


Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 61 of 89

8.1.3. NoDominantPilotArea
No Dominant Pilot Area refers to the coverage areas with multiple weak Ec/Io pilots
increasing the overall interference. The RSCP signal levels are still sufficient, Ec/Io values
arent. The strategy is hereby to remove individual pilots in order to strengthen one pilot and
hence gain an improved Ec/Io ratio. This is usually done by antenna tilt / type changes and
DL transmit power modifications. Still this approach requires caution because it may
introduce not wanted problems in other areas where a particular modified sector provided
coverage or now introduces interference.

8.2.

PilotPollution

Multiple pilot receptions in the same area increase the overall level of interference. Pilots not
used by the terminals cause interference to the ongoing communication, which in the worst
case may cause a call failures. Typically the term pilot pollution describes the existence of
too many pilots in an area, which arent required to sustain the communication. Pilot
pollution occurs when the following conditions take place:

Number of present pilots is larger than the Active Set Size

Present pilots have similar signal strengths

Present pilots have poor Ec/Io ratios

Polluted area shows usually good RSSI values

Pilot pollution is typically found in urban areas with a dense cell site design. Common trouble
spots are bridges, upper floors in buildings, elevated highways, street intersections and large
bodies of water.
Pilot pollution is interference and results in a rapid BLER rise, leading to the call setup
failures and drops. The UE demands a lot more power from the system to mitigate the
registered interference. Pilots that cannot be added to the active set cause interference
because the active set is already full with other similar pilots. In practise many active set
updates are observed with pilot swapping causing an increase of signalling towards the
system. Overshooting sectors should be eliminated mainly through antenna configuration
changes (tilt, azimuth). The general rule is: Use the pilot in the active set to improve the
communication and the overall system performance lowering the used power or eliminate the
pilot causing interference. Verify that remained present pilots are declared as neighbors.
The optimization technique to identify potential pilot pollution areas is to analyse the number
of pilots measured by the scanner within a specified dB range margin to the best measured
pilot (RSCP of Ec/Io). The specified dB range margin is usually the relative pilot removal
threshold for example 5 dB. Pilot pollution is minimized by elimination of individual pilots
from the polluted area through antenna modifications (tilt, azimuth) and/or individual cell
parameter modifications like transmit power. The goal is to increase the dominance of pilots
that should cover the area and reduce coverage (interference) of unwanted pilots. At the
same time, continuous coverage through the soft handover must be ensured to take
advantage of the soft handover gain.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 62 of 89

Another aspect for interference is the multipath reception. Each received pilot is
accompanied by several strong multipaths. The UE 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 two multipaths. The additional pilots and multipaths are interference.
Problem areas with low Ec/Io ratios may be misinterpreted as a pilot pollution areas and lead
to the unnecessary iterative drive testing and parameter changes in attempts to establish a
dominant pilot. The RF optimization engineer needs to determine whether the Ec/Io ratio is
poor due to the excessive pathloss or Pilot Pollution. If the pilot doesnt have sufficient RSCP
signal strength (extensive pathloss), the problem area is considered as a coverage hole.
Figure 24 below shows an example of Pilot Pollution. The area around the bridge has
multiple pilot reception, up to five strong pilots are received. The existing Active Set size is
three. During this drive test a drop call occurred on the bridge due to a BLER raise. RSSI
also raised and aggregated Ec/Io ratio dropped, which are the typical symptoms for a pilot
pollution.

Figure 24 - Pilot Pollution Area


Pilot pollution does not always cause call failures. The UE is able to stand interference up to
a certain degree (SIR target). Nevertheless, the network should be investigated regarding
potential trouble spots and pilot polluted areas should be mitigated. The analysis should
always concentrate on large observed problem area rather than small spots.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 63 of 89

8.3.

AroundtheCornerProblem

The Around-the-Corner Problem is a situation when suddenly significant high pilot power of a
new cell, not part of the active set, appears too fast. This is usually observed beyond
buildings (obstructions) at crossroads (Figure 25 and Figure 26). The interfering pilot has in
many cases a lower pathloss than the pilots in the active set.
The downlink signal quality degrades immediately until the handover is performed or the
downlink power control reacts to compensate the interference. When the UE goes into
handover with the new cell site, fast power control will be needed to quickly reduce cell site
transmit power.
The optimization goal is similar to the strategy of the Near-Far problem. The power control
mechanism should be inspected to ensure it is functioning properly. The Around-the-Corner
problem is a continual and unavoidable issue in dense urban areas. For known trouble spots
such as an elevated highway or a street crossroads a solution is to modify the handover
border of the involved sectors. This can be achieved by changing the handover margin
through the cell individual offset or in some case by reducing the cell coverage for one of the
pilots to force the handover earlier respectively to reduce interference and therefore avoid
the Around-the-Corner effect.

Active Set Pilot


Interfering Pilot

Figure 25 Around the Corner Problem

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 64 of 89

Serving Cell

Fast raising Around


the Corner Interferer

Figure 26 Around the Corner Problem

8.4.

NearFarProblem

The Near-Far problem occurs when an UE transmits on high power near the cell site, thus
creating excessive interference for an UE located far away from the cell site. (See Figure 27)
The goal of the cell site is to receive all UEs at equal signal strengths. Therefore fast closed
loop power control is needed to direct mobiles to power up/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. An
indication of power control failure is if NodeB or the UE is always transmitting on full power
despite satisfying block error rates (e.g. <5%). The tuning of the power control parameters is
usually not done in the field and adjusted by the system architecture engineers. A startup
network with a low subscriber base should not be affected by this type of problem.

Figure 27 Near Far Problem

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 65 of 89

8.5.

CellBreathing

An UMTS system has the characteristic of cell breathing, which is dependent on the network
loading. An increase of the network load is associated with an increase of the network
interference, which means more power is transmitted by the network cells and users. High
interference lowers the quality of service at the initial cell coverage border and thus shrinks
the effective coverage area. Inversely, low load leads to low network interference, which
increases the effective cell coverage (see Figure 28).

30% Loading
Cell A

Cell B

50% Loading

Figure 28 Cell Breathing

Radio optimisation is performed during the initial network rollout with the UMTS downlink
feature OCNS (Orthogonal Channel Noise Simulator) as used by Lucent Technologies to
capture the cell breathing effects. On the uplink an attenuator attached to the UE simulates
the non variable load. Mature networks use performance metric systems to identify hot cells
with high cell load. The approach to mitigate the problem is to reduce the coverage of hot
cells and distribute the users to other surrounding cells. This may also trigger new additional
sites to better distribute the generated traffic.

8.6.

MissingNeighbors

Missing Neighbors are pilots that are not defined in the neighbour list. These pilots are
measured with an adequate receive level but cause interference because they cannot be
added to the active set.
It is important that all received UMTS sectors are either eliminated if not required to sustain
the communication path or declared in the neighbor list. A non optimized neighbour list has
a big impact to the quality and performance of connection. The practise shows that most of
times missing neighbour relations are encountered across RNC borders.
Neighbour list are pre-optimized during the radio network design stage. Scanner data can be
used to automatically compute a neighbour list for an initial network rollout. The user
specifies the percentile in the neighbour pilot distribution that before considering neighbour to
the best measured pilot. All measured pilots are usually averaged in a defined bin size
(square) before computing the neighbour list. The distribution of pilots is done by the number
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 66 of 89

of times a relation is computed using also the distance information from the radio network
design. This approach will highlight as site effect overshooting sectors as well as non
obvious neighbour relation in respect to the radio network design. Neighbours can also be
optimised during the initial optimization phase by evaluating the detected set information
from the UE terminal. Root case analysis of experience drive test failures will provide
information on missing neighbour relations. In all cases extensive drive test is required.
Another possibility to optimise neighbour lists is to use the performance management
counters (handover matrix) when network traffic is present.

8.7.

IntraSystemHandover

Unnecessary delays in intra system handovers (soft/softer handovers) may cause


uplink/downlink interference. Quick intra system handovers are required for rapid changes in
pathloss between the UE and the sector due to fading. Also, unnecessary handovers due
non-contiguous UMTS coverage or pilot pollution lead to excessive handover activity, require
additional signalling resources, and increase downlink interference. Time delays due to
resource allocation (channel units, transmission links to RNC, OVSF codes) degrade call
quality and reduce the throughput of data calls.
Conversely, too aggressive settings may cause unstable situations where the system could
get blocked by adding and removing pilots to the active set in an oscillating manner.
The performance of intra-system handovers is influenced by:

Parameters for reporting ranges

Time-to-trigger parameters

Vendor implementation of intra-system handovers

Current load situation in serving RNC

The goal is to optimize the intra system handover performance by careful selection of
thresholds and timers to balance the quality targets and resource availability. The
implementation of the intra system handover follows specification of the standard.
Thresholds and timers are specified in the 3GPP 25.311. The UTRAN implementation of the
algorithms to decide on a particular measurement report event is vendor dependent and not
scope of this multi-vendor document. Thus the general behaviour is straight forward and
covered by the standard documentation. Misbehaviour of the algorithm in respect to the
specification requires the support of the customer and needs to be addressed to the vendor.

8.8.

InterRATHandover

The Inter Radio Access Technologies handover (Inter RAT or IRAT) covers the transfer of a
connection from a UTRAN system to another system technology. The standard currently
defines the IRAT handover from UMTS to GSM. (refer also to UMTS IRAT Optimization
Guidelines and UMTS Inter-System Handover UMTS-GSM DAHO Guideline).

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 67 of 89

The transition from UMTS to another technology should usually occur at the UMTS coverage
boarder. The optimization tasks cover:

Definition of sharp transition borders to avoid unnecessary handovers

Underlying system should provide continuous stable coverage

Idle mode parameters should be considered and harmonized to avoid ping-pong


effects

The Inter RAT handover can be executed as database-assisted handover algorithm (DAHO)
or as mobile-assisted handover algorithm (MAHO). The algorithm can be activated
alternatively or simultaneously in a cell.
Database assisted handover (DAHO) is a terminology given to a handover where the
decision for executing the handover procedure is based solely on precise knowledge of the
network topology. The reason behind an inter-system database assisted handover is to
avoid inter-RAT measurements to be performed by the UE in compressed mode.
Mobile-assisted handover (MAHO) takes into account the received signal strength of the
GSM neighbor cells at the current location of the UE. The UTRAN requests inter RAT
measurements from the UE before any handover decision is made. The event triggered
reporting mechanism is used for inter RAT measurements in order to limit the performance
impact on the UE and the network. The UE sends the measurement report to the network
only, if certain signal quality conditions of the current UMTS cell(s) and GSM neighbor cell(s)
are fulfilled. Because of architectural limitations within most UEs, hard handover scenarios
like UMTS to GSM handover, require the network to help the UE to perform inter RAT
measurements. These architectural limitations restrict the UEs ability to receive signals from
two transmitters at the same time. For these types of UEs the network is required to leave
periods of time (in both the downlink and uplink direction) for which the UTRAN will not send
downlink frames or receive uplink frames from the UE. These periods are used by the UE to
perform measurements on the potential target frequencies for subsequent reporting to the
UTRAN. The UTRAN takes into account the UE capability information when commanding
"Compressed mode operation". The disadvantage of compressed mode operation is that it
reduces the performance of the radio interface in both uplink and downlink. The amount of
capacity degradation depends on the amount of time given to the mobile on the downlink to
search and measure the other frequencies. This time also impacts the uplink performance
due to architectural limitations in the mobile station.
The use of compressed mode should be limited as it has negative impact on the interference
situation. The compressed mode trigger depends on the vendors implementation and can be
for examples triggered by the UE transmit power, the received pilot RSCP, and the
measured pilot Ec/Io (see 3GPP 25.311).
The optimization of the IRAT handover may require the modification of the UMTS coverage
to achieve sharp boarder and reliable radio conditions. This can be realized through antenna
configuration changes (tilt, azimuth) and/or parameter settings. The performance of the
IRAT handover depends mainly on the design of the IRAT neighbors. For MAHO the
optimization focus is the compressed mode to avoid unnecessary UE time spent in this
mode. In general a handover to the other RAT system should follow after the compressed
mode trigger. The practice shows that reliable IRAT handover is achieved through the RSCP
threshold criteria.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 68 of 89

8.9.

HSDPA

High Speed Downlink Packet Access (HSDPA) is a major feature of the 3GPP Release 5
providing enhancements to the downlink transmission capacity (higher end-user data
throughput). New physical channels such as HS-PDSCH (downlink), HS-SCCH (downlink),
and HS-DPCCH (uplink) require be traced and analyzed.
The End-to-End optimization strategy for HSDPA applies following considerations:

Plan drive/indoor/walk testing activities to cover HSDPA cells and collect HSDPA
relevant data.

Define all Key Performance Indicators (KPIs) according to a precise methodology,


which makes KPIs comparable throughout the measurement campaigns

Definition of a methodology to correlate test results with relevant network


performance counters

Monitoring capabilities on the interfaces to collect the relevant traces on UTRAN and
Core Network.

The HSDPA performance depend in general from radio channel coverage condition, traffic
type (VoIP, Streaming, HTTP,), user classes (different subscription levels), and available
downlink resources. HSDPA related metrics are round trip time (RTT), throughput per user,
HS-DSCH cell change success rate, and HS-DSCH data interruption time during cell change.
The cell change procedure does not support soft/softer handover for the downlink HS-DSCH.
The UE uses soft handover for the uplink, the downlink dedicated control channels and any
simultaneous R99 CS voice or data connection using the existing procedures and triggers for
the active set update (events 1A, 1B, 1C). A handover of a HSDPA connection can be seen
as a hard handover where the HS-DSCH is transferred from the source cell to the target cell
with interruption of the data transfer. A possible change is signaled by the UE through the
event 1d in the measurement report. The network initiates the cell change by the transport
channel reconfiguration. The user plane data interruption is caused by the transfer of the
MAC-hsscheduler to the new Node B. The throughput degrades as all data buffered in
source Node B is transferred to the target Node B.
The hard handover constrains on the HS-DSCH require the following radio optimization
aspects to be considered to maximize HSDPA performances (throughput) and avoid
degradation, including eventual drops:

optimize soft/softer handover boundaries to avoid excessive sector coverage overlap

create clear dominant pilot coverage through antenna configuration tuning (tilt,
azimuth) to avoid unnecessary handovers

Remove existing overshooters which create interference and possible instable


radio conditions

Minimize pilot pollution areas

Cell change should be performed not too late, when the UE has already moved into
the area of the new best cell to avoid radio link quality as well as throughput
degradation. On the other hand cell change should not be performed too early to
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 69 of 89

avoid ping-pong effects by switching back to the previous best cell if the radio
conditions vary.

Local optimization is initially done through the tuning of the parameters hysteresis
and time-to-trigger (e.g. in dense urban environment). In special cases use the cell
individual offset to fine tune the trigger condition (e.g. round-the-corner effect).

The radio parameters that affect the cell change are:

hysteresis is the value for triggering the change of the best cell within the active set.

time-to-trigger is the elapsed time with fulfilled trigger condition before the UE sends
an event triggered measurement report to the UTRAN. The evaluation of triggering
condition includes the hysteresis, cell individual offset, and measurement results for
serving and target cell.

cell individual offset is added to the measurement for the cell before the UE decides
whether the event has occurs

More End-to-End optimization aspects involves other network elements and relate for
example to the cell change interruption time with large handover transmission gap causing
RLC retransmission and as a consequence results in a larger gap in UE application layer.

8.10. AccessFailures
In additions to the previous topics, it is important to mention access failures which, apart from
the eventual Network problems, can occur due to the RF specific issues and are therefore
aspect of the radio optimization.
Access failures on RACH can occur due to the missing neighbors, pilot pollution, marginal
coverage, autonomous cell reselection, and other aspects. Network access parameters, such
as for the RACH and cell reselection procedure (intra and idle IRAT), should be considered
in order to improve call setup success rate (CSSR) performance. In case of idle IRAT cell
reselection, similar to IRAT HO, parameter settings modification in both UTRAN and target
technology should be considered (GSM: for example FDDQMin, FDDQOffset). The UE is
not available during the cell reselection procedure until it has completed the registration in
the other RAT system. Also in idle it is important that the neighborhood is well defined for the
serving camped cell.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 70 of 89

9
9. DefinitionsofTerms

A
Access delay: The value of elapsed time between an access request and a successful
access (source: ITU-T X.140).
Active Set: Set of radio links simultaneously involved in a specific communication service
between an UE and a UTRAN access point.
Air Interface User Rate: The user rate between Mobile Termination and IWF. For T services
it is the maximum possible AIUR not including padding. For NT services it is the maximum
possible AIUR.
Application: an application is a service enabler deployed by service providers,
manufacturers or users. Individual applications will often be enablers for a wide range of
services.
Application protocol: The set of procedures required by the application.

B
Bearer: A information transmission path of defined capacity, delay and bit error rate, etc.
Bearer service: A type of telecommunication service that provides the capability of
transmission of signals between access points.

C
Call: a logical association between several users (this could be connection oriented or
connection less).
Cell: Radio network object that can be uniquely identified by a User Equipment from a (cell)
identification that is broadcasted over a geographical area from one UTRAN Access Point.
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 71 of 89

Cell Site: Cell Site refers actually to the cell as previous explained. Within the UMTS RF
Engineering the term Cell Site is rather used to specify unmistakable the site property with its
cell UMTS equipment (NodeB). A cell site consists usually of three sectors.
Common Channel: A Channel not dedicated to a specific UE.
Connected Mode: Connected mode is the state of User Equipment switched on and an
RRC connection established.
Connection: A communication channel between two or more end-points (e.g. terminal,
server etc.).
Connection mode: The type of association between two points as required by the bearer
service for the transfer of information. A bearer service is either connection-oriented or
connectionless. In a connection oriented mode, a logical association called connection needs
to be established between the source and the destination entities before information can be
exchanged between them. Connection oriented bearer services lifetime is the period of time
between the establishment and the release of the connection. In a connectionless mode, no
connection is established beforehand between the source and the destination entities; the
source and destination network addresses need to be specified in each message.
Transferred information cannot be guaranteed of ordered delivery. Connectionless bearer
services lifetime is reduced to the transport of one message.
Control channel: A logical channel that carries system control information.
Controlling RNC: A role an RNC can take with respect to a specific set of UTRAN access
points. There is only one Controlling RNC for any UTRAN access point. The Controlling RNC
has the overall control of the logical resources of its UTRAN access point's.
Core network: An architectural term relating to the part of 3GPP System which is
independent of the connection technology of the terminal (eg radio, wired).
Coverage area: Area over which a 3GPP System service is provided with the service
probability above a certain threshold.
Current serving cell: This is the cell on which the MS is camped.

D
Delivered QoS: Actual QoS parameter values with which the content was delivered over the
lifetime of a QoS session.
Downlink: Unidirectional radio link for the transmission of signals from a UTRAN access
point to a UE. In general, the direction from Network to UE.
Drift RNS: The role an RNS can take with respect to a specific connection between a UE
and UTRAN. An RNS that supports the Serving RNS with radio resources when the
connection between the UTRAN and the User Equipment need to use cell(s) controlled by
this RNS is referred to as Drift RNS.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 72 of 89

E
Enterprise Systems: Information Systems that are used in the telecommunication
organization but are not directly or essentially related to the telecommunications aspects
(Call Centre's, Fraud Detection and Prevention Systems, Invoicing etc).

H
Handoff Gain/Loss (dB): This is the gain/loss factor (+ or -) brought by handoff to maintain
specified reliability at the cell boundary.
Handover: The transfer of a users connection from one radio channel to another (can be the
same or different cell).
Handover: The process in which the radio access network changes the radio transmitters or
radio access mode or radio system used to provide the bearer services, while maintaining a
defined bearer service QoS.
Hard Handover: Hard handover is a category of handover procedures where all the old radio
links in the UE are abandoned before the new radio links are established.

I
Idle mode: The state of UE switched on but which does not have any established RRC
connection.
Information Data Rate: Rate of the user information, which must be transmitted over the Air
Interface. For example, output rate of the voice codec.
Inter cell handover: A handover between different cells. An inter cell handover requires
network connections to be altered.
Interactive service: A service which provides the means for bi-directional exchange of
information between users. Interactive services are divided into three classes of services:
conversational services, messaging services and retrieval services (source: ITU-T I.113).
Intra cell handover: A handover within one sector or between different sectors of the same
cell. An intra cell handover does not require network connections to be altered.
Iu: Interconnection point between an RNC or a BSC and a 3G Core Network. It is also
considered as a reference point.
Iub: Interface between an RNC and a Node B.
Iur: A logical interface between two RNC. Whilst logically representing a point to point link
between RNC, the physical realization may not be a point to point link.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 73 of 89

L
Logical Channel: A logical channel is an information stream dedicated to the transfer of a
specific type of information over the radio interface. Logical Channels are provided on top of
the MAC layer.
Logical O&M: Logical O&M is the signaling associated with the control of logical resources
(channels, cells,) owned by the RNC but physically implemented in the Node B. The RNC
controls these logical resources. A number of O&M procedures physically implemented in
Node B impact on the logical resources and therefore require an information exchange
between RNC and Node B. All messages needed to support this information exchange are
classified as Logical O&M forming an integral part of NBAP.

M
Maximum output Power: For UE, this is a measure of the maximum power supported by
the UE (i.e. the actual power as would be measured assuming no measurement error) (TS
25.101). For FDD BS, the mean power level per carrier of the cell site measured at the
antenna connector in a specified reference condition (TS 25.104). For TDD BS this refers to
the measure of power when averaged over the transmit timeslot at the maximum power
setting (TS 25.105).
Maximum Transmitter Power per Traffic Channel (dBm): The maximum power at the
transmitter output for a single traffic channel.
Mean bit rate: A measure of throughput. The average (mean) bit rate available to the user
for the given period of time (source: ITU-T I.210).
Medium Access Control: A sub-layer of radio interface layer 2 providing unacknowledged
data transfer service on logical channels and access to transport channels.
Mobile evaluated handover: Mobile evaluated handover (MEHO) is a type of handover
triggered by an evaluation made in the mobile. The mobile evaluates the necessity of
handover based on the measured radio environment and based on criteria defined by the
network. When the evaluation meets the hand-off criteria the necessary information is sent
from the mobile to the network. The network then decides on the necessity of the handover
based on the reported evaluation result and other conditions, e.g. uplink radio environment
and/or availability of network resources, the network may then execute the handover.
Mobility: The ability for the user to communicate whilst moving independent of location.
Mobility Management: A relation between the mobile station and the UTRAN that is used to
set-up, maintain and release the various physical channels.

N
Negotiated QoS: In response to a QoS request, the network shall negotiate each QoS
attribute to a level that is in accordance with the available network resources. After QoS
negotiation, the bearer network shall always attempt to provide adequate resources to
support all of the negotiated QoS profiles.
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 74 of 89

Network connection: An association established by a network layer between two users for
the transfer of data, which provides explicit identification of a set of network data
transmissions and agreement concerning the services to be provided by the set (source:
ITU-T X.213 / ISO-IEC 8348).
Network Element: A discrete telecommunications entity which can be managed over a
specific interface e.g. the RNC.
Node B: A logical node responsible for radio transmission / reception in one or more cells
to/from the User Equipment. Terminates the Iub interface towards the RNC.

O
Orthogonal Channel Noise Simulator a mechanism used to simulate the users or control
signals on the other orthogonal channels of a downlink

P
Packet data protocol (PDP): Any protocol which transmits data as discrete units known as
packets, e.g., IP, or X.25.
Packet transfer mode: Also known as packet mode. A transfer mode in which the
transmission and switching functions are achieved by packet oriented techniques, so as to
dynamically share network transmission and switching resources between a multiplicity of
connections (source: ITU-T I.113).
Performance: The ability to track service and resource usage levels and to provide feedback
on the responsiveness and reliability of the network.
Physical Channel: In FDD mode, a physical channel is defined by code, frequency and, in
the uplink, relative phase (I/Q). In TDD mode, a physical channel is defined by code,
frequency, and time-slot.
Point-to-point: A value of the service attribute "communication configuration", which denotes
that the communication involves only two network terminations.
Protocol: A formal set of procedures that are adopted to ensure communication between
two or more functions within the within the same layer of a hierarchy of functions (source:
ITU-T I.112).

Q
QoS profile: a QoS profile comprises a number of QoS parameters. A QoS profile is
associated with each QoS session. The QoS profile defines the performance expectations
placed on the bearer network.
QoS session: Lifetime of PDP context. The period between the opening and closing of a
network connection whose characteristics are defined by a QoS profile. Multiple QoS
sessions may exist, each with a different QoS profile.
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 75 of 89

Quality of Service: The collective effect of service performances which determine the
degree of satisfaction of a user of a service. It is characterized by the combined aspects of
performance factors applicable to all services, such as;

Service operability performance;

Service accessibility performance;

Service retainability performance;

Service integrity performance and

Other factors specific to each service.

R
Radio access bearer: The service that the access stratum provides to the non-access
stratum for transfer of user data between User Equipment and CN.
Radio Access Mode: Mode of the cell, FDD or TDD.
Radio Access Network Application Part: Radio Network Signaling over the Iu.
Radio Bearer: The service provided by the Layer 2 for transfer of user data between User
Equipment and UTRAN.
Radio frame: A radio frame is a numbered time interval of 10 ms duration used for data
transmission on the radio physical channel. A radio frame is divided into 15 time slots of
0.666 ms duration. The unit of data that is mapped to a radio frame (10 ms time interval)
may also be referred to as radio frame.
Radio interface: The "radio interface" is the tetherless interface between User Equipment
and a UTRAN access point. This term encompasses all the functionality required to maintain
such interfaces.
Radio link: A "radio link" is a logical association between single User Equipment and a
single UTRAN access point. Its physical realization comprises one or more radio bearer
transmissions.
Radio link addition: The procedure where a new radio link is added to the active set.
Radio Link Control: A sublayer of radio interface layer 2 providing transparent,
unacknowledged and acknowledged data transfer service.
Radio link removal: The procedure where a radio link is removed from the active set.
Radio Link Set: A set of one or more Radio Links that has a common generation of Transmit
Power Control (TPC) commands in the DL
Radio Network Controller: This equipment in the RNS is in charge of controlling the use
and the integrity of the radio resources.
Radio Network Subsystem Application Part: Radio Network Signaling over the Iur.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 76 of 89

Radio Network Subsystem: Either a full network or only the access part of a UTRAN
offering the allocation and the release of specific radio resources to establish means of
connection in between an UE and the UTRAN.
A Radio Network Subsystem is responsible for the resources and transmission/reception in
a set of cells.
Received Signal Code Power: Given only signal power is received, the average power of
the received signal after despreading and combining.
Receiver Antenna Gain (dBi): The maximum gain of the receiver antenna in the horizontal
plane (specified as dB relative to an isotropic radiator).
Receiver Noise Figure (dB): Receiver noise figure is the noise figure of the receiving
system referenced to the receiver input.
Receiver Sensitivity (dBm): This is the signal level needed at the receiver input that just
satisfies the required Eb/(No+Io).
Requested QoS: a QoS profile is requested at the beginning of a QoS session. QoS
modification requests are also possible during the lifetime of a QoS session.
Required Eb/(No+Io) (dB): The ratio between the received energy per information bit to the
total effective noise and interference power density needed to satisfy the quality objectives.
RRC Connection: A point-to-point bi-directional connection between RRC peer entities on
the UE and the UTRAN sides, respectively. An UE has either zero or one RRC connection.

S
Seamless handover: "Seamless handover" is a handover without perceptible interruption of
the radio connection.
Sector: A "sector" is a sub area of a cell. All sectors within one cell are served by the same
cell site. A radio link within a sector can be identified by a single logical identification
belonging to that sector.
Service: a component of the portfolio of choices offered by service providers to a user,
functionality offered to a user.
Service Area: The Service Area is defined in the same way as the Service Area according to
ITU-T Recommendation Q.1001 [4]. In contrast to the PLMN area it is not based on the
coverage of a PLMN. Instead it is based on the area in which a fixed network user can call a
mobile user without knowing his location. The Service Area can therefore change when the
signaling system is being extended, for example.
Service bit rate: The bit rate that is available to a user for the transfer of user information
(source: ITU-T I.113).
Serving RNS: A role an RNS can take with respect to a specific connection between an UE
and UTRAN. There is one Serving RNS for each UE that has a connection to UTRAN. The
Serving RNS is in charge of the RRC connection between a UE and the UTRAN. The
Serving RNS terminates Iu for this connection.
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved
Page 77 of 89

Shared Channel: A radio resource (transport channel or physical channel) that can be
shared dynamically between several UEs.
(U)SIM code group: Combination of the (U)SIM code and the associated network subset and
network codes (it is equivalent to the IMSI).
(U)SIM personalization: Enables a user to personalize a ME so that it may only be used with
particular (U)SIM(s).
Soft Handover: Soft handover is a category of handover procedures where the radio links
are added and abandoned in such manner that the UE always keeps at least one radio link
to the UTRAN.
Suitable Cell: This is a cell on which an UE may camp. It must satisfy certain conditions.

T
Terminal: A device into which a UICC can be inserted and which is capable of providing
access to 3GPP System services to users, either alone or in conjunction with a UICC.
Throughput: A parameter describing service speed. The number of data bits successfully
transferred in one direction between specified reference points per unit time (source: ITU-T
I.113).
Total power dynamic range: The difference between the maximum and the minimum total
transmit output power for a specified reference condition (TS25.104).
Traffic channel: A "traffic channel" is a logical channel which carries user information.
Transmitter Antenna Gain (dBi): The maximum gain of the transmitter antenna in the
horizontal plane (specified as dB relative to an isotropic radiator.
Transport Block: Transport Block is defined as the basic data unit exchanged between L1
and MAC. An equivalent term for Transport Block is MAC PDU.
Transport channel: The channels offered by the physical layer to Layer 2 for data transport
between peer L1 entities are denoted as Transport Channels. Different types of transport
channels are defined by how and with which characteristics data is transferred on the
physical layer, e.g. whether using dedicated or common physical channels.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 78 of 89

U
UE Service Capabilities: Capabilities that can be used either singly or in combination to
deliver services to the user. The characteristic of UE Service Capabilities is that their logical
function can be defined in a way that is independent of the implementation of the 3GPP
System (although all UE Service Capabilities are of course constrained by the
implementation of the 3GPP System). Examples: a data bearer of 144 kbps; a high quality
speech teleservice; an IP teleservice; a capability to forward a speech call.
Universal Subscriber Identity Module (USIM): An application residing on the UICC used
for accessing services provided by mobile networks, which the application is able to register
on with the appropriate security.
Uplink: An "uplink" is a unidirectional radio link for the transmission of signals from a UE to a
cell site, from a Mobile Station to a mobile cell site or from a mobile cell site to a cell site.
User: An entity, not part of the 3GPP System, which uses 3GPP System services. Example:
a person using a 3GPP System mobile station as a portable telephone.
User-network interface: The interface between the terminal equipment and a network
termination at which interface the access protocols apply (source: ITU-T I.112).
User Services Profile: Contains identification of subscriber services, their status and
reference to service preferences.
Uu: The Radio interface between UTRAN and the User Equipment.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 79 of 89

10
10.DefinitionsEquations
Following RF relevant formulas are given, as specified by 3GPP:

CPICH _ E c
I or

The ratio of the received energy per PN chip of the CPICH to the total transmits
power spectral density at the NodeB (SS) antenna connector.

Ec

Average energy per PN chip.

Ec
I or

The ratios of the average transmit energy per PN chip for different fields or
physical channels to the total transmit power spectral density.

Io

OCNS_ Ec
OCNS_ Ec
Ior

P CPICH _ Ec

The total received power spectral density, including signal and interference, as
measured at the UE antenna connector.
Average energy per PN chip for the OCNS.

The ratio of the average transmits energy per PN chip for the OCNS to the total
transmit power spectral density.

Average* energy per PN chip for P-CPICH.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 80 of 89

UTRAN measurement abilities

CPICH RSCP
Definition

Applicable for

Received Signal Code Power, the received power on one code measured on the
Primary CPICH. The reference point for the RSCP shall be the antenna connector of
the UE. If Tx diversity is applied on the Primary CPICH the received code power from
each antenna shall be separately measured and summed together in [W] to a total
received code power on the Primary CPICH.
Idle, Connected Intra, Connected Inter

UTRA carrier RSSI


Definition
Applicable for

The received wide band power, including thermal noise and noise generated in the
receiver, within the bandwidth defined by the receiver pulse shaping filter. The
reference point for the measurement shall be the antenna connector of the UE.
Idle, Connected Intra, Connected Inter

CPICH Ec/No
Definition

Applicable for

The received energy per chip divided by the power density in the band. The CPICH
Ec/No is identical to CPICH RSCP/UTRA Carrier RSSI. Measurement shall be
performed on the Primary CPICH. The reference point for the CPICH Ec/No shall be
the antenna connector of the UE. If Tx diversity is applied on the Primary CPICH the
received energy per chip (Ec) from each antenna shall be separately measured and
summed together in [Ws] to a total received chip energy per chip on the Primary
CPICH, before calculating the Ec/No.
Idle, Connected Intra, Connected Inter

Transport channel BLER


Definition

Estimation of the transport channel block error rate (BLER). The BLER estimation
shall be based on evaluating the CRC of each transport block associated with the
measured transport channel after RL combination. The BLER shall be computed over
the measurement period as the ratio between the number of received transport
blocks resulting in a CRC error and the number of received transport blocks.
When either TFCI or guided detection is used, the measurement Transport channel
BLER may only be requested for a transport channel when the associated CRC size
is non zero and at least one transport format in the associated transport format set
includes at least one transport block.
When neither TFCI nor guided detection is used, the measurement Transport
channel BLER may only be requested for a transport channel when the associated
CRC size is non zero and all transport formats in the associated transport format set
include at least one transport block.

Applicable for

The measurement Transport channel BLER does not apply to transport channels
mapped on a P-CCPCH and a S-CCPCH. The UE shall be able to perform the
measurement Transport channel BLER on any transport channel configured such
that the measurement Transport channel BLER can be requested as defined in this
section.
Connected Intra

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 81 of 89

SIR
Definition

Signal to Interference Ratio, is defined as: (RSCP/ISCP)SF. Measurement shall be


performed on the DPCCH of a Radio Link Set. In compressed mode the SIR shall not
be measured in the transmission gap. The reference point for the SIR measurements
shall be the Rx antenna connector.
where:
RSCP = Received Signal Code Power, unbiased measurement of the received power
on one code.
ISCP = Interference Signal Code Power, the interference on the received signal.
SF=The spreading factor used on the DPCCH.

SIRerror
Definition

SIRerror = SIR SIRtarget_ave, where:


SIR = the SIR measured by UTRAN, defined in section 5.2, given in dB.
SIRtarget_ave = the SIRtarget averaged over the same time period as the SIR used in the
SIRerror calculation. In compressed mode SIR target=SIRcm_target shall be used when
calculating SIRtarget_ave. In compressed mode the SIRtarget_ave shall not be calculated
over the transmission gap. The averaging of SIR target shall be made in a linear scale
and SIRtarget_ave shall be given in dB.

Transmitted carrier power


Definition

Transmitted carrier power, is the ratio between the total transmitted power and the
maximum transmission power. Total transmission power is the mean power [W] on
one carrier from one UTRAN access point. Maximum transmission power is the
mean power [W] on one carrier from one UTRAN access point when transmitting at
the configured maximum power for the cell. Measurement shall be possible on any
carrier transmitted from the UTRAN access point. The reference point for the
transmitted carrier power measurement shall be the Tx antenna connector. In case
of Tx diversity the transmitted carrier power for each branch shall be measured and
the maximum of the two values shall be reported to higher layers, i.e. only one value
will be reported to higher layers.

Transmitted code power


Definition

Transmitted code power, is the transmitted power on one channelisation code on one
given scrambling code on one given carrier. Measurement shall be possible on the
DPCCH-field of any dedicated radio link transmitted from the UTRAN access point
and shall reflect the power on the pilot bits of the DPCCH-field. When measuring the
transmitted code power in compressed mode all slots shall be included in the
measurement, e.g. also the slots in the transmission gap shall be included in the
measurement. The reference point for the transmitted code power measurement
shall be the Tx antenna connector. In case of Tx diversity the transmitted code power
for each branch shall be measured and summed together in [W].

Transport channel BER


Definition

The transport channel BER is an estimation of the average bit error rate (BER) of the
DPDCH data of a Radio Link Set. The transport channel (TrCH) BER is measured
from the data considering only non-punctured bits at the input of the channel decoder
in Node B. It shall be possible to report an estimate of the transport channel BER for
a TrCH after the end of each TTI of the TrCH. The reported TrCH BER shall be an
estimate of the BER during the latest TTI for that TrCH. Transport channel BER is
only required to be reported for TrCHs that are channel coded.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 82 of 89

Physical channel BER


Definition

The Physical channel BER is an estimation of the average bit error rate (BER) on the
DPCCH of a Radio Link Set. An estimate of the Physical channel BER shall be
possible to be reported after the end of each TTI of any of the transferred TrCHs.
The reported physical channel BER shall be an estimate of the BER averaged over
the latest TTI of the respective TrCH.

Round trip time


Definition

Round trip time (RTT), is defined as


RTT = TRX TTX, where
TTX = The time of transmission of the beginning of a downlink DPCH frame to a UE.
The reference point for TTX shall be the Tx antenna connector.
TRX = The time of reception of the beginning (the first detected path, in time) of the
corresponding uplink DPCCH/DPDCH frame from the UE. The reference point for T RX
shall be the Rx antenna connector.
Measurement shall be possible on DPCH for each RL transmitted from an UTRAN
access point and DPDCH/DPCCH for each RL received in the same UTRAN access
point.

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 83 of 89

11
11.Abbreviations

A
AICH
AM
AN
ARFCN
AS
ASC
AWGN

Acquisition Indicator Channel


Acknowledged Mode
Access Network
Absolute Radio Frequency Channel Number
Access Stratum
Access Service Class
Additive White Gaussian Noise

BCH
BER
BLER

Broadcast Channel
Bit Error Ratio
Block Error Ratio

CCCH
CCH
CCPCH
Cct
CCTrCH
CDMA
CI
CPICH
CPCH
CRC
CS
CSD
CTCH
CW

Common Control Channel


Control Channel
Common Control Physical Channel
Circuit
Coded Composite Transport Channel
Code Division Multiple Access
Cell Identity
Common Pilot Channel
Common Packet Channel
Cyclic Redundancy Check
Circuit Switched
Circuit Switched Data
Common Traffic Channel
Continuous Wave (unmodulated signal)

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 84 of 89

D
DCCH
DCH
DL
DPCCH
DPCH
DPDCH
DRAC
DRNS
DSCH
DTCH

Dedicated Control Channel


Dedicated Channel
Downlink (Forward Link)
Dedicated Physical Control Channel
Dedicated Physical Channel
Dedicated Physical Data Channel
Dynamic Resource Allocation Control
Drift RNS
Downlink Shared Channel
Dedicated Traffic Channel

ETS
ETSI

European Telecommunication Standard


European Telecommunications Standards Institute

FACH
FDD
FER
FR

Forward Access Channel


Frequency Division Duplex
Frame Erasure Rate, Frame Error Rate
Full Rate

GGSN
GTP
GTP-U
GUI

Gateway GPRS Support Node


GPRS Tunneling Protocol
GPRS Tunneling Protocol for User Plane
Graphical User Interface

HO
HSCSD
HTTP
IM
INAP
IP
ISCP
ISO
ISP
ITU

Handover
High Speed Circuit Switched Data
Hyper Text Transfer Protocol
Intermodulation
Intelligent Network Application Part
Internet Protocol
Interference Signal Code Power
International Organization for Standardization
Internet Service Provider
International Telecommunication Union

L1
L3
LAN
LLC
Lm

Layer 1 (physical layer)


Layer 3 (network layer)
Local Area Network
Logical Link Control
Traffic channel with capacity lower than a Bm

MAC
Mcps

Medium Access Control (protocol layering context)


Mega-chips per second

NAS
NBAP
NCELL

Non-Access Stratum
Node B Application Part
Neighboring (of current serving) Cell

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 85 of 89

O
O&M
OCNS
OSI RM
OTA
OVSF

Operations & Maintenance


Orthogonal Channel Noise Simulator
OSI Reference Model
Over-The-Air
Orthogonal Variable Spreading Factor

P-CCPCH
P-CPIH
PC
PCCCH
PCCH
PCH
PCPCH
PCU
PDCH
PDN
PDP
PDSCH
PDTCH
PDU
PHY
PhyCH
PN
PPCH
PPP
PRACH
PS
PSC
PSCH
PSPDN

Primary Common Control Physical Channel


Primary Common Pilot Channel
Power Control
Packet Common Control Channel
Paging Control Channel
Paging Channel
Physical Common Packet Channel
Packet Control Unit
Packet Data Channel
Packet Data Network
Packet Data Protocol
Physical Downlink Shared Channel
Packet Data Traffic Channel
Protocol Data Unit
Physical layer
Physical Channel
Pseudo Noise
Packet Paging Channel
Point-to-Point Protocol
Physical Random Access Channel
Packet Switched
Primary Synchronization Code
Physical Shared Channel
Packet Switched Public Data Network

QoS

Quality of Service

RA
RAB
RAN
RB
RL
RLC
RLCP
RLP
RNC
RNS
RNSAP
RR
RRC
RRM
RSAT
RSCP
RSSI
RWB
RX
RXLEV

Routing Area
Radio Access Bearer
Radio Access Network
Radio Bearer
Radio Link
Radio Link Control
Radio Link Control Protocol
Radio Link Protocol
Radio Network Controller
Radio Network Subsystem
Radio Network Subsystem Application Part
Radio Resources
Radio Resource Control
Radio Resource Management
Radio System Acceptance Test
Received Signal Code Power
Received Signal Strength Indicator
Resolution Bandwidth
Receive
Received signal level
Copyright 2006 Lucent Technologies
Unpublished and Not for Publication
All Rights Reserved

Q
R

Page 86 of 89

RXQUAL

Received Signal Quality

S-CCPCH
S-CPICH
SAP
SB
SCCH
SCH
SDCCH
SDU
SF
SFN
SHCCH
SIR
SM
SMS
SMS-CB
SN
SP
SQN
SRB
SRNC
SRNS
SS7
SSC
STTD

Secondary Common Control Physical Channel


Secondary Common Pilot Channel
Service Access Point
Synchronization Burst
Synchronization Control Channel
Synchronization Channel
Stand-Alone Dedicated Control Channel
Service Data Unit
Spreading Factor
System Frame Number
Shared Channel Control Channel
Signal-to-Interference Ratio
Session Management
Short Message Service
SMS Cell Broadcast
Subscriber Number
Switching Point
Sequence number
Signaling Radio Bearer
Serving Radio Network Controller
Serving RNS
Signaling System No. 7
Secondary Synchronization Code
Space Time Transmit Diversity

TA
TC-TR
TCP
TD-CDMA
TF
TN
TPC
TPDU
TrCH
TRX
TS
TSC
TSG
TSTD
TX
TXPWR

Timing Advance
Technical Committee Technical Report
Transmission Control Protocol
Time Division-Code Division Multiple Access
Transport Format
Timeslot Number
Transmit Power Control
Transfer Protocol Data Unit
Transport Channel
Transceiver
Time Slot
Training Sequence Code
Technical Specification Group
Time Switched Transmit Diversity
Transmit
Transmit Power; Tx power level in the MS_TXPWR_REQUEST and
MS_TXPWR_CONF parameters

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 87 of 89

U
UARFCN
UARFN
UDD
UDP
UE
UI
UL
UM
UMTS
UP
URAN
URB
USCH
USF
USIM
UTRA
UTRAN
UUI

UTRA Absolute Radio Frequency Channel Number


UTRA Absolute Radio Frequency Number
Unconstrained Delay Data
User Datagram Protocol
User Equipment
User Interface
Uplink (Reverse Link)
Unacknowledged Mode
Universal Mobile Telecommunications System
User Plane
UMTS Radio Access Network
User Radio Bearer
Uplink Shared Channel
Uplink State Flag
Universal Subscriber Identity Module
Universal Terrestrial Radio Access
Universal Terrestrial Radio Access Network
User-to-User Information

VA

Voice Activity factor

WAP
WCDMA
WDP
WLAN
WTDD

Wireless Application Protocol


Wideband Code Division Multiple Access
Wireless Datagram Protocol
Wireless Local Area Network
Wideband Time Division Duplexing

V
W

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 88 of 89

References
[0]

3GPP TS 23.101 V4.0.0, General UMTS Architecture

[0]

3GPP TS 25.301 V3.8.0, Radio Interface Protocol Architecture

[0]

3GPP TS 25.211 V3.8.0, Physical channels and mapping of transport channels onto physical
channels (FDD)

[0]

3GPP TS 25.331 V3.8.0, RRC Protocol Specification

[0]

3GPP TS 25.304 V3.8.0, UE Procedures in Idle Mode and Procedures for Cell Reselection in
Connected Mode

[6]

3GPP TS 25.922 V3.6.0, Radio resource management strategies

[7]

3GPP TS 25.214 V3.9.0, Physical layer procedures (FDD)

[8]

Optimum power setting for pilot and control channel, Frank Beyer, Lucent

[9]

1xEV RF Optimization Guidelines, version 1.09, 07/11/2002, by: Vladan Jovanovic, Anu
Sandhu, Hayder Kammona, Amit Shah

[10]

3G1x RF Optimization Procedures and Guidelines for PCS and Cellular CDMA Systems,
Version 1.0, Dec 2001, by Devesh Patel

[11]

CDMA RF Optimization Procedures for 1.9 GHz PCS Systems, Version 1.53, November 6,
1996, by V. DaSilva, M. Feuerstein, J. McElroy, S. Shio, X. Wang

[12]

CDMA RF PERFORMANCE ANALYSI S & TROUBLESHOOTING GUIDE REV 20.0

Copyright 2006 Lucent Technologies


Unpublished and Not for Publication
All Rights Reserved
Page 89 of 89

Vous aimerez peut-être aussi