Agileto_Help_V7.19.

docx

Agileto ®
PRO Edition

Help
(Detailed User Guide - ver. 7.19)

Important remarks:

1) Agileto Help document (*.chm) is context sensitive. It means that while you are
running Agileto software tool you may press anytime the key F1 and this document
will open automatically at the right topic according with the context where you are
working in Agileto tool at that time.

2) The latest version of this document may be downloaded from here:

http://www.agileto.com/docs/Agileto_Help.pdf

3) You may get anytime online access to Agileto video tutorials from here:
https://www.youtube.com/playlist?list=PL6VEOXBhw1-D2ZMQxfQl-R8E_SqqXXvxP

Page 1 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Contents:
Agileto®.................................................................................................................................... 1
What is Agileto doing? ............................................................................................................ 3
PC requirements: hardware and software ................................................................................ 4
Before you start ........................................................................................................................ 5
How to install ........................................................................................................................... 8
How to start – getting the license ............................................................................................. 9
A) Get Licence On-Line ..................................................................................................... 11
B) Get Licence Off-Line ..................................................................................................... 14
C) Agileto GOLD EDITION .............................................................................................. 17
DEMO_PROJECT ................................................................................................................. 19
How to upgrade Agileto tool ................................................................................................. 22
Directory structure ................................................................................................................. 24
Modules available .................................................................................................................. 30
Database & GIS................................................................................................................. 30
1.1) Generate and update Agileto reference database (2G/3G/4G) .......................... 30
1.2) Generate MapInfo + GoogleEarth (2G/3G/4G) cells/sites Objects .................. 40
1.3) Network boundary: ‘Border Cells’ detection .................................................... 48
1.4) View Active database / MapInfo / GoogleEarth representation(s) ................... 52
Network Audit (reports & proposals) ................................................................................ 54
2.1) OMC (snapshot *.xml/*.txt): Audit and Sanity Check ..................................... 54
2.2) 3G(PSCs) / 4G(PCIs) allocation: Audit and Optimization ............................... 72
2.3) 2G(BCCHs) allocation: Audit and optimization ............................................... 78
2.4) Network comparison between two OMC dump files ........................................ 84
Neighbors Visually representation and converters ........................................................... 99
3.1) OMC (snapshot) <-> MapInfo & Google Earth converters .............................. 99
3.2) Neighbors database -> MapInfo & Google Earth converters .......................... 107
3.3) MapInfo Neighboring tool (3G –> 3G or 3G –> 2G) ..................................... 115
3.4) ANR: Automatic Neighbors Relation (2G/3G/4G) ......................................... 120
Network Optimisation (audit and proposal).................................................................... 129
4.1) Network Optimisation based on Drive Tests .................................................. 129
4.2) Network Optimisation based on Call Traces ................................................... 188
4.3) Process Drive Test log files (NEMO, TEMS, etc) .......................................... 205
4.4) Neighbors Optimisation based on PSCs Detected (*.txt)................................ 213
Investigation based on Cells KPIs in MapInfo & GoogleEarth representation ............. 217
5.1) Generate MapInfo & GoogleEarth cells/sites objects based on KPIs values .. 217
Annexes................................................................................................................................ 232
Agileto reference database [MobileNW_Config.xls] ...................................................... 232
Drive Tests measurements (scanner/mobile) file ............................................................ 238
KPIs file structure and format ......................................................................................... 246
PSCs detected file format ................................................................................................ 247
OMC 2G network file format ........................................................................................... 248
MapInfo Neighbors export file ........................................................................................ 249
MapInfo Neighbors import file ........................................................................................ 250
External Neighbors declarations file............................................................................... 251
Agileto Contact Details ........................................................................................................ 253

Page 2 of 253 www.agileto.com

Agileto_Help_V7.19.docx

What is Agileto doing?

Agileto is a piece of software running on Windows platforms which can help the RF
and OMC engineers to audit, analyse and optimise a mobile telecommunication
network (2G/3G/4G) being vendor independent. For more details click here.

It works with input data placed at the intersection between different domains like:
 RF Planning
 OSS maintenance
 OSS Call Traces
 OMC monitoring
 Drive Test Optimisation

It is based on intelligent algorithms (developed after a lot of working experience ~

more than 20 years) which allow the end user to quickly clasify and solve a technical
problem which can affect a mobile telecommunication network.

Due to its usage’s simplicity and efficiency in solving the most often detected
problems it is highly reccomended to be used especially during the roll-out or swap
projects where even not very skilled engineers can achieve very good results in a very
short time without requiring an extensive training.

There are two versions of Agileto software tool, as following:

 GOLD Edition: Limited functionality, no more developing, focus only on 3G;
 PRO Edition: Profesional version, continuos update, supporting 2G/3G/4G;

Although this document is oriented to support Agileto PRO Edition, it may be used
for Agileto GOLD Edition too, but with caution as far as some features have evolved
/ improved / emerged in PRO vs GOLD.

Please see below a quick overview about what Agileto is doing automatically:
o Output reports & mapping in MapInfo + Google Earth
(Sites & Cells + Neighbors + Drive Test + Call Traces + KPIs)
o OMC dumps Audit & Sanity check comparisons and verifications
o Inconsistency Cells parameters declarations
o Lack of coverage & quality areas
o Pollution areas
o Overshooters cells
o Cell Coverage areas (Top1 / ASet / Full)
o Missing neighbors (to be added)
o Non useful neighbors (to be deleted)
o Cross sectors / feeders
o Planning errors for 2G(BCCH) / 3G(PSC) / 4G(PCI)
o “Border cells” list evaluation (for optimization purposes)
o etc…

Page 3 of 253 www.agileto.com

Agileto_Help_V7.19.docx

PC requirements: hardware and software

 Recommended HW: Intel Dual Core with 1 GB RAM or more.

 OS: Windows XP, Windows Vista, Windows 7, 8, 10 and also on Windows
2003 server or Windows 2008 server.

Agileto® is an Windows application working in conjunction with other three

Windows applications:
 MS Office Excel (Excell 2000 or greater) -> mandatory,
 MapInfo (ver. 8 or greater) -> optional,
 Google Earth or Google Earth Pro version -> optional;

Important:
In order to benefit of all Agileto’s modules there is a pre-request that Excel, MapInfo
and Google Earth applications should be already pre-installed.

Notice:
In case that any libray (common Windows *.dll/*.ocx file) used by Agileto is missing
from your PC then during the installation phase that library will be downloaded and
and registred automatically (if your PC is connected to internet). In case that
automatically registration process fails you will get a warning message like the one
presented below indicating the missing / corrupted / not registred file.

This case you may register it (manually) very eazy, as following:

1.Download (*.dll / *.ocx) the missing file (ex: msxml6.dll) and store it at this path:
C:\Windows\System32\msxml6.dll
2. Open a DOS command prompt window:
Click on the Windows ‘Start’ menu then choose ‘Run’ and type cmd .
3. Into the new DOS window type the following command then press enter:
regsvr32 "C:\Windows\System32\msxml6.dll"
You should receive a confirmation message telling you that the file has been
successfully registred on your PC.
(click here to get guidance for troubleshooting when the above method failed)

Alternativelly, please contact us ([email protected]) or check topic on internet.

Page 4 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Before you start

You have to check that MS Office Excel, MapInfo and Google Earth applications
are already pre-installed on your PC (MapInfo and Google Earth are not mandatory
but they are recommended in order to benefit of all Agileto’s modules).

Also, you should have available (as inputs for different modules) the following files:
 OMC 2G/3G/4G network configuration file in one of the following formats:
*.xml, *.xcm or *.txt. Usually this is called a snapshot (dump) file exported
from OMC/OSS and the OMC Engineer has access to get this file. All the
telecom equipment vendors on the market are able to export their 2G/3G/4G
network configuration data into files formats like: *.xml, *.xcm or *.txt. For
this Detailed User Guide this file will be named - File #1.

Notice:
Agileto software tool is technology and vendor independent meaning that it is
supporting all the technologies (2G/3G/4G) as well as all the major telecom vendor
equipments (Ericsson/Huawei/Nokia-Siemens/Alcatel-Lucent/ZTE/etc) therefore it
will recognize automatically all the file formats and internal data organization
coming from any of the technologies and the vendors mentioned before.

 Excel (external database) file containing the following information (usually

exported from any Planning Tool or mobile operator database). The type of the
information necessary to be provided into these external Excel files is
mentioned below for each type of the network (2G/3G/4G). This information
contains mainly the positions (geographically coordinates) and orientations
(azimuths) related to the 2G/3G/4G cells and it is required in order to be able
to map the mobile networks into MapInfo/Google Earth applications. The
unique identification of the cells for each technology is given by the two red
elements as per presented below. Mandatory fields are presented below into
green background while yellow are optionally but recommended.

For 2G network For 3G network For 4G network

o LAC o RncId o eNodeBId
o Cell_Id o Cell_Id o Cell_Id
o Long_WGS84 o Long_WGS84 o Long_WGS84
o Lat_WGS84 o Lat_WGS84 o Lat_WGS84
o Azimuth o Azimuth o Azimuth
o Sector ID o Sector ID o Sector ID
o Cell_Name o Cell_Name o Cell_Name

For this Detailed User Guide this file will be named - File #2.

The common references keys used for the data association between any
external Excel file and Agileto reference database (2G/3G/4G) are:

Page 5 of 253 www.agileto.com

Agileto_Help_V7.19.docx

 2G -> LAC + Cell_Id (or Cell_Name)

 3G -> RncId + Cell_Id (or LocalCell_Id or Cell_Name)
 4G -> eNodeBId + Cell_Id (or GlobalCell_Id or Cell_Name)

Also, some other optional additionally information (if they are available) may help
you while working with different Agileto modules. The additionally information is
used to update Agileto reference database (2G/3G/4G). For more information about
the (optional) additionally information which may be used please see the description
of the module M1.1 as well as the Annex describing Agileto reference database
[MobileNW_Config.xls].

Some of the Agileto’s software modules would require you to have available some
other additionally information / files as they are presented below.

 Call Traces in *.tab or *.xml format up to the 3G vendor equipment. The

purpose of getting these files is for the network optimization method (M4.2)
based on the Call Traces. The Call Traces files may be collected by the OMC
engineer after a dedicated command of launching so called “(Call Traces)” in
advance for a given period of time. In order to have the best Neighboring
optimization approach, the time recommended for the data collection of the
Call Traces (on all the 3G cells belonging to a dedicated geographically
region/area [cluster of ~ 20 NodeBs, or one / more RNCs] is 1 week (minimum
1 day). The recommended time for the Call Traces collection is suggested to be
1 week in order to ensure that the geographically traffic distribution related to
most of the mobile users is ‘collected’ representative from the statistically
point of view (as the traffic profile may change considerable from one day to
another day along to an entire week, especially during the weekend compared
with the weekday). For more information please check the description of the
module M4.2. For this Detailed User Guide these Call Traces files will be
named - File #3 (related to a sample file).

 Drive Test measurements file (*.csv). The purpose of getting this file is for the
network optimization method (M4.1) based on the Drive Test measurements
data collection. This file may result after performing a drive test while a GPS
device was attached to the drive test measurement equipment. This file
contains the raw data information related to the geographically position of the
drive test equipment (Lat/Lon collected continuously from the GPS) associated
with (three) basic metrics on each specific technology (2G/3G/4G)
representing the BCCH/PSC/PCI + two other metrics representing the signal
strength & quality collected from the scanner/mobile device used for the drive
test purpose. For more information regarding the structure/format of this file
please see the description of the module M4.1 as well as the Annex describing
the Drive Tests measurements (scanner/mobile) file. For this Detailed User
Guide this file will be named - File #4.

Page 6 of 253 www.agileto.com

Agileto_Help_V7.19.docx

 KPIs file (*.xls). The purpose of getting this file is for the mapping of the
network(s) 2G/3G/4G cells into MapInfo and Google Earth based on their cells
performance (KPIs). They may be represented in MapInfo and Google Earth
by having different colors and/or radius lengths according with their KPIs
values. These files may be provided by the Monitoring/Performance Engineers
with different KPIs/metrics collected/reported for a specific period of time. For
more information regarding the structure/format of this file please see the
description of the module M5.1 as well as the Annex describing the KPIs file
structure and format. For this Detailed User Guide this file will be named -
File #5.

 PSCs detected file (*.txt). The purpose of getting this file is for the neighboring
optimization method (M4.3) based on the PSCs Detected. This file may be
outputted as result after (either):
o Drive Test (mobile) export processing data,
o Monitoring reports,
o Call Traces export processing data.
For more information regarding the structure/format of this file please see the
description of the module M4.3 as well as the Annex describing the PSCs detected
file format. For this Detailed User Guide this file will be named - File #6.

 OMC 2G network export file (*.xls/*.csv). => Obsolate approach! This file is
no more used with this format since OMC 2G dumps are assimilated now with
the file #1 too, presented above.

The purpose of getting this file is for updating Agileto 2G reference database;
this operation may be performed directly by the module M1.1 (or indirectly by
the module M2.1). This file contains information exported directly from the
OMC (2G) related to the 2G network and it should contain as minimum the
following information regarding the 2G network cells:
 CID
 LAC
 BCCH
 BCC
 NCC
For more information regarding the format of this file please see the
description of the modules M1.1 and M2.1, as well as the Annex describing the
OMC 2G network file format. For this Detailed User Guide this file will be
named - File #7.

Page 7 of 253 www.agileto.com

Agileto_Help_V7.19.docx

How to install

To watch on-line the related video training for this purpose click on the link below:
Agileto PRO Edition how to download & install: https://youtu.be/DYS1M25vMTM

Launch Agileto_Setup.exe provided by Agileto® and follow the instructions.

During the installation you can change the default installation directory:

After installation, it will be created a shortcut in Start -> Programs - > Agileto from
where you may launch Agileto anytime (see below):

Page 8 of 253 www.agileto.com

Agileto_Help_V7.19.docx

How to start – getting the license

You can launch Agileto from the following path: Start -> Programs - > Agileto

If you do not have a valid Licence (usually when you start Agileto for the first time)
you will get the following message:

If you select “OK” then you will go directly to the case A) mentioned below which
will lead you to get the Basic licence On-Line.

In case you select ‘Cancel’ then you will get the main Agileto® window like below:

(Notice: the red dot means no valid

Licence)

You have to push “About” button and you will get the following screen:

Page 9 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Now choose “Licence Menu” and after this push OK button and you will have:

There are two ways for getting a Licence:

 A) Get Licence On-Line -> This way may be used only when you are
connected On-Line to Internet;
 B) Get Licence Off-Line -> This way can be used anytime by exchanging
Agileto Licence file from your PC (using the email) with Agileto Sales Team.

Before to continue further it is necessary to notice that there are two main types of
Agileto Licences, as following:

 Agileto BASIC Licence -> This licence can be obtained instant On-Line and it
is usually provided as FREE OF CHARGE. It has limited functionalities, has
no support for any 2G/3G/4G vendor equipment and it is issued for 15 days
validity period of time while the user may explore Agileto with limited
capabilities.

Page 10 of 253 www.agileto.com

Agileto_Help_V7.19.docx

 Agileto ENHANCED Licence -> This licence has support for minimum one
(1) vendor equipment, has access to all Agileto’s modules (it may be
customised which module to have access or not) and its validity period of time
is provided by an agreement between the user and Agileto Sales Team.

A) Get Licence On-Line

In case you select to ‘Get Licence On-Line’ then you will get the following window
prompting to select which tupe of Licence would like to get (like below):

If you already have a valid licence then the second option (ENHANCED) is enabled,
otherwise you may be obliged to get initially an Agileto BASIC licence.

After pressing the button OK the registration form is open like below and the user is
requested to provide his/her registration details.

Page 11 of 253 www.agileto.com

Agileto_Help_V7.19.docx

After all the registration fields are datafilled press OK and you get Agileto EULA:

You need to agree with Agileto EULA then you will get the following message:

Page 12 of 253 www.agileto.com

Agileto_Help_V7.19.docx

After pressing the OK button the full Licence details windows will occur like below:

After pressing OK button the main Agileto window occurs with the (old) red dot
changed now into a green dot meaning that a valid licence is running (for 15 days).

Page 13 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Notice: Agileto BASIC Licence is the first type of Licence that a user may get On-
Line. After you have got a BASIC licence, you may select anytime to Get the
‘ENHANCED’ Licence (On-Line) if there is an agreement between you and the
Agileto Sales Team or you are qualified for a special Agileto promotion claming for
such of ENHANCED Agileto Licence.

B) Get Licence Off-Line

In case you select to ‘Get Licence Off-Line’ then you will get the following window
prompting to select which tupe of operation you would like to perform (like below):

Initially please select the first option “Export the Licence file” and then push OK.
You will get:

Fill the Name and Surname with your relevant information and then push OK. You
will get then the next window asking for the path location where you want to save
your Agileto exported licence file:

Page 14 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Save your Agileto Exported Licence *.txt file on your PC and then send it by mail to
[email protected].

You will receive back your customized Agileto ENHANCED License file (*.txt)
which you will need to import in order to be able to use the tool, as following:

Launch again Agileto® software and then choose:

About -> Licence Menu -> Get Licence Off-Line -> Import the Licence, then
push OK.

You need to agree with Agileto EULA (by pressing the Yes button) then you have to
select the license file (which you’ve got back from the Agileto Sales Team) then push
the “Open” button like into the next picture.

Page 15 of 253 www.agileto.com

Agileto_Help_V7.19.docx

After the successfully import of the license you will receive a confirmation
message/window like it is presented into the next picture. Push OK.

You will get then another window containing the summary details of the Licence that
was given to you (ENHANCED) and it was just imported successfully (see the
picture below).

Page 16 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get again Agileto® Main menu window as per below:

(Notice: the red dot changed to the

green dot)

C) Agileto GOLD EDITION

Agileto ‘GOLD EDITION’ is our special edition focused on the 3G technology

which cumulates multiple results, modules & features developed by Agileto up to a
certain moment of time. It is coming together with an Enhanced Licence (free of

Page 17 of 253 www.agileto.com

Agileto_Help_V7.19.docx

charge) and is supporting all the main telecomm vendors for the 3G technology like:
Ericsson, Nokia-Siemens, Alcatel-Lucent, Huawei.

The licencing process is no more necessary for Agileto GOLD Edition as it is

required for Agileto PRO Edition, like it was described into the previous section. The
registration process for Agileto GOLD Edition is optional (reccommended) in order
to allow the user to benefit for free and with priority of the following:
 Technical Support,
 New/Beta versions & upgrades,
 Communication news regarding Agileto.

Remember:
Agileto GOLD Edition is provided “as it is” meaning that there is no more
development or very limited updates are going to be provided in the future. If you
want to benefit of the professional Agileto version supporting new and enhanced
features + continuously support, updates and maintainance in line with the news and
technology then you should consider to use Agileto PRO Edition version.

You may check on the link below a breef comparison between Agileto GOLD
Edition versus Agileto PRO Edition:
http://www.agileto.com/promo_page1.html#GOLD_vs_PRO

You may purchase from our web site anytime (7/24) an ‘Enhanced’ Agileto PRO
Edition license by using your Debit/Credit Card or PayPal account. Please check the
link mentioned below for more details and don’t miss the promotions…

http://www.agileto.com/payment.html

Final remarks:

1) You may check any time the status of your Licence in order to have displayed the
full Licence details (updated) window like it was presented before by pressing from
Agileto Main menu the following combination: About -> Licence Menu -> Licence
details and pressing always the OK button.

2) Please be aware that for any new project you will need to run for the first time the
module M1.1, before running any other module. This is necessary to be performed
initially in order to generate Agileto’s 2G/3G/4G reference database which should be
available for all the other modules. For more details about Agileto reference database
please follow on this document the section named: 1.1) Generate and update
Agileto reference database (2G/3G/4G)

You may start now to use Agileto® software tool. Good Luck!

Page 18 of 253 www.agileto.com

Agileto_Help_V7.19.docx

DEMO_PROJECT

For the reference purpose as well as for a new user to become quickly familiar with
Agileto’s capabilities it was included into Agileto setup kit a DEMO_PROJECT
containing some predefined samples databases/outputs and guidelines which provide
indications (step-by-step) about how to perform different basic tasks in Agileto.

Agileto DEMO_PROJECT help file (Agileto_DEMO_PROJECT.chm) contains

some basic Agileto tasks and few examples. It is open automatically when the
DEMO_PROJECT is installed or it may be open by pressing the dedicated button
from the main Agileto window (when the project ‘DEMO_PROJECT’ is selected).

Page 19 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Agileto DEMO_PROJECT is installed automatically during Agileto installation

process but it may be downloaded separately and installed manually from here:
http://www.agileto.com/setup/Agileto_DEMO_PROJECT.exe

To activate (and re-install) Agileto DEMO_PROJECT later on (during the normal

usage of Agileto when a different project has been selected as active) the user should
perform the following selection from the main menu (like it is presented into the
picture below): About -> Activate (Install) DEMO_PROJECT

Page 20 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Press OK button and Agileto DEMO_PROJECT installation process will start like it
is presented into the next picture.

You will need to ‘Accept’ in order to continue. When the installation is completed
Agileto_DEMO_PROJECT help file is open automatically like it was presented at the
beginning of this chapter.
Agileto_DEMO_PROJECT help file resides at the following path:
C:\Agileto\DEMO_PROJECT\Agileto_DEMO_PROJECT.chm

Page 21 of 253 www.agileto.com

Agileto_Help_V7.19.docx

How to upgrade Agileto tool

All you need to be sure that you are using the very last version available for Agileto
is to verify that your PC is connected to internet before launching Agileto.

If your PC is connected to internet, each time when Agileto is launched it will check
if a new version is available and if it is the case the upgrade process to the last
available version will start automatically like it is presented further.

In case there is available a new Agileto version then Agileto ‘Updater’ will manage
automatically the upgrade to the last version available without any user manual
intervention. This case the following windows are going to be displayed:

When the upgrade is completed the message will change to the following:

After the upgrade is completed a follow-up change Log version history window will
display the news related to the new version like you may see below (you may press
the Stop button in order to keep-up this window otherwise it will disappear in ~ 10s):

Page 22 of 253 www.agileto.com

Agileto_Help_V7.19.docx

You may continue to use straightway Agileto who’s Main Menu will re-open again
(automatically) presenting the new Agileto version number updated like below:

This is Agileto version number.

All the previous Agileto’s settings including the Licence details remained the same
after the upgrade has been performed.

You may continue to use Agileto tool straightway like you already did before the
upgrade process took place.

Page 23 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Directory structure

You may start using Agileto tool by pushing the “Start” button, as per below:

and you will see the main interface:

You can change ‘Agileto Working Path’ that means the directory where all the Agileto
Projects (each Agileto Project has its own folder) will be stored. This path is stored
internally by the tool as the reference “Working Path” of the tool.

In case this path doesn’t exist on your PC then the path will be displayed with red
color, otherwise it will be displayed with green color like above: C:\Agileto. In order
to change “Agileto Working Path” you need to press the “Change Working Path”
button from the above picture and follow the indications provided by the tool.

As an example to setup ‘Agileto Working Path’ after you press the “Change Working
Path” button a dedicated window interface (see below) will ask you to select the
desired path:

Page 24 of 253 www.agileto.com

Agileto_Help_V7.19.docx

If you choose C: drive and push the “Save” button then C:\Agileto folder will be
created. Please notice that after the path selection is performed the folder Agileto is
created automatically into the path selected and this will be the final “Working Path”.

Example:
Path selected: -> C:\ (which means that):
Agileto Working Path: -> C:\Agileto

Starting with Agileto engine version 36.685 it has been adopted the idea of working
separately/dedicated on projects. This means that each project will have created its
own directory under the “Agileto Working Path” location. This directory will carry
on all the data related to that project. The name of the project is the same with the
name of its associated directory generated under “Agileto Working Path”.

As per the example presented into the first image on this chapter, in case that no
project was already created under “Agileto Working Path” (or the last active
project/folder was deleted) then under the “Active Project Name” it will be displayed
with the red color the message “NO_PROJECT_SELECTED”.

In order to perform the management of the projects (generate a new project or select
an existing one) you need to press the button named “Projects Management”.

When pressing the button “Projects Management” (see the next picture) you need to
type in (or select) the name of the desired project. If it is typed the name of a new
project a new corresponding folder will be automatically generated under “Agileto
Working Path” location corresponding to the new project just created.

Page 25 of 253 www.agileto.com

Agileto_Help_V7.19.docx

After selecting / typing the name of the desired project this will be recorded by the
tool as the last (working) Active project and you do not need to select it again next
time when you open the tool.

In case you would like to select another existing project you just need to select it
from those available into the form (like it is presented into the above picture).

Under “ ” location there are generated folders representing all

Agileto’s projects already created in advance; each Agileto project (folder) contains a
number of standard subfolders like they are presented into the picture below (they are
generated automatically by Agileto tool when a new project is created):

Page 26 of 253 www.agileto.com

Agileto_Help_V7.19.docx

All the folders presented above are automatically generated under each project
(folder) and they are going to be used during the usage of the tool for different
purposes; some of them are recommended to be used by the user for the purpose of
storing specific data, some of these folders are used automatically by the tool when
generating different outputs and reports.

Page 27 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The purposes/usage/meaning of these folders and their associated files are presented
below.

As a general rule, under the standard subfolders generated automatically for each
project, the set of subfolders 2G/3G/4G are generated automatically by the tool and
inside of each of them are stored the data specific to that technology [2G/3G/4G].

Audit_SanityCheck -> directory where the tool is storing the reports and the output
files of specific modules like M2.1 (Audit & ‘Sanity Check’) or M2.2, M2.3, M2.4.
 2G/3G/4G -> directories where the tool is storing the outputs according with
the dump file technology (2G/3G/4G);
Ex: OMC_ATT_20110325 -> it is an output directory generated by the tool (with
the module M2.1) by using as input the OMC snapshot file
OMC_ATT_20110325.xml.
Call_Traces -> directory related to the network optimization (3G-3G/3G-2G
neighbors analysis/proposals -> M4.2 & M4.4) based on Call Traces containing:
 CT_files -> directory where it is recommended to store the Call Traces
(*.xml/*.tab) files/directories [input data for M4.2];
 CT_Optimisation -> directory where the tool is storing the output reports for
the network optimization based on the Call Traces (M4.2 outputs);
 CT_PSC_Det -> directory where it is recommended to be stored the Call
Traces (*.txt file) containing PSC detected [input data for M4.4];
 CT_PSC_Det_Optim -> directory where the tool is storing the output reports
for the neighbors optimization based on PSCs detected (M4.4 outputs);
Drive_Tests -> directory related to the network optimization based on the Drive
Tests (module M4.1); this directory contains two subdirectories, one for inputs
(DT_Measurements) and another-one for outputs (DT_Optimisation), as following:
 DT_Measurements -> directory where it is recommended to store the Drive
Tests (scanner/mobile) measurements data files [input data for M4.1];
 DT_Optimisation -> directory where the tool is storing the output reports for
the network/neighbors optimization based on the Drive Tests (M4.1 outputs);
GoogleEarth -> directory related to the representation in Google Earth formats of
different outputs like 2G/3G/4G mobile Networks, Drive Test outputs, Neighbors,
KPIs, etc:
 2G/3G/4G -> directories where the tool is storing in GoogleEarth formats the
2G/3G/4G Sites & Cells files (automatically generated & stored here by M1.2);
 Drive_Tests -> directory where the tool is storing the output results of the
Drive Test Analysis/Optimisation generated in Google Earth format (M4.1);
 Neigh_GE -> directory where the tool is storing the neighbors generated in
Google Earth format by different modules (M3.1, M3.2, M4.2);
 KPIs -> directory where the tool is storing the KPIs of the Cells generated in
Google Earth format by the moduleM5.1 (one dedicated folder per KPI type);
KPIs -> directory related to the module M5.1 -> this is a directory where it is
recommended to store all the KPIs files as inputs for the M5.1 (Generate MapInfo &
GoogleEarth cells/sites objects based on KPIs values);
Page 28 of 253 www.agileto.com
Agileto_Help_V7.19.docx

MapInfo -> directory related to the representation in MapInfo of the 2G/3G/4G

mobile networks + their associated Neighbors + Drive Test + KPIs:
 2G/3G/4G -> directories where the tool is storing in MapInfo formats the
2G/3G/4G Sites & Cells files (automatically generated & stored here by M1.2);
 Drive_Tests -> directory where the tool is generated (for each study case) a
directory representing the output of the files resulted after the Drive Test
Analysis/Optimisation activity in MapInfo specific format -> [M4.1 outputs];
 Neigh_CT_MI -> directory where the tool is generated (for each study case) a
directory representing the output of the files resulted after the Call Traces
Analysis/Optimisation activity in MapInfo specific format -> [M4.2 outputs];
 Neigh_DB -> directory where it is recommended to store all the external
neighbors definitions files (ex: 4G4G/4G3G/3G3G) -> [input data for M3.2];
 Neigh_DB-MI -> directory where the tool is storing the neighbors generated in
MapInfo format having as input external neighbors file [M3.2 outputs];
 Neigh_MI_Delta_Export -> directory where it is recommended to store all
the neighbors changes (3G-3G and/or 3G-2G) performed visually in MapInfo
and then exported as *.csv files [M3.3 outputs];
 Neigh_MI_Delta-OMC -> directory where the tool is storing the generated
Work Orders [WO] related to the neighbors changes (3G-3G and/or 3G-2G)
performed visually in MapInfo; the WO reports files are generated into the
right format ready to be loaded directly into OMC after performing the format
conversion Neigh_MI_Delta_Export -> Neigh_MI_Delta-OMC [M3.1 (top
option) outputs];
 Neigh_OMC-MI -> directory where the tool is storing its proprietary MapInfo
(formats) generated files related to all the currently defined Neighbors [3G3G,
3G2G, etc] declared into the Network as they are stored into OMC snapshot
file [M3.1 (low option) outputs]; these output files are used as input for M3.3;
MobileNW_Config -> directory containing the configuration data regarding the
2G/3G/4G mobile networks:
 MobileNW_Config.xls -> Agileto (default) reference database file containing
the 2G/3G/4G (sheets) related to 2G + 3G + 4G cells database information;
 MobileNW_Config_New -> directory where there will be saved automatically
all the new generated/updated Agileto database backup files (output M1.1);
 MobileNW_External_DB -> directory where it is recommended to store the
external Excel (2G/3G/4G) database files (used as inputs for M1.1);
 OMC-2G_Export -> obsolete directory (!) -> it is recommended to store the
2G network OMC export files (used usually as input for M2.1, top option);
OMC_Snapshots -> directory where are recommended to be stored the OMC
2G/3G/4G snapshot files (*.xml, *.xcm, *.txt) under the specific 2G/3G/4G
subfolders according to the technology which the files belongs to; this path location is
used by the tool as the default input path for the OMC snapshot files.

Page 29 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Modules available
Database & GIS
1.1) Generate and update Agileto reference database (2G/3G/4G)

To watch on-line the related video training for this module click on the link below:
a) Based on OMC/OSS dump file: https://youtu.be/QnptqYVeEPk
b) Based on External Excel file: https://youtu.be/xCrvsqBfV_0

For more details / information regarding the format & structure of Agileto’s reference
database file please see the Annex named ‘Agileto reference database
[MobileNW_Config.xls]’.

Whenever a new project is created you will need to generate Agileto reference
database related to that project (by using M1.1) that is in fact the file named generic
MobileNW_Config.xls. This operation may be performed by using any of the options
(a or b) presented above but it is highly recommended to perform this in two steps
(Step 1 = a, followed by Step 2 = b).

The first step is by using File #1 and the second step is by using File #2 (see “Before
you start”).

Step 1

Choose OK and then you have to select the second option “By using OMC
2G/3G/4G snapshot files” and to provide the relevant information (see below):

Page 30 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OMC 2G/3G/4G snapshot configuration file contains the 2G/3G/4G network

configuration details and may be obtained in different formats (*.xml, *.xcm, *.txt)
up to the mobile Network equipment vendor. This file was named initially File #1
(see chapter “Before you start”).

If you want to use as input all the OMC snapshot files stored into the same folder
with the one selected, you should ‘select’ (as per below) the option ‘All OMC
snapshot files from the same folder will be loaded’ into the form presented above.

or

Choose OK and you will get the following window:

Initially, only the top option is available -> “Generate a NEW Agileto database
containing ONLY the Cells included into OMC snapshot file”, then push OK.

Page 31 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Notice:
When you generate a new Agileto database for a new project, you may choose to
extract the 3G Local_CID of the cells like they are declared into the OMC snapshot
file OR to generate it artificially like a unique number by the concatenation between
RNC_ID and CELL_ID (in order to fulfill Agileto rule which demand that each cell
3G Local_CID should be unique over the entire mobile 3G network).

Recommendation !
Because some telecom vendors don’t follow the rule to have an unique 3G cell
Local_CID over the entire 3G mobile network it is highly recommended (to avoid the
duplication of the Local_CID over the database) keeping the suggested construction
of the 3G Local_CID [9 digits] as the concatenation between the RNC_ID [4 digits]
and the CELL_ID [5 digits] like it is presented into the picture above. This setting
will be set as a standard string (Local_CID = RNC_ID & Cell_ID) written into
Agileto database (inside 3G sheet, on the first column at the end of the cells
declarations –see the image below) and during the lifetime of the project this setting
will be checked every-time by the tool while loading the database (if necessary the
Local_CID will be overwritten if doesn’t fulfill this condition).

When the module finished its work you will get a similar window like below:

Page 32 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Please notice that a file copy of the new generated Agileto’s database was saved on
the path location and file name as per they are mentioned into the above message.
This message is just for the info (backup) purpose as now Agileto’s database has
been already generated based on the info contained into the OMC snapshot file
according with its technology (2G/3G/4G).

Because the geographically coordinates and the azimuths of the cells are not usually
data-filled into OMC snapshots files (or because they are not accurate/up to date) we
need always to continue with the ‘Step 2’ in order to add the 2G/3G/4G cells
geographically information to Agileto’s database as it will be presented below.

Step 2:

Choose again the module M1.1 (like at the beginning of the Step 1) and then click
OK. You will get the following window:

Page 33 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Now you have to choose the option “By using external Excel file”.

For the top “(*.xls)” file you have to provide File #2 (see chapter “Before you start”)
which is an Excel file exported from the Planning Tool or from the mobile operator
database containing some mandatory information.

Choose OK and you will get the following:

Choose “Update Agileto database ONLY for the common detected Cells included
in both databases” then push OK.

Observation:
You may skip the step 1 presented above and you may want to generate directly
Agileto reference database only “By using External Excel file”; this case you will
need to select above the option “Generate a NEW Agileto database file containing
ONLY the Cells included into External Excel database file (*.xls)”.

Page 34 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Page 35 of 253 www.agileto.com

Agileto_Help_V7.19.docx

You need to provide for each technology (2G/3G/4G) selectable on the top-left tab
(see the previous pictures) the right input data Excel sheet (top-right selection => Ex:
Tech2G sheet for the 2G technology) from the External Excel database then you need
to select the good columns correspondence between the standard Agileto header
names and their names detected into the External Excel database file.

For each technology (2G/3G/4G) you need to provide at least the minimum columns
keys correspondence representing the Cells unique keys identification like they are
presented with the red color into the above pictures (and mentioned below):
2G: Cell_ID + LAC or Cell_Name
3G: Cell_Id + RNC_Id or Local_CID or Cell_Name
4G: Cell_Id + eNodeB_Id or Global_CID or Cell_Name
If the Cells unique keys identification columns correspondences are not provided then
the tool cannot continue and the form cannot be closed when pressing “OK” button.

If you don’t want to update Agileto database for a specific technology then you
should select the ‘empty/blank’ input sheet for that technology [example: 4G above].

Each technology (2G/3G/4G) has the input data divided into three (3) main categories
according with their background color, as following:
1) Mandatory fields -> Green background (data retrieved from Excel file);
2) Optionally fields -> Yellow background (data retrieved from Excel file);
3) Optionally fields -> Blue background (data retrieved usually from OMC
snapshot file but if this is not available it may be retrieved from the Excel file, too);

Page 36 of 253 www.agileto.com

Agileto_Help_V7.19.docx

For the purpose of quickly storing/retrieving the specific user columns

correspondence into different Templates, for each technology (2G/3G/4G) there is
available a ‘Change Template’ button (ex: see on top-left picture the button Change
3G Template) which is managing (Load/Save/Delete) the Active Template as per the
below picture (to be used as appropriate):

When finishing to provide the columns correspondence for each technology, after
pressing the “OK” button a summary standard column correspondence is provided for
each database (2G/3G/4G) like it is presented below (where no column
correspondence is provided then the standard correspondence show nothing):

Page 37 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OBS.
In case that the 4G network information was not provided (case when the Excel sheet
for the 4G technology is set to blank), then no changes will be performed into
Agileto’s 4G database and you will get the above message.

Choose OK and you will be notified with the confirmation message about Agileto’s
database update. Additionally, it is generated automatically a copy of the new
updated Agileto’s reference database like presented into the below message. This
message is just for the info (backup) purpose as now Agileto’s reference database has
been already generated based on the two (2) steps presented before: Step 1 -> info
data contained into the OMC snapshot file followed by the Step 2 -> info data
updated from an external Excel file.

Choose OK again and you have just completed the run for the module M1.1.
Notice: You may open anytime Agileto reference database for the Active project by
using the module M1.4 or “View Agileto Outputs” button from the main interface.

Remarks:

Page 38 of 253 www.agileto.com

Agileto_Help_V7.19.docx

1) It is important to remark that you may update any time Agileto’s reference
database file [MobileNW_Config.xls] from different sources [OMC snapshot file(s)
and/or External Excel database file] by using the module M1.1. The 2G/3G/4G
mobile networks sheets (Agileto’s reference database) may be updated anytime,
together or separately for each technology, in single/multiple steps, according with
the data available included into the input sources.

2) Agileto tool is pointing always automatically to its default reference database file
[…Agileto Working Path \Agileto\ProjectName\MobileNW_Config\
MobileNW_Config.xls] during the time of running all of its modules. By splitting the
working activity on different projects it will be always a dedicated Agileto’s
reference database file (MobileNW_Config.xls) associated for each project.

Obs:
ProjectName -> It is the name of Agileto’s “Active project name” -> this is the
consequence of the new concept of working on dedicated projects introduced since
Agileto engine version 36.685.

Page 39 of 253 www.agileto.com

Agileto_Help_V7.19.docx
1.2) Generate MapInfo + GoogleEarth (2G/3G/4G) cells/sites Objects

To watch on-line the related video training for this module click on the link below:
How to generate cells/sites objects: https://youtu.be/D_Mf-kZPoek

Select the section 1) Database and GIS, then the module M1.2:

Choose OK and you will get:

Press OK and you will get the next window where you may customize the settings
related to the generation of the 2G/3G/4G sites & cells into MapInfo & Google Earth.

Page 40 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Please notice that it is recommended to generate the Google Earth outputs as Spatial
in 3D in order to benefit at maximum from the spatial visualization (3D) available in
Google Earth (see the example below).

Page 41 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Select the desired options/values into the main form then push OK button.

When the generation of the 2G/3G/4G mobile network files is completed the message
presented above will be displayed, presenting the default location where the files
have been saved. Notice that you may use the module M1.4 in order to visualize in
MapInfo and/or Google Earth the mobile networks (2G/3G/4G) just generated.

Page 42 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Please notice the following remark on this module [M1.2] regarding to the generation
of the 2G/3G/4G network objects in MapInfo & GoogleEarth:
 The output MapInfo & GoogleEarth files (including all 2G/3G/4G info) are
automatically generated & stored by the tool under the following Paths:
 MapInfo: …\Agileto\ProjectName\MapInfo\MobileNW.wor
 GoogleEarth: …\Agileto\ProjectName\GoogleEarth\MobileNW.kmz

Example of Mobile Networks generated in MapInfo; General overview:

Page 43 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of Mobile Networks 2G/3G/4G generated in MapInfo; Detailed view:

Example of Mobile Networks generated in Google Earth; General overview:

Page 44 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Example of Mobile Networks (2G/3G/4G) generated in Google Earth; Detailed view:

Page 45 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Some additionally info easy to be noticed on MapInfo & Google Earth screenshots:
 The name of the representation in Google Earth (see the left panel) will be the
name of the project followed by ‘-MobileNW‘ (ex: DEMO_PROJECT-
MobileNW, see the above picture);
 On GE (Google Earth) left sidebar, under the main folder
(DEMO_PROJECT-MobileNW) it will be included the folders 4G, 3G and
2G and under each of them there will be placed the folders related to the
associates sites and cells (see for details the above picture);
 On GE, in order to limit the loading of the entire 2G/3G/4G networks/cells, the
desired group of cells to be visualized may be selected based on their
subfolders as per the creation input selected, as following (the same applies to
BCCHs/PSCs/PCIs):
o Cells_2G -> by 2G LAC (or BSC Name or 2G Cluster);
o Cells_3G -> by RNC_Name (or 3G LAC or 3G Cluster);
o Cells_4G -> by 4G TAC (or 4G Cluster);
 Both MapInfo & Google Earth (2G/3G/4G sites/cells) representations are using
the same legend colors and shapes like they are presented below;
 All 2G sites (round bullets) belonging to the same area (LAC/BSC/Cluster)
will have the same color (2G sites belonging to different areas will have
different colors);
 All 3G sites (triangles) belonging to the same area (RNC/LAC/Cluster) will
have the same color (3G sites belonging to different areas will have different
colors);
 All 4G sites (crosses) belonging to the same area (TAC/Cluster) will have the
same color (4G sites belonging to different areas will have different colors);
 2G Cells are always displayed with Blue colors, as following:
o GSM 900MHz -> dark blue
o DCS1800MHz -> light blue;
 3G Cells color association regarding the Frequency layer legend:
o 3G_Layer_F1 -> yellow (2GHz band lowest DL UARFCN frequency);
o 3G_Layer_F2 -> green (2GHz band, next frequency);
o 3G_Layer_F3 -> pink (2GHz band, next frequency and so on…);
o 3G_Layer_F7 -> red (900MHz band lowest DL UARFCN frequency);
 4G Cells color association regarding the Frequency layer legend:
o 4G_Layer_F1 -> violet (lowest DL eARFCN frequency);
o 4G_Layer_F2 -> light brown (next DL eARFCN frequency);
 2G/3G/4G cells having omni-directional antennas (Beamwidth=360) will be
presented with circles;

Page 46 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Please see below MapInfo details regarding the 2G/3G/4G sites/cells colors codes:

Page 47 of 253 www.agileto.com

Agileto_Help_V7.19.docx

1.3) Network boundary: ‘Border Cells’ detection

To watch on-line the related video training for this module click on the link below:
‘Border Cells’ detection: https://youtu.be/Ah5rT0knr1k

This module is used to evaluate the 2G/3G/4G ‘Border Cells’ meaning all the cells
which are pointing outside of the main Mobile Network coverage area. The ‘Border
Cells’ represent a special class of cells due to their inter-RAT handover particularity.

Select the section 1) Database and GIS, then the module M1.3:

Choose OK and you will get the following window:

Press OK button and you will get the next window:

Page 48 of 253 www.agileto.com
Agileto_Help_V7.19.docx

You have few options to select according with the following three inputs:
 Antennas Beamwidth enlargement percentage [%];
 Coverage Distance [Km] beside a cell is considered as ‘Border Cell’;
 Which cells (All / Ony those detected into OMC snapshot files) are considered
for the ‘Border Cells’ calculation;

Change the values according with your needs and then push OK.

When the module completed the calculations you will get the following message:

Page 49 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the results into Excel in the background as an workbook
(saved under the standard Audit_SanityCheck folder) containing many sheets, each
sheet corresponding to the ‘Border Cells’ analysis performed for that technology
(2G/3G/4G) and specific frequency layer (see as example the screenshot below):

Each frequency layer [1/2/3…] from each technology (2G/3G/4G) has a dedicated
output sheet [3G_F1/3G_F2/3G_F3/etc] where all the cells belonging to that
frequency layer are recorded and the output results in background are colored with
pink color for all the cells detected as ‘Border Cells’ based on the initially input data
provided [BW percent enlargement % + Max coverage distance].

Page 50 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The ‘Border Cells’ detected are generated additionally into Google Earth (GE) format
(Border_Cells.kmz) which is loaded automatically when the general Mobile Network
file (MobileNW.kmz) is visualized in Google Earth (see below).

The ‘Border Cells’ may be selected to be visualized (with specific line colors) in GE
per technology (2G/3G/4G) and per the frequency layer on each technology, as per it
may be seen into the above picture.

The ‘Border Cells’ detected by this module may be used to be assigned with a special
handover ‘class’ for further optimization purpose in order to better optimize the main
KPIs like CSSR & CDR.

Page 51 of 253 www.agileto.com

Agileto_Help_V7.19.docx

1.4) View Active database / MapInfo / GoogleEarth representation(s)

To watch on-line the related video training for this module click on the link(s) below:
Project database: https://youtu.be/xCrvsqBfV_0?t=4m37s
Network in MI: https://youtu.be/1TgOntWXt9U?t=34m45s
Network in GE: https://youtu.be/D_Mf-kZPoek?t=25m39s
Neighbors: https://youtu.be/2ptZYhwEXi8
KPIs: https://youtu.be/3B65edyGBBg?t=10m30s
Drive Test: https://youtu.be/-N_GuLsRPU8?t=57m15s

This module is used to display the ‘active’ Agileto project reference database or
different MapInfo / GoogleEarth representations which have been created in advance
by different Agileto modules.

Select the section 1) Database and GIS, then the module M1.4. This action is
equivalent with the pressing of the button “View Agileto Outputs” (see below):

Choose OK and you will get the next window:

Page 52 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Select the desired option and then press OK button to display the selection
accordingly.

The selection may be displayed in MapInfo or Google Earth according with the
bottom setting performed into the window presented above.

Page 53 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Network Audit (reports & proposals)

2.1) OMC (snapshot *.xml/*.txt): Audit and Sanity Check

To watch on-line the related video training for this module click on the links below:
A: https://youtu.be/du_HYDt1c4c and/or
B: https://youtu.be/Gsp-jwjSdvI

This module is used to make an audit on the 2G/3G/4G mobile network regarding its
main RF parameters based on the input OMC snapshot files exported from each
technology (2G/3G/4G). The outputs will include the summary as well as the detailed
neighbors declarations detected into OMC input snapshot file.

In case that are inconsistencies detected during the audit phase (ex: 3G external cells
declared into the input OMC 4G snapshot file with different parameters) they will be
emphasized accordingly and Agileto will generate automatically the associated
corrective Work Orders [WO].

Select the section 2) Network Audit (reports + proposals), then the module M2.1.

Choose OK and you will get the next window (see below).

Page 54 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OMC 2G/3G/4G snapshot file should be the File #1 (see “Before you start”). In case
there is the interest to evaluate which is the closest cell inside of the main beamwidth
of each cell from the network, then it should be checked the option “Perform Border
Cells analysis” but you should be aware that this task will increase the necessary time
to complete the execution of this module.

If multiple inputs OMC snapshot files placed on the same folder are desired to be
processed into one single analysis then the option “All OMC snaphot files from the
same folder will be loaded” should be selected (see below):
or

According with the technology (2G/3G/4G) the input OMC dump file belongs to, the
output results will be saved into the related folder (2G/3G/4G) under the standard
folder named “Audit_SanityCheck”.

The output format and the results are technology dependent (2G/3G/4G) but
independent concerning the vendor’s OMC input dump file.

The outputs are going to be presented further per each technology (2G/3G/4G), as
following:

Page 55 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OMC 2G Technology:

The outputs for the 2G technology are as following:

2G_Cells-SanityCheck.xls -> This is a summary report file on 2G Cell basis

presenting the main 2G Cell RF associated parameters, CoChannel + InfChannel +
SupChannel interference analysis, as well as the summary 2G Cell Neighbors audit
(2G->2G);

2G2G-NewInfoadded.csv -> This is the file presenting all 2G->2G Neighbors

declarations detected into OMC snapshot configuration file where have been added
some other supplementary information (neighbors distance, priority, reverse
declaration, etc);

Page 56 of 253 www.agileto.com

Agileto_Help_V7.19.docx
2G_Cells-SanityCheck Report (1)
The main 2G cells RF parameters are presented on the left side of the report followed by CoCh/InfCh/SupCh interference analysis:

2G_Cells-SanityCheck Report (2)

On the right side are presented the ‘Border Cell’ + summary neighbors analysis (2G2G):

Page 57 of 253 www.agileto.com

Agileto_Help_V7.19.docx
2G2G-NewInfoadded.csv
This is the output format presenting the detailed 2G-2G neighbors declarations:

Page 58 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OMC 3G Technology:

Like it is presented into the above message, the output results may be up to five (5)
files, as following:

 3G_Cells-SanityCheck.xls -> This is a summary report file on FDDCell basis

presenting the main 3G Cell RF associated parameters as well as the summary
3G Cell Neighbors audit (3G->3G + 3G->2G);
 3G3G-NewInfoAdded.csv -> This is the file presenting all 3G->3G Neighbors
declarations detected into OMC snapshot configuration file + some other
supplementary information (neighbors distance, priority, relation ID, etc);
 3G2G-NewInfoAdded.csv -> This is the file presenting all 3G->2G Neighbors
declarations detected into OMC snapshot configuration file + some other
supplementary information (neighbors distance, priority, relation ID, etc);
 CellsToUpdate-2G.xls -> This is the file representing the corrective Work
Order [WO] necessary to be applied into the 3G network in order to correct
some of the 2G Cells parameters (not yet updated) detected into the 3G
network (OMC 3G dump file).
 GSMCells_only3GOMC-NoExcel.xls -> This file contains all the 2G cells
declarations into the 3G network which have not been detected into Agileto 2G
reference database. On this case, these 2G cells declarations need either to be
deleted from the 3G network (no more existing into the real 2G network) either
they need to be updated into Agileto 2G reference database.

Page 59 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3G_Cells-SanityCheck Report (1):

The main 3G cells RF parameters are presented on the left side of the report followed by the summary and the discrepancy detected:

3G_Cells-SanityCheck Report (2):

On the right side are presented the summary 3G neighbors analysis (IntraFrequency/InterFrequency/InterRAT), as following:

Page 60 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3G3G-NewInfoAdded

Page 61 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3G2G-NewInfoAdded:

Page 62 of 253 www.agileto.com

Agileto_Help_V7.19.docx

CellsToUpdate-2G:
The corrective WO is automatically generated (if necessary) in order to update properly the 2G parameters into 3G network:

Page 63 of 253 www.agileto.com

Agileto_Help_V7.19.docx

GSMCells_only3GOMC-NoExcel:

Page 64 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OMC 4G Technology:

The outputs for the 4G technology may be as following:

4G_Cells-SanityCheck.xls -> This is a summary report file on 4G Cells basis

presenting the main 4G Cell RF associated parameters, as well as the summary 4G
Neighbors audit (4G->4G / 4G->3G / 4G->2G);

4G4G-NewInfoadded.csv -> This is the file presenting all 4G->4G Neighbors

declarations detected into OMC snapshot configuration file + some other
supplementary information (neighbors distance, priority, reverse declaration, etc);

4G3G-NewInfoadded.csv -> This is the file presenting all 4G->3G Neighbors

declarations detected into OMC snapshot configuration file + some other
supplementary information (neighbors distance, priority, etc);

4G2G-NewInfoadded.csv -> This is the file presenting all 4G->2G Neighbors

declarations detected into OMC snapshot configuration file + some other
supplementary information (neighbors distance, priority, etc);

Additionally, there are provided the discrepancies detected into the eNodeBs
external cells declarations comparing with their real parameters values, as following:

CellsToUpdate-4G.xls -> for all the 4G Cells detected in discrepancy;

CellsToUpdate-3G.xls -> for all the 3G Cells detected in discrepancy;
CellsToUpdate-2G.xls -> for all the 2G Cells detected in discrepancy.

Page 65 of 253 www.agileto.com

Agileto_Help_V7.19.docx
4G_Cells-SanityCheck Report (1)
The main 4G cells RF parameters are presented on the left side of the report followed by the summary + discrepancy detected:

4G_Cells-SanityCheck Report (2)

On the right side are presented the summary neighbors evaluation (4G4G/4G3G/4G2G):

Page 66 of 253 www.agileto.com

Agileto_Help_V7.19.docx
4G4G-NewInfoadded.csv
This is the output format presenting the detailed 4G-4G neighbors declarations:

Page 67 of 253 www.agileto.com

Agileto_Help_V7.19.docx
4G3G-NewInfoadded.csv
This is the output format presenting the detailed 4G-3G neighbors declarations:

Page 68 of 253 www.agileto.com

Agileto_Help_V7.19.docx
4G2G-NewInfoadded.csv
This is the output format presenting the detailed 4G-2G neighbors declarations:

Page 69 of 253 www.agileto.com

Agileto_Help_V7.19.docx
CellsToUpdate-3G.xls
This output presents the 3G cells declared into OMC4G @ eNodeBs and detected in discrepancy with some parameters:

Obs.
1. The discrepancy may result even if the Cell_Name is detected with different values;
2. Param Mismatch = 1only if at least one of the parameters PSC/LAC/UArfcn is detected in discrepancy;
3. OMC 4G should be updated with the external 3G Cells parameters presented above in blue background.

Page 70 of 253 www.agileto.com

Agileto_Help_V7.19.docx
CellsToUpdate-2G.xls
This output presents the 2G cells declared into OMC4G @ eNodeBs and detected in discrepancy with some parameters:

Obs.
1. The discrepancy may result even if the Cell_Name is detected with different values;
2. Param Mismatch = 1only if at least one of the parameters BCCH/BCC/NCC is detected in discrepancy;
3. OMC 4G should be updated with the external 2G Cells parameters presented above in blue background.

Page 71 of 253 www.agileto.com

Agileto_Help_V7.19.docx

2.2) 3G(PSCs) / 4G(PCIs) allocation: Audit and Optimization

To watch on-line the related video training for this module click on the link below:
PSCs/PCIs allocation (audit + optim): https://youtu.be/l6PR3ytiQmU

This is a module which can be used either for the 3G technology (PSCs) or for the 4G
technology (PCIs) in order to analyze and optimize the PSCs/PCIs allocation over the
mobile network. The focus on this presentation will be on the 3G(PSCs) technology
but the 4G(PCIs) technology analysis should be treated on a similar way.

The module allows you to make an audit and optimise the planning of the PSCs over
the entire 3G network on each of the frequency layers used by the mobile operator.

The audit of the PSCs allocation will identify all the critical situations, meaning all
the cases representing 3G cells sharing the same PSC with a low inter-cells distance
between them; the cells falling into this special category represent always a problem
from the point of view of optimization as they will generate bad KPIs performance
like low Accessibility, high Call Drop Rate, low Throughput, etc. The quick solution
to solve such non-optimized 3G network is to change the PSCs allocation for the
detected cells falling into this ‘bad’ category mentioned above.

The PSCs/PCIs audit and optimization can be performed at two levels:

 A) Cell/Site level (best usage during local optimization/deployments);
 B) Network level (best usage during the optimization of large areas).

Select the section 2) Network Audit (reports + proposals), then the module M2.2.

Page 72 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the following window:

Choose OK and you will get:

Please select the technology (3G/4G) to be analyzed accordingly. We will focus

forward on the 3G technology but similar approach should be for the 4G.

Choose Yes or No according with your needs and you will get the main form
regarding this module (dedicated for the 3G or 4G technology), as following:

Page 73 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Page 74 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The main form (presented above) allows you to perform locally at Cell/Site level the
audit and optimization of the PSCs allocation for all the cells belonging to the same
NodeB (and the same frequency layer) like the input cell which was selected into the
General Input Data area.

The main form allows you to change the following three inputs (see the pink arrows):
1) LocalCell_Id / Cell Name (into General Input Data area)
2) Input PSC (into REFERENCE (SOURCE) DATA area)
3) PSCs reservations (when a number of PSCs is reserved for specific cells)

During each change it is performed an instant audit analysis presenting into the form
the current status of the repetition of the same PSC in regards with the reference
(source) cells; the fields from “REFERENCE (SOURCE) DATA:” area
respectively “CALCULATED (TARGET) DATA:” area are updated automatically
during each change. On the same “session” all the previous PSCs changes are taken
into account when updating the data from “CALCULATED (TARGET) DATA:”.

For all the Cells belonging to the same Site (presented into “REFERENCE
(SOURCE) DATA:” area) are automatically calculated the following:
 The closest target cells sharing the same PSCs (which details are presented into
“CALCULATED (TARGET) DATA:”),
 The optimum PSC allocation (presented into the green background)
considering the maximization of the distance Source-Target cells which are
sharing the same PSC; this case the following two parameters are provided:
o Optim PSC
o Optim Dist. [Km]
When PSC reservations are provided as input (txt file with one value per line) then
Optim PSC belongs to PSC reservations if the Input PSC belongs and vice-versa.

When the option is selected after each input cell

changed the “Input PSC” are automatically allocated with Optim PSC values.

The data presented into the main form may be exported into Excel by using the grey
button “Export all displayed Results”, as following:

Page 75 of 253 www.agileto.com

Agileto_Help_V7.19.docx

It is possible to perform the audit and optimization of the PSCs allocation at the entire
Network level by pressing the blue button “evaluate PSC optim -> all 3G NW” into
the main form. The following message will appear:

By performing the PSC Audit & Optimisation at the entire Network level an Excel
report file is generated into background presenting the old & new (optimized)
allocation for the PSCs which meet the criteria imposed into the above message. The
screenshots presenting the Excel report files related to the 3G(PSCs) and 4G(PCIs)
technologies are presented at the end of this chapter.

Both methods (Cell/Site level and Network level) are considering for the PSCs
optimization purpose the maximization of the distance between any two 3G cells
belonging to the same frequency layer and sharing the same PSC.

The first option (Case 1 -> Cell/Site level) is best suitable when there are detected
one/few 3G Cells having an issue related to their PSCs allocation (high CDR, low
Accessibility, low Throughput, etc) or for the new insertions/additions of the (new)
sites as deployment between the existing sites.

The second option (Case 2 -> Network level) is more suitable for the initially PSCs
planning / allocation of the entire 3G network in deployment or for the re-planning in
optimized mode of the PSCs allocations for the existing 3G network.

Up to the currently status of the 3G network (initially planning, ongoing

deployments, general area of optimization or punctual optimization troubleshooting /
investigation) it may be selected the Case 1 or the Case 2 as the best approach in line
with the above mentioned recommendations.

Like it was already mentioned before the 4G PCIs analysis and optimization can be
performed with a similar approach like for the 3G PSCs method presented above.

Obs:
It is important to remember that the PSCs range interval is [0 to 511] while the PCIs
range interval is [0 to 503].

Page 76 of 253 www.agileto.com

Agileto_Help_V7.19.docx
3G (PSCs) Allocation and Optimisation at Network level

4G (PCIs) Allocation and Optimisation at Network level

The optimization is performed on each frequency layer detected and the results are saved on dedicated sheets like it is presented into
the above screenshot examples. The report contains the initially & optimized PSCs/PCIs allocations for each cell.

Page 77 of 253 www.agileto.com

Agileto_Help_V7.19.docx

2.3) 2G(BCCHs) allocation: Audit and optimization

To watch on-line the related video training for this module click on the link below:
BCCHs allocation (audit + optim): https://youtu.be/RdTrT5m4EwY

This module is used for the 2G technology in order to audit, analyze and optimize the
BCCHs allocation over the mobile 2G network. The module allows you to make an
audit and optimize the planning of the BCCHs over the 2G network by keeping the
BCCHs frequencies inside of the same mobile operator 2G frequency slot allocations.

The audit of the BCCHs allocation will identify all the critical situations, meaning all
the cases representing 2G cells sharing the same BCCH with a low inter-cells
distance between them; the cells falling into this special category represent always a
problem from the point of view of optimization as they will generate bad KPIs
performance like low Accessibility, high Call Drop Rate, low Throughput, etc. The
quick solution to solve such non-optimized 2G network is to change the BCCHs
allocation for the detected cells falling into this ‘bad’ category mentioned above.

The BCCHs audit (optimization) may be performed by the module at two levels:
 A) Cell/Site level (best usage during local optimization/deployments);
 B) Network level (best usage during the optimization of large areas).

Select the section 2) Network Audit (reports + proposals), then the module M2.3.

Page 78 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the following window:

Obs:
It is important to remember that the full BCCHs range intervals (ARFCN) are defined
into 3GPP standards and a quick overview may be read at the link below:
https://en.wikipedia.org/wiki/Absolute_radio-frequency_channel_number

In case that there is a set of BCCHs values which are reserved to be used only for a
specific type/number of cells, these BCCHs reservations values can be provided as
input into one *.txt file (BCCHs reservations values are written one per line) like seen
into the screenshot below (the total number of BCCHs reservations is written at the
end of the string and their values may be inspected into the associated listbox
presented into the main form).

This feature (which allows to input a set of BCCHs reservations values) is very useful
and important because the network 2G cells will be divided in two main groups:
1) Cells 2G which share the set of BCCH reservations values;
2) Cells 2G which do NOT share the set of BCCH reservations values;
According with the above status of the 2G cell concerning which group belongs to, its
optimum BCCH value will be calculated in such of way to get the target optimum
cell belonging to the same group like the source cell.

Choose OK on the previous window and you will get the main form related to this
module like it is presented into the screenshot below.

Page 79 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The data presented into the main form (see above) may be exported into Excel by using the grey button “Export the displayed
Results”, as following:

Page 80 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The main form (presented above) allows you to perform locally at Cell/Site level the
audit and optimization of the BCCHs allocation for all the cells belonging to the same
Site (and the same 2G frequency band) like the input cell which was selected into the
General Input Data area.

Based on the BCCHs cells declarations detected into the 2G database, the tool
evaluates which 2G frequency bands are used (GSM900, E_GSM900, DCS1800) and
more exactly which are the Min & Max channels in usage for each frequency band
detected. If desired the Min/Max channels for each frequency band in usage can be
modified manually in such of way that the new frequency range interval (for each
band) should not exceed the frequency spectrum range interval allocated for the
mobile operator (see the orange arrow into the above screenshot).

Excepting the Min/Max channels (related to each Frequency Band), the main form
allows you to change the following three inputs (see the pink arrows):
 Cell Name (into General Input Data area)
 Input BCCH (into REFERENCE (SOURCE) DATA area) –> may change
inside the Min/Max range from the same band;
 BCCH Reservations (in case that a number of BCCHs channels are
reserved for special cells);

During each change it is performed an instant audit analysis presenting into the form
the current status of the repetition of the same BCCH (CoChannel) in regards with
the reference (source) cells; additionally, there are presented the similar results for the
adjacent inferior and superior channels (AdjChan Inf/Sup); the fields from
“REFERENCE (SOURCE) DATA:” area respectively “CALCULATED
(TARGET) DATA:” area are updated automatically during each change.

During the same “session” all the input BCCHs changes are taken into account when
updating the data from CALCULATED (TARGET) DATA. If a number of BCCHs
changes are performed during a session they need to be exported after each change
and Agileto 2G database needs to be updated with all these changes (M1.1 may be
used for this purpose or the sheet 2G can be edited manually by using M1.4),
otherwise it will keep the same initially values before the BCCHs changed.

For all the Cells belonging to the same Site (presented into “REFERENCE
(SOURCE) DATA:” area) are automatically calculated the following:
 The closest target cells sharing the BCCH CoChannel / AdjChan_Inf /
AdjChan_Sup (which details are presented into “CALCULATED (TARGET)
DATA:”),
Obs: If the Target CoChannel cell has the same BSIC like the Source cell then a
small red circle is displayed near the target cell (see the above screenshot);
 The optimum BCCH allocation (presented into the green background) considers
the maximization of the distance Source-Target cells which are sharing the same
BCCH (CoChannel); this case the following three parameters are provided:

Page 81 of 253 www.agileto.com

Agileto_Help_V7.19.docx

o Optim BCCH
o Optim Dist. [Km]
o Optim InBW -> Inside BeamWidth Source-Target (S->T|T->S) calculation
(presenting if the Source-Target Cells are detected inside the beamwidth of
the antennas each other;
Obs:
1) Optim BCCH is evaluated like the closed target cell which share the same
BCCH with the source cell at the maximum distance but does NOT have the same
BSIC like the source cell.
1) If BCCHs reservations are provided AND the input BCCH from the source cell
is detected between the BCCHs reservations values then the Optim BCCH is
calculated only between the BCCHs reservations values.
2) Reciprocally, if BCCHs reservations are provided AND the input BCCH from
the source cell is detected outside BCCHs reservations values then the Optim
BCCH is calculated only outside BCCHs reservations values.

When the option is selected after each input cell changed

the “Input BCCH” are automatically allocated with Optim BCCH values.

The optimization method at Cell/Site level is considering for the BCCH optimization
purpose the maximization of the distance between any two 2G cells belonging to the
same frequency band and sharing the same BCCH. It is suitable when there are
detected a limited number of 2G Cells having an issue related to their BCCHs
allocation (high CDR, low Accessibility, low Throughput, etc) or for the new
insertions/additions of the (new) sites as deployment between the existing sites.

In addition to the BCCH audit and optimization performed at Cell/Site level it is

possible to perform the audit of the BCCHs allocation over the entire 2G Network
level by pressing the blue button “BCCH audit -> all 2G NW” into the main form.

When performing the BCCH audit over the entire 2G Network level an Excel report
file is generated into background presenting the audit concerning the channels
CoChan (BCCH) + AdjInf_Chan (BCCH-1) + AdjSup_Chan (BCCH+1) in
regards with the minimum distance between any two 2G cells belonging to the same
frequency band and sharing the same frequency channel.

The below screenshots presenting the Excel report file concerning the BCCH audit
over the entire 2G Network level are placed at the end of this chapter.

By using the above mentioned report it is easy to evaluate the most critical cases
presenting the CoChannel repetitions at very low distance over the entire 2G
Network. Once these critical cases have been evaluated in such of way, we can
optimize the BCCH allocation for each of the critical cases detected by using the
main form presented initially which provide the BCCH audit and optimization at
Cell/Site level.

Page 82 of 253 www.agileto.com

Agileto_Help_V7.19.docx
2G (BCCHs) audit at Network level (Part 1)

2G (BCCHs) audit at Network level (Part 2)

The audit is performed on each 2G frequency band detected and the results are saved on dedicated sheets like it is presented into the
above screenshot examples. The report contains the CoChan/AdjChInf/AdjChanSup audit analysis for each cell.
Page 83 of 253 www.agileto.com
Agileto_Help_V7.19.docx

2.4) Network comparison between two OMC dump files

To watch on-line the related video training for this module click on the link below:
NW comparison between two OMC dumps: https://youtu.be/2qDwveX6g4A

This module can be used for all the technologies (2G/3G/4G) and its aim is to
perform the comparison audit over two different (Old vs New) OMC/OSS dump
(snapshot) input files (exported at different moments of time) and to provide the main
cells differences between the data contained into the New vs the Old dump files with
a focus on some specific technology RF parameters and the neighbors declarations.

Grace to the very detailed output, this module is used extensively especially during
the roll-out and the swap projects where it is very important to be evaluated with
precision all the main differences which occur into the network during different
moments of time based on the dump files extracted from OMC/OSS at those times.

The output directory (where the results will be saved) will be generated into the
specific 2G/3G/4G folders (according with the OMC input dump files technology)
under the standard Audit_SanityCheck directory and it will be named starting with
the prefix “NC-“ (standing for Network Comparison) followed by the names of the
New – Old OMC input files, like they will be presented further.

Please notice that before proceeding and for the very best results you should have
already prepared in advance Agileto’s database by using the module M1.1.

Select the section 2) Network Audit (reports + proposals), then the module M2.4.

Page 84 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the main form related to this module, as following:

Example for the OMC inputs (OLD vs NEW) related to 2G technology:

Example for the OMC inputs (OLD vs NEW) related to 4G technology:

After providing the inputs (OLD vs NEW) OMC dump files as appropriate, choose
OK and you will get the specific technology (2G/3G/4G) results as they are presented
further.

If desired, please remember that you may select for each of the input dump (OLD /
NEW) file one of the following options, as appropriate:
or
or

Page 85 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Technology 2G:

It is provided a general and summary 2G_Audit (*.xls) file + the detailed neighbors
declarations as they are presented further.

Page 86 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NC_20161020-20160911_Audit.xls (Network comparison between two 2G dumps -> the Audit)

Part 1 -> General Cells Parameters detected in discrepancy:

On the left side there are the 2G cells detected with the main RF parameters followed by the column presenting if the cells are
detected into the OLD dump, followed by the column presenting the cases where any of the following parameters are detected as
different (BCCH, BCC, NCC, Pwr), followed by the Summary Neighbors comparison audit between the NEW and the OLD dumps.
On the bottom it is presented the summary about the module’s version, running time, inputs & outputs.

Page 87 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Part 2 -> 2G2G neighbors comparison

NC_20161020-20160911_2G2G.csv (2G2G Neighbors comparison - details)

Abbreviations: NO -> No Operation / A -> Addition / D -> Deletion

Page 88 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Technology 3G:

It is provided a general and summary 3G_Audit (*.xls) file + the detailed neighbors
declarations as they are presented further.

Page 89 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NC_20161020-20160929_Audit.xls (Network comparison between two 3G dumps -> the Audit)
Part 1 -> General Cells Parameters detected in discrepancy:

On the left side there are the 3G cells detected with the main RF parameters followed by the column presenting if the cells are
detected into the OLD dump, followed by the column presenting the cases where any of the following parameters are detected as
different (PSC, LAC, UARFCN, PwrCPicch), followed by the Summary Neighbors comparison audit between the NEW and the
OLD dumps. On the bottom it is presented the summary about the module’s version, running time, inputs & outputs.

Page 90 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Part 2 -> 3G3G IntraFreq comparison

Part 3 -> 3G3G InterFreq comparison

Part 4 -> 3G2G InterRAT comparison

Abbreviations: NO -> No Operation / A -> Addition / D -> Deletion / CP(S) -> Change Priority (Sib11)

Page 91 of 253 www.agileto.com

Agileto_Help_V7.19.docx

NC_20161020-20160929_3G3G.csv (3G3G Neighbors comparison - details)

Operation (it may be one of the following neighbor actions performed on the Old dump to get the New dump):
NO -> No Operation / A -> Addition / D -> Deletion / CP(S) -> Change Priority (Sib11)

Page 92 of 253 www.agileto.com

Agileto_Help_V7.19.docx

NC_20161020-20160929_3G2G.csv (3G2G Neighbors comparison - details)

Operation (it may be one of the following neighbor actions performed on the Old dump to get the New dump):
NO -> No Operation / A -> Addition / D -> Deletion / CP(S) -> Change Priority (Sib11)

Page 93 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Technology 4G:

It is provided a general and summary 4G_Audit (*.xls) file + the detailed neighbors
declarations as they are presented further.

Page 94 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NC_20161020-20161005_Audit.xls (Network comparison between two 4G dumps -> the Audit)

Part 1 -> General Cells Parameters detected in discrepancy:

On the left side there are the 4G cells detected with the main RF parameters followed by the column presenting if the cells are
detected into the OLD dump, followed by the column presenting the cases where any of the following parameters are detected as
different (PCI, TAC, eARFCN, PwrRef), followed by the Summary Neighbors comparison audit between the NEW and the OLD
dumps. On the bottom it is presented the summary about the module’s version, running time, inputs & outputs.

Page 95 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Part 2 -> 4G4G IntraFreq comparison

Part 3 -> 4G4G InterFreq comparison

Part 4 -> 4G3G + 4G2G InterRAT comparison

Abbreviations: NO (No Operation) / D (Deletions) / A (Additions)

Page 96 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NC_20161020-20161005_4G4G.csv (4G4G Neighbors comparison - details)

Operation (it may be one of the following neighbor actions performed on the Old dump to get the New dump):
NO -> No Operation / A -> Addition / D -> Deletion

Page 97 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NC_20161020-20161005_4G3G.csv (4G3G Neighbors comparison - details)

NC_20161020-20161005_4G2G.csv (4G2G Neighbors comparison - details)

Operation (it may be one of the following three neighbor actions performed on the Old dump to get the New dump):
NO -> No Operation / A -> Addition / D -> Deletion

Page 98 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Neighbors Visually representation and converters

3.1) OMC (snapshot) <-> MapInfo & Google Earth converters

To watch on-line the related video training for this module click on the link below:
OMC dump -> MI + GE neighbors: https://youtu.be/TTvFI8YqdOs

Select the section 3) Neighbors Visually representation + converters, then M3.1.

Choose OK and you will get two main options as they are presented below:

According with the above screenshot, this module supports two cases, as following:

Page 99 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Case 1: -> “OMC Snapshot (*.xml/*.txt) => MapInfo / Google Earth Neighbors
format (*.csv/*kmz)”
Case 2: -> “MapInfo Delta Neighbors format (*.csv) => OMC (*.xls)”

Case 1: OMC Snapshot (*.xml/*.txt) => MapInfo / Google Earth Neighbors

format (*.csv/*kmz)

This case is used to convert all type of the neighbors declarations (2G2G, 3G2G,
3G3G, 4G4G, 4G3G, 4G2G, etc) detected inside of the OMC snapshot file into a
suitable format (*.csv/*.kmz) capable to be imported and mapped into
MapInfo/GoogleEarth in order to represent visually these neighbors relationships.

Obs:
The *.csv output files of this Case 1 represent the input files for the module M3.3
(MI) while the *.kmz files are used to be opened into GE environment.

The only input to be provided is the OMC (2G/3G/4G) snapshot file which contains
different type of the neighbors declarations which will be translated into MapInfo and
Google Earth. The OMC file may be obtained in different formats (*.xml, *.txt) up to
the OMC/OSS vendor equipment - File #1 (see chapter “Before you start”).

After providing the input OMC snapshot file and pressing the OK button you need to
provide the radius of the reference cell (3G_F1) for GE representation.

Notice:
For the good match of the neighbors presentation in GE between the neighbors lines
and the edge of the cells please provide above the same radius like the one used to
generate the mobile network by using the module M1.2.

According with the input OMC dump file technology (2G/3G/4G) and the name of
the OMC dump file, when the module M3.1 has been completed it has generated
dedicated folders under the standard paths for MapInfo and GoogleEarth where have
been saved a specific number of dedicated neighbors files like they are presented into
the finnish message presented below.

Page 100 of 253 www.agileto.com

Agileto_Help_V7.19.docx

When the module is completed you will get a similar message like below:

The necessary *.csv and *.kmz files containing OMC neighbors declarations have
been saved into locations as per indicated into the above screenshot.

The name of the dedicated directories generated automatically unde the standard path
locations…MapInfo\Neigh_OMC-MI\ respectivelly …GoogleEarth\Neigh_GE\ are
starting with “Nb2G” (or 3G/4G) according with the input OMC dump file
technology provided followed by “_” and then by the name of input OMC dump file
(above example: Nb3G_RNC0105).

The output MapInfo *.csv files generated by this module (M3.1) may be used as
inputs for the module M3.3 (MapInfo Neighboring Tool) where are provide more
related details.

For more details regarding the structure of the MapInfo generated neighbors *.csv
files please see the Annex named “MapInfo Neighbors import file”.

The output Google Earth *.kmz neighbors files are linked one with each other into
the same directory and they are generated spatially (3D) in Google Earth.

The Google Earth synthesis of the neighbors is recorded into Neighbors.kmz file
which may be visualized in Google Earth (by using the module M1.4) like presented
into the screenshot below (It should be selected the name of the directory generated).

Page 101 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Each neighbor relationship is represented in GE by a line between the edge of the

Source cell and the edge of the Target cell. The line presents near its Target cell edge
the neighbor priority/order number as it may be seen in any of the screenshots below.

The neighbors lines are generated in Google Earth by using the standard neighbors
legend color/presentation which is presented below.

The neighbor lines colors are allocated after the following rules:
a) 3G Source technology and neighbor flag = dchUsage -> dark color (special case);
b) 2G/3G/4G technologies (all the other cases) -> the neighbor line color is the same
with the Target cell color technology (to remember the standard cells color allocation
per technologies and per frequency layers please review the description at the end of
the module M1.2).

You may see below some screenshot examples (provided together with Agileto
DEMO_PROJECT) regarding the neighbors presentation which may be seen in
Google Earth when loading the Neighbors.kmz file.

Page 102 of 253 www.agileto.com

Agileto_Help_V7.19.docx

DEMO_OMC_DUMP example:

DEMO_PROJECT example:

Page 103 of 253 www.agileto.com

Agileto_Help_V7.19.docx

To summarize, the neighbors colors are as following (check into pictures above):

1. yellow lines which present the neighbors with target 3G (F1) cells;
2. green lines which present the neighbors with target 3G (F2) cells;
3. pink lines which present the neighbors with target 3G (F3) cells;
4. black lines which present the neighbors with 3G source cells having the target
cells declarations with DchOnly flag allocation;
5. dark blue lines which present the neighbors with target 2G (GSM900) cells;
6. light blue lines which present the neighbors with target 2G (GSM1800) cells;
7. purple lines which present the neighbors with target 4G cells;

All the neighbors are generated spatially (3D) in Google Earth and from this
perspective they look like they are presented into the next screenshot:

It is important to emphasize into the above screenshots that in addition to the

neighbors lines there are presented/displayed as well the associated neighbors
priorities/orders related to all the neighbors declarations selected to be displayed.

Page 104 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Case 2: MapInfo Delta Neighbors format (*.csv) => OMC (*.xls)

This case is used to convert the neighbors changes performed visually in MapInfo
(exported as *.csv format) into a suitable format (*.xls) capable to be imported
directly into OMC/OSS.

Please have a look on the picture below presenting the available inputs:

1) MapInfo Neighbors export file is a (*.csv) file exported from MapInfo

Neighboring tool and it contains all the neighbors changes (Add/Delete) performed
visually in MapInfo Neighboring tool (launched by the module M3.3). For more
details regarding the structure/format of this type of file please see the Annex named
“MapInfo Neighbors export file”.

2) OMC 2G/3G/4G snapshot file may be obtained in different formats (*.xml, *.xcm,
*.txt) up to the OMC vendor equipment - File #1 (see chapter “Before you start”).

After selecting the above inputs push OK into the above form and you will get:

Press OK and you will get the next window.

Page 105 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose the appropriate button (Yes/No) according with your needs.

When the conversion is completed you will get the results into Excel files according
with the screenshots below:

Example of 3G->3G case:

Example of 3G->2G case:

Page 106 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3.2) Neighbors database -> MapInfo & Google Earth converters

To watch on-line the related video training for this module click on the link below:
Neighbors database -> MI + GE neighbors: https://youtu.be/1TgOntWXt9U

This module (M3.2) allows you to generate all type of the neighbors declarations for
MapInfo (see M3.3) and Google Earth when the OMC (2G/3G/4G) dump
configuration files of the mobile network are not available but the neighbors
declarations are available in *.csv formats.

This kind of work may represent a temporary solution (to be used instead of the
module M3.1) when the neighbors declarations are available in different formats but
the OMC configuration files of the mobile network are not yet available.

Select the section 3) Neighbors Visually representation + converters, then M3.2.

Choose OK and you will get the following window.

Page 107 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Neighbors database file is a *.csv file where different type of the neighbors
declarations are stored (2G-2G, 3G-3G, 4G-4G, 4G-3G, etc). They may be provided
in different formats (structure) and for the right matching of the data columns it is
necessary to provide further the right columns associations like it is presented below.

For more details regarding the format (structure) of this type of the neighbors
declarations files please see the Annex named “External Neighbors declarations file”.

It is highly recommended to store the external neighbors declarations files under the
standard path of ProjectName\MapInfo\Neigh_DB\... like it is presented into the
example from the above screenshot -> 2G-2G neighbors declarations from the
DEMO_PROJECT (delivered together with Agileto setup installation kit):

C:\Agileto\DEMO_PROJECT\MapInfo\Neigh_DB\2G-2G_Neighbors_Demo.csv

After selecting the desired input file push OK into the above form and you will get
one of the following windows (screenshots) which need to be customized according
with the neighbors Source and Target input technologies (2G/3G/4G):

Up to the contents of the neighbors declarations file you should select the Source and
Target technologies (2G/3G/4G) and the other associated cells unique identification
column correspondence like they are presented into the next screenshot (see below).

The Source and the Target cells can be unique identified per technology by selecting
one of the following formats:

Technology 2G: CellId + LAC

Technology 3G: CellId + RncId or localCellId
Technology 4G: CellId + eNodeBId or GlobalCellId

Page 108 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of the 2G-2G neighbors declarations:

Example of the 3G-2G neighbors declarations:

Page 109 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of the 3G-3G neighbors declarations:

Example of the 4G-4G neighbors declarations:

Page 110 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Optionally (if this info is available) you may provide the specific neighbors
information regarding the sib11orDch / Priority / Special.

A special attention should be given to the field ‘Special’ from the ‘Optional Inpus’
because when it gets the values +1/-1 it triggers the neighbor representation line from
the standard color to the red/black color (an example will be presented further). The
main purpose for this field is to represent with red/black colors a subset of the
neighbors triggered by the values +1/-1 into the field selected for ‘Special’ (Ex:
neighbors which are detected in one set and not detected into another set will be
drawn in red respective black colors).

The generation of the neighbors in Google Earth formats is automatically preselected

(check on left bottom of the form: Generate Google Earth files) but you should
datafill Reference 3G_F1 Cell Radius value as appropriate in order to match with
the same value which was used during the generation of the mobile network by M1.2.

According with the Source cell technology and the name of the neighbors
declarations input file, when the module M3.2 has been completed it has generated
dedicated folders under the standard paths for MapInfo and GoogleEarth where have
been saved a specific number of dedicated neighbors files like they are presented into
the finish message presented below.

The name of the dedicated directories generated automatically unde the standard path
locations…MapInfo\Neigh_DB_MI\ respectivelly …GoogleEarth\Neigh_GE\ are
starting with “Nb2G” (or 3G/4G) according with the technology selected for the
Source cells followed by “_” and then by the name of the neighbors declarations
input file (above example: Nb2G_2G-2G_Neighbors_Demo).

Page 111 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The output MapInfo *.csv files generated by this module (M3.2) may be used as
inputs for the module M3.3 into the same manner like have been presented the output
files of the module M3.1 (Case_1).

The output Google Earth *.kmz neighbors files are linked one with each other into
the same directory and they are generated spatially (3D) in Google Earth like they
have been presented during the Case_1 of the previous chapter (3.1).

The Goggle Earth synthesis of the neighbors is recorded into Neighbors.kmz file
which may be visualized in Google Earth (by using the module M1.4) like presented
into the screenshot below.

The neighbors legend colors and the presentation remain the same like they have
been presented (with examples) during the Case_1 of the previous chapter (3.1).

Please see below few more details and related examples for the cases when the field
‘Special’ is used which will trigger that some neighbors which are detected with the
values = +1/-1 on this field will be represented with red/black lines and no more with
their standard associated colors.

Page 112 of 253 www.agileto.com

Agileto_Help_V7.19.docx

When the user is going the assign something for the field ‘Special” there is a pop-up
message remainder which states that the neighbors detected with the values = +1/-1
on this field will be represented with red/black colors (see below).

Below it is a screenshot which presents the neighbors representation in Google Earth

for the cell AgiletoDemo1-X which has two neighbors represented with red colors
[to be added] because they had the value = +1 into the column ‘Neighbor Diff’ and
four neighbors represented with black colors [to be deleted] because they had the
value = -1 into the column ‘Neighbor Diff’ [corresponding to the field ‘Special”].

Page 113 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Another important feature of this module is the Single way neighbors detection:

All the neighbors cases which are not declared reciprocally (IntraTechnology cases:
2G2G or 3G3G or 4G4G) are detected automatically and they are represented in
Google Earth with an additional string [S] (standing for Single way) near the
neighbor priority, like they may be observed into the above screenshot.

Page 114 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3.3) MapInfo Neighboring tool (3G –> 3G or 3G –> 2G)

To watch on-line the related video training for this module click on the link below:
MapInfo Neighboring tool ( ): https://youtu.be/2ptZYhwEXi8

This module is used to activate MapInfo Neighboring tool which let you to visualize
and modify in MapInfo the neighbors representation between the same or different
technologies (currently is supporting 3G->3G IntraFr/InterFr + 3G->2G).

The tool provides the possibility to change (add/remove) the input neighbors
configuration data and then to export these changes in different files formats; these
neighbors changes may be converted by the module M3.1 (Case_2) into the right
format (Work Order) in order to import them directly into OMC.

Remember:
1) Please notice that before using this module (M3.3) you need to run in advance the
module M1.2 in order to generate the standard MapInfo workspace named
“MobileNW.wor” including the 2G/3G/4G sites/cells objects which contains
(enabled to be seen) at least some of the following MapInfo *.tab layers (Sites_3G,
Cells_3G_F1, Cells_3G_F2, …Cells_3G_FX, + Sites_2G, Cells_2G).

2) You have also to run in advance one of the modules M3.1 or M3.2 in order to get
the right neighbors declarations (*.csv) file accepted to be imported in MapInfo.

Select the section 3) Neighbors Visually representation + converters, then M3.3.

Page 115 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the following window:

Here you can choose several options according with your needs, as appropriate:
 3G-3G: Intra-Frequency or,
 3G-3G Inter-Frequency or,
 3G-2G Inter-RAT.

You can also choose the frequency layers to be used [F1, F2, up to F10] according
with the frequency layers detected in advance and stored into Agileto’s 3G database.

After selecting the type of the neighbors and the Source / Target frequency layers (as
appropriate) press the OK button and the following two actions will happen:

1) MapInfo opens automatically in the background with the standard workspace

named “MobileNW.wor” which was generated in advance by the module M1.2.

2) You get the specific MapInfo neighboring tool pop-up message asking you to
provide the (*.csv) input neighbors file (3G->3G or 3G->2G) like it is presented into
the screenshot below.

The (*.csv) input neighbors file which needs to be provided as input for the pop-up
message mentioned above should have the right format accepted by MapInfo
neighboring tool (this file should be prepared in advance as output of the modules
M3.1 or M3.2). For more details regarding the structure of the neighbors file to be
imported in MapInfo please see the Annex named ‘MapInfo Neighbors import file’.

Page 116 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Ex of input file as output of the module M3.2 (DEMO_PROJECT):

Ex of input file as output of the module M3.1 (DEMO_OMC_DUMP project):

Page 117 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The installation kit of the tool is coming with two neighbors test files
(3G_3G_Test.csv / 3G_2G_Test.csv) which will be always copied and stored under
the directory: C:\Agileto\ActiveProject\MapInfo\Neigh_OMC-MI\ as it may be
seen into the screenshot below. They may be used as right references formatted
3G-3G/3G-2G neighbors files in case any troubleshooting action is required.

After selecting the desired input neighbors (*.csv) file MapInfo Neighboring tool will
take immediately the focus like it is presented into the picture below (this is an
example of the neighbors for the case 3G->3G):

Page 118 of 253 www.agileto.com

Agileto_Help_V7.19.docx

You will notice in MapInfo on the right top main menu a new menu named
“Neighbour Tool” like into the above picture. There are now available new icons –
see on the above picture and on the below pictures in focus - which by pressing will
allow the user to execute the following neighbors operations (see the pictures below):
 Show Neighbors
 Add Neighbors
 Remove Neighbors

MapInfo Neighboring tool allows you to export all the 3G->3G and 3G->2G
neighbors changes performed visually in MapInfo into a *.csv ‘Delta’ file (see this
option into the above picture under the ‘Neighbour Tool’ menu). The ‘Delta’ file
may be used later by the module M3.1 (Case_2) in order to convert all the neighbors
changes performed visually in MapInfo directly into a suitable format to be imported
into OMC mobile network.

To activate Show/Add/Remove neighbors operations you need to do the following:

1) Select (press) ‘Show Neighbours’ icon;
2) Select the reference 3G cell (all its neighbors will be displayed);
3) Select (press) the desired operation to be performed (Add/Remove
Neighbours);
4) Select the target 3G/2G cell; => the user will see updated visually in MapInfo
the new set of the neighbors according with the operation selected in advance.

Below it is presented a screenshot for the case of the 3G->2G neighbors, representing
how they are seen into MapInfo Neighboring tool. The same process presented above
in order to Show/Add/Remove neighbors applies for the 3G and 2G technologies.

Example of the neighbors case type 3G->2G:

Page 119 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3.4) ANR: Automatic Neighbors Relation (2G/3G/4G)

To watch on-line the related video training for this module click on the links below:
New: https://youtu.be/TNc6ETpiG6Y or Old: https://youtu.be/AMzYKdTbml0

This module is used to generate automatically the entire set of the neighbors
declarations @ network level (2G/3G/4G) taking into account as input only the Cells
positions (latitude + longitude) and their antennas orientations (azimuths).

You may use this module when you start the deployment/roll-out of a mobile
telecommunication network based only on the Cells (2G/3G/4G) planning
information related to their positions and orientations and you will get the optimum
neighbors declarations (Intra + Inter Technology) related to the input data provided.

This module can be used as well for an existing mobile telecommunication network
where there is already in place a set of the neighbors declarations and - additionally
by comparing with the previous case - you will be provided with the
missing/redundant neighbors declarations after the comparison with the optimum
neighbors configuration proposed by Agileto tool after running this module (M3.4).

Providing and maintaining up to date the right neighbors (Intra/Inter

Technology/Frequency) was always a time consuming problem for the technical
planning and optimization departments, therefore this module is a valuable asset in
their hands as far as it completes the job @ network level just in a matter of seconds.

Select the section 3) Neighbors Visually representation + converters, then M3.4.

Page 120 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get:

Press OK and you will get the next window where you may customize the input
specific settings related to this module as they will be detailed further.

The first input that should be selected by the user is the Source Cells Technology
which can be 2G or 3G or 4G.

Page 121 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Before going forward to explain the meaning of all the other parameters from the
form presented above we will present below few formal concepts/definitions plus the
main 8 cases between the Source and the Target cells position and orientation which
lead to a neighboring relationship.

First of all we need to define the parameter evaluated at cell level IC_MinDist (Inter
Cells Minimum Distance) which represents the minimum distance between the
reference cell and all the other cells from the network belonging to the specified
Target technology (with other words this is the distance between the reference cell
and the closest cell).

If we agregate (median value) for the entire network this parameter (IC_MinDist)
over all the cells belonging to the same Source technology like the reference cell, we
will get the new parameter IC_Dist (Inter Cells Distance) which represents the
“average” inter cells distance over the entire network (with other words IC_Dist tells
us how close are the cells/sites one near the other in average over th entire network).

The Source Cell Point main Coverage area (S_PtCvg) represents a point placed on
the cell’s azimuth at a specific input distance (S_PtCvgD) from the cell (see below
the illustration). S_PtCvgD = IC_Dist * S_MultF (S_MultF=1.3 by default) and is
one of the main input parameters of this module.

The evaluated distance between the Source and the Target cells will be named as
ST_D (Source-Target Distance) -> see below the illustration.

The maximum accepted Source-Target distance is noted here with ST_MaxD

(ST_MaxD = IC_Dist * T_MultF, T_MultF=3 by default) and is another input
parameter which represents the maximum distance between the Source cell and the
Target cell in order that the Target cell may be accepted as a neighbor of the Source
cell (ST_D <= ST_MaxD).

Page 122 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The following main 8 cases of neighboring relationship may occur:

Case 1: (P1)
The Target cells (T) are cosite with the Source (S) reference cell (ST_D = 0)

Case 2: (P2)
The Source cell is detected inside the beamwidth of the Target cell at a distance
ST_D <= P2_multF * S_PtCvgD (P2_multF=1.8 by default):

Case 3: (P3)
The Target cell is detected inside the beamwidth of the Source cell at a distance
ST_D <= P3_multF * S_PtCvgD (P3_multF=1.1 by default).

Case 4: (P4)
The Source Cell Point main Coverage area (S_PtCvg = P4) is detected inside the
beamwidth of the Target Cel (only the condition ST_D <= ST_MaxD has to apply).

Page 123 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Case 5: (P5)
The point P5 which is placed on the cell’s azimuth at the distance P5_Dist
(P5_Dist = P5_multF * S_PtCvgD, P5_multF=0.33 by default) is detected inside
the beamwidth of the Target cell; see below the illustration.

Obs: When P5_multF=1 then P5->P4

Cases 6 or 7: (P6 or P7)

At least one of the points P6 or P7 - which are placed on the cell’s azimuth
+/- AzimDif (AzimDif = 30 degrees by default, or half of the cell’s Antenna
Beamwidth) at the distance P6P7_Dist (P6P7_Dist = P6P7_multF * S_PtCvgD,
P6P7_multF=0.7 by default) - is detected inside the beamwidth of the Target cell.

Case 8: (P8)
The point P8 (very similar with the P5 presented above) which is placed on the cell’s
azimuth at the distance P8_Dist (P8_Dist = P8_multF * S_PtCvgD, P8_multF=0.1
by default) is detected inside the beamwidth of the Target cell. The main difference
related to P5 is that P8 is much closer to the cell’s center (P8_multF=0.1 comparing
with P5_multF=0.33). This case was created in order to cover the area exactly in
front of the Source cell by a potential Target cell.

Page 124 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Returning to the main form of this module, there are two sections which provide the
input for the parameters presented above (S_PtCvgD and ST_MaxD) as following:

A) Source Cell coverage distance:

This section define the parameter S_PtCvgD by two possible inputs:
A.1 -> based on IC_Dist and the specific multiplication factor (Source)
A.2 -> based on specific imposed distance (Km)

B) Max Target (neighbor) Cell distance:

This section define the parameter ST_MaxD by two possible inputs:
B.1 -> based on IC_Dist and the specific multiplication factor (Target),
B.2 -> based on specific imposed distance (Km).

The general optimum input values presented above are provided as default values by
the tool but the user has the liberty to change them based on his own experience and
particularity on the network.

Optionally, the toll allows to provide as input the references to the files representing
the neighbors declarations to each of the target technology (2G/3G/4G) in order to
compare the optimum neighbors configuration detected by the tool with these
references (the format of the reference neighbors should comply with those presented
into the Annex named External Neighbors declarations file).

In case that no reference input neighbors configuration files are provided then the tool
will provide as results exactly three output optimum neighbors configuration files
(one file per each target technology 2G/3G/4G).

If a reference input neighbors configuration file is provided per specific Target

technology then for that Target technology there will be provided by the tool three
output sets of the neighbors configuration files, as following:

1) ANR optimum set of the neighbors containing flags [value=1] for those neighbors
declarations which are not detected inside of the reference input file;
2) The set of the difference neighbors between the ANR optimum detected and the
reference input file (with flags: to be added [1], to be deleted [-1]);
3) The entire ANR set containing the reference neighbors + the set presenting the
difference [to be deleted and added = point 2 above] in such of way to lead to the
final optimal set of the neighbors presented at the point 1 above.

According with the type and the inputs provided for the main distances
(multiplication factors or really distances) the output directory - where ANR output
files are saved - is always generated and saved under the standard directory
Audit_SanityCheck of the project and it will contain related input information and
the runtime info [hour & minutes & seconds] details like is presented into the final
display message that you may see into the screenshot below.

Page 125 of 253 www.agileto.com

Agileto_Help_V7.19.docx

After each analysis there is generated a summary ANR (*.txt) file containing all the
input settings and the main outputs for the future reference (see below).

Page 126 of 253 www.agileto.com

Agileto_Help_V7.19.docx

ANR’s structure of the output (*.csv) files is related to the Source (S) and the Target
(T) cells as per it is presented below.

On the column “Neighbor case” it is provided the figure number [1 to 8] according

with the case of neighboring (described in advance) detected by the tool. The value
=”-1” is generated if the reciprocity is imposed AND none of the neighboring cases
[1 to 8] are detected but the reverse neighboring is detected.

If it is provided the neighbors reference input file then the column “Neighbor Diff”
will contain the values = “1” for all the neighbors relationships [to be added]
detected as optimum by the tool but not detected into the reference input file and the
values =”-1” for all the neighbors relationships [to be deleted] detected into the
reference input file but not detected as optimum by the tool.

Example of the 3G-2G neighbors output format:

Example of the 3G-3G neighbors output format:

Example of the 4G-3G neighbors output format:

Page 127 of 253 www.agileto.com

Agileto_Help_V7.19.docx

ANR output files presenting the optimum neighbors configuration detected by the
tool may be mapped in Google Earth by using the module M3.2 (Neighbors database
-> MapInfo & Google Earth converters) and the results will be presented similar like
on the screenshots below (the missing neighbors [to be added] with red lines and the
redundant neighbors [to be deleted] with black lines).

ANR: Example of 3G-3G neighbors

ANR: Example of 3G-2G neighbors

Page 128 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Network Optimisation (audit and proposal)

4.1) Network Optimisation based on Drive Tests

To watch on-line the related video trainings for this module click on the links below:
DT Analysis: https://youtu.be/5wXpXNObrk4
DT Optimization 2G: https://youtu.be/f3uoeIENcUc
DT Optimization 3G: https://youtu.be/-N_GuLsRPU8
DT Optimization 4G: https://youtu.be/_oafTkMk99Q

This module may be used for two main purposes, as following:

 Drive Test Analysis (DTA)
 Drive Test Optimisation (DTO)

As mentioned by their suggestive names, each case mentioned above is used mainly
for the following activities related to the drive test:
 Analysis -> this case is used just to represent and compare one/two specific
drive test metrics into MapInfo & Google Earth for the purpose of analysis;
 Optimisation -> this case is more complex than the above as it involves
supplementary intelligent optimization results provided by the tool as they will
be documented later on this document.

Select the section 4) Network Optimisation (audit + proposals), then M4.1.

Choose OK and up to the input files you will get one of the following windows:

Page 129 of 253 www.agileto.com

Agileto_Help_V7.19.docx

-> The *.csv file should be File #4 (see “Before you start”) containing the Drive test
measurements data (scanner/mobile measurements data). For more details about the
structure of this file, please see the Annex named “Drive Tests measurements
(scanner/mobile) file”. This file may be obtained by using the module M4.3, too.

-> OMC 2G/3G/4G snapshot file contains the network configuration details and may
be obtained in different formats: *.xml, *.xcm, *.txt - up to the OMC vendor - File #1
(see chapter “Before you start”).

Please notice that you may provide as input the second (2nd) Drive Test file by
selecting this option (2nd File) into the above window (see an example below).

Up to the files formats provided for the 1st and the 2nd Drive Test file(s) you will be
notified on the top right area (see the brown text) with the Drive Test Input Type
that could be one of the following:
Page 130 of 253 www.agileto.com
Agileto_Help_V7.19.docx

 Drive Test Analysis (case of mapping the Drive Test metrics into MapInfo &
Google Earth, eventually to compare two metrics on common routes);
 2G-2G IntraGSM,
 3G-3G IntraFrequency,
 3G-3G InterFrequency,
 3G-2G InterRAT,
 4G-4G IntraFrequency,;
 4G-4G InterFrequency,
 4G-3G InterRAT,
 4G-2G InterRAT

Below there are presented some other cases/screenshots for exemplification:

Drive Test Analysis:

2G-2G IntraGSM:

Page 131 of 253 www.agileto.com

Agileto_Help_V7.19.docx

4G-4G IntraFrequency:

4G-3G InterRAT:

Processing the original Drive Test log files:

The drive test log files acquired by different acquisition tools (Nemo, Tems, Couei,
etc) can be processed directly or indirectly by Agileto tool by using the module M4.3
[Process Drive Test log files (NEMO, TEMS, etc)].

Before going forward with this module (M4.1) you need to have already prepared the
Drive Test measurement file (exported directly from the acquisition tool or by using
Agileto module M4.3) into the right format accepted by Agileto as per it is presented
into the Annex named “Drive Tests measurements (scanner/mobile) file”.

Page 132 of 253 www.agileto.com

Agileto_Help_V7.19.docx

4G-2G InterRAT:

Reference neighbors data options:

1. For the purpose of Neighbors analysis & optimization based on the Drive Test
measurements data it may be provided as input (check on the form the lower input
file area) the OMC snapshot file or the neighbors *.csv file.

2. In case the OMC snapshot file is not available it may be provided as input the
neighbors (*.csv) file by selecting the option “Select Neighbors (*.csv) file
instead of OMC file” (like it was selected into the above screenshot); this case
the neighbors file should contain at least two columns representing the Cell_IDs
of the source and the target cells having the standard headers strings as:
sourceCID, targetCID; in case the standard neighbors format is mismatching
then the below warning message is displayed when the OK button is pressed.

For more details regarding the neighbors file formats please check the Annex named
External Neighbors declarations file.

Page 133 of 253 www.agileto.com

Agileto_Help_V7.19.docx

3. In case that neither the OMC 2G/3G/4G snapshot file or the Neighbors (*.csv) file
are available then it may be selected the option “Don’t select any Neighbors
reference file”; this case the output neighbors analysis & optimization results will
still provide the best suggested neighbors results but the comparison with the
reference neighbors declarations could no more be performed automatically.

Example of the selection case: “Don’t select any Neighbors reference file”:

After providing the relevant information on the previous form, choose OK and you
will get the one of the following two main forms (according with the content of the
Drive Test measurement file) which will be detailed further:
• Drive Test Analysis (DTA) or,
• Drive Test Optimisation (DTO)

The Drive Test Analysis (DTA) can be used in two different situations, as following:
 One input metric (file) is provided -> This is a case when the spatial binning
operation can be performed along the drive test route and the tool may evaluate
one of the following operations for all the samples detected into the same ‘bin’:
o Average
o Minimum
o Maximum
o Occurrences
o Sum
 Two input metrics (files) are provided -> This is a case when the spatial
binning operation is mandatory and the tool will evaluate the difference
between the two metrics detected in common aggregated ‘bins’ evaluated for
both drive tests (the drive tests could be the same or different) containing the
input metrics; after spatial binning is performed each metric is evaluated as the
average between all its samples detected on the same ‘bin’ and after that the
difference is evaluated on all the bins detected in common for both drive tests.

Page 134 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of the case Drive Test Analysis (one input metric):

Example of the case Drive Test Analysis (two input metrics):

Page 135 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of the case Drive Test Optimisation:

Spatial binning concept:

Agileto tool may apply the spatial binning operation to any input
drive test file, meaning that if many samples of the same metric fall into the same
geographically squared bin size (which is provided by the related input
) then the metric will be associated for that bin just
with the aggregated value (Average) of all the samples detected inside of that squared
bin size.

The concept of processing the drive test based on the Spatial Binning aggregation
has been developed by Agileto tool in order to get the following benefits:

 Quick evaluation about the drive test acceptance quality criteria (which
percentage of the drive test has been performed with no mobility detection);
 Performance metric evolution by performing (geographically @ bin size/point
level) the difference between the same metric resulted from two different drive
tests executed approximately on the same drive test routes;
 Capacity to evaluate with great accuracy the InterRAT + InterFrequency
neighbors analysis and optimization based on the drive tests performed
approximately on similar routes (the drive tests routes may be slightly different
and this will not affect the final results);
 some other secondary benefits that will be presented later…

Page 136 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Both Drive Test options mentioned above (Analysis and Optimisation) are
providing summary statistics about the drive test quality performance with output
representations for each point of the drive test into MapInfo & Google Earth, as
following:

 Total duration of the drive test [100%];

 Total duration of the drive test without GPS information [x%];
 Total duration of the drive test without scanner/mobile data information [y%];
 Total duration of the drive test in static position (no mobility detected) [z%];
 Total duration of the drive test validated [100-x-y-z %].

The set of the data information mentioned above is provided very fast and it is very
useful in order to evaluate the quality of the drive test. As example, please see below
a virtual case example which leads to the conclusion that the drive test needs to be
repeated because of the very bad drive test quality detected into summary statistics
=> That means an important time of the drive test has been performed without GPS
info recorded, or without scanner/mobile data recorded, or with no mobility detected.

Example of one bad quality Drive Test summary performance results:

 Total duration of the drive test = 5 hours [100%]
 Total duration of the drive test without GPS information = 20 min [6.67%];
 Total duration of the drive test without scanner/mobile data information = 10
min [3.33%];
 Total duration of the drive test in static position (no mobility detected) = 1 hour
and 30 min [30%];
 Total duration of the drive test validated = 3 hours [60%] (100-6.67-3.33-30)

It is important to remark into the performance of the “bad” quality Drive Test
mentioned above that from a total drive test time of 5 hours only 3 hours [60%] of the
drive test was performed properly while the other remaining 2 hours of the drive test
time was spent by the drive test team without any utility for the drive test analysis
due to different issues (missing GPS data, missing scanner/mobile device data, no
mobility detected).

Quick Drive Test acceptance evaluation:

On many cases the drive test activities are externalized (outsourced) to different
specialized companies and need to be evaluated properly and fast. The type of the
summary statistics like - those mentioned above - are automatically evaluated by
Agileto tool which helps a lot the RF Engineer involved into the drive test
analysis/optimization in order to qualify quickly if a drive test may be accepted as
validated (after certain quality criteria) or needs to be performed once again.

Page 137 of 253 www.agileto.com

Agileto_Help_V7.19.docx

A) Drive Test Analysis (DTA)

Up to the number of the Drive Test input files, DTA can be used in two different
cases (spatial binning option is automatically selected on the second case):
 One input metric (file); -> The output is: Real or Avg/Min/Max/Sum/Occur
 Two input metrics (files); ->The output is: Difference

A.1) DTA One input metric:

This case is used mainly to get the drive test summary statistics and representation
into MapInfo and Google Earth of one desired Drive Test parameter (contained into
the Drive Test measurement data *.csv file); this parameter can be selected by the
user who can modify its associated Legend too, like it may be seen below.

The minimum information necessary to be included into the Drive Test measurement
file and provided by the user as appropriate is the following (see for reference the
screenshot below):
 GPS Latitude (WGS84);
 GPS Longitude (WGS84);
 Time Stamp (optional, just for the tracking purpose);
 Parameter Selected -> this is one of the metrics contained into the DT file;
 Parameter Name -> this may be customized as the name of the ‘Parameter
Selected’ how it will occur into MapInfo & Google Eearth representations;
 Legend Parameter values (ranges and colors).

Page 138 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The following mandatory columns correspondence between the standard Agileto

inputs and the columns from the Drive Test measurements file should be provided:
 GPS Latitude WGS84 (Ex: Latitude into the above example);
 GPS Longitude WGS84 (Ex: Longitude into the above example);
 Time Stamp (Ex: Time Stamp into the above example);
 Parameter Selected (Ex: RxLev_A into the above example);

This Drive Test Analysis case may be performed with or without the Spatial binning
option selected (according with the investigation purpose) but if this option is
selected then the following parameter should be provided, too:
 Spatial bin size [m] (Ex: 10 into the above example);

The field called “Parameter Name” is already data-filled by default with the
appropriate string based on the value selected into the field “Parameter Selected”
but it may be changed manually by the user with any desired string (Ex: RxLev_A
was kept like this into the above example).

Observation:
The final string written into the field corresponding to “Parameter Name” will be
the string (RxLev_A) which will be the reference for this Drive Test Analysis [it will
be the name of the output folder(s) generated by the tool having as prefix the string
“DTA_” standing for Drive Test Analysis (Ex: DTA_RxLev_A)].

If the spatial binning is selected then the name of the output directories will include
the bin size selected and it will add at the end the aggregation method selected
(Avg/Min/Max/Sum/Occur) => This case the output folder(s) will become
DTA_Bin10m_RxLev_A_Avg and this string will be visible into the associated
Google Earth representations as per it will be presented into the further screenshots.

The last set of the inputs which should be provided by the user is representing the
Legend Parameter values which consist into the definition of the following:
 Five (5) thresholds corresponding to six (6) Legend colors (ranges);
 The way how the Legend colors are going to be associated to their correlated
thresholds (ascending or descending);

Press the OK button when finishing providing all the required (above mentioned)
inputs.

When the module completed the analysis it will display a message like below
(mentioning the MapInfo and Google Earth paths locations where the dedicated files
have been generated/saved like presented below).

Page 139 of 253 www.agileto.com

Agileto_Help_V7.19.docx

It is to remark the following:

 The set of directories named DTA_Bin10m_RxLev_A_Avg (the directory
string name starts always with DTA_ followed by the bin size (Bin10m) if the
spatial binning was selected, followed by the Parameter Name, followed by
the aggregation method Avg/Min/Max/Sum/Occur if the spatial binning was
selected) are created automatically by Agileto under the active project standard
MapInfo & Google Earth path locations, as per indicated above;
 There are standard names used for the output files generated for MapInfo &
Google Earth (Drive_Test.wor / Drive_Test.kmz + Drive_Test-Audit.kmz)
and they may be open manually too (in case they are distributed to the third
party who does not have already installed Agileto on his/her PC);
 Under Google Earth path there is generated another dedicated file named
Drive_Test-Audit.kmz where it may be checked the performance of the drive
test, meaning the points reported with issues during the drive test, like:
o GPS Invalid (no data received from GPS -> this case the point will be
represented with the GPS coordinates belonging to the previous valid
point);
o GPS Static (no mobility was detected, that means the drive test
measurement equipment remained on the same static position);
o Parameter Invalid (no information was recorded for the Parameter
selected on that point, that means at that specific time stamp).

Page 140 of 253 www.agileto.com

Agileto_Help_V7.19.docx

You may use the module M1.4 in order to visualize the results into MapInfo and/or
Google Earth environments as per presented below.

Page 141 of 253 www.agileto.com

Agileto_Help_V7.19.docx
See below MapInfo representation of the parameter selected (RxLev_A_Avg):

Page 142 of 253 www.agileto.com

Agileto_Help_V7.19.docx
See below Google Earth representation of the same parameter selected (RxLev_A_Avg):

Page 143 of 253 www.agileto.com

Agileto_Help_V7.19.docx

You may notify the following features available in Google Earth:

 There is a Drive Test Legend displayed on the top left area associated to the
Parameter selected (Ex: RxLev_A_Avg) in line with the thresholds selected
initially by the user as input;
 From GE left panel you may select to display at one time all the drive test
points or only those which fall into one or more of the 6 ranges (T1 to T6)
corresponding to the 5 thresholds provided initially as inputs;
 On GE left panel it is presented the absolute number of points belonging to
each of the 6 ranges (Ex: 42 / 80 / 152 / 154 / 51 / 0);
 On GE left panel (and into the Drive Test Legend displayed, too) it is
presented the relative percentage of the number of points belonging to each of
the 6 ranges comparing with the total number of points detected into the whole
drive test (Ex: 8.8% / 16.7% / 31.7% / 32.2% / 10.6% / 0%);
 On GE left panel there is a Summary folder and when the user press on it
with the mouse, then GE will display an info balloon containing the summary
related to the Drive Test Performance as per already mentioned initially and it
is presented into the screenshot below.

A.2) DTA two input metrics:

This case is used to evaluate (on each bin square detected in common from two input
drive tests files) the difference between two similar drive test metrics (Ex: RxLev,
Throughput, etc) extracted from these drive tests which have to be performed on
similar drive test routes (not necessary perfect identically).

This metric of difference is often requested to be evaluated especially during the

swap projects when it is important to evaluate (including map representations) the
relative comparison for many metrics like coverage, quality, throughput, etc,
between the situations recorded as reference (before) and after the swap took place.

Page 144 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Below it is presented the parameter B (RxLev_B_Avg) as the second input (in

addition to the parameter A presented above RxLev_A_Avg) followed by the
difference between A and B (A-B) which was represented by RxLev_A-B evaluated
on the common detected bins/routes from where A and B were extracted.
RxLev_B_Avg:

RxLev_A-B: (Difference)

All the others technical details for this case (DTA with two input metrics) remain
similar with those already presented previously on DTA with one input metric.

Page 145 of 253 www.agileto.com

Agileto_Help_V7.19.docx

B) Drive Test Optimisation (DTO)

The purpose of this option (Drive Test Optimisation) is to provide the Network
optimization actions (with focus on neighbors and pilot pollution/overshooters)
necessary to be performed into the 2G/3G/4G mobile networks based on the Drive
Test measurements data. The target of Agileto is to get automatically (without
important human manual intervention) all the optimization tasks and
recommendations by using intelligent SON [Self Optimized Network] principles
starting from the data contained into the Drive Test measurements file(s).

Which data to be used: the UE scanner or mobile drive tests measurements data ?!

First of all we would like to remind that the Drive Test measurements file should
contains the Top_1 to Top_X best servers (detected into the 2G/3G/4G mobile
networks) according with the content and format detailed into the Annex named
“Drive Tests measurements (scanner/mobile) file”.

In order to provide a fast answer to the question “which device data to be used: UE
scanner or mobile ?” we would recommend to use always the scanner measurements
data if they are available, due to their highest performance in sensitivity, coverage,
independence against mobile network neighbors declarations and more general
capabilities compared with the mobile(s) drive tests measurements data.

However, due to the special “Spatial binning” option provided by Agileto in post-
processing the input Drive Tests measurements data, the UE mobile drive tests
measurement data may be provided as input too, as far as the missing neighbors
declarations may be detected and compensated by the aggregations performed during
the post-processing data in line with the “Spatial binning” method.

Effectively, by using the “Spatial binning” method, all the signals detected inside
each of the bin (basic squares) having the bin size imposed initially (Ex: 10m) will be
aggregated (averaged all the samples from the same signal) and ultimately Agileto
will perform the sorting in descending order (based on their signal strengths) of all of
signals available on each bin. This way Agileto will (re)generate the Top_1 to Top_X
signals in descending order for each point of the drive test corresponding to an unique
bin having the desired bin size. These results (spatial binned) will be exported into
*.csv files if the option “Export Data Spatial Binned” is selected (see an example
on the screenshot below).

Up to the number and the format of the Drive Test measurements input files,
currently are supported eight (8) types of DTO cases, as following:
 Case: 1 3G-3G IntraFrequency;
 Case: 2 3G-3G InterFrequency;
 Case: 3 3G-2G InterRAT(GSM);
 Case: 4 2G-2G IntraGSM.
 Case: 5 4G-4G IntraFrequency;
Page 146 of 253 www.agileto.com
Agileto_Help_V7.19.docx

 Case: 6 4G-4G InterFrequency;

 Case: 7 4G-3G InterRAT;
 Case: 8 4G-2G InterRAT;

Please see below the main “Drive Test Optimisation” form when two (2) Drive Tests
measurements files are provided as inputs generating the Case 3 [3G-2G
InterRAT(GSM)]. On the right side it is presented the “Preview” of the beginning
data contained inside the 1st Drive Test file.

You will remark that there is a set of the same common inputs like they were already
presented for the case of Drive Test Analysis, as following:

 GPS Latitude WGS84 (Ex: Latitude into the above example);

 GPS Longitude WGS84 (Ex: Longitude into the above example);
 Time Stamp (Ex: Time Stamp into the above example);
 Spatial bin size [m] (Ex: 5 into the above example);

Observations:
a) In case that two (2) Drive Test measurements files are provided as input then the
option “Perform Spatial Binning” is selected by default in order to allow the
geographically superposition between the type of the signals detected into each Drive
Test measurements file [the drive tests corresponding to each input file may take
place simultaneously or on different days and the final results will not be altered (!)].

Page 147 of 253 www.agileto.com

Agileto_Help_V7.19.docx

b) Even when a single Drive Test measurements file is provided as input, we

recommend to select the option “Perform Spatial Binning” in order to get the best
performance. This action will lead even to better optimization results as far as the
action of passing many times with the drive test VAN on the same routes will just
increase the precision of the signals detected into that area (aggregation is performed
better by average).

It may be seen into the screenshot below, that the Spatial bin size [m] may be
selected from a discret number of predifined values or it may be inserted manually:

If the “DT 2nd File” option is selected (top right option) then the preview of the data
will present now the beginning of the second Drive Test file (see the next screenshot,
below). You should provide the right (3) columns correspondence for the 2 nd Drive
Test file on the following inputs (otherwise this missing info it will be signalized
when pressing the OK button).
 GPS Latitude WGS84 (Ex: Latitude into the below example);
 GPS Longitude WGS84 (Ex: Longitude into the below example);
 Time Stamp (Ex: Time Stamp into the below example).

Page 148 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Below it is presented the Case 7 where specific 4G-3G parameters are presented:

In case that two (2) input Drive Test measurements files are provided related to two
3G frequencies layers, it is considered by default that the “Source” data are related to
the 1st Drive Test file (Ex: frequency layer 1) and the “Target” data are related to the
2nd Drive Test file (Ex: frequency layer 2); see the example below:

Page 149 of 253 www.agileto.com

Agileto_Help_V7.19.docx

General Drive Test Optimisation Input Parameters:

EcNoMin [dB] (3G) -> the minimum value accepted as valid input for the 3G
analysis & optimization process; all samples with values less that this value will be
discarded for the neighbors optimization process performed by Agileto;

RSCPMin [dBm] (3G) -> the minimum value accepted as valid input for the 3G
analysis & optimization process; all samples with values less that this value will be
discarded for the neighbors optimization process performed by Agileto;

Active Set Delta [dB] -> this is the accepted range interval below the real Top_1
best server where all the others detected Top_X servers may be formally considered
as Top_1 reference server against all the others available Top_Y servers (where the
strength of the Top_Y <= Top_X) for the neighboring optimization purpose. This
approach increase the chance to detect optimum all the necessary and potential
neighbors relationships by analyzing the neighbors relations Top_X -> Top_Y even
when the Top_X is not the real Top_1 but the Top_X is inside of this range interval
below the real Top_1 best server; all the Top_X servers detected below this interval
range against the real Top_1 best server will be discarded (they will not be formally
considered as Top_1 reference server for all the others detected Top_Y servers,
where the strength of Top_Y <= Top_X); this range (value) may be chosen in
conjunction with the event e1a in case of the 3G-3G neighbors analysis.

Monitor Delta [dB] -> this is the monitor range interval accepted for the neighboring
optimization purpose below the Top_X servers (which may be treated sometimes as
Top_1), in line with the idea mentioned above regarding Active Set Delta where the
Top_X may be considered formally at some time like the Top_1 reference server
against all the others Top_Y (where the strength of the Top_Y <= Top_X); all the
Top_Y servers detected below the monitoring range against the Top_X will be
discarded from the neighbors analysis and optimization process; this approach
increase the probability of getting only the necessary neighbors relationships and this
range value may be chosen in conjunction with the event e1b in case of the 3G-3G
neighbors analysis.

Notice:
Agileto tool has extended the same 3G Active Set & Monitor Delta concepts
presented above on the 2G & 4G technologies for the neighboring analysis purpose.

RSSIMin [dBm] (GSM) -> the minimum value accepted as valid input for the 2G
related to the 3G-2G or 2G-2G neighbors analysis & optimization process; all
samples with values less that this value will be discarded from the neighbors
optimization process performed by Agileto;

Page 150 of 253 www.agileto.com

Agileto_Help_V7.19.docx

RSRP_Min [dBm] (4G) -> the minimum value accepted as valid input for the 4G
analysis & optimization process; all samples with values less that this value will be
discarded for the neighbors optimization process performed by Agileto;

3G/4G Frq Layer [Source] -> This is the 3G/4G frequency layer associated to the
drive test measurement data contained by default into the 1st Drive Test file (if there
are provided two Drive Test input files) or which is provided on the “left” side in
case only one Drive Test file is provided.

3G/4G Frq Layer [Target] -> This is the 3G/4G frequency layer associated to the
drive test measurement data contained by default into the 2nd Drive Test file (if there
are provided two Drive Test input files) or which is provided on the “right” side in
case only one Drive Test file is provided.

nrBS [Source] -> This is the number of the top Best Servers detected as exported
into the Drive Test measurements (Source) file; although this value may be detected
initially as “1” due to the accepted Drive Test file format (check into the Annex the
Top_X different lines format) the real value will be calculated by Agileto during
post-processing the data and it will be reported properly on the output results.

nrBS [Target] -> This is the number of the top Best Servers detected as exported
into the Drive Test measurements (Target) file; although this value may be detected
initially as “1” due to the accepted Drive Test file format (check into the Annex the
Top_X different lines format) the real value will be calculated by Agileto during
post-processing the data and it will be reported properly on the output results.

Minimum weight Neighbors contribution [%] -> If the neighbor relationship

between the cells A->B is outcome as possible by a number [N] of occurrences
detected for this relationship (A->B) then the weight (W) of this number of
occurrences is W=N/TotalOccurences [%] where TotalOccurences are the total
occurrences for all potential neighbors relationship related to the cell A). This
parameter impose that W should be greater or equal than the imposed threshold input
value in order to accept A->B as a valid neighbor relationship; in contrary case the
relation detected A->B will not be proposed by Agileto as a potential neighbor
relationship.

Top_X (To be represented) -> This is the number of the Top_X best servers to be
outputted and represented by Agileto in Google Earth environment; supposing that
the number of the Best Servers exported into the Drive Test measurements file is 6
than only the first Top_X (Ex when X= 3 -> Top_1 + Top_2 + Top_3) best servers
will be represented as dedicated representations into Google Earth; usually this is
recommended to be kept = 1 and only for special analysis to be chosen as desired
(usually the Top_1 best server is giving enough information about the general drive
test coverage pattern).

Page 151 of 253 www.agileto.com

Agileto_Help_V7.19.docx

GE neighbors lines have variable widths (up to nr of occurrences) -> Selected by

default, should be used if you want that the neighbors lines proposals suggested by
Agileto for each cell to be displayed into Google Earth with variable (proportional)
width lines according with the number of occurrences detected per each neighbor
relationship; if this option is not selected than all the neighbors proposals suggested
by Agileto will be displayed into Google Earth with the same lines width.

Radius [Km] (Reference 3G_F1) -> This is the radius [Km] of the 3G_F1 Reference
cell (3G frequency layer F1) to be considered for the good representation of all the
neighbors which are going to be generated and displayed in Google Earth; it should
be used for the good matching of the neighbors lines the same value which has been
used when generating the 2G/3G/4G mobile networks by using the module M1.2.

GE movie summary per points -> When this option is selected while running into
Google Earth the movie tours “ActiveSet_RePlay” or “ActiveSet_NbMiss” the
summary info related to each point from the drive test is presented dynamically into a
dedicated balloon; if this option is not selected then the summary info for each point
of the drive test is no more presented and are presented only the links between the
drive test measurement point and the cells (from Active Set) which the mobile should
be in communication at that time according with the input (Active Set Delta)
provided initially; the Top_1 best server will be displayed always with the green line
while the other cells concurrent in Active Set will be displayed with yellow color; in
case that a concurrent cell from the Active Set is not already detected as neighbor
declaration with the Top_1 best server then the line between the measurement point
and that cell is colored in red; all subcases detected like missing neighbors from
Active Set will generate the movie tour “ActiveSet_NbMiss” which is practically a
collection of subcases from the movie tour “ActiveSet_RePlay”.

GE shows NB Deletions in Proposals -> When this option is selected then into the
final Google Earth neighbors proposals configuration will be inserted with the pink
colors all the existing neighbors declarations which are recommended to be deleted
due to the fact that they were not detected during the drive test analysis.

Export Bin Data -> When this option is selected then all the Top_X best servers
detected and ranked into descending order on each bin are exported after the spatial
binning operation is performed; these *.csv files are exported and saved on the same
path location where the Drive Test network optimization files are saved.

Observation:
The 3G/4G Frq layer [Source/Target] association is very important to be performed
properly as it may lead to erroneous results if the data recorded by the UE
(scanner/mobile) device was related to one specific Frequency Layer and the
association was made with another Frequency Layer.

Page 152 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Up to the experience and the knowledge of the RF Optimization Engineer + the

specific settings already existing into the real 2G/3G/4G mobile networks - which
trigger the different events (ex: e1a/e1b) - there is an optimal set for several inputs
which have been mentioned above and which may be changed when providing the
entire set of the inputs.

By default, the end user may keep the default proposed input values as they have
been already tested extensively in many cases but obviously that the fine tuning may
take place in order to get the optimum output results.

When Agileto has completed the calculations and already generated the output
results, the Network optimization report Excel file will remain displayed (open) into
the background and a similar message like the one below will be displayed.

Page 153 of 253 www.agileto.com

Agileto_Help_V7.19.docx

It is important to mention that the network optimization output results are saved into
special folders generated automatically by Agileto under the path
…\Project\DriveTests\DT_Optimisation respectively under the MapInfo and
GoogleEarth \ DriveTests \ paths folders. The name of these folders is always the
same (Ex: Bin5m_DEMO_Drive_3G_3G3G_F1F1) being composed by the size of
the bin square selected initially (Ex: Bin5m when spatial binning is selected),
followed by the name of the Drive Test measurements input file (Ex:
DEMO_Drive_3G) followed by the analysis type performed (Ex: 3G3G_F1F1).

The Drive Test Network Optimisation report Excel file (Ex:

Bin5m_DEMO_Drive_3G-3G3G_F1F1_DT-NWOptim.xls) contains three sheets
(Neighbors / Overshooters / CrossSect+Coverage) presenting the analysis and
optimization results performed by Agileto based on the Drive Test measurements
input file (notice: the sheet Overshooters is generated only for the 2G and 3G/4G
IntraFrequency analysis). =>

The format and the information presented into all the sheets Neighbors/
Overshooters / CrossSect+Coverage will be presented further.

In order to see the output results in MapInfo or Google Earth you may use the module
M1.4 as per below, by selecting the right options:

For each DTO analysis there are three options which may be selected to load and
visualize the output results in Google Earth, as following:

Page 154 of 253 www.agileto.com

Agileto_Help_V7.19.docx

 Load Audit results -> This option will load into Google Earth the file named
“Drive_Test-Audit.kmz” which contains the following information:

 Load Main / Optimisation results -> This option will load the file named
“Drive_Test.kmz” which contains the following standard information:

 Load Cells Coverage results -> This option will load the file named
“CellsCoverage.kmz” which contains the coverage points detected for each
cell along the drive test.

All the output optimization info presented above will be presented further in details.

Page 155 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The output files for MapInfo are different tables (*.tab files) similar like presented
above for Google Earth and they are already integrated into the workspace MapInfo
file named “Drive_Test.wor”.

Returning to the formats of the Drive Test Neighbors / Overshooters /

CrossSect+Coverage optimization report(s), they can be summarized as following
(some screenshots will be presented further to provide the right exemplification).

Neighbors (Analysis and Optimisation): =>

This Excel report presents the selected Source-Target technology (2G/3G/4G)

analysis in successive lines representing all the combinations between the Cell Source
– Cell Target relations (neighbors) detected during the drive analysis. All the detected
combinations Cell Source – Cell Target are sorted descending per each reference
Source Cell by taking for sorting the number of occurrences which represents how
many times the combination Cell Source – Cell Target has been detected during the
entire drive test analysis.

The columns are presented into the final report from the left to right as following:
 Cell Source details:
3G: RNC/LCID/CellName/PSC/EcNoAvg|Min|Max/DistAvg|Min|Max;
(2G: LAC/CID/CellName/BCCH/RSSIAvg|Min|Max/DistAvg|Min|Max);
(4G: TAC/eNBid|cId/CellName/PCI/RSRPAvg|Min|Max/DistAvg|Min|Max);
 Cell Target details:
RNC/LCID/CellName/PSC/EcNoAvg|Min|Max/DistAvg|Min|Max;
 Cases detected between Target cells with wrong PSC planning/allocation;
 Source-Target combination with different parameters/status, as following:
o Distance;
o Source->Target [and reverse T->S] Inside Beamwidth evaluation;
o Number of Occurrences detected and the associated weight in percentage;
o Existing as neighbor declaration [Yes(1)/No(0)] evaluation;
o Source Number of Neighbors declared/detected/sib11andDch flag allocations;
o For the target 2G technology there are presented the number of cases when
BSIC was decoded / verified properly (especially if scanner device is used);
o The last columns present the info including the new “Priority allocation”
proposal based on the Drive Test measurements data as well as the info related
to the “Neighbors Status” as Detected / Missing (LI) / NotDetected;

When the weight given in percentage [%] (representing by the number of occurrences
Cell Source -> Cell Target) becomes lower than the input imposed target (Ex: 1%)
then the Priority allocation will be set as negative, the Neighbors Status becomes
Missing LI (stand for Low Importance) and that means that the respective neighbor
relationship is no more considered to be included into the final neighbor list proposal.

The report ends with the Summary info + the Drive Test collection data
performance. For more details please have a look into the next screenshots.

Page 156 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-3G Drive test Neighbors Optimization report – Part 1:

Page 157 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-3G Drive test Neighbors Optimization report – Part 2:

Page 158 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-2G Drive test Neighbors Optimization report – Part 1:

Check on the above screenshot the warning cases detected as “Wrong Target BCCH planning” (see above the columns colored in
pink); each such of case is detected when the UE is under the coverage of one source cell and there are detected as potential neighbors
at least two different 2G cells which share the same BCCH. Obs: More than two lines may be detected as belonging to the same case.

Page 159 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-2G Drive test Neighbors Optimization report – Part 2:

Page 160 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of the Summary Drive test Neighbors (Overshooters) Optimisation report (written at the end of the data):

All the main input and output information (data) is synthesized into the summary presented as per into the above screenshot.

Page 161 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Overshooters (Analysis and Optimisation): =>

This report (sheet) presents all the cells detected as “Overshooters” following the
principle which state that during a drive test the cells combination Source Cell ->
Target Cell is detected with some occurrences during the Drive Tests neighboring
analysis but the reciprocally combination (Target Cell -> Source Cell) is Not
detected. This case we may assume that the Target Cell is an overshooter.

In order to have a common understanding of the “Overshooter” cells, lets define

them they are cells which have a relative important signal level into an area (situated
far from their main “Overshooter” coverage area) which is close to the main
coverage area of the “Affected Cells”; this case we may say that the “Overshooter”
cell is polluting the “Affected Cells” or simply, the “Affected Cells” are polluted by
the “Overshooter” cell.

The technical description of the “Overshooter” cell may be the following, as well:

When the UE (mobile) is under the main coverage area of the “Affected Cell”
(polluted cell) during the drive test it may detect as well the signal coming from the
“Overshooter” cell but when the UE moves away from the main coverage area of the
“Affected Cell” and the UE enters under the main coverage area of the
“Overshooter” cell it has no more the detection of the signal coming from the
“Affected Cell”.

In other words the following type of relationship combinations have been detected
during the DT analysis:
 “Affected Cell” [strong signal] -> “Overshooter” [signal] is detected;
 “Overshooter” [strong signal] -> “Affected Cell” [signal] NOT detected.
Conclusion: We may say simple that the reciprocity is no more detected!

All the overshooters cells detected in line with the above definition have been sorted
in descending order based on the number of their associated “Affected Cells” and for
each overshooter cell all its associated “Affected Cells” are sorted in descending
order based on the number of occurrences related to the combination detected
Affected Cell -> Overshooter Cell.

All the above mentioned rules have been used for the visual representation of the
overshooters in Google Earth environment and when one overshooter cell is selected
all its “Affected Cells” are linked by lines (similar with the neighbors presentation)
with a figure near each “Affected Cell” presenting its importance according with the
number of the combination detected Affected Cell -> Overshooter Cell.

The next screenshots present some overshooters tables examples followed later into
this document by their associated visual Google Earth representations examples
generated automatically by Agileto.

Page 162 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Example of the Drive test Overshooters report – Part 1:

Page 163 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Example of the Drive test Overshooters report – Part 2:

Page 164 of 253 www.agileto.com

Agileto_Help_V7.19.docx

CrossSect+Coverage optimization report: =>

This is a table report that is delivered into its dedicated Excel sheet presenting the
Cross Sector + Coverage areas (Top1/ASet/Full) cells analysis provided automatically
by Agileto tool when finishing the execution of the module M4.1.

Cross Sector evaluation:

When Agileto is processing the drive test data there are calculated for each cell the
following four metrics in two analysis (Cell is detected in Full(All) coverage versus
Cell is detected as the Top1 Best server) see the above example:
 Cvg Points -> Total nr of points where the Cell is detected in the drive test;
 Cvg PtsGood [%] -> Points detected inside Cell’s antenna beamwidth [%];
 Cvg PtsBad [%] -> Points detected outside Cell’s antenna beamwidth [%];
 CrossSector -> TRUE/FALSE (TRUE if Cvg PtsBad [%] > PtsGood PtsBad [%])

The quick way to evaluate (almost sure) during the drive test the cases detected like
having the Cross Sector is to filter on TRUE both (or only one) CrossSector
parameters for CvgAll and/or Top1.

To validate the results we need to double check all the resulted cells and for each cell
we need to check visually on Google Earth the Cell’s coverage (already generated by
Agileto) presenting the lines between the cell edge and all the points where the cell
was detected as Top1 or Full(All) (see below a real cross sector case detected).

Page 165 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Coverage areas (Top1/ASet/Full) evaluation:

The Drive test Coverage area for one cell is an original concept developed by Agileto
in order to evaluate how much a cell is detected during the drive test on its surrounding
area based on the following approach:

Step 1:
We design a circle with its geographically center placed on the same location like the
cell under investigation and divide it in number of equal sectors (each sectors having
the same angle of 1 degree). We get a number of 360 distinct sectors (S = 1 to 360);

Step 2:
We browse between all of the Drive Test points where the cell under investigation was
detected in a specific range (Top1/ASet/Full) and evaluate the following two data:
1) Which is the sector (S) where the drive test measurement point is detected inside;
2) Which is the distance (D) between the drive test measurement point and the
geographically cell position;

Step 2 continuation:
If another drive test point where the cell was detected before has been already
evaluated inside of the same sector (S) like the one just evaluated then it is compared
the distance (D) just calculated with the old one (D_old) corresponding to the other
point and finally it is retained for the sector (S) the maximum (D_max) between the
two (D and D_old).

When finish to browse all the drive test measurements points where the cell under
investigation is detected in a specific range (Top1/ASet/Full) we will get finally for
each sector (S = 1 to 360 degrees) a specific distance D_Max according with the
detection (or not) of the cell inside of each sector (S) as per described above.

If we generate a new set of points for each sector (S = 1 to 360) each one placed at its
specific distance (D_Max) and finally link all of them we get a polygon whose area is
easy to evaluate and it represents the drive test Cell coverage area for that cell detected
in that specific range (Top1/ASet/Full).

Coverage Top1 -> Area of the polygon where the cell was detected as Top1
Coverage ASet -> Area of the polygon where the cell was detected in ASet
Coverage All -> Area of the polygon where the cell was detected everywhere

If the Cell Coverage areas related to different Cell ranges are available it is interesting
to see which is the Cell coverage performance by comparing the cases when the cell is
in a specific range (Top1/ASet) with the reference case when the cell is everywhere ->
Full (All) coverage. Consequently the following two metrics are defined:
Cvg_Top1 Efficiency = Coverage Top1 / Coverage All [%]
Cvg_ASet Efficiency = Coverage Aset / Coverage All [%]

Page 166 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Based on the original drive test Cell coverage area concepts presented above, Agileto
is evaluating all of them for each cell detected during the drive test. The results are
provided in both tabular way and visually in Google Earth representations like you
may see into the screenshots below.

Below is presented an example related to the Cell Top1/ASet/Full coverarage areas:

Page 167 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Checking and interpreting the results in Google Earth and MapInfo:

a) Load Audit results -> This option will load into Google Earth the file named
“Drive_Test-Audit.kmz” which contains the following information:

GPS_Static / GPS_Invalid -> represent the ‘problematic’ points where ‘No mobility’
was detected or ‘No GPS info” was provided. If ‘No GPS info” is detected the points
are displayed on the map on the previous correct point detected.

MeasS_Invalid / MeasT_Invalid -> This are the points where no valid Source/Target
signal information was received;

Google Earth (GE) representation for these cases will look like this:

Page 168 of 253 www.agileto.com

Agileto_Help_V7.19.docx
ActiveSet_RePlay -> represents the movie (Google Earth tour ) which shows the links
between each drive test measurement point and all the cells from Active Set which the
mobile should be in communication at that time.
Top_1 best server will be displayed always with the green line while the other cells
concurrent in Active Set will be displayed with yellow color.
In case that a concurrent cell from the Active Set is not already declared as neighbor
with the Top_1 best server then the line between the measurement point and that cell is
colored in red; all subcases detected like missing neighbors from Active Set will
generate the movie tour ActiveSet_NbMiss which is practically a collection of
subcases from the movie tour ActiveSet_RePlay.
Below it is presented a screenshot example from ActiveSet_RePlay:

Load Main / Optimisation results -> This option will load the file named
“Drive_Test.kmz” which contains the following standard information:

Page 169 of 253 www.agileto.com

Agileto_Help_V7.19.docx
ActiveSet_RePlay: There is the general overview about how it looks the movie tour for the Active Set radio links:

Page 170 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Summary: There is always a summary folder describing in synthesis the Project inputs and outputs information like below:

Page 171 of 253 www.agileto.com

Agileto_Help_V7.19.docx
GPS_Route: It displays with black points the entire drive test route::

Page 172 of 253 www.agileto.com

Agileto_Help_V7.19.docx
ActiveSet_Size: It displays the Active Set size (simulated for 2G & 4G) as per it was evaluated by Agileto

Page 173 of 253 www.agileto.com

Agileto_Help_V7.19.docx
ActiveSet_Size: Display Active Set Size info in MapInfo environment with few other options available:

Page 174 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Google Display only selected interval Legend (If desired only the points belonging to selected interval Legend may be displayed):

Page 175 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Top1_EcNo: It displays the Top1 EcNo which can be checked in details at point level:

Page 176 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Top1_RSCP: It displays the Top1 RSCP which can be checked in details at point level:

Page 177 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Top1_CellsCoverage: It displays by colored lines (following the legend color) the points where the cell selected was the Top1:

Page 178 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Area_CellsCoverage: It displays by polygons the areas where the cell selected was in Top1/ASet/Full coverage:

Page 179 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Overshooters: It displays lines between the overshooter selected cell and all its affected (polluted) cells:

Page 180 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NB_Proposals: It displays the lines between the selected cell and all its neighbors proposals (missing neighbors have the red color):

Page 181 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NB_Missing: It displays the red lines between the selected cell and all its missing neighbors detected (purple lines for missing LI):

Page 182 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NB_NotDetected: It displays the pink lines between the selected cell and all its neighbors declarations NOT detected in Drive Test:

Page 183 of 253 www.agileto.com

Agileto_Help_V7.19.docx
NB_WrongPlanPSC: It displays the case(s) selected (1 below) when two potential neighbors are sharing the same PSC (135 below):

Page 184 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Load Cells Coverage results -> This option will load the file named “CellsCoverage.kmz” which contains the coverage points
detected for each cell along the drive test.

Please notice that by performing this action your computer’s processor will start to be under very high activity due to Google Earth
requests caused by the very high numbers of points and associated lines which should be evaluated and mapped for each cell as its cell
coverage lines; especially you may notice on Google Earth application that it may look like frozen (although if you are waiting an
important amount of time finally it may start to behave normally).

Due to the potential issue mentioned above it is not really recommended to use frequently this option in order to avoid freezing your
application.

To overcome this potential issue mentioned above of freezing your Google Earth application when loading this option, you may use
for the Full Cell coverage evaluation instead the Area_CellsCoverage option (already presented before) and select under the desired
cell only the Full coverage area polygon (like it is presented below by overlapping both representations in Google Earth).

Page 185 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Full_CellsCoverage: It displays by colored lines (following the legend color) all the points where the cell was detected in Drive Test:

Page 186 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Conclusions:

When Agileto has completed the execution of the module M4.1 (Drive Test
Optimisation) the OMC/RF Engineer may proceed with the following actions:

 Based on the Neighbors optimization report it has already the following outputs
which may serve him/her to optimize straightway the neighbors declarations based
on the data collected during the drive test:
 Neighbors Proposals -> this is the final and optimal neighbors configuration
proposed by Agileto for each cell based on the drive test measurements data;
 Neighbors Missing -> these are the neighbors proposals which have not been yet
declared as neighbors (they should be added as neighbors);
 Neighbors NotDetected -> these are the neighbors declared into the network
which have not been detected during the drive test or which have been detected
with a low number of occurrences (the weight was lower than the imposed
threshold); these neighbors are candidates for the list of deletion but this will be
treat with caution (based on their visually representation in Google Earth) due to
the particular drive test routes/ways which may lead to false decisions in case the
drive test was not performed dense enough into that specific area.
 Based on the Overshooters report it may analyze directly into Google Earth all the
overshooters detected (already sorted out since the most important overshooter
detected up to the less important overshooter detected by their corresponding number
of “Affected Cells”); if necessary, suitable antennas downtilt proposals should be
provided for the shortlisted overshooters selected and verified.
 To complete this analysis the user may use the representation in Google Earth of
the Top1_CellsCoverage as well as of the CellsCoverage by checking where the
overshooters cells have been detected as the Top_1 best server and where it was
detected for the ‘Full’ coverage during the drive test (the coverage lines will
indicate the coverage areas and the color lines will indicated the signal strength).
 Area_CellCoverage tables and visual GE representations can be used, too.
 Another important optimization output is the list of the cases detected and flagged by
Agileto with Wrong planning BCCH (2G) / PSC (3G) / PCI (4G); these are the
cases collected when a “source” cell is detected to be in potential neighboring
relationship with at least two different “target” cells which share the same
BCCH(2G) / PSC(3G) / PCI(4G). These cases have been represented by Agileto in
Google Earth and based on their quick visual checking it may be decided if the
BCCH/PSC/PCI allocation should be (re)planned again for those specific cells (for
the purpose of BCCH(2G)/PSC(3G)/PCI(4G) (re)allocation we can use the modules
M2.2 and/or M2.3).
 Cross feeders automatically detected cases provided by Agileto should be checked
visually in GE by using the methodology presented before in details. The validated
cases should be highlighted to the maintenance team and corrected asap.

The drive test optimization actions presented above may be doubled / completed by the
optimization actions based on the Call Traces, as they are described into the next
chapter.

Page 187 of 253 www.agileto.com

Agileto_Help_V7.19.docx

4.2) Network Optimisation based on Call Traces

The purpose and the target of this module is to provide (automatically - without human
manual intervention - by using SON [Self Optimized Network] principles) the Network
optimization actions (with focus on neighbors and overshooters) necessary to be
performed into the 3G network (3G-3G IntraFrequency + InterFrequency + 3G-2G
InterRat) based on the real signalization data exchanged over the 3G network and
collected for a limited period of time into the Call Traces files.
The major three advantages of using this module for network optimizations are:
1) The results are based on the real traffic distribution over the 3G network and not on
simulations therefore the final reports and proposals will be as closed as possible to
the reality => very high level of confidence into the final results;
2) The associated costs related to this method are practically ZERO compared with the
traditionally way of performing the neighbors optimization based on the drive tests;
by comparison, the drive tests involve usually high costs and they are time expensive
in order to produce, post-process and analyze them; they may not even collect the
data statistically properly comparing with the real traffic distribution over the
network => the final decisions may not be optimized for the real network;
3) The human resources work force allocation for this task is practically ZERO if we
compare again with the traditionally drive test method. The tool is processing by
itself all the inputs data based on intelligent algorithms and is generating the output
results as a sum of actions/corrections to be performed into the 3G network like
adding/removing specific neighbors -> ready to be implemented straight into OMC.

Select the section 4) Network Optimisation (audit + proposals), then M4.2.

Choose OK and you will get the following window:

Page 188 of 253 www.agileto.com
Agileto_Help_V7.19.docx

-> The Call Traces (*.tab/*.xml) files should be a set of files collection recorded by the
mobile operator (internal tracing) for the purpose of network (neighboring)
optimization. These type of file(s) have been generic called at the beginning of this
Detailed User Guide as the File #3 (see chapter “Before you start”). Up to the 3G
vendor equipment they may be provided in different formats and they may collect
specific information during the collection time.

For example, in case of Ericsson 3G vendor equipment, the call traces collected are so
called GPEH traces and they should record the following (RNC internal) events:
 INTERNAL_SOFT_HANDOVER_EXECUTION
 INTERNAL_SOHO_DS_MISSING_NEIGHBOUR
 INTERNAL_IFHO_REPORT_RECEPTION
 INTERNAL_IRAT_HO_CC_EXECUTION

For Alcatel-Lucent 3G vendor equipment, the call traces collected are so called CTN
and they should use the Neighbors Optimisation template available.
For full details regarding the collection and format of the Call Traces up to the specific
3G vendor equipment please do not hesitate to contact us ([email protected]).

-> OMC 3G snapshot file contains the 3G/2G network configuration details and may be
obtained in different formats: *.xml, *.xcm, *.txt - up to the 3G vendor - File #1 (see
chapter “Before you start”).
After providing the relevant information, choose OK and you will get the main form
where you need to set different parameters related to this specific module.

The main form of this module is looking like the screenshot below. You will have here
different options to setup as they will be explained further.

Page 189 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Page 190 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Here you have several options. It is possible to review (top area) the settings provided
into the previous form (window) and additionally, there is a set of parameters to be
provided as input for post-processing the call traces data.

As an important and special feature of this module, it may be possible to re-analyze the
Call Traces already analyzed one time in advance by selecting the option B) from the
screenshot presented above; this consists in providing as inputs for this module the Call
Traces 3G-3G and 3G-2G analysis reports already generated one time in advance
instead of providing as inputs the originally (*.xml/*.tab) call traces files. This is a very
powerful feature of this module as it requires just few minutes of (re)processing time
comparing with few hours how it may take initially when processing the originally call
traces files, depending of the Call Traces collection interval of time.

Regarding the CT (Call Traces) post-processing settings section you may provide
different inputs, as following:

 There are different filtering criteria options you may select for ‘abnormal cases’;
 You need to impose for each neighbors category [IntraFreq/InterFreq/InterRAT]
the maximum number of neighbors as well as the total number of neighbors
having sib11andDch flag allocation (these settings are made up to the mobile
operator strategy as well as up to the 3G vendor capabilities);
 You need to impose for each [S (Source) ->T (Target) combination detected]
neighbors category the minimum weight contribution [%] in order that specific
S->T combination detected to be validated as neighbor relationship;
 Additionally output Neighbors settings are available like:
o Keep always the neighbors co-site neighbors declarations;
o Neighbors priorities should start with the value 0 or 1;
 You need to select the type of the reports to be generated (by default are selected
all that means 3G->3G Neighbors / 3G Overshooters / 3G->2G Neighbors);
 Some other additionally settings may be performed (ex: neighbors reciprocity
desired between different layers /etc).

After you choose all the desired options, please push OK button and when the module
completed the calculations you will get a similar message like the one below
(meanwhile you will see a progress indicator bar informing about the status of the post-
processing data like it will be presented further):

Page 191 of 253 www.agileto.com

Agileto_Help_V7.19.docx

As output, three types of the Call Traces analysis reports are provided as following:
1) Call Trace analysis regarding 3G-3G neighbors optimization;
2) Call Trace analysis regarding 3G-2G neighbors optimization;
3) Call Trace analysis regarding 3G Over-shooters cells;

Summary conclusion regarding the Call Traces Network Optimisation method:

The results of this method are provided into three main outputs (directly into the
generated reports) including all the necessary changes to be performed into the 3G
network in order to optimize the neighbors declarations, detect and correct the
overshooters cells to improve the KPIs general performance, as following:

A) The new Network Neighbors Proposal (final optimized configuration);

B) All types of the neighbors optimization changes to be performed, as following:

1) Neighbors to be deleted;
2) Neighbors to be added;
3) Neighbors to be changed (priority and/or sib11anddch usage);

C) Detected Overshooters cells.

All the neighbors changes proposals mentioned above are provided for each type
of the neighbors declarations, as following:
a) 3G->3G Intra-Frequency
b) 3G->3G Inter-Frequency
c) 3G->2G Inter-RAT

Page 192 of 253 www.agileto.com

Agileto_Help_V7.19.docx

To Remember:
All the three main outputs presented above (Proposals/Changes/Overshooters) are
generated in *.csv tables files as well as they may be visualized straightway in MapInfo
& Google Earth by using the modules M3.3 respective M1.4.

(Re) allocation of the neighbors priorities and the sib11orDch flags is performed during
the optimization process based on real network traffic distribution and weight:

1) Each new neighbor proposed to be added it is provided with the optimum priority to
be allocated as well as with the optimum type of sib11orDch allocation based on the
specific limitations imposed initially caused by the 3G vendor provider or by the mobile
telecom operator strategy (and obviously based on its specific weight extracted and
calculated from the Call Traces post-processed results).

2) The remaining neighbors (which were not proposed to be deleted) are reallocated
with the new sib11orDch flags and priorities based on this new optimized method
involving the real customer traffic repartition and the weight detected into Call Traces
collected during that period of time.

The list of the suspected Overshooters cells:

This method of network optimization provides additionally as output the list of the cells
suspected to act as overshhoters (together with all their associated affected target cells
grouped per each overshooter cell).

This shortlist containing the suspected overshooters cells may be used straightway by
the RF Optimization engineers in order to quickly verify the correctness of these
detected overshooters/polluters cells; if necessary, after the positive detection as
overshooters (visually / planning tools / drive tests) antennas down-tilts proposals
should be provided as appropriate.

FINAL CONCLUSION:

Like it was already mentioned since the beginning of this chapter, the efficiency and the
network optimization performance obtained by using this method is very high as the
human resources work force allocation for this task is reduced to the minimum
(practically to ZERO) if we compare with the standard drive test method involving a lot
of the money spent and time consuming.

On another side, the final results are much more accurate comparing with the
traditionally drive test method because the Call Traces are using the real signalization
data from the real mobile network customers in time that the drive test may just collect
partial data that may not be always customer representative.

As a general conclusion, this method is highly recommended to be used and

maintained regularly into the mobile network optimization process.

Page 193 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Additionally, this method is mandatory to be performed as the first step especially

when new features are going to be tested into the mobile networks on specific
clusters in order to avoid the abnormal KPIs results which may be generated just
due to the poor neighbors optimization allocation process and the presence of an
important number of overshooters (the poor neighbors optimization allocation
process may be the result of its completion based only on visual mobile network
representation even eventually improved with the limited info which may come from
limited drive tests which cannot be statistically representative).

Page 194 of 253 www.agileto.com

Agileto_Help_V7.19.docx

In order to have the better idea about the progress and status of this module there is displayed a progress bar (like presented below)
presenting the level of the percentage completed together with different other associated details (very usefully for large numbers of
CT amount of data which may lead to an important processing time to complete).

Notice: The similar type of the progress bar (like below) is displayed for all the others modules of this tool.

Start time related to Order number and the It is presented the total size of the remaining Estimated End Time
ongoing process / name related to ongoing CT (*.xml) traces files still to process and the related to ongoing
task process / task associated estimated required time. process / task

There is a second progress bar (like it is presented below) showing the summary progress and the post-processing status for each CT
(*.xml/*.tab) file to be loaded related to all (CT) traces detected as inputs.

Start time related to Order number and the It is presented the total size of the Estimated End Time
ongoing CT (*.xml) name related to ongoing ongoing CT (*.xml) file to be post- related to ongoing
processing file CT (*.xml) processing file processed. CT (*.xml) file

The next screenshots will present some examples for each type of the three above mentioned Call Traces analysis reports.

Page 195 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-3G Call Trace Neighbors Optimisation analysis report, Part 1:

There are evaluated all the 3G-3G

Additions/Deletions/Detections Sib11 and Priority allocations values
and their specific ratios for S->T and reciprocally [T->S]
are retrieved from the snapshot.

In case of Detections then

There are evaluated all the S->T EcNo Avg/Min/Max
(Source-Target) combinations values are provided
detected into CTn (*.xml) traces

The New Priority allocation is The New Priority allocation for

based on this column ranking S->T and reverse T->S

Summary Neighboring info is provided

for each 3G (Source) cell before all
S->T combinations detected.

Page 196 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-3G Call Trace Neighbors Optimisation analysis report, Part 2:

S->T Operation to be performed:

A->Addition;
D->Deletion;
C[P/S]-> Change Priority/Sib11

Final configuration proposal:

1->Neighbor Exist
0->Neighbor doesn’t Exist

Different Parameters like

Name/Code/RNC are
provided for S & T

Frequency Layers related to

Source [S] and Target [T]
Geographically evaluations are
provided for each S->T

There are evaluated all the S->T Number of times when the The New sib11orDchUsage
(Source-Target) combinations Target cell was seen allocation (for S->T)
detected into CTn (*.xml) traces as ‘Overshooter’

Page 197 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G Call Trace analysis Overshooters report:

In case of Detections then

EcNo Avg/Min/Max Frequency Layer related
values are provided to Overshooter [O]

There are evaluated all transitions

Additions/Deletions/Detection
s between T->O
Geographically evaluations are
provided for each O->T

Different Parameters like

For each Overshooter it is a Summary
Name/Code/RNC are
line providing the following:
1) localCell_ID provided for ‘O’ & ‘T’
2) Cell_Name
3) Nr of Target cells affected by the overshooter

It is provided the entire list of

the Target cells affected
by each Overshooter

Page 198 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-2G Call Trace Neighbors Optimisation analysis report, Part 1:

The New Priority allocation is

based on this column ranking

There are evaluated all [CS & PS]

3G-2G Attempts/Failures/SR[%]

Sib11 and Priority allocations values The New Priority allocation

for each 3G-2G [S->T] which are proposal for 3G-2G [S->T]
retrieved from the snapshot.
Geographically evaluations are
provided for each S->T S->T Operation to be performed:
A->Addition;
There are evaluated all the 3G->2G D->Deletion;
[S->T] (Source-Target) combinations C[P/S]-> Change
detected into CTn (*.xml) traces Priority/Sib11

Each 3G (Source) cell contains a

summary line with regards
to All the 3G2G activity
(Attempts/Failures/SR[%])

Page 199 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of 3G-2G Call Trace Neighbors Optimisation analysis report, Part 2:

3G Source & 2G Target

Names & Codes
are provided

S->T Operation to be performed: The New sib11orDchUsage

A->Addition; allocation for the 3G-2G
D->Deletion; combination detected
C[P/S]-> Change Priority/Sib11 [S->T]

Different set of Parameters for

The New Priority allocation 3G Source & 2G Target are
proposal for 3G-2G [S->T] provided like:
• 3G Frq Layer
• 3G RNC
There are evaluated all the 3G->2G • 2G LAC
[S->T] (Source-Target) combinations • 2G BCCH
detected into CTn (*.xml) traces

Page 200 of 253 www.agileto.com

Agileto_Help_V7.19.docx

At the end of each analysis report there is generated a summary info where all the inputs/settings parameters used for post-
processing the data are recorded, as well as the all the CT (*.xml/*.tab) files processed as input data; some additionally info for each
CT (*.xml/*.tab) file is appended to this info as well as the validation for each CT file, like into the screenshot presented below.

Few neighbor optimisation examples represented in Google Earth based on this method are presented into the next screenshots.

Page 201 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Example of neighbors proposal -> remark the priorities & the width of the neighbors lines meaning the traffic weight from cell source to cell target:

Page 202 of 253 www.agileto.com

Agileto_Help_V7.19.docx
The same Sourse cell as before presenting the neighbors to be deleted based on the low traffic distribution (toward Target cells) on the real network:

Page 203 of 253 www.agileto.com

Agileto_Help_V7.19.docx
The screenshot below presents an example of an Overshooter detected cell (the most “Affected Cells” are displayed by their order and “weight”):

Page 204 of 253 www.agileto.com

Agileto_Help_V7.19.docx

4.3) Process Drive Test log files (NEMO, TEMS, etc)

To watch on-line the related video training for this module click on the links below:
DT log files processing (Nemo): https://youtu.be/w0aukB4jKxE
DT log files processing (Tems): https://youtu.be/91Th8iD6kCE

In order to perform the drive test optimization activity by using Agileto tool, the
original drive test log files collected by different drive test acquisition tools (NEMO,
TEMS, XCAL, etc) need to be converted to specific input files formats accepted by
Agileto tool (for details please check the Annex named “Drive Tests measurements
(scanner/mobile) file”) and this action can be performed directly or indirectly by
using Agileto dedicated module M4.3 like it is presented below.

There are two categories of the drive test log files accepted as input for this module:
NEMO files (*.nmf) or TEMS Export file (*.fmt/*.txt).

A) Nemo files (*.nmf):

Nemo (*.nmf) drive test log files (2G/3G/4G, scanner or mobile devices) are
completely processed by Agileto like it is presented below.

B) Tems export files (*.fmt/*.txt) or other similar delimited files formats (*.csv):
These files may be exported text files from TEMS software tool containing the Top1
to TopX best servers for each UE and technology. To get these files you may use the
methodology provided further and the standard templates (*.tex) files available to be
downloaded from Agileto server like presented below.

Page 205 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example for processing NEMO (*.nmf) drive test log files:

Press the Browse button in order to provide the input Drive Test log file and select
the desired Nemo (*.nmf) input file like presented into the screenshot below.

Page 206 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Notice that all *.nmf files located into the same directory with the one selected will
be processed together. During the processing time of all the *.nmf files the evolution
is presented into a dedicated progressing bar form like below:

When the process is completed the summary info is displayed like presented below.

Page 207 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The image of the output (*.csv) files is looking like below:

The output (*.csv) files are saved on the same input directory as the input *.nmf
file(s) and they are divided by the equipment device Mobile(M)/Scanner(S), followed
by the technology (2G/3G/4G) and then by the frequency layer/band like they are
presented into the above screenshot. The name of the input directory gives the
starting names of the output (*.csv) files (see the example into the screenshot above).

All of the output (*.csv) files have already the good format (for details please check
the annex named “Drive Tests measurements (scanner/mobile) file”) and they may be
used as input files for the module M4.1 – the section Drive Test Optimization.

Page 208 of 253 www.agileto.com

Agileto_Help_V7.19.docx

B) TEMS export files (*.fmt/*.txt) or other similar formats (*.csv):

TEMS may record the original drive test files with several extensions (*.log/*.trp)
which can be used to export very easy different parameters necessary to built-up an
input (*.csv) Drive Test file accepted to be imported in Agileto, as following:

From the Logfile menu, choose Export Logfile, to open the Export Logfile dialog:

Select the Add Order button, to open the Add Export Order dialog.

After selecting the desired inputs (similar like presented into the left screenshot
above) press the “Setup” button and you will get the right window from above. Here
you need the export the appropriate Top1 to TopX best servers and for this purpose
you may use the “Load” button in order to use Agileto predefined template files
(*.tex) dedicated per UE (mobile/scanner) and per technology (2G/3G/4G).

Agileto templates (*.tex) archived file (*.rar) may be downloaded directly from
Agileto tool by pressing the button Get (*.tex) like it will be presented further or it
may be downloaded manually from Agileto’s web site at the link presented below:

http://www.agileto.com/pro/TEMS_EXPORT_for_Agileto_Templates.rar

Inside of the above mentioned archive it is a Read_me.txt file which is presenting an

up to date templates version and step by step process about how to use them.

Once you have selected the right template file (*.tex) – as appropriate for the UE
(scanner/mobile) + technology (2G/3G/4G) + frequency layer/band - then start the
export process and finally you should get a *.txt file containing the best Top1 to
TopX best servers for that technology (like presented into the screenshot below).

Page 209 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is presented an example about how it may looks the TEMS export txt file containing the Top1 to Top6 best servers (3G):

The above TEMS export txt file should be now processed by Agileto by selecting only the specific lines on which we are interested.
In the above example we should select into the 5th column only the lines which contain the text “Top N Pilot Scan Data Message”
but in a similar way some other filters may be applied if necessary (ex: on the 11th column UARFCN can be filtered on “10762” in
order to get only the results from this DL frequency layer). If the input txt file has a reasonable size this filtering process may be
performed very easy in Excel but if it reaches a big size (over 300MB) - that is often the case when exporting from TEMS multiple
log files - it is no more possible to process it by Excel, therefore it will be processed by Agileto like it is presented below.

The delimiters accepted by Agileto for these types of files are: “tab” -> TEMS export case, “,” -> commas, “;” -> semicolon.

Page 210 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Press the ‘Browse’ button to select the input *.fmt/*.txt/*.csv file:

After selecting the input *.txt file please provide the other two inputs like presented
above (Filtering options) meaning that from the total lines included into the initial input
file will be “extracted” only those lines which contain the desired “TEXT” into the
“Column number” like it is presented above.

Page 211 of 253 www.agileto.com

Agileto_Help_V7.19.docx

During the processing time of the file the evolution is presented into a dedicated
progressing bar form like below:

When the process has been the completed the following message is displayed presenting
the name of the output file and the number of lines extracted from total.

The output file will look like it is presented below and a similar process to filter the 11th
column (UARFCN) with “10762” may apply in order to get the Top1 to TopX best
servers from a single frequency layer in order to be suitable to use it for the Drive Test
Optimization purpose in Agileto.

The last operation is to replace the header strings from the above columns 12 to 29 with
the standard strings defined into the Annex named “Drive Tests measurements file”.

Page 212 of 253 www.agileto.com

Agileto_Help_V7.19.docx

4.4) Neighbors Optimisation based on PSCs Detected (*.txt)

The purpose of this module is mainly to convert the PSCs “Detected” into their
associated 3G cells [detected]; furthermore, this module checks if the associated 3G cell
detected is already between the declared neighbors of the source cell; some other
supplementary investigations are performed too (the distance source <-> target, the
weighting factor as the percentage relating to the number of occurrences for the same
Source – Target combinations, etc); the output results of this module in correlation with
other additionally info may lead to decision to add (or not) as neighbors the cells
associated to specific PSCs detected; however, this module is recommended to be used
only as a temporary alternative to the modules M4.1 / M4.2 which are doing similar
tasks but performing better this type of action.
PSCs detected set may be the output of the Drive Tests, Monitoring or Call Traces
analysis, therefore the format how they are provided may vary up to their source.
However, the meaning of this type of the data is always the same, representing the set of
the PSCs which are reported by the mobiles but which are not detected between the set
of the PSCs related to the neighbors cells already declared to the “source” cell.
Therefore, there is not at all important the source which provides the set of the PSCs
detected as all of them can be processed identically. This module is taken a particularly
format related to the list of the PSCs detected but other formats can be easier converted
to this particular format and further the post-processing process remains the same. The
format regarding the PSCs detected is described into the Annex named “PSCs detected
file format”. This is the format related to the File #6 (see chapter “Before you start”).

Select the section 4) Network Optimisation (audit + proposals), then M4.4.

Page 213 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the following window:

-> The *.txt file representing the PSCs detected (in Drive Tests/Monitoring/Call Traces)
is the file described at the beginning of this document as File #6 (see chapter “Before
you start”). For more details regarding the format of this file please see the Annex
named “PSCs detected file format”;

-> OMC 2G/3G/4G snapshot file should be a 3G dump files which contains the 3G
network configuration details and may be obtained in different formats: *.xml, *.xcm,
*.txt - up to the 3G vendor - File #1 (see chapter “Before you start”).

After providing the relevant information, choose OK and you will get the next message:

Choose OK and you will get the final PSCs Detected Neighbors Analysis and
Optimisation report as it is presented into the next screenshots.

Page 214 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of PSCs Detected Neighbors Audit & Optimisation Report – Part 1:

Few explanations regarding the structure and the format of the PSCs detected Neighboring Optimisation report presented above:

 The report contains at the end a summary info regarding the module version, processing time, inputs and output data, etc;
 On the left side, the first columns are formatted in such of way to be able to load immediately in MapInfo all the Source –
Target combinations detected/selected (yellow background);
 The Clusters related to the Source/Target cells are following on the right side;
 There is a validation process for the both Source & Target cells meaning that if at least one cell doesn’t exist (it is not
declared) into OMC 3G snapshot file then the relation Source – Target is invalidated (this may happen in the case that
Agileto reference database is updated with all the 3G cells planned for future deployments but the cells are not yet declared
into the real OMC 3G network);
 There is a checking to see if the Source –Target combination is already declared as neighbor relationship into the snapshot;

Page 215 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of PSCs Detected Neighbors Audit & Optimisation Report – Part 2:

 There are presented the following info for both (the Source & Target) cells:
o RNC
o LCID
o Cell_Name
o PSC
 Geographically information in regards with the Source – Target cells are provided:
o Distance (Source – Target);
o Inside Beamwidth Source / Target -> [this is a boolean checking if the Target cell is detected inside of the beamwidth
coverage of the Source cell and reciprocally, if the Source cell is detected inside of the beamwidth of the Target cell);
 On the right side is following the data regarding the number of occurrences [numbers as well as weighted percentage]
representing how many times [weight per one source/reference cell] a specific detected combination Source – Target
occurred into the input data file by referencing to the same Source cell.

The final decision for adding (or not) a Source - Target combination [detected] as neighbor relationship may be based on the
number of occurrences, their weighted contribution per the Source cell as well as looking to different other additionally information
[EcIoAvg, EcIoMax, etc];

Page 216 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Investigation based on Cells KPIs in MapInfo & GoogleEarth

representation
5.1) Generate MapInfo & GoogleEarth cells/sites objects based on KPIs values

To watch on-line the related video trainings for this module click on the link below:
KPIs in MI + GE: https://youtu.be/3B65edyGBBg

This module provides very easy the visually representation in MapInfo and Google
Earth of different network cells (2G/3G/4G) performance KPIs related to their
geographically representation and distribution. This may help the troubleshooting /
optimization teams to perform different visual correlations and to quickly identify an
issue that may affect a dedicated geographically area of the mobile network (Ex:
external radio interference affecting a group of 3G cells from a dedicated geographically
region, or to identify a general transmission issue which will be reflected into the bad
performance for all the cells from the same region using the same [erroneous]
transmissions lines, etc);

By using the potential of this module the entire mobile network cells (2G/3G/4G) may
be represented in MapInfo and Google Earth by adjusting their sector colors and/or their
radius according with their KPIs values. This way it may be very easy to identify
visually in MapInfo and/or Google Earth the absolute and relative performance of the
2G/3G/4G cells by comparisons with their neighbors. Some additionally
explanation/details will be provided further during the description of this module.

Select the section 5) KPIs in MapInfo and Google Earth representation then M5.1.

Page 217 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and you will get the following window:

The KPIs file can be any Cells KPIs report file exported from the mobile operator
monitoring system (OMC/OSS); this file may contain different types of KPIs for
multiple cells (2G/3G/4G) taken at specific time or it may contain the same KPI taken at
different periods of times (example: CDR taken for different days). This is the File #5
(See “Before you start”) and some example details regarding this file format/structure
may be checked into the Annex named “KPIs file structure and format”.

Now choose OK and the main window of this module will pop-up like it will be
presented further with few examples. Here there are available several input parameters
and options which will be explained further. After choosing all the desired settings,
choose OK and you will see the message presenting where the associated KPIs output
files have been saved for MapInfo and Google Earth, as per below.

Page 218 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Choose OK and then you may use the module M1.4 in order to view the KPIs values in
MapInfo & Google Earth representation(s) like presented below:

The KPI’s name is used to create the output generated KPI directory (CDR):

Page 219 of 253 www.agileto.com

Agileto_Help_V7.19.docx
The next screenshot is the Google Earth representation of the KPI = CDR with the input settings which are presented further:

Page 220 of 253 www.agileto.com

Agileto_Help_V7.19.docx
The next screenshot is the MapInfo representation of the same KPI = CDR with the input settings presented below:

Page 221 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Example of one case when the KPI is the 3G CS_CDR [%] -> (This KPI is expressed generally as percentage %):

Page 222 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The following inputs / settings should be given on the main form for this module:

Technology:
 Should be selected 2G or 3G or 4G

Initial settings:
 KPIs database sheet -> should be selected the desired KPIs sheet from all
available into the input KPIs file (KPIs_3G into the previous example);
 The common Key selection that should be one between Local_CID and
Cell_Name (into the above example the Cell_Name has been selected);
 Should be selected the column associated with the Key selection (into the above
example this was the 3G_Cell_Name);
 Selected KPI column associated should be performed with one of the headers
(columns) available into the KPI report (Ex: CS_CDR);

Data Inputs:
 If the KPI is generally represented like a percentage [%] then the corresponding
field (Present KPIs as percentage %) is recommended to be selected in order to
have a better visualization on the selected input data (like presented above);
 The name of the KPI (a short string) should be data-filled into the field
KPI Name; this name (CDR) will be used to generate output MapInfo & Google
Earth directories where dwdicated files will be saved.
 All Cells -> This option is selected when desired to plot all the cells, including (in
grey color) those cells which were not detected inside KPIs database; if this
option is not selected then these specific cells are no more generated.
 Reference Cell Radius [Km] -> It is the radius of the cells (Frequency layer F1
on each technology) used to generate the cells in MapInfo and Google Earth.
 Generate Cells Radius proportionally with their KPIs value -> When this
option is selected then the cells are generated with different radius lengths
proportionally with their KPIs value (otherwise all cells have the same radius); if
this option is selected then another two subsequent inputs should be provided:
o Reference KPI value -> This is the value of the KPI associated with the
previous field “Reference Cell Radius [Km]” meaning that a cell having
this KPI value will be represented with the “Reference cell Radius” while
the other cells will be represented with different radius values
proportionally with their KPIs values;
o Maximum cell radius [Km] -> This is a upper limitation of the cell radius
value in case that due to the variable length the radius may become very
large and consequently the associated cells will no more be represented
properly in maps due to huge overlapping between them.
o suggestive into the mapping representation;

Page 223 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Legend:
 Up to the KPI’s type it should be selected KPIs ascending or descending color
order -> the difference between these two (2) settings is reflected in which color
is associated to the minimum KPI value (green or red);
 Should be setup the four (4) thresholds (ranges/intervals) in order to establish the
association between the legend colors and the KPIs values;

Always will be generated MapInfo and Google Earth associated KPIs files into specific
directories as following:

The KPI’s input given name (Ex: CDR) is used by Agileto tool to generate directories
with the same name under the standard paths …\KPIs\ under MapInfo and GoogleEarth
directories. On these KPIs folders there are created automatically the standard folders
2G/3G/4G and according with the input technology type the output KPIs files will be
saved under the corresponding directory (2G/3G/4G). This way, the name of the output
KPIs generated files are always standard (the same) and the most important names of
these files under each technology are as following:

2G: -> GE: MobileNW_2G_KPIs.kmz | MI: MobileNW_2G_KPIs.wor

3G: -> GE: MobileNW_3G_KPIs.kmz | MI: MobileNW_3G_KPIs.wor
4G: -> GE: MobileNW_4G_KPIs.kmz | MI: MobileNW_4G_KPIs.wor

Because Google Earth may be customized better than MapInfo on this topic, it is always
created on the KPI root directory the synthesis file named MobileNW_KPIs.kmz
which will open automatically the other three for each technology presented above.

Below it is presented the example related to the GoogleEarth files generation:

Page 224 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Below it is presented the example related to the MapInfo files generation:

If you want to open the KPIs representations into MapInfo or Google Earth you may use
the module M1.4 like it was presented above by selecting the desired KPI name or you
may manually open the most representative files presented above.

The great advantage of the Google Earth (freeware software) KPIs output files is that
they may be transferred and then analyzed on any other PC without necessary to have
Agileto tool installed -> you just need to open the entire KPI’s name directory on the
other PC and just open the file named MobileNW_KPIs.kmz like you may see below
(the links to the other related KPIs files are done automatically).

Page 225 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is presented a case when it was selected to generate the Cells with their radius proportionally with their KPIs values:

Page 226 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is the GE representation of the case when generating the Cells with their radius proportionally with their KPIs values:

Page 227 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is the MI representation of the case when generating the Cells with their radius proportionally with their KPIs values:

Page 228 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is presented the case when the option “All Cells” was selected (The cells without KPIs are displayed in grey color):

Page 229 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is the GE representation of the case when selecting “All Cells” -> The cells without KPIs are displayed in grey color.

Page 230 of 253 www.agileto.com

Agileto_Help_V7.19.docx
Below it is the MI representation of the case when selecting “All Cells” -> The cells without KPIs are displayed in grey color.

Page 231 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Annexes
Agileto reference database [MobileNW_Config.xls]

Agileto reference database file is an Excel file containing three sheets (2G/3G/4G) as following:
 2G/3G/4G – each sheet contains the data related to the related mobile network technology.

The structure for each database [2G/3G/4G] sheet is presented into the following screenshots. Agileto installation kit is coming with
the file named MobileNW_Config_Template.xls which already has this structure (template) and is used by the tool in order to
generate a new Agileto reference database according with the specific project data (mobile operator). Each column’s header from
each sheet (2G/3G/4G) contains explicative comments describing if the field & data related are mandatory to be filled or not + other
useful information.
The following column’s head background colors are valid for each sheet (2G/3G/4G) and they have the following meanings:
 The green columns are mandatory and updated by using the module M1.1 from external databases (File # 2);
 The blue columns are usually updated from OMC snapshot files by using the modules M1.1 or M2.1 (File # 1);
 The yellow columns contain optionally info which are updated by using the module M1.1 from external databases (File # 2);

The structure of the sheet 2G: Part 1

Page 232 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The structure of the sheet 2G: Part 2

 Each 2G cell is unique identified by its Cell_ID + LAC as the keys reference when searching in multiple databases;
 At the end of all the 2G cells (see the picture above) there is a blank line marking the end of the 2G cells definitions followed
by a summary info presenting the moments and inputs when the 2G data base has been updated; this summary is updated
each time after running the modules M1.1 or M2.1;
 The first column named Cell_Code is unique allocated for each 2G cell and it is generated/updated automatically by the tool
as following:
o 2G Cell_Code = 2G Frq Band Letter (G -> 900MHz / D -> 1800MHz) + LAC + “.” + Cell_ID + “_” + Sector_ID;
o In case that a 2G Cell doesn’t have data filled the geographically coordinates (Long_WGS84/Lat_WGS84) then there
is a prefix “MC-” (stands for Missing Coordinates) which is added to the standard Cell_Code described previously;
 The last columns (21, 23, 24) from the above picture are updated automatically by the tool after the running of the modules
M1.1 or M2.1 and mark with “1” those 2G cells which:
o 21: are detected inside OMC 2G snapshot files;
o 23: are detected inside OMC 3G/4G snapshot files as external 2G cells declarations;
o 24: are detected inside OMC 3G/4G snapshot files with parameters which do not match (ex: bcch/bcc/ncc);
Page 233 of 253 www.agileto.com
Agileto_Help_V7.19.docx

The structure of the sheet 3G: Part 1

The structure of the sheet 3G: Part 2

Page 234 of 253 www.agileto.com

Agileto_Help_V7.19.docx

 Each 3G cell is unique identified by its Local_CID as a key reference when searching in multiple databases;
Notice: another unique reference key for the 3G cells may be represented by the combination: RNC_ID + Cell_ID;
 At the end of all the 3G cells there is a separation line (colored in green into the above picture) marking the end of the 3G
cells definitions followed by a summary info presenting the moments and inputs when the 3G data base has been updated;
this summary is updated each time after running the modules M1.1 or M2.1;
 If during the creation of the new Agileto database was selected the following option
then the following string will be written into the first column
on the separation line: “Local_CID = RNC_ID & Cell_ID”; this case the tool will check always the values of the
Local_CID and overwrite them accordingly if necessary (like presented into the above picture);
 The first column named Cell_Code is unique allocated for each 3G cell and it is generated/updated automatically by the tool
as following:
o 3G Cell_Code = Frq_layer associated Letter + Local_CID + “_” + Sector_ID + Frequency_Layer
o In case that a 3G Cell doesn’t have geographically coordinates (Long_WGS84/Lat_WGS84) data filled then there is a
prefix “MC-” (stands for Missing Coordinates) which is added to the standard Cell_Code described previously;
 The Frequency_Layer allocation is performed automatically by the tool, as following:
o UMTS frequencies in 2GHz band are allocated with the layers 1 to 6 while 900MHz band are allocated with the layers
7 to 10. The correspondence between the Frequency_Layer and the DL_UARFCN numbers may be seen into the cell
comment from the first column on the separation (green) line like is presented into the above picture => on the first line
from the comment are presented the DL_UARFCN(s) from the 2GHz band separated by commas
(10712,10737,10762), while on the second line are those belonging to 900MHz band (3087); this correspondence is
updated automatically each time after running the modules M1.1 or M2.1;
For more details about UARFCN visit: https://en.wikipedia.org/wiki/UMTS#UARFCN
 The last columns (21, 22, 23) from the above picture are updated automatically by the tool after the running of the modules
M1.1 or M2.1 and mark with “1” those 3G cells which:
o 21: are detected inside OMC 3G snapshot files;
o 22: are detected inside OMC 2G/4G snapshot files as external 3G cells declarations;
o 23: are detected inside OMC 2G/4G snapshot files with parameters which do not match (ex: PSC/LAC/Frequency);

Page 235 of 253 www.agileto.com

Agileto_Help_V7.19.docx

The structure of the sheet 4G: Part 1

The structure of the sheet 4G: Part 2

Page 236 of 253 www.agileto.com

Agileto_Help_V7.19.docx

 Each 4G cell is unique identified by its Global_CID as a key reference when searching in multiple databases; Global_CID
is automatically generated by the tool as the concatenation between the eNodeB_ID and the Relative_CID;
 At the end of all the 4G cells there is a blank separation line (see the above picture) marking the end of the 4G cells
definitions followed by a summary info presenting the moments and inputs when the 4G data base has been updated; this
summary is updated each time after running the modules M1.1 or M2.1;
 The first column named Cell_Code is unique allocated for each 4G cell and it is generated/updated automatically by the tool
as following:
o 4G Cell_Code = Frq_layer associated Letter + Global_CID + “_” + Sector_ID + Frequency_Layer
o In case that a 4G Cell doesn’t have geographically coordinates (Long_WGS84/Lat_WGS84) data filled then there is a
prefix “MC-” (stands for Missing Coordinates) which is added to the standard Cell_Code described previously;
 The Frequency_Layer allocation is performed automatically by the tool as following:
o The lowest DL_eARFCN is allocated with the layer “1” and the next in ascending order are increased by one. The
correspondence between the Frequency_Layer and the DL_eARFCN numbers may be seen into the cell comment
from the first column on the separation line like is presented into the above picture => the DL_eARFCNs are
presented on the same line separated by commas (ex: 1900,3350 -> 1,2); this correspondence is updated automatically
each time after running the modules M1.1 or M2.1;
 The last columns (21, 22, 23) from the above picture are updated automatically by the tool after the running of the modules
M1.1 or M2.1 and mark with “1” those 4G cells which:
o 21: are detected inside OMC 4G snapshot files;
o 22: are detected inside OMC 2G/3G snapshot files as external 4G cells declarations;
o 23: are detected inside OMC 2G/3G snapshot files with parameters which do not match (ex: PCI/TAC/Frequency);

Page 237 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Drive Tests measurements (scanner/mobile) file

The Drive Tests measurements files are text files (*.txt/*.csv) accepting one of the following three delimiters between the columns:
1) “,” comma;
2) “->” tab;
3) “;” semicolon.

These files may be converted into the good format accepted by Agileto tool by using the module M4.3 to process originally Drive
Test log files recorded by the drive test acquisition tools like TEMS or Nemo (see below the reference video-tutorials).
Processing Nemo drive test log files: https://youtu.be/w0aukB4jKxE
Processing TEMS drive test log files: https://youtu.be/91Th8iD6kCE

Alternatively, you may need to export the Top1 to TopX best servers from any drive test acquisition tool and then to prepare the
output data in order to fit with one of the two accepted formats which will be presented below.

Agileto tool accepts two Drive Test (Optimisation) input formats, as following:
a) Top_X in line format; -> the Top1 to Top_X best servers detected at one time are presented into one single line;
b) Top_X different lines format; -> the Top1 to Top_X best servers detected at one time are presented in different lines one after
the other;

Additionally to the Top1 to Top_X best servers the Drive Tests measurements files should contain always the Time_Stamp & GPS
information columns, as following:
Time_Stamp / GPS Lat / GPS Lon;
Obs:
1) The three columns above mentioned are mandatory but the headers/names of these columns are not mandatory to be the same.
2) The content of the column “Time_Stamp” should be a string in any desired format as far as this info is used basically mainly for
the tracking purpose when performing the drive test analysis and interpretation.

Each Drive Test technology (2G/3G/4G) file has a different format structure (specific headers/columns string names) like it is
presented below. If the Drive Tests measurements (*.csv) files are open in Excel they should have the following formats:

Page 238 of 253 www.agileto.com

Agileto_Help_V7.19.docx

A) 2G case: => Top_X in line format:

The name of the mandatory columns which are presented inside of the red rectangle into the above picture should contain
minimum the red strings presented into the above picture.

The Drive Tests measurements data should contain the Top 1 to TOP X best servers detected from the 2G UE (scanner/mobile
device) at one time containing the following details:
TOP X ARFCN / TOP X RSSI / TOP X BSIC into this order, one after the other in ascending order of the servers (1 to X);
It doesn’t really matter if the Top 1 is the best server but it is important that the order of the column headers to follow exactly this
format.

As presented into the above picture, the columns headers/names should contain mandatory the following strings:
TOP 1 ARFCN / TOP 1 RSSI / TOP 1 BSIC / TOP 2 ARFCN / TOP 2 RSSI / TOP 2 BSIC / TOP 3 ARFCN / …

It is recommended to export at least the first Top 10 best servers (2G) into the file in order to get the best drive test analysis and
optimisation results.

Page 239 of 253 www.agileto.com

Agileto_Help_V7.19.docx

B) 2G case: => Top_X different lines format:

The name of the mandatory columns/fields should contain minimum the red strings presented into the above picture that means:
TOP 1 ARFCN / TOP 1 RSSI / TOP 1 BSIC

In this case (Top_X different lines format) by comparison with the previous case (Top_X in line format) the TOP X best servers
detected from the 2G UE (scanner/mobile device) at one time are presented in different lines one after the other, always into the
same columns (corresponding formally to the Top 1 best server) as per how is presented into the above picture. The number and
order of the Top_X best servers exported (meaning which is the order how they are exported into the Drive Test measurement file)
doesn’t matter for this format as far as Agileto tool will sort them accordingly during the time of processing the data.

For this format it is very important the column Time_Stamp as far as identical values on successive lines will indicate that the
measurements are performed on the same time.

Page 240 of 253 www.agileto.com

Agileto_Help_V7.19.docx

C) 3G case: => Top_X in line format:

The name of the mandatory columns (which are presented inside of the red rectangle into the above picture) should contain
minimum the red strings presented into the picture above:

The Drive Tests measurements data should contain the Top1 to TOP X best servers detected from the 3G UE (scanner/mobile
device) at one time containing the following details:
TOP X SC / TOP X CPICH Ec/No / TOP X CPICH RSCP into this order, one after the other in ascending order of the
servers (1 to X); It doesn’t really matter if the Top 1 is the best server but it is important that the order of the column headers to
follow exactly this format.

As presented into the above picture, the columns headers/names should contain the following strings:
TOP 1 SC / TOP 1 CPICH Ec/No / TOP 1 CPICH RSCP / TOP 2 SC / TOP 2 CPICH Ec/No / TOP 2 CPICH RSCP / TOP 3 SC / …

It is recommended to export at least the first Top 6 best servers (3G) into the file in order to get the best drive test analysis and
optimisation results.

Page 241 of 253 www.agileto.com

Agileto_Help_V7.19.docx

D) 3G case: => Top_X different lines format:

The name of the mandatory columns/fields should contain minimum the red strings presented into the picture above:
TOP 1 SC / TOP 1 CPICH Ec/No / TOP 1 CPICH RSCP

In this case (Top_X different lines format) by comparison with the previous case (Top_X in line format), the TOP X best servers
detected by the 3G UE (scanner/mobile device) at one time are presented in different lines one after the other, always into the same
columns (corresponding formally to the Top 1 best server) as per how is presented into the picture above. The number and the order
of the Top_X best servers exported (meaning which is the order how they are exported into the Drive Test measurement file)
doesn’t matter for this format as far as Agileto tool will sort them accordingly during the time of processing the data.

For this format it is very important the column Time_Stamp as far as identical values on successive lines will indicate that the
measurements are performed on the same time.

Page 242 of 253 www.agileto.com

Agileto_Help_V7.19.docx

E) 4G case: => Top_X in line format:

The name of the mandatory columns (which are presented inside of the red rectangle into the above picture) should contain
minimum the red strings presented into the picture above:

The Drive Tests measurements data should contain the Top1 to TOP X best servers detected from the 4G UE (scanner/mobile
device) at one time containing the following details:
TOP X PCI / TOP X RSRP / TOP X RSRQ into this order, one after the other in ascending order of the servers (1 to X); It
doesn’t really matter if the Top 1 is the best server but it is important that the order of the column headers to follow exactly this
format.

As presented into the above picture, the columns headers/names should contain the following strings:
TOP 1 PCI / TOP 1 RSRP / TOP 1 RSRQ / TOP 2 PCI / TOP 2 RSRP / TOP 2 RSRQ / TOP 3 PCI / TOP 3 RSRP / TOP 3 RSRQ / …

It is recommended to export at least the first Top 6 best servers (4G) into the file in order to get the best drive test analysis and
optimisation results.

Page 243 of 253 www.agileto.com

Agileto_Help_V7.19.docx

F) 4G case: => Top_X different lines format:

The name of the mandatory columns/fields should contain minimum the red strings presented into the picture above:
TOP 1 PCI / TOP 1 RSRP / TOP 1 RSRQ

In this case (Top_X different lines format) by comparison with the previous case (Top_X in line format), the TOP X best servers
detected by the 4G UE (scanner/mobile device) at one time are presented in different lines one after the other, always into the same
columns (corresponding formally to the Top 1 best server) as per how is presented into the picture above. The number and the order
of the Top_X best servers exported (meaning which is the order how they are exported into the Drive Test measurement file)
doesn’t matter for this format as far as Agileto tool will sort them accordingly during the time of processing the data.

For this format it is very important the column Time_Stamp as far as identical values on successive lines will indicate that the
measurements are performed on the same time.

Page 244 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Observation:
If the Drive Test Optimisation analysis is evaluated for the case of Intra-Technology + InterFrequency or Inter-RAT Technology
than we may built up a single Drive Test measurement file presenting on the left side the info for the Top_X (in line format) related
to the source technology followed then on the right side by the Top_Y (in line format) best servers from the target technology into
the right formatted technology.

However, from the practical point of view, it is recommended to export always separately each Source and Target technology on a
single file and then we can play with the way how these files are given as inputs representing the Source respective the Target.

Page 245 of 253 www.agileto.com

Agileto_Help_V7.19.docx

KPIs file structure and format

This file is usually provided by the OMC/monitoring Engineer and the format should be similar like it is presented below:
Ex: below is KPI = CDR[%]:

One column (usually the first on the left but not mandatory) should contain the reference key for the cells (LCID or Cell_Name)
and the others may contain different KPIs; this reference key is used by Agileto tool to match each cell with its associated KPI.

The next screenshot present a set of data for the case of KPI = CS RB Setup:

The KPIs can be provided into the files having datasheets with one type of KPI per sheet for different days (hours/etc) – like it is
presented above - or it may be provided in sheets containing the reference key column (LCID or Cell_Name) followed by different
KPIs such as CSSR, CDR, CS_RB_Setup, PS_Throughput, etc, taken at specific time.

Page 246 of 253 www.agileto.com

Agileto_Help_V7.19.docx

PSCs detected file format

These files may come as output from different sources (Drive Tests, Monitoring, Call Traces) and they need to present the
combinations detected between the 3G source cell and PSC detected; some other additionally information may be provided like the
number of occurrences for each Source – Target combination occurred, EcNo_Avg/Min/Max, etc.

Below it is presented the format when the set of PSCs detected is coming as output after post-processing Cal Traces:

 On the left side the first columns provides the necessary elements for the unique identification of the 3G source cell
[RefRncCellId -> RNCID + CellID + (PSC)];
 PSC detected is given into the column Detected cell SC;
 Additionally info may be provided as: Occurance/EcIoAvg/EcIoMax/etc;

Other formats coming from other sources may be easy converted into the above format and they may be used straight by the tool.

In case of special demand coming from different customers, we may provide converters in order to get the good format.

Page 247 of 253 www.agileto.com

Agileto_Help_V7.19.docx

OMC 2G network file format

This is the file that should be exported from the (2G) OMC related to the 2G networks. It should contain important key 2G
information / parameters necessary to be updated always into the 3G network as long as they have been changed into 2G network.
These files can be provided into *.csv or *.xls formats but if they are open in Excel they should look like into the screenshot below.

The names of the columns and the order how they are detected into this file are not important as the right association between the
columns may be selected during the running of the modules M1.1 or M2.1 (when these files may be used as inputs).

The mandatory type of the columns to be exported from the (2G) OMC are:
 GSMCell_ID
 LAC
 bcc
 ncc
 bcchFrequency

The last field (Cell_Name) is not mandatory but it is highly recommended to be provided (if available) in order to have a better
association/detection between the 2G cells by using their Cell Names instead of their CID.

Page 248 of 253 www.agileto.com

Agileto_Help_V7.19.docx

MapInfo Neighbors export file

This file is a *.csv file exported from MapInfo while working with the module M3.3 (MapInfo Neighboring tool). This file contains
the neighboring changes performed visually in MapInfo (Additions and/or Removals).
If the file is open in Excel it should look like the screenshot presented below (case of 3G-3G neighbors):

 The first four (4) columns reflect the Cell Codes and their associated RNC_IDs related to the Cells Source and Target;
 It follows the sib11orDchUsage flag allocation (specific for each neighbor relationship);
 In case it is necessary just to change for an existing neighbor declaration the sib11orDchUsage flag, then the new column named
NewSib11OrDchValue will be data-filled with the new desired value regarding sib11orDchUsage flag allocation;
 The last column (Method) presents the action to be performed (Remove/Add);

Please see below a similar screenshot for a case representing an export of 3G-2G neighbors changes.

In case of the 3G-2G neighbors export it is a new column CGI_Target (2G) presenting: CID.LAC.MCC.MNC.

Page 249 of 253 www.agileto.com

Agileto_Help_V7.19.docx

MapInfo Neighbors import file

These *.csv file formats are inputs for M3.3 and usually are provided as outputs of the modules M3.1 or M3.2. They contain the
3G-3G and 3G-2G neighbors declarations to be imported into MapInfo. In case they are open in Excel they should look like the
formats presented below. The file structure and formats associated to these files are presented into the next screenshots.

3G-3G Neighbors file

The structure has the same first five (5) columns presented into MapInfo Neighbors export file (see above):

3G-2G Neighbors file

The structure has the same first three (3) columns presented into MapInfo Neighbors export file (see above):

Page 250 of 253 www.agileto.com

Agileto_Help_V7.19.docx

External Neighbors declarations file

These (Neighbors declaration) *.csv files contain a number of the Source – Target cells neighbor declarations where the Source and
the Target cells may belong to any technology (2G/3G/4G). Accordingly, they should be provided in specific standard formats as
they are mentioned below. These files can be used as inputs for the modules M4.1 (Drive Test) or M3.2 (when OMC dump
configuration files are not available) in order to map the neighbor declarations into MapInfo and Google Earth environments.
According with the Source and the Target cells neighbors technologies, they may be unique identified by the following parameters:
Technology 2G: -> LAC + Cell_Id
Technology 3G: -> RNC_Id + Cell_Id (or localCellId)
Technology 4G: -> eNideB_Id + Cell_Id or (globalCellId)

Notice: When these files are used as inputs during M4.1 the following header strings should be used per technology:
Technology 2G: -> Source cell: sourceCID + sourceLAC / Target cell: targetCID + targetLAC
Technology 3G: -> Source cell: sourceCID (= Source 3G localCellId) / Target cell: targetCID (= Target 3G localCellId)
Technology 4G: -> Source cell: sourceCID (= Source 4G globalCellId) / Target cell: targetCID (= Target 4G globalCellId)

Below there are provided the format examples of the (*.csv) files which can be used as external neighbors declarations.

Page 251 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Please notice that only the first columns marked into the pink rectangles are mandatory (for the module M4.1). The other columns
presented on the right side ore optionally or alternative to be provided as inputs for the module M3.2.

Obs: The headers order how they are organized into the file is not important but the header strings should be exactly like they are
presented above in order to be accepted as inputs for the module M4.1 (Drive Test).

Page 252 of 253 www.agileto.com

Agileto_Help_V7.19.docx

Agileto Contact Details

®
Agileto

Web site: www.agileto.com

Sales: [email protected]
Support: [email protected]
Facebook: https://www.facebook.com/agileto
Skype Id: agileto

Page 253 of 253 www.agileto.com