umts optimization gauideline

• Cell FACH state to Cell PCH state 3G PS state transition • URA PCH state 3G PS state transition • 3G to 2G with PDP context activation PS test; 3G to 2G cell reselection • 2G to 3G wit

UMTS Optimization Guideline

BASIC TUNING 2

KPI S AND S ERVICE R EQUIREMENTS 2

IRAT Performance 2

CS Performance 2

CS Requirements 3

PS Performance 4

PS Requirements 5

T OOLS 8

Tools Requirements 8

RF Measurements 11

Throughput Measurements 12

Call Performance 13

Tools Currently Available to Capture / Process data 15

Drive Test Equipment and Software 18

Post-Processing Software 22

P RE -L AUNCH O PTIMIZATION P ROCESS 24

Database Verification 25

Drive Test Route Selection 27

Drive Test Data Collection 29

Data Post-processing and Root-Cause Analysis 30

Root Cause Analysis and Recommendation 31

High Downlink Interference 31

Pilot Pollution 33

Out of Pilot Coverage 34

Insufficient received UL DPCH power 34

High UE TX Transmit Power 35

Swapped feeders 36

Low data throughput 38

Handover Event Detection Failure 40

No Suitable Cell 42

Assessing Success of Recommended Change 42

OMC STATISTICS BASED TUNING 43

KPI S 43

IRAT - Inter Radio Access Technology (IRAT) performance 51

CS Performance additional information 52

PS Performance additional information 52

T OOLS 53

Tools Requirements 53

Tools Currently Available to Capture / Process Data 54

P OST -L AUNCH O PTIMIZATION P ROCESS 57

Data Post-processing and Root-Cause Analysis 58

Optimization Strategy per Root-cause and/or Problem Category/Type/Area 68

Assessing Success of Recommended Change 84

Basic Tuning

KPIs and Service Requirements

IRAT Performance

Handover between WCDMA and GSM allows the GSM technology to be used

to give fallback coverage for WCDMA technology This means subscribers can experience seamless services even with a phased build-out of WCDMA The IRAT performance is evaluated under the following test cases

• IDLE mode to GERAN (3G to 2G cell reselection)

• Cell FACH state to Cell PCH state (3G PS state transition)

• URA PCH state (3G PS state transition)

• 3G to 2G with PDP context activation (PS test; 3G to 2G cell reselection)

• 2G to 3G with PDP context activation (PS test; 2G to 3G cell reselection)

• 3G to 2G CS Handover (CS-only test)

• 2G to 3G CS Handover (CS-only test)

• 3G to 2G CS Handover with PDP context activation; Multi-RAB handover (CS + PS test)

• Event 3A measurement activation / deactivation

CS Performance

• Call Event Success Rate

• Call Block Rate

• Drop Call Rate

• SHO Event Success Rate

• Location Update success rate

• Channel Utilization

• Call Completion Success Rate

• Signaling Load

• Inter Cell Handover Success Rate

• Handover Success Ratio

• Paging and Routing Area Updates

• Connection Setup Success and Dropped

• Call Setup Rate

• Bad Quality Call Rate %

These two KPI’s RRC setup complete rate and RRC Establishment

complete rate combine to give us another key KPI, accessibility, which is a measure of the origination success rate

A typical retainability requirement for a network is Drop Call Rate < 1.5% for voice conversations.

PS Performance

• RLC DL throughput: Total RLC downlink throughput

• RLC UL throughput: Total RLC uplink throughput

• Session App Mean Throughput DL (kbit/s): Mean throughput, calculated over the whole of the current session, for data received at the application level (mean downlink throughput)

• Session App Mean Throughput UL (kbit/s): Mean throughput, calculated over the whole of the current session, for data sent at the application level (mean uplink throughput)

• Ping Delay (ms): Delay for an individual Ping Response during the current Ping session

• Success Rate of internet connections

• Variable data rate performance

• End to end packet delay transfers

• Throughput at the edge of the cell

• PS and CS Bearers

• Attach / Context

• Blocked Error Rate %

• Packet Bad Quality %

• PDP Context Activation success ratio

• Attach success ratio

• PDP context drop ratio

• Data Transfer drop ratio

• Attach setup time

• PDP context activation time

• Service Access time

• End to end access time

• Mean user data rate

• Round trip time

• Packet loss ratio

• Initial Service Response

• Transfer interruption time

• End to end accessibility success ratio

• Service Access Success Ratio

PS Requirements

• HSDPA DL Application Layer Throughput > 400 kbps

• R’99 DL Application Layer Throughput > 133 kbps

• HSDPA Ping Round trip Latency < 150ms

• R’99 Ping Round trip Latency < 150ms

• OCNS with 20% of Minimum Design capacity

Optimization Insights

Optimizing the Network

The optimization process should start in the so-called pilot network, an intermediate stage of the network rollout where only the common channels for signaling and synchronization are use While carrying no traffic itself, this pilot network provides a useful representation of the traffic flow in the future operational WCDMA network Many aspects of optimization activities can be done in this phase

Some other aspects of optimization such as adjusting the Soft Handover ratio must wait until the user equipment (UE) is in operation.

Basic Tuning to be done early phase of roll out

Coverage Optimization

1 Since each Node Bs continuously transmits CPICH, scanning the CPICH using a Drive test system enables a quick and effective examination of the network RF Coverage, as well as a means to identify the Node Bs It is important to detect high CPICH levels from too many cells as this causes interference

2 Lack of RF Coverage - Can cause calls to drop or be blocked due to lack of coverage at the edge of the cell site coverage or coverage hole in the area

Missing Neighbors and Pilot Pollution

1 Missing Neighbor in the neighbor list - Neighbor condition occurs when

a high level pilot (i.e one whose measured value is above T_Add (Threshold to Add)) that does not appear in the neighbor list is sent to a phone This condition adds interference, resulting in a low quality connection, and possible causing dropped calls

2 Pilot Pollution and Interference - Pilot Pollution occurs when there are

an excessive number of pilot signals In such a situation a subscriber could notice interference on an active call

Balancing of Channel Transmission Powers:

The relative output powers of various channels in WCDMA can be freely adjusted, and should be since they have different requirements

Signaling channels need less power than the channels that carry user data

Particularly important to ensure that Synchronization channels are transmitted strongly enough to be reliably detected

Cells in the vicinity of one another must use different offsets for the synchronization burst in order for the synchronization channel to work properly

Type of test call in drive-test:

Short voice call: Each voice call is made to a PSTN number and held for duration of 100 seconds and waited for 10 seconds between calls

Long Voice call: Voice call is made to a PSTN number and held until the end of the cluster drive test, or until the call dropped

Short CS Data Call: CS data call is made to another mobile or to a CS ftp server and held for a duration of 100 seconds then wait for 10 seconds before making the next call

Long CS Data Call: CS data call is made to another mobile or to a CS ftp server and held until the end of the cluster drive test, or the call dropped.Short PS Call: About 100 seconds worth of data transfer DL or DL FTP a 2.5 MB file (approximately)

Long PS Call: About 1 hr worth of data transfer DL or multiple DL FTP files

of size about 10MB

KPIs:

CPICH RSCP: Received signal code power, the received power on onecode measured on the primary CPICH

DL RSSI: Received signal strength indicator, the wide-band received

power within the relevant channel bandwidth

CPICH Ec/No: The received energy per chip divided by the power density

in the band

UE UL TxPwr: The total UE transmitted power on one carrier

Transport CH BLER: Estimation of the transport channel block error rate

Call event success rate: Formula: # Call Ends / (# Call Ends + # Blocked Calls + # Dropped Calls)

SHO event success rate: Formula: (# add + # remove + # replace) / # all SHO

Tools

Tools Requirements

Different tools are required to accomplish basic tuning in UMTS network

• Cell Planning Tools

• Route Planning Tools

• Drive Testing Tools

• Data Processing and Report Generation Tools

Cell Planning Tools

During basic tuning, Cell Planning Tool is used to:

• Plan and design UMTS network,

• Analyze coverage and interference,

• Design neighbor cell relationships and define handover margins,

• Analyze traffic,

• Review network capacity planning for voice and data services

Route Planning Tools

Often Mapinfo is used to plan drive routers before drive-tests Mapinfo is a commercial application working on PC In route planning process, Mapinfo can be used to plan route, sites and spatial data visualization and printing

A digital map is required with Mapinfo format including raster and vector information of terrain

Besides Mapinfo, maps or map software such as Microsoft Street and Trips, can be used to plan routes

Driver Testing Tools

During the basic tuning for a pre-launch UMTS network, drive-testing is the most important way to collect the network performance data, since there are limited subscribers using the UMTS pre-launch network and accurate network statistics is not available from OSS Drive testing tools are used to:

• Record UE and scanner measurement data,

• Visualize UE and scanner measurement data during drive testing (synchronized maps, tables, graphs and text information)

To do the drive test in UMTS network, the following components are required

Since UMTS can support voice, CS data and PS data, usually we need more test UEs during the drive test To get all RAB performances in UMTS network, the following call type is necessary to do a drive test:

 Short voice call: Each voice call is made to a PSTN number and held for duration of 100 seconds and waited for 10 seconds between calls.

 Long Voice call: Voice call is made to a PSTN number and held until the end of the cluster drive test, or until the call dropped

 Short CS Data Call: CS data call is made to another mobile or to a CS ftp server and held for a duration of 100 seconds then wait for 10 seconds before making the next call

 Long CS Data Call: CS data call is made to another mobile or to a CS ftp server and held until the end of the cluster drive test,

or the call dropped

 Short PS Call: About 100 seconds worth of data transfer

GPS can provide position information during drive tests With GPS we can get the result that abnormal RF problem can be connected to geographical information

• FTP Server

In order to transfer data stably without any unexpected problem from Internet,

a dedicated FTP server should be set up before doing drive tests

Different size files on a FTP server should be put so as to perform short PS data calls or long PS data calls For example: 1MB, 2 MB, 5 MB, 10MB, 100MB, etc

Data Processing and Report Generation Tools

To analyze drive test log file, post data processing tools can be used to display a plot, which includes radio measurement results and geographic information on MapInfo In addition, this post data processing tools can provide the statistics of call events and radio measurement data, often used in our customer reports

RF Testing Tools

A spectrum analyzer is a tool to monitor spectrum characteristics It is useful to track external interference inside or outside of the operational band In the initial deployment phase (coverage limited system), it can be used to survey the level of adjacent channel interference from other operators

RF Measurements

The following is the key RF performance indication in UMTS drive tests.Test UE

 Scrambling codes of active set cells and monitored set cells

 CPICH_Ec/No of active set cells and monitored set cells (dB)

 CPICH_RSCP of active set cells and monitored set cells (dBm)

 Scrambling codes of all CPICHs

 Ec/No of all CPICHs (dB)

 RLC DL throughput: Total RLC downlink throughput

 RLC UL throughput: Total RLC uplink throughput

 Session App Mean Throughput DL (kbit/s): Mean throughput, calculated over the whole of the current session, for data received at the application level (mean downlink throughput)

 Session App Mean Throughput UL (kbit/s): Mean throughput, calculated over the whole of the current session, for data sent at the application level (mean uplink throughput)

 Application Throughput DL(kbit/s): Current throughput for data received at the application level (current downlink throughput)

 Application Throughput UL(kbit/s): Current throughput for data received at the application level (current uplink throughput)

 Ping Delay (ms): Delay for an individual Ping Response during the current Ping session

Call Performance

Often the drive test tools can provide some call events statistics that can

be used to evaluate radio network performance These call performance statistics can be categorized into four groups

Accessibility

 RRC connection setup successful rate from the UE point of view

% 100 request

connection RRC

sent of Number

complete setup

connection RRC

sent of Number

×

 RB establishment successful rate per RB from the UE point

of view

% 100 setup

bearer radio received of

Number

complete setup

bearer radio sent of

Retainability

 Average RRC connection drop rate when the UE is in cell_DCH mode

[ ] s- 1 test

drive

w hole the of tim e Total

idle to

C ell_D CH from

is state

U E he t

in w hich drops

abnorm al of

N um ber

 Average RRC connection drop rate when the UE is in cell_FACH mode

[ ] s- 1 test

drive

w hole the of tim e Total

idle to

C ell_FA C H from

is state

U E he t

in w hich drops

abnorm al of

N um ber

Mobility

 Soft handover success rate

(# add + # rem + # repl) / # all

Where

add = Radio Link Addition events

rem = Radio Link Removal events

repl = Radio Link Replacement events

all = all Radio Link events, including failures

 IRAT hard handover success rate

From UMTS to GSM:

% 100 command UTRAN

from HO of Number

Complete UTRAN

from HO of

From GSM to UMTS:

% 100 command UTRAN

to HO of Number

Complete UTRAN

to HO of

 Downlink transport channel BLER

 Best serving cell CPICH Ec/No, i.e pilot channel quality

Tools Currently Available to Capture / Process data

At present many drive test software and analyze software are available to capture and post-process measurement data Basically these software can be categorize into two groups based on the provider of these software

Software developed by Mobile Infrastructure Equipment Vendor

An advantage of this kind of software is that vendors can add some additional test functions to let these software work well with their infrastructure network For example, Ericsson adds SQI measurement function in their drive test tools – Tems Investigation, this function can evaluate voice quality during drive tests Also in Ericsson infrastructure network, same function is used in performance statistic

Two major drive test and post-process tools listed below are commonly used in different operators

Nemo Outdoor™

Nemo Outdoor™ is a portable engineering tool designed for measuring and monitoring the air interface of wireless networks Fast and accurate measurement data provides detailed information in real time for 2G, 2.5G, 2.75G, and 3G networks

For more detail information about Nemo Outdoor, please read his web site http://www.nemotechnologies.com/index.php?249

Nemo Analyze™

Nemo Analyze™ is a front-line analysis tool for quick and easy data review It can be used on the field or in the office for immediate problem solving and report generation Nemo Analyze is designed to be the analysis tool for measurement files produced with the Nemo measurement tools: Nemo Outdoor and Nemo Handy

For more detail information about Nemo Analyze, please read his web site http://www.nemotechnologies.com/index.php?267

Tems

Tems products are developed by a branch of Ericsson Corporation Tems products portfolio includes radio network planning, radio network optimization, benchmarking, indoor coverage testing

Tems Investigation

TEMS Investigation is a portable air-interface tool for troubleshooting, verification, optimization, and maintenance of mobile networks The tool collects all the data needed to keep the network running smoothly and to plan for future improvements The collected data is presented in real time, and can be used together with site information to improve troubleshooting

capability The flexible interface allows the user to filter network data and focus on relevant information for truly in-depth analysis

For more detail information about Tems Investigation, please read his web site

http://www.ericsson.com/solutions/tems/realtime_diagnostics/investigation.shtml

Tems DeskCat

TEMS DeskCat is advanced post-processing software It enables users to easily mine drive test data, visualize air interface problems, and drill down into the data for easy analysis and problem resolution It also provides the unique System Quality Report for comprehensive network comparison Designed to support experienced RF engineers and network optimization specialists, but able to provide managerial reports as well

For more detail information about Tems DeckCat, please read his web site

http://www.ericsson.com/solutions/tems/realtime_diagnostics/deskcat.shtml

Software developed by Testing and Measurement Company

Developed by companies dedicating to develop sophisticated equipments, these drive test tools have a common characteristic on RF testing function

For more detail information about Rohde-Schwarz products, please read their web site http://www.rohde-schwarz.com

Agilent E6474A

The E6474A Agilent Wireless Network Optimization Platform provides true cross technology scalability and allows early verification of network deployments for 2G, 2.5G and 3G wireless networks Its optimization platform enables wireless service providers and network equipment manufacturers to proactively address challenges with wireless voice and data networks by quickly and accurately identifying problems

Drive Test Equipment and Software

The field measurement equipment usually consists of:

• A laptop, which store the measurements data and run the drive test software

• A GPS, to record the exact location of the measured parameters

• Mobile phones and scanners to be used as measurement devices

HUB Scanner

Three phones can used to provide a flexible test configuration and test both data and voice calls (short and long calls) Using both mobile and scanner simultaneously in WCDMA measurements enables the measuring

of all pilots available in the area and the comparison of the results to the view seen by the user equipment (UE) The UE reports values based on a neighbor list received through signaling and makes cell reselections and handovers based on the planned neighbor list However, there can be pilots available that are not defined in the neighbor list and these can be spotted with a scanner In other words, measurements together with scanner and mobile would also identify missing or interfering pilots

Effective UMTS drive test software should be able to measure and perform the following tasks:

• Evaluate call-processing operations

• Perform selected call processing functions

• Measure and report the amplitude of the received base station signal

• Measure and report the signal quality of the received base station signal

• Read and report the neighbor cell list from the broadcast messages

• Report the amplitude of neighbor list base stations

• View and log protocol messages in decoded form for easy interpretation

• Quantify wireless data user’s quality of service (with data measurement options)

• Perform integrated analysis using the phone and receiver at the same time

• Correlate call drops within the RF environment

• Show current position and the route traveled on a map as data is collected.

The following is a list of some of the parameters measures

• Real-Time Data Throughputs

• RLT Counter Radio link timeout

• FER

• Vocoder State

• DTX State

• Retransmitted RLC Block Rate

• RLC/MAC Real-Time Data Throughputs

• Each CPICH in the Active List

• Ec/No of each CPICH in the Active List

• Composite and per finger RSCP

• Each CPICH in the Candidate List

• Ec/No of each CPICH in the Neighbor List

• Cell ID of each CPICH in the Active and Neighbor Lists

− Downlink Coding Scheme

− Uplink Coding Scheme

• Streaming Video

• IP Protocol Trace

• Data throughput UL/DL

• Ftp, http, and ping test applications

Key features of a data analysis and post processing tool for UMTS is the ability to:

• Support multiple technologies i.e GSM, GPRS and WCDMA on one platform simultaneously

• Provide maps, histograms and cumulative distribution charts and statistical analyses of key packet data and radio link performance metrics

• Correlate WCDMA scanner and UMTS UE measurements from independent log files

• Support interfaces to a variety of vendors of drive test equipment, protocol analyzers and measurement programs

• Access to radio interface messaging, including message counters and cause value breakdown for failure, error and reject messages

• Correlate abnormal data performance with radio link parameters

• Assess Subscriber-perceived performance analysis for IP and data applications (e.g HTTP, UDP)

• Provide support for open interfaces, which can typically be used to collect performance data well in advance of proprietary data sources, like test mobile and peg counter data

• Reduce data through binning and standard database type querying and filtering capabilities

• Synchronize data collected from different network elements and sources to remove timing discrepancies

• Provide interfaces into databases for storing collected data statistics and provide web-enabled reporting interfaces for extracting data

• Embed engineering expertise into the software to automate the process of analyzing large amounts of data

Pre-Launch Optimization Process

An overview of the radio network optimization process will be briefly presented

Database Verification

Purpose

YesNo

Performance Analysis

Parameters Tuning

Mechanical Tuning

Meet Project Target

FinishPerformance Review

The purpose of the database verification activity is to verify that the radio network has been properly configured, meaning that the actual system parameter settings correspond to the recommended values, and RF parameter settings correspond to the radio network design results.

RAN database verification is the first step of basic tuning By implementing the verification, unnecessary troubleshooting will be avoided and further investigations can be carried out focusing on problems other than parameter configuration mistakes

Database verification includes two parts of work- RF Parameters Verification and System Parameters Verification

RF Parameters Verification

The RF parameter settings that are implemented in the live network and the original radio network design results are the base to conduct basic tuning These RF parameter settings contain PN code plan, neighbor list plan, antenna height, antenna direction and tilt Make sure that the RF parameter settings in the live network are exactly the same with the radio network design results

Meanwhile, conducting drive test for each site can ensure that no antenna swap mistakes exist in the live network

Often missing neighbors and antenna swaps are the most common mistakes in the pre-launch network, resulting in serious radio network performance problems in UMTS networks, e.g high drop call rate in some cells, bad quality area (with low Ec/No) etc

System Parameters Verification

In order to avoid abnormal system parameter setting in live network, verifying the parameter settings in the live network correspond to the

recommended values is important These recommended values are based on lots of testing and simulations results, which are optimal values

in most networks

The procedure to implement system parameters verification is as below:

1 Retrieve current parameter settings from systems

2 Check current versus recommended parameter values

3 Apply the consistency check rules to current parameter values

4 Produce a list of parameters to be changed and generate the change requests for clients

5 Get approval from clients and load changes to the systems

A parameter dump should be created from the live network to retrieve current parameter settings, following by a conversion of the system dump file into readable Microsoft Excel file with script developed by Excel Macro

or VB

Equipments from different vendors often provide different recommended system parameter setting values, which may require to be modified when new software version is released Therefore, it is important to get recommended parameter setting values for current software version from clients before implementing system parameter setting verification

Drive Test Route Selection

Drive testing is done to verify the coverage and the service requirement KPI’s i.e availability, Retentivity etc or for pin pointing and resolution of any network related issue The Drive route criteria for both the scenarios are different

Baseline drive route

• The main purpose of baseline drive testing is to find the problem areas of the network Using field measurement, coverage holes, interference areas, and handoff regions.

• The primary drive route consists mainly of freeways, highways and high traffic areas (like downtown) The high traffics areas are also define in the coverage and capacity objective, part of the Wireless System Design (and Implementation) Report Both directions

of travel need to be considered If the three primary types of road do not cover problem areas, secondary road should be considered If time and resource permit, selected secondary streets can be included in the drive routes

• For baseline drive test, the drive routes need to cover farther than good coverage areas For example, route will include roads covered lower than Ec/Io=-16dB

• The route should cover all the sectors included in the test

• Avoid the area with known coverage problem because of the unavailability or hardware problems of cells covering the area

Problem Resolution Drive route

When problem area is identified, a punctual drive route should be design

to verify and quantify the extent of the problem

• The route should be driven both directions to verify if the problem exists in one direction or both directions E.g To verify handovers from any sector from a site we need to check the outgoing

and incoming handovers for which we need to drive in both directions

of the drive route

• If we do encounter any problem/ issue we should repeat the route so as to repeat the problem

• If in the network there are a couple of problem areas, it is recommended to have separate spot drives for each of the problem areas

Drive Test Data Collection

Before we start data collection we need to make sure that the hardware is connected and configured properly

• Make sure all the Phones, Scanners, Scanner Antenna’s, GPS, Hubs and Laptop are connected properly

• Make sure all the devices are connected to the appropriate COM port, and the COM ports are configured accordingly

• Set up the Autocall settings to set up the phones for Long Call and Short call with the appropriate set up times, number to call, Max Idle time and Connect time

• Make sure the appropriate Mapinfo workspace for the drive test area is configured in the Drive Test tool

• Import the most current Cell site database which has information on the Sites, their PN’s and the Antenna orientations

• Set up the FTP server with a suitable file for testing of Data Download and upload speeds

• Set up the Scanner configurations as a Pilot Scanner with the appropriate Scan lists, Avg Ec/Io and Correlation taps

• Open at least one window for the Map, The phone data, Scanner Data, and the Summary data for all the devices

• Connect all the devices, the Data collection software shows the connected devices.

• Run a test call to confirm that the Autocall, Scanners, GPS and the phones working fine

• If everything is working fine, start logging and save the log files with suitable identifiers like <<Date>><<Time>><<Log File>> Save the log files in the appropriate directory

Data Post-processing and Root-Cause Analysis

Performance recording

Performance recording includes two parts, log-file from drive-test tools and

UE trace log-file from OSS with UE tracing function UE tracing function provides UL information received by Node B side and signaling between

Node B and RNC Performance recording is the important input when performing a basic tuning in pre-launch network.

Fault logs from RNC and Node B

Fault logs are useful to identify abnormal system behavior caused by node faults

Parameter data

Parameter setting reviews are useful to understand the intention of the original radio plan and to determine how the parameter changes should be

Root Cause Analysis and Recommendation

High Downlink Interference

Phenomena

During the drive test, following phenomena might be observed through drive testing tools:

• Received Ec/No of the pilot channel is less than –16dB and

• Received RSCP of the pilot channel is high enough to maintain the connection, e.g > -100dBm and

• DL RSSI is very high and

• The connection drops eventually

Reason 1 – Non Dominant Cell

Many overlapping cells exist in the problematic areas and received signal strengths of the pilots in these overlapping cells are almost the same.

Recommendation

A direct and effective solution is to increase the pilot channel power – Primary CPICH power of the desired cell

Reason 2 – Dominant Interferer

An undesired cell is identified because of its high signal strength, causing missing neighbor problem

Recommendation 3

The third solution is to change the antenna configuration of the overshooting cell The possible practices include tilting down the antenna, re-directing the antenna orientation, reducing the antenna height and so on

This solution will not lead to UL/DL coverage imbalance problem in the interferer because UL/DL path-loss is changed simultaneously

Reason 3 – Low Best Serving PPilot/PTot

The third possible reason is that the pilot power setting is not large enough to fulfill existing downlink load, because low received Ec/No

of the best serving pilot channel (near or less than –16dB) can be observed even if there is no other cell

In cell_DCH mode, pilot pollution refers to the phenomenon that a

UE at one location alters its active set cells frequently (e.g active set update rate is very high) because many received pilot channels have similar quality (or signal strength) such as Ec/No (or RSCP)

Reason – No Dominant Cell

Due to poor cell planning, a large number of overlapping cells exist

at a particular area

Recommendation 1

To change the antenna configurations or reduce the pilot power of the undesired cells is a common practice to remove the cells overlapping

Recommendation 2

An alternative solution to remove the cell overlapping is to increase the pilot channel power – Primary CPICH power of the desired cells.

Out of Pilot Coverage

Phenomena

During the drive test, following phenomena might be observed

• Received Ec/No of the pilot channel is less than –16dB and

• Received RSCP of the pilot channel is very low, e.g 100dBm and

<-• DL RSSI is very low and

• The connection drops eventually

Reason – low pilot channel power

To set the low pilot channel power can lead coverage holes

Recommendation 1

The most common solution to overcome this problem is to add a new site in the problematic area

Recommendation 2

To increase the pilot channel power is an alternative solution

Insufficient received UL DPCH power

Phenomena

During the drive test, following phenomena might be observed through drive test tools and UE tracing function:

• Received Ec/No of the pilot channel is larger than –16dB and

• UE Tx power does not reach the maximum allowed value and

• UL SIR target of the radio connection reaches to the maximum allowed SIR target and

• UL BLER of the radio connection increases and

• The connection drops eventually

Reason

The possible reason that the base station cannot receive high enough power from the uplink dedicated physical channel is because the parameter - maximum allowed UL SIR Target is set too low

Recommendation The maximum allowed UL SIR Target should be justified to allow

UEs to transmit with higher power

High UE TX Transmit Power

Phenomena

During the drive test, following phenomena might be observed though drive test tools and UE tracing function

• Received Ec/No of the pilot channel is larger than –14dB and

• Received RSCP of the pilot channel is good, e.g <-85dBm and

• UE Tx power reaches the maximum UE allowed value (23dB) and

• UL BLER of the radio connection increases

• UL RSSI is high

Reason – Uplink Interference

The possible reason that UE transmit with very high power even if with good the downlink quality (Ec/No) and high downlink signal strength (RSCP) is because of UL interference

The UL interference could be internal interference (generate by other UEs) or external interference (repeater or industry interference)

Recommendation

Check cell UL loading in nearby cells to determine whether the interference is coming from internal Check external interference with spectrum analyzer if there is external interference exsiting

Swapped feeders

Phenomena

Due to swapped feeders, many problems will occur such as no downlink coverage, no uplink coverage or high UL/DL interference The following are some (but not limited to) examples of swapped feeders:

 Case 1: Cell B Tx feeder is swapped with the cell A Tx

feeder The following symptoms might be observed:

 Scrambling codes cover wrong directions

 Handover fails from other cells to Cell A/Cell B because

of improper handover relationship or uplink DPCH synchronization problem

 Connection setup will fail during random access or uplink DPCH synchronization procedures Connection setup fails during random access or uplink DPCH synchronization procedures

 Case 2: Cell B Tx feeder is swapped with one of the cell A

Rx feeder The following symptoms might be observed

 There is no downlink coverage (Cell B desired coverage area)

 Downlink interference is high (Cell A desired coverage area)

 Scrambling code covers wrong direction

 When the UE tries to connect to cell B in cell A area, connection setup fails during random access or uplink DPCH synchronization procedures

A

C B

 If the UE tries to handover to cell B in cell A area, the UE may always send addition handover events to UTRAN but handover function always fails due to uplink DPCH synchronization problem.

 The UE connected to cell A transmits with higher UE Tx power than that in normal feeder case because of higher

UL interference (e.g UL RSSI)

 Connection drops when the UE moves to the planned cell

B area

 Case 3: One of the cell B Rx feeder is swapped with another

cell A Rx feeder The following symptoms might be observed:

 The UE connected to cell A or/and cell B transmits with higher UE Tx power than that in normal feeder case because of higher UL interference (e.g UL RSSI)

• Average UL or DL throughput of the radio access bearer is much lower than the data rate of the known source or

• Long round trip time or

• Many missing packets

Reason 1 – Poor Radio Link Quality

Poor radio links introduce error bits in packets To keep integrity of the packets received, system retransmits the error packets However, this may results in longer RTT and lower data throughput

Recommendation

Refer to “High Downlink Interference”

Reason 2 - Many Down-Switches Due To Coverage Triggering

The imbalance between PS64/384 or PS64/128 radio bearer and pilot coverage can trigger channel switching function to switch its radio bearer to the next lower bit rate when it reaches to the coverage border This results in lower overall throughput of the connection

Recommendation

Improve the network coverage

Reason 3 - Many Down-Switches Due To Congestion Control

Because of congestion, the connection might be switched down to the common channel, causing the low overall throughput of connection

The problem that low data throughput due to congestion control is rarely happened in pre-launch network If it happens, changing handover parameter to move traffic to other neighbor cells, or decreasing the CPICH power to reduce the coverage of the congestion cell

Handover Event Detection Failure

The handover event detection failure defined in this guide is that the network side does not receive “measurement reports” when the

UE enters (or leaves) the desired (or undesired) cell coverage area

Reason 1 – Poor Uplink Quality

UTRAN does not receive “measurement reports” from UE, which implies the quality of poor uplink is poor

Recommendation

Refer to High UE Transmit Power (Uplink Interference)