GSM SERVICE DELIVERY

GUIDELINE FOR
INITITAL TUNING SERVICE
DELIVERY DESCRIPTION/P
LO

1(39)

Table of contents
1 INTRODUCTION..............................................................................................................................3
1.1 General..............................................................................................................................................3
1.2 Abbreviations....................................................................................................................................4
1.3 Input..................................................................................................................................................5
1.4 Output...............................................................................................................................................5
2 TIME TABLE....................................................................................................................................6
3 TOOLS FOR INITITAL TUNING SERVICE DELIVERY DESCRIPTION............................7
3.1 CELL PLANNING...........................................................................................................................7
3.2 CONSISTENCY CHECKING.........................................................................................................7
3.3 DRIVE TESTING............................................................................................................................7
3.4 SYSTEM MONITORING................................................................................................................8
4 PROCEDURE....................................................................................................................................8
4.1 General..............................................................................................................................................8
4.2 Workflow..........................................................................................................................................9
4.3 Parameter Check.............................................................................................................................10
4.4 Consistency check...........................................................................................................................11
4.4.1 Determine what to check.............................................................................................................11
4.4.2 Perform the check.......................................................................................................................11
4.4.3 Analyzing the consistency report................................................................................................12
4.4.4 Updates........................................................................................................................................12
4.5 DRIVE TESTS...............................................................................................................................12
4.5.1 Preparations................................................................................................................................12
4.5.2 Personnel.....................................................................................................................................12
4.5.3 Test routes...................................................................................................................................13
4.5.4 Packet data drive testing ...........................................................................................................14
4.6 Performance monitoring.................................................................................................................16
4.6.1 Statistics review...........................................................................................................................16
4.6.2 Review from other measurements...............................................................................................16
4.6.3 Customer complaints review.......................................................................................................16
4.7 ANALYSIS.....................................................................................................................................17
4.7.1 Problem identification................................................................................................................17
4.7.2 Action..........................................................................................................................................17
4.8 Parameter tuning............................................................................................................................17
4.8.1 Parameter tuning Workflow........................................................................................................17
4.8.2 Collect statistics..........................................................................................................................19
4.8.3 Changing parameter values........................................................................................................19
4.8.4 Evaluating statistics....................................................................................................................19
4.8.5 Reporting.....................................................................................................................................19
4.9 FEATURE EnablING.....................................................................................................................20
4.9.1 Enable features Workflow...........................................................................................................20
4.9.2 Preparation.................................................................................................................................21
4.9.3 Field Trial...................................................................................................................................21
4.9.4 Activation....................................................................................................................................21
4.9.5 Follow-up....................................................................................................................................21
4.9.6 Documentation............................................................................................................................21
4.10 MECHANICAL TUNING............................................................................................................22
4.11 FREQUENCY PLANNING.........................................................................................................22
APPENDIX 1-RADIO PROBLEM ANALYSIS............................................................................23
1. LONG SDCCH MEAN HOLDING TIME.................................................................................26
2. SHORT SDCCH MEAN HOLDING TIME...............................................................................27

2(39)

3. SDCCH CONGESTION................................................................................................................28
4. POOR SDCCH AND/OR TCH AVAILABILITY......................................................................29
5. LOW RANDOM ACCESS SUCCESS RATE.............................................................................30
6. LOW TCH ASSIGNMENT SUCCESS RATE............................................................................31
7. HIGH TCH DROP CALL RATE.................................................................................................32
8. HANDOVER ANALYSIS..............................................................................................................33
9. NO OR FEW HANDOVER ATTEMPTS....................................................................................34
10. LOW HANDOVER SUCCESS RATE.......................................................................................35
11. LOW LLC THROUGHPUT.......................................................................................................37
12. BAD PACKET DATA RESELECTION PERFORMANCE...................................................38
13. GSM-UTRAN HANDOVER PROBLEMS................................................................................39

1
1.1

INTRODUCTION

GENERAL
This document describes the initial tuning procedure of the Radio Network
Design for GSM.

3(39)

It is an integral part of the Radio Network Design Service. It describes the

procedures to be followed when dealing with Initital Tuning Service Delivery
Description, as defined in the Vendor Service concept. This document is
designed to create a common understanding of how to perform Initital
Tuning Service Delivery Description, regarding procedures and information
flow.
The purpose of the Initial Tuning is to make sure the radio network works
well after the network has been built or in case of an expansion. This is a
very crucial activity, which is often done under pressure.

1.2

ABBREVIATIONS
AMR
ARFCN
BCCH
BSIC
BSC
CDD
CER
C/I
CNA
CNA-I
CR
CS
CTR
DT
EFR
EGPRS
FR
FOX
FTP
GPRS
GPS
IMSI
IPOS
LAN
MCC
MNC
MRR
MS
MSC
MTR
NOX
OSS
QOS
RBS
R-PMO
SQI
STS
TCP
TEMS
TRU

4(39)

Adaptive Multi Rate

Absolute Radio Frequency Channel number
Broad Cast Channel
Base Station Identity Code
Base Station Controller
Cell Design Data
Cell Event Recording
Carrier to co-channel interference ratio
Cellular Network Administration
Cellular Network Administration Interface
Change Request
Circuit Switched
Cell Traffic Recording
Data Transcript
Enhanced Full Rate
Enhanced General Packet Radio Service
Full Rate
Frequency Optimization Expert
File Transfer Protocol
General Packet Radio Service
Global Positioning System
International Mobile Subscriber Identity
Input & Parameter Optimization Software
Local Area Network
Mobile Country Code
Mobile Network Code
Measurement Result Recording
Mobile Station
Mobile Switching Center
Mobile Traffic Recording
Neighbour Optimization Expert
Operation and Support System
Quality of Service
Radio Base Station
Real Time Performance Monitoring
Speech Quality Index
Statistics and Traffic Measurement Subsystem
TEMS Cell Planner
Test Mobile System
Transceiver Unit

1.3

INPUT
Inputs to the Initial Tuning procedure are given by the procedures Radio
Network Design, Frequency Planning and Preparation of CDD. These should
include:

Site data
Cell parameter data
Frequency plan
Map data

The main network input is STS and drive test data.

1.4

OUTPUT
The output from this procedure is
The Initial Tuning Report
Change requests to correct found radio network problems.

5(39)

TIME TABLE

To perform a high quality Initital Tuning Service Delivery Description, the

time schedule presented below gives an estimation of the required time.
However adjustments may have to be done if some of the following factors
are involved:

A poor cell plan, which needs a lot of adjustments.

New functionality is used.
Heavy traffic, the test routes take longer when there is a traffic jam.
Water, if test routes have to be performed by boat.

The figures in table 1 are presented as man-hours per site.

Event

Preparations
Initial tuning
Report
Table 1

6(39)

Voice

Voice/GPRS/EGPRS

4.2
7.6
4.2

4.5
9.5
4.5

A timetable showing the estimated time needed for an Initital Tuning Service
Delivery Description

3
TOOLS FOR INITITAL TUNING SERVICE DELIVERY
DESCRIPTION
3.1

CELL PLANNING
TEMS CellPlanner can be used for cell planning. During Initial Tuning, it is
often necessary to make relatively minor changes to the cell plan. Examples
are re-directions or tilts of the antennas.

3.2

CONSISTENCY CHECKING
There are various tools available for the Consistency checking.
The most convenient way to perform the consistency check is by using the
CNA function in OSS. Thereby no data retrieval is necessary, and any
inconsistencies found can be rapidly corrected and verified using the same
tool.
There are also various tools available for performing the consistency
checking, using printout-files from the BSCs and MSCs. This could be an
option in case OSS is not available or accessible, or if the initial tuning is
made from a different office without OSS-connection.
For this purpose, the idea at the moment is to primarily use the tool Exert,
which is based in Excel. The main purpose of this tool is to perform
consistency checks and some supportive functions to facilitate them.
Another possibility is to use IPOS, which is a database-tool created to
primarily handle Cell Design Data, but which has consistency checking
features as well.

3.3

DRIVE TESTING
The following list contains the minimum number of equipment in order to
perform a TEMS test-route. If there is enough personnel to do two test-routs
simultaneously, double the number of equipment needed. If the C/I analysis
is including in the tests-routs, the TEMS Investigation must be used.
1 TEMS MS including:
- Serial cable to PC
- Power cable to cigarette lighter socket
- External antenna
1 GPS including:
- Serial cable to PC
- Power cable to cigarette lighter socket
- External antenna
1 portable PC equipped with:
-

TEMS software
Two serial ports for TEMS phone and GPS
Power adapter to cigarette lighter socket

1 Two or three-way splitter for cigarette lighter socket.

1 test vehicle (car or van) with metal roof.

7(39)

Depending on the type of network, for example, dualband, GPRS/EGPRS,

AMR, combination with UMTS, the test mobile must be able to handle all the
different cases and be compatible with the possible cases.

3.4

SYSTEM MONITORING
Drive testing is a rather time consuming and expensive method to gather
data. It is therefore often advantageous to monitor system performance
using available system features.
The main system information source is usually statistics provided by STS
obtained either through OSS or some similar tool or straight from the raw
data, post-processed by some tool. The statistics provide counters related to
very many aspects of the network, and can be primarily to see what has
happened.
4

4.1

PROCEDURE

GENERAL
Initial Tuning is performed in a new network or in an expansion phase of an
existing network prior to the commercial launch. The network performance is
measured in terms of coverage and quality. The service contains a
verification of the frequency plan and a control of the initial parameter
settings to make sure that they correspond to the CDD, the Vendor
recommended values and the actual network status.
Drive tests are performed to verify that handovers are working correctly, to
detect interference areas, to note unexpected coverage holes and to verify
parameter and frequency changes.
In a network including GPRS service, circuit switched and packet data
services will compete for the same spectral resources, and network quality
might degrade. The additional GPRS interference should be taken into
account. However, initially, GPRS traffic is not so significant and it has
assumed that the interference increase (due to the introduction of GPRS)
can be neglected. Nevertheless an analysis of the C/I can be done both to
check the frequency plan and throughput on radio interface. The equipment
that has to be used for this analysis is the TEMS Investigation.
In a network where both EGPRS and GPRS should be used, it is necessary
to assess, and possibly tune, the performance of both.
In a combined GSM and UMTS network, the handovers and reselection to
and from UMTS must be checked and tuned.
In case the system is designed for AMR mobiles, it is necessary to perform
the initial tuning using them. It should be noted that in case non-AMR
mobiles are used in an AMR-designed network, the performance is likely to
appear as very bad. This effect can be avoided in R10, balancing the
situation with the new AMR Power Control Feature to avoid bad performance
over non-AMR mobiles. See reference 10 for more information.

8(39)

System monitoring should only be used in networks with enough traffic.

It is very important not to rely on for example statistics if there is too little
activity in the network.
After the Initial Tuning, the system should have a performance according to
the contract and hopefully pass the Acceptance test. Since the Initial
Tuning is often performed with little or no traffic in the network,
problems that are dependent on the system load cannot always be
measured or detected. Therefore, it must be kept in mind that the
frequency plan, as well as the parameter settings, must be reviewed when
there is more traffic in the system and that the work is not included in the
initial tuning.

4.2

WORKFLOW
Schematically, the initial tuning workflow can be presented as below:
BSC cell
data

Parameter
checking
check
procedure

STS
reports

Consistency
Consistency
check
checking
procedure

Drive tests
test
Drive
procedure
Drive test
Drive
test
report
report

Performance
Performanc
monitoring
e
monitoring

Quality
drive test
data
External
drive test
reports
Customer
service
information

Traffic
Traffic
recording
recording

Analysis
Analysi
s

Parameter
tuning
tuning

Enabling
features
features
procedure

procedure

Check Result!!!
Mechanical
tuning

Frequency
planning

Optimization
logbook
CR

Radio network

Figure 1

The workflow describes the initial tuning procedure

The following summarizes the problem analysis flow to be performed on a

daily basis:

9(39)

1.

Analyze the radio statistics reports

2.

Check overall system performance per BSC

3.

Identify potential problem areas and problem cells (top 10)

4.

Perform benchmarking. Compare with other cells or parts of the network

and/or with defined quality targets

5.

Identify problem areas

6.

Retrieve detailed statistics on the problem areas

7.

Initiate and perform further measurements, such as drive testing with

TEMS, or BSC/MSC/OSS recordings.

8.

Perform a careful and detailed analysis

9.

Take actions to solve the problems

Immediate actions (e.g. parameter changes, adding of missing

neighbours etc)

Short term, within the same day (drive tests, change of frequencies,
BSIC, hysteresis etc)

Mid term, 1-2 days (e.g. change antenna configuration, additional TRUs,
antenna tilts/directions etc)

Long-term, 1-2 weeks (e.g. new sites, cell splits, etc)

10. Verify improvements, if the problem is still there. Find another

solution, and continue until the best possible performance has been
achieved.

4.3

PARAMETER CHECK
It is important to make sure that the parameter setting is according to the
recommended Vendor values in a first stage. This check should be done
before anything else. The recommended values can be found in reference 3.
The parameter checks can be made using various tools.
It is advisable that this check is performed before too many other activities
are started in the initial tuning, as some of the worst problems can be found
easily and proactively.

10(39)

4.4

CONSISTENCY CHECK
Once the correct parameter setting is used according to the recommended
values, it is also necessary to make sure that all the settings are consistent
in the various cell, sites, BSCs, MSCs, etc. The consistency check workflow
is described in the figure below.

1. Determine what to
check

2. Define and run the

consistency check

3. Analyze the
consistency report

4. Making Updates

Figure 3 Workflow for the consistency checking procedure

4.4.1

Determine what to check

Before starting the consistency check, one must determine exactly which
inconsistencies that should be checked. When the first check is made it is
often good to select all options to see how the situation is, but to enhance
efficiency in later runs, it could be beneficial to limit the checks to most
critical, or those related to changes made in the network. For example, when
the frequency changes are being implemented, it is very important to make
sure the MBCCHNOs are correct. In addition, by removing unnecessary
checks makes it easier to spot the more serious problems.

4.4.2

Perform the check

Using either the OSS data for the CNA or the command files for the PCbased tools, the consistency check can be run. The output is a report that
states all the inconsistencies.

11(39)

4.4.3

Analyzing the consistency report

The next step is to analyze the report. This can be quite a significant task, so
please remember that not all inconsistencies listed in the report need to be
corrected. On the other hand, it is necessary to make sure the important
problems are detected. Several of the listed inconsistencies might be
difficult to understand, so it is essential to have sufficient information
available about how to interpret the reports.

4.4.4

Updates
After analysis, it had to be decided which inconsistencies that should be
corrected. Using OSS, this can easily be done using the built-in functionality.
In case the PC-based tools are used, DT, Data Transcript, must be created
and loaded.
The timing of the updates depend on the type of upgrades and the network
status. For instance, major upgrades in a commercially launched network
should preferably be done at low-traffic hours.

4.5

DRIVE TESTS
Once the cell data is correct, it is time to start drive testing. Drive testing
should be done both to discover problem areas, as well as to confirm that
improvements have been achieved after changes. In a network with few or
no subscribers, drive testing is necessary. If there are many subscribers,
drive testing should be avoided as much as possible, since it requires many
resources and is very expensive compared to using statistics. Therefore,
drive tests would be used only for detailed analysis of local problems,
detected by statistics.

4.5.1

Preparations
Before the actual tuning of the network starts, there are some initial
preparations to be done.

4.5.2

12(39)

Check the map datum setting in the GPS to correspond to the digital
map data

Mount test equipment in car.

Include all BCCH frequencies in the measuring lists for all the cells. This
makes it easier to spot a missing neighbour in the neighbour list.
However 32 measurement frequencies is the maximum that can be
added to a cell. This point is not mandatory, but recommended.

Create a TEMS cell file to be able to track the serving and neighbouring
cells.

Initiate a Mobile Traffic Recording, MTR, in the OSS. This should only
be done if it there is available time to analyze it.

Personnel

A drive test route is initially performed with three people:

One driver.

One person operating TEMS.

One navigator, who makes sure that the driver follows the test-route.

After a while, when the team is familiar with the test area, it could be
possible to reduce the number of people performing the drive tests to two;
one driver and one navigator/TEMS operator. This depends on how
experienced the navigator/TEMS operator is and how good the driver is.
4.5.3

Test routes
Preferably, the Vendor personnel should plan the drive test routes. However,
if the customer has opinions regarding special important areas etc., they
should be taken into consideration. Before starting the field measurements,
Vendor and the customer should agree on the planned routes. The routes
should be planned so that they

pass through all cells in the network.

cover all the major areas where coverage is predicted.

perform handovers between as many cells as possible. All of the most

important cell-boarders should preferably be crossed.

pass through important areas within the service area and the route
should be planned so that important roads are included.

are as efficient as possible. The individual routes should be planned so

that they geographically cover separate areas. Overlap should be
minimized.

For the first drive test in an area, the drive routes should be made around
every site, in both directions to ensure that handovers are performed
between the cells. This can also be used as a check of the antenna
directions by controlling that handovers are performed in the expected area,
see figure below.
In some cases, the intensive tests for all cosited handover verification are
done as BTS are integrated, as part of Acceptation Test for the site
Installation. In such cases, it could be not neccessary that the general routes
include the descripted exhaustive grid pattern for each site.
A

C
B

Figure 5

13(39)

The arrows A, B and C corresponds to the antenna directions for each cell in a
three-sector site. The circular arrows show schematic drive-routs, in both
directions, around the site.

Drive routes between sites should be designed so that handovers are

performed between each cell and its neighbours, see the shadowed area in
the figure below.
A1

C1
B1

A2

C2
A3

B2

C3
B3

Figure 6

The shadowed area shows where to drive to check handovers between cell B1,
A2, C2 and A3. B2 and B3 should also be included in B1s neighbour list.

Before driving a test route, the planned route should be marked out on the
map. If possible, site names should be marked as well as BSIC and
frequencies per cell. This will make it easier to detect errors while performing
the test route. By using a best server plot from the cellplanning tool on the
road map, the planning of the test routes become easier.
The log-files should not be too long, preferably less than 20 minutes.
Therefore, a test route should be split in to several log-files.
The following items should be particularly considered when drive testing:
Call set-up success
Handovers
Dropped calls
RxLev
RxQual
SQI
C/I
After the drive test, the results should be reported in an appropriate way.
4.5.4

Packet data drive testing

Includes new counters for GPRS-traffic, allowing the problem detection by
statistics. Nevertheless, in the current situation, the GPRS traffic is
commonly low and in a new network the traffic level is expected to be lower.
Therefore, the drive testing is essential for a good characterization of GPRS
traffic.
The drive testing should be done with TEMS Investigation 3.2 or later with
MS software R1E or later.

14(39)

4.5.4.1

Cell Reselection testing:

This test is similar to handover testing for the circuit switched case.
Offers an approximation to study this topic through the number of times the
downlink buffer contents in the PCU were discarded due to an inter RA cell
reselection or inter PCU cell reselection, but the cell reselection in the same
RA/PCU is not registered, so these measurements must be performed using
TEMS-phones.
Cell reselection could be measured using the following methodology:
1. An ftp-transfer should be running.
2. Packet Messages are received on the downlink. The last message to be
received on downlink before a reselection is usually Packet Downlink
Ack/Nack.
3. After the reselection, the transfer is then started again on the next cell.
The reselection should be considered as finalized when either Packet
Uplink Assignment or Immediate Assignment has been received.
4. If this occurs within a certain time after the last message in the old cell,
then that should be regarded as a successful reselection. This time could
for example be 5-10 seconds.
There are thus two things to measure regarding reselection:
Success rate of the procedure above within a timeframe
Average time of the procedure above

4.5.4.2

Throughput testing:
The purpose of this test is to measure the downlink throughput for a TEMS
mobile that is standing still. The test should be performed in many different
locations. The steps to follow are:
1. Make sure the parameter setting supports the highest possible expected
throughput. (selection of CS, QoS, etc)
2. Start an FTP-transfer of for example 200 Kbytes.
3. Note the radio link throughput (kbit/s per timeslot) for the download.
4. Redo the test in the same location three times.
The result of the throughput tests should be according to the radio design for
location.

15(39)

4.6

PERFORMANCE MONITORING
Depending on the status of the network, the methods to be used for the
performance monitoring can vary slightly. At the beginning, before there are
even friendly users, drive testing is really the only way to handle the
performance monitoring. As the number of users increases, it is possible to
start using various complaints as well as slowly considering the network
statistics.
The performance of the radio network should be examined on a daily,
weekly and monthly basis to identify problems. The status should be
assessed, the trends should be evaluated and the results should be
documented in different reports. The monitoring on a daily basis should
result in problem reports for immediate action. The monitoring on a weekly
basis should result in a weekly performance review report. The monitoring on
a monthly basis should result in a monthly trend report.

4.6.1

Statistics review
The statistics reports, containing STS-formulas should be examined on a per
cell basis to identify problems in the network. Examples of problems are:
Low handover success rate
High dropped call rates (TCH and SDCCH)
Congestion (in expansions)
Low packet data throughput

4.6.2

Review from other measurements

Even if STS provides the most valuable source for performance monitoring,
the other measurement can be used as well to evaluate the network
performance. Due to the large data volumes created by these applications, it
might be difficult to review the results as often as STS, and these tools are
mainly intended for trouble shooting.

4.6.3

Customer complaints review

It is sometimes possible to use the information from the customer service
department to identify areas where subscribers perceive quality problems.
These complaints should be checked for importance and liability and
reported to the network optimization group. It is important that this is done in
an organized way, as the number of complaints might be large.

16(39)

4.7

ANALYSIS
The purpose of the analysis phase is to gather all the problems retrieved
from the Parameter check, Consistency Check, Drive tests and Performance
monitoring and that were not solved immediately during those activities, to
find possible solutions. Depending of the result of the analysis, actions such
as Parameter Tuning, Feature enabling, Mechanical Tuning, Frequency
Planning can be applied to improve the performance.

4.7.1

Problem identification
If a cell or an area is identified as having a problem then a check should be
made in the optimization problem log to see if the problem has been
reported previously. If it is a new, the statistics data for the previous couple
of days should be examined to determine whether this is a new problem or
one, which may have been overlooked.
Initially during the network start-up phase a certain amount of discretion may
have to be shown by network monitoring when deciding whether to issue a
problem report or not, as there may be many such problems. Problems
should be weighed against each other and priority given to the most
important.
A set of big maps fixed to the wall is useful for tracking and also identifying
problems. When a problem has been identified and a decision has been
made to issue a problem report, the problem report should be entered as a
new item in the radio network optimization log.

4.7.2

Action
Once the problem has been identified, an appropriate action to solve it must
be proposed. Once possible solution has been found, it has to be decided if
one should go ahead with it. Sometimes, various management decisions
must be taken and sometimes, the engineer can decide by himself. Often,
some commercial issue might affect the possible solutions.

4.8

PARAMETER TUNING
The purpose of the parameter tuning is to change certain parameters to
improve network performance. It also includes manually adding neighbors
and similar, is one of the major activities during initial tuning.
In case the setting is not suitable for the network, some other default setting
should be determined.

4.8.1

17(39)

Parameter tuning Workflow

The parameter tuning workflow is described in the figure below.

Collect statistics

PRE-ANALYSIS

Change parameter
value

Parameter
differs from par.
rec. and/or par.
log?

Yes

Update parameter
log

No
Evaluate statistics
Compare with the
pre-analisis result

Yes

More parameter
values to be
tested?
No

Recommended
No
value(s)
to be
changed?

Yes

Update parameter
recommendations,
write report if
required

FIN

Figure 8

Graphic representation of the workflow for the Initital Tuning Service Delivery
Description procedure

During the period when one or several parameters are tuned in an area, no
other major activities may be performed in this area that may affect the
result, in order to isolate the results and so, establish a clear cause-effect
relationship between parameters changes and performance changes.

18(39)

4.8.2

Collect statistics
Before parameters are changed, statistics should be collected for the
intended area. The statistics should be collected for a certain period before
any parameters are changed, in order to be able to compare and to prove an
improvement.
The amount of statistics collected must be sufficient to establish statistically
significant results. In general it can be stated that a small amount of affected
cells, require more data.

4.8.3

Changing parameter values

If the new parameter value differs from the value given in a parameter
recommendation list, a parameter log should be updated. This is to avoid the
parameter changes to be "corrected" and changed back to their original
value by the parameter status check.
In general, only one parameter should be changed at a time. If several
parameters are going to be changed at the same time they should be closely
related to each other. Parameters related to the same feature, e.g. MS
Power Control might be changed at the same time if a completely new
parameter setting for this feature is going to be tested.
If a large number of parameters are to be changed, or if a completely new
parameter setting is to be tested, the procedure for feature enabling should
be considered.

4.8.4

Evaluating statistics
Evaluating statistics is the key activity in parameter tuning. It is important to
make sure the quality does not deteriorate in the surrounding areas

4.8.5

Reporting
The parameter changes should be documented. With limited parameter
testing activities, updating of the logs should be sufficient. With larger testing
projects, the activities should be documented in project reports.

19(39)

4.9

FEATURE ENABLING
The purpose of enabling/disabling features is to achieve better network
performance by making use of additional network software functionality.
Regarding features affecting interference or strongly relation with frequency
planning or reuse patterns

4.9.1

Enable features Workflow

1. Select
Feature
2. Proposal

no

yes

3. Field
trial?

5. Field Trial

no

yes
6. Go
ahead?
7. Activation

8. Follow-up

9. Documentation
Figure 9

Graphic representation of the workflow for how to enable features

Certain features, such as frequency hopping and overlaid/underlaid subcells,

have several modes of operation. A significant change of how the feature is
used should also be considered a feature enabling.

20(39)

4.9.2

Preparation
The feature should be studied in detail, particularly with respect to
parameters, expected benefits and possible drawbacks. A document should
be prepared containing:

parameter settings
areas/regions where the feature should be enabled
introduction time for the various parameter settings
measurement methods
expected outcome
fallback procedures

The fallback procedure should give details about the state of the network
before enabling the feature (parameter setting, operation mode,
geographical area etc.) and where this information is stored.
4.9.3

Field Trial
If the feature to be enabled is suspected to have a large or doubtful impact
on the network performance, the enabling might have to be preceded with a
radio network field trial covering a few sites. If the results from the field trials
are positive, the feature should be enabled in a larger area.
In other cases, only an application over a wide range can create the positive
pursued effect, for example with Power Control feature.

4.9.4

Activation
STS and/or recording functions should be used to collect performance data
for at least one week prior to enabling of the feature. The data should be
selected so that a comparison and evaluation of the network performance
before and after the introduction of the new feature can be performed.
If the change in the network is large and expected to be significant, the
Network Maintenance/Operation unit, or similar, should be informed about
the plans well in advance. If the parameter changes are service affecting,
they should also be involved in planning the time for the changes.
When everything is ready, the feature should be switched on.

4.9.5

Follow-up
STS or recording functions should be collected for at least a week after the
new feature has been switched on. Drive testing can also be used to collect
additional data. Some minor optimization of the feature might be expected
the first few days.
If the feature does not give the expected benefits, some really good
explanations must be prepared to the customer. Usually, when fancy
features are switched on, almost nothing measurable happens. If the
network performance deteriorates due to the new feature, a fallback
procedure should be activated.

4.9.6

21(39)

Documentation

All changes of parameter settings and measurement results in the network

should be documented.
4.10

MECHANICAL TUNING
Mechanical adjustments to the antennas such as changes of the antenna tilt
and height affect the received signal strength and thereby the coverage area
and interference levels.
The height of the antenna position affects the cell coverage area. The higher
the antenna position, the bigger the coverage area. In case the antenna is
located in a tower, it is sometimes possible to change the height to achieve
the coverage area objectives. Before the antenna height is changed, a
thorough analysis should be made in TEMS Cell planner to make sure the
objectives will be met by the change.
As most sites use the relatively narrow-beamed 65-degree antennas, the
coverage might sometimes be weak far from the main antenna direction.
Sometimes, a re-direction of an antenna may help the situation. A redirection will of course also affect the interference situation in the network,
and should be carefully evaluated before implementation.
By down tilting the antenna (either mechanically or electrically), the coverage
area can be reduced, and in particular the spillover coverage can be
removed. Antenna down tilting thus affects the cell plan both with regard to
cell borders and interference. Down tilting can reduce the interference in cochannel or adjacent channel cells as well as in the cell itself. In addition,
down tilting gives a generally "calmer" behavior in the network, as the signal
strength becomes more concentrated to the area close to the site. The major
drawback of having too much down-tilt, is the risk of a loss in overall
coverage. The result of mechanical and electrical down tilts is different, and
this aspect should be considered when deciding the tilt angle. Commonly,
the mechanical downtilt implies a sidelobe boost effect, which does not
appear with electrical downtilt.

4.11

FREQUENCY PLANNING
Major interference problems require a change of frequency in one or more
cells. For a less severe problem, antenna down-tilts can help the situation.
Minor interference problems can be eliminated or reduced by parameter
changes. Moving cell borders and/or changing the handover behavior (e.g.
smaller handover hysteresis and shorter filter lengths) can take care of local
interference problems.

22(39)

APPENDIX 1-RADIO PROBLEM ANALYSIS

The following sections contain flowcharts for solving various radio problems.
When the problem is identified the appropriate flowchart should be followed.
The analysis should follow the following steps:
1. Analyze the radio statistic reports in order to find the 5 10 worst
performing cells. Cells with a high amount of dropped calls, poor
handover success rate and/or suspected poor speech quality should be
prioritized. Cells with no traffic should also be prioritized.
2. When analyzing the statistics, the cells or BSCs should be compared with
each other in order to find the worst performing cells or BSCs.
3. Depending on what problem is found in the statistic analysis, the
corresponding workflow for problem analysis should be followed.
4. Check the following when a problem cell has been identified:
Have there been any alarms on the site during the period?
Are the site operational and the cells active?
Has there been any transmission problem?
Is the RBS properly configured? Check the configuration of the RBS
and compare to similar RBS.
Are the parameters properly set? Compare the parameter setting with
similar cells and check differences.
Is the site/cells affected by any known radio related problem such as
interference, lack of coverage etc?
Have any surrounding cells been halted or not received the proper
configuration due to problems?
Are external neighbouring cells defined properly in the MSCs, other
BSCs and RNCs?
Do the BA lists correspond with the defined neighbouring cells?
When was the concerned drive route driven last time? Performance?
Check thoroughly the problem log and previous change requests for
the concerned cell or cells.
Check interference and coverage predictions in Planning Tools.

23(39)

START
Analyze the radio statistics reports
Check overall system performance per BSC
Identify problem areas and

10 worst problem cells

Perform benchmarking
- Compare with other cells
and parts of the network and with the quality targets
Yes

Is the requirement
met?

Need to improve?
No

No

Yes

Identify and prioritize the problems

END
Yes

Previously known
problem?

Previous CRs
implemented?

No

Yes

No
Log problem in problem log

Need to improve?

No

Yes
Retrieve detailed statistics on the problem

END

Problem identified?
No
Initiate and perform further measurements e.g TEMS
drive -tests, CTR, MTR, NCS, MRR etc.
Perform a careful and detailed analysis
No

Problem identified?
Yes

Take actions to solve the problem (CR, HW CR)

Verify improvement by statistics (or drive tests)

No

Yes
Problem solved

24(39)

END

Log actions and report

In this section, some examples of how to work with common problems in

Initial Tuning are given:
Long SDCCH mean holding time
Short TCH mean holding time
SDCCH congestion
Poor SDCCH and/or TCH availability
Random accesses not approved
Low TCH assignment success rate
Dropped calls on TCH
Handover analysis
No or few handover attempts
Unsuccessful handovers
Obviously, many other problems might also occur, but these schemes
provide an insight in how to make analysis. In addition these described
problems are rather common and can thus be used as a reference.

25(39)

1. LONG SDCCH MEAN HOLDING TIME

Long SDCCH mean

holding time

Check TCH congestion

Congestion
on TCH?

YES

Add TCH capacity

YES

Perform SDCCH
1
redimensioning

NO

Check SMS performance

Many SMS
messages?
NO

Check BTS error log

HW fault?

YES

Swap & repair faulty HW

YES

Change frequency and

reduce interference

NO

Check random access performance

Check frequency plan

Perform drive test

Many false
accesses?
NO

END
1

SDCCH redimensioning can also be performed automatically and

dynamically with the feature Adaptive configuration of logical channels

26(39)

2. SHORT SDCCH MEAN HOLDING TIME

Short TCH mean

holding time

Check number of dropped calls

High dropped call

rate?

YES

Perform Dropped Call

Analysis

YES

Check handover
parameters, tune HO
relations if needed

YES

Check intra-cell
parameters

YES

Swap & repair HW

NO

Mechanical tuning

NO

Check handover performance

Many handovers
out from cell?

NO

Many intra-cell
handovers?

NO

Check HW

Faulty tranceiver?

NO

Perform drive test

Radio design in the area

according to plan?

YES

END

27(39)

3. SDCCH CONGESTION
D

SDCCH
congestion

Check channel configuration

Check HW
availabilty
Low
availability?

Same for all

cells in area?

YES

See TCH & SDCCH

availability

NO

Check site
position
YES

Location
area border?

YES

NO

Check and
increase CRH

Change location
area border

Check TCH
traffic
TCH
Congestion?

Change channel
configuration

NO

YES

Is cell
broadcast
used?

Avoid cell broadcast

if possible

YES

NO

Check traffic trend

Short term
traffic growth?

No activity

YES

NO

YES

Add TCH
capacity and/or
Assignment to
other cell or CLS

Check SDCCH mean holding time

NO

Long mean
holding time?

Check SMS activity

Many SMS
messages?

YES

Redimension
1
SDCCH

YES

Check HW and number

of false accesses

NO

Check SDCCH dimensioning

NO

Check periodic registration

Underdimensioned

SDCCH?
Too frequent
registrations?

YES

Redimension
SDCCH

NO
YES

Consider changing
registration interval
timers

END

NO

SDCCH redimensioning can also be performed automatically and dynamically with the feature
Adaptive configuration of logical channels

28(39)

4. POOR SDCCH AND/OR TCH AVAILABILITY

SDCCH & TCH

availability

Cell synth hopping?

YES

Check NUMREQBPC
(RLBDP), set to number
of channels

NO

Cell baseband
hopping?

YES

Check that NUMREQBPC

is set to SYSDEF and that
number of frequencies is
correct

YES

Replace & repair faulty

HW

NO

Check BTS Error log

HW problems?
NO

Check transmission

Transmission
problem?

YES

HW fault?

YES

Perform more
investigations

NO

NO

Capacity problem?

Check loaded SW

YES

Add transmission
capacity

NO

Change or repair
transmission equipment
Missing SW
correction?
NO

END

29(39)

YES

Contact NMC to
load correct SW

5. LOW RANDOM ACCESS SUCCESS RATE

Not approved
random accesses

Check BSIC allocation

Check frequency plan

Access burst from

another co-channel cell

YES

Change BSIC or
frequency plan

NO

Check cell parameter setting

MAXTA too low?

YES

Increase MAXTA

YES

Consider tilting or
lowering site

YES

Increase SAE

YES

Reduce interference

NO

Check site location

High located site?

NO

Check SAE

Software file
congestion?
NO

Check ICM, run FAS if needed

Check if unknown access code

High noise floor?

NO

END

30(39)

6. LOW TCH ASSIGNMENT SUCCESS RATE

Low TCH
assignment
success rate

Check TCH congestion

Congestion
on TCH?

YES

Add transceivers and/or

tune Assignment to other
cell and CLS.

NO

Check output power, check if cell reaches

too far by TA distribution with MRR

Low output power?

YES

Check output power

parameters

Wrong parameter
setting?

NO
NO

Check BTS Error Log

Check signal strength of

BCCH and TCH
NO

HW fault?

YES

Contact NMC to
swap & repair HW

Low SS for call

access?

NO
YES

Check coverage plots

Adjust TCH output

power
Perform drive tests

Dominant
server exists?

NO

Add BTS

YES

Check interference with

ICM, FAS and/or MRR

Disturbance
on SDCCH or
target TCH?
NO

END

31(39)

YES

Improve & adjust

frequency plan

YES

Rectify parameters

7. HIGH TCH DROP CALL RATE

Dropped calls on TCH

High ICM?

YES

Check frequency plan,

external interferers
and/or filters

YES

Check site location &

TALIM

YES

Perform handover
analysis

YES

Remove site or change

frequency

YES

Swap & repair HW

Check locating parameters

NO

High timing
Bad parameter
setting?

YES

Correct parameter
setting

advance?
NO

Check lost handovers

NO

Check radio network features

Power regulation
used properly?

NO

Correct power regulation

parameters

Most dropped calls

during handover?
NO

YES

Check site position

Check output power

Power balance?

NO

Adjust output power

Site covering
too much?
NO

YES

DTX used?

Check BTS error log

NO

Introduce DTX
HW fault?

YES

Frequency
hopping used?

NO

Activate frequency
hopping

NO

Check link quality

YES

Check dropped call

reason

Bad quality?

Transmission fault?

YES

Perform interference
analysis with MRR
and/or FAS

Low signal strength?

YES

Perform low signal

strength analysis

NO

Missing neighbours
suspected?

32(39)

Perform link
investigation

NO

Add site

NO

Best server exists?

NO

YES

YES

Check MS fleet
Perform drive tests

YES

Run NCS

Perform MTR/CTR/MRR
etc. recordings

NO

Perform site survey

Check antenna installation

END

8. HANDOVER ANALYSIS
E

Handover
analysis

Select worst relation

External?
Check successful handovers per cell

YES

NO

Start Inter-BSC/MSC
analysis

NO

Next cell

Success below x%?

NO

High ratio of
urgency
handovers?

High ratio of lost

handovers?

High ratio of
retensions?

YES
YES

Check handover activity

YES

Check up- and down link interference with

MRR, FAS ICM, TEMS
More than x
handovers
performed?

NO

Check frequency plan

YES

Check handover related parameters such as relations,

missing relations (using NCS), BA-list, BSIC,
hysteresis, offsets, etc.

Check site location

Important cell?

NO

Check if K or L locating is used

Check if many ping-pong

handovers

YES

Check handover flow

Check if assignment handovers
are used
Uneven flow?

Check if cell has HW problems

YES

Check if congested target cell

NO

Difference in
performance in outand incoming?

Check SAE

YES
NO

Focus on bad direction

33(39)

Perform measures to
improve performance

END

9. NO OR FEW HANDOVER ATTEMPTS

No or few
handover
attempts

Check neighbouring cell relations,

use NCS if necessary

Unnecessary
neighbouring cell
relations?

YES

Remove unnecessary
relations

NO

Check locating parameters

Unfortunate
parameter setting?

YES

Rectify parameter
setting

NO

Check BTS definition

BTS defined but

not in service?

NO

END

34(39)

YES

Rectify parameter
setting

10. LOW HANDOVER SUCCESS RATE

Unsuccessful
handovers

Delayed handover
decision

Check congestion
performance

TCH congestion?

YES

YES

Check handover
parameters

YES

Introduce unused
features

YES

Improve coverage

YES

Reduce interference for

potential candidate

NO

Add TCH capacity

Check use of radio

features

NO

Check SAE setting

SW congestion?

Are all radio

features used?
YES

Increase SAE
NO

NO

Check coverage

Check neighbouring cell definitions

Wrong cells
defined?

YES

Check interference, run MRR

and/or FAS; check ICM

Remove incorrect
definitions

NO

Missing
neighbours?

Perform drive test

YES

Run NCS, add

missing relation
Timer expiry after
MS is lost?

NO

Too many
neighbours?

YES

Remove unnecessary
relations

YES

NO

Too many
measurement
channels?

Low SS on cell
border?

Review and correct the

defined MBCCHNO
NO

NO

NO

Check Locating parameters

Bad quality?

Strange or corrupt
parameter setting?

NO
B

35(39)

YES

YES

Rectify parameters

Check BTS Error Log

HW fault?

YES

Swap & repair HW

YES

Improve transmission

YES

Change feeder

YES

Rectify tilting

YES

Change antenna
position

YES

Rectify installation

NO

Check link quality

Transmission fault?
NO

Perform site visit

Check antenna
installation

Antenna connected
to wrong feeder?

NO

Incorrect downtilt?
NO

Hidden antenna?
NO

Bad antenna
installation?

NO

END

36(39)

11. LOW LLC THROUGHPUT

Low LLC data throughput

Communication problem
on TCP/IP-level?

YES

Not a radio-related
problem.

NO

Bad Coverage?

YES

Log the area as bad tp

due to lack of coverage

YES

Improve the frequency plan

NO

Bad interference?
NO

Is the optimal Link Quality

control mode used?

NO

Change it to:
LA, or IR, if hardware is
capable

YES

Is there congestion or
very high utilization??
NO

END

37(39)

YES

Reduce the TCH utilization

or add TRUs

12. BAD PACKET DATA RESELECTION PERFORMANCE

Bad packet data reselection performance

Bad Coverage?

YES

Log the area as bad tp

due to lack of coverage

YES

Improve the frequency plan

NO

Bad interference?
NO

Reselection parameter
settings OK?

NO

Change to the
recommended parameter
settings

YES

Is LQC switched on in
the BSC?

NO

Switch on LQC, using the

recommended settings, if
hardware is capable

YES

Is LQC used in all

cells?

NO

Check that LQC is used in all

cell with the recommended
settings, if hardware capable

NO

Is there congestion or
very high utilization?

NO

END

38(39)

YES

Reduce the TCH

utilization or add TRUs

13. GSM-UTRAN HANDOVER PROBLEMS

GSM-UTRAN Handover Problems

Check UMTS HO is on
Signs of UMTS?

NO

e.g. COEXUMTS, FDDMRR, FDDARFCN

YES

Handover take place at all?

NO

Check relation settings

e.g. UTRANID, FDDMRR, FDDARFCN

YES

Strange Handovers?

YES

Check the triggers

e.g. QSC, QSCI, ISOLEV, MRSL,

NO

Low success rate?

YES

Check coverage in the two

networks, adapt the UMTS
HO triggers. Also check
GSM interference

NO

Still problems?

NO

END

39(39)

YES

Check the UMTS side.