Pre-Launch RF Optimization GuidelinesFSC Performance Engineering

Document Initiated January 14, 2008Revision Number 4.0Revision Date March 31, 2008

Table of Contents1.Introduction........5

1.1.Purpose & Scope 51.2.Definitions for this Document 5

2.UMTS technology in brief 82.1.Architecture 92.2.UTRAN Interfaces9

3.Phases of Network Optimization 113.1.Objective.113.2.Optimization / Acceptance Phases11

4.Cluster Optimization 124.1.Objective.124.2.Process Flow 12

4.2.1.Cluster Unloaded Optimization 134.2.2.Cluster Loaded Optimization 14

4.3.Actix Spotlight Post Processing 164.3.1.ACTIX Spotlight Setup & Loading Log files 16

4.3.1.1.Creating a Project Template 174.3.1.2.Creating a Spotlight Project 20

4.4.Log Files Analysis234.4.1.Swap Sector and SC Inconsistency Check Analysis 254.4.2.Azimuth Verification 284.4.3.Sector Coverage / Boomer Cell Analysis 284.4.4.Coverage Analysis 29

4.4.4.1.RSCP DL Coverage Optimization304.4.4.2.Ec/No Pilot Dominance Optimization 334.4.4.3.UE Transmit Power UL Coverage 364.4.4.4.Downlink BLER Quality 374.4.4.5.Coverage Analysis Deliverables 38

4.4.5.Pilot Pollution Analysis394.4.5.1.Spotlight Cell Pollution Analysis 394.4.5.2.Identifying Polluting Cells 42

4.5.Over-Propagating Cell Identification 434.5.1.Spotlight Boomer Cell Analysis434.5.2.Identifying Over-Propagating Cells 44

4.6.UMTS Neighbor List Analysis 454.6.1.Missing Neighbor Analysis 474.6.2.SHO Overhead Analysis 49

4.7.Access Failure Analysis 514.7.1.Spotlight Access Failure Analysis 554.7.2.Access Failure Causes 59

4.7.2.1.RACH Access Troubleshooting 644.7.2.2.RRC Setup Troubleshooting 67

4.8.Drop Call Analysis 704.8.1.Drop Call Causes 714.8.2.Drop Call Analysis in Spotlight 74

4.9.Packet Session Data Analysis 774.9.1.R99 DCH Low Throughput Analysis 784.9.2.Using Actix To Identify Low R99 Throughput 794.9.3.Using Actix To Analyze Low R99 Throughput 854.9.4.HSDPA Low Throughput Analysis 894.9.5.Using Actix To Identify Low HSDPA Throughput 90

4.9.5.1.Event Explorer 904.9.5.2.Drill Down 924.9.5.3.Additional Attributes 93

4.9.6.Using Actix To Analyze Low HSDPA Throughput 985.Market Level Optimization 104

5.1.Objective.1045.2.Process Flow 104

5.2.1.Market Loaded Optimization 1055.3.IRAT Handover Failure Analysis 107

5.3.1.Identifying IRAT Handover Failures: 1075.3.2.IRAT Handover Failure Trouble Shooting Process 1095.3.3.Global IRAT handover failures:111

5.3.3.1.IRAT prerequisites: 1115.3.4.Cell Specific IRAT failures 112

5.3.4.1.Preparation Phase Failure 1145.3.4.2.Execution phase failures. 1165.3.4.3.Confirmation phase failures 119

6.Reference...........120

1. Introduction

1.1. Purpose & ScopeThe purpose of this document is to provide guidelines for UMTS Pre-Launch Optimization in order to help the RF Optimization Engineers successfully optimize the KPI requirements for Cluster & Market Level Acceptance. Pre-launch optimization deals with assessing a newly-built network, uncovering problems and resolving them prior to the Launch phase. It entails detailed field RF measurements, detecting and rectifying problems caused by radio, improper parameter settings or network faults and finally, grading the radio access part of the network to make sure that it passes certain evaluation criteria.

This document is primarily focused on resolving typical RF issues through the Actix Spotlight platform. These guidelines will be revised to update Actix processing once ActixOne becomes available. In addition, whilst this document contains a lot of generic content, there is also content which is specific to Ericsson markets such as PM counters / parameters. Content specific to Nokia markets will be added at a later stage. At the pre-launch Optimization stage, it is not envisioned that large scale parameter changes will be necessary as primary actions such as Physical changes & some basic parameter changes only will be made. Hence, do not use this guidelines to change any parameters without there being satisfactory understanding of the consequences involved or unless there is an FSC mandate to do so.

1.2. Definitions for this Document

Term or Acronym Definition

3GPP Third Generation Partnership Project

AS Active Set

BSIC Base Station Identity Code

BTS Base Transceiver Station

CN Core Network

CPICH Common Pilot Channel

DCH Dedicated Channel

DL DownLink

DPCCH Dedicated Physical Control Channel

DPCH Dedicated Physical Channel

DRNC Drift Radio Network Controller

FACH Forward Access Channel

FIFO First In First Out

GERAN GSM EDGE RAN

GSM Global System for Mobile Communications

HCS Hierarchical Cell Structure

IAF Intra Frequency

IE Information Element

IEF Inter Frequency

IFHO Inter Frequency HandOver

Inter-RAT Inter Radio Access Technology

IRAT Inter Radio Access Technology

Iur Interface between two RNCs

KPI Key Parameter Indicator

LA Location Area

LAI Location Area Indicator

NBAP Node B Application Part

Node B

Logical node responsible for radio transmission and reception in one or several cells

OCNS Orthogonal Channel Noise Simulator

PLMN Public Land Mobile Network

RA Routing Area

RAB Radio Access Bearer

RAI Routing Area Indicator

RAN Radio Access Network

RAT Radio Access Technology

RB Radio Bearer

RBSRadio Base Station another name for the Node B

RF Radio Frequency

RL Radio Link

RNC Radio Network Controller

RRC Radio Resource Control

RSCP Received Signal Code Power

RSSI Received Signal Strength Indicator

SIB System Information Block

SIR Signal to Interference Ratio

TRX Transceiver

TX Transmit

UE User Equipment

UL UpLink

UMTSUniversal Mobile Telecommunication Services

UTRAN UMTS Terrestrial Radio Access Network

WCDMA Wideband Code Division Multiple Access

2. UMTS technology in briefWideband CDMA is the recognized air interface standard for 3G-UMTS. It was developed as one of the third generation radio access technologies whose ultimate goal is better spectrum efficiency, faster data transfer rate and an increase in service quality.

WCDMA utilizes the spread spectrum technology for radio access where users are identified by unique codes, which means that all users can use the same frequency and transmit at the same time. A bandwidth of 5MHz is used per channel with a chip rate of 3.84 Mcps.

For optimal operation of the wireless system, several functions are in place to control the radio network and the many active handsets. Efficient power control in both directions regulates the over-all interference level which is very important in a network with a frequency reuse of 1. Fast power control algorithms at 1500 Hz counter fading dips and ensure good performance. Cell breathing is a phenomenon inherent in WCDMA. This is the trade-off between coverage and capacity where the size of the cell varies depending on the current load. Macro diversity is another feature of the network which is achieved during soft handover. A user can be connected to two or three base stations at a time providing a more reliable connection, thus reducing the risk of premature disconnection. A drawback with soft handover is that it requires additional hardware resources on the network side, as the handset has multiple connections. In a well-designed radio network, 3040 % of the users will be in soft or softer handover. Other system functionalities are admission and congestion controls which, as the names imply, are responsible for maintaining optimum loading in all parts of the radio network. Some of the ways by which this is done are by selective admission of users depending upon the expected noise level contribution and by dynamic reduction of the bitrates of certain non-real time applications to resolve overload situations.

2.1. ArchitectureFor mobile network operators like T-Mobile that has an existing GSM infrastructure, the migration scheme towards 3G primarily involves annexing a UMTS Terrestrial Radio Access Network (UTRAN) to the current setup. Both the GSM BSS and the UTRAN are connected to the same core network which handles all voice and data traffic from both systems, in circuit-switched (CS) or packet-switched (PS) modes.

The UTRAN which is analogous to the BSS in GSM consists of the Radio Network Controller (RNC) and the linked Node Bs which basically has similar functionalities as the BSC and BTS, respectively.

Figure 1: UMTS Network Architecture & Interfaces

2.2. UTRAN InterfacesWith the advent of new UMTS standards, comes a new set of interfaces and hence, interface names. Within the UTRAN, the main interfaces are:

Iu an open, multi-vendor interface that connects the UTRAN to the core network. It can have two different physical instances, the Iu-CS and Iu-PS, respectively connecting circuit switched and packet switched traffic into the core network, equivalent to the A and Gb interfaces in GSM

Iur connects two RNCs belonging to the same PLMN, supporting exchange of both signaling and user data. Non-existent between BSCs in GSM, this interface is there to support macrodiversity in UMTS. During soft-handover situations when a user equipment (UE) is connected to two or more Node Bs that belong to different RNCs, the Iur makes it

possible for the controlling RNC to manage the process by itself. In cases where the Iur does not support user plane transfer or if this link is not in place at all, this control is handled via the Iu interface through the MSC. The process now becomes the so-called hard handover.

Iub situated between the RNC and the Node B, performing rather complex tasks between the two entities. The interface protocols are fully specified by 3GPP making it possible to link Node Bs and RNCs from different compliant vendors. In GSM, this interface is the Abis.

Uu the air interface between the base stations and the UE

Although the Uu interface is obviously where RF optimization will be focused most of the time, an understanding of the functionality aspect of the other interfaces is vital to being able to make a well-rounded approach to problem solving and fault isolation.

3. Phases of Network Optimization

3.1. ObjectiveIn a nutshell, the main goal of pre-launch optimization is to make the UMTS network ready for the Launch Phase. To achieve this, a series of tests and tuning methods must be carried out and repeated as many times as required in order to meet certain performance criteria. Tests will basically start from cell level and then progressively widen in scope to encompass larger groups of cells until the entire market is tested as one functioning unit.

3.2. Optimization / Acceptance PhasesIn preparing for launch, the network undergoes various phases as shown in the diagram below.

Figure 2: Optimization Process

This document details the phases starting from Cluster Unloaded Optimization through to Market Launch. All other phases are outside the scope of this document and are covered in other literature.

KPIs met?

Site Acceptance

Spectrum verification1) UL and DL (if no verification has been done both links)2) UL or DL, which ever is missing

Cluster Unloaded Optimization

No

KPIs met?

Cluster Loaded Optimization

No

Yes

All clusters optimized?

Yes

No

Market Loaded Optimization

KPIs met?

Market Launch

Business as Usual Optimization

Yes

No

Yes

Late Sites Optimization

Both DL & UL cleared?No

DL or UL cleared?

No

DL Optimization (if DL is the only link cleared )

Yes

Yes

Spectrum verification (DL or UL, whichever is

cleared)

Initial Spectrum Clear notification

Authorized to transmit received from FSC

4. Cluster Optimization

To perform Cluster Level Optimization, a Market is divided into several clusters. Each cluster contains about 60-90 sites depending on the site density, morphology and expected subscribers mobility. There will be a team of one RF Engineer and one Drive Testing Engineer responsible for a Cluster to complete the Cluster Level Optimization. Each cluster can be broken down in mini sub-clusters to ease the drive testing process. However, the final KPIs are computed from this 60-90 site cluster.

4.1. Objective

The objective of cluster level optimization for both Loaded & Unloaded test configurations is to meet all the required cluster level CS & PS KPIs. This is achieved by performing RF Optimization activities such as adding missing neighbors, reducing / eliminating pilot pollution areas & coverage holes, identifying overshooting cells and so forth.

Table 1: Cluster Acceptance KPIs

4.2. Process Flow

4.2.1. Cluster Unloaded Optimization

The flowchart of Cluster Unloaded Optimization is shown below. There will be 2 drive tests for this phase with any further drives requiring the UMTS PMO approval. Whilst the aim is to meet the KPIs, these are on a best effort basis during Unloaded Optimization. At the completion of each drive test, change requests will be generated for Physical & Parameter changes. After the 2nd drive, change requests can be generated however an Unloaded drive test will not occur to verify these changes Instead these will be verified during the Loaded phase.

Figure 3: Cluster Unloaded Optimization

Device Type of Call Mode CommentsMS1 Scanner DualMS2 Voice Short UMTS 15sec dur, and 10 sec gapMS3 Voice Long UMTS 1800 secMS4 PS DL/UL UMTS R99 2MB

LT1

Setup 1

Table 2: Cluster Unloaded Drive Test Configuration

Drive data quality ok?

Setup 1LT1: Scanner (Dual), Voice SC, Voice LC, PS DL

No

Cluster Unloaded Optimization

KPIs met?

Yes

Yes

No

Analysis , recommendations and

implementation

Cluster Loaded Optimization

Voice Access Failure Rate (MS2) Drop Call Rate (MS3) Quality (MS3) Voice Call Setup Time (MS2) Handover Factor (MS3)

PS R99 Access Failure Rate (MS4) Drop Call Rate (MS4) DL Throughput (MS4) UL Throughput (MS4) PS Call Setup Time (MS4)

Table 3: Cluster Unloaded KPIs

Table 2 shows the current drive test configuration for the Unloaded Phase. CS Short, CS Long & PS data call will be the only service types tested and Table 3 shows which UE will be used to extract the relevant KPI. The purpose of this test is to

Identify site installation issues such as swapped feeders Identify areas of pilot pollution, over-shooting cells Identify coverage holes, areas of poor pilot dominance Detect missing neighbors Identify scrambling code plan collisions Provide change recommendations

4.2.2. Cluster Loaded Optimization

The process flow of Cluster Loaded Optimization is shown below. There will be 3 drive tests for this phase with any further drives dependent on the impact of HSDPA on CS Voice. Whilst the first 2 drives will involve testing CS & PS services only, the last drive will have PS replaced by HSDPA. This is to measure the impact of having HSDPA with CS Voice users. This is dependent on a HSDPA UE being available at the time of testing. At the completion of each drive test, change requests will be generated for Physical & Parameter changes. After the 3rd drive, change requests can be generated however a Loaded drive test will not occur to verify these changes.

Note that Stationary Testing will also occur in this phase with PS & HSDPA services. Ideally, stationary locations comprising 5% of sites within a cluster should be identified for testing purposes. Depending on drive test scheduling, there could be 2 drive teams operating simultaneously within a cluster. However, thorough coordination is required to ensure drive test results are not adversely caused by each team. Stationary testing can be prolonged to the Market Optimization phase if all locations cannot be tested within the nominal timeframe.

The drive test configuration & KPI definitions are presented in the following diagrams for both Cluster Loaded & Unloaded phases.

Drive data quality OK?

Setup 1 (Mobile Test)LT1: Scanner (Dual), Voice SC, Voice LC, PS DL

No

Loaded Cluster Optimization

KPIs met?

Yes

NoAnalysis ,

recommendations and implementation

Loaded Market Optimization

Setup 2 (Stationary Test)LT1: R99 PS, HSDPA PS

No

Analysis , recommendations and

implementationNo

Figure 4: Cluster Loaded Optimization

LT1 Device Type of Call Mode Comments

Setup 1

MS1 Scanner Dual MS2 Voice Short UMTS 15sec duration & 10 sec gapMS3 Voice Long UMTS 1800 sec

MS4 PS DL/UL UMTSR99 2MB or HSDPA 10MBThe final drive will do packet services on HSDPA No EUL

Table 4: Cluster Loaded Drive Test Configuration Mobile Test

Table 5: Cluster Loaded KPIs Mobile Test

The purpose of this test is to:

Validate the RF Design criteria such as Ec/No & RSCP against the actual network performance

Identify areas of pilot pollution, over-shooting cells Identify coverage holes, areas of poor pilot dominance Provide change recommendations Investigate any significant KPI degradations experienced by CS Voice UEs when a HSDPA

UE is present

HSDPA Access Failure Rate (MS4) Drop Call Rate (MS4) DL Throughput (MS4)

Voice Access Failure Rate (MS2) Drop Call Rate (MS3) Quality (MS3) Voice Call Setup Time (MS2) Handover Factor (MS3)

PS R99 Access Failure Rate (MS4) Drop Call Rate (MS4) DL Throughput (MS4) UL Throughput (MS4) PS Call Setup Time (MS4)

Provide change recommendations

LT1 (Stationary, Approx 1.5 hours per location) Device Type of Call Mode Comments

Setup 2

MS1 R99 UMTS 5 DL 10MB, 5 UL 3M and 1000 ping done one after the other

MS2 HSDPA UMTS 5 DL 10MB & 1000 ping done one after the other. Starts after MS2 test

Figure 5: Cluster Loaded Drive Test Configuration Stationary Test

Figure 6: Cluster Loaded KPIs Stationary Test

The purpose of this test is to:

Identify the peak & mean throughputs for PS R99 services Identify the latency times for PS R99 services Identify the peak & mean throughputs for HSDPA Identify the latency times for HSDPA Investigate areas of non-existent 16-QAM when it should exist Provide change recommendations

Whilst the drive test configurations & KPIs have been shown above, this document will not provide details regarding how to perform drive tests. All detailed content relating to Drive Test Setup, Drive Test Operations, Pre-Drive Test Preparation is available from the UMTS Acceptance Drive Test Methodology document located at:

http://docs.eng.t-mobile.com/InfoRouter/docs/~F100484

4.3. Actix Spotlight Post Processing

This section discusses Post Processing of TEMS Log files to identify the areas of Optimization in the UMTS Radio Network. Actix Spotlight is the tool for post processing the TEMS Log files. When this document was written, the ActixOne platform was not in place. Hence in this document, the process assumes every Cluster RF Engineer has a Standalone Desktop loaded with Actix Spotlight.

4.3.1. ACTIX Spotlight Setup & Loading Log files

The purpose of this section is to describe the procedure for creating a Spotlight project with Actix Analyzer Software. Spotlight, allows the user to use automated workflow and analysis to

PS R99 DL Average Throughput (MS1) DL Peak Throughput (MS1) UL Average Throughput (MS1) UL Peak Throughput (MS1) Latency (MS1)

HSDPA DL Average Throughput (MS2) DL Peak Throughput (MS2) Latency (MS2)

investigate, troubleshoot, and report UMTS and HSDPA drive data. Suitable for large data volumes, it creates a dashboard that highlights certain event types and allows a user to drill down in a specific file without loading it in its entirety. The following subjects will be discussed in this section:

Creating a Project Template in Actix Spotlight

Creating a Project in Actix Spotlight and Loading log files

Handling Projects

Various Actix Spotlight features

For detailed Actix Spotlight processes please refer to the documents found at:

(http://docs.eng.t-mobile.com/InfoRouter/docs/~F101336)

With ActixOne in place, it will not be required to do many of the steps in this section. For example, it will not be required to create a project/template, Celref, etc. It will not be required to load the log files. A project will already exist in ActixOne for a specific cluster and this can be worked on immediately.

4.3.1.1. Creating a Project Template

When Actix is initially opened, the user will be provided the option to open Actix Classic or Actix Spotlight. Choose the option that allows the user to open Actix Spotlight when the following screen appears, Figure 7.

Figure 7: Choosing An Engineering Process

After choosing Actix Spotlight, the following screen will appear as shown in Figure 8. All previously created projects will be visible as well as the ability to create a new one. Hence, select the New Project button.

Figure 8: Creating A New Project

Spotlight comes standard with several templates available. In addition, a user can create a new template using an existing one as a base. The following procedure describes the process of creating a new Template. Select the New Template button as shown in Figure 9.

Figure 9: Creating A New Project Template

The New Project Template Step 1 screen gives the user a chance to create a name for the new template and to select an existing template to base it on. Type in a new name in the Template Name field, and select UMTS Voice from the drop-down menu. Note that other templates are to start from if appropriate (e.g. GSM UMTS Voice) if required. This procedure assumes only UMTS data is being processed. Once finished, click the Next button as shown in Figure 10.

Figure 10: Naming The New Project Template

After creating a name for the new template, Step 2 allows the devices that will be processed to be selected. This option allows the user to define which devices will be loaded for the Spotlight analysis. For example, if the user is only interested in analyzing scanner data, and excluding all other devices, this could be achieved by clicking the Add Device button and creating the appropriate filter. This may be useful in reducing the processing time if the log files contain data from multiple devices. The default setting is All devices and is generally recommended to insure that all data is loaded. After creating the appropriate filter click the Next button.

Figure 11: Select Devices For Template

The next step is to define the KPIs that will be analyzed, and the Reports that will be created. Based on these selections, Spotlight will create a dashboard that reports on different types of events. To investigate the full range of UMTS/HSDPA failures, ensure that the checkboxes are selected as shown in Figure 12. After making the appropriate selections, click the Next button.

Figure 12: Selecting KPIs And Reports

Now that the various KPIs have been chosen, Step 4 allows Attributes to be added (see Figure 13). The base template that was selected comes with several Binned Data Queries that include default attributes. These attributes will be available for viewing in Spotlights dashboard. In addition, other attributes of interest can be added. For example, to add the Average HSDPA CQI attribute, select the UMTS UE Binned Data query to list the currently selected attributes. Next, select the attribute from the Attribute Picker (i.e. 3G UMTS > Downlink Measurements > 3G HSDPA > Uu_HSDPA_CQI_Average).

Figure 13: Adding An Attribute To A Binned Query

Included in Step 4 is the data binning options which is illustrated in Figure 14. Typically, area binning will be used when Pilot Pollution and Neighbor List analysis is required. Select the meters

radio button as the Units of Measurement, and enter the X and Y bin size. The bin size utilized should be based on the binning that was used by Asset 3G during the design phase. For example, if 5 meter bins were used for the Manhattan design, then the same bin size should be used for the Spotlight analysis. Finally, select Conformal Project (USA) from the Projection drop down box, and click the Next button.

Figure 14: Binning Options

The final step in the process is to define Global Filters. This is typically left unchanged. Complete the template creation process by selecting the Done button as shown in Figure 15.

Figure 15: Template Completion

4.3.1.2. Creating a Spotlight Project Now that a template has been created, it can be used to process files for the Spotlight Project. From the Actix Spotlight main screen, click the New Project button. The first step in creating a project is to create a Project Name and select the appropriate template (see Figure 16). Once this is completed, click the Next button to proceed to the next step.

Figure 16: Selecting A Project Name & Template

The next step is to define the appropriate site data base, or Cellref file. It is imperative that an accurate Site database is used. This site data base must match the state of the network at the time the drive test data was collected. This is especially true for scrambling code and neighbor list data. The procedure for creating this Actix formatted cellref file is not included in this document. It is

assumed that this file will be provided to the user. Currently, the Actix Cellref file is scheduled to run daily at 8:15am EST. The daily file can be retrieved from the following location:

ftp://10.16.6.183/UMTSExport/

As illustrated in Figure 17, click the Browse button to navigate to the appropriate cellref file and select it.

Figure 17: Selecting A Celref File

In addition to selecting the correct celref file, Step 2 also allows advanced options to be configured via the Setting and Thresholds links highlighted in blue. Clicking the Settings link opens the Change Preferences window as shown in Figure 18. Most of the advanced options in this window are either configured by the project template, or the default settings are sufficient. However, it is suggested that the WCDMA Neighbor List settings are confirmed. These settings can be changed after the Spotlight project is created, but the follow setting will serve as a good starting point.

Figure 18: Change Preferences

At this point, click the Thresholds link to open the Thresholds Editor (see Figure 19). In most cases, default setting will be appropriate (defaults can be restored by clicking the Restore Defaults button). However the Uu_CallSetupFailure_Num_RRCConnReq threshold (expand UMTS > Event Control) should be set to 5 to match the recommended value for the configurable RNC parameter N300. In addition, confirm that the threshold Uu_Scan_TooManyServersThreshold (expand UMTS > Scan_Coverage) is set to 5. Lastly, the SL_Overspill_Dist_Threshold (located in the Spotlight folder) should be adjusted based on the morphology and site density of the area to be analyzed. For example, Manhattan will require a lower value (e.g. 500 meters) while North Dallas may only require 2000 meters. This threshold will

help identify over propagating (Boomer) cells. Alternatively, this threshold can be configured on a per cell basis by means of the cellRef file, which is the better option. Once the thresholds have be modified and confirmed, click the OK button to exit and save the threshold changes. At this point click the Next button to move to step 3.

Figure 19: Threshold Editor

The final step is to select the files to be processed. Click the Add Files button as shown in Figure20. Optionally, all files in a folder can be added by selecting the Add Folder button. Navigate to the appropriate folder, select the files or sub-folder, and click Open.

Figure 20: Adding Log Files

After all files have been selected (see Figure 21), click the Done button to begin processing the selected log files. At this point, a status bar appears indicating the status of the data processing.

Figure 21: Selected Files

After the log files have been loaded and processed, a Data Processing Summary window appears indicating how many files loaded, and how many files failed to load. In some cases, not all files initially load due to computer limitations (e.g. processing capability and limited memory). If files fail

to load, reselect the files and attempt to load them again. If files fail to initially load, however successfully load on repeated attempts, consider reducing the amount of data loaded during each attempt. On the other hand, if a specific file continuously fails to load, it may be corrupt. Once the Data Processing Summary window is closed, the Spotlight Summary Dashboard appears (see Figure 22).

At this point, additional log files can be loaded by clicking the Add Data link. Before proceeding with the analysis phase, confirm that all log files have been loaded. The Repository Summary indicates the number of log files loaded. This number should match the number of log files that were intended to be loaded (less any corrupt files).

Figure 22: Spotlight Summary Dashboard

4.4. Log Files Analysis

The objective of analyzing Log files is to make the network meet the required Cluster Level KPIs (as per Table 1) by identifying issues and resolving it through optimization. Following are the metrics that a Cluster RF Engineer may consider for analysis in general.

Coverage plot in terms of RSCP To identify the areas of poor coverage Best Server Plot (1st Best SC based on Ec/No) To verify the sector wise coverage, SC

inconsistencies, Sector Swaps, etc. Ec/No Plot of the 1st Best Server To identify areas of poor Ec/No Downlink BLER plot To identify the areas of poor down link quality UE Transmit Power Plot To identify the areas of poor uplink coverage and path imbalance Uplink BLER To identify the areas of poor uplink quality ( Possible only with UETR Trace

files) Active Set Size Plot To identify the areas of high secondary traffic and too many servers.

Following is the analysis that a Cluster RF Engineer may need to exercise to identify issues and reach optimization solutions.

Swap Sector Analysis / SC inconsistency Check To identify the sector swaps and/or improper data fill of Scrambling codes

Azimuth Verification To identify the difference between the azimuth deployed and azimuth designed.

Missing Neighbor Analysis To identify the reported missing neighbors and recommend the required neighbor list changes.

Analysis of Pilot Pollution / Interference / Pilot Overshoot To identify the possible cause of poor Ec/No, poor DL BLER, High SHO overhead, etc.

Drop Calls / Access Failure Analysis To identify the reason for Drop calls and Access Failures and provide to solutions to resolve.

Following are the analysis that a RNC Engineer may need to do on a RNC Level for all the sites.

Neighbor List Inconsistency Check To identify issues like one way neighbors, neighbor data fill issues, IRAT Neighbor issues, etc.

SC Inconsistency Check To identify any SC collisions based on Neighbor List

Figure 23 shown below depicts the process flowchart that a Cluster RF Engineer may follow to analyze the drive data for Cluster Optimization. Please note that it is not required to go in sequence as shown, the Engineer can prioritize themselves the importance of each task. However, care needs to be taken to ensure the analysis performed is thorough.

Figure 23: Flowchart of Cluster Drive Log Files

4.4.1. Swap Sector and SC Inconsistency Check Analysis

This analysis is the 1st and most important in any new market that is about to be launched. The objective of this analysis is to verify if the sectors are transmitting as stated in the RF Design without any sector / cable swaps and ensuring the correct SC as per RF Planning. This can be verified using the 1st Best Servers SC plot from the Scanner device. It is always preferred to take this 1st Best servers SC Plot from the Scanner. This is because the 1st best server observed by UE could be impacted by a poor Neighbor List. 1st Best Servers SC plot can be displayed in Actix Spotlight using the following step.

In the Summary Dashboard, select the Scanner tab

Post Processing of Log files in Actix Spotlight

Swapped Sector and SC Consistency Check Analysis

using 1st Best Server SC PlotDeliver Swap Sec and SC Check Report

Azimuth Verification using sec coverage & beam width

Deliver Azimuth Verification Report

Sec Coverage / Boomer Cell using Sector Coverage (RSCP)Deliver List of Overshooting and Poor

Covering cells with resolutions

Coverage Analysis using RSCP, Ec/No, UETxPwr,

BLER PlotsDeliver Coverage KPIs and Resolutions

to meet them

Pilot Pollution Analysis using Pilot Pollution metricsDeliver % of samples with Pilot

Pollution and Resolution to reduce it

SHO Overhead Analysis using Active Set Size Plot

Deliver Simulated SHO OH from Scanner and SHO OH from Long Call UE.

Resolutions to meet the SHO OH KPI

3G Missing Neigh Analysis using 3G Missing Neigh metric &

1st Best Server SC PlotDeliver List of missing neighbors and RNC Script to update the Neighbor list

IRAT Not Reqd in Cluster Tuning

Call Drop and Access Failure using Event Explorer Analysis

Deliver CD Rate and AF Rate. Reason and Resolution for every CD and AF

Click on the Radio Network button which will take you to the Radio Network Explorer window

Select the Cell Coverage tab in Radio Network Explorer window From the Attributes select CPICH_Scan_SC_SortedbyEcIo_0. This will display the 1st Best

Servers SC in the Map window as shown below in Figure 24.

One should also make sure that the loaded cellref file in Actix Spotlight has the updated SC, Azimuths, etc.

Figure 24: 1st Best Server SC Plot

It is recommended to label the sectors and the drive map (using layer control in the map window) with SC. A visual verification over the plot would reveal that if there are any sectors swaps and/or SC inconsistencies. A zoomed picture of 1st Best Servers SC plot is shown below. As we see here, the drive datas SC exactly matches with the SC of the sectors. Incase, if there is a sector swap, we should see otherwise. For example in Figure 25 shown below, on site B104841D, if sectors 1 and 2 are swapped, then we should see SC 229 on top then 221 below. Sometimes, all the three sectors in a site would have been swapped. Say, Sec1 Sec 2, Sec2 Sec3 and Sec3 Sec1. This can also be identified in the SC Plot. Instead of 221, 229 & 237, you will see like 237, 221 and 229 (shifted clockwise). In few other cases, if the planned SC is not data filled properly in RNC / NodeB, you may see a different SC in drive data than the one in the site. This is known as a SC Inconsistency.

A similar verification is to be done for all the sites in your cluster. If there are any issues noticed, a list of Sector Swaps and/or SC inconsistencies can be sent to UTRAN / RNC engineer for modifications / corrections.

Figure 25: 1st Best Server's SC Plot - Drive Data Vs Sector SC

Another way to identify the swap sectors / SC inconsistencies is to look at the summary spread sheet on top of the Map window, in Cell Coverage Tab of the Radio Network Explorer Window. A sample window is shown below in Figure 26.

Figure 26: Cell Coverage

This spread sheet the cell wise coverage statistics observed during the drive test. You can sort this spread sheet in terms of % >180 Beam, by clicking on it. This will bring up sites which are having most drive samples falling out side the imaginary antenna beam width. Higher the percentage in this column means more drive samples are falling out side the 180 deg imaginary antenna beam width. This could be an issue of Sector Swap and/or SC inconsistency. If you click on the particular site with high percentage, it will take you to that site on map window, displaying the RSCP of that sector. On

this map window, by displaying the 1st Best Servers SC, you will be able to analyze if there is any Sector Swap and/or SC Inconsistency as discussed above.

Following are the cautions that should be considered in this analysis

Detailed drive data should be available to do this analysis. Hence, it is recommended to do this analysis with the Cluster Tuning Drive but not with Market Drives

This analysis should not be done for the sites at the edge of the cluster or drive area, especially for the sectors facing outside the cluster or drive area.

4.4.2. Azimuth Verification

The objective of this analysis is to verify if the azimuth of a sector is deployed as per the RF Design. This can be done in the same way as explained in the previous section. Using the Sector wise RSCP and the 1st best servers SC plots, we can approximately estimate what could be the azimuth of that sector. Sector wise RSCP can be displayed by clicking a Sector of interest, in Cell Coverage tab in the Radio Network Explorer window. Figure 27 below shows the RSCP of a sector.

Figure 27: Sector RSCP (SC 165)

It should be noted that, in this analysis, we are not trying to estimate the azimuth accurately. Its only an approximate estimation. If a difference in azimuth noticed, a cell technician need to be sent to the site for verification, before making any work order for change of azimuth.

4.4.3. Sector Coverage / Boomer Cell Analysis

This analysis can be done in parallel with Azimuth Verification (4.4.24.4.2) Coverage of a Sector can be displayed by clicking on the Sector of interest on the Map window while in Cell Coverage Tab in

Radio Network Explorer Window. It is recommended to choose the Scanner as the device to look at the Sector Coverage. Figure 27 shows an example of coverage in terms of RSCP of a sector.

Generally a Sector Coverage in terms of RSCP should be better than -104 dBm up to the next near by neighbor cell. This will make sure there is enough coverage and big coverage holes in the cell edges. It is recommended to verify the coverage of every sector in your cluster in this way. In case if you find any site covering very low (very low coverage radius), then following could be the issues:

Improper Antenna Azimuth Improper Electrical and/or Mechanical Tilt Major Obstructions Node B hardware issues High VSWR on Feeder Cables Poor RF Connectors / Antenna

If a poor coverage is noticed from any of the sectors, please make a note of the sectors and validate these sectors while doing the cluster level detailed coverage analysis as per 4.4.4

In some cases, you find that the cell coverage exceeds beyond the 2nd or 3rd tier Cells. This could due to Overshooting pilots also known as Boomer Cells. Please refer to 4.5 about identifying the overshooting pilots and optimizing it.

In few circumstances, because of the clutter type, a 2nd Tier Cell will be the strongest serving cell for the UE. This could be because of any major obstruction on the 1st Tier Cell. In this case, the 2nd Tier Cell should not be considered as an overshooting pilot or Boomer Cell.

4.4.4. Coverage Analysis

Coverage Analysis would generally be the first step in Log files Analysis. The Objective of Coverage Analysis is to make sure that the coverage of a site or the cluster from the drive test meets the coverage objective of the RF Design. Figure 28 below shows the process that a Cluster RF Engineer may follow to perform coverage analysis.

Figure 28: Coverage Analysis Flowchart

4.4.4.1. RSCP DL Coverage Optimization

Best Servers RSCP of your cluster can be displayed using the following steps in Spotlight. It is preferred to take the RSCP from Scanner. This is because the RSCP observed by UE could be impacted by a poor Neighbor List. RSCP from the Scanner will the true picture of the outdoor coverage since we place the Scanners external antenna on top of the drive test vehicle.

In the Summary Dashboard, select the Scanner tab Click on the Radio Network button which will take you to the Radio Network Explorer

window Select the Cell Coverage tab in Radio Network Explorer window

Coverage Analysis in Actix Spotlight

DL Coverage Area Optimization

Optimization to create Pilot Dominance

UL Coverage and Path Balance Optimization

RSCP KPI Met?

Verification of Cell / RNC Parameters related to

BLER

End of Coverage Analysis

Ec/No KPI Met?

UE TX PWR KPI Met?

DL BLER KPI Met?

YES

YES

YES

YES

NO

NO

NO

NO

From the Attributes select CPICH_Scan_RSCP_SortedbyEcIo_0. This will display the 1st Best Servers RSCP in the Map window as shown below in Figure 29.

Figure 29: Spotlight RSCP Plot

The objective of RSCP analysis is to meet the required RF Design KPI in terms of RSCP. This KPI would differ from market to markets. For example, in NY the RSCP should be better than -105 dBm at 100% of the area. To find out the Percentage of RSCP from drive test that is better than -105 dBm, please refer the Map Legend on the right side of Map window. You can calculate the percentage of samples above -105 dBm to the total number of drive test samples. If the KPI is not met, then a visual verification of plot would reveal the areas of coverage less than -105 dBm. An attempt should be made to improve DL coverage in those patches.

Apart from meeting the RSCP KPI, it is also recommended to make a visual verification of drive test RSCP in comparison with the RSCP prediction from the RF Design. A sample of such comparison is shown in Figure 30 below. Where ever the drive test RSCP is inferior to the Predicted RSCP, an attempt should be made to do a DL Coverage Optimization.

Figure 30: Drive Test RSCP Vs RF Design Predicted RSCP

DL COVERAGE (RSCP) OPTIMIZATION

The intention of DL Coverage Optimization is to improve the RSCP to a level as optimum as possible. It is always recommended to identify the 1st Best Server in terms of Ec/No, in the area you are optimizing. And then try improving the RSCP of that sector. Following could be the causes of poor coverage from a sector.

Obstructions Buildings, Hoardings, etc. Either very high or very low Electrical / Mechanical Tilts Improper Antenna Azimuth Improper Antenna High Feeder Cable Loss due to higher feeder cable length Feeder Cable / Connecter issues Incorrect CPICH Power Incorrect NodeB parameters like, ulAttenuation, dlAttenuation, TMA insertion loss, etc. Node B Hardware Issues, Alarms, etc.

Following are the ways the Cluster RF Engineer may try to optimize the coverage.

Change of RET (No or Low Cost) Change of Azimuths (High Cost) Change of Mechanical Tilts (High Cost) Change of Antenna (Very High Cost) Verify the CPICH power from the RNC dump of the day of drive test Verify if there was any Node B Alarm on the day of drive test If the feeder cable or Node Hardware suspected, a cell tech may be sent to the site to verify

the feeder cable, connectors, VSWR, hardware issues, etc

In case if it is not possible to optimize 1st Best Servers Sector, or if the poor coverage patch is at the cell edges, then you can try to improve the coverage of the 2nd Best or 3rd Servers Sector. But in this case, you should try to reduce coverage from 1st Best Server, so that your optimization does not lead to pilot pollution, poor Ec/No or higher soft handover overhead.

4.4.4.2. Ec/No Pilot Dominance Optimization

DL coverage in UMTS is not just the RSCP but the combination of RSCP and Ec/No. Care should be taken through out the optimization, to create or keep a Pilot dominant in any given coverage area. Single or less number of pilots in an area leads to less Io and hence better Ec/No.

It is recommended to the Ec/No from the Scanner, because of the fact that Ec/No observed by UE could be impacted by a poor Neighbor List. 1st Best Servers Ec/No of the Scanner can be displayed in Spotlight from the Cell Coverage tab in Radio Network Explorer window by choosing the attribute CPICH_Scan_EcIo_SortedbyEcIo_0. A sample plot of Ec/No is shown below in Figure 31.

Figure 31: Spotlight 1st Best Server's Ec/No

The objective of Ec/No analysis is to meet the required RF Design KPI in terms of Pilot Ec/No. This KPI would differ from market to markets. For example, in NY the Pilot Ec/No should be better than -14 dB at 100% of the area. To find out the Percentage of Ec/No from drive test that is better than -14 dB, please refer the Map Legend on the right side of Map window. You can calculate the percentage of samples above -14 dB to the total number of drive test samples. If the KPI is not met, then a visual verification of plot would reveal the areas of Ec/No less than -14 dB. An attempt should be made to improve Pilot Ec/No in those patches.

Apart from meeting the Pilot Ec/No KPI, it is also recommended to make a visual verification of Ec/No plot to see if there are any areas of poor Ec/No (say, areas with Ec/No less than -9 dB). An attempt can be made to improve Pilot Ec/No on those patches.

As said earlier, the coverage in UMTS is the combination of RSCP and Ec/No. In spotlight, from the Cell Coverage tab in Radio Network Explorer window, you will see an area graph of RSCP and Ec/No showing coverage of all sectors in the drive log files loaded. An example of such a graph is shown below in Figure 32.

Figure 32: Coverage In Terms Of RSCP & Ec/No

Thresholds for Good Ec/No and Good RSCP need to be configured properly in the Spotlight, to get the right results. With proper thresholds in the above graph, the areas with Good Ec/No & Poor RSCP and Poor Ec/No & Poor RSCP are of POOR COVERAGE. The area with Poor Ec/No & Good RSCP is of area with NO DOMINANT PILOT. Area with Good Ec/No and Good RSCP is of GOOD COVERAGE.

Following could be some of the causes for the poor Pilot Ec/No

Pilot Pollution Having too many pilots at a good RSCP in a location Pilot Spillover (Boomer Cells) Spillovers causes increase in Io in the far field causing poor

Ec/No Missing 3G Neighbors Without the proper neighbor definitions, a strong undefined neighbor

becomes an interference, which could reduce Ec/No. Improper IRAT Trigger If the IRAT Handover to 2G is not done at the right time, it could

lead to poor Ec/No. Poor Coverage (RSCP) At the cell edges when the RSCP is bad, obviously Ec/No will be

bad. But this area is categorized as a Poor Coverage Area. Improper Cell Selection / Reselection A UE camped on a wrong cell could initiate a call in a

poor Ec/No environment. High Traffic on the Cell High Traffic increases Io and causing reduction in Ec/No Improper Soft Handover Parameters. Power Control Parameters Improper Power Control Parameters on Broadcast channels

could impact the Pilot Ec/No. But the chances are minimal for this cause considering that a RNC level parameter consistency check is done often.

GOOD COVERAGE

NO DOMINANT PILOT

POOR COVERAGE

To improve the Pilot Ec/No, the main area of focus should be on the No Dominant Pilot Area. Following are the ways a cluster RF engineer may follow to create a Dominant Pilot

Out of available Pilots in an area, identify the 1st Best Server in terms of Ec/No. Attempt should be made to improve the RSCP of the 1st Best Server and reduce the RSCP of

other servers. This may make the 1st best server more dominant and reduce the pilot pollution.

But if the 1st Best Server comes from the 2nd Tier cells or far due to overshooting pilot, you may decide to reduce the 1st Best Server (to contain the overshooting) and try to improve the next available 1st Tier Sector.

To identify if the pilot is overshooting, With Scanner selected as a Device, in the Cell Coverage tab Radio Network Explorer window, click on a sector that you want to analyze. It will show the RSCP of that sector as shown below in Figure 33. Depending on the coverage level at the area of analysis and at which level the level the pilot overshoots, you can decide if that pilot is to be contained or not.

Figure 33: Sector Coverage (RSCP) & Overshooting Pilot

While improving the RSCP of the 1st Best Server, care should be taken not to make

overshooting pilot. Also while containing the RSCP of other servers, care should be taken not to loose the

coverage.

Overshooting Pilot

In few circumstances, because of the clutter type, a 2nd Tier Cell will be the strongest serving cell for the UE. This could be because of any major obstruction on the 1st Tier Cell. In this case, the 2nd Tier Cell should not be considered as an Overshooting pilot or Boomer Cell.

To improve or contain the RSCP of a sector, antenna parameters like RET, Mechanical Tilt, Azimuth or even the Antenna can be changed.

In few circumstances where if you are not able to contain the overshooting pilot or reduce the pilot pollution, 3G and 2G (if required) Neighbor Lists may not be modified accordingly. This may make sure there is no drop calls in the pilot pollution or overshooting areas.

Neighbor list need to be corrected incase of any Missing Neighbors. IRAT Handover boundary may need to be tuned if there is a early or delayed IRAT HO. ( Not

Required During Cluster Tuning) On a high level, you may decide to tune the Soft Handover Parameters to reduce the call

drops due to handover failures of pilot pollution. But this is not recommended during cluster tuning phase.

4.4.4.3. UE Transmit Power UL Coverage

UE Transmit Power Plot can be taken using the Handset making Long Call (MS3). It is recommended to use the Long Call Handset, for the fact that, the UE transmits the right power when it is on call. During idle mode UE does not transmit continuously. To display the UE TX PWR, in the Summary Dashboard, Select the Long Call Handset (MS3) and then click Radio Network. In the Radio Network Explorer window, select UE_TxPow from the Attributes. This will display the UE Transmit Power in the map window as shown below in Figure 34.

Figure 34: UE Transmit Power Plot - UL Coverage

Main objective of checking the UE Transmit Power is to verify the Path Balance. Where ever there is a good RSCP, UE should transmit at a lower power. The UL & DL may not be balanced due to various factors such as like differences in Downlink and Uplink Power Control algorithms, Interference conditions, Traffic conditions, etc.

To verify the path balance visually, from the UE TX Power Plot, identify the areas of high UE Transmit Power (Say > 0 dBm) and then look at the RSCP and Ec/No Plots. If you see poor RSCP, it could be a poor coverage area. In this case, an attempt should be made to improve the coverage. If you see a poor Ec/No with a good RSCP, it could be due to interference or high traffic. If it is an interference issue due to pilot pollution or overshooting pilot, an attempt should be made to improve the Pilot Ec/No.

In few circumstances, UE Transmit Power could be higher with a good RSCP and Ec/No. This indicates an issue with the Uplink. This may be due to any of the following issues.

TMA, Cable, Antenna, Node B Hardware issues Improper Uplink Power Control Parameters Improper IRAT Trigger Improper Cell Selection / Reselection parameters Improper Node B parameters like, ulAttenuation, dlAttenuation, TMA Insertion Loss, TMA

Gain, etc. External Uplink Interference

If any hardware issues suspected at the site, Alarm history may be verified and if required a Cell technician may be sent to the site to verify the hardware, TMA, Antenna, feeders, etc. You can also verify the level of RWTP reported at Node B. Higher RWTP could be an indication of External Uplink interference, Hardware Issues, etc.

4.4.4.4. Downlink BLER Quality

Quality of Downlink in terms of BLER can be displayed in the Event Explorer Window by choosing the Attribute Uu_TrCh_DownlinkBlerAgg. As per the U12 Contract Specifications KPI table, DL BLER should be less than or equal to 2% in 95% of the samples. This can be calculated using the BLER Legend displayed on the right side of the Map window. BLER can be displayed and the BLER KPI can be calculated for all the handsets (MS2, MS3 and MS4). For MS4 making PS calls, the KPI for DL BLER is less than or equal to 5% in 95% of drive samples. A sample plot of DL BLER is shown below in Figure 35.

Figure 35: DL BLER Plot

In most of the cases the required KPI in terms of DL-BLER will be met. If the KPI is not met, a visual verification over the plot would reveal the areas of poor BLER. Following could be the reasons why the DL BLER can be bad.

Poor Ec/No (due to Pilot pollution, overshooting pilot, Missing Neighbors, etc) Poor Coverage (poor RSCP and Ec/No)

Improving RSCP and Ec/No would generally bring the DL BLER up to meet the required KPI.

4.4.4.5. Coverage Analysis Deliverables

Following is the list of deliverables at the end of Coverage Analysis for every cluster / market.

RSCP Coverage Statistics / Distribution. Percentage of drive samples with RSCP > -104 dBm Ec/No Statistics / Distribution. Percentage of drive samples with Ec/No > -14 dBm UE TX PWR Statistics / Distribution. Percentage of drive samples with UE TX PWR < 18 dBm DL BLER Statistics / Distribution. Percentage of drive samples with DL BLER < 2% List of Changes in Sites / Parameters to achieve the required coverage KPIs. An example is

shown below

Sl No. RNC Site ID Cell ID Parameters

Current value

Proposed Value

Reason for Change

1NYRNC001

NY01001A

UNY01001A11 RET 4 6

Pilot Pollution at 5th Ave and 40th St

2NYRNC001

NY01001A

UNY01001A31 Azimuth 240 260

To improve Coverage at 39th St and 6th ave

Table 6: Physical Parameter Changes

4.4.5. Pilot Pollution Analysis

Since WCDMA utilizes N=1 frequency reuse, inter-cell interference is an ever-present issue. System performance and overall service quality are directly related to the degree to which interference can be controlled. In CDMA systems, interference is mitigated by soft handover. However, increased soft handoff results in increased network resource utilization (e.g. RF power, OVSF codes, channel elements, Iub capacity, and RNC processing load). In addition, HSDPA does not utilize soft handover and is therefore highly susceptible to system interference.

The concept of pilot pollution has created a lot of industry buzz; most engineers realize that pollution is bad. But it is important to keep in mind the reasons why pollution is bad. Although pollution analysis utilizes the pilot energy as an indication of potential interference, it is not actually the pilot that is the problem. Typically the pilot (CPICH) is less than or equal to ten percent of the total potential power of the cell. Therefore, it is this potential energy from a loaded cell that will cause the interference. That being the case, the objective of pollution analysis is to identify areas where pollution exists, and take actions to improve the coverage in that area to reduce interference. The classical definition of pilot pollution is a situation in which the received power (RSSI) is high, but Ec/No of the best server is low. This definition has evolved over time into a more quantifiable one, namely, a situation in which four or more pilots are received within 5 dB of each other, including the strongest pilot. This definition is implemented in Actix when the advanced option Uu_Scan_TooManyServersThreshold was set to 5 dB (refer to Creating a Spotlight Project, 4.3.1.2).

During the analysis process, scanner data will be used to identify areas of high pilot pollution. This analysis should allow the T-Mobile engineer to quickly identify sites that are over/under propagating, and recommend corrective action.

4.4.5.1. Spotlight Cell Pollution Analysis

To begin the pilot pollution analysis, click the Radio Network link on the Summary Dashboard screen of the Actix Spotlight project. After the Radio Network screen appears, select the Cell Pilot Pollution tab to move to the pollution analysis screen (see Figure 36).

At this point, it may be useful to describe some terms, as well as features available on the Cell Pilot Pollution tab of the Radio Network Explorer. Before beginning the pollution analysis, it is important to select the correct type of analysis. Referring to Figure 36, the Analysis drop down menu allows the user to choose one of two types of pollution analysis (i.e. Pilot Pollution Scanner, or Too Many Servers Scanner). The default option is Pilot Pollution Scanner. This option flags measurement events when four or more pilots are measured less that some pre-defined threshold (default = 15 dB). This analysis is more appropriate for IS-95 or CDMA1x technologies which have fixed thresholds for adding and removing cells to the active set. On the other hand, WCDMA uses reporting ranges that track the strongest pilot in the active set. Therefore, it is more appropriate to use the Too Many Servers Scanner option. This option

flags bins when four or more pilots are measured within 5 dB of the strongest pilot (as configured Threshold Editor).

Figure 36: Cell Pilot Pollution Screen

Referring to Figure 36, the upper third of the Radio Network Explorer contains statistical data, based on a per cell basis. The data provided includes Too Many Servers Events, # of Outbound Cells, and # of Inbound Cells. When a specific cell is selected, pollution events involving this cell are displayed on the map (see Figure 37). In addition, the other cells involved are listed on the left side of the Network Explorer. In this example, SC 139 is selected, and the Too Many Servers events related to this cell are mapped. The red lines point to cells that are polluted by SC 139. On the other hand, the blue lines originate from cells that are polluting SC 139. These definitions are based on which cell is the strongest cell when a Too Many Servers event occurs. If this event occurs and SC 139 is the strongest, it is considered an inbound event. If this event occurs and SC 139 is not the strongest, then it is considered an outbound event. When a cell is initially selected, the inbound bins associated with the inbound events are flagged with yellow exclamation points (as shown in Figure 37).

Figure 37: Cell Specific Pilot Pollution

When a specific line is selected, the bins associated with the inbound or outbound event are flagged with yellow exclamation points (See Figure 38 & Figure 39). Figure 38 illustrates the results of selecting the red outbound line pointing to SC 386. In this case the polluted bin is flagged a yellow exclamation point. When this point is selected, the cells contributing to the pollution are identified by the black lines. The solid black line indicates that SC 386 is the strongest cell in of the four. Since SC 386 is the strongest cell in the bin, SC 139 is causing outbound pollution to SC 386. If SC 139 had been strongest cell in this example, then SC 386, SC 394, and SC 21 would have been identified as inbound polluters.

Figure 38: Selecting Outbound Pilot Pollution Events

Note that the definition of outbound and inbound cannot always be taken literally. For example, Figure 39 illustrates where SC 341 is considered an inbound polluter to SC 139. This is because SC 139 is the strongest cell in the polluted set. However the map indicates the SC 139 was over propagating into an area where SC 349 should have been strongest. Therefore SC 139 was actually the polluter in the case. At this point, coverage analysis on both cells can be performed by going to the Cell Coverage tab and viewing each cells coverage (both Where Seen and Best Server). In

this case, the pollution event can be resolved by either increasing the dominance of SC349, or reducing the coverage other cells in this area.

Figure 39: Selecting Inbound Pilot Pollution Events

4.4.5.2. Identifying Polluting Cells

Obviously the T-Mobile Engineer can indentify polluting cells by simply clicking on each cell and observing the Too Many Server events. However this can be a time consuming process. The preferred approach would identify the cells that are the highest contributors to pollution. In this manner, corrective action can be taken on these offending cells, thus achieving the greatest amount of improvement with the lowest amount of effort and potential cost.

As previously described (see Figure 36), the upper third of the Radio Network Explorer contains statistical data, based on a per cell basis. The data provided includes Too Many Servers Events, # of Outbound Cells, and # of Inbound Cells. By clicking the column headings for this data, the results can be sorted in descending or ascending order. For example, in Figure 39, the data for the # of Inbound Cells was sorted in descending order. By sorting on these columns, cells that are involved with a high frequency of pollution events can be identified.

It should be noted that the Too Many Servers Events provides contradicting information and should be used with caution. It does not indicate the number of polluted bins containing a selected SC (although this would be quite useful). Nor does is provide the sum of inbound and outbound events. It is likely to be based on un-binned measurements which can result in unpredictable results (e.g. zero velocity scanner data collected while test vehicle was stopped).

Figure 40: Sorting Pilot Pollution Data

4.5. Over-Propagating Cell IdentificationThe identification of over-propagating cells (i.e. Boomer Cells) will allow the T-Mobile Engineer to quickly resolve a host of issues. Not only do these boomer cells contribute to downlink interference, and subsequently pollution and neighbor list issues, they can also have a tremendous impact on capacity and user experience.

From a capacity perspective, the fact that a boomer cell is over-propagating in the downlink implies that it is also receiving uplink interference from a larger number of UEs than necessary. This additional uplink interference will affect the cells capacity in its intended coverage area. In addition, this boomer cell will cause the system soft handover factor to increase. Finally, if the boomer cell is the best server in a large geographical area, it is likely to be the HS serving cell for a greater number of UEs than necessary. This will result in lower downlink throughput for all users being served by that cell.

4.5.1. Spotlight Boomer Cell AnalysisTo begin the boomer cell analysis, click the Radio Network link on the Summary Dashboard screen of the Actix Spotlight project. After the Radio Network screen appears, select the Cell Coverage tab to move to the cell coverage analysis screen.

At this point, some of the cell coverage analysis options will be described. Referring to Figure 41, there are four types of analysis available for cell coverage. These include: Handset Where Seen, Handset Best Server, Scanner Where Seen, and Scanner Best Server. If scanner data is available, the last two options are preferred as the scanner is not governed by a neighbor list. Both the Best Server and Where Seen options can be used to assess the coverage of a given cell. The Where Seen option plots all the bins that a given cell is detected, while the Best Server option plots the bins in which the cell is the best server. The latter option is certainly interesting as this will identify areas where the cell will be the dominant server. In all cases, the bins are plotted based on RSCP and Ec/No and can be selected/deselected via the layer control or legend check boxes.

Figure 41: Selecting Cell Coverage Analysis Types

4.5.2. Identifying Over-Propagating CellsObviously the T-Mobile Engineer can indentify boomer cells by simply clicking on each cell and observing the propagation on the map. However this can be a time consuming process. The preferred approach would be to identify the cells that are the most excessive over-propagating cells. In this manner, corrective action can be taken on these worst offending cells, thus achieving the greatest amount of improvement with the lowest amount of effort and potential cost.

One method of achieving this with Actix Spotlight is to use statistic data based on thresholds for cell radius. This method counts the number of times a cells pilot is detected outside its defined cell radius. By sorting on this data, the cells with the highest amount of overspill can be identified. This is achieved by clicking the >Dist header in the upper third of the Radio Network Explorer (see Figure 41). This threshold is illustrated the map by the red circle encompassing the selected cell. It should be noted that this data is not based on binned data, and therefore the sorted results may be affected by drive routes and test conditions (e.g. zero velocity measurements will not filtered out). In addition, scrambling code aliasing is a potential risk with any analysis of this type. Because scrambling codes are reused, the tool ties SC measurements to cells based on distance. This assumption is not always correct.

In this example (Figure 41), cell NJU70187, SC 130 was detected 13,855 times beyond its cell radius. The plot clearly shows that this is a boomer site. In fact, SC 130 is the best server in measurements taken 12 km from the site.

The value of this cell radius is configured by one of two means. The Threshold Editor can be used to define the SL_Overspill_Dist_Threshold (see Figure 42). This is a global setting and should be adjusted based on the morphology and site density of the area to be analyzed. Alternatively, cell specific radiuses can be defined by the MaxServerDist parameter in the cellref file. If this is defined, its value will supersede the global parameter SL_Overspill_Dist_Threshold.

Figure 42: Cell Radius Global Setting

In addition to using the cell radius method to identify boomer cells, pollution and neighbor list analysis will typically identify over-propagating cells as well. In addition, some OSS tools may identify boomer cells once there is sufficient traffic. For example, the Ericsson WNCS missing neighbor tool provided distance information for both defined and missing neighbors, which can be used to identify boomers.

Once a boomer cell is identified, it is obvious that corrective action should be taken (e.g. tilts, ACL, etc.). However, if the over-propagating coverage can not be corrected, the boomer cell must be added to the affected cells neighbor list (and vice-versa).

4.6. UMTS Neighbor List AnalysisTo begin the neighbor list analysis, click the Radio Network link on the Summary Dashboard screen of the Actix Spotlight project. After the Radio Network Explorer screen appears, select the 3G Missing Neighbors tab to move to the neighbor list analysis screen (see Figure 43).

At this point, it may be useful to describe some terms, as well as features available on the 3G Missing Neighbors tab of the Radio Network Explorer. Referring to Figure 43, the upper third of the Radio Network Explorer contains statistical data, based on a per cell basis. The data provided includes the recommended number of neighbor Additions, Retentions, and Removals. Check boxes are provided for each of these categories; which govern what is displayed on the map, as well as listed on the left side of the Network Explorer window. The Server Count provides the number of bins that a cell is the best server, and corresponds to the Ec/No data points plotted on the map.

The lines displayed on the map are related to the three neighbor categories and are displayed if the appropriate checkbox is selected. If the analysis determines that a missing neighbor exists, a green line will be drawn from the selected cell to the missing neighbor cell. In addition, data related to the missing neighbor will be listed on the left side of the window and highlighted green. This is true for neighbor removal and retentions results, which are colored red and blue respectively.

Figure 43: 3G Missing Neighbor Window

The neighbor events (i.e. Additions, Retentions, and Removals) are based on settings defined in the Preferences of the Spotlight Project Template. However, Spotlight allows the user to modify these settings at any time. To modify these settings, select the Data Settings link on the Radio Network Explorer window (see Figure 43). This will open the Change Data Settings window illustrated below in Figure 44.

Figure 44: Changing Neighbor Analysis Data Settings

The descriptions for these setting are provided in. When choosing these settings, it is important to not limit the available data by being overly conservative. For example, the default value for the Reporting Range is 5 dB. Initially this seems reasonable as it is similar to the soft handover parameters Event 1a and 1b. However the scanner data does not typically include in-building data; and opening this threshold may yield additional missing neighbors. The Maximum Intersite Distance and Angle to Site Threshold settings are disabled because WCDMA neighbor list analysis should be based on signal level, not geographical considerations. Finally, the Minimum Samples is reduced because some drive routes may not have the optimum density for this type of analysis. It should be noted that all of these settings can be modified dynamically. If the results yield too many neighbors, the settings can be tuned to values closer to the default settings.

Setting Default value

Suggested Value

Description

Reporting Range (dB) 5 9 For each data point, the algorithm creates a candidate list that includes those SCs within the Reporting Range value of the strongest signal. For example, if the strongest signal is -4 dBm, the default value of 5 dB would include in the candidate list all weaker SCs with signal strengths down to -9 dBm.

Maximum Size 15 32 Defines the maximum number of candidates in the candidate list.

Addition Threshold (%) 1 1 Defines the percentage of samples that must be reached to trigger a cell being added as a suggested neighbor. This is used to reduce the effect of stray signals.

Removal Threshold (%) 0.2 0.2 Defines the minimum percentage of samples that cells in the current neighbor list must achieve in order to be recommended for retention in the list. When the percentages of samples fall below this threshold, cells will be recommended for removal from the list.

Minimum Samples 50 10 Only sectors which have been measured above the Ec/No Threshold at least this many times will be included in the analysis. Note that the algorithm works off Binned data.

Maximum Intersite Distance (meters)

5000 0 Defines the maximum line-of-sight distance in meters between two cells for one to be considered for inclusion on the other's neighbor list. For rural areas where the average intersite distance is naturally greater than a dense urban environment, use a higher value. To disable this feature, set this value to 0.

Angle to site threshold (degrees)

90 0 Defines the maximum angle between the edge of a cell's beam width and the data point, for that cell to be considered for inclusion in the serving cell's neighbor list. To disable this feature, set this value to 0.

Include existing neighbors

Selected Selected Select this option for the current neighbor list in the cellrefs file to be considered for additions and removals.

Only process first best SC

Selected Selected Select this option to analyze the neighbors of the best cell only. De-select this option if you want to analyze the neighbor list of all of the cells within the reporting range.

Table 7: Neighbor List Analysis Settings

4.6.1. Missing Neighbor AnalysisTo simplify the missing neighbor analysis, uncheck the Retention and Removal check boxes. In this manner, only the Addition events are displayed on the map and listed on the left side of the window. As illustrated in Figure 45, the analysis is suggesting that nine neighbors should be added to UNY01437B21s neighbor list. The specific cells recommended are listed in green; and the percent of bins in which the missing neighbor met the criteria, while SC 278 was the strongest, is provided. In this example, UNY01282B21 (SC 192) met the missing neighbor criteria in 9% of the bins in which SC 278 was the strongest cell.

Figure 45: Viewing Missing Neighbor Events

To focus on this specific missing neighbor, either select the green line between SC 286 and SC 192, or select cell UNY01282B21 from the list of additions on the left side of the Radio Network Explorer window. This will display the bins that triggered the missing neighbor event for these SC pair (see Figure 46). In this case, it appears that the over propagation of SC 286, and the unexpected propagation of SC 192, resulted in the missing neighbor event occurring. These results can be corroborated by going the Cell Coverage tab and view each cells coverage (both Where Seen and Best Server). In this example, additional coverage analysis should be initiated to attempt to correct the coverage issue of both cells. However, if the coverage issues cannot be corrected, these two cells should be added to each others neighbor list. This procedure should be repeated for each missing neighbor event.

Figure 46: Focusing on Specific Missing Neighbors

In addition to performing missing neighbor analysis, the validity of existing neighbors can be confirmed. This is accomplished by using the Retention and Removal features of the 3G Neighbor Analysis. An existing neighbor will be flagged for Removal if it does not have a sufficient percentage of bins that meet the Reporting Range (as defined by the Removal Threshold). On the other hand, if an existing neighbor meets this criterion, it will be flagged for Retention. In both cases, the analysis can be corroborated by using the Cell Coverage tab and viewing coverage of the two neighbor cells. Caution should be used when removing neighbors from a cells neighbor list. Because this analysis is based on drive testing, certain areas within a cells coverage (including in-building) will be excluded from the analysis. A preferred method for removing neighbors from a cells neighbor list is to utilized UTRAN counters or OSS tools (e.g. Ericssons WNCS report).

Once Additions, Removals, and Retentions have been confirmed, they can be sorted in descending order to determine priority within the cells neighbor list. This is accomplished by clicking the % button indicated in Figure 47. At this point the list can be exported by clicking the Export Data link on the Radio Network Explorer window. Only the cells with their checkbox checked will be exported.

Figure 47: Prioritizing Neighbor Lists

Once the updated neighbor list has be created, it must be checked to confirm that basic neighbor list rules are followed before it is loaded into the RNC. These rules include:

Co-sectors should be neighbors of each other

Neighbor relations should be bi-directional

A cells neighbor list should not contain a neighbor with the same scrambling code as itself

A cells neighbor list should not contain two neighbors with the same scrambling code

A composite neighbor list created due to soft handover should not contain two unique neighbors with the same scrambling code

4.6.2. SHO Overhead Analysis

Soft Handover Overhead is the metric that gives the amount of radio resources being used in the Uu interface when the Active Set Size of the UE is more than 1. There are two ways to calculate this overhead.

1. Percentage of Soft Handover Traffic to the Total Traffic Soft Handover Traffic includes soft, softer, 3-way soft, 4 way soft, etc. Total Traffic will include the Primary Traffic and the Soft Handover Traffic. This type of metric can be calculated using the respective counters to do the capacity performance analysis. As of now, since we do not have much traffic on the network, we will not be able to rely on the counter values.

2. Average Number of Sectors used per UE during drive test This metric can be calculated using Active Set Size Plot from the Handset device making Long voice Call or using the Simulated Active Set Size Plot from the Scanner. This type is generally used to calculate the soft handover overhead using the drive test data.

To display the Active Set Size Count Plot from Long Call Handset, from the Summary Dashboard select the Long Call Handset and then click Radio Network Explorer. In the Radio Network Explorer window, select the Uu_ActiveSet_Count as an Attribute. This will display the Active Set Size in the Map window, as shown below in Figure 48.

Figure 48: Active Set Size Plots

The SHO Overhead can be calculated using the ActiveSet_Count legend on the right side of the Map window. Following is the formula for SHO overhead, which is taken from the U12 KPI document.

Equation 1: SHO Overhead

Where: AS Active Set Size M Maximum Active Set Size as defined in the RNC. Duration (AS) Duration of Call on a Active Set Size (AS = 1, 2,..M). Instead of duration, we

can use the number of drive test samples from the Active Set Size Plot.

To simply the formula, let us calculate the SHO overhead for a Active Set Size Plot Legend shown below.

Figure 49: Active Set Legend

SHO Overhead = (1*2295 + 2*173 + 3*44) / (2295+173+44) = 1.103

This is amazingly a very good value for the SHO overhead. This is because the UE is with only one SC in Active Set for most of the time as we see in the Active Set Size Plot above. This indicates the network has got very less internal interference and enhanced capacity. As per the U12 KPI document, the threshold for SHO overhead is 1.6.

Similar calculation for SHO Overhead can be done using the Simulative Active Set Size Plot using the Scanner Device as well.

If the KPI for SHO Overhead is not met the following steps may be taken by the Cluster RF engineer.

Identify the areas with higher Active Set Size Plot Verify the Pilot Pollution Plot in that area. If there is a Pilot Pollution, steps should be taken to

reduce it. Also verify the Too Many Server Plot. This is a good indication of Active Set Size. Coverage in

terms of Ec/No and RSCP may be good. But, Too Many Servers increases the SHO overhead and reduces the overall System Capacity.

If there are any Too Many Server noticed, steps should be taken to reduce coverage from 2nd, 3rd or 4th, etc., best servers while retaining or improving the coverage from 1st Best Server.

Coverage reduction or improvement can be done by changing RET, Mechanical Tilt, Azimuth or Antenna, if required.

While doing this, care should be taken not to loose the coverage of 2nd, 3rd or 4th, etc., best servers and increase the overshooting pilot from 1st Best Server.

Incase if there is any irresolvable Pilot Pollution or Too Many Server issues, optimizing the Soft Handover Parameters will help reducing the SHO overhead. But this should be done as the last measure, because any change in SHO parameters may impact the entire RNC.

4.7. Access Failure Analysis

The following section provides a summary of the Call Setup procedure. The fundamental steps required in accessing a UMTS network is similar for both CS and PS services. In both cases the UE utilizes the same random access procedure to request establishment of a RRC Connection with the RNC. If dedicated resources are available to setup this radio link, an RRC Connection will be established with the RNC. Once an RRC Connection is established with the RNC, the Core Network (CN) is signaled to establish an Iu connection between the CN and RNC. At this time the core network initiates security procedures such as Authentication and Ciphering. After the security procedures are completed, the UE requests services from the Core Network. The CN then requests the establishment of a Radio Access Bearer (RAB) with the RNC to support the requested services. If this RAB is established, the RNC will acknowledge the CN request and a successful access will have occurred. Alternatively, if any of these steps fail, an access failure will occur. Therefore, there are essentially 3 procedures that need to be completed before call setup is deemed to be successful.

RACH Access Procedure Used to access the network to initiate various procedures including network updates, voice & data call setup, paging responses

RRC Connection Setup Procedure Used to establish signaling radio bearers and provide an interface to the NAS layer

Pre-RAB & RAB Setup Procedure Used to establish end to end connection and complete authentication & security procedures whilst establishing DCH for a specific service type

Each of these sections has already been expanded upon in the Feature Guidelines which can be found at: http://docs.eng.t-mobile.com/inforouter/docs/~D461931. It is recommended that users familiarize themselves with content from this document to understand the Access Setup procedures in greater detail.

The Access failure is the product of the RRC Connection Failure, NAS Setup Failure and the RAB Establishment Failure. RRC Connection Success shall be counted when the RNC receives a RRC Setup Complete from the UE. NAS Setup shall be considered successful when the signaling messages in the call flow during call setup flow is successfully completed by relevant Network Elements. A RAB is considered successfully established when the RAB Assignment Response is sent by RNC to the CN. An AMR call flow is shown below to illustrate this:

Figure 50: AMR Call Flow

The current definitions for Access Failures as per the contract are:

CSVAccessFailureRate = 100

[

1

CSV Calls

CC Alerting / Connect

CSV Calls

RRC Connection Re quest

]

Equation 2: CSV Access Failure Definition

PSD Access Failure Rate = 100

[

1

PSD Calls

Activate PDP Context Accept

PSD Calls

RRC Connection Re quest

]

Equation 3: PSD Access Failure Definition

The next section highlights basic guidelines for using Actix Spotlight to troubleshoot Access Failures.

4.7.1. Spotlight Access Failure Analysis

After all drive test log files have been loaded into Spotlight, a summary screen as shown below will be displayed which shows a variety of issues including Access Failures.

Figure 51: Summary Dashboard

Hence to begin access failure analysis, proceed as follows:

From the summary dashboard, the CS & PS Access Failure rates are displayed. Hence, click on the Event Explorer link

Figure 52 will appear containing all critical issues. Hence, from the Events drop down menu, select both UMTS Call Setup Failures & UMTS PS Call Setup Failures to display all Access Failures. Selecting both of these options will highlight them in red

Selecting #Setup Failures will sort all failures in a descending manner. This list can also be exported by clicking on the Excel icon located at the top left portion of Figure 52

Selecting the magnifying glass button on the right of the #Setup Failures icon will display the access failures details along with a diagnosis of what led to the access failure. This is based on information contained within 5 secs of the failure.

Figure 52: Event Explorer

To analyze all access failures, check all boxes located in the Drill-down section located at the bottom left portion of Figure 52

Now, check the box to Load Entire File to allow detailed investigation of failures as shown in Figure 53. Whilst it is possible to select a time period in seconds for before & after an access failure, this might not produce enough information to successfully analyze the access failure hence it is recommended to load the entire file.

Figure 53: Events Drill-down

After the entire file is loaded, a new workspace appears as shown below. This workspace displays the following information:

Protocol Stack Browser

Setup Failures Map

UMTS Active & Neighbor Sets

Event Explorer

Figure 54: Events Drill-down Analysis

Protocol Stack Browser:

The Protocol Stack Browser provides detailed messaging around a specific event. It provides a host of Layer 3 RRC & NAS messages which contain:

RRC Setup Messages

Radio Bearer Configuration:

Measurement Control & Reports:

System Information Blocks (SIB):

The current Actix platform does not support the implementation of UE Traces. However, this will be available shortly and will contain information such as:

NBAP Protocol

RANAP Protocol

RNSAP Protocol

RRC Protocol

In addition to the Stack browser, it is also advisable to show the Message Browser window for Call Failure Analysis. This can be viewed by going to the toolbar, View Display Message Browser

UMTS Active & NBor Sets:

The UMTS Active & Monitored set window shows the respective current set at a specific point in the drive test. The information displayed is:

Primary Scrambling code (PSC)

RSCP & Ec/No for each PSC

Setup Failures Map:

The Setup Failures Map displays the following:

All Setup Failures

Active Set PSC

Active Set Ec/No

DL BLER

UE TxPower

Additional information can be displayed by going to the Attribute Explorer and choosing the required attributes.

4.7.2. Access Failure CausesFollowing is a basic flowchart that can be used for troubleshooting Access Failures.

Figure 55: Access Failures Troubleshooting Flowchart

Whilst some reasons for Access Failures have been presented below, subsequent sections exist to describe RACH & RRC Setup failures. Note that whilst parameters have been discussed in the following sections, all physical changes to control the RF environment needs to be exhausted before parameter changes should be considered.

Start Analyzing an Access Failure

Neighbor List Optimization

Optimization to create Pilot Dominance and reduce spillovers OR

Optimize SC

UL Coverage / Path Balance Optimization

UEs best server =

Scanners best server?

Possible Causes: 1) Poor Cell Reselection Parameters, 2) Hardware Issues,