UMTS RF Optimization Guideline v3-1

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 Too s ...........................................................................................35 5. !pp ication Tests "or #et$or% Per"ormance &eri"ication ....................................44 6. '(T) Per"ormance (etrics..................................................................................49 *. '(T) RF Parameters............................................................................................52 +. RF Optimization !spects........................................................................................59 9. ,e"initions o" Terms...............................................................................................*1 1-. ,e"initions .quations...........................................................................................+11. !//re0iations.........................................................................................................+4
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 do!"ment# "$date a!!ording mar%et e&$erien!es Review Version
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.
2
2. 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 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
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 o o o Access network UTRAN Core network GSM and UMTS Interworking
UMTS radio link and radio resource management o o o o o o o o 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 o Power Control Handover
UMTS system services o 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):
Pre" Optimization Site Readiness

M&P Documents
Optimization Planning Optimization #$ecution
M&P Documents RF Tools Lab Global RF Core Support Homepage 'avigator Portal
RF !ools
% ! S RF Op tim izat ion
!est Applications
Scope of Work / Acceptance Test Plan (ATP)
Performance etric RF Parameters
UMTS RF Performance Analysis and Troubleshooting Guideline
Translation and Application Notes
Optimization Aspects
UMTS RF Performance Analysis and Troubleshooting Guideline
Translation and Application Notes
% !S &no'ledge
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. RF Optimization Process
3.1. RF Optimization Process Overview
3
Service Measurement Based Optimization
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)
RF Optimization Start
Drive Test Based Optimization
Figure ( Overall Optimization Process
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
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 usin#
Ocelot
RF Desi#n $eri"ication New ell Deplo!ment
Optimization Process
PreOptimization
RF Parameter De"inition Nei#&%or +ist De"initions Scram%lin# ode *ssi#nments
Service Measurement Based Optimization

Re"er to RF Trou%les&ootin# 'uideline
Drive Test Based Optimization

Spectrum learance *ntenna *udit Baseline ()istin# S!stem Sector $eri"ication
Site Readiness
Optimization Plannin#
luster De"inition Drive Route Plannin#
RF Parameter *udit Scram%lin# ode Plan *udit Nei#&%or +ist Plan *udit *ntenna *udit luster Optimization S!stem $eri"ication
Optimization ()ecution
Figure ) Optimization Process
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 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.
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 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. 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 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. New Cell Deployment 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. RF Parameter Definition 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. 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 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 ell Source Tar#et Sector ell Co-located GSM 900 Cell Site Neighbor located GSM 900 Cell Site Co-located DCS 1800 Cell Site Neighbor located DCS 1800 Cell Site "G Micro Cell Site (Ca)acit * "G Micro Cell Site (Co$erage* ,'--.' Declaration YES YES NO NO NO YES .'--,' Declaration YES YES Onl i! "G cell #ite i# in#ide 3G co$erage of e.g. Ec%No & -9 d' Onl i! "G cell #ite i# in#ide 3G co$erage of e.g. Ec%No & -9 d' Onl i! "G cell #ite i# in#ide 3G co$erage of e.g. Ec%No & -9 d' YES
3G UMTS Cell Site
3G UMTS Cell Site 3G UMTS Cell Site
!a*le 1 " +andover 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.
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 , " General -eigh*or 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.
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. Scrambling Code Assignment 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.
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 . Scram*ling 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.
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
S ,//0. NB S ,//01 S .// NB S 1//
NB
Mo%ile
Figure / Scram*ling 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. Pre-Optimization using Ocelot 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
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 consists of three stages encompassing the following activities: Site Readiness o o o o Spectrum Clearance Antenna Audit Sector Verification Baseline Existing System
RF Optimization Planning o o o o o o Perform Parameter Audit Neighbor List Audit Scrambling Code Plan Audit Tool Readiness Define Clusters Drive Route Planning
RF Optimization Execution o 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. Site Readiness
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.
3.4.2.2. Spectrum Clearance Verification
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. Antenna Audit
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. Sector Verification
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.
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. Baseline Existing System
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. Optimization Planning
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.
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 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. Neighbor List Plan Audit
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).
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. Scrambling Code Plan Audit
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).
(C300
Figure 0 Scram*ling code reuse conflict Copyright 2006 Lucent Technologies Unpublished and Not for Publication All Rights Reserved Page 24 of 89
3.4.4. Tool Readiness 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. Define Clusters
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.
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. 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 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).
luster1
luster .
luster ,
'ater
Figure 1 " Cluster 2efinition for -e' 2eplo3ments
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 (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
)ighway
luster 2
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 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.
luster 2 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] 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
luster 2
+igh'a3
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 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.
C(
C1
C, C)
Figure 1( " Cluster 2efinition for e$isting net'or8: no' ne' deplo3ments
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 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.
%nderl3ing S3stem Cell Sites
C1 C( C)
Optimization Route $eri"ication Route S!stem $eri"ication Route Outer overa#e Route luster Border Route
;ater
Figure 1) " !3pes of 2riving Routes

Verification Drive Route
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.
3.5.
RF Optimization Execution
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. Cluster Optimization
3.5.2.1. Cluster Optimization for New Network Deployments
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.
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.
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. Cluster Optimization for Networks different to New Network Deployments
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.
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. System Verification 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.
4
4. RF Optimization Tools
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. Anal3sis !ool 5Post"processing6 tool6 -et'or8 Performance 2ata 5-et'or8 Counter6
GPS
Field easurement Collection !ool = 2ata Application !ools 5;9-2S6
R-C
3MTS ore
%#5s6
% !S Scanner -ode <
%!RA- Optimization Features 5OC-S: RF Call !race6
Drive Test +o# File
Anal3sis !ool 5Post"processing6 tool6
Figure 1, 2rive !est <ased !ool 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
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.
Drive Test Based Optimization Tools
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
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)
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 1. RF !ool &its
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.
4.3. Service Measurement Based Optimization 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.
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 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.
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 1/ "
ap9nfo Plot #$ample
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.
Figure 10 " Google#arth 'ith cell data from
ap9nfo
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
5
5. Application Tests for Network Performance Verification
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.
C( Voi!e Calls C( Video Calls *$$li!ation +est P( ,ata (essions )(,P* (essions
Figure 11 " Primar3 Application !ests
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 o 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 14 " !est application Scenario
5.2.
CS Voice Call
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 (7 " Voice >ualit3 !est 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.
CS Video Call
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.
PS Data Sessions
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.
HSDPA Sessions
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.
Example of Test Scenario.
Test Case Example Circuit Switched Voice RF Toolkit Configuration: three User Equipment (UE) + Scanner
Figure 21 below shows a possible test configuration in detail.
Figure 21 Test Configuration
6
6. UMTS Performance Metrics
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:
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: Data: Data Session Success Rate Data Session Drop Rate Drop Call Rate Call Success Rate (originations and terminations) Voice Quality
6.2.
Collecting Key Performance Data
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.
6.3.
Key Performance Indicators
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 = Failures) 100 * (NumRABDrop.sum) (Total Number of RAB Attempts - Total Number of RAB Establishment
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.
7
7. UMTS RF Parameters
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
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: 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
7.2.
Primary Parameters
7.2.1. Neighbor Lists
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. Antenna Parameter 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. Pilot Channel Power 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.
Secondary Parameters
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. Cell Selection / Re-Selection 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 +,-al.in (d'* +r0le$.in (d'.*

Mini.-. re,-ired ,-alit le$el (Ec%No* a cell .-#t ha$e !or #election in idle .ode/ Mini.-. re,-ired 12 le$el (1SC3* a cell .-#t ha$e !or #election in idle .ode/
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.
Cell Select 1e#election Mea#-re.ent +o!!#et1#7n (d'*
+o!!#et"#7n (d'* +h #t1# (d'* +h #t"# (d'* +,-al.in (d'* +r0le$.in (d'.* Tre#election# (ti.e* #5'3SintraSearch #5'3SinterSearch #5'31>TSearch
De!ine# 4hether C35C6 1SC3 (1* or C35C6 Ec%No (0* i# -#ed a# the cell re#election ,-alit .ea#-re/ Thi# $al-e i# con#olidated/ 1eco..ended i# C35C6 Ec%No (0*7 #o +h #t" and +o!!#et" are -#ed/ Thi# #)eci!ie# the o!!#et bet4een the t4o cell# (6 #tere#i# $al-e )rioriti8ing the ran9ing o! the #er$ing cell*/ 5t i# -#ed !or TDD and GSM cell# and !or :DD cell# in ca#e the ,-alit .ea#-re !or cell #election and re-#election i# #et to C35C6 1SC3/ Thi# #)eci!ie# the o!!#et bet4een the t4o cell# (6 #tere#i# $al-e )rioriti8ing the ran9ing o! the #er$ing cell*/ 5t i# -#ed !or :DD cell# in ca#e the ,-alit .ea#-re !or cell #election and re-#election i# #et to C35C6 Ec%No/ 6 #tere#i# $al-e )rioriti8ing the ran9ing o! the #er$ing cell (d'* i! C35C6 1SC3 i# -#ed a# ,-alit .ea#-re/ ;al-e i# not -#ed i! the reco..ended Ec%No ,-alit .ea#-re i# -#ed/ 6 #tere#i# $al-e )rioriti8ing the ran9ing o! the #er$ing cell (d'* i! C35C6 Ec%No i# -#ed a# ,-alit .ea#-re/ Thi# $al-e #ho-ld be increa#ed i! )ing-)ong re#election# are e0)erienced/ Thi# #)eci!ie# the .ini.-. re,-ired 3ilot ,-alit le$el in the cell in d'/ Thi# #)eci!ie# the .ini.-. re,-ired 3ilot 12 le$el in the cell in d'./ Ti.e $al-e <#ec= 4hich de!ine# ho4 long a neighbor cell .-#t be ran9ed higher than the #er$ing cell be!ore thi# cell i# #elected/ > longer ti.e 4ill .a9e )ing-)ong re#election# -nli9el b-t al#o dela the re#election o! a ne4 #ector/ De!ine# a thre#hold !or the ,-alit $al-e S,-al abo$e 4hich the UE #to) )er!or.ing intra!re,-enc :DD .ea#-re.ent#/ De!ine# a thre#hold !or the ,-alit $al-e S,-al abo$e 4hich the UE #to) )er!or.ing inter!re,-enc :DD .ea#-re.ent#/ De!ine# a thre#hold !or the ,-alit $al-e S,-al abo$e 4hich the UE #to) )er!or.ing .ea#-re.ent# !or re#election to4ard# thi# 1>T t )e/
7.3.2. Access Procedure 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.
3o4erO!!#et3). (d'*
31>C6 con#tant ;al (d'* 3o4er 1a.) Ste)
The 3o4er o!!#et 3 )-. ? 3.e##age @ control @ 3)rea.ble7 .ea#-red in d' 5t# #etting ha# to be con#idered along 4ith #etting o! )ara.eter 31>C6 con#tant ;al #ince lo4 $al-e# o! 31>C6 con#tant ;al lead 1>C6 )rea.ble to be detected at a $er lo4 Eb%N07 th-# to #end the 1>C6 .e##age )art at a )o4er le$el too lo4 to be decoded correctl b the Node'/ 6igh $al-e# i.)ro$e the 1>C6 #-cce## rate o! 1>C6 b-t al#o increa#e o! UA inter!erence/ Too lo4 $al-e# .a ca-#e 1>C6 3rea.ble# to be detected at $er lo4 Eb%N0/ Other4i#e 4ith too high $al-e#7 1>C6 3rea.ble# .a be tran#.itted 4ith .ore )o4er than i# nece##ar to be detected7 th-# increa#ing the -)lin9 inter!erence/ The )o4er-ra.)ing !actor 3o4er 1a.) Ste) <integer & 0=/ Trade-o!! bet4een .ini.i8ing UA inter!erence and #)eed -) the #-cce##!-l UE acce## to the net4or9/
Please refer to 3GPP TS 25.303 v3.x.0 Interlayer Procedures in Connected Mode.
7.3.3. Soft/Softer Handover 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

1e)orting 5nter$al :ilter Coe!!icient 3eriodicit o! re)orting hando$er e$ent# (1>B1C* !ro. the UE to the UT1>N/ Thi# )ara.eter a!!ect# the #)eed o! the hando$er )roced-re/ >$erage 4indo4 o! the e$ent .ea#-re.ent# b the UE7 .ean# !or 4hich )eriod an hando$er e$ent i# !-l!illed be!ore #ending a .ea#-re.ent re)ort to the UT1>N/ > narro4 4indo4 4ill #)eed -) the hando$er )roced-re7 b-t 4o-ld al#o ca-#e )ing-)ong e!!ect/
Handover Algorithm
Deacti$ation Thre#hold The )ara.eter #et the .a0i.-. acti$e #et #i8e !or 4hich e$ent 1> can be re)orted/ The o)ti.i8ed $al-e #ho-ld con#i#t in a good trade-o!! bet4een -)lin9-li.ited #cenario# (4here better )er!or.ance# are achie$ed 4ith higher n-.ber o! acti$e #et cell#* and do4nlin9li.ited #cenario# ($ice $er#a*/ The o)ti.-. )oint i# al#o di!!erent !or di!!erent data rate#/ The )ara.eter #et the .ini.-. acti$e #et #i8e !or e$ent 1C to be re)orted/ Thi# )ara.eter #ho-ld be al4a # #et to a $al-e greater than )ara.eter Deacti$ation Thre#hold in order to allo4 E$ent 1C to be re)orted The )ara.eter #et the re)orting range !or a candidate )ilot to be able to trigger e$ent 1> and 1'/ The #.aller the $al-e o! thi# )ara.eter7 the le## re#tricti$e it i#/ The o)ti.i8ed $al-e #ho-ld con#i#t in a good trade-o!! bet4een -)lin9 li.ited and do4nlin9 li.ited #cenario#/ The $al-e o! thi# )ara.eter .-#t be con#idered along 4ith )ara.eter 6 #tere#i#/ 5n ca#e o! !or e$ent 1> the gi$en $al-e decrea#e# the global h #tere#i# !actor !or e$ent 1> .a9ing the triggering condition le## re#tricti$e/ 5n ca#e o! e$ent 1' the gi$en $al-e increa#e# the global h #tere#i# !actor !or e$ent 1' .a9ing the triggering condition le## re#tricti$e/ 5n ca#e o! e$ent 1C thi# h #tere#i# )ara.eter i# the onl one that control# the range !or triggering condition and the gi$en $al-e .ean# that the ne4 candidate cell 4ill ha$e to be b the indi$id-al #etting better than the 4or#t )ilot incl-ded in the acti$e #et !or e$ent 1C to be triggered/ Thi# )ara.eter i# -#ed to li.it the .ea#-re.ent #ignaling load a$oiding Mea#-re.ent 1e)ort .e##age to be #ent b the UE !or a de!ined )eriod o! ti.e d-ring 4hich the triggering condition# !or the related e$ent ha$e e0i#ted/ :or e$ent 1> and 1C it i# not reco..ended to dela the occ-rrence o! the e$ent7 4herea# !or e$ent 1' dela ing the occ-rrence i# i.)ortant in order to en#-re that no lin9 i# dro))ed !ro. the acti$e #et d-e to a #hort !ade in the recei$ed #ignal/ The o!!#et on a cell ba#i# can be either )o#iti$e or negati$e/ 5n ca#e o! e$ent# 1> or 1' the o!!#et i# added to the .ea#-re.ent ,-antit o! the cell candidate to enter or lea$e the acti$e #et re#)ecti$el / 5n ca#e o! e$ent 1C one o!!#et i# added to the .ea#-re.ent ,-antit o! the ne4 candidate cell to enter the acti$e #et and one o!!#et i# added to the .ea#-re.ent ,-antit o! the 4or#t cell incl-ded in the acti$e #et/
>cti$ation Thre#hold
1e)orting 1ange (d'*
6 #tere#i# (d'*
Ti.e To Trigger (d'*
Cell 5ndi$id-al O!!#et
7.3.4. InterRAT Below is list of some typical Inter-RAT HO parameters, changeable on the cell basis:
.ea#-re.ent+-antit 5nte r1>T66O
.aho' G#.Mea#-re.e nt#
Thi# )ara.eter i# -#ed !or 5nter-1>T hard hando$er !ro. UT1>N to GSM/ 5t deter.ine# the ,-antit to be -#ed !or .ea#-re.ent# o! the UMTS !re,-enc / :ollo4ing o)tion# are t )icall a$ailableC a* 1SC3 b* Ec%No c* 1SC3 and Ec%No Thi# )ara.eter enable#%di#able# the .obile a##i#ted hando$er algorith. (M>6O* !or triggering the UMTS to GSM hando$er )roced-re/ The M>6O algorith. i# ba#ed on .ea#-re.ent# o! the GSM cell#/ T )icall 7 M>6O algorith. i# al4a # enabled/ De!ine# GSM .ea#-re.ent# criteria !or inter-1>T 6O !ro. UMTS to GSM 4ith !ollo4ing #-b-)ara.eter# (M>6O*C a* g#.+-alit Thre#holdC S)eci!ie# a $al-e !or the ,-alit o! GSM # #te. !or triggering e$ent 3> and 3C (act-al ,-alit i# abo$e #)eci!ied thre#hold* b* g#.:ilterCoe!!icientC lo4 )a## !ilter !or GSM .ea#-re.ent# (3> B 3C* c* co.binedG#.Neighbo-rAi#tSi8eC Ma0i.-. n-.ber o! GSM neighbo-r cell# related to the acti$e #et 4hich #ho-ld be .ea#-red b the UE De!ine# the .ea#-re.ent# criteria !or acti$ation o! co.)re##ed .ode !or UMTS to GSM 6O 4ith !ollo4ing #-b-)ara.eter#C a* rSC3Thre#holdeCN0Thre#holdC S)eci!ie# a $al-e !or the ,-alit o! the o4n # #te. (UMTS !re,-enc * !or triggering e$ent "D (act-al ,-alit dro)# belo4 #)eci!ied thre#hold#*/ Thi# e$ent i# -#ed to #tart inter-1>T .ea#-re.ent# !or a UE that re,-ire# CM/ b* ti.eToTriggerC S)eci!ie# the ti.e !or 4hich the triggering condition# .-#t be tr-e be!ore the UE #end# an e$ent triggered .ea#-re.ent# re)ort to the UT1>N/ De!ine# the .ea#-re.ent# criteria !or deacti$ation o! co.)re##ed .ode !or UMTS to GSM 6O 4ith !ollo4ing #-b-)ara.eter#C a* rSC3Thre#holdeCN0Thre#holdC S)eci!ie# a $al-e !or the ,-alit o! the o4n # #te. (UMTS !re,-enc * !or triggering e$ent ": (act-al ,-alit ri#e# abo$e #)eci!ied thre#hold#*/ Thi# e$ent i# -#ed to #to) inter-1>T .ea#-re.ent# !or a UE that re,-ire# CM/ b* ti.eToTriggerC S)eci!ie# the ti.e !or 4hich the triggering condition# .-#t be tr-e be!ore the UE #end# an e$ent triggered .ea#-re.ent# re)ort to the UT1>N/ De!ine# the .ea#-re.ent# criteria to trigger UMTS to GSM 6O (M>6O* 4ith !ollo4ing #-b-)ara.eter#C a* rSC3Thre#holdeCN0Thre#holdC S)eci!ie# a $al-e !or the ,-alit o! the o4n # #te. (UMTS !re,-enc * !or triggering inter-1>T M>6O in ca#e o! Ser$ice 6ando$er #et to D#ho-ld notE (act-al ,-alit dro)# belo4 #)eci!ied thre#hold#*/ b* ti.eToTriggerC S)eci!ie# the ti.e !or 4hich the triggering condition# .-#t be tr-e be!ore the UE #end# an e$ent triggered .ea#-re.ent# re)ort to the UT1>N/ c* FeightC S)eci!ie# 4eighting bet4een #tronge#t lin9 and re.aining acti$e lin9# !or co.)-ting the ,-alit o! the o4n # #te. (UMTS # #te.*/
U.t#"G#.6OMea#
-.t#"G#.+>ctCM"D
-.t#"G#.+DeactCM":
-.t#"G#.+TriggerM>6 O
(refer to UMTS IRAT Optimization Guidelines).
7.3.5. HSDPA Below are listed some typical HSDPA parameters:

hSD3>Sr$CellChgCri t/h #tere#i# hSD3>Sr$CellChgCri t/ti.eToTrigger hSD3>Sr$CellChgCri t/-#eC5O o-t:DD>dGCell#/cellO !!#et 6 #tere#i# $al-e !or triggering the change o! the be#t cell 4ithin the acti$e #et/ Ti.e to trigger be!ore a e$ent 1D i# #ent/ 5ndicator 4hether a cell #)eci!ic o!!#et i# -#ed !or e$ent 1D e$al-ation/ Setting o! the cell #)eci!ic o!!#et/
8
8. RF Optimization Aspects
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.
Radio Coverage
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.
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. Coverage Hole or Outer Coverage Area 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. Overshooting Sector Cell Coverage 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
-eigh*or 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. No Dominant Pilot Area 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.
Pilot Pollution
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.
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 (, " 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.
8.3.
Around-the-Corner Problem
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.
>cti$e Set 3ilot 5nter!ering 3ilot
Figure (. Around the Corner Pro*lem
Serving Cell
Fast raising Around the Corner 9nterferer
Figure (/ Around the Corner Pro*lem
8.4.
Near-Far Problem
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 (0 -ear Far Pro*lem
8.5.
Cell Breathing
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).
,/4 +oadin# ell * ell B 5/4 +oadin#
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.
Missing Neighbors
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.
Intra System Handover
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.
Inter RAT Handover
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).
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.
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. Access Failures

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.
9
9. Definitions of Terms
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.
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.
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.
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.
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.
10
10.Definitions Equations
Following RF relevant formulas are given, as specified by 3GPP:
1PI12 - . c I or
.c
.c I or
The ratio o! the recei$ed energ )er 3N chi) o! the C35C6 to the total tran#.it# )o4er #)ectral den#it at the Node' (SS* antenna connector/
>$erage energ )er 3N chi)/ The ratio# o! the a$erage tran#.it energ )er 3N chi) !or di!!erent !ield# or )h #ical channel# to the total tran#.it )o4er #)ectral den#it / The total recei$ed )o4er #)ectral den#it 7 incl-ding #ignal and inter!erence7 a# .ea#-red at the UE antenna connector/ >$erage energ )er 3N chi) !or the OCNS/
Io
O1#) _ .c
O1#) _ .c Ior
The ratio o! the a$erage tran#.it# energ )er 3N chi) !or the OCNS to the total tran#.it )o4er #)ectral den#it /
P 1PI12 ? .c
>$erageH energ )er 3N chi) !or 3-C35C6/
UTRAN measurement abilities
CPICH RSCP
De"inition 1ecei$ed Signal Code 3o4er7 the recei$ed )o4er on one code .ea#-red on the 3ri.ar C35C6/ The re!erence )oint !or the 1SC3 #hall be the antenna connector o! the UE/ 5! T0 di$er#it i# a))lied on the 3ri.ar C35C6 the recei$ed code )o4er !ro. each antenna #hall be #e)aratel .ea#-red and #-..ed together in <F= to a total recei$ed code )o4er on the 3ri.ar C35C6/ 5dle7 Connected 5ntra7 Connected 5nter
*pplica%le "or
UTRA carrier RSSI

De"inition *pplica%le "or The recei$ed 4ide band )o4er7 incl-ding ther.al noi#e and noi#e generated in the recei$er7 4ithin the band4idth de!ined b the recei$er )-l#e #ha)ing !ilter/ The re!erence )oint !or the .ea#-re.ent #hall be the antenna connector o! the UE/ 5dle7 Connected 5ntra7 Connected 5nter
CPICH Ec/No
De"inition The recei$ed energ )er chi) di$ided b the )o4er den#it in the band/ The C35C6 Ec%No i# identical to C35C6 1SC3%UT1> Carrier 1SS5/ Mea#-re.ent #hall be )er!or.ed on the 3ri.ar C35C6/ The re!erence )oint !or the C35C6 Ec%No #hall be the antenna connector o! the UE/ 5! T0 di$er#it i# a))lied on the 3ri.ar C35C6 the recei$ed energ )er chi) (Ec* !ro. each antenna #hall be #e)aratel .ea#-red and #-..ed together in <F#= to a total recei$ed chi) energ )er chi) on the 3ri.ar C35C67 be!ore calc-lating the Ec%No/ 5dle7 Connected 5ntra7 Connected 5nter
*pplica%le "or
Transport channel BLER

De"inition E#ti.ation o! the tran#)ort channel bloc9 error rate ('AE1*/ The 'AE1 e#ti.ation #hall be ba#ed on e$al-ating the C1C o! each tran#)ort bloc9 a##ociated 4ith the .ea#-red tran#)ort channel a!ter 1A co.bination/ The 'AE1 #hall be co.)-ted o$er the .ea#-re.ent )eriod a# the ratio bet4een the n-.ber o! recei$ed tran#)ort bloc9# re#-lting in a C1C error and the n-.ber o! recei$ed tran#)ort bloc9#/ Fhen either T:C5 or g-ided detection i# -#ed7 the .ea#-re.ent DTran#)ort channel 'AE1E .a onl be re,-e#ted !or a tran#)ort channel 4hen the a##ociated C1C #i8e i# non 8ero and at lea#t one tran#)ort !or.at in the a##ociated tran#)ort !or.at #et incl-de# at lea#t one tran#)ort bloc9/ Fhen neither T:C5 nor g-ided detection i# -#ed7 the .ea#-re.ent DTran#)ort channel 'AE1E .a onl be re,-e#ted !or a tran#)ort channel 4hen the a##ociated C1C #i8e i# non 8ero and all tran#)ort !or.at# in the a##ociated tran#)ort !or.at #et incl-de at lea#t one tran#)ort bloc9/ The .ea#-re.ent DTran#)ort channel 'AE1E doe# not a))l to tran#)ort channel# .a))ed on a 3-CC3C6 and a S-CC3C6/ The UE #hall be able to )er!or. the .ea#-re.ent DTran#)ort channel 'AE1E on an tran#)ort channel con!ig-red #-ch that the .ea#-re.ent DTran#)ort channel 'AE1E can be re,-e#ted a# de!ined in thi# #ection/ Connected 5ntra
*pplica%le "or
SIR
De"inition Signal to 5nter!erence 1atio7 i# de!ined a#C (1SC3%5SC3* S:/ Mea#-re.ent #hall be )er!or.ed on the D3CC6 o! a 1adio Ain9 Set/ 5n co.)re##ed .ode the S51 #hall not be .ea#-red in the tran#.i##ion ga)/ The re!erence )oint !or the S51 .ea#-re.ent# #hall be the 10 antenna connector/ 4hereC 1SC3 ? 1ecei$ed Signal Code 3o4er7 -nbia#ed .ea#-re.ent o! the recei$ed )o4er on one code/ 5SC3 ? 5nter!erence Signal Code 3o4er7 the inter!erence on the recei$ed #ignal/ S:?The #)reading !actor -#ed on the D3CC6/
SIRerror
De"inition S51error ? S51 @ S51targetIa$e7 4hereC S51 ? the S51 .ea#-red b UT1>N7 de!ined in #ection J/"7 gi$en in d'/ S51targetIa$e ? the S51target a$eraged o$er the #a.e ti.e )eriod a# the S51 -#ed in the S51error calc-lation/ 5n co.)re##ed .ode S51 target?S51c.Itarget #hall be -#ed 4hen calc-lating S51targetIa$e/ 5n co.)re##ed .ode the S51targetIa$e #hall not be calc-lated o$er the tran#.i##ion ga)/ The a$eraging o! S51 target #hall be .ade in a linear #cale and S51targetIa$e #hall be gi$en in d'/
Transmitted carrier power

De"inition Tran#.itted carrier )o4er7 i# the ratio bet4een the total tran#.itted )o4er and the .a0i.-. tran#.i##ion )o4er/ Total tran#.i##ion )o4er i# the .ean )o4er <F= on one carrier !ro. one UT1>N acce## )oint/ Ma0i.-. tran#.i##ion )o4er i# the .ean )o4er <F= on one carrier !ro. one UT1>N acce## )oint 4hen tran#.itting at the con!ig-red .a0i.-. )o4er !or the cell/ Mea#-re.ent #hall be )o##ible on an carrier tran#.itted !ro. the UT1>N acce## )oint/ The re!erence )oint !or the tran#.itted carrier )o4er .ea#-re.ent #hall be the T0 antenna connector/ 5n ca#e o! T0 di$er#it the tran#.itted carrier )o4er !or each branch #hall be .ea#-red and the .a0i.-. o! the t4o $al-e# #hall be re)orted to higher la er#7 i/e/ onl one $al-e 4ill be re)orted to higher la er#/
Transmitted code power

De"inition Tran#.itted code )o4er7 i# the tran#.itted )o4er on one channeli#ation code on one gi$en #cra.bling code on one gi$en carrier/ Mea#-re.ent #hall be )o##ible on the D3CC6-!ield o! an dedicated radio lin9 tran#.itted !ro. the UT1>N acce## )oint and #hall re!lect the )o4er on the )ilot bit# o! the D3CC6-!ield/ Fhen .ea#-ring the tran#.itted code )o4er in co.)re##ed .ode all #lot# #hall be incl-ded in the .ea#-re.ent7 e/g/ al#o the #lot# in the tran#.i##ion ga) #hall be incl-ded in the .ea#-re.ent/ The re!erence )oint !or the tran#.itted code )o4er .ea#-re.ent #hall be the T0 antenna connector/ 5n ca#e o! T0 di$er#it the tran#.itted code )o4er !or each branch #hall be .ea#-red and #-..ed together in <F=/
Transport channel BER

De"inition The tran#)ort channel 'E1 i# an e#ti.ation o! the a$erage bit error rate ('E1* o! the D3DC6 data o! a 1adio Ain9 Set/ The tran#)ort channel (TrC6* 'E1 i# .ea#-red !ro. the data con#idering onl non-)-nct-red bit# at the in)-t o! the channel decoder in Node '/ 5t #hall be )o##ible to re)ort an e#ti.ate o! the tran#)ort channel 'E1 !or a TrC6 a!ter the end o! each TT5 o! the TrC6/ The re)orted TrC6 'E1 #hall be an e#ti.ate o! the 'E1 d-ring the late#t TT5 !or that TrC6/ Tran#)ort channel 'E1 i# onl re,-ired to be re)orted !or TrC6# that are channel coded/
Physical channel BER

De"inition The 3h #ical channel 'E1 i# an e#ti.ation o! the a$erage bit error rate ('E1* on the D3CC6 o! a 1adio Ain9 Set/ >n e#ti.ate o! the 3h #ical channel 'E1 #hall be )o##ible to be re)orted a!ter the end o! each TT5 o! an o! the tran#!erred TrC6#/ The re)orted )h #ical channel 'E1 #hall be an e#ti.ate o! the 'E1 a$eraged o$er the late#t TT5 o! the re#)ecti$e TrC6/
Round trip time

De"inition 1o-nd tri) ti.e (1TT*7 i# de!ined a# 1TT ? T12 @ TT27 4here TT2 ? The ti.e o! tran#.i##ion o! the beginning o! a do4nlin9 D3C6 !ra.e to a UE/ The re!erence )oint !or TT2 #hall be the T0 antenna connector/ T12 ? The ti.e o! rece)tion o! the beginning (the !ir#t detected )ath7 in ti.e* o! the corre#)onding -)lin9 D3CC6%D3DC6 !ra.e !ro. the UE/ The re!erence )oint !or T 12 #hall be the 10 antenna connector/ Mea#-re.ent #hall be )o##ible on D3C6 !or each 1A tran#.itted !ro. an UT1>N acce## )oint and D3DC6%D3CC6 !or each 1A recei$ed in the #a.e UT1>N acce## )oint/
11
11.Abbreviations
A
*.C) *M *' *RFC' *( *(C *12' *!/"isition .ndi!ator Channel *!%nowledged Mode *!!ess 'etwor% *0sol"te Radio Fre/"en!y Channel '"m0er *!!ess (trat"m *!!ess (ervi!e Class *dditive 1hite 2a"ssian 'oise
B
3C) 34R 354R 3road!ast Channel 3it 4rror Ratio 3lo!% 4rror Ratio
C
CCC) CC) CCPC) C!t CC+rC) C,M* C. CP.C) CPC) CRC C( C(, C+C) C1 Common Control Channel Control Channel Common Control Physi!al Channel Cir!"it Coded Com$osite +rans$ort Channel Code ,ivision M"lti$le *!!ess Cell .dentity Common Pilot Channel Common Pa!%et Channel Cy!li! Red"ndan!y Che!% Cir!"it (wit!hed Cir!"it (wit!hed ,ata Common +raffi! Channel Contin"o"s 1ave 6"nmod"lated signal7
D
,CC) ,C) ,5 ,PCC) ,PC) ,P,C) ,R*C ,R'( ,(C) ,+C) ,edi!ated Control Channel ,edi!ated Channel ,ownlin% 6Forward 5in%7 ,edi!ated Physi!al Control Channel ,edi!ated Physi!al Channel ,edi!ated Physi!al ,ata Channel ,ynami! Reso"r!e *llo!ation Control ,rift R'( ,ownlin% (hared Channel ,edi!ated +raffi! Channel
E
4+( 4+(. 4"ro$ean +ele!omm"ni!ation (tandard 4"ro$ean +ele!omm"ni!ations (tandards .nstit"te
F
F*C) F,, F4R FR Forward *!!ess Channel Fre/"en!y ,ivision ,"$le& Frame 4ras"re Rate# Frame 4rror Rate F"ll Rate
G
22(' 2+P 2+P89 29. 2ateway 2PR( ("$$ort 'ode 2PR( +"nneling Proto!ol 2PR( +"nneling Proto!ol for 9ser Plane 2ra$hi!al 9ser .nterfa!e )andover )igh ($eed Cir!"it (wit!hed ,ata )y$er +e&t +ransfer Proto!ol .ntermod"lation .ntelligent 'etwor% *$$li!ation Part .nternet Proto!ol .nterferen!e (ignal Code Power .nternational :rgani;ation for (tandardi;ation .nternet (ervi!e Provider .nternational +ele!omm"ni!ation 9nion
+
): )(C(, )++P .M .'*P .P .(CP .(: .(P .+9
L
51 53 5*' 55C 5m 5ayer 1 6$hysi!al layer7 5ayer 3 6networ% layer7 5o!al *rea 'etwor% 5ogi!al 5in% Control +raffi! !hannel with !a$a!ity lower than a 3m
M
M*C M!$s Medi"m *!!ess Control 6$roto!ol layering !onte&t7 Mega8!hi$s $er se!ond
N
'*( '3*P 'C455 'on8*!!ess (trat"m 'ode 3 *$$li!ation Part 'eigh0oring 6of !"rrent serving7 Cell Copyright 2006 Lucent Technologies Unpublished and Not for Publication All Rights Reserved Page 85 of 89
O
:<M :C'( :(. RM :+* :V(F :$erations < Maintenan!e :rthogonal Channel 'oise (im"lator :(. Referen!e Model :ver8+he8*ir :rthogonal Varia0le ($reading Fa!tor
P
P8CCPC) P8CP.) PC PCCC) PCC) PC) PCPC) PC9 P,C) P,' P,P P,(C) P,+C) P,9 P)= PhyC) P' PPC) PPP PR*C) P( P(C P(C) P(P,' Primary Common Control Physi!al Channel Primary Common Pilot Channel Power Control Pa!%et Common Control Channel Paging Control Channel Paging Channel Physi!al Common Pa!%et Channel Pa!%et Control 9nit Pa!%et ,ata Channel Pa!%et ,ata 'etwor% Pa!%et ,ata Proto!ol Physi!al ,ownlin% (hared Channel Pa!%et ,ata +raffi! Channel Proto!ol ,ata 9nit Physi!al layer Physi!al Channel Pse"do 'oise Pa!%et Paging Channel Point8to8Point Proto!ol Physi!al Random *!!ess Channel Pa!%et (wit!hed Primary (yn!hroni;ation Code Physi!al (hared Channel Pa!%et (wit!hed P"0li! ,ata 'etwor%
Q
>o( >"ality of (ervi!e
R
R* R*3 R*' R3 R5 R5C R5CP R5P R'C R'( R'(*P RR RRC RRM R(*+ R(CP R((. R13 R? R?54V Ro"ting *rea Radio *!!ess 3earer Radio *!!ess 'etwor% Radio 3earer Radio 5in% Radio 5in% Control Radio 5in% Control Proto!ol Radio 5in% Proto!ol Radio 'etwor% Controller Radio 'etwor% ("0system Radio 'etwor% ("0system *$$li!ation Part Radio Reso"r!es Radio Reso"r!e Control Radio Reso"r!e Management Radio (ystem *!!e$tan!e +est Re!eived (ignal Code Power Re!eived (ignal (trength .ndi!ator Resol"tion 3andwidth Re!eive Re!eived signal level Copyright 2006 Lucent Technologies Unpublished and Not for Publication All Rights Reserved Page 86 of 89
R?>9*5
Re!eived (ignal >"ality
S
(8CCPC) (8CP.C) (*P (3 (CC) (C) (,CC) (,9 (F (F' ()CC) (.R (M (M( (M(8C3 (' (P (>' (R3 (R'C (R'( ((@ ((C (++, (e!ondary Common Control Physi!al Channel (e!ondary Common Pilot Channel (ervi!e *!!ess Point (yn!hroni;ation 3"rst (yn!hroni;ation Control Channel (yn!hroni;ation Channel (tand8*lone ,edi!ated Control Channel (ervi!e ,ata 9nit ($reading Fa!tor (ystem Frame '"m0er (hared Channel Control Channel (ignal8to8.nterferen!e Ratio (ession Management (hort Message (ervi!e (M( Cell 3road!ast ("0s!ri0er '"m0er (wit!hing Point (e/"en!e n"m0er (ignaling Radio 3earer (erving Radio 'etwor% Controller (erving R'( (ignaling (ystem 'o. @ (e!ondary (yn!hroni;ation Code ($a!e +ime +ransmit ,iversity
T
+* +C8+R +CP +,8C,M* +F +' +PC +P,9 +rC) +R? +( +(C +(2 +(+, +? +?P1R +iming *dvan!e +e!hni!al Committee +e!hni!al Re$ort +ransmission Control Proto!ol +ime ,ivision8Code ,ivision M"lti$le *!!ess +rans$ort Format +imeslot '"m0er +ransmit Power Control +ransfer Proto!ol ,ata 9nit +rans$ort Channel +rans!eiver +ime (lot +raining (e/"en!e Code +e!hni!al ($e!ifi!ation 2ro"$ +ime (wit!hed +ransmit ,iversity +ransmit +ransmit PowerA +& $ower level in the M(-+?P1R-R4>94(+ and M(-+?P1R-C:'F $arameters
U
9*RFC' 9*RF' 9,, 9,P 94 9. 95 9M 9M+( 9P 9R*' 9R3 9(C) 9(F 9(.M 9+R* 9+R*' 99. 9+R* *0sol"te Radio Fre/"en!y Channel '"m0er 9+R* *0sol"te Radio Fre/"en!y '"m0er 9n!onstrained ,elay ,ata 9ser ,atagram Proto!ol 9ser 4/"i$ment 9ser .nterfa!e 9$lin% 6Reverse 5in%7 9na!%nowledged Mode 9niversal Mo0ile +ele!omm"ni!ations (ystem 9ser Plane 9M+( Radio *!!ess 'etwor% 9ser Radio 3earer 9$lin% (hared Channel 9$lin% (tate Flag 9niversal ("0s!ri0er .dentity Mod"le 9niversal +errestrial Radio *!!ess 9niversal +errestrial Radio *!!ess 'etwor% 9ser8to89ser .nformation
V
V* Voi!e *!tivity fa!tor
W
1*P 1C,M* 1,P 15*' 1+,, 1ireless *$$li!ation Proto!ol 1ide0and Code ,ivision M"lti$le *!!ess 1ireless ,atagram Proto!ol 1ireless 5o!al *rea 'etwor% 1ide0and +ime ,ivision ,"$le&ing
References
B0C B0C B0C B0C B0C BGC B@C BFC B9C B10C B11C B12C 32PP +( 23.101 VD.0.0# 2eneral 9M+( *r!hite!t"re 32PP +( 2E.301 V3.F.0# Radio .nterfa!e Proto!ol *r!hite!t"re 32PP +( 2E.211 V3.F.0# Physi!al !hannels and ma$$ing of trans$ort !hannels onto $hysi!al !hannels 6F,,7 32PP +( 2E.331 V3.F.0# RRC Proto!ol ($e!ifi!ation 32PP +( 2E.30D V3.F.0# 94 Pro!ed"res in .dle Mode and Pro!ed"res for Cell Resele!tion in Conne!ted Mode 32PP +( 2E.922 V3.G.0# Radio reso"r!e management strategies 32PP +( 2E.21D V3.9.0# Physi!al layer $ro!ed"res 6F,,7 :$tim"m $ower setting for $ilot and !ontrol !hannel# Fran% 3eyer# 5"!ent 1&4V RF :$timi;ation 2"idelines# version 1.09# 0@H11H2002# 0y Vladan Iovanovi!# *n" (andh"# )ayder Jammona# *mit (hah 321& RF :$timi;ation Pro!ed"res and 2"idelines for PC( and Cell"lar C,M* (ystems# Version 1.0# ,e! 2001# 0y ,evesh Patel C,M* RF :$timi;ation Pro!ed"res for 1.9 2); PC( (ystems# Version 1.E3# 'ovem0er G# 199G# 0y V. ,a(ilva# M. Fe"erstein# I. M!4lroy# (. (hio# ?. 1ang C,M* RF P4RF:RM*'C4 *'*5=(. ( < +R:9354()::+.'2 29.,4 R4V 20.0

UMTS RF Optimization Guideline v3-1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UMTS RF Optimization Guideline v3-1

Uploaded by

Copyright:

Available Formats

UMTS RF Optimization Guideline

Issue 3.1 November 2006

Pre" Optimization Site Readiness

Optimization Planning Optimization #$ecution

% ! S RF Op tim izat ion

Scope of Work / Acceptance Test Plan (ATP)

Performance etric RF Parameters

UMTS RF Performance Analysis and Troubleshooting Guideline

Translation and Application Notes

UMTS RF Performance Analysis and Troubleshooting Guideline

Translation and Application Notes

UM1001W UMTS Product Training.

Drive Test Based Optimization

Figure ( Overall Optimization Process

RF Desi#n $eri"ication New ell Deplo!ment

RF Parameter De"inition Nei#&%or +ist De"initions Scram%lin# ode *ssi#nments

Service Measurement Based Optimization

Drive Test Based Optimization

Figure ) Optimization Process

Network Deployment Scenarios

3G UMTS Cell Site

3G UMTS Cell Site 3G UMTS Cell Site

Figure , " General -eigh*or Relation Rules

Figure . Scram*ling Code Group Assignment

S ,//0. NB S ,//01 S .// NB S 1//

Figure / Scram*ling code reuse conflict

RF Drive Test Based Optimization

RF Optimization Execution o o Cluster Optimization System Verification

3.4.2.2. Spectrum Clearance Verification

3.4.3.2. Perform RF Parameter Audit

Figure 1 " Cluster 2efinition for -e' 2eplo3ments

3.4.5.3. Cluster Definition for a Small New Deployment

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

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

Existing Cell Site

%nderl3ing S3stem Cell Sites

Figure 1) " !3pes of 2riving Routes

Cluster Performance Verification

Cluster Optimization for Network Expansion

Please refer to Cluster Optimization for a Small New Deployment.

Field easurement Collection !ool = 2ata Application !ools 5;9-2S6

%!RA- Optimization Features 5OC-S: RF Call !race6

Drive Test +o# File

Anal3sis !ool 5Post"processing6 tool6

Drive Test Based Optimization Tools

Figure 1. RF !ool &its

Analysis Tools Supplementary Tools

4.3. Service Measurement Based Optimization Tools

Supplementary Tools are helpful or required during the optimization process.

ap9nfo Plot #$ample

Figure 10 " Google#arth 'ith cell data from

UTRAN Optimization Features are: OCNS RF Call Trace

Figure 14 " !est application Scenario

Example of Test Scenario.

Figure 21 below shows a possible test configuration in detail.

Figure 21 Test Configuration

Collecting Key Performance Data

Key Performance Indicators

Voice Quality Refer to Chapter 5.2.

7.2.1. Neighbor Lists

Cell Selection +,-al.in (d'* +r0le$.in (d'.*

Cell Select 1e#election Mea#-re.ent +o!!#et1#7n (d'*

31>C6 con#tant ;al (d'* 3o4er 1a.) Ste)

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