top103gradiooptimisationactions-100927074613-phpapp02

UMTS RF optimisation methodology used in 3GIS TVP

TOP 10 3G Optimisation Actions 21 (21)

NET/OS/OS Performance

March 2004V.0.4

TOP 10 3G RAN Optimisation Actions

Version 0.4

Author(s):Pekka Ranta

Title:TOP 10 3G Optimisation Actions

Key words:WCDMA optimisation, dominance, interference, throughput

Department:NET/OSS/OS Performance, 3G Radio Program

HISTORY

DateVersionAuthor(s)Change /Notes

27.02.20040.1PrantaFirst draft

04.03.20040.2PrantaUpdated version

04.03.20040.3S.IronsCombined AMR and Video common parameters. Editorial changes. Addes NetAct references.

05.03.20040.4PrantaRadio Plan check added, UE performance check added

Distribution

DateVersionDelivery

27.02.20040.1Review team

04.03.20040.2Review team

05.04.20040.4NP Radio Intranet

Table of contents

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

IntroductionThe 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.Network planning rules for optimum performanceExperience 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 relationsThere 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

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 checkNeighbour consistency checkCell load checkKPI check UE performance check for all the services in a controlled environmentBTS 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].Comment by Irons: Should we add the work arounds or typicall fixes?.Fault in O&M and DSP SW interfaceDescription: 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.ATM overflowDescription: 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.DSC-bus failureDescription: 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.Unit SW download failedDescription: 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.WSP R-Bus ErrorDescription: Wideband Signal Processor (WSP) R-Bus Error IRAD ASIC has detected a R-bus error.No Connection to UnitDescription: Auto detection does not get a response from a unit that is mentioned in the HW Database.Software and Parameter checksThe 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]).Neighbour Consistency checksNeighbour 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.Cell load checksCell 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.RAN Counter and KPI checksPerformance 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].Cell AvailabilityWith 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]RRC setup and access complete ratioThis 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].RAB setup and access complete ratioThis 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].RAB drop ratioThis PI can be used as dropped call rate. More info about how this is calculated is reference [5]UE Performance checkThe 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

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 Surveys

Top 10 optimisation activities to improve call performanceThese activities are split into Common performance issues that affect any serviceVoice (AMR) call performanceCS Video call performancePS call performanceISHO performanceThere 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.Common Call Performance IssuesBehaviourProblemDescriptionPossible solutions

Call set-up failureCall drop Poor coverage area If problem is poor coverage, this means poor RSCP (