umts optimization guideline

UMTS Optimization Guideline of 82

UMTS Optimization Guideline

1. BASIC TUNING...................................................................................................................................2

1.1 KPIS AND SERVICE REQUIREMENTS..............................................................................................21.1.1 IRAT Performance....................................................................................................................21.1.2 CS Performance........................................................................................................................2

1.1.2.1 CS Requirements........................................................................................................................31.1.3 PS Performance........................................................................................................................4

1.1.3.1 PS Requirements.........................................................................................................................51.2 TOOLS............................................................................................................................................8

1.2.1 Tools Requirements..................................................................................................................81.2.1.1 RF Measurements.....................................................................................................................111.2.1.2 Throughput Measurements......................................................................................................121.2.1.3 Call Performance.......................................................................................................................13

1.2.2 Tools Currently Available to Capture / Process data............................................................151.2.2.1 Drive Test Equipment and Software.......................................................................................181.2.2.2 Post-Processing Software........................................................................................................22

1.3 PRE-LAUNCH OPTIMIZATION PROCESS........................................................................................241.3.1 Database Verification.............................................................................................................251.3.2 Drive Test Route Selection.....................................................................................................261.3.3 Drive Test Data Collection.....................................................................................................281.3.4 Data Post-processing and Root-Cause Analysis....................................................................291.3.5 Root Cause Analysis and Recommendation...........................................................................30

1.3.5.1 High Downlink Interference......................................................................................................301.3.5.2 Pilot Pollution..............................................................................................................................321.3.5.3 Out of Pilot Coverage................................................................................................................331.3.5.4 Insufficient received UL DPCH power....................................................................................331.3.5.5 High UE TX Transmit Power....................................................................................................341.3.5.6 Swapped feeders.......................................................................................................................351.3.5.7 Low data throughput.................................................................................................................371.3.5.8 Handover Event Detection Failure..........................................................................................391.3.5.9 No Suitable Cell.........................................................................................................................40

1.3.6 Assessing Success of Recommended Change.........................................................................41

2 OMC STATISTICS BASED TUNING.............................................................................................42

2.1 KPIS.............................................................................................................................................422.1.1 IRAT - Inter Radio Access Technology (IRAT) performance.................................................502.1.2 CS Performance additional information................................................................................512.1.3 PS Performance additional information................................................................................51

2.2 TOOLS..........................................................................................................................................512.2.1 Tools Requirements................................................................................................................522.2.2 Tools Currently Available to Capture / Process Data...........................................................53

2.3 POST-LAUNCH OPTIMIZATION PROCESS......................................................................................552.3.1 Data Post-processing and Root-Cause Analysis....................................................................562.3.2 Optimization Strategy per Root-cause and/or Problem Category/Type/Area.......................662.3.3 Assessing Success of Recommended Change........................................................................82

inCode CONFIDENTIAL and PROPIETARY


1. Basic Tuning

1.1 KPIs and Service Requirements

1.1.1 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)


3G to 2G CS Handover with PDP context activation; Multi-RAB handover

(CS + PS test)

Event 3A measurement activation / deactivation

1.1.2 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 %

DL Power Outage %

SHO Overhead

Bs TXP

RAB establishment success rate

1.1.2.1 CS Requirements

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.

Accessibility

The network operator should target an Accessibility rate greater than 98 %

for circuit switched voice conversations and packets switched data

sessions.

Retainability

Retainability is a measure of the Radio networks ability to maintain an

active mobile session until the user terminates. It indicates the percentage

of active calls dropped.



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

for voice conversations.

1.1.3 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


emanus, 04/17/06,

Same numerator and denominator counters


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

1.1.3.1 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 one

code 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

1.2 Tools

1.2.1 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

RF Test 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.

Test UE

With Test UE, drive testing tools can capture RF measurements on the UE

side, like UE transmit power, DL CPICH Eb/No, DL RSSI, etc. Further more,

to get a full picture (both downlink and uplink information) of the problem, it is

possible to use UE trace function during the drive test, if the RAN and OSS

can support this function.

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 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.

Pilot Scanner

A pilot scanner is a tool to measure the CPICH Eb/No and CPICH RSCP

regardless the neighbor list setting, correlated with GPS positioning data. It is

useful to determine a handover relationship and to evaluate radio wave

propagation characteristics, pilot channel qualities, soft handover area

locations and downlink interference contributions.

GPS

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.

1.2.1.1 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)

DL RSSI (dBm)

DL transport BLER (%)

DL SIR target and estimated DL SIR (dB)



UE transmitted power (dBm)

All UE sent and received L3 messages

Pilot Scanner

Scrambling codes of all CPICHs

Ec/No of all CPICHs (dB)

RSCP of all CPICHs (dBm)

DL RSSI (dBm)

1.2.1.2 Throughput Measurements

During the drive test in UMTS network, it is important to measure and monitor

wireless data service performance, since wireless data service is the

significant characteristic of UMTS technology. PS performance

measurements can be obtained as follows:

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.

1.2.1.3 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

RB establishment successful rate per RB from the UE point of view

Retainability

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

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

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:

From GSM to UMTS:

Quality

Downlink transport channel BLER

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

1.2.2 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

Nemo is a Finland company which dedicates to develop drive test and

post-process software for mobile networks. The former of this company is

a branch of Nokia. Nemo is used commonly by operators who use Nokia

system, like T-Mobile.

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


http://www.nemotechnologies.com/index.php?249


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.


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

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

http://www.nemotechnologies.com/index.php?267


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.sht

ml

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 example:

Rohde-Schwarz TS9951+ ESPI+ROMES3

Rohde-Schwarz TS9951 is a drive test hardware used to support up to 4

mobile phones. Rohde-Schwarz ESPI is a test scanner to accomplish the

PN scan and CW measurement. These two tools should be run on the

drive test software Rohde-Schwarz ROMES3.

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.


http://www.rohde-schwarz.com/

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

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


1.2.2.1 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.

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:


HUB

Scanner


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.

Interlayer Messages

• UMTS Layer 3 Messages

• GSM Layer 3 Messages

• GSM Acknowledged Mode

Messages Layer 2

• GPRS RLC/MAC Messages

• GPRS GMM/SM Messages

QoS Indicators

• Real-Time Data Throughputs



• RLT Counter Radio link timeout

• FER

• Vocoder State

• DTX State

• Retransmitted RLC Block Rate

• RLC/MAC Real-Time Data Throughputs

• RLP Report

• Handover Counter

UMTS Measurement Information

• UL/DL ARFCN

• ARFCN RxLev

• 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

• BSIC

• Power Control

– UE Tx Power

– DPCH SIR

HSDPA Measurement Information

• CQI

• DCH BLER

• DCH Retransmissions

• DSCH Throughput (kbit/s)

• SCCH OVSF Code Info

• HS Session



GSM/GPRS/EDGE Layer State and Measurement Information

• Layer 1 Information

• RR Information

• MM Information

• MAC Information

• RLC Information

− Downlink Coding Scheme

− Uplink Coding Scheme

• LLC Information

• GMM Information

• SM Information

• SNDCP Information

• Service State

Data and service testing

• Streaming Video

• IP Protocol Trace

• Data throughput UL/DL

• Ftp, http, and ping test applications.

• MMS and SMS testing

• New Command sequence

• Roundtrip delay

1.2.2.2 Post-Processing Software

Post processing forms a key counterpart to data collection in the

verification of infrastructure performance, automated calculation of

performance metric analyses and troubleshooting.

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.



1.3 Pre-Launch Optimization Process

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



1.3.1 Database Verification

Purpose


Yes

No

Basic Tuning

Database Verification

Performance Monitor

Drive Test Performance Report

Test User Complain

Performance Analysis

Parameters Tuning

Mechanical Tuning

Meet Project Target

Finish

Performance 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.

1.3.2 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.

1.3.3 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.

1.3.4 Data Post-processing and Root-Cause Analysis

Data Post-Processing

To optimize the pre-launch network, various input data is needed:

Performance statistics

Performance recording

Fault logs from RNC and Node B

Parameter data

Performance statistics

Performance statistics is generated from the live, and is made up of a

number of predefined counters. Combining these counters into formulas,

we can get statistical reports which are useful for performance monitoring

and optimization. During the basic tuning for a pre-launch network, since

there are limited test users in the network, the performance statistics are

not so accurate like the performance statistics in live network.

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.

1.3.5 Root Cause Analysis and Recommendation

1.3.5.1 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 1

The simplest solution is to convert the interferer to a useful radio

link by including the overshooting cell into the neighboring cell list.

Recommendation 2

The second solution to solve this problem is to decrease the pilot

power - Primary CPICH power of the overshooting cell.

With the pilot power decreasing, the total downlink power for the

common channels of the interferer decreases. At the mean time,

the power of all other common channel decreases because their

parameter settings are related to the pilot power value.

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

Recommendation



To add a new site with “good coverage control” in the problematic

area is a common practice.

1.3.5.2 Pilot Pollution

Phenomena

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.

1.3.5.3 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


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.

1.3.5.4 Insufficient received UL DPCH power

Phenomena


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


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.

1.3.5.5 High UE TX Transmit Power

Phenomena


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.

1.3.5.6 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


A

CB


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.

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).



Recommendation

The direct solution to remove this problem is to ensure no crossed

feeders and correct scrambling codes for the all cells in the site.

1.3.5.7 Low data throughput

Phenomena


when downloading files to/from the operator’s server (or the known

public server) by FTP and pinging that server simultaneously.

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.

Recommendation

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.

1.3.5.8 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.

Phenomena


through drive test tools and UE tracing function.



The UTRAN fails to receive “measurement reports” from UE

or

The UE does not generate “measurement reports” when it

enters the desired cell coverage area or

The UE does not generate “measurement reports” when it

leaves the 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)

Reason 2 - Missing Neighboring Relationship

Missing neighboring cell relationship is another possible reason.

Neighboring cell relationship can be checked by monitoring the

neighboring cell window during the drive test.

Recommendation

To add the desired cell to the neighboring cell lists of the cells in the

active set is a common practice. However, too many neighboring

cell relationship may make the process for searching pilot channel

slow.

Reason 3 – pilot pollution in dedicated mode

The third possible reason is pilot pollution in dedicated mode.

Recommendation



Refer to solutions about pilot pollution.

Reason 4 – slow searching or fast UE

Handover events may be neglected because:

Many cells in the monitored set slow down the search for pilot

channel

The UE is in fast moving.

Recommendation

The usefulness of the handover relationships should be reviewed

and the unnecessary relationships should be removed

1.3.5.9 No Suitable Cell

Phenomena

During the drive test, the UE in the idle mode can not camp on any

cell and the display of the UE shows “no coverage”.

Reason 1 – High Downlink Interference

High downlink interference is the possible reason causing no

suitable cell. Please refer to “High Downlink Interference”

Reason 2 - high restriction on cell (re)-selection parameters

The second possible reason causing no suitable cell is high

restriction on cell (re)-selection parameters, even though the actual



quality and signal strength of the pilot are good enough to provide

coverage.

The parameters for the cell (re)-selection are:

QqualMin: Minimum quality for selection/reselection

QrxlevMin: Minimum level for Selection/Reselection

UE Max Transmission Power

Recommendation

The cell (re)-selection parameters (i.e. QqualMin, QrxlevMin, UE

Max Transmission Power) should be reviewed and adjusted to

suitable values.

1.3.6 Assessing Success of Recommended Change

Drive test and performance statistics are often used to assess success of

the recommended changes. Drive test conducted in the same problematic

area can verify whether these changes improve the performance in the

problematic area. Performance statistic in the following few days can be

used to check whether there is any side effect to other areas or other

cells.

2 OMC Statistics Based Tuning

2.1 KPIs

Differentiated Performance Monitoring

The QoS of differentiated packet switched (PS) and circuit switched (CS)

services can be assessed through counters collected and classified in the

RNS. The analytical approach assumes that the network topology where



the service performances are analysed is already defined (or selected

within a wider scope) together with the measurement period (history), and

user satisfaction criteria.

The identified area may encompass radio network controllers (RNC), base

stations (BSs) or Node Bs, cells and the interface between the base

station and the radio network controller (Iub). Our target is to define

essential counters and key performance indicators (KPIs) that need to be

retrieved, and/or derived from measurements in NEs, for a capacity and

QoS status view in the RNS and/or a detailed performance analysis. In the

latter case, for example, performance results may be compared directly to

the target values or, since only the QoS perceived by end-user matter,

expressed in terms of satisfied users. The network administrator may then

compare the number of satisfied users to the related target thresholds

defined a priority.

Classification of Counters

CS Conversational

Call type: Speech or Transparent (T) data Guaranteed bit rate Transport channel type: e.g. DCH

CS Streaming

Non Transparent (NT) data Guaranteed bit rate Transport channel type: e.g. DCH

PS Conversational

Guaranteed bit rate Allocation Retention Priority (ARP) Transport channel type: e.g. DCH

PS Streaming



Guaranteed bit rate Allocation Retention Priority (ARP) Transport channel type: e.g. HS-DSCH, DCH

PS Interactive

Maximum bit rate Traffic Handling Priority (THP) Allocation Retention Priority (ARP) Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH

PS Background

Maximum bit rate Allocation Retention Priority (ARP) Transport channel type: e.g. HS-DSCH, DCH, FACH, RACH

Cell, RNC, URA, RA and LA identifiers

QoS Monitoring

Uplink Eb/N0, BLER and BER

In the UMTS system the QoS is typically defined in terms of the BLER that

the system must provide for the specific application. The required BLER is

maintained through the combined operation of several different

mechanisms. Among these, power control is unique in terms of its short

latency and ability to compensate for large changes in propagation and

interference conditions.

BLER: This is long-time average block error rate calculated from

transport blocks.

A transport block is considered to be erroneous if a CRC error is

indicated by appropriate information element of Framing Protocol for

uplink data. Unfortunately there is not good downlink BLER report

specified yet that could be sent by user equipment. Only RRC

measurement report with event-ID e5a indicates that downlink BLER

exceeded a defined threshold.



BER: Bit error rate (BER) can either be measured as Transport

Channel BER or Physical Channel BER. Reports are sent by Node B

to RNC for uplink data. The uplink BER is encoded in Framing Protocol

Quality Estimate value.

SIR Error: This shows the gap between the assigned SIR target and

measured SIR. Analysis of SIR error per connection shows how good

the SRNC is able to adjust uplink transmission power of UE, which

means accuracy of Open Loop Power Control.

Downlink BLER Computation

The downlink transport channel block error rate (BLER) is based on

evaluating the CRC of each transport block associated with the

measured transport channel after RL combination. The BLER is

computed over the measurement period as the ratio between the

numbers of received transport blocks resulting in a CRC error and the

number of received transport blocks. The mobile when explicitly

ordered by the network may report such a measurement periodically

on event based

Throughput Computation

The throughput relates only to the correctly received bits during a

predefined measurement period (observation time), denoted by S in

the following, where RLC buffers are not empty.

RLC Retransmission Rate

This indicator relates to number of retransmissions required to transmit

an RLC PDU when the first transmission was not successful through

the radio interface. The metric can be used to set the maximum

number of allowed link layer retransmissions without compromising the

load of the cell for the global quality of service requirements



Service Data Unit Error Ratio

The SDU error ratio is defined as the fraction of SDUs lost or detected

as erroneous

Downlink Transfer Delay Computation

The transfer delay is defined as maximum delay for 95th percentile of

the distribution of delay for all delivered SDUs during the lifetime of a

bearer service, where delay for an SDU is defined as the time from a

request to transfer an SDU at one SAP to its delivery at the other SAP.

In practice, in these terms, the statistical measurement of the transfer

delay would require to measure the delay of all delivered SDUs during

the lifetime of one bearer service and save the corresponding values

separately so that the distribution of delay could be derived. The

transfer delay would then be the delay that is greater than or equal to

the delays of 95% of the delivered SDUs during the lifetime of the

bearer service. Hence, the transfer delay measurement may become

an issue when a statistical analysis is required.

Downlink Jitter Computation

The jitter of a specific bearer service is defined as the difference

between the one-way delays of the selected packet pair, e.g.

consecutive packets.

QoS Accessibility and Retainability Monitoring

Accessibility and retainability measurements are based on the

success/failure of procedures needed to setup, modify or maintaining a

certain bearer service or signalling connection. Hence, the proposed

measurements are attached either to the successful or the

unsuccessful issue of a procedure for RAB or signalling connection

management.



RAB Management

Five measurement types may be defined for CS and PS domains

• Number of RAB assignment attempts: On receipt by the RNC of a

RANAP RAB ASSIGNMENT REQUEST message for CN, each RAB

assignment request is added to RAB.AttEstab.m counter.

• Number of successfully established RABs: On transmission by the

RNC of a RANAP RAB ASSIGNMENT RESPONSE message to the CN,

each successfully established RAB is added to RAB.SuccEstab.m

counter.

• Number of RAB establishment failures: On transmission by the RNC

of a RANAP RAB ASSIGNMENT RESPONSE message to the CN, each

RAB failed to establish is added to RAB.FailEstab.Cause.m counter

according to the failure cause.

• RAB connection set-up time (mean): This measurement is obtained by

accumulating the time intervals RAB.SuccEstabSetupTimeMean.m for

each successful RAB establishment, which is then divided by the number

of successfully established RABs observed in the granularity period to

give the arithmetic mean.

• RAB connection set-up time (maximum): This measurement may be

obtained by the high tide mark RAB.SuccEstabSetupTimeMax.m of the

monitored time intervals for each successful RAB establishment.

• Number of RAB releases: On transmission by the RNC of a RANAP

RAB RELEASE REQUEST message, each RAB requested to be released

is added to the relevant per cause measurement RAB.Rel.Cause.m.

KPI may be derived from above:



Bearer Accessibility

Bearer Reliability

Both Bearer Accessibility and Reliability product of the two KPIs above

result in RAB Success Ratio

Signalling Connection Management

• Attempted signalling connection establishments: This measurement

provides the number of attempts SIG.AttConnEstab.m by RNC to

establish an Iu control plane connection with the CN. In this case, m may

simply denote the PS or CS domain. The trigger point is the transmission

of a RANAP Initial UE message by the RNC to the CN, which is sent by

the RNC on receipt of an RRC Initial Direct Transfer message from the

UE.

• Attempted RRC connection establishments: This measurement provides

the number of RRC connection establishment attempts for each



establishment cause. On receipt of an RRC Connection Request message

by the RNC from the UE, each received RRC Connection Request

message is added to the relevant per cause measurement

RRC.AttConnEstab.Cause.

• Failed RRC connection establishments: This measurement provides the

number of RRC establishment failures for each rejection cause. On

transmission of an RRC Connection Reject message by the RNC to the

UE, or an expected RRC CONNECTION SETUP COMPLETE message

not received by the RNC, each RRC Connection Reject message received

is added to the relevant per cause measurement

RRC.FailConnEstab.Cause.

• Successful RRC connection establishments: This measurement provides

the number of successful RRC establishments for each establishment

cause. On receipt by the RNC of a RRC CONNECTION SETUP

COMPLETE message following a RRC establishment attempt, each RRC

Connection Setup Complete message received is added to the relevant

per cause measurement RRC. SuccConnEstab. Cause.

• RRC connection set-up time (mean): This measurement is obtained by

accumulating the time intervals for every successful RRC connection

establishment per establishment cause between the receipt by the RNC

from the UE of a RRC CONNECTION REQUEST and the corresponding

RRC CONNECTION SETUP COMPLETE message over a granularity

period. The end value of this time, denoted as

RRC.AttConnEstabTimeMean.Cause, is then divided by the number of

successful RRC

connections observed in the granularity period to give the arithmetic

mean. The measurement is split into sub counters per establishment

cause.



• RRC connection set-up time (max): This measurement is obtained by

monitoring the time intervals for each successful RRC connection

establishment per establishment cause between the receipt by the RNC

from the UE of a RRC CONNECTION REQUEST and the corresponding

RRC CONNECTION SETUP COMPLETE message. The high tide mark of

this time, RRC.AttConnEstabTimeMax.Cause, is the collected value.

• Attempted RRC connection releases: This measurement provides the

number of RRC connection release attempts per release cause sent from

UTRAN to the UE. On transmission of an RRC CONNECTION RELEASE

message by the RNC to the UE, each RRC Connection Release message

sent is added to the relevant per cause measurement

RRC.AttConnRel.Cause.

2.1.1 IRAT - Inter Radio Access Technology (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 with PDP context activation; Multi-RAB

handover (CS + PS test)

Event 3A measurement activation / deactivation

2.1.2 CS Performance additional information

Customer demand Indicator Measure

Service accessability Availability & CoverageBlocked callsCall setup delay

Ec/No, RSCPAdmission controlRAB assignment

Service integrity Voice quality Noisy frames (FER), MOS

Service retainability Dropped calls Handover failureNo coverageInterference



2.1.3 PS Performance additional information

Customer demand Indicators Measures

Service accessability Availability & CoverageBlocked service accessService access delay

Ec/No, RSCPAdmission controlAttach, PDP context activation, IP service setup

Service integrity Video qualityAudio qualityWeb page download timeE-mail sending time, etc.

BLER, FER, throughput, delay, jitter

Service retainability Dropped data connectionConnection timeouts

Dropped PDP context/attachNo coverageHandover failure

2.2 Tools

This section gives an overview of the standard Tool setup in collecting,

monitoring and analyzing UMTS performance counters and Key

Performance Indicators. It discusses briefly the requirements and will

mention some known tools in the market today.

2.2.1 Tools Requirements

OMC/OSS Configuration



OSS/OMC Setup

OSS / OMC Server - is an integrated service and management system

for GSM, GPRS, EDGE and 3G networks. It has 3 main features –

Configuration Management, Performance Management and Fault

Management.

Performance Management Server – is 3rd party Application Server

capable of generating Performance Reports. Client/s can be setup to

access this application through CITRIX.


Core Network

UE

Node B Node B

RNC

RNC

Router

PM Server

OSS

Citrix Server

PM Client

OSS PM Client

Iub

MubMub

Mun

Mur

Iur

Iu


OSS Performance Management Application – is a third party

application supported by the OSS. It can query the Performance

database from the OSS, create and generate Performance Reports and

customized KPI and formulas. Users or clients can connect and access

this application through CITRIX.

Some common features:

User defined KPI’s

User defined reports

Real time reporting

Trending and Historical reports

Library of pre-configured calculations and KPI’s

Export to excel or any database format

Alarm monitoring

2.2.2 Tools Currently Available to Capture / Process Data

NetworkAssure by Vallent (formerly Watchmark Prospect)

NetworkAssure is a high performance management (PM) solution that pulls

together OSS data to manage the most complex multi-vendor, multi-

technology networks. It provides a seamless aggregation and correlation of

data from multi-vendor, multi technology networks and pre-built network

interfaces for technologies, including UMTS, GSM, GPRS, IP, CDMA,

ATM/FR, transmission, switched voice and others.

Metrica / NPR data management systems (DMR)

Metrica/NPR gets you up and running quickly, with preconfigured solutions for

major network technologies. These Technology Layers include GSM, GPRS,

UMTS, IP and Voice Switching. With Metrica/NPR you get all the benefits of a



configurable, modular solution that you can easily extend and modify. It

interprets and manages large volumes of data at high performance, provides

comprehensive and easy to view performance information for business and

operational users, identifies problem areas and discovers underlying trends

before service-affecting problems occur and provides historical reporting and

forecasts performance trends and helps to predict effects of network change.

OPTIMA by Aircom

Provides historical reporting and forecasts performance trends and helps to

predict effects of network change.

Some typical uses of Optima for network operation and performance

management are:

Daily reporting of cell, site, BSC, MSC and transmission network

performance.

Daily reporting of any cluster of cell sites or network elements covering

particular cities, roads or other geographical regions.

Identification of performance anomalies across network regions.

Overall monitoring of alarms and equipment operational status.

Identification and strategic reporting of traffic hotspots and network

locations generating high traffic and revenues.

Nokia Netact

Integrated network and service management system for

GSM/GPRS/EDGE/3G networks

Modular, scalable and open solution for operating mobile networks

Supports operator processes

Provides smooth management evolution towards a more service

oriented world

Multi vendor



Ericsson OSS

Ericsson’s OSS-RC provides fault, performance and configuration

management of Radio and Core networks.

Configuration Methods

Export configuration data then import configuration changes

through the OSS.

Enter configuration changes via the OSS Graphical User Interface

(GUI).

Make configuration changes in the UTRAN via a ChangeAll script.

Use EMAS (Element Manager Software).

Call Trace Capability

Ericsson OSS supports three different types of call trace namely UETR, CTR

and GPEH.

UETR – User Equipment Traffic Recording

CTR – Cell Traffic Recording

GPEH – General Performance and Event Handling

2.3 Post-Launch Optimization Process

Testing and monitoring QoS in the UMTS network requires several kinds of

analysis actions and network monitoring through the whole life cycle of the UMTS

network, starting from the network element development and ending with the

operation of the network. The protocol layers carrying signaling and user plane

data have to be accessed and verified to ensure proper network performance.

Protocol analysis and tracing of protocol messages are required for

troubleshooting purposes and for finding the origins of any problems. For long

term monitoring, the signaling and user plane traffic on the protocol layers must

be recorded and analyzed with post-processing tools as well as with applications



capable of visualizing real-time metrics and following certain Key Performance

Indicators. Real time analysis is usually done using several of the OSS tools

which help in recording and scheduling real time reports. These reports contain

several KPIs which help in understanding any key problems in the network and

also enable us to implement quick changes in the network in a very time efficient

manner. Most reports provide key statistical reports such as traffic and RF

measurements which enable to rectify problems and help in troubleshooting

process without the need of any extra resources.

2.3.1 Data Post-processing and Root-Cause Analysis

Statistical measurements play an important and more traditional role in the

operative networks when QoS is controlled. Moreover, statistical

measurements can be utilized right after rollouts to validate the UMTS

network’s ability to provide satisfactory QoS level.


RNC

OSS Applications Recording Definition

Reports

Node BRecording Data

OMC


For performing QoS measurements, a monitoring tool is needed. It

explores characteristics of a UMTS network in the field or in the laboratory

by analyzing and monitoring both signaling and user plane traffic captured

with probes from the network interfaces. The QoS monitoring system

consists of network probes and sophisticated software for analyzing the

captured traffic.

QoS monitoring software consists of two main software components: the

GUI (graphical user interface) for operating the QoS monitoring system

and showing the results of the QoS measurements, and the QoS server

software for processing the gathered information. The QoS server

software performs all the analysis of the information captured from the

UMTS interfaces.

Current setup in the network has a built-in QoS Monitoring in the

OSS/OMC or as a third party application supported by the OSS/OMC

vendor. Raw data from the counter measurement tables are fetched and

converted in database or text format by a Mediation application. These

data are then available for the OSS Performance application and third

party Performance Monitoring application.



QoS Monitor StructureThe basic features of the QoS Monitoring system are for statistics

measurements, capacity measurements and call tracing.

Root Cause Analysis.

As the amount of UMTS subscribers quickly increases, operators and

equipment vendors are facing big challenges in maintaining and

troubleshooting their networks.

We may raise the question of how one can efficiently narrow

down the root causes of the problems when there is a huge

amount of subscribers and traffic in a live UMTS network.

What are the principles of examination of the fault scenarios and

narrowing down the problem investigation into logical

manageable pieces?


QoSGUI

Statistics Measurement

Statistics Measurement Call Trace

Call TraceCapacity

Measurement

Capacity Measurement

QoS DB

QoS Monitor Software

Probe Probe Probe


Before investigating and solving KPI triggered faults, make sure the

following has been performed:

1. The general alarm status of the network has been checked. No

clear network alarms pointing to the root cause of the fault can be

detected.

2. Traces from external interfaces of RNC have been taken with a

protocol analyser in order to record the fault scenario. Also RNC

internal trace has been taken when the fault took place.


Paging Paging

RRC Connection

Establishment

RRC Connection

Establishment RAB Establishment

RAB Establishment User-Plane

Data Flow

User-Plane Data Flow

MT Call MO Call

Overview of UMTS Call Setup


Troubleshooting Process Flowchart:

Network troubleshooting means to detect problems, and then find and

eliminate the root causes of these problems. The fewer problems one

finds, the higher quality of services can be guaranteed.


New SW, HW, parameters, UE model or feature

introduced?


The KPIs are useful because they give a first overview of network quality

and behavior and they may also be helpful to identify possible problems in

defined areas of the network. However, simple counters and simple ratio

formulas are often not enough. For instance, if the already defined GRPS

Attach Failure Ratio is calculated per SGSN, it can be used to indicate

whether there is an extremely high rate of rejected GPRS Attach Requests

in a defined SGSN area. However, such a high Attach Failure Ratio does

not need to indicate a network problem by itself. Always a further analysis

is necessary to find the root cause of network behavior. Based on the root

cause analysis it can be determined whether there are problems or not.

This procedure is also called drill-down analysis.

In case of rejected GPRS attach, the first step of analysis will always be to

check the reject cause value of the Attach Reject message. A value that is

often seen here is the cause “network failure.” From 3GPP 24.008

(Mobility Management, Call Control, Session Management) it is known

that the cause value “network failure” is used “if the MSC or SGSN cannot

service an MS generated request because of PLMN failures, e.g.

problems in MAP.” A problem in MAP may be caused by transmission

problems on Gr interface between SGSN and HLR. The address of a

subscriber’s HLR is derived from IMSI and the best way to analyze the

procedure is to follow up the MAP signaling on Gr interface after GRPS

Attach Request arrives at SGSN. On Gr it can be seen whether there is a

response from HLR or not and how long does it take until the response is

received.

Common reasons why GPRS attach attempts are rejected with cause

“network failure” are

expiry of timers while waiting for answer from HLR, because of

too much delay on signaling route between SGSN and HLR



abortion of MAP transactions because of problems with

different software versions (application contexts) in SGSN and

HLR

invalid IMSI (e.g., if a service provider does not exist anymore,

but its USIM cards are still out in the field)

routing of MAP messages from foreign SGSN to home HLR of

subscriber impossible, because there is no roaming contract

between foreign and home network operators

The first two reasons indicate network problems that shall be solved to

improve the general quality of network service. The latter two reasons

show a correct behavior of the network that prevents misusage of network

resources by unauthorized subscribers.

This example shows how difficult it is to distinguish between “good cases”

(no problem) and “bad cases” (problem) in case of a single reject cause

value. In general, four main features can be identified as main

requirements of good KPI analysis:

Intelligent multi-interface call filtering

Provision of useful event counters

Flexible presentation of measurement results from different

points of view(sometimes called dimensions), e.g., show first

Attach Rejects messages by cause values and then show IMSI

of rejected subscribers related to one single cause value (to find

out if they are roaming subscribers or not)

Latency measurement to calculate time differences, e.g.,

between request and response messages



Failure Cause-Type Per Measurement.

RAB Assignment Failures

RAB Release Cause Type

Protocol Cause type Description

RANAP Radio layer network cause Relocation Triggered

RANAP Radio layer network cause Unable to Establish During Relocation

RANAP Radio layer network cause Requested Ciphering and/or Integrity Protection algorithms not Supported

RANAP Radio layer network cause Failure in the Radio Interface Procedure

RANAP Radio layer network cause Requested Traffic Class not available

RANAP Radio layer network cause Invalid RAB Parameters Value

RANAP Radio layer network cause Invalid RAB Parameters Combination

RANAP Radio layer network cause Condition Violation for SDU Parameters

RANAP Radio layer network cause Invalid RAB ID

RANAP Radio layer network cause Interaction with other procedure

RANAP Radio layer network cause Request superseded

RANAP Transport layer cause Iu Transport Connection Failed to Establish

RANAP Protocol cause Transfer Syntax Error

RANAP Protocol cause Semantic Error

RANAP Protocol cause Message not compatible with receiver state

RANAP Protocol cause Abstract Syntax Error (Reject)

RANAP Protocol cause Abstract Syntax Error (Ignore and Notify)

RANAP Protocol cause Abstract Syntax Error (Falsely Constructed Message)

RANAP Miscellaneous cause No Resource Available

RANAP Miscellaneous cause Unspecified Failure

Internal Other causes

RANAP Radio layer network cause Requested guaranteed bit rate not available

Radio Link Setup Failures

RAB Release Cause Type


NBAP Radio layer network cause Unknown C-ID

NBAP Radio layer network cause Cell not available

NBAP Radio layer network cause Power level not supported

NBAP Radio layer network cause DL radio resources not available

NBAP Radio layer network cause UL radio resources not available

NBAP Radio layer network cause RL Already Activated/allocated

NBAP Radio layer network cause Node B Resources unavailable

NBAP Radio layer network cause Requested configuration not supported

NBAP Radio layer network cause Unspecified

NBAP Radio layer network cause Invalid CM setting

NBAP Radio layer network cause Number of DL codes not supported

NBAP Radio layer network cause Number of UL codes not supported

NBAP Radio layer network cause UL SF not supported

NBAP Radio layer network cause DL SF not supported

NBAP Radio layer network cause Dedicated Transport Channel Type not sup-

NBAP Radio layer network cause CM not supported

NBAP Transport layer network cause Transport resource unavailable

NBAP Transport layer network cause Unspecified

NBAP Protocol cause Protocol error

NBAP Miscellaneous cause Control processing overload



NBAP Miscellaneous cause OAM intervention

NBAP Miscellaneous cause Hardware failure

NBAP Miscellaneous cause Not enough user plane processing resources

NBAP Miscellaneous cause unspecified

Internal Cause type not applicable No Reply

Outgoing Hard Handover

Hard Handover Failure Causes


RRC Failure cause (RRC) Configuration unsupported

RRC Failure cause (RRC) Physical channel failure

RRC Failure cause (RRC) Incompatible simultaneous reconfigurations

RRC Failure cause (RRC) Protocol error

RRC Failure cause (RRC) Compressed mode runtime error

RRC Failure cause (RRC) Cell update occurred

RRC Failure cause (RRC) Invalid configuration

RRC Failure cause (RRC) Configuration incomplete

Internal Cause type not applicable No Reply

Hard Handover Failure per Adjacent Cell Pair Causes


RRC Failure cause (RRC) Configuration unsupported

RRC Failure cause (RRC) Physical channel failure

RRC Failure cause (RRC) Incompatible simultaneous reconfigurations

RRC Failure cause (RRC) Protocol error

RRC Failure cause (RRC) Compressed mode runtime error

RRC Failure cause (RRC) Cell update occurred

RRC Failure cause (RRC) Invalid configuration

RRC Failure cause (RRC) Configuration incomplete

Internal Cause type not applicable NoReply

Inter-RAT Hard Handover

Inter-RAT Hard Handover Failure Causes


RRC Inter-RAT handover failure Configuration unacceptable

RRC Inter-RAT handover failure Physical channel failure

RRC Inter-RAT handover failure Protocol error

RRC Inter-RAT handover failure Inter-RAT Protocol error

RRC Inter-RAT change failure (RRC) Configuration unacceptable

RRC Inter-RAT change failure (RRC) Physical channel failure

RRC Inter-RAT change failure (RRC) Protocol error

Hard Handover Failure per Adjacent Cell Pair Causes


RRC Inter-Rat handover failure cause Configuration



unacceptable

RRC Inter-Rat handover failure cause Physical channel failure

RRC Inter-Rat handover failure cause Protocol error

RRC Inter-RAT handover failure cause (RRC) Inter-RAT Protocol error

RRC Inter-RAT change failure (RRC) Configuration unacceptable

RRC Inter-RAT change failure (RRC) Physical channel failure

RRC Inter-RAT change failure (RRC) Protocol error

Iu Release

Iu release request causes



RANAP Radio layer network cause Release due to UTRAN Generated Reason

RANAP Radio layer network cause User inactivity

RANAP Radio layer network cause Iu UP failure

RANAP Radio layer network cause Repeated Integrity Checking Failure

RANAP Radio layer network cause Release due to UE generated signaling connection re-

RANAP Radio layer network cause Directed retry

RANAP Radio layer network cause Radio Connection With UE Lost

RANAP Miscellaneous cause OAM intervention

Iu release command causes


RANAP Radio layer network cause Relocation Cancelled

RANAP Radio layer network cause Successful Relocation

RANAP Radio layer network cause Release due to UTRAN Generated Reason

RANAP Radio layer network cause User inactivity

RANAP Radio layer network cause Iu UP failure

RANAP Radio layer network cause No Remaining RAB

RANAP Radio layer network cause Release due to UE generated signaling connection release

RANAP Radio layer network cause Directed retry

RANAP NAS Cause Normal Release

RANAP Miscellaneous cause Unspecified Failure

Internal Other causes


RANAP Radio layer network cause Repeated Integrity Checking Failure

RANAP Radio layer network cause Radio Connection With UE Lost

RANAP Miscellaneous cause OAM intervention

Admission Control

Causes for admission control rejections


Internal Non-standard cause Maximum uplink load



Internal Non-standard cause Maximum downlink load

Internal Non-standard cause Code allocation failure

Internal Non-standard cause Congestion Control is ongoing

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

The root cause for degradation of network performance can be summed

up into two different categories.

Drop calls due to abnormal RAB release

Failures due to

Intrafrequency handovers triggered by radio conditions,

mobility

Interfrequency Handovers triggered by capacity and

coverage

Intersystem Handovers (ISHO) triggered by mobility and

limited UMTS coverage

The raw counters can be classified into three types according to the

interval in which it is updated.

1) Cumulative Counter :

Measurement data is incremented every time a message is received from

the monitored object or every time an event occurs in the monitoring

object.

2) Gauge Counter:



The data of the monitoring object changes during the granularity

period, and the measurement data in that period are calculated in the

end of that period.

3) Suspect Flag:

Set to ON when regular measurement data cannot be properly

collected in the granularity period.

Some measurements are not really related to one dedicated cell, but to an

active linkset, which in case of soft handover comprises more than one

cell. There are different approaches for these measurements:

a) “All cells” approach: measurement is considered for every cell of the

active link set.

b) “Newest cell” approach: measurement is considered for the most

recently added cell of the active link set only.

The diagram below shows the counters classified according to

measurements.



There are vendor specific raw counters which can be formulated for

different KPIs and that gives a statistical insight of the network

performance.

Drop Call

The un-normal release of a connection UTRAN originated is indicated

either by the RAB RELEASE REQUEST message or the IU RELEASE

REQUEST message transmitted from the RNC to the CN. The RAB

RELEASE REQUEST message will be used when the failure occurs in the

RAB management as e.g. “firmware failure PRLC, DHT”. In any case the

UE is still reachable via a RRC connection. The IU RELEASE REQUEST

message is used in case the UE is lost at the air interface. The CN will



response either with the RANAP message RAB ASSIGNMENT

REQUEST indicating the RAB to be released if another parallel

transaction is still ongoing or with the IU RELEASE COMMAND message.

The RAB release counter UTRAN originated is incremented by the

number of RABs involved in the release even the RANAP message Iu

RELEASE REQUEST has been transmitted.

Thus, the number of abnormal RAB releases is used to determine the Call

Drop Rate. The number of abnormal RAB release along with reasons in

serving RNC for CS and PS connection is extracted using the following

counters

The counter numbers has to be converted to 3GPP numbers to find the

reason for abnormal release.



About 70% of the drops occur in the UTRAN side and the remaining

occurs in interfaces between CN and UTRAN. Major reasons for drop calls

is abnormal RAB release due to

1) Unknown C-ID

The Node B is not aware of the cell with provided C-ID. This can

happen when a foreign cell is using the network. The switch database

must be data filled with this ID to prevent future drops.

2) Radio Resources not Available

The Node B does not have sufficient radio resources available. This

needs an increase in node capacity.



3) Requested Configuration not supported

The concerning cell(s) do not support the requested configuration, i.e.

power levels, transport formats and physical channel parameters.

4) Hardware failure

This might be due to link and/or module failures. The nodes should be

checked for any alarms and cleared.

For detailed Drop Call analysis, monitor the following causes,

DL coverage DL interference

High DL BLER

High UL Tx Power

High UL Tx Power and DL BLER

Network Commanded Release_DL Coverage

Network Commanded Release_High UL Tx Power

Network Commanded Release_Not Classified

No Data

Not Classified

Handover Failures

There are three types of handover performed by UMTS network,

1. Intrafrequency triggered by radio conditions, mobility

2. Interfrequency Handovers triggered by capacity and coverage

3. Intersystem Handovers (ISHO) triggered by mobility and limited

UMTS coverage

The common failure reasons are,



Configuration Unsupported

If UTRAN instructs the UE to use a configuration that it does not

support, the UE shall set the IE failure cause to configuration

unsupported. This usually happens when UE goes from UMTS

coverage area to GSM area.

Physical channel establishment failure

When a physical dedicated channel establishment is initiated by the

UE, the UE shall start a timer T312 and wait for layer 1 to indicate

N312 successive "in sync" indications. On receiving N312 successive

"in sync" indications, the physical channel is considered established

and the timer T312 is stopped and reset.

If the timer T312 expires before the physical channel is established,

the UE shall consider this as a "physical channel establishment

failure". This can be due to many reasons like node busy, UE in

coverage fringe, low timer value. If the failure is high, T312 wait timer

can be increased to give UE more time to sync.



The counters used for intra RNC and inter RNC handovers are:

Other Optimization Strategies

1. Load Estimation based on Throughput

This approach is simple and fast. However, it ignores other cell

interference issues that may result in reduced throughput, thereby

giving false impression of the spare system capacity

2. Load Estimation based on Wideband Received Power

This approach provides a better view of the used resources (cell of

interest plus interferers) to provide an indication of the loading

conditions. The problem with this approach lies in the accuracy of



the reported measurements and the fact that they have to be

averaged over a period of time for increased reliability.

3. Network Audit Strategy

Characterization of Radio Properties

Complete neighbor relations overview

Complete feeder check

Complete parameter value and consistency check

Counter statistics collection: starting point of performance

Setting up routine for monitoring all other activities in the

network (SW upgrades, re-parenting etc)

Network Audit Strategy

Radio Network Aspects

Cell Planning Coverage

Cell Planning , InterferenceNeighbor Definitions

Location Area / Routing Area Planning

Careful geographical placement of LA/RA borders to

minimize the number of LA/RA updates and Iur handovers

In low traffic areas

Perpendicular to main traffic flow

Number of Cells in LA/RA

Load from LA/RA updates

Paging Load

Basic Rule

1 to 3 RNC per LA and RA

Same RA as LA



No sharing of LA/RA i.e separate LA/RA for GSM /

GPRS and for WCDMA even if they cover the same

geographical area and the same sites in case of co-

siting.

UL / DL Power Balancing

Output Power of common control channels

Code Planning

Parameter Tuning

O & M Aspects

Parameter consistency

Software status

Detecting Crossed Feeders

Measurement Principles

Some Optimization examples done on live UMTS network:

1 Optimization of ISHO Thresholds

There is a main parameter in the ISHO procedure that determines whether to

leave the 3G network for the 2G network (connected mode) on RSCP or

EcNo. Even if these parameters are link (through the RSSI), there are rather

independent and it is difficult to guaranty a certain level of RSCP by a

level of EcNo and vice versa.

On IDF, we noticed that at RSCP levels of -100dBm the quality of the radio

links was rather poor and therefore it was difficult to correctly keep the

connection alive till the ISHO operation successes.



There are 3 events involved in the ISHO procedures namely e2d, e2f and

e3a.

ed2 à compressed mode activation à UE starts measuring 2G cells based

on the 3G2G neighbors list

e2f à compressed mode deactivation à UE stops the measurements

e3a à handover from UTRAN command (ISHO) à UE sends the elected

2G cell to perform the HHO

The initial thresholds for these 3 events are respectively -100dBm, -97dBm

and -103dBm.

It is important to notice that during the compressed mode the UE is really

busy with the monitoring and the power control. Most of the time, it is during

this phase that we experience the worst quality of the voice. Hence the

settings will tend to reduce this time of CM.

The propose settings are:

The UE goes into CM 2dB early thus it guaranty a better quality of the RL.

The main modification is that e3a is higher than e2d which mean that

the UE is allowed to go on GSM has soon as the best suitable 2G cell is

found.

Remark: The procedure works correctly only and only if the 3G2G neighbor

plan is optimized


e2f @ -97dBm

e3a @ -

103dBm

C

Me2f @ -96dBm

e3a @ -97dBm

e2d @ -98dBm

AFTER BEFORE


2 Optimization of Qrxlevmin for 3G Network Eligibility

Ping-pong type 1 – Green Area :

FDD_Qmin vs QRxLevmin_3G

The S criteria is there to prevent the UE selecting a cell with RSCP below

QRxLevmin and EcNo below QQUAL_min but the radio conditions change

quickly (especially at low levels). Hence it happens that the UE reselects the

3G layer and goes rapidly out of 3G coverage after the network reselection.

Also, when the RSCP is low the measurements of EcNo reported by the UE

are less accurate and this ping-pong effect is therefore emphasized.

Ping-pong type 2 – Purple Area :

FDD_Qmin vs QQUALmin + SSearch-RAT

If the hysteresis between the 2 thresholds FDD_Qoffset and QQUALmin +

SSearch-RAT is not big enough then it will happen that the UE decides to

reselect the 2G layer right after a 3G reselection (and vice versa). This


QRxLevmin_3G is lowered from

-111dBm to -115dBm

FDD_Qmin

Qqualmin + Ssearch-RAT


behavior is due to the fluctuating radio conditions. The actual margin of 4dB is

considered wide enough to regulate this effect.

Parameter modification: QrxlevminIt was noticed on the measurements made in connected mode that there are

situations where the UE goes back and forth between the 2G and 3G

networks. The 3G-2G reselection is necessary to control when the UE is

allowed to go (or should go) on the 3G network but the ping-pong is a side

effect of this procedure: the UE is in an undetermined state.

Hence, it is important to reduce this effect because:

- It reduces the availability of the UE (especially for video calls)

- It decreases the life time of the battery of the UE

- It loads the RNC with signalling for network selection management in

IDLE mode.

The proposition is to modify the Qrxlevmin 3G from -111dBm to the minimal

value of -115dBm

Remark: T0 is the 17th of February 2005. The period of observation is from

the 31st of January 2005 to the 6th of March 2005

Interpretations:

The inter-RAT cell reselection is a good criterion to know the rate of network

switching between 3G and 2G.

A low inter-RAT cell reselection rate means that you stay whether on the 3G

or the 2G network.

In our case we stay longer on the 3G network because the minimum level of

3G cell eligibility is lowered giving easier access to 3G cells



Conclusions:

Processing amount on the RNC is decreased. Even if this issue is not

critical now, it will become an issue with the traffic growth.

Basically, the RNC processes more “Service requests” than “Signalling

requests” in proportion.

The ping-pong effect is reduced since the UE stays longer on the 3G

network.

Therefore the UE is more available on the 3G network.

Remark:

The quality criterion for a 3G network is the EcNo more than the RSCP. With

a Qrxlevmin 3G at the minimum level of -115dm, almost all cells are eligible

for 3G registration even when the UE’s are indoor. It is then the minimum

EcNo requirement (FFD_Qmin) that will determine if a cell can be selected for

reselection. Also, as the lost of 3G coverage is detected à -115dBm or -18dB

(Qqualmin) it becomes even more important to tune properly the other cells

reselection parameters.

3 Optimization of ROFFSET for Enhanced SHO Management

The event e1a’ is intended to release a call when the interferences brought by

the communication become too high. The “Improved HO handling” feature

helps in maintaining enough radio links after a SHO failure in order to allow

further SHO attempts. If we don’t set a limit to this system then the UE will

bring interferences from the serving cells to the neighbour cells. The RRC Re-

Establishment procedure will be initiated if e1a’ fails (which is equivalent to a

call drop for CS with the Qualcomm chipsets that do not support this call re-

establishment).



When e1a’ is received the RNC performs a last try: if the procedure fails

then all the RL are released.

If there is a procedure e1a in progress when the e1a’ is received then all

the RL are released also if the procedure fails

e1a’ is triggered every “reporting interval” à several attempts are allowed

since the radio links are not released after SHO failure

If the UE goes too deep inside the service area of cell 2 (with cell 2 as

neighbour and cell 1 as serving cell) then if the SHO attempt fails the

procedure asks to release the RL to avoid interferences on cell 2

The settings of event e1a’ are sent in the second measurement control

message right after the definition of SHO events e1a, e1b and e1c. To

distinguish the 2 measurement report types the measurement identity is


SHOarea


set to 9 for e1a and to 14 for e1a’. The event e1a’ inherits the settings of

event e1a except for the triggering threshold defined as follow:

Re1a’ = Re1a – Roffset, with Re1a’ ≥ 0

Description of the problem

The parameter Roffset was initially set to 0dB such that e1a and e1a’ have

the same triggering threshold.

With this original setting events e1a and e1a’ are sent at the same time

resulting in a release of the radio links in case of SHO addition failure.

Indeed, as the e1a’ is sent to release the call in case of SHO failure.

Therefore, all e1a are pre-empted by e1a’ events.

à This behaviour is suspected to create additional drops.

Implemented modification

The value of Roffset will be set to 3dB thus setting. Indeed, With the new

setting, the event e1a’ is delayed by 3dB compared to e1a which is

equivalent to extra time allowed to perform the HO. Eventually, when the

best SC of the neighbour set reaches the level of the best cell of the active

set within the range of 1dB (Re1a’) then the call is released (for CS only –

for PS there are different procedures).

Expected gains and behaviors

à Reduction of the number of e1a’ and at the same time an increase of

the number of e1a

As the e1a’ is delayed we allow more attempts of e1a and therefore this

number should increase. But we should also decrease the number of e1a’

since there will be fewer situations triggering this event. We will verify that

this delta between these two events does not increase so much that it may

overload the RNC in term of signalling.

à Lower CDR



As the system is more resistant to SHO failures there should be

improvements on the call drop rates.

2.3.3 Assessing Success of Recommended Change

The effect of the recommended changes should be analyzed for its

success. This can be verified through,

Drive Test – real time throughput performance

Statistics - KPI improvements against Baseline

QoS Performance – from Statistics or Protocol Analyzer


umts optimization guideline

Documents