UMTS RF optimisation methodology used in 3GIS TVP

TOP 10

3G RAN Optimisation Actions

Version 0.4

TOP 10 3G Optimisation Actions

WCDMA optimisation, dominance, interference, throughput

NET/OSS/OS Performance, 3G Radio Program

Table of contents

41.Introduction

2.Network planning rules for optimum performance43.Network health check53.1BTS Alarms causing Blocked cells53.1.1Fault in O&M and DSP SW interface53.1.2ATM overflow53.1.3DSC-bus failure63.1.4Unit SW download failed63.1.5WSP R-Bus Error63.1.6No Connection to Unit63.2Software and Parameter checks63.3Neighbour Consistency checks63.4Cell load checks73.5RAN Counter and KPI checks73.5.1Cell Availability73.5.2RRC setup and access complete ratio73.5.3RAB setup and access complete ratio73.5.4RAB drop ratio83.6UE Performance check84.Performance check with Field Measurements85.Top 10 optimisation activities to improve call performance95.1Common Call Performance Issues95.2Voice (AMR) specific performance Issues115.3Video Call Performance Issues125.4PS Call Performance Issues125.5ISHO performance156.Optimisation Tools156.1Nokia Application Launcher (AL)156.1.1RNW Object Browser156.1.2RNW Online Management166.2Nokia Plan Editor166.3EOS Reporting Solution (RS)176.4NetAct Reporter176.5Field Measurement Tools (FMT)176.5.1RF scanner186.5.2NEMO TOM Drive Test tool186.6Actix Analysis tool197.References208.Glossary21

1. Introduction

The aim of this document is to summarize how to

Investigate the reasons for poor 3G radio performance (call set-up failure, call drop),

Describe the potential reasons

Propose actions to improve performance (as top 10 optimisation actions)

Both common and service specific (CS AMR, CS Video and PS)

This document can be used as network pre-launch optimisation checklist.

2. Network planning rules for optimum performance

Experience has shown that the optimum performance will be achieved with the following network planning rules: -

Sites should be located close to the users

The cells should cover only what they are supposed to cover (avoid high sites)

Unnecessary overlapping should be avoided

By doing so the overall interference level will be minimized and network capacity will be maximized. SHO helps to reduce the interference providing SHO gain which needs to balanced against used resources (BTS power, Iub transmission).

First check could be done with Radio Planning tool by looking at the CPICH coverage, cell dominance, SHO overhead, service coverage and intercell interference areas.

The main reasons for poor radio performance are related to:

Non optimum cell design (location, antenna type/height/bearing/tilt)

Wrong site implementation (antennas, cables, parameters)

Wrong or bad parameter planning (scrambling code allocations etc, CPICH etc.)

Wrong or missing neighbour relations

There can be also other reasons than bad network planning, like:

UE-specific problems (hanging onto the cell, poor cell reselection, poor power control)

UE-NW incompatibilities

BTS, RNC or network faults

3. Network health check

The Network health check ensures that the planned network is implemented correctly, all cells are up and running and correct parameters are set. These should be done before optimisation. There are many checks to look at: -

Alarm check (BTS, RNC, other)

SW and Parameter check

Neighbour consistency check

Cell load check

KPI check

UE performance check for all the services in a controlled environment

3.1 BTS Alarms causing Blocked cells

The alarm status has to be checked first because they affect performance. There could be faults in BTSs, transmission, RNC or in other network elements. The alarm info can be retrieved from NetAct.

The alarms having the biggest impact on the performance is BTS alarm, numbered 7651 Base station operation degraded. Typically, 7651 alarms means that there would be call set-up failure, SHO failure or dropped call.

To clear the alarm, BTS cell/site restart may be needed. However new BTS SW releases (>???) have significantly improved the situation.

The alarm 7651 contains supplementary field information about the different fault reasons. Described below are the main reasons. More information about alarm info is available in RAN Customer Care Bulletins and the Alarm Manual in NED [17].

.

3.1.1 Fault in O&M and DSP SW interface

Description: SFN synchronization is lost. Illegal SFN value in downlink. The WSP does not receive frame number from the Wideband Application Manager Unit (WAM), or the frame number is faulty.

3.1.2 ATM overflow

Description: Unable to allocate AAL2 resources.

Instructions: The reason for this could be lack of transmission capacity. This can be also due to RNC because it has limit in transmission capacity related to AAL2 resources. The situation will improve in RAN1.5.2ED2 release.

3.1.3 DSC-bus failure

Description: Data, Control and Signalling Bus between WAMs and WSPs (DSC-Bus) Failure. Target Node (ASIC) detects a fault in its operation, or some ASIC has not been able to write data on the DSC-bus to the target node, or a failure in the DSC-bus, which means that messages do not get through via that DSC-bus.

3.1.4 Unit SW download failed

Description: In Case Alarming source O&M slave WAM or Wideband Signal Processor (WSP) the software downloading from SW Management subsystem to the unit/subunit has failed.

This alarm is closely related to Fault in O&M and DSP SW interface problem.

3.1.5 WSP R-Bus Error

Description: Wideband Signal Processor (WSP) R-Bus Error IRAD ASIC has detected a R-bus error.

3.1.6 No Connection to Unit

Description: Auto detection does not get a response from a unit that is mentioned in the HW Database.

3.2 Software and Parameter checks

The SW in all NEs (WBTS, RNC, AXC etc.) should be checked (to be the latest one). Also the SW in optimisation tools (NEMO, UE etc.) should be checked (to be the latest).

The parameters in the RNC database should be checked so that they are implemented as planned, including all interfaces (Iub, Iur). The latest parameter recommendations [ref?] should be reviewed and implemented before further optimisation.

A history of the parameter changes into the network a consistency database for all parameters should be available.

Mass modifications are possible with Nokia Plan Editor (see details in LACE reference [1]) and small changes with Nokia Application Launcher (see details in NEMU documentation[2]).

3.3 Neighbour Consistency checks

Neighbour implementation should be checked so that it is as planned in order to have proper cell reselection and SHO functionality.

Neighbours should be bi-directional.

Neighbour plan can be checked using 3G Netplan tool [3]. The purpose with this tool is to graphically display cells, which are using the same DL scrambling code and to show its neighbours defined in OSS database.

3.4 Cell load checks

Cell load can be checked by looking at the UL interference situation with PrxNoise counter in each cell. Normally the PrxNoise is around 102-105 dBm, but if it is more than this, there is something wrong in the cell. The reason could be external interference, or incorrect MHA parameters.

The total load in UL and DL (PtxTotal, PrxTotal) should be less than (PtxTarget, PrxTarget), otherwise the cell is overloaded.

Nokia EOS Reporting Solution (RS) [4] can be used for this check. Alternatively NetAct Reporter tools [ref] can be used to extract the data from the NetAct database.

3.5 RAN Counter and KPI checks

Performance can be seen from the RAN counter statistics. The most important KPIs with recommended target values are below:

Cell availability, >98 %

RRC setup and access complete ratio, >95 %

RAB setup and access complete ratio, >95 %

RAB drop rate for voice, < 3 %

RAB drop rate for others,< 4 %

EOS RS tool can be used to check counters and KPIs. See KPI info from different projects [4].

Alternative these counters can be extracted using the NetAct Reporter tools [ref].

3.5.1 Cell Availability

With the cell availability info it is checked that the cell is up and running. If not the BTS restart is needed.

EoS Repoting Solution (RS) reports could be used to to check the cell availability. Also customer complains and Planner info will help to find sleeping cells. More info about cell availability definition is in reference [4]3.5.2 RRC setup and access complete ratio

This PI gives success rate for the RRC establishment. This is KPI for call setup performance, which is available in EOS RS reports. More info about how this is calculated is in reference [5].

3.5.3 RAB setup and access complete ratio

This PI gives success rate for the RAB establishment this however is not Call Setup Success Rate as it does not include RRC phase. More info about how this is calculated is in reference [5].

3.5.4 RAB drop ratio

This PI can be used as dropped call rate. More info about how this is calculated is reference [5]3.6 UE Performance check

The UE behaviour might affect the network performance: its recommended to test in a controlled environment the UE performance for all the services, related to

Cell reselection

SHO

Power Control

4. Performance check with Field MeasurementsFor Performance check drive tests are typically needed. The set of cells and measurement route should be defined first (typically 10-15 sites, all cells must be measured). With drive test measurements basic KPIs can be verified. An example of KPIs and target values are listed below, see more info about definitions of those in [6].

GategoryName of the testsTarget

1. Performance testsValue

Call setup success rate for Voice> 94.0 %

Call setup success rate for CS 64 kbits/s Data> 92.0 %

Session setup success rate for PS 64 kbits/s Data> 92.0 %

Call drop rate for Voice< 4.0 %

Call drop rate for CS 64 kbits/s Data< 4.0 %

Session drop date for PS 64 kbits/s data< 4.0 %

2. Coverage tests

Depends on the planning criteria, suggestions below

CPICH RSCP>-95 dBm

CPICH EcNo>-12 dB

3. Capacity tests

Throughput & Round trip delay for PS data

DL 64 kbps> 50 kbits/s

Round trip time for 32 bytes ping < 220 ms

3. Time Tests

Call Setup Time for speech and CS data (MOC)

Call Setup time< 7 s

Session Setup Time for PS 64 kbits/s Data< 10 s

Table 1 Example KPIs from Drive Surveys5. Top 10 optimisation activities to improve call performance

These activities are split into

Common performance issues that affect any service

Voice (AMR) call performance

CS Video call performance

PS call performance

ISHO performance

There can be situations where the same problem will cause call set-up failures or call drops. The list of problems with possible solutions is listed below, starting with the most important ones.

5.1 Common Call Performance Issues

BehaviourProblemDescriptionPossible solutions

Call set-up failure

Call drop Poor coverage area If problem is poor coverage, this means poor RSCP (