Atoll Test Report Complete

1/121
Report
Tools Management &
Support
Atoll Evaluation Test

18.6.2008, ver. 1.0
For internal use

Report
Change History
Version
1.0
Date
2008-06-18
Authors
Rosario Colaianni,
Enrico Lorenzoni,
Pekka Matilainen,
Kimmo Mkelinen,
Petri Seppl
Comments
the one and only version
2/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Table of Contents
1. Purpose and Scope....................................................................................5

2. Administration of Atoll.................................................................................6
2.1 Installation................................................................................................................................ 6
2.2 Configuring the installation in single mode...............................................................................7
2.3 Multiuser Environment.............................................................................................................. 8
2.4 Digital Maps.............................................................................................................................. 9
2.5 Administration files.................................................................................................................. 11
2.6 Calculated results................................................................................................................... 12
2.7 Export and Import from and to Planner...................................................................................13
2.7.1 Export and Import from using Planet format........................................................................13
2.7.2 Import from other tools........................................................................................................ 13
2.7.3 Import using ASCII format....................................................................................................16
2.8 Atoll management Console.....................................................................................................17
2.9 Conclusions on Atoll Administration........................................................................................19
3. General Planning Issues in Atoll...............................................................20

3.1 Map Formats.......................................................................................................................... 20
3.2 Antenna Import....................................................................................................................... 22
3.3 Propagation Models................................................................................................................ 22
3.3.1 Usage of Two Propagation Models per Cell.........................................................................24
3.3.2 Approximation of NetAct Planner's Nokia Propagation Model in Atoll..................................26
3.3.3 Approximation of Planner's Standard Macrocell Model 3 in Atoll.........................................27
3.3.4 Propagation Model Tuning...................................................................................................31
3.4 Prediction Calculation.............................................................................................................31
4. 2G Radio Planning in Atoll........................................................................32

4.1 General issues about 2G radio planning in Atoll.....................................................................32
4.2 2G Coverage planning............................................................................................................ 33
4.2.1 Simulation vs. static calculation based calculation...............................................................33
4.2.2 Static Coverage calculation for Best server.........................................................................34
4.2.3 Summary on 2G coverage planning....................................................................................35
4.3 2G Neighbour planning........................................................................................................... 36
4.3.1 Manual neighbour planning.................................................................................................39
4.3.2 Visual analysis of neighbour plan........................................................................................39
4.3.3 Summary of neighbour planning in Atoll in comparison with NAP........................................40
4.4 2G Capacity planning............................................................................................................. 40
4.4.1 General about 2G Capacity planning...................................................................................40
4.4.2 TRX requirement definition methods and their applicability.................................................40
4.4.3 Carrier requirement definition in Atoll...................................................................................41
4.4.4 Frequency hopping planning...............................................................................................41
4.4.5 Interference matrix............................................................................................................... 41
4.4.6 Timeslot configuration planning...........................................................................................43
4.4.7 TRX Requirement count calculation....................................................................................43
4.5 GSM Frequency planning.......................................................................................................44
4.5.1 Automatic frequency planning.............................................................................................44
3/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
4.5.2 Manual GSM frequency planning.........................................................................................47

4.5.3 Summary about GSM Frequency planning..........................................................................47
4.6 Code and ID planning.............................................................................................................48
4.6.1 Planning and management of codes...................................................................................48
4.7 Reporting................................................................................................................................ 48
4.8 Conclusions on 2G radio planning with Atoll...........................................................................50
5. UMTS Planning in Atoll.............................................................................51

5.1 Test Environment....................................................................................................................51
5.2 UMTS Parameters..................................................................................................................52
5.2.1 Clutter Parameters..............................................................................................................52
5.2.2 Network Configuration......................................................................................................... 53
5.2.3 Configuration of Bearers, Services and Terminals...............................................................55
5.3 Import from a NetAct Planner Plan.........................................................................................58
5.4 Pilot Coverage Planning.........................................................................................................60
5.5 UMTS Traffic Modelling..........................................................................................................62
5.6 Monte Carlo Simulation.......................................................................................................... 63
5.6.1 Sufficient Number of Simulation Snapshots.........................................................................64
5.6.2 Defining "Equivalent" Simulations in Planner and Atoll........................................................68
5.7 HSDPA................................................................................................................................... 72
5.7.1 HSDPA Transport Formats..................................................................................................73
5.7.2 HSDPA Terminals................................................................................................................ 76
5.7.3 HSDPA Support in Transmitters and Cells...........................................................................77
5.7.4 HSDPA Scheduling..............................................................................................................77
5.7.5 HSDPA Prediction Studies...................................................................................................78
5.8 HSUPA................................................................................................................................... 80
5.9 Neighbour Planning................................................................................................................83
5.10 Scrambling Code Planning...................................................................................................83
5.11 Conclusions on UMTS Planning...........................................................................................84
6. WiMAX Planning.......................................................................................85
6.1 General Issues About WiMAX Radio Planning in Atoll............................................................85
6.2 Scope of WIMAX Support.......................................................................................................85
6.2.1 Test Case Description.......................................................................................................... 85
6.2.2 General Parameters............................................................................................................87
6.3 Results of WIMAX Network Analysis......................................................................................92
6.3.1 Basic Analysis...................................................................................................................... 92
6.3.2 Advanced Analysis.............................................................................................................. 98
6.3.3 Optional Analysis.................................................................................................................99
6.4 Directional terminal antennas (Fixed CPEs Case)................................................................104
6.4.1 How CINR Distribution with directional SS antenna can be calculated..............................104
6.5 WiMAX Frequency Planning.................................................................................................105
6.5.1 Is WiMAX Frequency Planning Supported.........................................................................105
6.5.2 Atoll WiMAX Roadmap......................................................................................................105
6.6 Conclusions on WiMAX Radio Planning with Atoll................................................................106
7. Atoll Roadmap and Future Development................................................107

8. Conclusions and Open Questions..........................................................108
9. Appendix: WiMAX Network Configuration...............................................110
4/121
Report
Tools Management &
Support
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9

18.6.2008, ver. 1.0
For internal use
WiMAX Frame Configuration Settings..................................................................................110

Bearer ID Mapping................................................................................................................113
Propagation Model................................................................................................................ 113
Preamble RSS Array Finding................................................................................................114
Antennas and Equipment......................................................................................................116
Power Settings...................................................................................................................... 117
Settings for Basic Analysis....................................................................................................117
Settings for Advanced Analysis.............................................................................................119
Settings for Optional Analysis...............................................................................................121
5/121
Report
Tools Management &
Support
1.

18.6.2008, ver. 1.0
For internal use
Purpose and Scope
In this document the capabilities of Atoll (ver. 2.7.0 by Forsk, www.forsk.com) in planning of radio
access networks are evaluated. The work was carried out in the GS MS NPO Tools Management
& Support team during May-June 2008.
The work was divided into separate evaluation of planning of GSM, UMTS and WiMAX radio
networks as well as evaluation of Atoll administration. Planning of GSM and UMTS networks was
studied by Petri Seppl and Kimmo Mkelinen, respectively. Atoll administration was the
responsibility of Pekka Matilainen, and planning of WiMAX networks was studied by Rosario
Colaianni (from CMO WSE West & South Europe) and Enrico Lorenzoni (from GS MS Managed
Services).
Only radio access network planning was investigated in evaluation. Aspects related to link planning
or transmission networks were not studied. Atoll supports also CDMA2000 (incl. EV-DO) and TDSCDMA technologies, but network planning for these technologies was been tested.
6/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
2.
Administration of Atoll
2.1
Installation
Atoll Version and modules:
Server/workstation Installation:
Hardware: Dell Precision 530
CPU Xeon 2 GHz
RAM 3.5 GB
OS: Windows XP, SP2, 32 bit
MS Access 2003, SP2
Oracle 10.2.0.2 EE
Installation process
Full installation
Client/workstation Installation
Hardware: IBM T43P
CPU Intel 2 GHz
RAM 2 GB
OS:
1.machine Windows XP, SP2, 32 bit
2.machine Windows Vista, 32 bin
MS Access 2003, SP2
Oracle 10.2.0.2 Client
Installation process
Without Atoll Calculation server
7/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Command line installation not tested. Personal licenses used in this test. No Add-in modules were
available for the test.
Conclusion: Installation goes along the manual. Only under Vista OS the dongle driver was not
compatible with operating system. OK
2.2
Configuring the installation in single mode.
There are many ways how the data can be stored

1.
2.
3.
4.
in a single file: planning data and digital maps as embedded

data in a single file and digital maps in separate folders
data in a MS Access database and digital maps in separate folders
data in a database (Oracle/msSQL) and digital maps in different folders as linked or
embedded
5. active Network data is located in local file, and it can be manually archived to the
local MS Access database and to the project database . Administrator takes care of
synchronization of all project data to the Master database
MsSQL database option not tested.
Conclusion: In a single user mode, data can be opened in one method and saved in an other way
quickly and easily. My recommendation is that Oracle is not used in single user mode. Export to
MS Access gives easy access to mass manipulation of the data. All methods are OK.
8/121
Report
Tools Management &
Support
2.3

18.6.2008, ver. 1.0
For internal use
Multiuser Environment
Master Document:
The Master Document is the core of the project. It holds the information of the digital maps and the
initial network design. The master document is accessed only by administrator and when ready,
Admin will export it to the database.
Shared Path Loss Matrices:
These files are generated by administrator, or the calculation service. Files are read only for all
users.
9/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Client side files:

Single file system saves the information about the map data, but in case a database is used, the
file information is passed to the application with parameter "C:\Program Files\Forsk\Atoll\Atoll.exe"
-cfg "H:\Atoll\Master.cfg". Connection to the right database with account information can be
included in the parameter. Prediction files and copy of the database should be located in a local
drive. The changed objects are saved to the database using function <File><Database><Archive>.
To retrieve the updated data from database is done with function <File><Database><Refresh>.
Most convenient way to use multi user environment is to save the project locally and every now
and then to update the data either or direction.
User rights:
User rights can be handled in various methods, the tool itself has limited support in this area.
-
site lists
Each project is stored under different username, schema or in a separate database.
Each table in one project can be provided with different access rights for each user
Master database and regional databases can be synchronized (static regionalization)
Oracle Spatial can be used in dynamic regionalization
Forsk can provide master database and set of scripts to maintain user accounts, access
rights and how to regionalize the project.
Conclusion: To setup many projects for multiple users is time consuming. Also many methods of
storing data with the easiness make the planning really interesting job: proper version handling,
corrupted data, overlapping network objects, just some of those dark clouds in the sky. My humble
opinion is the tool is nice and easy to use when we have few projects and less than 10 planners to
manipulate the same data.
.
2.4
Digital Maps
Atoll can use digital maps in various formats and the natural format is BIL-format.
6. geo data set
7. Web Map service maps
8. Autocad dxf-files
9. Atoll geographic data files
10. Arch view and grid files , shp, txt
11. MapInfo mif or tab files
12. Multi-import files
13. Planet format , database or index-files
14. BitMap files in Tiff and Bmp formats
15. Erdas files
16. ECW files
17. Bil Format
18. Vertical mapper files
19. Google earth maps ( in next release)
Also tool support directly conversion to a different format, e.g.
10/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
20. Mapinfo -> Atoll geographic data files, Arch view files , shp
21. NetAct Planner -> BIL, Arch view grid files txt, Tif, Bmp
Example using NetAct Planner map format. The data includes height and clutter in 5 m and
building data in Mapinfo format converted from NetAct Planner vector format.
Conclusion: The digital map formats and the way Atoll handles the digital map data, is suitable for
our needs. WMS (web map service) would be a nice method to share digital maps in our intranet.
11/121
Report
Tools Management &
Support
2.5

18.6.2008, ver. 1.0
For internal use
Administration files
The behaviour of the tool can be modified by editing these 3 types of configuration files.
The user configuration file (.cfg)
This file can contain paths and description of geographic data, computation zone definition,
filter/sort/group criteria applied to folders, display settings of objects, prediction study list,
customized studies, path to access macros and AFP settings. The file can be loaded automatically
or manually by the user. Each user and project can have own configuration file.
- Geographic data set:
- Definitions of the computation and focus zones
- List of coverage prediction studies:
- Automatic neighbour allocation parameters:
- AFP configuration (GSM GPRS EGPRS projects):
- Automatic scrambling code allocation parameters (UMTS HSPA and TD-SCDMA projects):
- Automatic PN offset allocation parameters (IS-95 cdmaOne and CDMA2000 1xRTT 1xEV-DO
projects
- Microwave Radio Links parameters
- Paths to files containing macros
The Atoll initialization file (.ini)
This file can contain site and transmitter naming conventions, calculation settings (modelling
method of antenna patterns) and other options (list of calculation servers, etc.). File is located in
the application folder, so it is for each client.
-General Options, like naming of new sites,
- Calculation Options, e.g. Cell edge coverage probability, saving method for prediction files,
display resolution for coverage arrays etc.
- GUI Options like display settings
- Distributed calculation server options, like serving servers, priority of service
- License options, to limit the modules to load
- Database Options, like database connection time out, automatic integrity checks
- GSM/GPRS/EGPRS/CDMA planning options
- Measurement options
An .xml study file
This file (default name: Studies.xml) describes prediction studies with customized settings.
The first step is to calculate and view a coverage or any other array plot and the from explorer
window to select Save as a template. XML file can be edited and imported back for a new
analysis
There is limitation of only one study can be active at the same time.
Conclusion: These functions work as promised. XML study could be easily expanded to the
standardization of threshold settings.
12/121
Report
Tools Management &
Support
2.6

18.6.2008, ver. 1.0
For internal use
Calculated results
Depending on the arrays, the results can be viewed on the map, exported to other formats (most
important ones Mapinfo and Bil) , as histogram and generated a report.
The report is easy to move to Excel using copy

and paste method.
Example of a simulation and Pilot

Pollution. Popup window is a nice way to
show the result pixel by pixel.
Conclusion: There are a lot of output options and they are easy to find. No problems covered.
2.7
Export and Import from and to Planner
13/121
Report
Tools Management &
Support
2.7.1

18.6.2008, ver. 1.0
For internal use
Export and Import from using Planet format
In Atoll there is 2 type of network planning data imports:

1. in XML format
2. Planet 2.8 Database import
Conclusion: Both of these are not the same NetAct Planner can produce, and therefore not
suitable solution in NSN.
2.7.2
Import from other tools
Forsk has introduced additional module to import data from other tools
Setup.CPTImport2.5.2.1704.exe
14/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Results
-
Propagation models were not imported.

In current version GSM sites and cells were not possible to import, and when trying to
import GSM cells to GSM project, the error message shows
When importing UMTS sites and cells, only antennas and sites were imported
NetAct Planner
Atoll
15/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Large Project 283 sites
The details of proper use of the import module for NetAct Planner plans has been discussed in the
Section 5.3.
16/121
Report
Tools Management &
Support
2.7.3

18.6.2008, ver. 1.0
For internal use
Import using ASCII format
Example of csv-file import
While importing the wrong values can be corrected before accepting the results.
17/121
Report
Tools Management &
Support
2.8

18.6.2008, ver. 1.0
For internal use
Atoll management Console
Before the management console is ready, all databases (in our terminology database = project in
NetAct Planner = user account in oracle) must updated.
Update process OK
Project database creation: OK. Project database is a clone from a master, a complete of partial
limited by a polygon or simple site filter.
18/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Opening a project database failed.
Because of the failure synchronizing of master and project database was not tested. The functions
to archive the master and refresh the project data, itself seam to be OK.
New database creation failed, reason unknown.
Concept of Master and Project database
19/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Conclusion: The concept of splitting the data into smaller groups is interesting. It brings some
admin work and my opinion it suits well in one or in few network planning projects. Centralized data
can be utilized in other functions of the company. On the other hand, the complete structure of data
(maps, traffic layers, local copies) is pretty complicated and it needs good knowledge and proper
discipline from all parties involved. The problems in the test were not crucial. In a smaller project
MS Access database is sufficient solution. Many tasks which belongs to users, are carried out by
administrator, e.g. the synchronizing antenna data in UMTS and GSM projects
2.9
Conclusions on Atoll Administration
Atoll is in its best when one user handles the complete data. It is also flexible if we need to combine small pieces of planning data to a countrywide project. But it not efficient if we have hundreds
of projects and we try to keep them centralized (it is not even efficient in NetAct Planner). The
synchronization of master, regional and local data is quite interesting idea.
The variety of storage methods gives also possibilities to manipulate data in many ways. It is easy
send a complete plan to a colleague with embedded digital map. The drawback is how we can
handle versions.
There seems not to be a big difference in the processing power, in NetAct Planner user can easier
select those data layers needed. The loading time of vectorized building data is longer in Atoll.
20/121
Report
Tools Management &
Support
3.

18.6.2008, ver. 1.0
For internal use
General Planning Issues in Atoll
The GUI of Atoll is heavily based on right-clicking. The general principle is that only global settings
are found in menus, and all parameter settings are made in dialogs that are found by right-clicking
on various objects in the trees at the Explorer window, which contains the data and objects of a
plan (which is called a document in Atoll), arranged hierarchically into folders. This is quite intuitive
in a sense that parameters of an object can found by right-clicking the object itself. However, since
the right-clicking menus are often 4-5 levels deep, it can be difficult to guess, where to start rightclicking.
Atoll computes prediction studies, Monte Carlo simulations, etc. within a user-defined computation
zone. The computation zone is undefined by default, and nothing can be computed in Atoll before it
is defined. The easiest way to define the computation zone is to zoom to large enough area and
select to fit the zone to the map window.
After the computation zone has been defined, Atoll carries out the calculation for all base stations
that are active (via a checkbox), selected by the current filter parameters, and whose propagation
zone intersects a rectangle containing the computation zone (whether the actual base stations are
inside or outside the computation zone).
In addition to the computation zone, there are also other Atoll zones that affect operations:
-
filtering zone restricts the objects displayed on the map and on the Data tab of the Explorer
window; it also restricts which objects are used in coverage predictions, etc.;
focus zone selects the area on which reports and results are generated;
printing zone defines the area to be printed;
coverage export zone defines part of the coverage prediction to be exported as a bitmap.
3.1
Map Formats
Digital maps that are in the NetAct Planner format (which is actually the Planet format) can be
imported to Atoll layer by layer simply by selecting separately the index.txt files in the height and
clutter directories of the map for import (from File | Import). After import of clutter, also the names of
the clutter types shall be correctly set in the map. The coordinate system of the map has to be set
separately under Tools | Options | Coordinates. The list of supported coordinate systems seems to
be quite comprehensive.
Vectors can also be imported in the same way. The old Planner vector format (of Planner 5.0)
corresponds to the Planet format, and the complete set of map vectors can be imported by
selecting the index.txt file. Such a complete import is not possible for the new Planner vector format
(MapInfo format vectors with index.xml file in Planner 5.1 and newer), but it is possible to import
individual MapInfo format (.mif or .tab) vectors one by one.
The following figures show screenshots of the clutter layer of the Helsinki Demo Map (for the UTM
zone 35N) in NetAct Planner and in Atoll (after the colour schemes were manually set to be
approximately equal).
21/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 1. Clutter layer of the Helsinki Demo Map in NetAct Planner.
Figure 2. Clutter layer of the Helsinki Demo Map in Atoll.
22/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
After import of a height or clutter layer of a NetAct Planner map, the individual map blocks will be
shown as separate branches in the Geo tree of Atoll. The individual map blocks (of one resolution)
of Planner can be combined into one single map file (into a single .bil file and the associated .hdr
file) just by selecting Save As in Atoll. Forsk recommends using such single file for each map layer
instead of large number of blocks.
When using maps with layers of multiple resolutions, the highest resolution map must be on top on
the tree. Atoll will try to use the maps in the order that they appear in the tree. Maps can be embedded into project configuration files (the .ALT files) so that a complete planning project can be
sent from one (standalone) Atoll user to another.
3.2
Antenna Import
Planet-format antennas can imported to Atoll, but the individual .msi files cannot be selected for
import as such. Instead, it is necessary to create an index file that lists the names of individual
antenna files to be imported, and to import this index file.
For an electrical tilt antennas, radiation patterns of different electrical tilts have to be imported
separately, and they cannot be combined together into a single antenna structure in Atoll.
The electrical tilt of an antenna is presented to user in somewhat confusing way. The electrical tilt
that has been read from the antenna import file is not displayed at all in an Atoll transmitter. Instead, all transmitters have a parameter additional electrical tilt. This parameter just introduces an
additional vertical rotation to the current antenna pattern. By using this parameter, electrical tilt can
be approximately modelled, when the exact antenna radiation patterns are not available.
There are no shared antennas in Atoll. Each transmitter must have it's own antenna, even if they
model the same physical antenna. When azimuth or tilt of one antenna is changed, the change has
to be repeated in the same way in the other transmitters that are using the same physical antenna.
3.3
Propagation Models
In Atoll, there are two distinct implementations of the Okumura-Hata propagation model: the
Okumura-Hata model for 150-1500 MHz and the Cost-Hata model for 1500-2000 MHz. Atoll users
have to explicitly select, which model to use. The selection of the correct formula does not take
place automatically according to the carrier frequency like in NetAct Planner.
The Okumura-Hata and Cost-Hata model are just direct implementations of the Hata equations. In
both of them, a so-called "clutter formula" can be assigned for each clutter type. The "clutter formula" is just one of the standard Hata equations for open, quasi open, suburban or urban (small or
large city) areas.
The Okumura-Hata and Cost-Hata model both take into account loss due to (knife-edge) diffraction, but only for one obstacle in the radio path. However, neither Okumura-Hata nor Cost-Hata
model take into account effective antenna height corrections due to differences in terrain height at
location of base station and terminal. The Okumura-Hata and Cost-Hata model cannot be tuned
from measurements. They could be possibly used for some nominal planning cases, but they are
useless in real detailed planning.
23/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
However, in addition to these two models, there is also the Standard Propagation Model, which is a
propagation model based on generalization of Hata formulas with six K coefficients that can be
edited by a user. The Standard Propagation Model of Atoll is similar to the Standard Macrocell
Model of Aircom, and hence it's prediction and tuning capabilities should also be similar to Aircom's
model. However, these two models are not exactly equal, and setting their parameters to correspond each other requires careful consideration.
The effective antenna height correction options of the Standard Propagation Model in Atoll are:
-
height above ground,

height above average profile,
slope at receiver,
spot Ht,
absolute spot Ht,
enhanced slope at receiver;
while the effective antenna height correction options in Planner are: absolute, average, relative and
slope, of which the method relative is recommended by Aircom. The Atoll's method spot Ht is
equivalent to the method relative in Planner. Atoll supports automatic selection of best antenna
height correction option in model tuning.
The Standard Propagation Model takes into account loss due to (knife-edge) diffraction from
multiple obstacles in the radio path. Diffraction losses can be calculated by using the methods:
- Deygout
- Epstein-Peterson
- Deygout with correction
- Millington
The diffraction methods in Planner are almost the same. The Millington method is not available, but
there is method Japanese Atlas, which is similar to the Epstein-Peterson method.
The Standard Propagation Model also takes into account effective antenna height corrections due
to differences in terrain height profile between the base station and terminal by using various
methods. The Standard Propagation Model is also a dual-slope model, where different K1 and K2
coefficients can be defined for short and long distances.
The Standard Propagation Model can be configured to use either a systematic or radial profile. The
"systematic profile" means that Atoll determines a separate profile (i.e. radio path) between each
transmitter and each pixel in its calculation area, while the "radial profile" means that Atoll establishes profiles from transmitters to each pixel on its calculation perimeter and uses the nearest
profile to make a prediction for pixels inside the calculation perimeter. Radial computation can be
carried out in much shorter calculation time. The results of radial computation will be slightly less
accurate, but as long as the resolution of computation is high enough, the accuracy should not be a
serious problem.
The other standard propagation models of Atoll are:
- ITU 529-3 Propagation Model
- Erceg-Greenstein Propagation Model
- WLL Propagation Model
- Longley-Rice Propagation Model
24/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
- ITU 1546 Propagation Model

An interface for 3rd party propagation models - like the Volcano models of Siradel - is also available
in Atoll. Atoll recommends that ray-tracing models should be used for planning of WiMAX networks
in urban areas; the accuracy of Atoll's Standard Propagation Model at WiMAX frequencies is only
satisfactory for planning of rural areas, since the high frequencies of WiMAX complicate the
propagation prediction.
In Atoll, it is possible to assign two propagation models to a single cell (to a single transmitter in
Atoll vocabulary): the main and extended propagation model. For both of them user can define
separately the propagation model, calculation radius and resolution. Two separate path loss
matrices (path loss prediction files) of different resolutions shall be calculated for the two models.
3.3.1
Usage of Two Propagation Models per Cell
Atoll supports free selection on propagation model and coverage array resolutions. Also two
propagation models per transmitter can be used. The idea of specifying two propagation models is
to achieve faster computation times. The resolution of a coverage array (prediction study) calculation is independent of the resolutions used in path loss matrices calculation. The following Figure
illustrates a prediction study made in Atoll. The prediction model resolution was 10 m for up to 3000
m distance, and 100 m beyond 3000 m. Point analysis display shows the distance of 3000 m from
site. The coverage study is shown on map with selected 10 m resolution regardless of the resolution used in path loss matrices.
25/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 3. A prediction study in Atoll for a prediction model with resolution 10 m until 3000 m and 100 m
beyond 3000 m.
When primary and secondary prediction models with different resolutions are used in NetAct
Planner 6.0, the coverage array resolution is limited by the prediction resolution. The following
Figure illustrates an example of coverage array in Planner. Path loss prediction is calculated on 10
m resolution for up to 3000 m, and 100 m resolution beyond 3000 m. Coverage array is calculated
with 10 m resolution. The resulting array shows coverage with 10 m resolution only in areas where
10 m resolution path loss prediction is available.
26/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 4. Multiresolution coverage array in NetAct Planner.
Both Atoll and NetAct Planner 6.0 support use of two propagation models per cell or transmitter,
and the resolution of coverage array calculation array is independent on resolution of prediction
files or path loss matrices. What is different in Atoll, is the fact that prediction study resolution
calculation can actually be interpolated to a finer resolution than the path loss matrices. What is
good in the Planner approach is that it can be clearly seen where the poorer prediction resolution
has been used.
3.3.2
Approximation of NetAct Planner's Nokia Propagation Model in Atoll
At 2100 MHz the Nokia Propagation model of NetAct Planner implements the Hata path loss
equation
L = 46.3 + 33.9 log(2100) 13.82 log(hB) + [44.9 6.55 log(hB)] log(d/1000)
where
f is the propagation frequency in MHz,
hB is the height of the base station antenna in m,
hM is the height of the mobile station antenna in m,
d is the distance between base station and mobile station in m.
The same path losses can be calculated from the Standard Propagation Model of Atoll
L = K1 + K2 log(d) + K3 log(hB) + K5 log(hB) log(d) + K6(hM)
when it's coefficients are set to
27/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
K1 = 46.3 + 33.9 log(2100) 344.9 = 24.22,

K2 = 44.9,
K3 = -13.82 + 36.55 = 5.83,
K5 = -6.55,
K6 = 0.
Frequency does not appear in the formula of the Standard Propagation Model. This model can be
configured to only one frequency at a time by setting the K1 coefficient. For frequencies below
1500 MHz different form of the Hata path loss equation must be used, and the corresponding Atoll
model will also be different.
In addition to selecting the K coefficients, it is also necessary to configure the effective antenna
height correction and diffraction correction in equivalent way in both models. The recommended
effective antenna height correction and topo correction for Nokia Propagation model are Method A
and Diffraction, and the recommended configuration of diffraction calculation is Weight Factor 67%
and method Deygout (N >= 3). In Atoll, the corresponding antenna height correction is Spot Ht, and
the corresponding diffraction loss algorithm is Deygout with K4 coefficient set to 0.67.
Line of sight calculation is recommended to be disabled in Planner, and hence it should be also
disabled in Atoll. The recommended morpho correction in Planner is Function, and the same clutter
correction factors that have been defined here for each clutter type should be defined also is Atoll.
After such configuration of propagation models, the prediction results in NetAct Planner and Atoll
are very close to each other, and the following network analysis should give similar results in both
software.
3.3.3
Approximation of Planner's Standard Macrocell Model 3 in Atoll
The path loss equation for Aircom's Standard Macrocell Model 3 is

L = k1 + k2 log(d/1000) + k3(hM) + k4 log(hM) + k5 log(hB) + k6 log(hB) log(d/1000) + k7(diffn)
where
d
hM
hB
diffn
distance from the base station to the mobile station (m),

height of the mobile station above ground (m),
effective base station antenna height (m),
diffraction loss;
and the path loss equation for the Standard Propagation Model of Atoll is
L = K1 + K2 log(d) + K3 log(hB) + K4(diffn) + K5 log(hB) log(d) + K6(hM2)
where
d
hB
hM2
diffn
distance from the base station to the mobile station (m),

effective base station antenna height (m),
effective mobile antenna height (m),
diffraction loss.
The following table shows the default k coefficients of the Standard Macrocell Model 3 at 2000
MHz, and the corresponding K coefficients of the Atoll's Standard Propagation Model.
28/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Coefficients of default Standard Macrocell

Model 3 at 2000 MHz
k1 = 162.5
k2 = 44.9
k3 = -2.55
k4 = 0
k5 = -13.82
k6 = -6.55
k7 = 0.8
hM = 1.5
Corresponding Coefficients of Atoll's Standard

Propagation Model
K1 = k1 3k2 + hMk3 = 23.98
K2 = k2 = 44.9
K3 = k5 3k6 = 5.83
K4 = k7 = 0.8
K5 = k6 = -6.55
K6 = 0
Forsk has a document ConvertMacroCellAssetToSPMAtoll.doc that discusses the conversion of the

Aircom's Standard Macrocell Model 3 into the Standard Propagation Model of Atoll.
The default effective antenna height correction of the Standard Macrocell Model 3 in NetAct
Planner is Relative, and the default diffraction loss algorithm is Epstein Peterson. In Atoll, the
corresponding antenna height correction is Spot Ht, and the corresponding diffraction loss
algorithm is Epstein-Peterson.
After such configuration of propagation models, the prediction results in NetAct Planner and Atoll
are very close to each other. The following figures show the UMTS Pilot Coverage from Planner
and received signal levels in Atoll (without fading margin) for a small artificial network of 8 base
stations, when corresponding propagation models have been used.
The coverage prediction results in the two tools are very close to each other.
29/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 5. Best RSCP (pilot coverage) array from NetAct Planner.
Figure 6. Coverage by signal level in Atoll.
30/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 7. Best downlink cell by RSCP (pilot coverage) array from NetAct Planner.
Figure 8. Coverage by transmitter in Atoll.
3.3.4
Propagation Model Tuning
31/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Among the standard propagation models of Atoll, only the Standard Propagation Model can be
tuned. In tuning of propagation model, Atoll supports normal filtering of measurement data by
distance, signal level, azimuth and clutter class.
Measurements for model tuning can be imported into Atoll in text format files (in .dat, .txt or .csv
files). The binary formats of measurement files are not supported.
In actual tuning, it is possible to individually include or exclude any of the K coefficients, clutter
corrections, antenna height correction and diffraction correction from tuning. This enables model
tuning in multiple successive stages, which should facilitate robust tuning. Atoll has a separate
"Measurements and Model Calibration Guide" that describes in detail the model tuning process.
No tests on model tuning were carried out, but Forsk demonstrated the tuning process. There are
no reasons to expect that model tuning would cause any serious problems in Atoll.
3.4
Prediction Calculation
When creating coverage predictions (prediction studies), an user can define any coverage resolution for calculation. The resolution does not have to be the resolution of the path loss matrices or
it's multiple. Atoll can decimate or interpolate the results into any given resolution, and it will use the
clutter information of the path loss matrices irrespective of the calculation resolution.
Like NetAct Planner, also Atoll supports use of measured data to correct the prediction result (over
an elliptical area) around the measurement point.
32/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
4.
2G Radio Planning in Atoll
4.1
General issues about 2G radio planning in Atoll
The evaluated version of Atoll was 2.7.0 (Build 2432). Atoll has been previously evaluated for 2G
planning by Siemens in autumn 2006. The version used in that evaluation was 2.5. The evaluation
was done by comparing key dimensioning and planning related calculations in Atoll vs. TornadoN,
which is in practice same tool as NetAct Planner. Report of the previous evaluation by Siemens is
stored in IMS:
https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/387103191
The version used in TornadoN was not mentioned in the evaluation report, but it is expected that it
was 5.0.
Basic 2G radio planning functionality has not much changed from Atoll version 2.5 to 2.7. Hence
the findings in the previous evaluation by Siemens should be still valid and similar comparisons
were not carried out in this evaluation for Atoll for 2G even though some overlapping of course
there inevitably is. The result of the previous evaluation was that differences in calculations in Atoll
and TornadoN in terms of prediction, dimensioning results, interference analyses etc. were rather
small and both tolls were concluded to deliver correct results for planning. Moreover, it was
concluded that due to better flexibility and ease of use, Atoll was seen as preferred tool.
It can be well argued that for many normal radio planning tasks Atoll is easier to be used. Also, with
Atoll different types of analysis with different criteria and parameter values are much easier to be
calculated and in fact Atoll can produce many types of results which NetAct Planner cannot. It is of
course somewhat question of opinion how relevant these different prediction results are.
There are also areas where NetAct Planner is better than Atoll. For example automatic neighbour
planning algorithm is better in NAP, even though reasonable neighbour plan can be created with
Atoll as well. In NetAct Planner also simulations can be used for 2G planning, even though there
are some issues due to which simulation may not be very good idea for 2G planning in NetAct
Planner (see https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/371883392).
As a short summary it can be concluded that Atoll for 2G radio planning is very flexible and user
friendly tool that features very broad capabilities for analysing expected network behaviour and
performance based on path loss predictions.
33/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
4.2
2G Coverage planning
4.2.1
Simulation vs. static calculation based calculation
Monte Carlo simulations are in Atoll available only for UMTS/HSPA, TD-SCDMA and WiMAX
network technologies. 2G planning is based on basic predictions, which takes path losses and DL
powers into account. No terminal parameters are considered and no snapshots are run for analysing effect of traffic amounts.
The lack of simulation capabilities is not major deficiency in Atoll; in fact, already current capabilities for network analysis can be seen as more than adequate. Even if Atoll is in principle easy to
use, there still are many things user need to consider when making planning decisions based on
tool calculation results.
4.2.1.1
Result analysis per pixel
Atoll has point analysis tool, with which many prediction based calculation results and network
environment can be analyzed per point. There are different options available in Point Analysis tool
for 2G and 3G. For 2G planning, following are available:
-
Profile tab for analyzing profiles between transmitter and receiver. Received levels
calculated in real time
Reception tab for analyzing predicted signal levels from number of servers.
Calculations are based on path loss matrices.
Interference tab for analyzing interferences between selected server and potential
interferers
Results tab for analyzing serving and interfering (co- and adj channel) levels in a point
In NAP similar functionality can be accessed via Map View Gadgets, Height Profile Window and
Pixel Analyzer. There are quite big differences in how all data is available and in which form. Due to
the big differences in how these are done in Atoll and NAP, it is difficult to compare these solutions.
Both are providing useful information for the planning process. What is good in Atoll is the fact that
many types of data are nicely and easily accessible in one window with several tabs. What is good
in NAP is that user can choose which data is shown and which is not and all data available from
simulations can be analyzed in Pixel Analyzer.
34/121
Report
Tools Management &
Support
4.2.2

18.6.2008, ver. 1.0
For internal use
Static Coverage calculation for Best server
4.2.2.1
Coverage visualisation
Coverage visualisation capabilities in Atoll are at least at the same level as is in NAP. In NAP
perhaps the visualisation functionality for the Arrays that are based on simulations are a bit more
advanced; the palette step vs. colour blend options, automatic step calculation and Coverage
Schema saving features offer better functionality for managing coverage visualisation in NAP.
Situation is different in NonSim arrays in NAP. The features are different for visualisation of NonSim
Coverage/Interference arrays. This makes the comparison between Atoll and NAP difficult. Perhaps
it is correct to conclude that both tools have adequate capabilities in coverage visualisation
capabilities and for 2G coverage visualisation it cannot be said which tool would be better.
4.2.2.2
Coverage Statistics
Coverage statistics generation functionality is in Atoll somewhat more graphical than in NAP. Data
is shown in histograms (as shown in the following figure) or CDF. Coverage areas can be reported
in area percentages or km2. In NAP the coverage statistic functionalities are less graphical but
more versatile. In NAP the coverage statistics are automatically created in Excel and there are
several options for generation of the coverage statistics. It is then up to the user to create the
needed graphs in Excel.
Figure 9. Coverage Statistics Dialog Window in Atoll.
35/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
4.2.2.3
Simulation based 2G coverage planning
Simulation is not possible in Atoll for 2G coverage planning. Therefore there is nothing to report
here. The lack of simulator for 2G Planning is not major defect as 2G planning is traditionally
downlink planning only and in GSM coverage and capacity are independent from one and another.
Therefore there is less demand for simulation for 2G as is the case with 3G radio planning.
4.2.2.4
Nth Best Server Calculation
In Atoll, Nth Best Server study is limited to 2nd Best Server only. 3rd or more cannot be done in Atoll
at all. What is better in 2nd Best Server study in Atoll is that 2nd Best Server study can be displayed
per Transmitter or per Signal Level and also number of criteria can be set for displaying the result.
4.2.3
Summary on 2G coverage planning
There are rather big differences between Atoll and NAP in basic coverage planning capabilities and
features available. Both tools offer feature that are missing from the other. It is impossible to say
which could be better as both do have versatile capabilities. E.g. in NAP there is the Compound
Array Generator that offers very large possibilities in combining results of one or more arrays with
certain criteria and these arrays can be based on simulations (2G or 3G) or Static
Coverage/Interference calculations. In Atoll there are much less possibilities in this area, but then
again, the possibilities that there are, are easier to be used.
Some notes on 2G Coverage planning in Atoll and NAP:
In Atoll
-
It is easy and quick to make different coverage studies with different criteria
Once different studies are created it is easy to switch from one study to another
Only one coverage map can be viewed at a time (2 map vies cannot be shown side by
side)
Graphical illustration on coverage statistics can be created easily
Simulation cannot be used for 2G planning
Point analysis tool offers nice possibilities in analyzing the results per point
In NAP
-
2G coverage planning can be based on Monte Carlo Simulations or Static

Coverage/Interference calculations
More than one map view can be visualized side by side
Has more versatile capabilities in combining results of different arrays with certain
criteria, but these are difficult to be used
Has more versatile coverage statistics reporting
36/121
Report
Tools Management &
Support
4.3

18.6.2008, ver. 1.0
For internal use
2G Neighbour planning
Atolls flexibility in comparison with NAP becomes apparent also in different aspects in automatic
neighbour planning. This has pros and cons. What is good in Atolls flexibility is that it is easy and
quick to alter the neighbour plan completely and it is also very quick to make a new neighbour plan.
Also different results can be evaluated and committed easily. What is less good in Atolls flexibility
is that in practice neighbour plan cannot be done so well in different steps as is the case with NAP.
Drawback in NAP is then that the rigidity of NAP and its database makes it rather difficult to change
the neighbour plan completely, which would in many cases be needed in practice.
Figure 10. Main neighbour planning dialog window in NAP.
37/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 11. Main neighbour planning dialog of Atoll.
The preceding figures illustrate the main GUI dialog windows for neighbour planning in NAP and
Atoll respectively. Even though the basic idea in neighbour planning is quite similar in both tools,
the main difference can be observed in these two dialogs. Basic idea in neighbour planning is to
determine if there is adequate amount of overlapping coverage between target and candidate cells
and by this way choose candidates to be chosen as neighbours for the target cell. Main difference
in this overlapping coverage determination is the fact that NAP has parameter Neighbour planning margin (dB), which is not existing in Atoll. By this parameter in NAP, user can specify how
much lower the candidate cells signal level can be in a pixel in order for that pixel to be counted as
overlapping coverage. In Atoll overlapping coverage is only considered in a target Cells Best
Server area (i.e. the coverage area where the target Cell has the highest signal level) added with a
second best serving area which is defined by Handover Start and Handover end parameters in
Coverage condition dialog (see the figure below).
Figure 12. Coverage condition dialog in Atoll.
38/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
It seems obvious, that using overlapping coverage only in automatic neighbour planning, will result
in practice in many neighbour relations missing. One way to increase the number of neighbours
found with this criteria is to use very large Handover End parameter value in Coverage Condition
parameters. By default this value was 12 dB, which can be considered as rather large. Due to the
fact that with overlapping coverage criteria only, we will not get all the neighbour relations wed
need, some features in neighbour planning has been added in Atoll.
The main selections in the automatic neighbour allocation dialog are Force co-site transmitters as
neighbours and Force adjacent transmitters as neighbours. The first one is obvious choice in
normal neighbour planning process and will result in the expected; co-site transmitters (=Cells) will
be defined as neighbours automatically. The latter is less straight forward. In this case adjacent
transmitter means a target cell has coverage in a candidate transmitters Best Serving area fulfilling
the Min BCCH Signal Level criteria at least in one pixel. This means in practice that using this
Force adjacent transmitters as neighbours selection will typically result in rather large amount of
neighbour relations.
In Atoll:
With default parameter values (% Min Covered Area = 10%) the overlapping
coverage criteria will result in just a few neighbors per Transmitter (Cell).
With default parameter values (Signal Level (BCCH) >105 dBm) the Force
adjacent transmitters as neighbors will result in large number of neighbor per
Transmitter (Cell)
Another matter that is different in Automatic Neighbour Planning in Atoll and NAP, is how Max No of
Neighbour limit is affecting. In NAP, the max no of neighbour limit limits only the number of
neighbours determined by selected criteria for a cell. If all neighbour relations are made mutual in
NAP (this is done after the automatic neighbour allocation is run), the mutuality will increase the
final number of neighbour relations resulting in larger number of neighbour relations for many cells
compared with the max number of neighbours criteria. In Atoll, the Max No of Neighbours is a hard
limit; even with the Force Neighbour Symmetry selection the number of neighbour relation will not
be exceeded for any transmitter. In fact, user will typically receive error messages stating that
neighbourhood symmetry was impossible.
39/121
Report
Tools Management &
Support
4.3.1

18.6.2008, ver. 1.0
For internal use
Manual neighbour planning
In both tools neighbour plans can be manually completed by adding or deleting neighbour relations
manually. In NAP, the manual addition of neighbour relations is easier, as it can be done in 2D Map
View by pressing the Add Neighbours button in 2D Map View and then selecting the neighbouring
cell. In Atoll, similar neighbour relation addition is also possible, but it is much less user-friendly;
user can add neighbour relations in Map View by pressing shift key and clicking new cells to be
added as neighbours. This method can never be figured out by user unless he reads the User
Manual. Of course, once the idea is recognized, it is very easy to add neighbour relations in Map
view manually.
4.3.2
Visual analysis of neighbour plan
Basic neighbor relation visualization in terms of lines indicating neighbor relations, are available in
Atoll the same way as in NAP. There are no big differences in this functionality. In addition to the
basic visualization, Atoll also features possibilities in visualization of coverage areas of neighbors
and reason for neighborhood. The following figure illustrates one example of neighbourhood
visualisation with neighboring cell service areas and neighbor relation causes. Green colour
indicates neighbor relation due to co-site cells, red colour indicates neighbor relations due to
adjacencies (=target cell has coverage in other red cells).
With neighboring cell coverage and neighborhood cause visualisation, Atoll can be concluded to be
somewhat more versatile in visual neighborhood planning. However, the usability in this kind of
analysis is somewhat low, i.e. it is difficult to create such map, and the true value of such
visualisation may be rather low.
Figure 13. Neighbour relation visualisation with coverage areas and neighbourhood reason.
4.3.3
Summary of neighbour planning in Atoll in comparison with NAP
40/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
In Atoll, the automatic neighbour planning is a lot quicker and much more flexible than in NAP. Then
again, the neighbourhood determination algorithm is more advanced in NAP (which is probably the
main reason for slower neighbour allocation process in NAP). Of course a reasonable initial
neighbour plan can be well created with Atoll, and that neighbour plan can then later be completed
with optimization tools such as NetAct Optimizer.
Also the neighbour plan management is somewhat better in NAP, due to its Oracle database data
management. In neighbour plan analysis NAP has perhaps more and better capabilities, even
though Atoll has nice features in visual illustration of neighbour relations, causes and service areas.
In both tools the automatic neighbour plan can be manually fulfilled by user. NAP is in this sense a
bit better as neighbour relations addition in 2D Map View is clearer as no special shortcut keys are
needed. NAP also incorporates semi automatic manual neighbour planning features that are quite
handy.
4.4
2G Capacity planning
4.4.1
General about 2G Capacity planning
Capacity planning may not be big issue in most of the GSM networks nowadays. Almost all networks are in a mature phase, where the biggest increase in traffic has been already long ago
experienced, at least for CS traffic. In PS traffic there could be more increase in traffic still to come.
For this reason there may not be much need for traffic planning for 2G traffic with a planning tool.
For 2G the definition of traffic in a planning tool is used only for determination of hardware
requirements. This is different in 3G planning, where amount of traffic has direct impact on simulation results. In general it could be argued that traffic definition in Atoll is rather complicated. Atoll
also lacks clear ways to check the amount of traffic based on which the planning is currently done.
4.4.2
TRX requirement definition methods and their applicability
4.4.2.1
Definition of traffic in Atoll
Atoll supports versatile ways to define traffic. Traffic definition is needed as basis for network
capacity analysis. Following ways for defining traffic are supported by Atoll:
Live traffic from network management system
Marketing based traffic data
Population based traffic data
2G network statistics
4.4.2.2
Some notes on different methods for traffic planning
-
This method of traffic determination was not tested during this evaluation. However, based on information from User Manual, we can conclude as follows. 1) Live traffic import functionality exists,
2) Traffic can be in units of Erlang or throughputs for PS traffic. 3) Traffic can also be imported as a
file from another Atoll document. 4) Terminal percentages, mobilities and Clutter distributions can
be defined and 5) Traffic map can be updated in case of e.g. added site.
41/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Atoll supports planning based on Marketing based Traffic Data, which can be based on user
profiles and/or environment data. The idea in user profiles is to model variations in user behaviours
during e.g. different times of day. The idea in environment maps is that marketing department can
specify certain environment maps based on which traffic amounts can be specified. This means in
practice that in e.g. urban clutter class in one city area there can be different traffic than in another
urban Clutter Class area.
This marketing based traffic data definition was only briefly tested in this evaluation test project.
Based on the tests it can be concluded that the environment definition works as documented and it
could be useful in case used properly. Environment based traffic map can be created or imported.
These kind of traffic definition possibilities are not existing in NAP.
Population-based traffic data can be based on population statistics and user densities can be
calculated from the density of inhabitants. Traffic density map can be created in Atoll or imported.
This traffic definition was not tested during this evaluation test project.
4.4.3
Carrier requirement definition in Atoll
Where in NAP it is discussed about Carrier requirement, in Atoll corresponding concept is TRX
Requirement. The process is in principle similar in both tools: after traffic raster has been defined,
traffic per Transmitter is captured by the tool hence coming up with a number describing the number of TRX (in Atoll) or Carriers (in NAP) required for each Transmitter or Subcell. Also both tools
have the possibility to scale the traffic to plan easily for increased traffic. GUIs related with traffic
capture and practical processes are a lot different
4.4.4
Frequency hopping planning
Atoll supports frequency hopping planning. The approach in Frequency Hopping planning is very
different in Atoll in comparison with NAP. Therefore it is difficult to compare these and detailed
frequency hopping planning validation was outside the scope of this evaluation test. Following
notes on frequency hopping planning in Atoll can be listed: 1) Frequency hopping planning is
supported. 2) With Atoll, HSN, MAIO and MAL can be planned (MAIOStep planning missing). 3) Not
all possible RF hopping planning strategies are supported by Atoll.
4.4.5
Interference matrix
There is somewhat confusing information of interference matrix in User Manual of Atoll. Quotation
of User Manual Chapter 7.4.2.2.1:
Before you can use the Atoll AFP module to allocate frequencies and BSICs, you must have created and calculated an
interference matrix.
Elsewhere in Atoll User Manual, it is said that interference matrix is not mandatory, e.g. in Chapter
7.4.2.1:
A valid interference matrix should also be generated (see "Interference Matrices" on page 265). Although it is possible
to run the AFP without an interference matrix, allocation will be calculated without taking interference into
consideration, i.e., without considering one of the two important constraints.
42/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
In NAP, interference matrix (table) is not mandatory for GSM frequency planning. Actually it could
be argued that in frequency planning with planning tools interference matrix is not very important
factor in frequency planning process. The need for (prediction based) interference matrix depends
on the neighbour plan, separation requirements and no of carriers available vs. TRX requirement.
Typically there should not be much room for interference minimization after co-cell, co-site and
neighbour separation requirements are met. And even if there still would be room for interference
minimization, this should be done based on network measurements using e.g. NetAct Optimizer
rather than path loss predictions.
In Atoll, interference matrix comprises probabilities for achieving different C/I ratios. In NAP,
interference matrix comprises amounts of interferences in Erlang or km2. In NAP, probabilities vs.
C/I levels are handled separately in interference weights table. The approach used in NAP is gives
clearer information to planner about amounts of interferences in case of co-channel allocation.
User can analyze better the results of interference matrix in NAP by e.g. Sorting interferers
according to amounts of interferences for a selected cell in order to find out the most interfering
cells in case of co-channel allocation.
Some notes on interference matrix creation in NAP and Atoll:
NAP:
-
Has more versatile options for prediction based interference matrix (table) creation
Has better capabilities for user to analyse (view) contents of interference matrix to
evaluate and check that the interference matrix to be used seem rational
Has more versatile options in interference matrix base: interference matrices can be
based on several OMC Statistics, test mobile data, CW measurements, etc.
Atoll:
43/121
Report
Tools Management &
Support
4.4.6

18.6.2008, ver. 1.0
For internal use
Timeslot configuration planning
Possibilities for timeslot configuration planning are quite at the same level in Atoll as in NAP. In Atoll
timeslot configurations are defined by TRX type. There user is able to specify number of shared
timeslots as well as number of Circuit and Packet timeslots. This means that capabilities in
signalling capacity planning are totally missing in Atoll as is the case with NAP as well.
Calculation of the number of TRXs required is based on the number of CS and PS traffic timeslots
vs. the required traffic. This, being at the same level as in NAP, can be seen as adequate planning
capabilities even though it would be easy to figure out enhancements in this area.
In practice the timeslot configuration definition (number of CS and PS traffic timeslots vs. TRX
count) is much easier in Atoll than is the case with NAP, but this is not very major issue.
4.4.7
TRX Requirement count calculation
As noted before, traffic definition in Atoll is rather complicated and it is somewhat challenging to
keep control on the amount of traffic according to which planning is to be performed. At the same
time it should be noted, that Atoll features very versatile ways to specify the traffic. Once user is
familiar with all aspects of traffic definition, Atoll offers good ways for planning work, but this
requires a lot of training for the users.
TRX requirement count calculation can be done with Atoll and it takes into consideration all needed
information: Used services, User profiles, Terminal capabilities, TRX types and amounts. The result
of TRX count calculation is number of required TRXs taking into consideration both Circuit- and
Packet Switched traffic. Atoll also features possibilities to determine codec capabilities of terminals,
but these selections are not considered in dimensioning calculations of Atoll (e.g. if half rate percentage of traffic is 50%, 50% of traffic is calculated to be half rate even though the terminals would
not support half rate).
For CS traffic the proportion of HR traffic affects on the timeslot / TRX count calculations in dimensioning. Proportion of HR is defined in Subcells. By default this value was 40%. It was tested and
noted that timeslot requirement and TRX count requirement calculations were correctly taking HR
amount into account in dimensioning for CS traffic. The proportion of HR traffic can be mass edited
in subcells by specifying the value in Cell type dialog. This means in practice that same proportion
need to be used in all subcells using certain Cell type; we cannot easily edit these values per e.g.
certain area unless specifying a new Cell type and use that in the needed area. This could be a
little problem, if far-sighted traffic planning is to be done. This should not be very typical case. If HR
portion is changed and new dimensioning is hence needed, new traffic capture must be calculated
before dimensioning calculation in order for the new HR portion to be considered in dimensioning.
Dimensioning for PS traffic was not actually tested. It was only noted that all needed functionality
for dimensioning for PS traffic seem to be available in Atoll. Multi timeslot capability in terminals can
be modelled, number of PS, CS and shared timeslots for TRX types can be modelled etc. So
basically all features for PS dimensioning and traffic planning are in place, offering needed capabilities. Practical execution for planning will comprise certain challenges which would require
extensive training for users in case Atoll is chosen as the tool to be used.
4.5
GSM Frequency planning
44/121
Report
Tools Management &
Support
4.5.1

18.6.2008, ver. 1.0
For internal use
Automatic frequency planning
In NAP, automatic frequency planning is widely considered to be rather difficult process and due to
this reason it is not very widely used for frequency planning. In Atoll, the situation is not very much
different. Also in Atoll the process is not very simple and straightforward process. Also the fact that
the frequency planning process in Atoll is very different from the corresponding in NAP, extensive
user training would be required for users familiar with GSM frequency planning process in NAP.
Figure 14. Frequency allocation progress window in Atoll.
The preceding figure illustrates the main automatic frequency allocation dialog window in Atoll.
Major difference between Atoll and NAP is the speed at which frequency iterations are performed,
in tests done in this evaluation project iterations in NAP were 60 times faster than the solutions in
Atoll. This is of course due to the different nature of algorithms used for these iterations or solutions
and without more detailed information about these algorithms, we cannot say anything which would
be better.
45/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
In Atoll, Focus Area is used to determine the area to which frequency planning is to be made.
Calculation area is the area covering focus area and surroundings; cells outside focus area but
within calculation area are considered in automatic frequency planning process but the frequency
allocations are not altered in the allocation process. In NAP, it is possible to specify planning areas
in more versatile ways. The following figure illustrates how planning areas would be defined in NAP
in case frequency re-planning is needed in a certain area if sites. As frequencies are to be changed
in this area delimited by red polygon, it is likely that some changes are needed in the surrounding
vicinity of this area (blue polygon). Then again, current carrier assignments in blue polygon area
are needed not to be changed unless they have to be changed. For this reason it is good to be able
to specify frequency planning actions so that carriers can be re-planned in this area with a certain
cost. Cells outside blue polygon area would be taken into account in planning but not changed at
all.
Area where frequency

re-planning is to be
done
Area where frequency

re-planning may
occur with certain
cost.
Figure 15. Illustration of frequency planning area definition possibilities in NAP.
Such definition of planning areas as illustrated in the preceding figure cannot be done hence it
could be argued that Atoll is a bit behind NAP in this functionality.
The following figure shows the frequency plan result window in Atoll. This window appears right
after the automatic allocation process has run for the user specified period of time. What is
extremely good about this window is that it gives instant information on separation violations in a
way that a user cannot fail noticing it! In NAP, the process of checking separation violations after
automatic frequency planning has been run, is as follows:
46/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
1. Apply the created plan into database

2. Start Frequency Planning Reporter
3. Specify the type of report you need and separation constraints against which you want to
check the plan
4. Create the report in Excel and analyse results
Figure 16. Frequency plan result window in Atoll.
So the process to find out about the possible separation violations is much easier and actually
automatic in Atoll whereas in NAP it is somewhat laborious process.
The Frequency Planning Report functionality in NAP gives freedom for user to specify the separations against which the analysis is done, and also some other means for analyzing the quality of
the resulted frequency plan. Also in Atoll the frequency plan can be afterwards analysed by Audit
functionality where separations, BSICs, HSNs etc can be analyzed.
47/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
In this tool evaluation project automatic GSM frequency plan was made for basically the same
network plan. The plan used in this exercise was not exactly the same: neighbour definitions were
a bit different. This is because neighbours were generated in NAP by NAP and in Atoll by Atoll.
Hence the neighbour assignments were not exactly the same (even though quite close) making the
critical issue of neighbour separation requirements different between these two tools. Therefore the
GSM frequency planning cases were not exactly the same and hence direct comparisons of the
quality of GSM frequency plan was not possible to be made. However, it was noted in the tests that
both tools (Atoll and NAP) seemed to produce rather similar GSM frequency plans in terms of
separation violations and interference results in plan. This means that the performance of automatic GSM frequency planning seemed to be at the same level in both tools in terms of planning
speed and quality of the resulted plan.
4.5.2
Manual GSM frequency planning
By manual GSM frequency planning we mean here a case where one or several carriers need to
be allocated to one or few cells. In NAP this type of case is such that definitely should be called
manual frequency planning, i.e. frequencies are selected and allocated manually. This is the way
that such case has to be handled in NAP, as usage of ILSA in such case is not feasible in practice.
Atoll is better than NAP in this type of case; i.e. case where one or a few carriers need to be allocated. In Atoll user does not have to find the ARFCN manually; he can easily use the tool for this
purpose. For this reason the term manual frequency planning is a bit misleading.
The process of finding one new frequency for a transmitter seemed to work well in Atoll. A
satisfactory result was produced quickly and the automatic frequency plan Result dialog window
showed nicely New Value for the Channel Assignment that just had been done. This method is
very useful functionality that actually is completely missing in NAP.
4.5.3
Summary about GSM Frequency planning
GSM planning functionalities in Atoll were not comprehensively evaluated against NAP in this
evaluation testing project. Exhaustive analysis would require much bigger effort. However, the AFP
functionality was tested in the extend that following conclusions can be made:
-
NAP has better capabilities in making a completely new frequency plan in a limited area making
limited but necessary changes in frequency allocations outside this re-planning area
Atoll has nice feature for finding automatically one or few new carriers in one or few cells
Quality of frequency plan results seemed to be at the same level in both Atoll and NAP, but this
was not comprehensively evaluated
GSM frequency planning process as whole is in both tools rather complex matter. This is perhaps unavoidable since there are so many issues to be considered in GSM frequency planning
48/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
4.6
Code and ID planning
4.6.1
Planning and management of codes
There are number of identifiers used to identify network elements. These are needed especially
when transferring plan data between planning tool and network management system. There are
number of issues to be considered when determining applicability of Atoll for NSN usage taking into
account aspects related with issues how plan data transferring could be carried out in practice.
Detailed analysis on these questions were out of scope in this evaluation project.
Following codes are relevant when transferring GSM network plan data between Network
management system NetAct and a planning tool:
-
BTS ID, BCF ID, Cell ID, TRX ID, LAC, RAC, BCC, NCC
Of these identifiers BTS ID, BCF ID, Cell ID, LAC and RAC are completely missing from Atoll. TRX
ID as such does not exist in Atoll, but corresponding object TRX index exists. For BSIC planning
(BCC and NCC) Atolls AFP tool has needed planning capability.
The absence of the above mentioned objects are not necessarily a big problem. User can add
fields in transmitter table and by this way produce the needed identifiers. However, automated
planning capability for these indicators of course does not exist. In NAP, there is automated
functionality for BTS ID generation which has been implemented for Nokias purposes earlier.
There are number of ways the network plan data transfer between planning tool and network
management system is carried out. Therefore it is not clear how applicable Atoll as a planning tool
is in comparison with NAP, detailed analysis of these questions are left as open issue at this point
of time.
4.7
Reporting
Reporting capabilities of Atoll and NAP are difficult to be compared against one and another as
they are rather differently implemented. Both tools features wide possibilities in reporting of plan
data and predicted network performance statistics. It seems that NAP has even larger reporting
capabilities, but we cannot find any major deficiencies in reporting capabilities of Atoll.
Transmitter table contains most of the relevant plan data in Atoll. The Table 1 contains the fields
normally available in the transmitter table. In case some needed data is missing (e.g. LAC), it can
always be added in the appropriate table. The data in the table can be easily copied to Excel. In
case tailored data tables are used, it may of course turn out to be an administrative challenge,
how to keep under control what data there are in data tables.
49/121
Report
Tools Management &
Support
Site
Transmitter
Active

18.6.2008, ver. 1.0
For internal use
DY (m)
Antenna
Power (dBm)
Losses (dB)
Feeder Equipment
Transmission Feeder Length
(m)
Miscellaneous transmission
losses (dB)
TMA Equipment
Height (m)
Azimuth ()
Mechanical Downtilt ()
Additional Electrical Downtilt ()
Cell type
Reception Offset (dB)
BTS Equipment
Main propagation model
Main calculation radius (m)
Main resolution (m)
Extended propagation model
Extended calculation radius (m)
Frequency band
Extended resolution (m)
Hopping mode
HCS layer
Layer Reception Threshold
Min range (m)
Max number of TRXs

Required TRXs
Number of TRXs
Channels
Max range (m)

EIRP (dBm)
BCCH
Freeze channels and MAIO
DX (m)
BSIC domain
BSIC
Freeze BSIC
Freeze HSN
GPRS/EGPRS
GPRS/EGPRS Equipment
Max number of coding
schemes (unused)
Codec Equipment
FN Offset
AFP Weight
Hexagon groups
Hexagon radius (m)
Max number of intra-technology
neighbours
Max number of inter-technology
neighbours
Comments
PBCCH Supported
PBCCH Reception Threshold
PBCCH Offset For Cell
Reselection (dB)
Table 1. Default fields in transmitter table of Atoll.
Network performance type of reporting can be produced in Atoll quite at the same level as in NAP,
even though the implementation is very different. These are e.g.
-
Frequency allocation statistics

Coverage and/or interference statistics
Throughput statistics
50/121
Report
Tools Management &
Support
4.8

18.6.2008, ver. 1.0
For internal use
Conclusions on 2G radio planning with Atoll
Atoll includes in principle all functionality needed for 2G radio planning. The practical implementation of many basic features needed in 2G radio planning are quite different from the corresponding ones in NAP. This means that if Atoll is chosen as planning tool, quite extensive competence
development activities should be carried out. Atoll is a good tool, it has good features and it is for
most planning tasks quite easy and fast once the user knows how to use the tool. Atoll actually
performs many calculations faster than NAP does the corresponding calculations. Atoll also has
versatile ways to define different criteria for many coverage and/or interference studies hence
making it possible to produce many types of analysis quite easily.
Quality of the GSM frequency plan produced by Atoll was not benchmarked against the corresponding with NAP. Detailed analysis of frequency plan result would be very laborious task as
several types of cases would need to be studied carefully and the comparison should be based on
rather large plan. Nevertheless, based on the tests done during this evaluation, it seemed that the
frequency plan quality is quite at the same level. There are aspect at which Atolls frequency planning is better than NAPs but also vice versa.
Atoll is very flexible tool. This flexibility may be good or bad, depending on the type of usage.
Mostly this flexibility is beneficial, but it requires rather disciplined usage and administration, but if
this is not a problem, the flexibility is very good.
51/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
5.
UMTS Planning in Atoll
5.1
Test Environment
The UMTS tests have been carried out on an Lenovo T61p notebook with 3 GB memory. The
following software environment has been utilized.
Software
Atoll
Operating system
Version
2.7.0, build 2432
Windows XP Professional SP2 (ver. 5.1.2600)
The exact Atoll module configuration was:

Module
Application Kernel
Coverage module
Import of DXF filter module
Measurements module
MicrowaveRLink Module
Import filter of PlaNet database module
UMTS module
Module Wimax
Atoll Propagation Models
GIS components module
Smart Antenna Module
Atoll Automatic Frequency Planning Model
Version
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
2.7.0 (Build 2432)
File
Atoll.exe
Coverage.atx
DxfImport.atx
Measures.atx
MicrowaveRLink.atx
PlanetImport.atx
UMTS.atx
Wimax.atx
FskPpag.dll
FskGIS.dll
FskSA.dll
StdAfp.dll
Atoll has been used in standalone single-user configuration on a single notebook PC without any
external database.
Installation of Atoll is very fast, since it does not require any external database. Hence, Atoll is very
well suited to different kinds of rapid tests and experiments. However, the standard installation of
Atoll did not work properly in the test PC, but it was necessary to install the Sentinel driver (for the
Sentinel dongle) separately again.
52/121
Report
Tools Management &
Support
5.2

18.6.2008, ver. 1.0
For internal use
UMTS Parameters
Configuration of an UMTS network requires setting of a huge number of parameters in various

network elements. Only a subset of them is necessary for network planning, but still the required
number of parameters in base stations and cells in a planning tool is very large.
In addition to the parameters of base stations and cells, performance analysis in a planning tool
requires setting a large number of parameters for various services as well as setting global
parameters related to radio propagation.
The performance analysis by Monte Carlo simulation can provide accurate estimates only if the set
of parameters is rich enough to realistically model the important aspects of a real UMTS network.
5.2.1
Clutter Parameters
In Atoll, the global parameters for each clutter type (for an UMTS plan under Geo | Clutter Classes
| Properties) are:
-
model standard deviation of shadowing loss on the path loss,

Ec/Io standard deviation of shadowing loss on the Ec/Io values,
Eb/Nt standard deviation DL of shadowing loss on the Eb/Nt values,
Eb/Nt standard deviation UL of shadowing loss on the Eb/Nt values,
indoor loss,
orthogonality factor,
% pilot finger (percentage of energy received by one mobile pilot finger).
The shadowing loss on path loss defines the random errors that are used in Monte Carlo simulation
while testing connections of terminals. The shadowing losses on Ec/Io and Eb/No values - and the
desired cell edge coverage probability - define the shadowing margins that can be optionally (by a
check box) added during calculation of prediction studies. These definitions allow prediction studies
at different shadowing margins to be created independently of the shadowing that has been used in
simulations.
The desired cell edge coverage probability can be set under Data | Predictions | Shadowing
Margins and Gains. The default value is 75%, which corresponds to area reliability 90% (for path
loss exponent 3.4 and standard deviation 10 dB of shadowing).
Forsk uses the abbreviation Eb/Nt in documentation instead of Eb/No (actually Eb/N0) to emphasize
the point that the spectral density of noise is for total noise that contains all noise and interference
components.
Atoll does not support separate standard deviations of shadowing for indoor and outdoor. Both
indoor and outdoor terminals encounter the same shadowing error (for a given clutter type) in
simulation, and the only difference between indoor and outdoor terminals is the additional indoor
loss.
The "% pilot finger" factor models the phenomenon that the Rake receiver of an UMTS UE uses
only one searcher finger for pilot reception. The searcher finger selects one path and only energy
from this path is considered as signal; energy from other multipaths is considered as interference.
The "% pilot finger" factor affects the Ec/Io calculations.
53/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Like in NetAct Planner, also in Atoll it is possible to define orthogonality factors per clutter. If the
orthogonality factor fields of clutter types are left blank in Atoll, the default orthogonality factor (from
the Global Transmitters tab of the Transmitters Properties dialogue) will be used.
The selection of clutter parameters in Atoll is more extensive than the one in NetAct Planner except for the missing standard deviation for indoor shadowing. The effects of clutter can be
modelled as accurately in Atoll as in NetAct Planner.
5.2.2
Network Configuration
While UMTS network configuration in Planner is based on defining properties, Node Bs and cells,
network configuration in Atoll is based on sites, transmitters and cells. Cell objects in both software
correspond well to each other, and the Planner properties correspond to the Atoll sites. An Atoll
transmitter models one antenna sector including the base station hardware for the sector, but it's
parameters correspond nicely to parameters of a complete Node B in Planner. The transmitter-level
parameters in Atoll include:
-
transmitter identity,
site,
activity,
antenna,
antenna height,
antenna azimuth,
mechanical downtilt,
additional electrical downtilt,
main propagation model,
main calculation radius,
extended propagation model,
extended calculation radius,
noise figure,
TMA equipment,
feeder equipment,
reception diversity,
transmission diversity;
54/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
and the cell-level parameters include:

-
cell name,
transmitter,
carrier,
activity,
max power,
pilot power,
SCH power,
other CCH power,
UL load factor,
max UL load factor,
max DL load,
HSDPA enabled,
available HSDPA power,
power headroom,
min number of HS-PDSCH codes per DL TS,
max number of HS-PDSCH codes per DL TS,
HSDPA dynamic power allocation,
HS-SCCH dynamic power allocation,
HS-SCCH power per DL TS,
number of HS-SCCH channels,
max number of HSDPA users,
HSDPA scheduler algorithm,
HSUPA enabled,
DL HSUPA power,
max number of HSUPA users,
UL load factor due to HSUPA,
number of HSUPA users.
The preceding parameter lists are not exhaustive, but they already show that an UMTS network
configuration in Atoll can be as detailed as in Planner. One minor exception to this is that the cell
parameters of Atoll do not include powers and activities of all individual downlink common control
channels (like in NetAct Planner), but the powers of common control channels are handled by only
three parameters: pilot power, SCH power (of both synchronisation channels, P-SCH and S-SCH)
and other CCH power (of the other common channels P-CCPCH, S-CCPCH, AICH and PICH).
There are no activities for downlink common control channels, and hence control channels are
assumed to be transmitted continuously. As a consequence, the powers defined for the control
channels in Atoll should be the average powers that include effect of the activity cycle - not the
nominal powers that are used during active transmission.
Atoll can take also the CDMA self interference into account in simulation. Each UMTS transmitter
(actually the BTS Equipment of the transmitter) and terminal in Atoll has a rho factor parameter,
which defines the percentage of the received power that can be utilized in signal reception (at the
opposite end of the transmission link). The remaining percentage of power will be considered as
self interference. Modelling CDMA transmission at this detail may be an overkill, but this could
probably be more useful for UMTS terminals (i.e. for uplink), where this self interference can model
the nonlinear distortion products of the terminal's power amplifier.
Only one base station resource can be modelled in Atoll. It is predefined as channel elements, and
it is always pooled at base station (site) level. The limits for channel elements are defined separately for uplink and downlink. The channel element consumption (in simulation) in uplink and
55/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
downlink can be defined for each R99 bearer. However, these settings cannot be found at the
bearer dialogs, but they are hidden under Data | Sites | Equipment | Channel Element Consumption.
In the Equipment of the sites, it is also possible to define the number of overhead uplink and
downlink CEs, which are the numbers of channel elements that are used for common channels in a
cell (not site!). This setting is also used for OVSF code allocation, where it indicates the number of
OVSF codes to be allocated to control channels in each cell.
In Atoll, there is no UMTS base station object, but the combination of the transmitters in a single
site corresponds quite well to definition of a Node B object in NetAct Planner. However, in Atoll
there still can be a template for a "base station", which is defined as a site with one or more
transmitters. The station templates can be used for placing multiple identical stations on a map.
It is possible to define UMTS network configuration in Atoll up to the same precision - or even more
precisely - as in NetAct Planner. The only notable exception is the modelling of only a single
resource, but the basic modelling of channel elements in Atoll should be sufficient for normal
network simulation.
5.2.3
Configuration of Bearers, Services and Terminals
Like in NetAct Planner, also in Atoll simulations are based on globally defined bearers, services and
terminals.
5.2.3.1
Configuration of Bearers
The parameters of a bearer in Atoll include:
-
bearer name
nominal rates (UL/DL)
type (interactive/conversational/background/streaming)
DPCCH/DPCH power ratio (UL/DL)
min and max TCH power
DL spreading factor (for active and inactive users)
As can be noticed on separate definitions for UL and DL, one bearer in Atoll defines a pair of uplink
and downlink channels, while one bearer in Planner defines one-directional channel either for uplink or for downlink.
56/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
The target Eb/Nos and Eb/No diversity gains (i.e. Eb/No requirements) of each bearer can be
defined for three mobility classes: pedestrian, 50 km/h and 90 km/h. The Eb/No parameters in Atoll
are:
-
UL Eb/No target,
DL Eb/No target,
UL 2RX diversity gain,
UL 4RX diversity gain,
DL open-loop diversity gain,
DL closed-loop diversity gain.
The DL closed-loop diversity gain refers to diversity, where UE transmits feedback information back
to the BS, and where phase and relative transmit power of signals of the diversity antennas are
adjusted according to the feedback information. Closed-loop diversity gain is not very commonly
used in UMTS networks.
However, "UL 2RX diversity gain", "UL 4RX diversity gain", "DL open-loop diversity gain" and "DL
closed-loop diversity gain" are really just labels that allow one of two UL diversity types and one of
two DL diversity configurations with separate diversity gains (or no diversity) to be selected in each
transmitter.
The definition of bearers in NetAct Planner contains multiple parameters related to power control
and handover: soft handover gain for DL bearers as well as power control headroom, average
power rise, soft handover gain, gain against average power rise and gain against power control
headroom in a soft handover for UL bearers.
Atoll has only global (not per bearer) parameters for modelling uplink handover. Under Data |
Transmitters | Properties | Global Parameters it is possible to define the default UL macrodiversity
gain, which corresponds to the UL soft handover gain of NetAct Planner. There is only one global
gain parameter, the gain cannot be defined separately for different mobile speeds or ratios between
the received uplink signal powers. There is also a separate checkbox for "+MRC in Softer/Soft",
which models the softer handover between co-site transmitters.
The DL soft handover gain in Atoll is not a user-definable parameter. Instead the DL soft handover
gain is automatically calculated in simulation by taking into account all transmitters of the active set.
Uplink power control headroom and average power rise are not modelled in Atoll. The power
control headroom can be taken into account with a workaround, where the maximum transmit
power of the terminal is reduced, but there is no practical workaround for modelling the average
power rise.
Bearers cannot be defined in Atoll quite as precisely as in NetAct Planner. However, the level of
detail in Atoll should be sufficient for realistic estimation of network performance.
57/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
5.2.3.2
Configuration of Services
The parameters of a service in Atoll include:
-
service name
packet/circuit mode
carrier
activity factor (UL/DL)
packet efficiency (UL/DL)
priority
handover supported
body loss
throughput scale factor
R99 radio bearer
requested average rate (UL/DL)
rate downgrading supported
HSDPA
HSUPA
In Atoll, one service can use only one bearer. It is not possible to define a service that would provide multiple bearers that would be successively tried for connection in simulation (like in NetAct
Planner). However, somewhat similar functionality is provided in Atoll by the rate downgrading. If
the rate downgrading is enabled in a service, and the Eb/No requirements of a R99 bearer are not
fulfilled in simulation, the bearer will be downgraded to a R99 bearer of the same type and a lower
nominal rate.
Each circuit-switched service contains a throughput scaling factor, which can be used for modelling
protocol overheads (framing bits, CRC, etc.). After simulation, it is possible to investigate either
MAC throughput or application level throughput. The application level throughput shall be calculated as the MAC throughput multiplied by the throughput scaling factor.
By default both Atoll and Planner calculate activities of packet services (separately for UL and DL)
from the www model of 3GPP, which is using the parameters
-
average number of packet calls per session,

reading time between two packet calls,
packet inter-arrival time,
packet size,
min and max length of a packet stream;
but it Planner it is possible to disable this computation and define the activity exactly manually. In
Atoll, same result can be achieved only be reverse engineering the desired activity back into
parameters of the www model. In the default www model settings for packet services, both the
average time between two packet calls and average time between two packets are set to 0 ms,
which produces 100% activity.
One minor difference between Planner and Atoll is also that in Atoll the body loss is defined for the
service - not for terminal. This is actually very sensible, since position of the cellular phone - either
on user's ear or (on a table) in front of the user - mainly depends on the used service.
The Atoll services are also somewhat more limited than the Planner services. However, the level of
detail in Atoll should again be adequate for realistic estimation of network performance.
58/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
5.2.3.3
Configuration of Terminals
In Atoll, the following terminal parameters are used in predictions:
-
receiver equipment,
main and secondary bands,
maximum terminal power,
gain and losses,
noise figures,
active set size,
DL rake factor,
rho factor,
compressed mode capability,
HSPA capability and HSPA-specific categories.
Hence, there are no parameters that are related to traffic spreading, speed distribution or services
(like in NetAct Planner). The terminal parameters only characterize the hardware capabilities of the
terminal type.
In NetAct Planner a service (or multiple services) is allocated to each terminal type. In Atoll, terminals are related to services via user profiles. A user profile tries to model behaviour of a typical user
in the network. Each user profile contains rows the define the average number of calls per hour for
a specific service using a specific terminal type. User profiles are then assigned to environment
classes, which are used for defining environment maps (see Section 5.5). After all of these relatively complicated definitions have been carried out, the result is a traffic map containing traffic for
specific services over specific terminals (at specific speed distributions).
The hardware capabilities of terminal types can be specified in Atoll as accurately or even better
than in NetAct Planner. The complications of traffic distribution in Atoll will be discussed in later
sections.
5.3
Import from a NetAct Planner Plan
There is an import module for NetAct Planner plans in Atoll, but it is not a part of the standard Atoll
distribution. It is a separate add-in that is called CPT Import. Forsk has developed it for Cingular to
support import of UMTS networks (from Planner 5.2) and hardwired into the import the NetAct
Planner XML files that must be included into an import:
- ANTENNA-LIST001.xml
- CARRIER-UMTS-LIST001.xml
- FEEDER-LIST001.xml
- MAST-HEAD-AMPLIFIER-LIST001.xml
- MODEL-LIST001.xml
- NODEB-LIST001.xml
- NODEB-TYPE-LIST001.xml
- PROPERTY-LIST001.xml
- UMTS-CELL-LIST001.xml
This list of XML files means that only the network-side configuration (and propagation models) is
imported. Definitions of bearers, services, terminal types or global parameters are not imported
from NetAct Planner. Import of 2G networks is not supported.
59/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Atoll has implemented a hidden undocumented propagation model type Atoll.SPMA.1 that
corresponds to the Aircom's Standard Macrocell Model 3. The dialog of this propagation model has
exactly the same parameters and settings as Aircom's Standard Macrocell Model 3 in NetAct
Planner (including the Through Clutter corrections). During import of NeAct Planner XML files,
propagation models will be also automatically converted. This conversion works correctly for
Aircom's Standard Macrocell Model 3.
As discussed in the Section 3.3.3, a propagation model that is equivalent to an Aircom's Macrocell
3 model can be created also by configuring manually the K coefficients of the Standard Propagation Model of Atoll.
If the Nokia Propagation Model has been used in the Planner project, it will appear in the NetAct
Planner XML files as a Macrocell model, and Atoll will try to import it also. The conversion does not
work correctly for the Nokia Propagation Model, and the coefficients of the imported model will be
useless.
A small artificial network of 8 base stations was successively imported from Planner 5.2 to Atoll
using the CPT Import add-in. No errors in import were noticed, except for the small problem in
powers of downlink common control channels that is discussed below. This network was subsequently used in various tests of this section.
The Planner XML files are backward compatible in such way that Planner 5.2 XML files can be
imported into Planner 6.0. However, it was not tested whether the CPT Import add-in of Atoll can
successfully read Planner 6.0 XML files. Depending on the Atoll implementation, there could be
some complications with the Planner 6.0 XML files.
Importing of the powers of downlink common control channels of cells is complicated by the fact
that the cell parameters in Planner and Atoll are different. The Cell Parameters of Planner include
the nominal powers and activities of all common control channels P-CCPCH, S-CCPCH, P-SCH,
S-SCH, AICH and PICH. For example
Pilot power [dBm]
Max Tx power [dBm]
P-CCPCH power offset [dB]
P-CCPCH activity
S-CCPCH power offset [dB]
S-CCPCH activity
P-SCH power offset [dB]
P-SCH activity
S-SCH power offset [dB]
S-SCH activity
AICH power offset [dB]
AICH activity
PICH power offset [dB]
PICH activity
33
43
-5
0.9
0
0.25
-3
0.1
-3
0.1
-8
0.8
-8
0.96
During import of XML files these parameters should be converted into effective powers of common
control channels in Atoll. For the above table the result should be
Max Power [dBm]
Pilot Power [dBm]
SCH Power [dBm]
43
33
33+10*log(0.1*10-3/10+0.1*10-3/10) = 23.0
60/121
Report
Tools Management &
Support
Other CCH Power [dBm]

18.6.2008, ver. 1.0
For internal use
33+10*log(0.9*10-5/10+0.25*10-0/10+0.8*10-8/10+0.96*10-8/10) = 32.1
However, even though the Max Power, Pilot Power and SCH Power were correctly imported, the
Other CCH Power was incorrectly calculated to contain only the powers of AICH and PICH as
33+10*log(0.8*10-8/10+0.96*10-8/10) = 27.5 dBm.
Atoll stores internally object data (sites, transmitters, repeaters, antennas, UMTS Cells, UMTS
parameters, etc.) into tables. Data of these tables can be exported an imported in proprietaryformat XML files. These files should not be confused to the NetAct Planner XML files. The format of
the Atoll XML files depends on the version of Atoll, and data can be correctly imported from these
XML files only if they have been created under the same Atoll version.
5.4
Pilot Coverage Planning
Results of calculation of received signal levels in Atoll, which corresponds to calculation of UMTS
Pilot Coverage in Planner, have been already shown in Section 3.3.3. Either Coverage by signal
level or Coverage by transmitter (i.e. dominance areas) can be plotted in Atoll. The coverage
results are independent of traffic and they do not require Monte Carlo simulations. The received
signal levels in Atoll do not contain terminal parameters, while the UMTS pilot coverage array in
Planner includes the terminal antenna gain and body loss.
In NetAct Planner, the pilot coverage can be calculated without defining traffic or running simulation, but the actual simulation arrays are linked to Monte Carlo simulations. A simulation array can
be calculated and displayed only after a simulation has been run.
In Atoll, the selection of displayable arrays is independent of simulations. Any of the Atoll arrays (or
prediction studies as they are called in Atoll) that depends on cell loading can be plotted on basis of
simulation (either one simulation snapshot or a complete simulation containing multiple snapshots)
or on basis of static load assumptions of cells. The only information that is used for arrays is the
uplink cell loads and the downlink transmit powers for each cell of the network. The selection of a
simulation snapshot or a complete simulation as the condition for the array simply means that the
cell loads and downlink transmit powers are extracted from simulation. Hence, the same selection
of arrays is always available irrespective of the simulations.
The exact values that can be updated in each cell from simulation are:
- total transmitted power,
- UL load factor,
- UL reuse factor,
- available HSDPA power,
- number of HSDPA users,
- UL load factor due to HSUPA,
- number of HSUPA users.
These values can naturally also be edited manually in the cells. Since only cell loading type of
results are taken from simulation, the selection of Atoll arrays does not include blocking probability
type of arrays. For the same reason, shadowing is modelled separately in simulation and in computation of arrays (see Section 5.2.1). When a new array is created, there is a checkbox for including or excluding the shadowing margin.
61/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
An Atoll array (a prediction study) is created by placing a "probe mobile" on each pixel of the analyzed area. The probe mobile characteristics (terminal type, mobility type, service type and carrier
frequency) affect the prediction study results. The power control algorithm is then performed for the
probe mobile in order to calculate the uplink power and active set. The probe mobile is not contributing to interference in the network.
The standard prediction studies of Atoll are:
-
Coverage by Transmitter
Coverage by Signal Level
Overlapping Zones
Downlink Total Noise
Pilot Reception Analysis (Ec/Io)
Service Area (Eb/Nt) Downlink
Service Area (Eb/Nt) Uplink
Effective Service Area
Handoff Status
Pilot Pollution
HSDPA Coverage
HSUPA Coverage
Scrambling Code Interference Zones
Each of these studies contain selection of several different quantities for display. For example, the
Downlink Total Noise array can show minimum, maximum or average noise level or minimum,
maximum or average noise rise. As a consequence, the visualization capabilities of Atoll can more
or less match the long list of simulation arrays in Planner. It should also be possible to define new
predictions as XML templates, but this feature has not been tested.
One of the arrays that can be displayed is Handover Status. In it Atoll divides 2-link handovers in
the normal way into soft and softer handovers, but Atoll also recognizes separately the 3-link handovers as softer-softer, softer-soft or soft-soft handovers. In a softer-softer handover all 3 cells of the
active set belong to the same Node B; in a softer-soft handover 2 cells belong to the same Node B
and the 3rd cell belongs to another Node B; and in a soft-soft handover all 3 cells belong to different Node Bs.
Resolution of a prediction study can be selected freely. It does not have be equal or multiple of the
resolution of the path loss matrices. Atoll shall utilize both height and clutter information of the
digital map for prediction studies for any chosen resolution.
62/121
Report
Tools Management &
Support
5.5

18.6.2008, ver. 1.0
For internal use
UMTS Traffic Modelling
In Atoll, it is not possible to use the clutter layer of the digital map directly for distributing traffic. It is
possible to achieve the same result, but this is very complicated process that requires multiple
steps. The first step is to import the clutter layer of the digital map again into a separate Environment map (from Geo | Traffic | New Map | Map based on Environments (Raster) | Import a File by
selecting the index.txt file in the clutter directory of the digital map). The clutter types of the map
then become Environments in the Environment map.
To get a real traffic layer for simulation, it is necessary to first create (at least one) User Profile that
defines the average number of calls per hour (per user) for a service using a specific terminal type.
Then, it is necessary to create a new Environment class for each clutter type of the map (under
Data | UMTS Parameters | Environments, with exactly the same name as the clutter type). The
traffic density (number of subscribers per km) for each terminal speed class (mobility type) and the
percentage of indoor subscribers must then be defined separately for each Environment class. The
Environment class use the defined user profile(s).
This process should create a traffic distribution that is based on the clutter layer of the digital map,
but the final result cannot be plotted for visual investigation. No traffic based on clutter types has
been used in the tests of this section.
On the other hand, in Atoll it is relatively easy to create a Cell Traffic Map, where a desired number
of terminals is assigned to each transmitter (i.e. to a sector), separately for UL and DL from Geo |
Traffic | New Map | Map based on Transmitters and Services (# Active Users). Number of users for
each service on UL and DL for each transmitter can be simply written into a table. The table
containing numbers of terminals can also be imported in a comma or tab separated text file.
Simulation of traffic depends on activities of services, but the method for using activities in Atoll is
quite different from the one in Planner. In Atoll, users are divided into four activity status classes inactive, active on UL, active on DL or active on UL and DL - according to the activity factor of the
service. For example, if voice service has the activity factor 0.5 (in both UL and DL), 25% of users
will be assigned into each of the four activity status classes. This means that no more than 25% of
users can ever be connected both on UL and DL, even if the coverage and capacity of the network
would allow more users to be connected. This means also that when 20 users are defined for uplink and 20 users are defined for downlink, the total number of users is not 20, but 40.
The user-defined activities are available for circuit-switched services. All users of packet-switched
services on a traffic map (based on number of active users) are considered as active in simulation.
This methodology is totally different than the method for using activities in Planner, where as many
users are connected as possible (within loading and power limitations), but power of every connected user is weighted by the activity factor of the service. The methodology of Planner models
more accurately the full-duplex connections of circuit-switched services in real networks, and it
provides results that are more intuitive to interpret.
In NetAct Planner services are allocated to specific carriers, and each cell is operating on a specific
carrier. This enables, for example, allocation of HSDPA traffic to one carrier and R99 traffic to another carrier in a network. In Atoll, services or terminals are not associated with carriers, and it is
not possible to assign a specific service to desired carriers only.
63/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Atoll transmitters are associated with one frequency band each, and Atoll terminals are associated
with one or two frequency bands. The concept of frequency band can thus be used for modelling
dual-band terminals in a multiband UMTS network, but it cannot be used for modelling of division of
traffic to different carriers, since one transmitters can only operate on one frequency band.
The complexity of creation of traffic maps and limitations in their visualization are major drawbacks
of Atoll. Every Monte Carlo simulation requires a traffic map, and easy creation of traffic maps is
one of the fundamental requirements for a planning tool. NetAct Planner is by no means perfect in
handling of traffic maps, but Atoll is still far behind NetAct Planner in this area.
5.6
Monte Carlo Simulation
As discussed in Section 5.4, the selection of displayable arrays in Atoll is independent of simulations. However, in Atoll it is possible to visualize the results of simulations themselves. The
locations of terminals of each class can be separately displayed on the map. The following figure
shows an example of the "Ec/Io < (Ec/Io)min" terminals (the reddish circles) that are shown on top
of the Pilot Ec/Io array.
Figure 17. Locations of the "Ec/Io < (Ec/Io)min" terminals displayed over the pilot Ec/Io array.
64/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
In this case, the Ec/Io threshold was -14 dB for all mobility types, and the shadowing margin in
simulation was slightly below 5 dB. Hence, all terminals having Ec/Io about -10 dB or less have
been rejected in simulation. The visualization of simulated terminals from each individual simulation
snapshot makes it possible to investigate in great detail, what has actually happened in individual
simulation snapshots.
The simulated terminals are classified in each simulation snapshot into different classes:
-
Connect DL+UL
Connect UL
Connect DL
Inactive
Pmob > PmobMax
Ptch > PtchMax
Admission rejection
UL Load Saturation
Ch. Elts saturation
DL Load Saturation
Multiple causes
Code saturation
Ec/Io < (Ec/Io)min
HSDPA Delayed
HSDPA Scheduler Saturation
The connection failure classes do not include any labels related to Eb/No requirements, but the low
power cases "Pmob > PmobMax" and "Ptch > PtchMax" obviously represent insufficient Eb/No.
In Atoll, Monte Carlo simulation models also internally the OVSF code tree and consumption of
codes by connections. Hence, connection to a terminal may fail also due to lack of codes.
5.6.1
Sufficient Number of Simulation Snapshots
The sufficient number of simulation snapshots was investigated by running six independent
simulation runs: two simulations with 5 simulation snapshots, two simulations with 20 snapshots
and two simulations with 50 snapshots. Except for the number of snapshots, the simulation
conditions were unchanged. The simulations were run for mixed voice and HSDPA traffic.
The following tables show average cell-by-cell simulation results for number of voice users, UL load
factor and HSDPA rate as well as root-mean-square differences between runs having the same
number of snapshots.
65/121
Report

18.6.2008, ver. 1.0
For internal use
Tools Management &

Support
No. of snapshots
Simulation run
Node0-1
Node0-2
Node0-3
Node1-1
Node1-2
Node1-3
Node2-1
Node2-2
Node2-3
Node3-1
Node3-2
Node3-3
Node4-1
Node4-2
Node4-3
Node5-1
Node5-2
Node5-3
Node6-2
Node6-3
Node6-1
Node7-3
Node7-1
Node7-2
rms difference
5
A
8
7.2
15.2
28.4
17.6
26.6
12
8.2
22.8
22.4
16.4
13.4
26.4
9.4
10.8
13.2
21
18.4
20
6.8
5.2
3.8
13.6
4.2
20
B
8.2
7.6
12.2
28.4
18.2
23.4
8.4
9.8
24
26.4
16.6
11.2
28.2
7.2
13
14
25
18.4
23.2
6.4
4.6
2.4
11.4
5
2.1
A
8.9
8.25
15.7
29.05
18
22.65
9.9
8.6
25.05
23.6
16.05
11.35
28.1
8.15
13.95
15.3
23.95
17.6
24.4
5.2
5.45
3.95
12.4
6.1
50
B
6.67
8.67
13.67
28.67
20.67
24.33
12.67
8.33
19
20.33
18.33
13
23.67
9.67
13.67
14.33
23.33
20.33
18.67
5.67
7.33
3.33
10.33
5.33
2.5
Table 2. Average numbers of voice users in different simulation runs.
A
8.6
7.74
14.66
27.68
17.88
23.54
10.18
9.6
24.6
23.1
17.5
11.52
26.82
8.7
12.98
14.6
23.88
17.9
23.34
5.98
4.68
3.26
11.62
5.6
B
8.68
7.24
14.24
28.68
17.9
24.68
9.36
8.74
23.96
24.66
18.12
11.32
27.3
8.16
12.4
15.38
24.48
18.28
23.38
6.16
5.34
3.16
11.76
5.9
0.6
66/121
Report

18.6.2008, ver. 1.0
For internal use
Tools Management &

Support
No. of snapshots
Simulation run
Node0-1
Node0-2
Node0-3
Node1-1
Node1-2
Node1-3
Node2-1
Node2-2
Node2-3
Node3-1
Node3-2
Node3-3
Node4-1
Node4-2
Node4-3
Node5-1
Node5-2
Node5-3
Node6-2
Node6-3
Node6-1
Node7-3
Node7-1
Node7-2
rms difference
5
A
14.45
20.63
36.66
41.3
26.27
44.46
19.85
14.18
36.98
35
28.19
19.12
38.59
14.47
17.95
19.93
34.87
23.34
31.21
10.31
10.31
5.82
20.42
7.9
20
B
12.54
17.91
27.69
36.72
27.95
36.27
12.79
13.87
35.86
42.96
23.83
18.16
41.65
12.88
21.5
18.79
31.96
25.39
27.41
9.19
6.14
3.23
13.71
7.3
4.3
A
13.18
21.73
33.41
40.81
29.54
33.05
15.78
14.67
38.66
32.04
25.66
18.3
41.29
13.79
23.23
21.38
38.35
25.88
33.55
9.29
8.59
5.77
18.27
9.7
50
B
10.64
28.43
32.34
39.97
32.87
31.66
19.63
20.31
33.57
24.53
24.51
16.34
46.66
18.27
22.07
20.58
35.03
34.1
21.33
9.5
9.05
5.95
15.85
9.71
4.5
Table 3. Average UL load factors (in %) in different simulation runs.
A
12.58
22.1
33.29
39.03
30.29
36.2
16.02
15.51
38.62
29.17
25.91
17.78
38.75
14.68
21.12
20.25
36.27
25.13
31.16
10.56
8.87
5.39
17.76
9.8
B
12.8
20.6
33
39.96
31.44
35.75
14.06
14.59
36.45
31.12
27.02
17.73
39.07
13.96
22.25
21.92
36.66
27.46
30.55
9.53
9.52
5.08
17.6
9.21
1.2
67/121
Report

18.6.2008, ver. 1.0
For internal use
Tools Management &

Support
No. of snapshots
Simulation run
Node0-1
Node0-2
Node0-3
Node1-1
Node1-2
Node1-3
Node2-1
Node2-2
Node2-3
Node3-1
Node3-2
Node3-3
Node4-1
Node4-2
Node4-3
Node5-1
Node5-2
Node5-3
Node6-2
Node6-3
Node6-1
Node7-3
Node7-1
Node7-2
rms difference
5
A
640
448
1120
1664
1152
1376
512
864
1696
576
992
1632
1344
928
1088
1344
1152
512
1024
896
1216
928
1248
0
20
B
1344
768
1184
1280
960
928
928
896
1376
928
1056
1184
1216
512
1440
960
1280
928
960
1088
1088
800
1024
608
337.6
A
1208
632
1368
1360
1160
1064
1224
736
1432
840
1032
1208
1400
720
760
1088
1304
1120
1368
360
776
824
1408
736
50
B
1013.33
533.33
1386.67
1653.33
1386.67
1066.67
1280
533.33
1653.33
0
533.33
1173.33
1226.67
1333.33
373.33
1173.33
1440
1280
640
800
533.33
0
1280
906.67
373.5
A
1075.2
470.4
1187.2
1264
1254.4
1273.6
1136
787.2
1510.4
537.6
1033.6
1084.8
1155.2
720
988.8
1126.4
1433.6
1040
1280
566.4
380.8
579.2
1193.6
748.8
B
1158.4
678.4
1004.8
1238.4
1193.6
966.4
1225.6
825.6
1465.6
547.2
1011.2
1033.6
1232
694.4
934.4
1113.6
1395.2
1049.6
1235.2
620.8
960
393.6
1260.8
921.6
160.4
Table 4. Average HSDPA rates (in kbit/s) in different simulation runs.
This simple comparison is a not a proper statistical analysis of the convergence of the simulation,
but anyhow it shows that using less that 50 simulation snapshots in Atoll can result in large variation of simulation results. For the HSDPA rate, variation of simulation results seems to be quite
large even for 50 simulation snapshots.
This result differs significantly from the Forsk recommendations, according to which 5-10 simulation
snapshots should be sufficient for low traffic simulations, while 20 snapshots should almost always
be enough. Earlier experiments and communication from Aircom indicate that about 20 simulation
snapshots are normally sufficient in NetAct Planner simulations.
5.6.2
Defining "Equivalent" Simulations in Planner and Atoll
68/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Defining equivalent simulation conditions for Planner and Atoll is a very complex task. One should
define equivalent parameters for all bearers, services, terminals, base stations, cells, etc. In many
cases (e.g. for the Eb/No requirements) this does not mean equal parameter values, but an appropriate conversion between the numerical values. One should also be able to define exactly equal
traffic over exactly equal area in both software.
Since the method for using activities in Atoll is quite different from the one in Planner (see the
section 5.5), even approximately equivalent simulations are only possible when 100% activities are
used for all simulated services.
A simulation of voice service on the small artificial network of 8 base stations was tried as an
example. The traffic array was created by assigning 20 users for each cell in the coverage area
(without any clutter weighting). However, the actual simulation area was slightly smaller than the
combined coverage area of cells, so that only about 300 of the 480 users were included in the
simulation area. The following figures and simulation reports show the results of simulations in Atoll
and Planner.
Figure 18. Pilot Ec/Io array from Planner simulation.
69/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 19. Pilot Ec/Io array from Atoll simulation and the connected terminals.
The pilot coverage is clearly better in Planner than in Atoll, which indicates that the interference
levels have been higher in the Atoll simulation. There is no obvious reason for the lower pilot Ec/Io
level in Atoll. The propagation models and pilot powers were equivalent in the two software.
The averaged Planner simulation results from simulation reports are:
- Mean Attempted
- Mean Served
- Mean Failed
- Mean In Soft or Softer Handover
- Mean In Softer Handover
298.7
233.1 (78.03%)
65.6 (21.97%)
87.9 (37.71%)
19.8 (8.49%)
Contributions to Failure:
- No UL RAS_CE Primary Channel
- No DL RAS_CE Primary Channel
- UL RAS_CE Channel Limit Reached
- DL RAS_CE Channel Limit Reached
- No UL HSDPA_codes Primary Channel
- No DL HSDPA_codes Primary Channel
- UL HSDPA_codes Channel Limit Reached
- DL HSDPA_codes Channel Limit Reached
- Low Pilot
- Downlink Eb/No (Range)
0.00%
0.00%
0.00%
0.00%
0.00%
0.00%
0.00%
0.00%
66.30%
18.63%
70/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
- Downlink Eb/No (Capacity)

- Uplink Eb/No
- Noise Rise
- No Carrier
- Excessive Pathloss
0.00%
99.58%
0.00%
0.00%
0.00%
Cell
No. of served
users
UL Load [%]
Total DL Tx
Power [dBm]
Node0A
Node0B
Node0C
Node1A
Node1B
Node1C
Node2A
Node2B
Node2C
Node3A
Node3B
Node3C
Node4A
Node4B
Node4C
Node5A
Node5B
Node5C
Node6A
Node6B
Node6C
Node7A
Node7B
Node7C
Average
8.0
14.0
10.9
11.2
12.4
11.2
6.9
8.4
11.1
11.8
10.0
9.2
11.6
7.2
8.6
9.2
11.8
9.9
4.9
11.9
9.1
10.1
6.8
6.7
9.7
9.6
20.6
20.5
14.2
17.1
16.5
10.0
11.0
15.6
15.2
14.2
11.0
15.0
9.9
12.0
10.9
17.2
13.7
6.8
14.2
10.6
11.7
8.5
7.5
13.1
36.8
37.7
37.0
36.6
37.0
36.8
36.7
36.8
36.6
36.8
36.9
36.9
36.6
36.9
36.9
36.8
36.6
37.1
36.6
36.9
36.7
36.8
36.7
36.6
36.8
Frequency
Reuse
Efficiency [%]
67.9
52.2
41.0
63.9
58.9
53.8
56.5
61.4
58.6
61.2
56.4
67.5
62.3
58.0
58.1
70.6
55.8
58.5
58.0
68.4
70.2
69.4
66.2
76.0
61.3
Terminals in
handover [%]
20.8
55.2
68.0
31.2
36.6
45.3
63.7
43.4
43.5
38.5
44.4
21.8
34.1
51.5
44.5
23.0
31.6
41.3
39.8
25.1
33.5
28.2
34.1
19.0
38.3
71/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
The averaged Atoll simulation results from the summary of an average simulation are:
Total number of users trying to connect:
294.3 (standard deviation 18.64)
Active Downlink + Uplink:
294.3
Total number of users not connected: 64.95 (22.1%)
- Pmob > PmobMax:
0
- Ptch > PtchMax:
0
- Ec/Io < (Ec/Io)min:
64.95
- UL Load Saturation:
0
- Ch. Elts saturation:
0
- DL Load Saturation:
0
- Multiple causes:
0
- Code saturation:
0
- Admission rejection:
0
- HSDPA Delayed:
0
- HSDPA Scheduler Saturation:
0
- HSUPA Scheduler Saturation:
0
Transmitter
Number of
Radio Links
UL Load Factor
[%]
Node0-1
Node0-2
Node0-3
Node1-1
Node1-2
Node1-3
Node2-1
Node2-2
Node2-3
Node3-1
Node3-2
Node3-3
Node4-1
Node4-2
Node4-3
Node5-1
Node5-2
Node5-3
Node6-2
Node6-3
Node6-1
Node7-3
Node7-1
Node7-2
Average
7.3
9.5
15.3
23.9
13.9
24.0
7.7
8.1
19.9
24.9
15.6
10.9
22.7
8.1
10.2
11.2
19.4
15.7
19.9
4.6
5.7
2.6
8.5
4.5
13.1
6.5
10.0
17.3
21.0
14.1
21.7
6.9
6.9
17.7
21.7
13.6
9.0
19.7
7.1
9.7
9.8
19.4
15.0
17.1
4.1
4.8
2.2
7.8
4.2
12.0
Total
Transmitted
Power [dBm]
37.1
37.1
37.4
37.6
37.0
37.9
36.9
36.9
37.3
38.3
37.6
37.7
37.4
37.2
37.4
37.7
37.5
38.2
38.5
36.6
37.2
36.4
37.2
36.7
37.4
UL Reuse
Efficiency
Factor
82
57
59
88
77
82
89
88
85
88
85
83
90
82
79
88
79
82
90
79
77
77
83
73
81
% Handoff
34.1
88.8
67.3
41.0
49.8
58.1
58.8
56.5
50.2
52.6
46.3
51.5
45.3
57.2
46.8
30.5
43.0
43.3
34.5
53.8
47.3
40.9
46.2
50.0
49.7
72/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
The number of rejected terminals is over 20% both in Planner and Atoll, but this happens only
because the simulated area is clearly larger than the coverage area of the cells. Such a high
rejection percentage could naturally not be accepted in any real network, but this is an artificial
network with only few sites, which are quite far from each other, and which cannot properly cover
the whole simulation area. However, the total number of attempted calls and the total number of
served calls are very close to each other in Planner and Atoll.
The lack of coverage is reported quite differently in Planner and Atoll. In Atoll, the missing coverage
is reported as too low Ec/Io for all rejected terminals; while in Planner the missing coverage is
reported as low Ec/Io or as too low uplink or downlink Eb/No. It is not clear, why Atoll seems to
encounter only Ec/Io criterion, while Planner is rejecting some terminals only for Eb/No criterion.
The Eb/No requirements were matched to each other in the two software.
The average cell loading is quite low, and none of the cells is close to it's loading limit. The average
cell loadings are close to each other in Atoll and Planner, but loadings of individual cells vary a lot.
The differences between loadings of individual cells are also clearly visible in the two pilot Ec/Io
arrays.
The variations in downlink power between cells are very small in both Planner and Atoll. The
reason for this is that for small numbers of users in all cells the downlink power is dominated by the
power of common control channels, which is almost 36 dBm.
The percentage of handover terminals is clearly larger in Atoll than in Planner. The parameters
related to handover in the two software were not matched exactly, which may explain - at least
partly - the differences in results. The reuse efficiencies are also larger in Atoll than in Planner.
Simulation is obviously a randomised process, and individual simulation runs shall always give
slightly different results. However, the differences between simulation runs in one planning tool are
relatively small (when the number of simulation snapshots is large enough), and they are clearly
smaller than the differences between simulation results in Planner and Atoll.
5.7
HSDPA
The modelling of HSDPA in NetAct Planner is based on defining a separate bearer for each HSDPA
transport format. In simulation, connections on these terminals will be tried one after another until a
connection can be made. This is very flexible methodology, but it is also quite slow when the
number of HSDPA bearers is large. In Atoll, the simulation of HSDPA connections differs quite a lot
from simulation of normal R99 UMTS connections.
73/121
Report
Tools Management &
Support
5.7.1

18.6.2008, ver. 1.0
For internal use
HSDPA Transport Formats
In Atoll, the HSDPA bearers are not defined in the same way as normal UMTS bearers, but they
have a separate dialog under Data | UMTS Parameters | Services | HSDPA Radio Bearers. The
default HSDPA bearer configuration uses exactly the same 30 transport formats (of 3GPP 25.214)
that are currently recommended for NetAct Planner.
Radio Bearer
Index
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Transport Block
Size [bit]
137
173
233
317
377
461
650
792
931
1262
1483
1742
2279
2583
3319
3565
4189
4664
5287
5887
6554
7168
9719
11418
14411
17237
21754
23370
24222
25558
Number of Used HSPDSCH Channels

1
1
1
1
1
1
2
2
2
3
3
3
4
4
5
5
5
5
5
5
5
5
7
8
10
12
15
15
15
15
Modulation
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
QPSK
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
16-QAM
RLC Peak Rate

[bit/s]
0
0
0
0
160000
160000
160000
320000
320000
480000
640000
800000
960000
1120000
1440000
1600000
1920000
2080000
2400000
2880000
3040000
3360000
4480000
5280000
6720000
8320000
10240000
11040000
11520000
12160000
74/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Atoll utilizes internally both MAC rates and the RLC peak rates of the HSDPA bearers. The MAC
rates are determined by the transport block sizes, and they correspond to the user data rates that
have been used in NetAct Planner. The default RLC peak rates are about 5% lower, and they have
been truncated to multiples of 160 kbit/s. The RLC peak rates of the four bearers with smallest
transport block sizes have been approximated as exactly zero.
The HSDPA Radio Bearers dialog does not contain Eb/No requirements of HSDPA bearers. The
HSDPA Eb/No requirements - actually Ec/No requirements - are hidden into separate lookup tables
under Data | UMTS Parameters | Terminals | Reception Equipment. There are two lookup tables:
mapping from pilot Ec/No to CQI and from HS-PDSCH CQI to HSDPA bearer. It is possible to
define separately the Ec/No requirements (lookup tables) for pedestrian users and for speeds 50
km/h and 90 km/h. However, the default settings are the same for all three speeds.
HS-PDSCH Ec/No [dB]

-17.5
-16.5
-15.5
-14.5
-13.5
-12.5
-11.5
-10.5
-9.5
-8.5
-7.5
-6.5
-5.5
-4.5
-3.5
-2.5
-1.5
-0.5
CQI
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
HS-PDSCH Ec/No [dB]

-0.5
0.5
1.5
2.5
3.5
4.5
5.5
6.5
7.5
8.5
9.5
10.5
11.5
12.5
13.5
14.5
15.5
CQI
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
31
Table 5. The default CQI mapping for HSDPA.
This default CQI mapping means that Ec/No values in the range -17.5 ... -16.5 dB are mapped to
CQI 0, Ec/No range -16.5 ... -15.5 dB is mapped to CQI 1, and so on until Ec/No range 14.5 ... 15.5
dB that are mapped to CQI 31. The default mapping simply steps in 1 dB intervals through the
Ec/No -17.5 ... 15.5 dB.
75/121
Report
Tools Management &
Support
HS-PDSCH CQI
1
5
8
10
11
12
13
14
15
16
17
18

18.6.2008, ver. 1.0
For internal use
Best HSDPA Radio Bearer

1
5
8
10
11
12
13
14
15
16
17
18
HS-PDSCH CQI
19
20
21
22
23
24
25
26
27
28
29
30
Best HSDPA Radio Bearer

19
20
21
22
23
24
25
26
27
28
29
30
Table 6. The default best bearer mapping for HSDPA.
This default mapping means that for CQI 10 and above CQI number is equal to the number of
HSDPA bearer. CQI numbers 2-5 are all mapped to the HSDPA bearer 5, CQI numbers 6-8 are all
mapped to the HSDPA bearer 8, and CQI numbers 9-10 are mapped to the HSDPA bearer 10.
Use of lookup tables for selection of HSDPA transport format should be clearly faster in Monte
Carlo simulation than the use of real bearer connection trials in NetAct Planner, but the simulation
times in large networks have not been tested during this evaluation.
In NetAct Planner, the performance requirements for HSDPA bearers are defined as Eb/No
requirements at user data rate, and they cannot be directly compared to the Ec/No requirements of
Atoll. However, if the performance requirements are compared as SINR requirements, the default
requirements in Atoll for transport formats of QPSK modulation are about 3.5-4.5 dB lower than the
recommended NSN values in NetAct Planner. For transport formats of 16-QAM modulation, the
SINR requirements are about 8-10 dB lower in Atoll.
All HSDPA transport formats will be automatically used in all cells that are supporting HSDPA.
There is no selection for HSDPA transport formats in Atoll transmitters or cells, and it is not possible
to define different support for different base stations. All HSDPA transport formats will also be
automatically used in the HSDPA service, they cannot be explicitly selected in the service. On the
other hand, user must select an appropriate associated R99 DPCH (A-DPCH) radio bearer for the
HSDPA service. In simulation, power control for the A-DPCH is first carried our on UL and DL, link
adaptation on DL is then carried out to select a HSDPA radio bearer.
Atoll models HSDPA connections in very detailed manner considering separately the A-DPCH, HSPDSCH and HS-SCCH channels. Connection to a HSDPA terminal can be made in simulation only
if the conditions
-
sufficient HS-SCCH power,

enough OVSF codes for a HSDPA bearer (HS-PDSCH),
sufficient power for a HSDPA bearer (HS-PDSCH)
are all met simultaneously. Atoll is modelling many aspects of HSDPA more accurately than NetAct
Planner.
76/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
In simulation, a HSDPA terminal can become connected or rejected, but it can also get the status
delayed, which means that it is only connected to an R99 bearer but not to a HSDPA bearer. The
delayed terminals are consuming code and power resources in cells, even though they do not have
real HSDPA connection. In simulation reports, the non-connected users include both delayed and
rejected users
Since the HSDPA transport have been implemented by lookup tables, it is not possible to assign
activities to individual HSDPA bearers. Hence, it is not possible to model constant application data
rate over a HSDPA connection by defining decreasing activities for increasing HSDPA data rate, as
in Planner.
5.7.2
HSDPA Terminals
Atoll uses HSDPA UE categories that correspond exactly to the 12 HSDPA UE categories of 3GPP.
The HSDPA UE categories are defined under Data | UMTS Parameters | Terminals | HSDPA User
Equipment Categories.
Category
1
2
3
4
5
6
7
8
9
10
11
12
Max no. of HSPDSCH channels

5
5
5
5
5
5
10
10
15
15
5
5
Min no. of TTIs

betw. 2 used TTIs
3
3
2
2
1
1
1
1
1
1
2
1
Max transport
block size [bit]
7298
7298
7298
7298
7298
7298
14411
14411
20251
27952
3630
3630
Modulation
QPSK only
QPSK only
The restrictions in maximum number of HS-PDSCH channels, maximum transport block size and
modulation effectively disable some of the defined HSDPA transport formats from many terminal
categories. The min number of TTIs between two used TTIs shall affect the bit rates that can be
achieved in simulation.
The tests in the HSDPA section have been run for HSDPA UE of category 10, which supports all
possible HSDPA transport formats at maximal rates.
5.7.3
HSDPA Support in Transmitters and Cells
There are many cell-level HSDPA parameters in Atoll:
77/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
HSDPA enabled
HSDPA Dynamic Power Allocation
Available HSDPA Power
Power Headroom
HS-SCCH Dynamic Power Allocation
HS-SCCH Power
Number of HS-SCCH Channels
Min. Number of HS-PDSCH Codes
Max Number of HS-PDSCH Codes
Max Number of HSDPA Users
HSDPA Scheduler Algorithm
If the "HS-SCCH Dynamic Power Allocation" checkbox has not been checked, static HSDPA power
allocation is modelled, and the "Available HSDPA Power" parameter defines the power (for the HSPDSCH and HS-SCCH) of HSDPA users. When the "HS-SCCH Dynamic Power Allocation" check
box has been checked, Atoll allocates the remaining power in the cell (which has not been already
allocated to R99 users and which is below cell loading limit) to HSDPA users.
This is quite different from the dynamic HSDPA power allocation support of NetAct Planner, where
HSDPA users never use higher power than the HSDPA Link power (which is a cell parameter), but
they may use the remaining available power on the cell, when it is lower than the HSDPA Link
power.
The large number of cell-level HSDPA parameters enables more accurate modelling than what is
possible in NetAct Planner.
5.7.4
HSDPA Scheduling
In Atoll, the HSDPA Scheduler Algorithm can be selected in each cell as:
-
Max C/I (descending order by CQI),

Round Robin (random order), or
Proportional Fair.
78/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
The modelling of Round Robin scheduling as random selection of terminals and Max C/I as sorting
terminals according to Ec/Io in Atoll correspond to the modelling of the two scheduling algorithms in
NetAct Planner.
However, Atoll provides also a third option: Proportional Fair scheduling. Accurate behaviour of
Proportional Fair scheduling cannot be exactly modelled in a memoryless static simulator, it would
only be possible in a dynamic simulator. In Atoll, Proportional Fair scheduling is modelled approximately as a (50%/50%) mix of the ranking of Max C/I and Round Robin rankings. This approximation works correctly in a sense that it will provide throughput that is between the throughputs of Max
C/I and Round Robin scheduling, but it is not clear how close the results will be to the throughputs
of real proportional fair scheduling. The weighting in the mix of the ranking of Max C/I and Round
Robin rankings can be changed in Atoll configuration files.
In Atoll HSDPA scheduling is always assumed to happen at cell level. It is not possible to model a
shared scheduler at a base station.
5.7.5
HSDPA Prediction Studies
The predefined HSDPA prediction studies (arrays) are:

-
Max DL A-DPCH Eb/Nt (dB)

Max UL A-DPCH Eb/Nt (dB)
HS-SCCH Power (dBm)
HS-SCCH Ec/Nt (dB)
HS-PDSCH Ec/Nt (dB)
CQI
MAC Rate (kbps)
MAC Throughput (kbps)
MAC Throughput per Mobile (kbps)
RLC Peak Rate (kbps)
RLC Peak Throughput (kbps)
RLC Throughput per Mobile (kbps)
Average RLC Throughput (kbps)
Application Throughput (kbps)
Application Throughput per Mobile (kbps)
79/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
The following figure shows, as an example, the achievable HSDPA MAC rate from Atoll for the test
network.
Figure 20. Achievable HSDPA MAC rate array from Atoll.
The maximum achievable HSDPA MAC rate in this network is over 3.5 Mbit/s. In Planner, simulation of the same network gives the maximum achievable bit rate as only about 500 kbit/s. This
difference results primarily from Eb/No requirements, which are (too) low in Planner and quite high
in Atoll.
In most aspects the HSDPA modelling in Atoll is more detailed than in NetAct Planner, which
should also result in more accurate performance estimation. The only important exception is the
global nature of HSDPA transport formats in Atoll. In NetAct Planner, it is possible exactly control,
which HSDPA transport formats are selected for services, terminals and cells. Such control is not
possible in Atoll.
80/121
Report
Tools Management &
Support
5.8

18.6.2008, ver. 1.0
For internal use
HSUPA
Modelling of HSUPA in Atoll resembles in many aspects the modelling of HSDPA. It is also
assumed in Atoll that HSUPA is only used in uplink in such connections where also HSDPA is used
in downlink, which is a very reasonable assumption.
Like HSDPA transport formats, also HSDPA transport formats are not defined as normal bearers,
but they have a separate dialog under Data | UMTS Parameters | Services | HSUPA Radio
Bearers. The default HSUPA transport format configuration is
Radio bearer
index
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
TTI duration
[ms]
10
10
10
10
10
10
10
10
10
10
10
10
2
2
2
2
2
2
2
2
2
2
2
2
Transport
block size [bit]
320
640
1280
1920
2560
5120
7680
10240
12800
15360
17920
20480
128
256
512
768
1024
2048
3072
4096
5120
6144
7168
8192
No. of EDPDCH codes

1
1
1
1
1
2
2
3
3
4
4
5
1
1
1
1
1
1
1
1
2
2
2
2
Min spreading
factor
4
4
4
4
4
4
4
4
2
2
2
2
4
4
4
4
4
4
2
2
2
2
2
2
RLC peak rate

[bit/s]
32000
64000
128000
192000
256000
512000
768000
1024000
1280000
1536000
1792000
2048000
64000
128000
256000
384000
512000
1024000
1536000
2048000
2560000
3072000
3584000
4096000
As for HSDPA bearers, Atoll utilizes internally both MAC rates and the RLC peak rates also for the
HSDPA bearers. The MAC rates are determined by the transport block sizes, and the default RLC
peak rates are somewhat lower.
The default transport format of the preceding table look rather curious. It seems that Forsk has
based these definitions on the old 3GPP TR 25.896 V6.0.0 from the year 2004. Anyhow, this dialog
of Atoll enables definition of appropriate HSUPA transport formats.
81/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Like the Eb/No requirements of HSDPA bearers, also the Eb/No requirements of HSUPA bearers
are hidden into a separate lookup table under Data | UMTS Parameters | Terminals | Reception
Equipment.
Radio Bearer Index
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
No. of Retransmissions
2
2
2
2
2
2
2
2
2
2
2
2
4
4
4
4
4
4
4
4
4
4
4
4
Required Ec/No
-21.7
-19.0
-16.1
-13.9
-13.0
-10.1
-8.0
-7.0
-6.0
-5.0
-4.0
-3.0
-20.9
-17.9
-16.1
-13.9
-10.9
-9.1
-8.0
-6.0
-6.8
-5.7
-4.8
-3.8
Like HSDPA services, also HSUPA services always contain an associated (R99) DPCH (A-DPCH)
radio bearer.
Atoll uses HSUPA UE categories that correspond exactly to the six HSUPA UE categories of 3GPP,
which are defined according to their radio access capabilities:
-
maximum number of E- DPDCH codes transmitted,

minimum spreading factor, and
support for 2 ms TTI.
The HSDPA UE categories are defined under Data | UMTS Parameters | Terminals | HSUPA User
Equipment Categories.
Category
Max no. of EDPDCH codes
Support for
TTI
Min spreading
factor
Max block
size for 2 ms
Max block
size for 10 ms
82/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
TTI
1
2
3
4
5
6
1
2
2
2
2
4
10 ms
2/10 ms
10 ms
2/10 ms
10 ms
2/10 ms
4
4
4
2
2
2
2798
5772
11484
TTI
7110
14484
14484
20000
20000
20000
Before HSUPA can be used in an Atoll network, it must be enabled separately in every UMTS cell.
When the HSUPA check box has been selected, user can also define the DL HSUPA Power, which
is the power allocated to HSUPA DL channels E-AGCH, E-RGCH, and E-HICH, and the Max
Number of HSUPA Users that the cell can support at any given time.
As a result of Monte Carlo simulation, each cell gets the UL Load Factor Due to HSUPA and the
(average ) Number of HSUPA Users. User can also enter these parameters manually into cells.
They will be used as input to HSUPA prediction studies.
Atoll does not try to model any specific HSUPA scheduling algorithms. While connecting HSUPA
terminals to cells in Monte Carlo simulation, Atoll uses the so-called noise rise scheduling, which
attempts to evenly share the remaining cell load (difference of maximum allowed uplink load and
the load produced by the served R99 traffic) between HSUPA users. Atoll processes all HSUPA
users that are connected or delayed on a HSDPA bearer and have enough transmit power for a
HSUPA bearer. The assigned load then defines the Ec/No for each HSUPA user, which (together
with the maximum transmit power of the terminal) determines the HSUPA bearer that can be used.
Like HSDPA scheduling, also the HSUPA noise rise scheduling is always assumed to happen at
cell level.
HSUPA support in Atoll is quite good, and it is infinitely better than the HSUPA support in NetAct
Planner, which does not exist.
83/121
Report
Tools Management &
Support
5.9

18.6.2008, ver. 1.0
For internal use
Neighbour Planning
Atoll supports automatic allocation of (intra- and inter-carrier) neighbours in a UMTS network. The
cells for allocation are selected by using the focus and computation zones. Atoll allocates
neighbours only to the cells within the focus zone and considers as possible neighbours all the
active and filtered cells whose propagation zone intersects a rectangle containing the computation
zone.
Neighbour allocation is controlled by the following parameters:
-
maximum inter-site distance

maximum number of neighbours
% min. covered area
coverage conditions (min. pilot signal level, min. Ec/Io, Ec/Io margin, power contribution to Io,
shadowing)
The relative importance of coverage, adjacency and co-site location can be weighted by user.
Neighbour planning has been extensively tested during 2G testing, where the quality of neighbour
planning in Atoll was found to be lower than the quality in Planner. Similar tests have not been
repeated for UMTS networks.
5.10
Scrambling Code Planning
Atoll supports also planning of (primary) scrambling codes for UMTS downlink. The possible
constraints on the automatic scrambling code allocation are:
-
neighbours (either 1st, 2nd or 3rd order),

Ec/Io conditions (min. Ec/Io and Ec/Io margin),
(min.) reuse distance between two cells using the same scrambling code (a cell parameter).
In addition to these constraints, it is also possible to define in Atoll "exceptional pairs", which are
pairs of cells that are not allowed to have the same primary scrambling code.
The automatic allocation strategy can be selected as:
-
clustered (codes preferentially from the same cluster.)

distributed per cell (codes preferentially from different clusters)
one cluster per site (preferentially one cluster to each base station, then one code of the cluster
to each cell)
distributed per site (group of adjacent clusters to each base station, then one cluster to each
cell)
There are 512 primary codes that are divided into 64 code groups of 8 codes. However, Atoll uses
the term group for referring to user-defined sets of scrambling codes (which are called scrambling
code schemas in NetAct Planner), and hence the code groups are referred to as "clusters" in Atoll.
Cells are included into automatic scrambling code planning by using the focus zone and computation zone: the scrambling codes for cells within the computation zone are (re)planned, and the
84/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
scrambling codes for cells within the focus zone are unchanged but taken into account as constraints.
Both Atoll and Planner support planning of scrambling codes and visualization of codes on map,
but the terminology and practical steps of code planning are quite different. Planning of scrambling
codes for a large network could reveal differences in the performance of scrambling code allocation
algorithms, but the small test network that has been used in this section cannot really test the allocations.
5.11
Conclusions on UMTS Planning
In many aspects (OVSF code consumption, multiple parallel channels and parameters for HSDPA
and HSUPA, etc.) Atoll models UMTS networks more accurately than Planner, but in some aspects
(number of simulation arrays, resources, etc.) Planner seems to be more complete. If all parameters are appropriately set in Atoll, network performance estimation in Atoll should be as accurate or
even better than in NetAct Planner.
For many aspects of UMTS networks Atoll provides preconfigured default support, which is not as
easily available in Planner. For example, the HSDPA bearers and their parameters for all modelled
HSDPA transport formats have to defined from scratch by the user in Planner.
One obvious advantage of Atoll is that it already has quite good HSUPA support, which is still
missing from NetAct Planner.
Since simulation snapshots are statistically independent from each other, activities of UMTS
services have to be explicitly defined in planning tools. However, the methodology for using the
activities in simulation is quite different in Atoll and in Planner. In Planner, power and resource
consumption of a service is weighted by it's activity factor. In Atoll, users are divided into four
activity status classes - inactive, active on UL, active on DL or active on UL and DL - according to
the activity factor of the service. Even though our judgement may be slightly biased by our familiarity with NetAct Planner, we find that the methodology of Planner models more naturally fullduplex connections of circuit-switched services in real networks, and it also provides results that
are more intuitive to interpret.
The greatest weakness of Atoll in UMTS planning are the traffic maps. Every Monte Carlo simulation requires a traffic map as it's input, and easy creation and visualization of traffic maps are
fundamental requirements for a planning tool. Typically, traffic maps that are used in simulation are
created by distributing traffic in relation to the clutter layer of the digital map. Creation of such map
requires far too many steps in far too many dialogs in Atoll, and the final result cannot even be
visualized on the map view.
85/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
6.
WiMAX Planning
6.1
General Issues About WiMAX Radio Planning in Atoll
The evaluated version of Atoll was 2.7.0 (Build 2432). As in NetAct Planner WiMAX (Wireless
Interoperability for Microwave Access) IEEE 802.16d and the IEEE 802.16e standards are handled
as separately technology.
In Atoll two separate document templates, named WiMAX 802.16d and WiMAX 802.16e, are
available for designing and planning these networks.
In Planner WiMAX 802.16d is supported since Version 5.2.1 meanwhile WiMAX 802.16e starts to
be supported in the Current Version 6.0.
It can be well argued that the Broadband Module Atoll is designed better than in Planner even if
there are few limitation that will be discussed later on. The current version of Atoll support already
AAS by modelling Smart Antenna equipment, meanwhile other Basic Planning functionality are not
present as in Planner (e.g. Preamble index Planning, Automatic Frequency Planning).
As a short summary it can be concluded that Atoll for WiMAX radio planning is very flexible and
user friendly tool that features very broad capabilities for analysing expected network behaviour
and performance. However the Current Version of Atoll is still missing of one basic Array: The
Preamble CINR that is one of the KPIs that reflects the quality of the WiMAX radio network.
6.2
Scope of WIMAX Support
6.2.1
Test Case Description
The Test of the WiMAX 802.16e template will be done in a small network of 12 Sites as shown in
the picture below:
86/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 21. Model Network for Test Cases.
The analysis will be performed according to the following cases:
Basic: Using Static Load 70% for Downlink, 50% for Uplink and 3dB of UL Noise Rise
Figure 22. Basic Test Cases.
Advanced :Traffic Simulation and MIMO using the following scenario:
87/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 23. Advanced Test Cases.
The AAS will not be tested since not present in NSN Roadmap.
6.2.2
Optional: Preamble CINR Workaround comparison with NAP, BLER Modelling in Quality
Indicator
General Parameters
Before start Planning in Atoll for Basic Scenarios different parameters and options are available. In
the WiMAX module that are used in coverage predictions as well as Monte Carlo simulations. In
this chapter we will go through those settings:
"Defining Frequency Bands"

"The Global Transmitter Parameters"
"Defining Frame Configurations"
"Defining WiMAX Radio Bearers"
"Defining WiMAX Quality Indicators"
"Defining WiMAX Reception Equipment"
6.2.2.1
Frequency Bands
Frequency Bands in Atoll represent what in Planner is the Mobile WiMAX Carrier configuration tab.
Planner define carrier by carrier (0, 1, 2, etc..) the Centre Frequency, Bandwidth, Duplex Mode and
UL/DL Adj. Channel Attenuation plus the OFDMA basic parameters such Cyclic Prefix, Frame
Duration, Transition Gap, # of OFDMA symbols and the UL/DL Overhead in %. Atoll define the
Band with the starting Frequency, the Channel Bandwidth, the first and the last channel and the
Adj. Channel Suppression Factor meanwhile the OFDMA parameters are moved on Global
Transmitters Parameters.
In the templates for WiMAX 802.16e are already defined several Frequency Bands Licensed and
Unlicensed by default, for our Test Cases we create three new Frequency Band according to the
3A Profile that allow the deployment of unpaired network assuming the starting DL Frequency at
2.5 GHz
88/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 24. Frequency Band Dialog Window in Atoll.
6.2.2.2
Global Transmitter Parameters
As already mentioned before Atoll specify all the OFDMA parameters in the global WiMAX
parameters tab. WiMAX Control Channel can be handle by fixed and variable overhead. Usually
Fixed Overhead can be used to Model Preamble since the unit is symbol duration and Preamble
symbol length is fixed (1 symbol in the Frame). The variable overheads can be used to model other
time-domain overheads such as broadcast messages including DL-MAP, ULMAP, FCH, MAC
Overhead (in downlink) and MAC Overhead, Ranging, Bandwidth Request messages (in uplink).
Figure 25. Transmitter Dialog Window in Atoll.
Additional consideration can be furnished in Atoll WiMAX Frame Configuration:
TDD Ratio: in Atoll is the percentage of the entire frame duration which corresponds to the
downlink sub-frame and must be calculated meanwhile in Planner can be easily specified
as number of Symbol.
Transmission and reception time guards: in Atoll TTG & RTG times [ms] are specified
separately, meanwhile in Planner is called Transition Gap [us] and includes both.
In summary the splitting in Atoll of the Overhead between Fixed and Variable, reflect better the
overhead modelled in Link Budget Calculation meanwhile in Planner can be defined only as a
percentage. As a constraint the WiMAX frame configuration is not totally transparent, the total
number of symbol in the frame is calculated internally and never show (even in grey, as computed)
even the TDD Ratio that is defined as a percentage could be better to define directly the number of
DL symbols since the number of symbols in the Frame is specified by IEEE as is it implemented in
Planner.
89/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Finding:
According to Chapter 8.1.5 of the Atoll Technical Reference Guide the number of symbol on the
frame are calculated as in the attached file:
Symbol
Calculation.xls
The possibility to specify only the 3rd decimal in TTG can introduce an error for 5 and 10MHz
cases considering 46 symbol instead 47 in the frame. Currently the same problem can appear in
Planner but in Planner Transition GAP in microsecond and the number of symbol in the frame are
visible in grey.
[Forsk Answer]: The number of symbols being rounded to the lowest integer value (and not to the
nearest), we need to use a TTG or RTG rounded to the lowest integer value, and not to the nearest
integer value. Means that in our case is TTG =0.105ms
The definition of the OFDMA parameters in the Global Transmitter Parameter Tab means that those
setting will be common for the whole network in Atoll meanwhile theoretically in Planner since is it
at Carrier level there is the possibility to handle cells with different TDD ratio (Capacity issue).Both
tool are able to handle configuration with uneven bandwidth between sectors.
6.2.2.3
Frame Configurations
A frame configuration is the description of a frame in the frequency as well as in the time dimension. In the frequency domain, it defines how many subcarriers exist in the channel width used, and
how many of these subcarriers are used and for which purpose, i.e., pilot, data, DC, guard. In the
time domain, it defines how long the frame is, and its composition.
In the Frame Configuration can be specified up to 8 for DL and up to 3 for UL different Permutation
zone according to the IEEE specification and if the segmentation is supported. The switching point
is defined at cell level in the segmentation usage Parameter.
In summary a detailed Frame configuration is available in Atoll meanwhile in Planner there is the
possibility only to specify the # of symbol between DL PUSC or DL FUSC. This current definition in
Atoll allows the modelling of Permutation in a proper way according to IEEE standards. For example Fractional Frequency Reuse is already supported by Atoll meanwhile is not clear how can be
handled by Planner.
Please, see the Section WiMAX Frame Configuration Settings in Appendix for the frame
configuration and cells settings used in order to perform our test cases.
6.2.2.4
WiMAX Radio Bearers
The definition of WiMAX radio bearers in Atoll differ a little bit from Planner, because is necessary
to configure three tabs (WiMAX Bearer, Quality Indicator and Reception Equipment) meanwhile in
Planner is performed by the Bearer Configuration tab. According to NSN Flexi WiMAX BTS Product
Description the Modulation and Code Scheme supported are present in the following figure:
90/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 26. WiMAX Bearer Dialog Window in Atoll.
The information used in throughput calculations is only: Bearer Efficiency (bits/symbol). For
information regarding Bearer Efficiency Formula please refer to Relation between bearer efficiency
and spectral efficiency in WiMAX User Manual.
In Summary in Planner the Bearer definition is performed using Modulation, Coding Rate (Used
also in case of definition of Bearer with different BLER) and Repetition (In case of QPSK only) so
Bearer efficiency is already calculated during the User Rate Calculation meanwhile in Atoll should
be inserted by hand. Channel Coding Rate is only for Information and is not used at all.
In addition Planner has the possibility to define in the Bearer table the support of MIMO bearer by
Bearer meanwhile MIMO modelling in Atoll doesnt impact the Bearer table.
6.2.2.5
WiMAX Quality Indicators
Quality indicators depict the coverage quality at different locations. According to NSN link level
simulation here the supported QI:
Figure 27. Quality Indicators Dialog Window in Atoll.
The Modelling of Quality indicators allows further analysis in the next version of Atoll when will be
available QI Maps. For further information se the Optional
In Summary in Atoll the possibility to model QI gives somehow the behaviour of HARQ/ARQ
algorithms that in Planner can be performed only with several bearers per several BLER target.
6.2.2.6
WiMAX Reception Equipment
91/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
WiMAX reception equipment models the reception characteristics of cells and user terminals.
Bearer selection thresholds and channel quality indicator graphs are defined in reception
equipment.
NSN link level simulations are available only for Pedestrian 3Km/h.In Atoll the SINR Bearer
Selection Threshold used are for 20% of BLER (in downlink the Bearer id 7 is not used since the
Modulation required worst SINR that the above ones).
The Quality Graph is used to specify SINR Threshold bearer by bearer at different BLER (20%,
10%,1%).
Figure 28. Bearer Threshold and Quality Graph Dialogs Window in Atoll.
For all the value used please see the Section Bearer id Mapping in Appendix.
92/121
Report
Tools Management &
Support
6.3

18.6.2008, ver. 1.0
For internal use
Results of WIMAX Network Analysis
Two types of WiMAX coverage predictions are available in Atoll: coverage predictions used to
analyse signal quality, and coverage predictions used to analyse the network response to traffic.
Signal quality coverage predictions can be used to analyse different signals (preamble, traffic, etc.)
in the downlink as well as in the uplink. These coverage predictions do not depend on the network
load conditions. You can study the network behaviour under traffic conditions by making coverage
predictions used to analyse the network response to traffic. Using these coverage predictions you
can study the effective service coverage area and capacity of each cell in the network. These coverage predictions depend on the interference in the network and the cell load conditions. For this
reason, the network load must be defined in order to calculate these coverage predictions. For the
purposes of these coverage predictions, each pixel is considered a non-interfering user with a
defined service, mobility type and terminal. The tool can be easily generated Preamble RSS, Data
Symbol CINR Array, DL/UL MCS Coverage and throughput arrays. Distribution over the selected
area can be exported into Excel and can be already visualize in Histograms.
6.3.1
Basic Analysis
Atoll can base its quality studies on the UL and DL traffic load and on the UL noise rise entered in
the Cells table as stated in the Test Case Description we will use:
UL traffic load = 50%

DL traffic load = 70%
UL noise rise = 3dB
For the setting used please see the Section Settings for BASIC Analysis in Appendix.
In our analysis no Shadowing Margin and Penetration Loss will be taken into account.
93/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 29. Coverage by C/(I+N) Level (DL): Comparison Scenario a), b) and c).
94/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 30. Coverage by Throughput (DL): Comparison Scenario a), b) and c).
95/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 31. Coverage by C/(I+N) Level (DL): Comparison Scenario a), d), e) and f.
96/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 32. Coverage by Throughput (DL): Comparison Scenario a), d), e) and f).
97/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
The aim of the Basic Analysis is to understand the behaviour of Atoll with different network
configuration, with particular focus into the DL C/(I+N) and throughput calculation.
In the present Atoll Version the Preamble C(I+N) is not available according to Forsk roadmap will
be available in next release 2.7.1. Actually also in Planner the C/I Calculation is not properly supported.
Comparison between Scenario a), b) and c)

In the Traffic CINR calculation we can see slight differences due to the fact that the Traffic
Load is fixed for all the scenarios meanwhile the Noise Calculation is changing due to
different Channel Bandwidth. The results are in line with the expectation.
In the Throughput Calculation we can see the capability of the tool to support uneven
Channel Bandwidth and the calculation in a proper manner of the Downlink Throughput.
Basically the capacity of 5MHz of Channel is half of 10MHz Channel as expected.
Comparison between Scenario a) and d)

In the Traffic CINR calculation we can see few differences due to the fact that the Traffic
Load is fixed for both scenarios, than using the same Preamble index schema (in Scenario
d)) the carrier calculation and interference calculation are both averaged by 1/3 in the pixel.
The slight difference is of course in the Noise Calculation since the Total BW of the Site in
Scenario a) is 30MHz meanwhile in Scenario d) is 10MHz. The results are in line with the
expectation.
In the Throughput Calculation we can see of course the difference since the total Bandwidth
of the site is different as mentioned before.
Comparison between Scenario d) and e)

In the Traffic CINR calculation we can see the differences due to the fact that the Scenario
e) is a Pure PUSC 1/3 (N=1) in this scenario of course the Inter-cell Interference is taken
into account. This is not a suitable scenario for WiMAX Network Design since even if the
cell Throughput is bigger (Close to the antenna) bigger outage zone are discovered
especially between sector and sites. The results are in line with the expectation.
Comparison between Scenario e) and f)

As already described before the scenario e) is not suitable for WiMAX design nevertheless
due to spectrum restriction in different country can be the only solution for an Operator. In
those cases the Fractional Frequency Reuse can reduce the Outage zones. In our test case
we can see that there are few improvement from this configuration: CINR and Throughput
gain can be found only at cell edge far away from Transmitter (Areas Highlighted in the
picture).
98/121
Report
Tools Management &
Support
6.3.2

18.6.2008, ver. 1.0
For internal use
Advanced Analysis
The aim of the Advanced Analysis is to verify Monte Carlo Simulation and the Impact MIMO on
CINR distribution. For all the setting used please see Section Settings for Advanced Analysis in
Appendix.
6.3.2.1
How MIMO transmission is modelled
The current Version of Atoll allows the modelling of different diversity techniques as MIMO and
Smart Antenna System as well. Matrix A that in Atoll called STTD (Space-Time Transmit Diversity)
and Matrix B that in Atoll is called SM (Spatial Multiplexing). In addition AMS (Adaptive MIMO
Switch) can be used in case of BTS equipment can switch between Matrix B to Matrix A if CINR
is getting worsen. This behaviour should be what is actually modelled in NSN Flexi WiMAX BTSs.
The example below show the Gain on DL Traffic CINR distribution in case of only STTD.
Figure 33. Coverage by C/(I+N): MIMO Gain.
In summary Planner support STTD and SM using a CINR adjustment based on the number of TX
or RX antenna elements. The MIMO supporting is specified in BTS, terminal type and Bearer. In
Atoll STTD Gain and SM gain is modelled in more accurate way (for further clarification please
refer to Atoll2.7.0_WiMAX Advanced Training Material) and MIMO supporting is specified at BTS
and terminal type level as in Planner and in the Permutation zone in the Frame configuration tab.
6.3.2.2
Traffic Simulation
Report
99/121
Tools Management &

Support

18.6.2008, ver. 1.0
For internal use
Atoll supports versatile ways to define traffic. Traffic definition is needed as basis for Advanced
network capacity analysis. Following ways for defining traffic are supported by Atoll:
-

For this test the Marketing based Traffic Data based on environment was selected and briefly
tested.
Basically running Monte Carlo Simulation UL, DL Traffic Load and UL noise Rise as well is computed than is possible to produce the same coverage plots present on Basic analysis but based on
Simulation results for additional study.
The implementation of Traffic Model in Atoll needs further Clarification since from end user prospective differs from Planner nevertheless the session tips and tricks of User Manual provide
some suggestion especially for VoIP modelling.
One of the main difference with Planner is that Atoll presents different scheduling methods that are
used by the Simulation Algorithm during Resource Allocation and can reflect better the behaviour of
the scheduler in the BTS since has an impact on user throughput calculation.
6.3.3
Optional Analysis
6.3.3.1
Preamble CINR in PUSC Reuse 1
The first Test Case selected is the workaround calculation for Preamble CINR in PUSC Reuse 1
Scenario a). Since Atoll is not yet supporting this Analysis and NAP doesnt support this case in a
proper manner for this test we would perform a benchmarking of the result of both tools.
As already described in the Propagation Model chapter, there are differences in the Preamble RSS
Array, for this reason we will use in Atoll a Preamble Power of 47,5dBm instead 36dBm as default
setting in NAP.
Following the Array results for Preamble RSS and CINR from NAP and Atoll:
100/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 34. Preamble RSS (NAP-Total Tx Power 36 dBm).
Figure 35. Preamble RSS (Atoll-Preamble Power 47,5dBm).
101/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 36. Preamble RSS (Atoll-Preamble Power 36 dBm).
Figure 37. Preamble RSS Statistics.
The statistics results show how the delta in Power brings the results very close.
102/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 38. Preamble CINR (NAP).
Figure 39. Preamble CINR (Atoll - 47.5dBm).
103/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 40. Preamble CINR Statistics.
The Statistics Results shown differences especially for areas with higher CINR, NAP show more
optimistic results meanwhile in Atoll there is a strange behaviour between sectors for all the cells
with azimuth going out of the selected Planning Area maybe this phenomenon could be related to
the cell radius used for the predictions even if the setting for both tools is the same (20Km). this
Phenomenon should be checked better with Forsk.
6.3.3.2
BLER Modelling in Quality Indicator
As already described in Chapter WiMAX Reception Equipment the Bearer selection Threshold
used in Bearer vs. CINR table represent the 20% of BLER, than using QI is possible to Model the
smoothing of the curve using a Quality Graph that require the CINR required at different Blocking
Error Rate.
In the current version of Atoll there are no Map available for Quality Indicator nevertheless this
information is already available in the Monte Carlo Simulation Report. Basically the Bearer Determination is performed assigning to the pixel, subscriber or mobile the lowest Bearer according to
the Traffic CINR threshold calculated.
104/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 41. Subscriber Properties.
The above example shown:

1
2
3
4
5
For the mobile selected the DL Traffic CINR Calculated is 13.04dB

According with the Bearer Table this threshold allow the selection of Bearer id 8
According with the Quality Indicator Graph 13.04 is a CINR value very close to 1% of BLER
The BLER interpolated value is 4% (0.04) assigned to this subscriber.
Than this BLER will be used for the Effective MAC Channel throughput from the Peak Value
6.4
Directional terminal antennas (Fixed CPEs Case)
6.4.1
How CINR Distribution with directional SS antenna can be calculated
The Current version of Atoll can handle Mobile Terminal type as well Rooftop Terminal simultaneously. In Atoll the RX antenna pattern of the CPE can be easily loaded for both terminal type. One
of the main benefit of Atoll is the Benefit to handle a list of fixed subscriber meanwhile in Planner
need a workaround (distribution of user in points).
In addition Atoll using the Automatic Server Allocation feature which recalculates the path loss,
received power, and other output for each subscriber furnish a list of output that usually are required by Customer in case of Fixed CPE deployment (e.g. to which BS the subscriber is belongs
to, CPE azimuth and Tilt, etc..)
The utilization of Rx Directional Antenna instead an Omni Receiver (Mobile users) imply differences
in the DL/UL CINR Distribution.
The example below show the DL Traffic CINR distribution in case of isotropic or directional
antenna.
105/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 42. Coverage by C/(I+N): isotropic vs. directional.
6.5
WiMAX Frequency Planning
6.5.1
Is WiMAX Frequency Planning Supported
The Current version of Atoll doesnt support Automatic Frequency Planning and Preamble index
allocation even the Neighbour allocation cannot be performed in automatic way.
Uneven Bandwidth, Preamble Segment and Sub-channel group are already supported as
somehow tested during our Basic test cases. The main difference with Planner is the supporting of
Preamble Index Parameters meanwhile in Planner is expected in Version 6.1, How ever since
Preamble CINR array is not yet computed we cannot appreciate the benefit of this feature.
6.5.2
Atoll WiMAX Roadmap
Below the list of the next feature expected in Atoll according to the biggest delivery milestone:
2.7.1
2.8.0
Automatic Neighbour Allocation

Automatic Preamble Index Allocation
Possibility to Model External Interference
New Coverage based on Preamble C(I+N)
New Propagation Model: Sakagami Extended Propagation Model
106/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Automatic Frequency Planning

Quality Indicator Coverage Map (BLER, BER, PER, etc)
6.6
Conclusions on WiMAX Radio Planning with Atoll
Atoll includes in principle all functionality needed for WiMAX radio planning, leaving out the Preamble CINR calculation that is expected in version 2.7.1. Atoll is a good tool, it has good features
and it is for most planning tasks quite easy and fast once the user knows how to use the tool.
The current version released presents almost the same functionality of Planner. Is important to
point out some key factor in Atoll:
WiMAX Control Channel can be modelled in a detailed way
Frame configuration is well modelled according to IEEE standard especially
regarding Permutation Zone and Segmentation. Small improvement could be
necessary in order to make it more transparent to end user
Fixed CPEs cases can be easily handled based on subscriber list. The Rx Antenna
pattern can be modelled and CPE azimuth has correctly impact on CINR Distribution
Calculation
Preamble Index Parameter is already present, his automatic allocation will be
available in the next release as well as Preamble CINR Array meanwhile Automatic
Frequency Planning will be available later on.
MIMO could be modelled in a detailed way (even on clutter basis)
Smart Antenna System is already supported
107/121
Report
Tools Management &
Support
7.

18.6.2008, ver. 1.0
For internal use
Atoll Roadmap and Future Development
The Forsk roadmap for the Atoll 2.8.0 version (to be released in December 2008) or for 2.7.x
versions before this includes the following major features:
-
WiMAX automatic frequency planning,

modelling of interference between GSM900 and UMTS900 networks,
new integrated ACP module (first only for UMTS, later also for GSM or GSM/UMTS),
Sakagami Extended propagation model for (fixed) WiMAX,
interactive frequency planning module for GSM (cost of selection of one frequency for one cell
can be interactively investigated).
Support for Long Term Evolution (LTE) of UMTS shall probably not be available before Q209, but a
mini LTE module will be provided for selected customers already in June/July 2008.
The Atoll WiMAX roadmap has been discussed in the Section 6.5.2.
The version 2.7.1 of Atoll will include an integrated ACP tool (for UMTS). Such a module might
provide an interesting ACP solution, since integration between the planning tool and the ACP tool
makes planning easier and more accurate.
When we take into account the HSUPA support in Atoll and the comprehensive implementation of
Mobile WiMAX, Forsk seems to be far ahead of Aircom in introduction of support for new radio
technologies.
108/121
Report
Tools Management &
Support
8.

18.6.2008, ver. 1.0
For internal use
Conclusions and Open Questions
Atoll was tested in radio access network planning of GSM, UMTS and Mobile WiMAX networks. In
all kind of networks, it was noticed that many calculations are faster in Atoll than in NetAct Planner.
It was also found that terminology, dialogs and overall logic of most planning tasks are quite different from the corresponding ones in NetAct Planner. This means that a switch from Atoll to NetAct
Planner would require extensive competence development among planners. On the other hand, it
was observed that most planning tasks are relatively easy and fast, once the user learns how to
use the tool.
In GSM planning, frequency planning is a critical planning task. It was found that the quality of the
GSM frequency plan in Atoll is more or less at the same level as the quality of the plan in NetAct
Planner.
Many aspects of UMTS networks are modelled and preconfigured more accurately in Atoll than in
NetAct Planner. However, there are still some aspects - e.g. simulation arrays and resources where NetAct Planner is more configurable and flexible. One obvious advantage of Atoll is also that
it already has quite good HSUPA support, which is still missing from NetAct Planner.
The greatest weakness of Atoll in UMTS planning are the traffic maps, the creation of which is far
too complicated in Atoll. The modelling of activities of UMTS services in Atoll is also less realistic
than in NetAct Planner.
Atoll was found to include all essential functionality that is needed for WiMAX radio planning, except the preamble CINR calculation that should be available in the next version (2.7.1). Modelling
of many aspects of WiMAX networks - WiMAX control channels, frame configurations, fixed CPEs,
MIMO, smart antenna systems, etc. - is more detailed in Atoll than in NetAct Planner.
The tests were carried out using a fairly new version of the software, but no significant bugs were
found during testing. The only major problem was encountered, when Forsk provided us some
demo networks, which could be not opened with the tested software version.
Atoll has been originally designed to be used with it's internal database, and that the use of an external database in multiuser environment is an afterthought. The amount of administration work in a
multiuser environment with an external database is going to be much larger for Atoll than for NetAct
Planner. This is an important drawback in NSN environment.
Detailed network planning is the most demanding application of a planning tool, and this application
defines the main criteria for a planning tool. However, there are many other kinds of small tests that
can be conducted with a planning tool. Atoll is very well suited for such tests, since it is fast to install, and since it is very easy to send a complete plan from one Atoll user to another.
Data transfer and interfaces to a network management system (NetAct) are going to be major
problem areas, if a new planning tool will be introduced into NSN environment. No external planning tool will contain an object model that would be directly compatible with NetAct, and conversions between data formats are going to require lot of work for any new planning tool.
109/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Data transfer capabilities of Atoll were not tested in this evaluation. However, the results of this
report show that the database of Atoll is rich enough to accurately model essential parameters of
2G and 3G networks. It should also be quite easy to extend the database of Atoll, if specific IDs
and fields are required for data export purposes. Hence, there is no reason to assume that Atoll
would be especially problematic in connection to a network management system.
It should be possible to automate execution of planning tasks in Atoll by writing scripts using
VBScript. This feature was not tested, but it could be a very powerful feature in NSN environment.
As a company, Forsk is concentrating on the planning tool business, and they seem to be relatively
fast in introduction of new technologies. Atoll is already now supporting HSUPA and Mobile
WiMAX, and Forsk is working on LTE support. Since planning tool is only one among the business
areas of Aircom, it is reasonable to expect that support for new technologies will be ready earlier in
Atoll than in NetAct Planner, and the support is probably also going to be more extensive.
110/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
9.
Appendix: WiMAX Network Configuration
9.1
WiMAX Frame Configuration Settings
Following the settings for our Test cases:
Scenario a): Three 10 MHz channel, with channel number 0,1 and 2, defined in the
frequency band, that can be allocated to sectors. The frame configuration that can be used
is FFT Size 1024.
a. Set up the frame configuration:
i. Open the Frame Configurations table
ii. Verify that the Segmentation Support check box is not selected.
iii. Double-click the frame configuration FFT 1024 PUSC N3. The Permutation Zones
table appears.
iv. Activate the permutation zones 0 (PUSC DL) and 8 (PUSC UL).
v. Click OK.
vi. Close the Frame Configurations tables.
b. Set up the cells:
i. Right-click the Transmitters folder. The context menu appears.
ii. Select Cells > Open Table from the context menu. The Cells table appears.
iii. In the Cells table, enter:
- Band: 3A - 2.5 GHz - 10 MHz for Sector1, 2 and 3
- Channel Number: 0 for Sector1, 1 for Sector2 and 2 for Sector3
- Frame Configuration: FFT 1024 PUSC N3
iv. Close the Cells table.
Scenario b):: Two 10 MHz channel , with channel number 0,1 and one 5MHz Channel, with
channel number 0 defined in the frequency band, that can be allocated to sectors. The
frame configuration that can be used is FFT Size 1024 and 512.
table appears.
vi. Double-click the frame configuration FFT 512 PUSC N3. The Permutation Zones
table appears.
vii. Activate the permutation zones 0 (PUSC DL) and 8 (PUSC UL).
viii. Click OK.
ix. Close the Frame Configurations tables.
- Band: 3A - 2.5 GHz - 10 MHz for Sector1, 1 for Sector2
- Channel Number: 0 for Sector1, 1 for Sector2
- Band: 3A - 2.5 GHz - 5 MHz Mixed for Sector3
- Channel Number: 0 for Sector3
111/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use

Scenario c): Three 5 MHz channel, with channel number 0,1 and 2, defined in the
frequency band, that can be allocated to sectors. The frame configuration that can be used
is FFT Size 512.
table appears.
v. Click OK.
- Channel Number: 0 for Sector1, 1 for Sector2 and 2 for Sector3
Scenario d): One 10 MHz channel, with channel number 0, that can be allocated to all the
three sectors. The frame configuration that can be used is FFT Size 1024.
i. Open the Frame Configurations
ii. Select the Segmentation Support check box for FFT 1024 PUSC N1.
table appears.
v. Click OK.
- Channel Number: 0 for Sector1, 2 and 3
- Preamble Index: 0 for the 1st sector, 32 for the 2nd sector, and 64 for the 3rd sector of
each 3-sector site.
- Segmentation Usage (DL) (%): 100%
112/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Scenario e): One 10 MHz channel, with channel number 0, defined in the frequency band,
that can be allocated to all the sectors. The frame configuration that can be used is FFT
Size 1024.
table appears.
v. Click OK.
Scenario f):: One 10 MHz channel, with channel number 0, defined in the frequency band,
that can be allocated to all the sectors. The frame configuration that can be used is FFT
Size 1024.
ii. Select the Segmentation Support check box for FFT 1024 PUSC N1.
table appears.
iv. Activate the permutation zones 0 (PUSC DL), 1 (PUSC) and 8 (PUSC UL).
v. Click OK.
- Preamble Index: 0 for the 1st sector, 32 for the 2nd sector, and 64 for the 3rd sector of
each 3-sector site.
- Segmentation Usage (DL) (%): 60%
9.2
Bearer ID Mapping
113/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 1. Bearer id Mapping
[Please Note] In WiMAX Reception Equipment -> UL Bearer and

in CPE Reception Equipment -> DL Bearer
9.3
Propagation Model
The Atoll Standard Propagation Model differs from The Standard Macrocell 3 of Planner below
there is the Asset-Atoll correspondence table
Asset
k1
k2
k3
k5
k6
k7
Atoll
K1= k1 - 3.k2 + 1.5 k3
K2=k2
K3=k5 - 3.k6
K4=k7
K5=k6
K6=0
Following there is the snapshot of the Model used:
114/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 2. Propagation Model Setting
9.4
Preamble RSS Array Finding
Using same antenna Pattern and Gain, Feeder Losses and Tx Power The results are very different,
as in the picture below:
Figure 3. Preamble RSS in Planner 6.0
115/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 4. Preamble RSS in Atoll 2.7.0
In order to get the same result we must boost the Preamble Power of 11.5dB in Atoll in order to get
the same coverage from Planner.
Figure 5. Preamble RSS in Atoll 2.7.0 (with Preamble boost)
This issue is under investigation with Aircom.
NetAct and Atoll

coverages_WiMAX.ppt
116/121
Report
Tools Management &
Support
9.5

18.6.2008, ver. 1.0
For internal use
Antennas and Equipment
For our Model Network we decide to use Flexi System Module and RF Head at 2.5 GHz, following
are described the environment used in order to evaluate the network performance.
Antenna: Kathrein_CS_7276901_-_2200-2700_MHz with 18.5 dBi of Gain
TMA: not used
Feeder: A Dummy feeder for the RF Head Jumper will be used assuming 0.5 dB of Losses
per meter. All sites will be equipped with 1meter of Feeder length in Tx and Rx.
BTS: Flexi WiMAX with 2.5 dB of Noise Figure.
117/121
Report
Tools Management &
Support
9.6

18.6.2008, ver. 1.0
For internal use
Power Settings
Following the setting used during our Test:
Preamble Power (dBm): 36 -> Assuming (4W RF Head)

Idle Pilot Offset (dB): 200 -> not used since no such implementation in current scheduler
FFT size is different between 5 and 10 MHz means that different number of subcarrier for Pilot and
Data are used. In this cases exactly the double according to IEEE.
Figure 6. Traffic Pilot Calculation
As you can se the Traffic and Pilot Offset is the same since the Power per subcarrier is double in
case of 5MHz but we have half subcarrier for Data and Pilot.
9.7
Traffic Pilot Offset (dB): 1.107

Pilot Power Offset (dB): 6.388
Settings for Basic Analysis
Figure 7. Mobility Dialog Window in Atoll
118/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 8. Terminal Dialog Window in Atoll
Figure 9. Service Dialog Window in Atoll
119/121
Report
Tools Management &
Support
9.8

18.6.2008, ver. 1.0
For internal use
Settings for Advanced Analysis
Figure 10. MIMO configuration Dialog Window in Atoll
Figure 11. Terminal configuration Dialog Window in Atoll
120/121
Report
Tools Management &
Support

18.6.2008, ver. 1.0
For internal use
Figure 12. Traffic Map
Figure 13. Users distribution
Figure 14. Service Dialog Window in Atoll
121/121
Report
Tools Management &
Support
9.9

18.6.2008, ver. 1.0
For internal use
Settings for Optional Analysis

NAP Settings
DL PUSC, UL PUSC = Sector

Tx Power = 36dBm
Pilot power = -100dBm, as there are no pilots on preamble symbol
Downlink Traffic Load = 100%, as the DL PUSC CINR array (represents Preamble
CINR in this case)
Figure 15. NAP Transmitter Setting
Atoll Settings
Preamble Power = 47,5dBm

Traffic Power Offset = 0dB, as all sub-carrier are transmitted on preamble symbol
Pilot Power Offset = 200dBm, as there are no pilots on preamble symbol
Idle Pilot Power Offset = 200dBm, as there are no idle pilots on preamble symbol
Downlink Traffic Load = 100%, as the Coverage by C(I+N) Level (DL) array
(represents Preamble CINR in this case)
Figure 16. Atoll Transmitter Setting

Atoll Test Report Complete

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Atoll Test Report Complete

Uploaded by

Copyright:

Available Formats

1/121

Atoll Evaluation Test

Atoll Evaluation Test

Atoll Evaluation Test

1. Purpose and Scope....................................................................................5

3. General Planning Issues in Atoll...............................................................20

4. 2G Radio Planning in Atoll........................................................................32

Atoll Evaluation Test

4.5.2 Manual GSM frequency planning.........................................................................................47

5. UMTS Planning in Atoll.............................................................................51

7. Atoll Roadmap and Future Development................................................107

Atoll Evaluation Test

WiMAX Frame Configuration Settings..................................................................................110

Atoll Evaluation Test

Purpose and Scope

Atoll Evaluation Test

Atoll Version and modules:

Atoll Evaluation Test

Configuring the installation in single mode.

There are many ways how the data can be stored

in a single file: planning data and digital maps as embedded

Atoll Evaluation Test

Atoll Evaluation Test

Client side files:

Atoll Evaluation Test

Atoll Evaluation Test

Atoll Evaluation Test

The report is easy to move to Excel using copy

Example of a simulation and Pilot

Export and Import from and to Planner

Atoll Evaluation Test

Export and Import from using Planet format

In Atoll there is 2 type of network planning data imports:

Import from other tools

Atoll Evaluation Test

Propagation models were not imported.

Atoll Evaluation Test

Large Project 283 sites

Atoll Evaluation Test

Import using ASCII format

Example of csv-file import

Atoll Evaluation Test

Atoll management Console

Atoll Evaluation Test

Opening a project database failed.

Concept of Master and Project database

Atoll Evaluation Test

Conclusions on Atoll Administration

Atoll Evaluation Test

General Planning Issues in Atoll

Atoll Evaluation Test

Figure 1. Clutter layer of the Helsinki Demo Map in NetAct Planner.

Figure 2. Clutter layer of the Helsinki Demo Map in Atoll.

Atoll Evaluation Test

Atoll Evaluation Test

height above ground,

Atoll Evaluation Test

- ITU 1546 Propagation Model

Usage of Two Propagation Models per Cell

Atoll Evaluation Test

Atoll Evaluation Test

Figure 4. Multiresolution coverage array in NetAct Planner.

Approximation of NetAct Planner's Nokia Propagation Model in Atoll

Atoll Evaluation Test