The document provides guidance on optimizing 3G radio network performance by identifying the top 10 optimization actions. It begins with an overview of network planning rules and the importance of cell design. Next it describes various health checks to perform on the network including alarms, software, parameters, neighbors and counters. Potential issues affecting voice, video and packet switched calls are then outlined. The document concludes by recommending optimization tools to identify performance problems and make improvements.

1. TOP 10 3G
OPTIMISATION
ACTIONS
1 (22)
NET/OS/OS Performance
March 2004 V.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
© Nokia Networks 2004, Company Confidential Page 1 of 22

2. TOP 10 3G
OPTIMISATION
ACTIONS
2 (22)
NET/OS/OS Performance
March 2004 V.0.4
HISTORY
Date Version Author(s) Change /Notes
27.02.2004 0.1 Pranta First draft
04.03.2004 0.2 Pranta Updated version
04.03.2004 0.3 S.Irons Combined AMR and Video common
parameters. Editorial changes. Addes
NetAct references.
05.03.2004 0.4 Pranta Radio Plan check added, UE performance
check added
DISTRIBUTION
Date Version Delivery
27.02.2004 0.1 Review team
04.03.2004 0.2 Review team
05.04.2004 0.4 NP Radio Intranet
© Nokia Networks 2004, Company Confidential Page 2 of 22

3. TOP 10 3G
OPTIMISATION
ACTIONS
3 (22)
NET/OS/OS Performance
March 2004 V.0.4
Table of contents
1. Introduction.......................................................................................................................................4
2. Network planning rules for optimum performance.............................................................................4
3. Network health check ......................................................................................................................5
3.1 BTS Alarms causing Blocked cells .............................................................................................5
3.1.1 Fault in O&M and DSP SW interface....................................................................................5
3.1.2 ATM overflow.......................................................................................................................5
3.1.3 DSC-bus failure....................................................................................................................6
3.1.4 Unit SW download failed......................................................................................................6
3.1.5 WSP R-Bus Error.................................................................................................................6
3.1.6 No Connection to Unit..........................................................................................................6
3.2 Software and Parameter checks................................................................................................6
3.3 Neighbour Consistency checks...................................................................................................6
3.4 Cell load checks..........................................................................................................................7
3.5 RAN Counter and KPI checks.....................................................................................................7
3.5.1 Cell Availability.....................................................................................................................7
3.5.2 RRC setup and access complete ratio.................................................................................7
3.5.3 RAB setup and access complete ratio..................................................................................7
3.5.4 RAB drop ratio......................................................................................................................8
3.6 UE Performance check...............................................................................................................8
4. Performance check with Field Measurements...................................................................................8
5. Top 10 optimisation activities to improve call performance...............................................................9
5.1 Common Call Performance Issues..............................................................................................9
5.2 Voice (AMR) specific performance Issues.................................................................................11
5.3 Video Call Performance Issues.................................................................................................12
5.4 PS Call Performance Issues.....................................................................................................12
5.5 ISHO performance....................................................................................................................15
6. Optimisation Tools..........................................................................................................................15
6.1 Nokia Application Launcher (AL)...............................................................................................15
6.1.1 RNW Object Browser.........................................................................................................15
6.1.2 RNW Online Management..................................................................................................16
6.2 Nokia Plan Editor......................................................................................................................16
6.3 EOS Reporting Solution (RS)....................................................................................................17
6.4 NetAct Reporter........................................................................................................................17
6.5 Field Measurement Tools (FMT) ..............................................................................................18
6.5.1 RF scanner.........................................................................................................................18
6.5.2 NEMO TOM Drive Test tool................................................................................................18
6.6 Actix Analysis tool.....................................................................................................................20
7. References.....................................................................................................................................21
8. Glossary..........................................................................................................................................21
© Nokia Networks 2004, Company Confidential Page 3 of 22

4. TOP 10 3G
OPTIMISATION
ACTIONS
4 (22)
NET/OS/OS Performance
March 2004 V.0.4
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)
o 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
© Nokia Networks 2004, Company Confidential Page 4 of 22

5. TOP 10 3G
OPTIMISATION
ACTIONS
5 (22)
NET/OS/OS Performance
March 2004 V.0.4
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.
© Nokia Networks 2004, Company Confidential Page 5 of 22

6. TOP 10 3G
OPTIMISATION
ACTIONS
6 (22)
NET/OS/OS Performance
March 2004 V.0.4
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.
© Nokia Networks 2004, Company Confidential Page 6 of 22

7. TOP 10 3G
OPTIMISATION
ACTIONS
7 (22)
NET/OS/OS Performance
March 2004 V.0.4
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].
© Nokia Networks 2004, Company Confidential Page 7 of 22

8. TOP 10 3G
OPTIMISATION
ACTIONS
8 (22)
NET/OS/OS Performance
March 2004 V.0.4
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: it’s 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 MEASUREMENTS
For 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].
Gategory Name of the tests Target
1. Performance tests Value
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
© Nokia Networks 2004, Company Confidential Page 8 of 22

9. TOP 10 3G
OPTIMISATION
ACTIONS
9 (22)
NET/OS/OS Performance
March 2004 V.0.4
5. 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
Behaviour Problem Description Possible solutions
Call set-up failure
Call drop
Poor coverage
area
If problem is poor
coverage, this means
poor RSCP (<-95 dBm)
thus also the EcNo
derades very rapidly (<
-12 dB) when the
coverage border is
reached.
Check Antenna line installation
(antenna position and quality,
cable length and quality).
Check that CPICH powers are
balanced between the studied
cells.
Check presence of shadowing
obstacles.
Add a site to the area.
Call set-up failure
Call drop
Poor dominance
area.
No main server in the
area, too many cells
with weak CPICH level.
CPICH EcNo is usually
very bad even the
RSCP is good e.q.
RSCP –80…-90 dBm
but EcNo about –10 dB
Use buildings and other
environmental structures to
isolate cell(s) coverage.
Down tilt antennas to make cells
dominant and limit effects of
interfering cell(s).
Check antenna bearing.
Add a site.
Call set-up failure
Call drop
Pilot Pollution Bad CPICH Ec/Io (<-12
dB) level although
CPICH RSCP level is
good. High site in the
neighbourhood may
cause interference.
Find interfering cell from Scanner
results.
Adjust antenna bearing and down
tilt or lower the antenna height
(too much tilt will break the
dominance).
Add interfering cell to the
neighbour of the serving cell.
© Nokia Networks 2004, Company Confidential Page 9 of 22

10. TOP 10 3G
OPTIMISATION
ACTIONS
10 (22)
NET/OS/OS Performance
March 2004 V.0.4
Behaviour Problem Description Possible solutions
Dropped
call/SHO failure
Missing
neighbour
A good usable
neighbour is present
within cells coverage
area, can cause DL
interference if it is not in
the active set.
Swapped sectors in
WBTS.
Check scanner data and look for
missing neighbours.
Check the cabling in antenna line.
Call set-up
Failure
Call drop
High PrxTotal
due to UL
External
interference
The PrxTotal level is
significantly higher than
expected in no/low load
conditions.
Try to figure the possible
area/direction of the interference
by checking PrxTotal level on
neighbouring cells.
Alternatively use spectrum
analyser & directive antenna to
locate interferer.
Inform operator/regulator about
the found conditions.
Check if auto tuning range is
large enough (20 dB).
Call set-up failure
Call drop
High PrxToatal
due to wrong
MHA settings
The PrxTotal level is
significantly higher than
expected in no/low load
conditions.
MHA settings should be
checked, see more in
reference [7]
In case of MHA is used in BTS
check MHA and cables loss
parameters, otherwise PrxTotal
value will be too high.
(If MHA parameter is set to ON,
Cable loss parameter is used,
Cable loss = Real MHA gain =
Feeder loss parameter)
Call set-up failure
Call drop
High Prxtotal due
to Installation
problems
The PrxTotal level is
significantly higher than
expected in no/low load
conditions.
Check the antenna installation as
the last alternative in high
PrxNoise case.
Cell set-up failure Bad RRC
connection set-
up success rate
due to slow Ue
cell reselection
RRC connection set-up
complete message not
heard by BTS.
Set parameters so that
reselection process will start
earlier:
Qqualmin, Sintrasearch and
Qhyst2 as per latest
recommendation [8]
Long call set-up
time
Long time
interval for sync
between RNC
and BTS before
connection
The value of Parameter
N312 is too high:
maximum number of “in
sync” indications
received from L1 during
the establishment of a
physical channel
Use smaller value N312 (2,
recommendation is 4).
Use Actix for checking the call
set-up delay (L3 messages).
Use call set-up time optimisation
feature Dynamic setting of
“ActivationTimeOffset” (possible
in RAN1.5.2 ED2) enables 200 to
500ms reduction for set up delay.
© Nokia Networks 2004, Company Confidential Page 10 of 22

11. TOP 10 3G
OPTIMISATION
ACTIONS
11 (22)
NET/OS/OS Performance
March 2004 V.0.4
Behaviour Problem Description Possible solutions
Dropped call SHO to wrong
cell will cause
drop call.
Overshooting cell come
temporarily into active
set and forces a
suitable serving cell to
be dropped out. Later
RSCP suddenly drops
in the “wrong cell” and
causes a dropped call
because there is no
neighbour defined.
Pan away overshooting cell if it is
too close to the serving cell,
otherwise apply down tilting as
well.
Dropped call Cell suffering
from UL
interference = DL
(CPICH)
coverage much
bigger than UL
coverage
As the UE Tx power is
not enough for target
cell synchronisation, the
SHO fails which will
cause call drop later.
Use cell individual offset
(negative value) parameter to
balance the DL and UL coverage.
Check traffic direction of in-car
UEs to decide which cell requires
offsets.
Dropped call DL CPICH
coverage < UL
coverage
Cell with lower CPICH
power than the
surrounding is having
“too good” UL
performance, as this
cells’ UL cannot be
used efficiently due to
SHO is decided upon
DL (CPICH Ec/No).
Use cell individual offset (positive
value) parameter to balance the
DL and UL coverage.
Note: Cell individual offsets are
not taken into account when
calculating the added cell Tx
power.
Dropped call Round the corner
effect
The call drops due to
too rapid CPICH
coverage degradation
for Cell A, and therefore
there is not enough time
for SHO.
Use cell individual offset (positive
value) parameter to balance the
DL and UL coverage.
Note: Cell individual offsets are
not taken into account when
calculating the added cell Tx
power.
Dropped
call/SHO failure
Too many
neighbours
In SHO area the
number of combined
neighbouring cells
become more than 31.
HO list is created using
RNC algorithm in the
final stage some of the
neighbours will
randomly be removed.
Delete unnecessary neighbours.
Improve dominance.
5.2 Voice (AMR) specific performance Issues
No AMR Specific scenarios
© Nokia Networks 2004, Company Confidential Page 11 of 22

12. TOP 10 3G
OPTIMISATION
ACTIONS
12 (22)
NET/OS/OS Performance
March 2004 V.0.4
5.3 Video Call Performance Issues
Behaviour Problem Description Possible solutions
Dropped
call
Not enough DL power
to maintain good
quality
CS video connection needs
more power to maintain the SIR
target and thus also BLER
target.
Increase the max DL Radio
Link power by decreasing
the CPICHtoRefRaBOffset
In case the max power
increment is a lot (~3dB)
then the minimum power is
increased by 3dB as well
which can lead to the
minimum power problems
(BTS sending too much
power to the UEs close to
the BTS and therefore
causing problems to the
UE and even dropped call)
Therefore the PCrangeDL
parameter should be tuned
according to the
CPICHtoRefRabOffset
parameter tuning (from the
default)
More info in reference [9].
Call set-
up Failure
Call drop
High PrxTotal due to
UL External
interference
The PrxTotal level is
significantly higher than
expected in no/low load
conditions.
Try to figure the possible
area/direction of the
interference by checking
PrxTotal level on
neighbouring cells.
Alternatively use spectrum
analyser & directive
antenna to locate interferer.
Inform operator/regulator
about the found conditions.
Check if auto-tuning range
is large enough (20 dB).
5.4 PS Call Performance Issues
PS call performance optimisation aims to maximise the data throughput. Throughput
depends very much on the round trip time (RTT, delay from mobile, typically through USB ,
connector to server and back). The lower the RTT the greater the potential for higher
throughput. Normally RTT is around 200ms.
Also the radio resource efficiency for certain bit rate should be optimised, such that
resources will only be allocated when needed, based on the throughput demand. This can
be optimised with Dynamic Link Optimisation (DyLo) feature parameters.
It should be noted that there is no optimum parameters set to be used for all networks for
maximising PS throughput, but every networks needs some local optimisation.
© Nokia Networks 2004, Company Confidential Page 12 of 22

13. TOP 10 3G
OPTIMISATION
ACTIONS
13 (22)
NET/OS/OS Performance
March 2004 V.0.4
Throughput also varies with UEs types.
Below are the throughput and efficiency specific problems and solutions, although the
common call performance issues also apply.
Behaviour Problem Description Possible solutions
Low Throughput The User bit rate is
much less than the
Radio Bearer bit rate
either in DL or UL.
The reason for lower
throughput problems in
file transfer is in flow
control between PC
and UE which could
mean that TCP
parameter settings are
not optimum, which
may cause
degradation to the
throughput [10]
Measure throughput
and RTT.
Increase TCP Window
Size - RWIN in case
RTT is much more
than 200ms and low
throughput has been
achieved.
In Windows 2000 the
default value is 17520
Bytes.
There are many tools
available to change the
window size, for
example DoctorTCP
[13].
Optimal RWIN in client
= 32660 B
Optimal RWIN in
server = 65535 B
See more in reference
[11].
Low Throughput The User bit rate is
much less than the
Radio Bearer bit rate in
bi-directional file.
When uploads and
downloads are
occurring
simultaneously then
the TCP ACKs (for the
downloading) are
competing with the
upload traffic to get
across the PPP link
between the PC and
UE. This competition
in combination with the
flow control instigated
by the UE will delay
the ACK. Depending
on how big the extra
delay is will depend on
how much TCP will be
forced to slow down.
Measure throughput
and RTT
Increase TCP Window
Size - RWIN in case
RTT is much more
than 200ms and low
throughput has been
got.
In Windows 2000 this
has default value of
17620 Bytes.
Optimal RWIN in client
= 32660 B
Optimal RWIN in
server = 65535 B
See reference [11].
Low Throughput The User bit rate is
much less than the
Radio Bearer bit rate in
bi-directional file.
PC has lots of data to
send in uplink direction
at a rate faster than
the actual radio
interface between UE
and BTS (=64 kbit/s).
To prevent overflow,
Measure throughput
and RTT
Increase TCP Window
Size- RWIN in case
RTT is much more
than 200ms and low
© Nokia Networks 2004, Company Confidential Page 13 of 22

14. TOP 10 3G
OPTIMISATION
ACTIONS
14 (22)
NET/OS/OS Performance
March 2004 V.0.4
Behaviour Problem Description Possible solutions
UE turns flow control
on towards PC to stop
data flow. The
problem is that this
stops also TCP ACK
for downlink data, sent
in uplink direction. This
causes downlink
throughput reduction,
because TCP session
(=ftp) is not receiving
ACKs so quickly.
The phenomenon is
bigger, if the DL data
rate is faster than UL
data rate.
throughput has been
got.
IWindows 2000 as
default value of 17620
Bytes.
Optimal RWIN in client
= 32660 B
Optimal RWIN in
server = 65535 B
See reference [11].
Low Throughput The User bit rate is
much less than the
Radio Bearer bit rate
either in DL or UL.
The reason for lower
throughput problems in
file transfer could be
wrong parameters in
server.
Tune TCP parameters
in the Server:
MSS = Maximum
Segment Size (in
bytes) = TCP payload
MTU = Maximum
Transmission Unit (in
bytes) = IP packet size
MTU = MSS + TCP
Header (20 bytes) + IP
Header (20 bytes)
Optimal MTU in client
and server =1460 B
Low Throughput The User bit rate is
much less than the
Radio Bearer bit rate in
bi-directional file
There is Problem in
FTP server
Change the FTP
server.
In general FTP server
should be located right
after the GGSN (not
behind the public
internet) so it would be
recommended to have
test FTP server located
right to the GGSN.
Make several FTP
sessions instead of
one to increase the
throughput.
Try with stream e.g.
http//wwitv.com
Low Throughput The User bit rate is
much less than the
Radio Bearer bit rate in
bi-directional file
Bluetooth connection
has been used
between UE and PC.
Use USB connection
instead of bluetooth.
Low Efficiency BTS Power resources
are wasted in case
Dynamic Link
Optimisation (DyLo)
Adjust the
PtxDLAbsMax
© Nokia Networks 2004, Company Confidential Page 14 of 22

15. TOP 10 3G
OPTIMISATION
ACTIONS
15 (22)
NET/OS/OS Performance
March 2004 V.0.4
Behaviour Problem Description Possible solutions
high bit rates are used
but throughput is low.
parameters are not set
optimum.
parameter (default
value 50 dBm as
maximum link power,
optimum setting
between 35-37dBm) to
trigger DyLo earlier.
5.5 ISHO performance
Behaviour Problem Description Possible solutions
Call drop RAN is not working
correctly during SHO.
No GSM neighbour list
is sent for
measurements in case
there are 3 cells in
Active Set. (RAN1.5.2
ED1 CD18)
This should be
corrected in laterRAN
release(s).
Call drop Failure to decode
BSIC before the call
drop.
CM starts too late Set higher ISHO
thresholds, FMCS:
CPICH EcNo, CPICH
RSCP, UE TX Pwr
[8]
Call drop Failure to decode
BSIC before the call
drop.
BSIC verification takes
too much time.
Set smaller
measurement time for
GSM cells, FMCG:
Maximum
measurement period,
Minimum
measurement interval,
[8]
6. OPTIMISATION TOOLS
Tools that can be used for problem solving, verification and performance improvement are
described below. For checklist part the tools were already mentioned.
6.1 Nokia Application Launcher (AL)
Nokia AL is part of NetAct tools. Inside AL there are many tools, like object browser and
cell load monitoring tools that are useful optimisation tools. With Radio Network (RNW)
Object Browser parameter modifications and value checks is possible. With RNW Online
Management tool cell load online monitoring could be followed. More info in reference [2]
6.1.1 RNW Object Browser
Object browser is tool for the WCDMA parameter changing and checking. Parameters are
divided into different categories:
• RNC parameters, RNC
• WBTS parameters, WBTS
© Nokia Networks 2004, Company Confidential Page 15 of 22

16. TOP 10 3G
OPTIMISATION
ACTIONS
16 (22)
NET/OS/OS Performance
March 2004 V.0.4
• Cell parameters, WCEL
• Neighbour parameters, ADJS (ADJI, ADJG)
• Handover parameters, HOPS (HOPI, HOPG)
• Measurement control parameters, FMCS (FMCI, FMCG)
There are different sets for Intra-Frequency (market as xxxS), Inter-Frequency (market as
xxxI) and Inter-System (market as xxxG) parameters for ADJx, HOPx and FMCx objects.
In WCEL object the parameters are more divided into categories listed below:
• General (identity)
• Handover control, HO
• Power control, PC
• Admission control, AC
• Load control, LC
• Packet scheduler, PS
• Common channel, CCH
• System Information Block, SIB
6.1.2 RNW Online Management
Online Monitoring tool shows the actual cell level load situation both in UL and DL direction.
Both the measurement results and parameter values could be seen on graphical user
interface. The values in GUI are:-
• PrxTotal (total UL load, measured value)
• PtxTotal (total DL load, measured value)
• PrxNoise, noise level, measured value
• PrxTarget, planned target rx load of the cell
• PtxTarget, planned target tx load of the cell
6.2 Nokia Plan Editor
Plan Editor is an off-line tool for manipulating Radio Access related parameters and plans.
Plan Editor is a part of Radio Access Configurator (RAC) solution. Plan Editor features
© Nokia Networks 2004, Company Confidential Page 16 of 22

17. TOP 10 3G
OPTIMISATION
ACTIONS
17 (22)
NET/OS/OS Performance
March 2004 V.0.4
support daily tasks in network development and optimisation e.g. integrating new sites, or
deleting objects, or optimising parameter values.
There is Plan Editor package support for OSS3.1 ED2, where Radio Access Configurator
has updated functionality for managing 3G RN1.5.2 and 2G S10.5 ED parameter data. In
addition to 3G RN1.5.2 parameters supported earlier, Plan Editor also supports common
2G BSS objects that can be used for defining intersystem adjacency relations (ISHO).
There are also new re-hosting related profiles and added functionality. AXC C2.0 is
supported for the parameters defined in the commissioning interface and more functionality
will come with RN1.5.2 ED2. More information in reference [1] and [14]
6.3 EOS Reporting Solution (RS)
EOS RS is tool developed for internal use, which has good RAN counter and KPI reporting.
It needs NetAct database to be installed to the network as it works with counters collected
from the network elements and stored in the database. PC is required run the tool and get
info from the database. The following KPIs can be retrieved using the tool.
• Cell Availability
• RRC Set-up Success Rate
• RRC Set-up and Access Success Rate
• RRC Drop Ratio
• RAB Set-up Success Rate
• RAB Set-up and Access Success Rate
• RAB Drop Ratio
• SHO overhead
• SHO Success ratio
• Also cell load info (PrxTotal, PtxTotal) can be checked.
More information is in reference [4] and [5].
6.4 NetAct Reporter
NetAct reporter is the official reporting functionality for Nokia NetAct platform. Tools
include KPI Browser, Report Builder and Report Browser. These tools allow data
extraction from the PM Database and are standard to the Nokia NetAct platform.
Also, Content Creation group within Nokia have developed WCDMA Reporting Suite, which
uses NetAct Reporter functionality. This is an optional feature so not all customers will
have purchased it.
Unlike the EOS RS the KPIs reports for RAN are not ready made although they could be
created with Report Builder.
© Nokia Networks 2004, Company Confidential Page 17 of 22

18. TOP 10 3G
OPTIMISATION
ACTIONS
18 (22)
NET/OS/OS Performance
March 2004 V.0.4
6.5 Field Measurement Tools (FMT)
There are a growing number of FMT available for WCDMA systems. These are divided
into scanner tools or Ue based measurements tools. Both these types play a key role in
the optimisation of the network. A review of tools can be found at [16].
6.5.1 RF scanner
The purpose of using the RF scanner is to be able to scan and measure all used
carriers/cells and their corresponding DL scrambling codes. This gives the full picture of
the (on air) radio network within a selected frequency band. The results are used to identify
and understand reasons for peculiar behaviour discovered during field measurements. In
addition, the scanner will indicate presence of “illegal” RF interference within the sub bands
allocated to the network. The scanner data analyses can be done for many purposes:-
• For low coverage areas
• For antenna installation problems
• For missing neighbours
• For coverage optimisation
With the scanner you can get the following info from the surrounding cells:
• Different Scrambling codes
• CPCIH RSCP value (dBm)
• CPICH EcNo value (dB)
More information is in reference [12].
6.5.2 NEMO TOM Drive Test tool
The NEMO DT tool with the Nokia 6650 UE is used to measure and verify long and short
AMR 12.2 kbps (voice) MOC calls. With TOM KPI verification can be done. –
© Nokia Networks 2004, Company Confidential Page 18 of 22

19. TOP 10 3G
OPTIMISATION
ACTIONS
19 (22)
NET/OS/OS Performance
March 2004 V.0.4
Laptop computer
GPS receiver
DC/AC converter
(12 VDC/230 VAC)
Charger
12 VDC
(Car battery)
UE measurements are different than to RF scanner measurements. The Scanner
measures all SCs, whereas the UE only measures SC signals from the cells that the
system has informed/ordered the UE through the BCH (neighbour list) or via the
“measurement control” message.
With TOM you can get following info:
• The BLER downlink
• Carrier RSSI
• Data Throughput Downlink
• Data Throughput Uplink
• Ec/No Active Cell
• Ec/No Monitored Cell
• Pilot BER
• Random Access Initial Tx Power
• Random Access Preamble Count
• Random Access Preamble Step
• Random Access Tx Power
• SIR target
• UE Tx Power
• Call Statistic: AMR, CS and PS data calls
© Nokia Networks 2004, Company Confidential Page 19 of 22

20. TOP 10 3G
OPTIMISATION
ACTIONS
20 (22)
NET/OS/OS Performance
March 2004 V.0.4
More information is in reference [12].
6.6 Actix Analysis tool
Actix analyser is a tool for post-processing cellular network data (GSM, CDMA, WCDMA).
The tool is specifically tailored to import measurement data from various (measurement)
tools and file formats and then present it in map, table, workbook or chart format. Also it is
possible to define your own specific queries, although Nokia have developed a standard set
of queries.
Note that there is more than one version of the Analyser.
• Rollout Verification Solution (RVS)
• System Verification Solution (SVS)
• Infrastructure Verification Solution (IVS)
Below is a list of the capabilities of Analyser:-
Radio Link Performance
Troubleshooting:
• Distant servers
• Too many servers
• Unnecessarily large neighbour
lists
• Excessive soft handoff
Event Detection and Drive Test
Analysis:
• Coverage problems
• Poor UL or DL, coverage limited,
interference
• Handover problems
• Missing neighbours
• Pilot pollution
Overall Call View: • Detailed dropped call and failed set-
up level analysis
• Detected problem(s) identified per
call
• Individual call extraction for detailed
message level analysis
Neighbour List Analysis: • Generation of recommendations for
optimal neighbour list settings
• Integration with Network Element
Database
• Based on UMTS/WCDMA scanner
drive test data
Supported Measurements with
Scanner are:
• Layer 1 scanner measurements
(for example EcIo, RSCP, etc.)
Supported Measurements with
Handset are:
• Layer 1 handset measurements (for
example EcNo, TxPow, etc.)
© Nokia Networks 2004, Company Confidential Page 20 of 22

21. TOP 10 3G
OPTIMISATION
ACTIONS
21 (22)
NET/OS/OS Performance
March 2004 V.0.4
• RRC Layer 3 signalling – Call
Control (CC), Mobility Management
(MM), GPRS Mobility Management,
GPRS Session Management
More information is in reference [12].
7. REFERENCES
[1] LACE Materials
[2] RNC Nemulandia
[3] 3G Netplan material
[4] KPI status from 3G projects
[5] KPI formulas and Counters
[6] Field Test Cases for System Acceptance
[7] MHA settings
[8] Parameter changes for RAN1.5.2 ED2
[9] WRST4 training material
[10] GPRS Core Network Optimisation Guideline
[11] TCP optimisation for 3G
[12] 3G field tools
[13] DrTCP
[14] Plan Editor Intanet Page
[15] NetAct Reporter Bookshelf
[16] FMT Homepage
[17] RN1.5.2ED on NOLS
8. GLOSSARY
NW Network
CS Circuit Switched
PS Packet Switched
© Nokia Networks 2004, Company Confidential Page 21 of 22

22. TOP 10 3G
OPTIMISATION
ACTIONS
22 (22)
NET/OS/OS Performance
March 2004 V.0.4
SC Scrambling Code
SW Software
UE User Equipment (aka MS)
NED Nokia Electronic Documentation
© Nokia Networks 2004, Company Confidential Page 22 of 22