Optimisation Process

Version 1.0

InternationalCellularInfrastructureGroup

OPTIMISATION PROCESS FOR TMN

GSM NETWORK IN
SOUTH LISBON
( A4 Project )

17th April 1999

System Engineering
India
Motorola India
Randeep Raina
Abstract
This document emphasizes on the methodology to be adopted for the optimization of
the expansion project in TMN GSM network in South Lisbon and to achieve the
greater Quality of Service.

Version 1.0

Page 1
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

REVISION HISTORY
Issue Date

Reason for Change

1.0

Initial Issue. No changes

17/04/99

REFERENCES

Page 2
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

TABLE OF CONTENTS
1.INTRODUCTION......................................................................................................
2.EXECUTIVESUMMARY........................................................................................
3.OPTIMISATIONPHILOSPHY...............................................................................
3.1BASICOPTIMISATIONPHILOSPHY...............................................................................
3.2ADVANCEDOPTIMISATIONPHILOSPHY......................................................................
4.OPTIMISATIONMETRICS....................................................................................
4.1SOFTWAREOPTIMISATIONTOOL................................................................................
5.BASICOPTIMISATIONPREREQUISITES........................................................
5.1PERSONELREQUIREMENTS.........................................................................................
5.2CHANGECONTROLPROCEDURE.................................................................................
5.3DRIVETESTROUTES...................................................................................................
5.4RFDESIGNANDDATABASEPARAMETERS.................................................................
5.5SWITCHTESTNUMBER...............................................................................................
5.6CUSTOMERFEEDBACKPROCEDURE...........................................................................
5.7TIMESCALES................................................................................................................
6.BASICOPTIMISATIONPROCEDURE................................................................
7.BASICOPTIMISATIONTOOLSANDSOFTWARE..........................................
7.1OMC...........................................................................................................................
7.2TEMS...........................................................................................................................
7.2.1Gims.....................................................................................................................
7.3RFPLANNINGTOOLNETPLAN.................................................................................
7.4MAPINFO.....................................................................................................................
7.5AINTERFACEANALYSER............................................................................................
7.6TESTMOBILES............................................................................................................
8.ADVANCEDOPTIMISATIONPREREQUISITES.............................................
8.1SUBSCRIBERS..............................................................................................................
8.2PERSONELREQUIREMENTS.........................................................................................
8.3TIMESCALES................................................................................................................
9.ADVANCEDOPTIMISATIONPROCEDURE.....................................................
10.ADVANCEDOPTIMISATIONTOOLSANDSOFTWARE.............................
10.1EXPERTADVISORINTELLIGENTOPTIMISATIONTOOL...........................................
10.1.1TargetOptimisationSolutions...........................................................................
10.1.2FrequencyPlanOptimisation...........................................................................
10.1.3TopologyOptimisation......................................................................................
10.1.4FutureEnhancements........................................................................................
10.2SOTSOFTWAREOPTIMISATIONTOOL...................................................................
10.3CELLANALYSISTOOLVER2(CAT2).....................................................................
10.4MARSSTATISTICALDATAANALYSIS...................................................................
11.TRAINING................................................................................................................

Page 3
Motorola Confidential Proprietary

Optimisation Process

1.

Version 1.0

INTRODUCTION

This document describes in detail the process of optimisation. The document covers
the traditional methods of optimising a cellular system in the basic optimisation section.
It then introduces the improvements being made to the Optimisation process with the
introduction of new tools and techniques in the advanced optimisation section.
The optimisation process is continually changing with the updates in technology and
the tools available, some of the tools refered to in this document are extremely new
and therefore at present no professional technical documentation or product literature
exists within Motorola. The tools however are functional and have therfore been
refered to in the document.
The process refered to in this document should not be taken as the only way of
Optimising a GSM system, as with all processes they are continually being improved
with new tools and techniques. The basic strategy remains however in that
optimisation is a process of improving the quality of a cellular network.

Page 4
Motorola Confidential Proprietary

Optimisation Process

2.

Version 1.0

EXECUTIVE SUMMARY

Optimisation can be an expensive omission from a network operators portfolio.

Without optimisation the network will degrade from the commissioned state. This
is because the network changes radically as the traffic on the GSM system grows, and
the snap-shot optimisation will not keep pace with these changes. Without
optimisation the system will suffer poor call quality, many dropped calls due to
interference and inaccurate parameters resulting in poor handover performance.
The return on investment will be reduced as less subscribers can use the cell. The
potential for losing subscribers to another network (churn) is increased due to
subscriber dissatisfaction as a result of their subjective observation of network quality.
Implementing an optimisation cycle impacts the total cost of ownership of the GSM
system and is often a hidden cost. Optimisation requires dedicated resource to tune the
network as the traffic on the system grows and to ensure that particular test routes
operate efficiently, not to the detriment of the rest of the cell coverage area.
The flowchart shown in figure 2.1 summarizes the basic optimisation process.
By constructing an understanding of the drive-test process cycle and applying
radically new ideas it has been possible to provide dynamic and potentially automatic
optimisation at an unparalleled rate (cells/day) with improved accuracy, without the
requirement for drive testing.
The solution takes advantage of the Motorola (M-Cell) intelligent base-site
architecture and routes optimisation information to either the OMC-R location or
locally to a BSC-based information collection system. By collating this information
centrally and using cellular database information, such as cell position, network
frequency plan and coverage areas, it is possible to provide comprehensive
optimisation suggestions.
By deploying Intelligent Optimisation solutions, network operators can undertake
optimisation based on traffic load, using actual subscriber call information to provide
optimisation information.
The flowchart in figure 2.2 summarizes the the advanced optimisation process.

Page 5
Motorola Confidential Proprietary

Optimisation Process

3.

Version 1.0

OPTIMISATION PHILOSPHY

Setting the parameters that control mobility have equal importance to the frequency
plan. In GSM there are a series of parameters that control mobility. Tuning these
parameters for improved GSM operations, in terms of maximising calls carried,
improved handover performance and increased call success rate, is termed
Optimisation.
The aim of optimisation is to maximise the Quality of Service of the GSM
network. In order to do this you need to measure the QOS, compare the measured
value with the desired value, and then take steps to correct the causes of any
deviations from the desired value.
3.1

Basic Optimisation Philosphy

It is typical that during optimisation the choice of cell frequency, the neighbour list and
any margins/timers will be examined and optimised for improved performance.
Optimisation is traditionally undertaken immediately after the commissioning stage, or
after a new frequency plan in a deployed network. Several teams of field personnel
drive around each site making a number of calls,concentrating on testing the
handover between each cell. Each call is investigated and any potential problems
resolved by classical fault-reasoning/resolution methods. This methodology,
termed drive-testing is used by most network operators as a tried and tested way
to improve their network.
Optimisation is divided into the following criteria when tuning a cell:
-frequency plan
-topology (neighbours)
-cell dynamics (handover timers and margins)
-real-estate (antenna tilts etc.)
Only Basic optimisation can be done in the network, if the network does not have a
substantial amount of active subscribers. For statistical data to be used as in the
advanced optimisation process, the network must be carrying a significant amount of
traffic
3.2

Advanced Optimisation Philosphy

Before optimisation is started the use of the advanced toolset in the RF design process
should reduce the amount of optimisation required, this will be done by simulating the
network, prior to intergration or the enhancement of the network, in Handsim. The
network will be set up to perform optimumly as per the simulation. As the network
grows and more information is feed back into the tools the better the accuracy of the
simulation
Motorola has developed advanced technology and a new series of GSM features that
supersede the current drive-testing methodology. By constructing an understanding
of the drive-test process cycle and applying radically new ideas it has been possible
to provide dynamic and potentially automatic optimisation at an unparalleled rate
(cells/day) with improved accuracy, without the requirement for drive testing.
Motorola continues to develop the processes of intelligent optimisation, the intelligent
optimisation tool is a product available now as a stand alone tool and has been put into
the Motorola Roadmap to become fully intergrated into the network as an optional
feature in the future.

Page 6
Motorola Confidential Proprietary

Optimisation Process

4.

Version 1.0

OPTIMISATION METRICS

The quality of the network can be measured through the statistics generated
from the network, these are available through the OMC (Operations and
Maintenance Center) These statistics are used to generate the key metrics. These
metrics will then be measured against the required metrics as agreed between the
operator and Motorola. Motorola believes this is the most effective way of
monitoring the performance of the network as the metrics are derived from all of the
users of the network.Drive test statistics, although a useful indication of network
quality, do not really emulate the typical user of a mobile network, as they are only a
very small sample of the total calls on the network, thus the statistics obtained from the
whole network through the OMC are a more acurate assesment of the quality of the
network.
The following metrics require an agreed target between the operator and Motorola
to measure the performance of the network.

Dropped Call Rate

Handover Success Rate
Overall RF Loss Rate - TCH & SDCCH RF loss combined
TCH Assignment Success Rate
Call Success rate
TCH Blocking Rate

If the agreed metric cannot be reached due to circumstances outside the control of
Motorola, this will be brought to the attention of the operator and with agreement
removed with respect to the overall acceptance metrics as agreed between Motorola
and the operator.
The typical targets set between operator and Motorola are

Dropped call Rate

Handover Sucess Rate
RF Loss Rate
TCH Assignment Rate
Call Sucess Rate
TCH Blocking Rate

4.1

Less than 2%
> than 95%
Less than 3%
> than 95%
> than 95%
To the RF design criteria (Usually 2%)

Software Optimisation Tool

Motorola have developed a software tool for analysing the performance of the network
(SOT - Software Optimisation Tool).
Motorola use this tool to provide the optimisation metrics required to measure the
performance of the network.
5.

BASIC OPTIMISATION PRE-REQUISITES

5.1

Personel Requirements

Page 7
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

The intention here is to show the engineers required in the optimisation process and
not the amount of engineers. The amount of engineers will depend on the size of the
network, the amount of area to be covered and the roll out schedule.
Once the above information is known a more precise proposal can be done detailing
specific numbers of people required.
The engineers required in the optimiation process is as follows

5.2

Type of Engineer

Functions

OMC Engineers
Database Changes.
Drive Test Engineers
Antennae and database Changes.
Performance Engineer
figures.
BSS Mtce Engineer
Antennae Riggers
Optimisation Control
Presentation of Quality Metrics,
control Management.

Statistical feedback, Network availability,

Drive Testing, Performance evaluation,
OMC Statistical Analysis, Quality Metric
Fault Identification and Clearance
Antennae Azimuth and downtilt changes
Management responsibilities of all staff,
Technical Guidance to Engineers, Change

Change Control Procedure

A procedure to manage changes within the network is required to maintain the

integrity and quality of the network.
The procedure ensures all changes required to improve the quality of the network are
valid and that precautions against failure of the change have been considered.
This procedure below is the change control procedure and ensures changes on the
network have been fully evaluated before implementation and that each change has a
test plan and a back plan in case of failure..
5.3

Drive Test Routes

Before drive testing is started drive test route need to be agreed with the operator.
These routes should cover the following points before agreement is reached.
All sites and sectors should be tested within the drive test routes at least once.
All major roads and highways should be tested at least twice within the agreed
routes.
All cells should be tested for handout and handin within the routes if possible.
The routes should be approxiamately 2 - 3 hours in duration. This is required to
manage the data collected.
Routes of major importance should be identified prior to starting and should be
driven first. i.e Airports to the city center
5.4

RF Design and Database Parameters

Beforre Optimisation can begin the RF design and database parameters will be
required. This is normally presented in spreadsheets from the RF planning and Datagen
tools.
Page 8
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

This information is required to help the drive test engineers to identify possible sources
of interference. The information is also used to evaluate possible changes to improve
the quality of service.
5.5

Switch Test Number

To aid in the optimisaqtion of the network a test number is required within the MSC.
This is required for the drive test teams to access from the test mobiles in the car, a test
number in the MSC is preferred as this removes any contact with the land system, so in
the event of any dropped or unavailable calls they will all be in the mobile network .
5.6

Customer Feedback Procedure

A procedure is required to feed back customer information on the performance and

coverage of the network. The recieved information is used to target areas of
optimisation and to verify coverage against the RF design.
The information feed back is also used in the growth of the network by identifying
were subscribers are using there mobiles.
The process of feeding information back is an internal process for each operator,
Motorola however have closely worked with customer care departments to assist in
providing information as to the coverage and quality of the network. The format of
providing information is usually graphically based around the Mapinfo GIS software,
this provides coverage maps from the RF planning tool and live data gathered from
drive test data. This support can be provided to any future customers.
5.7

Timescales

The optimisation process never comes to an end within a network, the process usually
evolves into the performance engineering department as the network evolves.
The rate of growth in most cellular networks means the network continues to expand
with new sites or more capacity with different RF design techniques, this will always
mean that optimisation will be required to maintain and improve the quality of the
network.
The initial optimisation of a system is somewhat variable depending on many factors i.e
amount of sites, area to be optimised, road traffic density e.t.c. However as an
indication until the precise information is known on the network it takes
approxiamately 2-4 weeks for one drive test team to optimise a BSC, a BSC usually
consists of about 14 - 18 sites at with present software load.
If a faster optimisation process is required more engineers will be required, another
team would see a reduction of 10 days in the process.
6.

BASIC OPTIMISATION PROCEDURE

The optimisation process starts immediatly the network is brought into operational
service or an enhancement takes place on the network. During times of little change to
the network Performance Engineering monitor the quality of the network and will seek
assistance from Optimisation Engineers if the quality of the network begins to fall.
The procedure below is the basic method for Optimising a system and can be modified
to each operator to maximise results.

Page 9
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

1. Before Optimisation starts all of the pre-requisites must have been done or be in
place. There must be a change control procedure in place with the operator that
Motorola are familiar with, the RF design and Database parameters must be
presented to the Optimisation control manager. All drive test teams must have test
mobiles and SIM cards provided by the operator. Note - The Optimisation control
personel are usually situated with the OMC personel for maximum effieciency as
OMC and Optimisation control are continually passing information between each
other.
2. The drive test routes must be agreed with the operator and a priority set on the
routes for testing.
3. The drive test teams make test calls on the network of 2 minute duration with a 15
second break between calls to the MSC test number with the Test Mobile
equipment (TEMS) and all data is logged to the computer, location information is
also taken using a GPS reciever to provide location information.
4. The drive test routes are usually 3 - 4 hours in duration so that the data collected
can be managed.
5. During or after completion of the drive test route analysis of the data collected
is done to find areas of dropped or noisy calls. This can either be done on the
RF planning tool or using the GIMS software in the field
6. The results of the drive test, including analysis is passed to Optimisation Control for
performance logging of the route.
7. Should the analysis of the route indicate problems of either dropped or noisy
calls ,with the aid of the RF design and Database parameters an assesment is made
to identify the possible source of interference causing the noisy or dropped call. If
a call is dropped and no interference is present a retest is made in the same area, if
the scenario of the dropped call can be repeated, information of the problem cell
should be obtained, this will then be escalated to Optimisation control to seek
assistance from the BSS maintenance engineers to investigate the cell dropping
calls.
Note - To assist in confirming possible sources of interference there may be a
requirement to remove the suspected interfering channel. This would be done via
the optimisation control engineersf. The suspected interfering carrier would be
removed temporarily from service and test calls made again in the problem area,
this would show if the interference had been removed. The process for
temporarily removing carriers would have to be agreed with the operator, this
usually varies as to the importance of the cell as to what time of day it can be
taken out of service.
8. After conformation as to what is causing the problem with the drive test route, the
drive test engineer will attempt to find a solution to the problem. This can be one
of a number of possibilities i.e Power Change to BTS, Frequency Plan change,
Neighbor addition required e.t.c.
Note - In the case of a frequency plan problem, this is usually escalated through
Optimisation Control to the RF design engineer to find a solution to the problem.
The RF designer and Optimiser for an area are usually the same engineer in
Motorola, this has continually proven to be the most efficient method of
improving the quality of the network with respect to problems with the frequency
plan of the network.
Page 10
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

9. Once a possible solution to the problem has been found it may be possible in some
circumstances to immediatly attempt the solution via the OMC, this usually relates
to minor database changes and adding neighbors. The solution is implemented and
proven immediately. If the problem is rectified the change remains in place and a
change request is raised for the solution for the purpose of keeping records of all
changes in the network. If the solution requires a major database change or
antennae work a change request must be raised via the Optimisation Control
Engineers. After the solution is implemented a retest of the problem area is
carried out to confirm the problem has been solved.
10. In the event of the problem not being solved alternative solutions may be
attempted, this process continues until it becomes immpossible to find a solution.
At this point the problem is discussed with the operator as to the reasons that the
problem cannot be solved for example the solution may require a new cell to be
built, clearly this is beyond the scope of optimisation. If the operator is in
agreement this particular problem will be removed from the drive tests until such
time a solution is implemented.
11. Steps 3 to 10 are repeated throughout the system until such time that all routes
meet the required metrics or no further improvement can be made due to
circumstances outside the control of Motorola.
7.

BASIC OPTIMISATION TOOLS AND SOFTWARE

7.1

OMC

The OMC is an integral part of a GSM system, its relationship to the Optimisation
process is to provide statistics for the quality metrics and information on the status of
the network.
7.2
Tems
Tems is the drive test mobile and software from Erisoft. The kit consists of a laptop
P.C, an Ericsson GH688 test mobile and a GPS reciever for positioning information.
7.2.1 Gims
Gims is the graphical display software associated with Tems, it displays the drive test
routes graphically on a map of the drive test area. It is especally good at providing
information to customer care and marketting departments.
7.3

RF Planning Tool - Netplan

An RF planning tool is required in the Optimisation Process for displaying drive test
routes for analysis, modifications to the frequency plan and antennae azimuths and
downtilt changes.
Motorolas RF planning tool is Netplan.
7.4

Mapinfo

Mapinfo is a GIS software tool, it is used to display drive test data for analysis and to
produce Optimisation reports in a clear and easy manner.

Page 11
Motorola Confidential Proprietary

Optimisation Process

7.5

Version 1.0

A interface Analyser

An A interface analyser i.e Siemens K1103 tester, is required to analyse the A interface
for possible messaging problems. This tool is required to prove areas of dropped calls
when there are no interference problems. It can also be used to identify faulty handover
processes between the BSS and MSC.
7.6

Test Mobiles

Test mobiles are an invaluable source of information, all field engineers should be
equipped with a test mobile to identify problem areas.
The test mobile should be capable of giving the recieved signal level, RXQual value,
Cell I.D and six neighbors with rxlevels.
8.

ADVANCED OPTIMISATION PRE-REQUISITES

The advanced optimization toolset developed by Motorola will be required to

undertake the advanced optimizations procedure in the network.
8.1

Subscribers

To gather meaningful data for the advanced optimisation tools the network should
have a substantial amount of traffic being generated by subscribers on the network.
8.2

Personel Requirements

The type of engineers required will remain the same as the requirements in the basic
optimisation pre-requisites. There will however be a requirement for extra performance
engineers to analyse data gathered from the intelligent optimisation tool,the Call Trace
Product Tool and the Cell Analysis Tool .
The requirement for drive test engineers will still be valid for verification purposes, but
a there should be a signifigant reduction in the amount of drive test engineers required.
The reduction will be based on the amount of advanced tools available in the network
and the timescales involved.
8.3

Timescales

As there is typically no requirement for drive testing in the advanced optimisation

process, the time taken to optimise the network is reduced signifigantly.
This reduction will depend on the amount of advanced tools available, the size of the
network and the roll out plans of the network.
As a comparison with basic optimisation for a BSC it should take approxiamately one
week to optimise as opposed to 3 - 4 weeks for the basic optimisation process.
9.

ADVANCED OPTIMISATION PROCEDURE

The advanced optimisation procedure for a network is as follows

1. The Motorola advanced OMC tools should be loaded onto all OMCs
2. The analysis of these tools will identify the worst performing BSCs in the network.
Page 12
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

3. Intelligent Optimisation is then carried out on the worst performing BSCs first.
4. The intelligent optimisation tool is usually deployed at the BSC site which serves
the area being optimised. This is required to extract the data via the A interface
links to each BTS.
5. Measurement report data is collected via remote nodes at the cell sites and sent to
the Intelligent Optimisation Tool over the A interface links.
6. The Intelligent Optimisation tool analyses the data and can identify problem areas in
the network.
7. If problem areas are identified then changes will be required to the network to
improve the problem areas and thereby improve the quality of the network.
8. Steps 3 to 7 are then repeated until the quality of the network reaches the objectives
set in the optimisation metrics agreed between Motorola and the operator.
10.

ADVANCED OPTIMISATION TOOLS AND SOFTWARE

10.1

Expert Advisor - Intelligent Optimisation Tool

Intelligent Optimisation is an optional product for the OMC Expert Advisor or can be a
stand alone product. Where deployed, it will:
Automatically identify optimisation issues to determine which cells require
optimisation.
Provide the necessary user interface to set up the scope of the optimisation
Direct the operation of the Intelligent Optimisation system i.e. Plan and schedule
data collection and analysis
Provide Optimisation recommendations to the Operator for final analysis
Provide C/I and C/A Matrices in a format for import to a planning tool
Provide accurate Performance statistics before and after the optimisation to monitor
the improvement in the network.
Provide facilities to start and stop the IOS processes
Provide facilities to view and change optimisation change requests
Link to the Expert Advisor on-line help system.
10.1.1 Target Optimisation Solutions
The following is a list of the solutions that are candidates for the first release of the
product.
10.1.2 Frequency Plan Optimisation
The frequency plan is the primary cause of RF sub-system problems, since a nonoptimal plan will produce many coverage "holes" and significant co- and adjacent
channel interference.
Page 13
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

Providing an optimal frequency plan will facilitate improved network performance.

The mechanism by which the frequency plan will be updated (iterated) is via the
generation of a Carrier-to-Interference channel (C/I) and a Carrier-to-Adjacent (C/A)
channel matrix. This is a prioritised list of each source cells interfering neighbours. A
new frequency plan is generated by processing this C/I and C/A matrix in conjunction
with spectral availability. For completeness since the generation of the iterated
frequency plan requires subscriber measurement, for the first plan the system will use
the propagation prediction-based frequency plan as the base-line and then iterate to
converge on an optimal and "best compromise" solution.
The iterated solution will encompass the subscriber usage within its data. This means
that the frequency plan will be statistically valid for the majority of the cells users. This
is in contrast with the traditional Drive Test method where routes are pre-determined
as representative without the benefit of correlation with subscriber usage patterns.
10.1.3 Topology Optimisation
Once the frequency plan is updated the next influence on RF sub-system performance
is the network topology. The topology encompasses the relationship that the source
cell has with its surrounding neighbour cells.
Clearly, there are three possible conditions that can exist for optimisation of topology:
i. No problems exist.
ii. The topology is incomplete, i.e. a neighbouring cell is missing from the topology and
if entered may reduce dropped calls since an appropriate handover will be undertaken.
iii. The topology is "over-complete", i.e. the topology has redundant elements where
handovers are not undertaken. This is not a significant issue if the cell is not heavily
utilised since the processing associated with each neighbour is not significant.
However, in a busy cell with many neighbours, the redundant link could be utilised by a
true neighbour.
The topology is modified in many different ways, but in all cases the topology
modifications are directed to increase subscriber call satisfaction by reducing the poor
call quality. In GSM, the mobile phone is the source of neighbour information since up
to 6 neighbour cells are reported. Over a period of time, all the frequencies can be
scanned. The neighbour information is then processed to add the missing neighbours
and remove the redundant links.
The process of scanning frequencies is aided by the "Test Neighbour" feature. It is
envisaged that test neighbours will be incorporated into the topology to aid both
frequency planning and topology optimisation. In addition, since new neighbours are
only identified by their BCCH ARFCN / BSIC combination, propagation information is
required to identify the neighbour GSM Cell Identity for the neighbour list.
10.1.4 Future Enhancements
In addition to the above solutions Motorola is investigating the addition the following
solutions to the Intelligent Optimisation Tool:
Location Area Code (LAC) Optimisation

Page 14
Motorola Confidential Proprietary

Optimisation Process

Version 1.0

Cell Dynamic Optimisation

10.2

SOT - Software Optimisation Tool

The SOT tool is a software package that analyses BSS statistical data stored on the
OMC. The tool provides statistical metrics for measuring system performance as well
as information on poorly performing cells.
10.3

Cell Analysis Tool Ver 2 (CAT2)

The CAT2 tool is a software package that analyses BSS statistical data stored on the
OMC. The tool profiles the statistics against preset profiles input to the tool for each
cell. This process is known as footprinting a cell. Should the analysis of the statistics
show a deviation outside the footprint set in CAT2 an alarm is raised on the OMC for
the attention of the OMC engineer.
10.4

MARS - Statistical Data Analysis

The MARS tool is a software package that runs on a unix system. The tool is used to
analyse long term data, upto 6 months worth of data can be analysed. The tool can be
used to provide growth plan information for the operator. The tool can also aid in the
fault identification process by analysis statistics recently gathered by the tool.
The tool can analyse all statistics available in the BSS.
11.

TRAINING

Motorola provide extensive training on its GSM infrastructure, this is done through the
Motorola Technical Training department.
As well as Motorola technical training, Motorola have a certification process for
System Engineers involved in the Optimisation of the network. This certification
consists of Motorola Technical training and on the job training with local System
Engineers who support the operator. The training will cover all tools and techniques
involved in the optimisation of the network, full certification of the operators engineers
will only be given when they are capable of performing all tasks involved in the
optimisation process.

Page 15
Motorola Confidential Proprietary