190221492 UMTS RF Optimization Guideline v3 1

8/10/2019 190221492 UMTS RF Optimization Guideline v3 1

1/89

UMTS RF

Optimization Guideline

Issue 3.1

November 2006

Lucent Technologies - ProprietaryThis document contains proprietary information

of Lucent Technologies and is not to be disclosed or usedexcept in accordance with applicable agreements

Copyright 2006 Lucent Technologies

Unpublished and Not for PublicationAll Rights Reserved


2/89

The copyright laws of the United States and other countries protect this guideline. It may notbe reproduced, distributed, or altered in any fashion by any entity (either internal or externalto Lucent Technologies), except in accordance with applicable agreements, contracts, orlicensing, 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 ([email protected])

Notice

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

Lucent Technologies - ProprietaryThis document contains proprietary information

of Lucent Technologies and is not to be disclosed or usedexcept in accordance with applicable agreements


mailto:[email protected]:[email protected]


3/89


4/89

Version History

Version Changes

0.1 First draft version

0.9 Preliminary Version ready for review

1.0 Preliminary Released Version

2.0 Review Version

3.0 Revised Version ready for reviewMajor Change Rewrite entire do!"ment# "$date a!!ording mar%ete&$erien!es

3.1 Review Version



Page 4 of 89


5/89

11. 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 andimproving the network performance so that it meets contractual and technical objectives. RFOptimization 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 theaddition 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 forpreparation and execution of the RF Optimization tasks. This document is also intended toassist the local technical staff during maintenance and operation of the system as well as thepost deployment teams delivering services to the customer.

The user of this guideline will gain a fundamental understanding of all major tasks performedduring 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 beable 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 Technologiesequipment. However, the described optimization methods and procedures shall be applicablefor any vendors UTRAN networks (multi Vendor).

In order to avoid duplicated documentation and outdated information, references to properdocuments will be included. This applies to the individual RF optimization procedures, forwhich detailed information is provided by Lucents Method and Procedure (M&P) documents.Other target documents are Lucents UMTS Translation Application Notes or the RFEngineering Guideline.

It should be noted that the RF optimization guideline is coordinated with the UMTS RFPerformance Analysis and Troubleshooting Guideline. The focus of the RF optimizationguideline is primary on describing procedures for the optimization execution. Details forspecifics such as RF parameters, performance metrics, network failures as well as individualtroubleshooting methods are found in the complementary .

It is strongly recommended to read Section 2 on Pre-Requisites before attempting to usethis document. This section provides the overall structure of the guideline in order to bestapply optimization methods.



Page 5 of 89


6/89

22. Pre-Requisites

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 ofWork). This document should be seen as a reference book guiding the RF engineers througheach of the individual work assignments.

This Guide is written to provide engineers with the necessary methods and procedures foroptimizing a UMTS network. References to complementary documentation such as LucentMethods & Procedures or optimization tool descriptions are provided throughout thisdocument.

The Global RF Methods and Procedures / Tool Support web portal provides Lucentpersonnel with an extensive knowledge base that is stored in technical method andprocedure documents. The document structure is divided into the Layer C, D, and E. LayerC 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 Edocuments include reference information, how-to and forms.

The UMTS RF Optimization Guideline should be used in conjunction with the [Available onGlobal RF Methods andProcedures / Tool Support -> RF Guidelines]. This guideline is based on the UMTSoptimization process and is used for the identification, classification and resolution ofproblems, failures and performance degradations. These activities comprise of the followingitems:

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 networkdesign, UMTS link budget, neighbor lists, and scrambling code planning refer to the RFEngineering 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



Page 6 of 89
http://globalrfmandp.wh.lucent.com/http://globalrfmandp.wh.lucent.com/http://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://globalrfmandp.wh.lucent.com/http://globalrfmandp.wh.lucent.com/http://globalrfmandp.wh.lucent.com/http://globalrfmandp.wh.lucent.com/http://quickplace.emea.lucent.com/QuickPlace/rfsys/Main.nsf/h_Toc/EBA62B1F375CC959C1256CF60043F978/?OpenDocumenthttp://quickplace.emea.lucent.com/QuickPlace/rfsys/Main.nsf/h_Toc/EBA62B1F375CC959C1256CF60043F978/?OpenDocumenthttp://globalrfmandp.wh.lucent.com/http://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://globalrfmandp.wh.lucent.com/http://globalrfmandp.wh.lucent.com/http://quickplace.emea.lucent.com/QuickPlace/rfsys/Main.nsf/h_Toc/EBA62B1F375CC959C1256CF60043F978/?OpenDocumenthttp://quickplace.emea.lucent.com/QuickPlace/rfsys/Main.nsf/h_Toc/EBA62B1F375CC959C1256CF60043F978/?OpenDocument


7/89

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

UMTS system architecture and components

o Access network

o UTRAN

o Core network

o GSM and UMTS Interworking

UMTS radio link and radio resource management

o Spreading

o Orthogonal variable spreading factor

o Scrambling codes

o Multi-path signals

o Definitions of channel types

o Physical channels

o Channel coding, multiplexing, and rate matching

o Transport channels

o Logical channels

Mobility and Call Management: location updates, call processing

o Power Control

o Handover

UMTS system services

o UTRAN Signaling (Call Flow)

o Interworking between UMTS and GSM

The UMTS Introduction Course UM1001W covers the aforementioned items. This coursecan 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 detailand 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


Page 7 of 89
https://training.lucent.com/http://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttps://training.lucent.com/http://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htm


8/89

Orthogonal Channel Noise Simulator (OCNS)

RF Call Trace

Radio Link Control (RLC)

High Level Protocol Stack Parameter

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

Figure 1 Overall Guideline Structure



Page 8 of 89

RFParameters

OptimizationAspects

Performanceetric

RF !ools

M&P Documents

RF Tools Lab

Global RF Core Support Homepage

'avigator Portal

Pre"Optimization

OptimizationPlanning

Site Readiness

Optimization#$ecution

M&P Documents

%!S&no'ledge

UM1001W

UMTS Product Training.

UMTS RF Performance Analysis and TroubleshootingGuideline

Translation and Application Notes

UMTS RF Performance Analysis and TroubleshootingGuideline

Scope of Work /

Acceptance Test Plan(ATP)

Translation and Application Notes

%!SRFOptimization

!est

Applications
http://globalrfmandp.wh.lucent.com/http://rftoolslab.web.lucent.com/http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://navigator.web.lucent.com/index.htmhttp://globalrfmandp.wh.lucent.com/https://training.lucent.com/Saba/Web/Mainhttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://globalrfmandp.wh.lucent.com/http://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://globalrfmandp.wh.lucent.com/http://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttps://training.lucent.com/Saba/Web/Mainhttp://globalrfmandp.wh.lucent.com/http://navigator.web.lucent.com/index.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://rftoolslab.web.lucent.com/http://globalrfmandp.wh.lucent.com/


9/89

33. RF Optimization Process

3.1. RF Optimization Process Overview

This Chapter shall provide the RF optimization engineer with a general RF optimizationmethodology. An overview of the different optimization tasks and references to detailed M&Pdocumentation is provided so the RF optimization engineer can assemble a processaccording 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 BasedOptimization. The entire process is dependent on the market situation, network deploymenttype and eventually also on the contractual obligations (Scope of Work). As indicated byFigure 2below, Pre-Optimization is an optional phase and might be required especially fornew network deployment or network extensions. This phase might incorporate tasks such ashardware functionality checks (proper integration), coverage verification, adjustments forinitial 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 neighborlist verifications.

Figure ( Overall Optimization Process



Page 9 of 89

Pre-Optimization(optional)

Drive Test Based Optimization

Service Measurement BasedOptimization

RFOptimizationStart


10/89

The objectives of the Service Measurement Based Optimization and the Drive Test BasedOptimization are to assess and improve network performance and quality. Both optimizationphases are independent of each other, but can be performed in the same phase dependingon market situation and contractual obligation. It is recommended to perform the servicemeasurement based optimization prior to drive test based optimization because majornetwork issues can be eliminated during this optimization phase, thus reducing costs. Thisallows the drive test based optimization to focus on the RF optimization or performance.

However, the Service Measurement Based Optimization is primary performed duringcommercial network operation with live traffic. The focus during the Service MeasurementBased Optimization is in assessing the network performance and quality using appropriatenetwork performance counters (PM) together with dedicated tools. It allows a comprehensiveanalysis from network to the individual UMTS cell or call, with conclusions on theperformance of network elements such as air interface, cell operation or core network. PMcounter and Key Performance Indicators (KPI) reflect the network viewpoint whereas drivetest data the subscriber viewpoint.

Network performance counters play a more and more significant rule for the networkoptimization. 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 toolssuch as Lucents SPAT3G/LUNAR, comprehensive and detailed performance evaluation isensured. Specific optimization techniques allow intensive and effective networktroubleshooting and hence network issues can be resolved without performing extensivedrive tests.

Network performance counters, as well several troubleshooting techniques, are in detaildescribed by the .

Assessing the UTRAN air interface by performing field drive tests will remain one of themajor tasks during UMTS RF Optimization. Although there is the consideration of othernetwork assessments and optimization techniques, the performance of the network is stillverified and reported based on drive tests (end user experience). The RF Drive Test BasedOptimization 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



Page 10 of 89
http://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.zip


11/89

Figure 3 provides an overview of the optimization process including the individual tasks. Asmentioned 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.

Figure ) Optimization Process



Page 11 of 89

Optimization

Process

Pre-Optimization

New ellDeplo!ment

RF ParameterDe"inition

RF Desi#n$eri"ication

ServiceMeasurement

BasedOptimization

Re"er to RFTrou%les&ootin# 'uideline

Pre-Optimization usin#

Ocelot

Drive TestBased

Optimization

Site Readiness

Optimizationecution

OptimizationPlannin#

Sector $eri"ication

*ntenna *udit

Spectrum learance

Baseline istin#S!stem

luster De"inition

*ntenna *udit

RF Parameter *udit

Drive Route Plannin#

luster Optimization

S!stem $eri"ication

Scram%lin# ode*ssi#nments

Nei#&%or +istDe"initions

Scram%lin# odePlan *udit

Nei#&%or +istPlan *udit


12/89

3.2. Network Deployment Scenarios

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 ensureseamless UMTS coverage for the defined service area, assumed no Inter SystemHandover (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 existingunderlay 2G PCS, GSM and/or DCS network(s). In general the same RFoptimization procedures are applicable, with minor changes to the tasks. Forexample the RF network design at the Overlay scenario is usually given by the

underlying network, e.g. antenna heights, cell site locations, mechanical tilts (fordual/tri band antennas). UMTS coverage holes are more or less inevitable andshould not affect the overall designated service coverage area due to the InterSystem Handovers (ISHO). Therefore one of the major focuses is to ensure theseamless 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 arealready deployed as well are overlay networks on GSM 900/1800/1900, the mostcommon scenario is the Network Expansion scenario. In this scenario additional cellsites 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 tooperating system that is serving already a high amount of customers. The secondfocus is verification of the target coverage area as well as seamless servicecoverage 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 isthat it is essential prior to any integration or optimization activity, to base line (i.e.record the performance of) the existing system. RF network performancemeasurements must be collected, analyzed and documented prior to the swapout.

Additional Carrier scenario, where additional carriers are integrated to an existingUMTS 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 codeand neighbor plans that need to be set up prior to any cell site operation. Tasks like RFservice coverage examinations, spectrum clearance tests, antenna audits or cellverification tests should be considered as primary tasks prior to the RF optimization.

Both Service-Based Optimization and RF Drive Test Based Optimization are especiallyapplicable for any existing commercial network.



Page 12 of 89


13/89

3.3. Pre-Optimization

3.3.1. Pre-Optimization Overview

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 RFdepartment, the RF coverage would need to be verified especially concerning the antennatilts 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 arealarms or not acceptable performance caused by the new cell site, the cell site must beswitched off and further investigations are required.

Pre-optimization is particularly important when integrating new sites in an area where UMTScoverage is already provided. The negative impact that could be caused by the integration ofnew 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 significantaspects are addressed here.

3.3.2. RF Design Verification

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 RFplanning / prediction tool (e.g. Lucent Airpro). The goal is to ensure efficient coverage for thetarget 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 bestserving 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 ofthe electrical antenna tilts. The footprints of the surrounding cell sites might becomeexcessive and thus need to be limited. The optimum antenna tilts can be achieved byexamining the terrain and clutter profile as well as the coverage footprints. If cell sites are co-located and multiple band antennas are used (common), the mechanical antenna tilts areoften 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 summaryof 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 orcoverage 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 toCopyright 2006 Lucent Technologies


Page 13 of 89


14/89

ensure proper tilt planning since its implementation is usually very costly. Tilt modificationsshould be considered prior to RF optimization and hence drive tests. For any unclearsituations during the design verification, current tilts should be used and the area must firstbe driven in order to prevent multiple antenna tilt modifications.

Any recommendation for modifications of the RF design (antenna tilts) must be documentedand addressed to customer. After any modification is implemented, the network maintenancetool (OMC-U) as well as the RF database should be updated accordingly.

3.3.3. New Cell Deployment

A common scenario is the deployment of single cell sites into an existing commercial cell sitecluster 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 ofnew cell sites within the same vicinity at different times would create different neighbor listseach time and will double drive test time. Performing repeated RF Optimization should beavoided to minimize expense and labour.

When deploying a cluster cell sites for a new area, cell sites should be integrated cluster bycluster. This method should also be applied for the Greenfield and New Deploymentscenario.

Under common circumstances in commercial networks, pre-optimized cell sites will be turnedon before completing the RF optimization. During this stage, network alarms must bewatched as faults can be expected. In case of network alarms, (faulty hardware), relevantcell sites must switched off and further investigations are required.

Performance counter verification is a possibility for performance testing after the pre-optimization phase and before the RF optimization phase. If specific counters (e.g. RABsetup failure, RRC connection failure, UL interference) indicate measurements high abovetargets, immediate investigations are required (e.g. neighbor lists). Performance counters arediscussed in detail in the .

3.3.4. RF Parameter Definition

The RF parameter assignment must be completed prior to the operational stage of the newcell site(s) (unlocked in OMC-U). During the pre-optimization phase the RF parameterassignment 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 theappropriate network maintenance tools (OMC-U). Those models might be dedicated to thenetwork 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. Thenetwork operator usually provides these parameter models / parameter sets or access toappropriate network tools.

For Lucent deployed markets the parameter sets for new the cell sites can either beassigned on the NDP Web Portalproject database or directly in the network maintenancetool OMC-U. Default parameter sets as well as the parameter catalogue (PARKAT) areavailable on this portal. Details about RF parameter, its definitions and recommendations areprovided by theTranslation and Application Notes.



Page 14 of 89
http://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://ge1884ndp01.de.lucent.com:7779/portal/page?_pageid=35,31210&_dad=portal&_schema=PORTALhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htmhttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://ge1884ndp01.de.lucent.com:7779/portal/page?_pageid=35,31210&_dad=portal&_schema=PORTALhttp://rfcoresupport.wh.lucent.com/TANS/rf_trans_appl_UMTS.htm


15/89

3.3.5. Neighbor List Definition

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 RFfailures due to missing neighbor relations and minimizes the amount of drive testing.

Neighbor list assignment during pre-optimization is required for network expansions sincenew cell sites will be integrated into commercials networks. The neighbor assignmentsinclude the neighbor list verification of the 1st, 2nd and 3rdtier cell sites. The 3G-2G neighborrelations must be declared for overlay networks (refer to UMTS IRAT OptimizationGuidelines)

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 andtarget 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 1below presents onepossible strategy for a UMTS / GSM900 / DCS1800 network. The strategy here is to use theDCS 1800 cell sites only as capacity expansion for GSM 900, therefore the 3G / DCS1800handover is declared one way.

!a*le 1 " +andover Relation Scenarios

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



Page 15 of 89

Sector ell Source Tar#et Sector ell ,'-.' Declaration .'-,' Declaration

3G UMTS Cell Site

Co-located GSM 900Cell Site

YES YES

Neighbor locatedGSM 900 Cell Site

YES YES

Co-located DCS1800Cell Site

NOOnl i! "G cell #ite i# in#ide 3G co$erageof

e.g. Ec%No & -9 d'

Neighbor located

DCS 1800 Cell Site NO

Onl i! "G cell #ite i# in#ide 3G co$erageof

e.g. Ec%No & -9 d'

3G UMTS Cell Site"G Micro Cell Site(Ca)acit*

NOOnl i! "G cell #ite i# in#ide 3G co$erageof

e.g. Ec%No & -9 d'

3G UMTS Cell Site"G Micro Cell Site(Co$erage*

YES YES
http://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS_IRAT_OptimizationGuideline.pdfhttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS_IRAT_OptimizationGuideline.pdfhttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS_IRAT_OptimizationGuideline.pdfhttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS_IRAT_OptimizationGuideline.pdf


16/89

If prediction tools are not available, a visualization tool such as MapInfo (preferably incombination with Google Earth) can be used for neighbor planning. Hereby following basicrules can be applied, refer to Figure 4.

The neighbor list for cell 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 3rdtier cells (purple)

Figure , " General -eigh*or Relation Rules

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



Page 16 of 89


17/89

Another method of neighbor list planning is the usage of the 2G / 2G handover matrix usuallyprovided by the GSM OMC. These matrixes provide the distribution for each GSM cell sectorin 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 cellsites.

Neighbor lists are declared on a per cell basis at the OMC-U. The recommended strategy isto limit neighbor relations per cell site to an acceptable minimum. The general rule is that thenumber of neighbor relations per handover type shall not exceed 15. An optimum is toachieve 10 to 12 neighbor relations per cell site and per handover type. (e.g. 12x 3G3Gand 12x 3G2G relations). It should be noted that there is a limitation on the RNC levelregarding 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 thecombined lists per handover type are limited to 32.

Aside from any neighbor planning method, neighbor relations will need to be verified duringthe drive test optimization. As mentioned before, proper neighbor planning drasticallyminimizes the amount of drive testing. Please refer to Chapter 3.4.3.3 that provides someadditional information regarding neighbor relation aspects.

3.3.6. Scrambling Code Assignment

The scrambling code assignment must be completed prior to the operational stage of thenew 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 requiredfor network expansions. For new network deployments new scrambling code plans areusually in place. If the scrambling code planning is task of the RF optimization team, planningstrategies 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 samescrambling code. Also cells declared as neighbors 1st and 2nd order must not use the samescrambling code. The UE must not receive similar scrambling code power of the sameprimary code from different cell sites.

During initial cell search, the UE performs the three-step cell search procedure to determinethe used scrambling code by the detected cell. In the first stage the UE detects the cell (P-SCH), in the second stage the scrambling code group (S-SCH) and finally in the third stagethe UE acquires the primary scrambling code (out of 8).

The different code planning strategies are consequences of the above mentioned cell searchstages. One way of planning would be to assign different primary codes (0-7) to neighboringcells belonging to the same code group. This would minimize the processing time used forthe second stage. The second way is to assign different scrambling codes to the neighboringcells using the same primary code (0-7). This would minimize the processing time used forthe third stage of cell search. The optimum code plan might be a trade between optimizingthe second and third cell search stage. The algorithms used during the cell search are UEvendor dependent and its performance might differ from UE to UE.



Page 17 of 89


18/89

The common code planning strategy is to assign different scrambling groups to theneighboring cells using the same primary codes (0-7). This guarantees a maximal distancebetween 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 belimited 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 5below shows an example of this method. The clusters consist of 57 cells (19 cell sites). Thescrambling code groups are assigned clockwise from 1-57, starting with the cell in the middleof the cluster. Each cluster will utilize the same primary code (0-7), e.g. the green cluster willutilize 0, yellow 1 and blue 2.

Figure . Scram*ling Code Group Assignment

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



Page 18 of 89


19/89

Assigning manual scrambling codes for new cell sites the following aspect should also benoted. The final distance between scrambling code reused must not only depend anconsideration of e.g. best server plots of the cells using the same scrambling code. Possible

scrambling code reuse conflicts caused by 2 ways handover scenarios must also beconsidered, see Figure 6.

Figure / Scram*ling code reuse conflict

The mobile moves into soft handover of SC300^1 and SC200. The new combined neighborlist 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 newcombined 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 reuseconflict is given for SC300 via 2 way handover relations.

3.3.7. Pre-Optimization using Ocelot

Pre-Optimization can also be performed using Lucent Technologies optimization tool

Ocelot. Ocelotperforms 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 Ocelotis usually an entirely independent process that is intended to perform RF

optimization system wide on commercial networks. This process is complex and propagationdata, as well as traffic models and can process scanner measurement data. In spite of the

complexity in using Ocelot, Ocelotcan be an essential tool during the Pre-Optimization

phase. It ensures a balanced network or cluster in advance and might minimize the amountof drive testing required for the primary RF Optimization phase. For detailed informationplease refer to the M&P documents on Global RF Methods and Procedures / Tool Support



Page 19 of 89

S ,//01S 1//

S .//

S ,//0.

Mo%ile

NBNB NB
http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://globalrfmandp.wh.lucent.com/http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://globalrfmandp.wh.lucent.com/


20/89

3.4. RF Drive Test Based Optimization

3.4.1. Overview

RF Drive Test Based Optimization is the primary phase of the RF optimization and consistsof three stages encompassing the following activities:

Site Readiness

o Spectrum Clearance

o Antenna Audit

o Sector Verification

o Baseline Existing System

RF Optimization Planning

o Perform Parameter Audit

o Neighbor List Audit

o Scrambling Code Plan Audit

o Tool Readiness

o Define Clusters

o Drive Route Planning

RF Optimization Execution

o Cluster Optimization

o System Verification

RF Drive Test Based Optimization is in detail described by the M&P RF Optimization UsingDrive Tests Process.Also specifics of each task are provided by the individual M&P sublayer documents. The following Chapters shall provide the RF engineer with the essentialsteps and hints for performing the RF drive test optimization.

3.4.2. Site Readiness

3.4.2.1. Overview

The Site Readiness procedures are health checks that ensure satisfactory performance ofcell sites. These health checks are mainly performed after deploying new networks or cellsites and should be usually covered by the integration team, e.g. antenna audit or sectorverifications. In general it is not part of the RF optimization except when it is required bycontractual obligation.

There are specific situations that require heath checks to be performed even when notrequired by the contractual obligation. For example base lining the existing network isessential during the network swapout scenario. Specific network issues found during the RFoptimization might require spectrum clearance tests or individual cell site verifications tests.



Page 20 of 89
http://windex.ih.lucent.com/dsweb/Get/Document-117715/D032_RF+Optimization+Using+Drive+Tests+Process.dochttp://windex.ih.lucent.com/dsweb/Get/Document-117715/D032_RF+Optimization+Using+Drive+Tests+Process.dochttp://windex.ih.lucent.com/dsweb/Get/Document-117715/D032_RF+Optimization+Using+Drive+Tests+Process.dochttp://windex.ih.lucent.com/dsweb/Get/Document-117715/D032_RF+Optimization+Using+Drive+Tests+Process.dochttp://windex.ih.lucent.com/dsweb/Get/Document-117715/D032_RF+Optimization+Using+Drive+Tests+Process.doc


21/89


22/89

Sector tests are usually part of the cell site deployment performed by the integration team. Itincludes a set of function tests in order to verify that each sector is transmitting with theappropriate 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 byperforming short drive tests around the cell site. It is also desirable to perform performancetests such as call setup for CS (Voice/Video) and PS (FTP). Additional tests might be theverification 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 functionaltests 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 thedata, which are then post-processed by the RF engineering team using Lucent LDAT3G orCouei XCAP. If sector problems exist, appropriate actions need to be taken. The sector testshould be repeated until all tests succeed.

Note: It is common during network deployments that the Integration Team performs only avoice test call from the site. In this case it needs to be decided by the project team weathercomplete sector verification tests are required.

3.4.2.5. Baseline Existing System

The primary objective for the Baseline Existing System task is to collect and document KeyPerformance 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 collectedduring the first optimization drives that represent the existing systems performance. Forperformance comparison purposes, it is important to keep the drive routes and metricsidentical. Drive routes and KPIs must be agreed upon with the customer.

3.4.3. Optimization Planning

3.4.3.1. Overview

The Optimization Planning phase emphasizes all tasks necessary to ensure readiness for RFOptimization. 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 optimizationefficiency.

Prior to any network modification it has to be ensured the latest network configurationdatabase is complete and up to date, especially concerning design parameter such as anantenna height, tilt and azimuths.



Page 22 of 89


23/89

3.4.3.2. Perform RF Parameter Audit

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

consistency with the UMTS parameter catalogue. The parameter catalogues should beprovided by the customer (vendor dependent) and contain the network parameter definitionsincluding recommended (default) settings. In any case the RF parameter setting lists andpossible parameter model definitions used in the network should be obtained. At thisoptimization stage all RF parameter are already assigned, for new parameter assignmentsplease 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 incorrectmodel definitions in the entire network. If the investigated parameters show high deviationfrom the recommendation settings, then the customer should be informed. Any parametermodification in order to improve network performance (e.g. IRAT parameters) should beperformed at a later step during the RF optimization.

The RF parameter audit can also provide the optimization engineer general views regardingthe network settings and its general behavior regarding network access (cell selection) orhandover conditions. This information can be very helpful during the network analysis lateron.

In case parameter-setting lists are unavailable in the beginning, important RF parameter canalso be verified within the system information blocks (SIB).

RF parameter settings and parameter models for Lucent deployed networks are obtainedeither from the NDP Web Portalproject database or directly from the OMC-U. The parametercatalogue (ParCat) is also available on this web portal. Detailed descriptions of all RFparameter including recommendation settings are provided by the Translation and

Application Notes.

3.4.3.3. Neighbor List Plan Audit

A correct neighbor list is one of the most important demands for ensuring reliable networkperformance. Missing neighbor relations would not only cause severe call failures (drop calls)but extensive drive tests during RF drive test optimization, therefore neighbor list verificationprior to the drive testing is highly desired.

The complete neighbor list verification is a very time-consuming process. If it is not part ofcontractual obligation, then an estimate of the extent of this verification shall be performed inadvance. 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 toolssuch as MapInfo in combination with GoogleEarth can help assess the neighbor lists. Moreinformation regarding neighbor planning are provided by Chapter 3.3.5. The neighbor listchecks should include:

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

department).

Verification of the amount of neighbor relations (


24/89

Searching for any obvious missing neighbor relation (NB lists with entries of only 3-

5).

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 isindicated, then the neighbor list verification is completed. Further verifications will beperformed 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 entirenew neighbor plan can be considered.

The implemented neighbor lists can be verified in the OMC-U, in appropriate networkmaintenance tools or even from the prediction tools if in sync with the OMC-U. For LucentUTRA deployed networks the neighbor lists can be obtained from either the NDP Web Portalproject database or directly from the OMC-U.

3.4.3.4. Scrambling Code Plan Audit

The scrambling code verification is a minor task and necessary for the RF drive testoptimization. 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 inverifying a meaningful code plan. If a poor code plan is observed, appropriate action must betaken (address to RF department). The primary code planning is addressed in further detailin 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 7below display the reuse of SC300 (red) and hence a conflict of the scrambling code plan(reuse distance of SC300 too low).

Figure 0 Scram*ling code reuse conflict



Page 24 of 89

(C300
http://ge1884ndp01.de.lucent.com:7779/portal/page?_pageid=35,31210&_dad=portal&_schema=PORTALhttp://ge1884ndp01.de.lucent.com:7779/portal/page?_pageid=35,31210&_dad=portal&_schema=PORTAL


25/89


26/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 andcluster size, as well as customer preferences regarding cell readiness and priority.

Cluster sizes are also dependent on the network scenario. Small networks or regions lessthan 20 cell sites should be determined as a single cluster. Networks of 20 to 40 cell sitesshould be divided into 1 to 3 clusters. For larger networks, each cluster should range in sizefrom 12 to 19 cell size.

Some examples of cluster definitions are provided in the following Chapters. Clusterdefinition is especially important for the optimization of new network deployments.

3.4.5.2. Cluster Definition for New Network Deployment

[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 topographicalenvironment. The clusters are selected to provide a centre cell site with two rings ofsurrounding cell sites as shown below in Figure 8. It is advisable to utilize natural barrierssuch as hills, rivers, RNC borders, etc. for cluster separation to minimize overlap andinfluence between the clusters. Some cell site overlap should remain between each cluster toensure seamless coverage across the boundaries. Special attention is required for theborder areas of the UMTS clusters. The border between two clusters should be as small aspossible to minimize the possible influence between the clusters. These cluster scenarioscan mainly be found in urban areas with large cell site deployments (>70 cell sites).

Figure " Cluster 2efinition for -e' 2eplo3ments



Page 26 of 89

luster1

luster ,

luster .

'ater


27/89

3.4.5.3. Cluster Definition for a Small New Deployment

[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 (cellsites 110). For the cluster definitions, the same rules are applicable. It is preferable todefine 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.

Figure 4 " Cluster 2efinition -e' 2eplo3ment 5region6

3.4.5.4. Cluster Definition for Network Expansion

[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 arebeing added for coverage or capacity purposes. New cell sites are only grouped to onecluster if they are connected to each other within 1st or 2nd cell tier. Figure 10below is anexample where two new cell sites are integrated into a commercial network area. The clustershall include all cell sites of 1st and 2nd tier as well as all cell sites that might influence theoptimization work and hence the performance verification later on.

Figure 17 " Cluster 2efinition for net'or8 #$pansion

3.4.5.5. Cluster Definition for Island Site Deployment

[New deployment of island cell site(s) into area of non-existing cell sites of same RAT]



Page 27 of 89

luster 2

luster 2)ighway

ExistingBorder Cell Sites


28/89

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

Figure 11 " 2eplo3ment of 9sland Cell Site

3.4.5.6. Cluster Definition for Existing Network

[Existing, commercial network]

RF optimization for an existing, commercial network might not require specific clusterdefinitions. Clusters might be defined according optimization purposes (hot spot, customercomplaint areas), driving routes, contractual obligations and resources as well time-line. Acommon 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 islanddeployments.

Figure 1( " Cluster 2efinition for e$isting net'or8: no' ne' deplo3ments



Page 28 of 89

C)

C(C1

C,

ExistingCell Site

+igh'a3

luster2


29/89

3.4.6. Drive Route Planning

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 tothe contractual obligations, customer demands and network scenario. Driving routes fornetwork performance verifications should always be determined within the service coverageof the network utilizing coverage prediction plots or signal strength surveys.

It is recommended to plan all driving routes with appropriate visualization tools similar toMapInfo. After determining the routes, drive route data are imported into the navigationsystem used by the drive test vehicles. The drive route planning is a very time consumingprocess and should not be underestimated.

Driving routes are classified according to its objectives and can be classified as verificationroutes, optimization routes, border routes, system verification routes, outer coverage routesand 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 oftwo or more days, based on a 6-hour drive per day.

Figure 1) " !3pes of 2riving Routes

Verification Drive Route



Page 29 of 89

C(

C1

C)

Outer overa#e Route

luster Border Route

Optimization Route

$eri"ication Route

S!stem $eri"ication Route

%nderl3ing S3stemCell Sites

;ater


30/89

Verification routes are defined for cluster performance verification. These drives are used todemonstrate reliable network performance in order to obtain customer approval for RFoptimization completion. Verification routes must have customer approval.

The routes for cluster verification should consist of major roads, highways, bridges andhotspots, but the customer determines actual routes. The lengths of the routes are alsodependent on the number of required samples per verification test (e.g. number of voicecalls). If the clusters are too small for efficient drive tests, then a few stationary tests might beconsidered.

System Verification Route

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

Optimization Route

Optimization Routes are individually defined by the RF optimization team and are determinedaccording optimization objectives. Extensive drive tests are required for neighbor list orcoverage verifications (scanner analyses). Problem areas showing high failures rates or pilotpollution require special investigations and individual drive tests. An optimization route doesnot require customer approval.

Optimization routes are required for large clusters sizes (urban areas) in particular. Smallerclusters 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 borderroute is chosen by the way it crosses the cluster borders. Border drives are mainly used forneighbor relation verifications. Border verification drives may be required depending oncontractual 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 usuallyincluded in the optimization drives.

Outer Coverage Route

The Customer may request a drive route in an area outside of the designed coverage area todetermine 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 routesand these routes should not be included in verification routes (exit drives). Outer coverageroutes may be required for smaller network deployments in rural areas. Outer coverageroutes are used in addition for inter system Handover verifications.



Page 30 of 89


31/89

3.5. RF Optimization Execution

3.5.1. Overview

The RF Optimization Execution consists of optimization drives, problem area identificationand clearance, and finally verification drives to ensure completion of Exit Criteria (seechapter 6).

The primary activities are to provide system tuning, data collection, and reporting. Designchanges relating to cell site layout modifications or adding a new cell site may be consideredif 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 interferencepresent. 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 andmodified 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 makeit easier to track the parameter changes and the impact on their performance. Anotherbenefit to smaller cluster optimization is that multiple teams can optimize different clusterssimultaneously. Each team is able to maintain focus on its cluster with minimal impact fromother teams. Additionally, smaller cluster optimization aids in speeding up system tests forcommercial operation. Optimization in equipped clusters can proceed simultaneously withinstallation of other clusters.

System Verification is the final phase of the RF Drive Test Based Optimization activity and itfocuses specifically on collecting overall performance statistics for customer acceptanceapproval. System Verification will begin after all clusters in the UMTS network have beentested.

3.5.2. Cluster Optimization

3.5.2.1. Cluster Optimization for New Network Deployments

Cluster optimization should be performed on fully deployed network sections. This avoids re-testing of previously optimized clusters in case the cell sites are integrated later. All cell sitesin 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, unloadedtests 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 especiallyregarding neighbor relations, loading conditions or excessive coverage cells. It isrecommended to finish the unloaded cluster tests for all clusters within the network ornetwork sections before continuing with the loaded cluster tests. After a small set of adjacentclusters pass the Exit Criteria, a border exit drive must be performed. The border exit driveshould be performed under loaded conditions in order to verify and confirm the Exit Criteriaat the borders of the clusters.



Page 31 of 89


32/89

Verification drives in areas outside of the designed coverage area (outside the clusters) maybe required to mitigate excessive coverage and scattered coverage footprints. Verification ofseamless service coverage by inter system handovers is required for overlay networks.

For each drive test an analysis is performed including failure analysis, Key PerformanceIndicator verification as well individual network investigations regarding optimization aspects.Appropriate reports must be produced according to customer requirements. The reports mustbe clear and concise since each network modification requires customer approval. In additionit is essential to carefully track any recommendations for network modifications and itsimplementation status.

The required data collection, processing and analysis tools for Cluster Optimization are aphone-based data collection tool kit including e.g. XCAL, CAIT3G, UMTS terminal(s) as wellas post-processing tools like XCAP, or LDAT3G. In addition to the phone-based tool kit, ascanner-based tool Agilent is used for power measurements on the physical UMTSchannels. The scanner is an important tool because it is capable of multiple pilot

measurements. This is useful depth coverage analysis (e.g. pilot pollution, missingneighbors) 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 networkconditions using the optimization route. Verification drives at the beginning for performancecomparison 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. Thefirst pass might lead to correction of neighbor lists and adjustments of the fundamental RFparameters such as transmit powers, antenna azimuths, and antenna tilts. The drive testinformation highlights fundamental flaws in the RF design under best-case conditions. Forlarge cell site deployments in urban areas it is recommended to perform a scanner analysisto 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 thesame routes as those used for the unloaded measurement drives. Loaded testing produces arise 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 cornereffects by fine-tuning the RF parameters such as the transmit power or handoverparameters. Antenna re-adjustments (e.g. down-tilts, azimuths, patterns/types or heights) areoccasionally performed.

Problem areas are normally re-driven after implementing changes. If the problem cannot beresolved after a certain amount of time, then a root cause analysis is performed. It isgenerally not recommended to attempt resolution of complex time-intensive performanceissues. For such problems, it is advisable to report the behaviour and proceed with the nextcluster.



Page 32 of 89


33/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 thecustomer.

In general Optimization routes can be utilized for the verification drives after customerapproval. 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 theanalysis of remaining network failures, coverage plots based on scanner data and tables ofKPIs.

Measurement statistics from out of coverage areas (coverage holes) should not beconsidered 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 notapproved, loaded cluster optimization must be continued until the troubles are resolved. Areport 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 beaddressed later in this document. For specific troubleshooting scenarios such as for callsetup failures, drop calls for both CS and PS, refer to the < UMTS RF Performance Analysisand Troubleshooting Guideline>.

3.5.2.2. Cluster Optimization for Networks different to New Network Deployments

The previously described cluster optimization procedures for new network deployments areapplicable for all network scenario types. Small variations for other network scenarios shallbe 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 systemhandovers. The coverage extension needs to be verified, scattered coverage should bemitigated to provide sharp coverage borders between UMTS and e.g. GSM. Intra systemhandover to cells close to the new deployment cluster (e.g. highway cells) need to beconsidered for performance verification. The cluster areas are usually not large. Thereforefor cluster optimization and verification the same routes are used.

Performance data collected in out of coverage areas are usually excluded from theperformance verification during the exit drives, depends on contractual obligations. Thisapplies for performance data such as PS data and CS Video data. CS voice performancedata are usually used to demonstrate reliable inter system handovers.



Page 33 of 89
http://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.ziphttp://rfcoresupport.wh.lucent.com/Guidelines_documentation/UMTS%20RF%20Performance%20Analysis%20&%20Troubleshooting%20Guideline%20Final%20U01.03.zip


34/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 cellsite(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 firstverification drive is used for the performance starting point. After the optimization iscompleted the cluster performance can be compared with the starting point to demonstrateimprovements.

The procedures used for optimizing existing networks are similar to cluster optimization fornew 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 pilotpollution.

3.5.3. System Verification

System verification is the final phase of the RF Drive Test Based Optimization activity and itfocuses specifically on collecting overall performance statistics. System verification will beginafter all clusters in the UMTS network have been tested, and are performed under loadedconditions with all cells activated. System verification involves fusion of the previouslyoptimized clusters and is required to demonstrate that Exit Criteria are met system-wide. Theexact system test requirements are defined in the customer contract.

The system verification route covers major highways and primary roads in the definedcoverage area. The focus is on the problem areas identified during cluster optimization. Theprocedures 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 acoverage hole that will be fixed by a future cell site addition. These items should be welldocumented 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 drivetest. The UMTS network is ready for live traffic testing, which will lead into commercialservice (in case of a new network deployment). Once significant loading with live traffic ispresent on the network, additional tuning of system parameters will be required toaccommodate uneven traffic conditions (e.g. traffic hot spots) and other dynamic effectswhich cannot model with a simulated traffic loading.



Page 34 of 89


35/89

44. RF Optimization Tools

4.1. General

The tools used for RF Optimization can be classified into data collection tools, data analysistools, optimization UTRAN network features and data application tools.

Figure 14 below dislpays an overview of tool classification in the field.

Figure 1, 2rive !est


36/89

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 providedby several individual documents available on the M&P portal.

4.2. Drive Test Based Optimization Tools

This Chapter shall provide an overview of the different tool types used for RF drive testoptimization. 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 Toolsare diagnostic driving and collection tools. They log andanalyze using real time displays both UL/DL air interface messages (Layer 1-3) and DLperformance measurements (e.g. DL BLER) from UMTS test terminals (UEs). Air interfacemessages and performance data are collected by test mobiles. Several test mobiles can beused 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



Page 36 of 89
http://rftoolslab.web.lucent.com/http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://navigator.web.lucent.com/index.htmhttp://navigator.web.lucent.com/index.htmhttp://globalrfmandp.wh.lucent.com/http://rftoolslab.web.lucent.com/http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/toolspage.htmhttp://navigator.web.lucent.com/index.htmhttp://globalrfmandp.wh.lucent.com/


37/89

Measurement collection tools are usually entire optimization platforms consisting of both themeasurement collection software tool and the analyzing software tool for post-processing.

Optimization platforms as from Ascom, Focus, Couei and SwissQual consist of a stationarytests system in addition to the mobile drive test system, allowing auto voice calls in bothdirections (mobile originated and mobile terminated calls). Audio files are exchangedbetween the mobile and stationary system, proving an evaluation of the voice quality basedon Mean Opinion Score (MOS) [EG ITU-T 862 / 862.1]. However, usually the mobile drivetest system platform is in general efficient for basic RF optimization.

Scanner Measurement Toolsmeasure the UMTS physical layer. The system performsabsolute and relative channel power measurements of the Primary Synchronization Channel(PSCH), Secondary Synchronization Channel (SSCH) and the Primary Common PilotChannel (P-CPICH). These three channel measurements can be performed simultaneouslyfor multiple scrambling codes. Dual and tri band scanners are able to perform similar powermeasurements 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 Terminaltypes used during theRF Optimization. Terminals are considered by their commercial availability, compatibly to themeasurement collection tools, and area of application (e.g. HSDPA, dual mode operation,Video). Utilized UMTS test terminals should also have the availability of charging duringoperation and should support external car roof antennas.

Readers should note that the at this relatively early stage in UMTS UE development, theperformance of the UEs has been found to vary considerably. Consequently the type of UEused for the measurements can have a significant effect on the results that are obtained. It isrecommended that wherever possible a range of different UEs should be available, and theirperformance 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 isproviding 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)



Page 37 of 89


38/89


39/89

Analysis Tools

Supplementary Tools

Analysis Toolsare 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 lowperformance 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 withthe measurement collection tools from Agilent Nitro and or Qualcomm CAIT3G.



Page 39 of 89


40/89

4.3. Service Measurement Based OptimizationTools

Service measurement tools must be utilized during the Service Measurement BasedOptimization. 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 networkperformance data (KPIs). Appropriate post-processing tools are used to evaluate theseperformance data. Such tools, like Lucents SPAT3G / LUNAR are used to generate servicemeasurement metrics based on the data received from the OMC-U. Thus, a rapididentification of trouble spots is ensured.

SPAT3G (System Performance Analysis Tool) and LUNAR (Lucent Network AnalysisReality) for 3G networks are Windows-based PC tool used to troubleshoot and analyze theperformance of a live network using data sources including Service Measurements, Per CallMeasurement 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 onpre-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. Supplementary Tools

Supplementary Tools are helpful or required during the optimization process.

WIND is an UDP-based application that acts as a constant configurable data source andreceiver. The key characteristic of the User Datagram Protocol (UDP) is that retransmissionson the user protocol are not performed. Use of these UDP test data transfers is preferred totest and characterize the air interface performance.

WINDSruns on a Server connected to the fixed (core) network, and will communicate withany number of WINDS applications installed on wireless terminals.



Page 40 of 89
http://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/WINDS.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/WINDS.htmhttp://rfcoresupport.wh.lucent.com/RFCoreSupportWebPage/WINDS.htm


41/89

An extension of the LDAT3G post-processing tool is the ability to read and process WINDSlog files. LDAT3G will be able to plot application layer statistics such as throughput andpacket 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.

MapInfois used in parallel with the analysis tools. MapInfo is a very effective tool that canhelp to assess the network performance with regard to the network design by using scannermeasurement 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 anexample of a MapInfo plot.

Figure 1/ " ap9nfo Plot #$ample

GoogleEarth is a Internet tool displaying detailed satellite images of urban areas. Thisefficient tool is used to perform network investigations regarding terrain conditions. It helps tojudge on excessive cell coverag