Professional Documents
Culture Documents
LTE RF System Design Procedure With - Atoll
LTE RF System Design Procedure With - Atoll
Revision 1.3
iProtect: Internal
Page 2
Table of Contents
1. INTRODUCTION................................................................................................ 17
1.1.
1.2.
1.2.1.
1.2.2.
1.2.3.
ML-CAT .......................................................................................................... 26
4.2.
4.2.1.
Installation ................................................................................................ 30
4.2.2.
4.3.
5.1.1.
5.1.2.
5.1.3.
5.2.
5.2.1.
5.2.2.
Placing Multiple Base Stations Using a Station Template via the Map..... 44
5.2.3.
5.2.4.
5.2.5.
Moving Sites............................................................................................. 47
5.2.6.
5.2.7.
Revision 1.3
iProtect: Internal
Page 3
5.2.8.
TERRAIN DATA.................................................................................................. 54
6.2.
6.2.1.
6.2.2.
Clutter Heights.......................................................................................... 60
6.3.
6.3.1.
6.3.2.
Building data............................................................................................. 66
6.4.
6.4.1.
6.4.2.
6.5.
6.6.
6.6.1.
6.6.2.
6.6.3.
7.1.1.
Sites ......................................................................................................... 82
7.1.2.
Transmitters ............................................................................................. 85
7.2.
7.2.1.
7.2.2.
7.2.3.
7.2.4.
7.3.
7.3.1.
7.4.
8.1.1.
Revision 1.3
Page 4
8.1.2.
8.1.3.
8.1.4.
8.2.
8.2.1.
8.2.2.
8.2.3.
8.2.4.
8.2.5.
8.3.
8.3.1.
8.3.2.
8.3.3.
8.3.4.
8.3.5.
8.3.6.
9.2.
9.2.1.
9.2.2.
9.3.
9.3.1.
9.3.2.
9.4.
9.4.1.
9.4.2.
9.4.3.
9.4.4.
9.5.
9.5.1.
Reports................................................................................................... 242
9.5.2.
9.6.
Revision 1.3
iProtect: Internal
Page 5
10.2.
10.3.
10.4.
10.5.
10.6.
10.6.1.
10.6.2.
10.6.3.
10.6.4.
10.7.
10.7.1.
10.7.2.
10.7.3.
10.7.4.
10.8.
10.8.1.
10.8.2.
10.8.3.
11.2.
11.3.
11.4.
12.2.
12.3.
12.3.1.
Adjusting the Bearer Threshold Values for Traffic Channel Studies....... 289
12.3.2.
12.3.3.
Revision 1.3
iProtect: Internal
Page 6
Revision 1.3
iProtect: Internal
Page 7
List of Tables
Table 1: Recommended Workstation Configuration ...................................................... 30
Table 2: Max Power (dBm)........................................................................................... 94
Table 3: TDD configurations.......................................................................................... 96
Table 4: Diversity support.............................................................................................. 97
Table 5: PUCCH RB's ................................................................................................. 110
Table 6: Max MIMO Gains .......................................................................................... 137
Table 7: DL MIMO Parameter Settings ....................................................................... 139
Table 8: Lognormal Fade Margin (CINR) .................................................................... 204
Table 9: Downlink/Uplink kTB Values.......................................................................... 229
Table 10: DL Effective SNR Values (i.e. bearer selection thresholds) ........................ 230
Table 11: UL Effective SNR Values (i.e. bearer selection thresholds) ....................... 231
Table 12: Template Services Parameters ................................................................... 249
Table 13: Highest Bearer Settings .............................................................................. 251
Table 14: HARQ Gain Effective Data Rate Impact ..................................................... 288
Revision 1.3
iProtect: Internal
Page 8
List of Figures
Figure 1: Budgetary Process Flow Chart...................................................................... 20
Figure 2: ML-CAT Capacity Process Flow Chart.......................................................... 21
Figure 3: Detailed System Design Flow Chart (A) ........................................................ 23
Figure 4: Detailed System Design Flow Chart (B) ........................................................ 24
Figure 5: ML-CAT GUI ................................................................................................. 27
Figure 6: Project Templates .......................................................................................... 35
Figure 7: Coordinates Tab from Options Dialog ............................................................ 36
Figure 8: Coordinate Systems Dialog (Find In list showing) .......................................... 37
Figure 9: Coordinate Systems Dialog (both Cartesian/geographic coordinates showing)
............................................................................................................................... 38
Figure 10: Units Tab from Options Dialog ..................................................................... 39
Figure 11: Auto Backup Configuration........................................................................... 40
Figure 12: Saving GIS Data within a Computation Zone .............................................. 41
Figure 13: Save As Settings for Saving GIS Data within a Computation Zone............. 42
Figure 14: Base Station Templates ............................................................................... 44
Figure 15: Site 12 Positioned via Map........................................................................... 44
Figure 16: Hexagon Radius for Site and Sector ............................................................ 46
Figure 17: Hexagon Group of Sites ............................................................................... 46
Figure 18: Properties Dialog for Station Templates....................................................... 51
Figure 19: Accessing the Station Templates Table ...................................................... 52
Figure 20: Open - Import .............................................................................................. 54
Figure 21: Data Types.................................................................................................. 55
Figure 22: Digital Terrain Model ................................................................................... 55
Figure 23: Digital Terrain Image................................................................................... 56
Figure 24: Digital Terrain Model properties .................................................................. 57
Figure 25: Data Types.................................................................................................. 58
Figure 26: Clutter Classes............................................................................................ 58
Figure 27: Clutter Classes Image................................................................................. 59
Figure 28: Clutter Classes properties ........................................................................... 60
Figure 29: Clutter height definition ................................................................................ 61
Figure 30: Data Types.................................................................................................. 62
Revision 1.3
iProtect: Internal
Page 9
iProtect: Internal
Page 10
iProtect: Internal
Page 11
iProtect: Internal
Page 12
Figure 130: Menu Options for Creating or Importing Zones ....................................... 190
Figure 131: Menu Options for Editing a Zone............................................................. 191
Figure 132: Example of Filter Zone and Computation Zone........................................ 192
Figure 133 : Propagation Zone and Computation Zone .............................................. 193
Figure 134 : Focus & Hot Spot Zone Polygons ........................................................... 194
Figure 135: Focus & Hot Spot Zone Reports .............................................................. 195
Figure 136: Exporting a Coverage Prediction............................................................. 196
Figure 137: Predictions Properties Subscriber Antenna Height .............................. 197
Figure 138: Propagation Model Properties Clutter .................................................. 198
Figure 139: Selecting New Predictions........................................................................ 199
Figure 140: Selecting Prediction Type........................................................................ 200
Figure 141: Predictions General Tab.......................................................................... 200
Figure 142: Predictions Condition Tab ........................................................................ 201
Figure 143: Predictions Display Tab........................................................................... 202
Figure 144: Predictions Condition Tab with Shadowing for RSSI............................... 203
Figure 145: Accessing the Shadow Fade Margin Calculator...................................... 204
Figure 146: Shadow Fade Margin Calculator for RSSI............................................... 205
Figure 147: Shadow Fade Margin Calculator CINR ................................................... 205
Figure 148: Accessing the Clutter Classes Properties ............................................... 206
Figure 149: Clutter Class Standard Deviation ............................................................ 207
Figure 150: Clutter Class Default Values ................................................................... 208
Figure 151: Setting Condition Tab.............................................................................. 209
Figure 152: Setting Throughput Display Information .................................................. 210
Figure 153: Sample Coverage by Throughput DL Peak....................................... 211
Figure 154: Effective Signal Analysis DL Options ................................................ 212
Figure 155: Sample Effective Signal Analysis Best Traffic Signal DL...................... 213
Figure 156: Coverage by Throughput DL Options................................................ 215
Figure 157: Sample Coverage by C/(I+N) Level Image DL ...................................... 217
Figure 158: Sample Coverage by Transmitter Image................................................. 218
Figure 159: Sample Coverage by Transmitter Image with Margin ............................. 219
Figure 160: Best Bearer Modulation Scheme............................................................. 220
Figure 161: Sample Coverage by Best Bearer Image DL ....................................... 221
Figure 162: Atoll generated best bearer ranges .......................................................... 222
Revision 1.3
iProtect: Internal
Page 13
iProtect: Internal
Page 14
Revision 1.3
iProtect: Internal
Page 15
Revision History
Atoll
Release
Revision
2.8.0
Date
Author
Description
1.0.0
Aug 31-2009
SSE
2.8.0
1.0.2
Sept 22-2009
SSE
2.8.0
1.0.3
Sep 29-2009
SSE
2.8.01
1.1
Apr 19-2010
P&D
2.8.02
1.2
Nov 2-2010
P&D
2.8.03
1.3
Dec 17-2010
P&D
In Rev. 1.1, new sections reference Atoll release 2.8.1. For an overview of significant Atoll 2.8.1 changes, refer to
the Supplement Atoll 2.8.1 Features for LTE and WiMAX RF System Design Procedure document
(http://compass.mot.com/go/316936464 ).
2
In Rev. 1.2, new material references Atoll release 2.8.2. For an overview of significant Atoll 2.8.2 changes, refer to
the Supplement Atoll 2.8.2 Features for LTE and WiMAX RF System Design Procedure document
(http://compass.mot.com/go/316936464 ).
Revision 1.3
iProtect: Internal
Page 16
1. Introduction
1.1. LTE RF System Design Procedure
This document describes the procedure to follow and the tools used in producing an
LTE RF system design. In the case of detailed designs, this document assumes that the
Atoll RF planning tool will be used in the design process.
Throughout this document the terms base station (BS) and eNodeB (eNB) may be
used, but both terms are referring to the same thing.
The LTE RF System Design Procedure and ML-CAT guide are documents that describe
how to design a system using the various planning tools (procedures, proper settings of
values, how to interpret the results, etc.). These guideline documents do not address
contract issues or the commitments that should or should not be made to the operator.
There should be no commitments to any in-building coverage unless studies and
specific testing are done for a specific building and then the commitments to
coverage would only apply within that specific building. The RF system designers
need to stress to any individuals that are making the commitments to the
customer that there should not be any commitment made for in-building
coverage. An allowance can be made in the design for a set building loss, but
based on the composition of the building, and angle and distance from the base
stations the penetration of the signal into one building will be different than into
some other building.
When describing the detailed design process using Atoll, some of the information and
text in this document is taken directly from the Forsk Atoll manuals.
Revision 1.3
iProtect: Internal
Page 17
1.2.1.
Budgetary RF system designs are a balance between the time available to produce the
study, the availability of market data, and accuracy of the end results. The exact site
location and end deployment details are not required at this step. Approximate site
counts with correct bill of materials is the primary goal of a budgetary study. Using MLCAT can quickly produce results that meet these requirements (see Section 2).
Producing a budgetary RF system design using ML-CAT takes the following ten steps:
1. Gather customer requirements
2. Define the system service area
3. Subdivide service area into geographic neighborhoods (see Note 1 below)
4. Determine area of each neighborhood (see Note 2 below)
5. Enter system parameters and appropriate propagation model data into ML-CAT
6. Compute the area covered by a site within each defined neighborhood using the
tool
7. Determine the number of sites required by each neighborhood (neighborhood
total area divided by the per site area for the neighborhood)
8. System site requirements = the sum of the site counts for each neighborhood
within the service area.
9. Review results
10. Produce report
For details on the use of ML-CAT, see ML-CAT Guide document.
http://compass.mot.com/go/310448858
If an image is required to show the coverage for a budgetary design, Atoll may be used
in conjunction with ML-CAT. For budgetary designs, a statistical propagation model
(e.g. COST-231 Hata) may be used within Atoll.
(See Figure 1: Budgetary Process Flow Chart )
NOTES:
Note. 1.
Revision 1.3
Page 18
Revision 1.3
iProtect: Internal
Page 19
ML-CAT
1.2.2.
The capacity and throughput of an RF system is calculated for each cell for a given
neighborhood along with the site radii while using ML-CAT tool as described in Section
1.2.1. This tool utilizes the site information entered into ML-CAT and assumes that each
cell is operating with a full buffer (fully loaded). (Refer to Section 2.)
Calculating a system throughput and capacity using ML-CAT tool takes the following
five steps:
1. Calculate the number of users supported by each cell within a neighborhood
based on ML-CAT and multiplying that value by the number of cells within the
neighborhood.
Revision 1.3
iProtect: Internal
Page 20
Start
Calculate total
Subscribers supported
Review Results
Produce
Report
End
Revision 1.3
iProtect: Internal
Page 21
1.2.3.
The level of detail an RF system design can contain is dependant on the availability of
detailed input data and allotted design time and the number of resources available (e.g.
manpower, computer processes, etc.). The results of the detailed design should provide
the exact location of base sites, equipment configurations, and system coverage
performance.
Producing a detailed RF system design using Atoll requires the following steps:
1. Gather customer requirements for system performance and deployment
constraints.
2. Gather customer preferred or mandatory site locations list.
3. Define the system service area.
4. Gather Geographic input data files (Terrain, Land Use / Land Cover Data, aerial
photography) for the system along with Building and Road data files if available.
5. Use aerial photography to subdivide service area into geographic neighborhoods
(Suburban, Suburban-hills, Urban Tract Housing, Dense Urban High-Rise, etc.).
6. Run 3 to 4 sample RF propagation predictions using Atoll for a neighborhood
chosen in step 5 and determine an average cell radius for the area.
7. Create a Base Station (BS) placement grid for the area using Hexagons for 3
sector sites (the grid area is 2.6*R^2, where R is the average cell radius).
8. Position this grid to include as many preferred customers sites as possible.
9. Identify likely eNB locations within remaining unoccupied grid elements using a
search ring which is 25% or less of the grid element radius located in the center
of the grid.
10. Repeat steps 6 through 9 for each of the neighborhoods defined in step 5 making
sure the boundary between neighborhoods is properly covered.
11. Enter system/site parameters into Atoll.
12. Run coverage studies in Atoll.
13. Analyze coverage and interference results to determine if requirements are met.
If coverage and interference criteria are not met or locations exist where there
may be too much site coverage overlap, then identify the sites most closely
associated with the problem location.
14. Make adjustments to these associated sites by antenna adjustments, relocation,
or, if unavoidable, additional eNBs.
15. Re-run RF predictions for the area being adjusted to verify the effectiveness of
the changes.
16. Repeat steps 13 through 15 until all coverage and interference issues are
resolved.
Revision 1.3
iProtect: Internal
Page 22
17. If a coverage and interference solution does not result from this effort, consider
revisiting step 7 utilizing a different grid orientation.
18. Review design.
19. Produce report
Though not explicitly mentioned in the steps above, the propagation model that is used
to produce the predictions should be tuned prior to completing the design. The initial
predictions can be done with a more generic propagation model, but this model may not
properly address the specific characteristics of the given market. Refer to Sections 8.1
and 8.2 for further discussion on the propagation models and their tuning.
(See Figure 3: Detailed System Design Flow Chart (A))
Revision 1.3
iProtect: Internal
Page 23
Coverage
Requirements
Met?
Y
END
Revision 1.3
iProtect: Internal
Page 24
Antenna gain
Transmit power
Diversity gain
Noise Figure
Receiver Sensitivity
EIRP
Other
Lognormal Fading
Fast Fading
Interference margin
Building loss
Vehicle loss
Body loss
Target SNR
Revision 1.3
iProtect: Internal
Page 25
2.1. ML-CAT
ML-CAT is a spreadsheet application that automates the management of the RF link
budget. This stand alone tool estimates the site coverage given the equipment selected
and base site height and other user supplied settings.
The Atoll RF planning tool can be used to produce a more detailed design. It provides a
user interface that accepts similar link budget inputs as ML-CAT. However, it also
incorporates terrain and clutter information to provide a better prediction of coverage.
Additionally, it can account for interference and traffic load in its predictions. (Further
detailed discussion on using Atoll for designing LTE systems starts at Section 4 and
continues to the end of this document.)
ML-CAT enables the user to estimate the coverage of an LTE base site configured with
specific base site and subscriber equipment. This can be utilized for budgetary
estimates for a design scenario.
The information to be supplied by the user is entered through the User Interface tab of
the spread sheet (see Figure 5).
Revision 1.3
iProtect: Internal
Page 26
Revision 1.3
iProtect: Internal
Page 27
The user enters the relevant data into each sub-window. The results of the selections
are continually refreshed showing the impacts of different input selections. The link
budget results are based on a noise limited design; an interference (i.e. C/(I+N))
analysis is not performed.
For further information, refer to the ML-CAT User Guide document available at
http://compass.mot.com/go/310448858. The latest version of ML-CAT can also be
found at http://compass.mot.com/go/310448858.
Revision 1.3
iProtect: Internal
Page 28
Additional information concerning the factors that influence LTE capacity can be found
in the LTE RF Planning Guide (http://compass.mot.com/go/310442223).
Revision 1.3
iProtect: Internal
Page 29
4. Installing Atoll
The Atoll application runs on PC work stations under Windows 2000, XP, or Windows
2003 Server. The first two subsections below provide configuration requirements, as
well as installation and upgrade procedures. All information in these subsections is
taken from Atoll documentation.
The last subsection in this chapter provides information on how to access and install
Motorola-specific template information for use with Atoll. This template provides
configuration information that is specific to Motorola equipment.
Minimum
Recommended
Processor
RAM
512 MB
2 GB
More than 10 GB
(according to the geographic
database)
Graphics
Higher
Operating System
Additional Software
Ports
1 Parallel port (25 pins) or 1 USB port required to plug-in the license key
Installation
To install Atoll:
Then either:
Go to http://compass.mot.com/go/Atoll and
appropriate release from the Atoll Releases folder
download
the
Or:
Revision 1.3
iProtect: Internal
Page 30
Or:
By default, the Atoll installation directory path is C:\Program Files\Forsk\Atoll (or the last
directory in which the Atoll application was installed). To define another directory path,
edit directly the appropriate box during the installation.
Revision 1.3
iProtect: Internal
Page 31
Notes:
-
In some instances, the following error window may be seen during the installation
process:
Revision 1.3
iProtect: Internal
Page 32
If multiple licenses are not sharing processing power, this is not an issue. Click OK and
continue.
4.2.2.
Removing Atoll
Click the Windows Start button, point to Settings, and then click Control
Panel
In the Install/Uninstall tab, select Atoll in the list, and then click
Add/Remove
iProtect: Internal
Page 33
When a new Atoll project is started, it is based on a project template that has the data
and folder structure necessary for the technology being used. Once the new project is
started, the network parameters can be modified to meet the projects particular needs.
Note: Atoll allows for creating a project from a database which allows for several users
to share the same data while managing data consistency. This alternative configuration
can be explored in the Atoll User Manual under Working in a Multi-User Environment.
Several project templates are supplied with Atoll including one for LTE. LTE Planning &
Design has created a custom LTE project template which contains information specific
to Motorola radio equipment. It also contains radio data (bearer selection thresholds,
quality curves) based on development input. The project template is called
"LTE_MOTOv282" and its use will facilitate Motorola-specific system design work.
The steps for creating a new project are summarized as follows:
1. Pre-assemble required data for the project.
2. Create a new Atoll document from a template.
3. Configure the basic parameters.
4. Import required geographic data.
5. Activate autosave.
Each step will now be described in more detail.
5.1.1.1. Pre-assemble required data for the project
All data required for the project should be pre-assembled. Geographic (or geo) data
such as terrain, clutter, and roads should be available to use in the project. Sufficient
lead time is required to order the data from the geo data source provider. Also,
coordination with a server administrator may be required to have the data loaded in the
appropriate folders. Radio equipment and channel data is, to a significant degree,
already incorporated into the Motorola LTE project template, but non-default site
specific information should be readily available.
Revision 1.3
iProtect: Internal
Page 34
The process of creating a new Atoll document (i.e. project) from a template is very
simple.
1. Select File > New > From a Document Template. The Project
Templates dialog appears.
Figure 6: Project Templates
2. Select the template on which to base the document and click OK. Atoll
creates a new document based on the template selected.
Note: Select LTE_MOTOv282", the Motorola-specific LTE template.
5.1.1.3. Configure the basic parameters
Once a new Atoll document has been created, the basic parameters of the Atoll
document are configured. The default values for some parameters, such as basic
measurement units, may be accepted as is, but the projection and display coordinate
systems must be selected.
The Atoll map window is a flat rectangular view of the system under design. The
geographic data files describe a curved surface (the earth). Each data point of this
curved environment must be projected onto the flat display surface for processing and
viewing. Atoll enables the user to select the projection parameters for data processing
purposes and for viewing purposes.
Revision 1.3
iProtect: Internal
Page 35
Figure 7 shows the Options dialog box from which the coordinate systems and the
measurement units can be specified. It is accessible via Tools> Options. Browse
buttons () bring up a Coordinate Systems dialog box (Figure 8). Within this dialog
box, a catalog is selected from the Find In pull-down list. Then, a coordinate system
can be selected from the list that appears. For Projection, only cartographic coordinate
systems will be available for selection.
Revision 1.3
iProtect: Internal
Page 36
For Display, both cartographic and geographic coordinate systems are available for
selection.
For convenience, the display coordinate system defaults to the selected projection
coordinate system, but it can be selected to display a system different from the
projection coordinate system. Also, if a geographic coordinate system is selected for
Display, then the Degree Format field will be enabled within the Options window and
the user can select from one of four format options for displaying the coordinates.
Revision 1.3
iProtect: Internal
Page 37
NOTES:
-
The
icon next to a projection name identifies it as a Cartesian projection
and will result in the map window rulers displaying position in X-Y coordinates.
The
icon next to a projection name identifies it as a geographic projection
and will result in the map window rulers displaying position in Latitude and
Longitude.
All imported raster geographic files must use the same cartographic system.
For more information on coordinate systems, refer to the Atoll User Manual under
Projection and Display Coordinate Systems.
The Units tab within the Tools-Options window (Figure 10) allows the user to modify the
measurement units from their defaults.
Revision 1.3
iProtect: Internal
Page 38
The geographic data (terrain, clutter, roads, etc.) should be imported via File>Import.
Atoll supports a variety of both raster and vector file formats. When a new geo data file
is imported, Atoll recognizes the file format and suggests the appropriate folder on the
Geo tab of the Explorer window for placement. Geo data files can be embedded in the
Atoll document while importing them or subsequent to importing them. Refer to Section
6 for more detail on the subject of Geo data.
5.1.1.5. Activate Auto Backup.
When working with large projects, it is advisable to protect against the loss of work by
regularly saving the document. Atoll provides a basic autosave functionality which is
configured via File>Configure Auto Backup. Refer to Figure 11. When the Activate
Auto Backup check box is selected, the other two inputs become enabled. The time
between auto backups can be specified by one input and the other input is a checkbox
that permits the user to indicate whether or not they should be informed prior to Atoll
performing an auto backup.
Revision 1.3
iProtect: Internal
Page 39
5.1.2.
To save an Atoll project, simply invoke File>Save (or Ctrl+S). The Save interface is a
standard Windows interface. If the document has previously been named, the document
will save immediately. If it is the first time that the save has been invoked, then an
interface will appear that will allow for specifying the name and location of the
document. The suffix for the Atoll project file will be atl.
To open the existing document, invoke File>Open (or Ctrl+O) and select the file from
within the interface.
Atoll permits for saving the entire project as a single file by embedding the geo data
within the atl file. This can be accomplished by selecting the Embed in Document
check box in the File Import or Vector Import dialog. This represents a method for
sharing the project. The project can also be linked to external files. Note that externally
linked files can still be embedded by selecting Embed on the General tab of the
Properties dialog for the particular data file (right-click on file under Geo tab of Explorer
and select Properties).
NOTE: In general, embedding geographic, vector, or pathloss data is not
recommended as it typically produces a very large project file. Embedding data is
only for cases where the combined size of the data is relatively small (e.g. less
than 100 MB).
5.1.3.
The project archive function is used for storing a complete project. This allows the
project information to be easily ported or shared. This function will create a zip file that
will contain the project ATL file, the pathloss files and all external GIS files.
The Project Archive can be found at Atoll > File > Add to Archive
Revision 1.3
iProtect: Internal
Page 40
*.ATL
\PATHLOSS
\GEO
Elevation File
Clutter Classes
Clutter Height
Image Files
Vector Files
If there is a large GIS data file (land use or elevation), some of the data files may need
to be removed so that the zip file is not too large.
If only a portion of the entire project area needs to be shared, the extents of the GIS
data files can be reduced by doing the following
Right click within the map display window and select Save As
Revision 1.3
iProtect: Internal
Page 41
The Save As window will pop up. Select Vertical Mapper Files (*.grd,
*.grc) from the Save as type pull-down list (as seen in the figure
below). Enter the desired file name for the saved data and click on
Save.
Another window will appear. Select the appropriate region to save (i.e.
The Computation Zone would be selected to only save the data
within the Computation Zone). Select the appropriate resolution of the
data and then click OK.
Figure 13: Save As Settings for Saving GIS Data within a Computation Zone
Revision 1.3
Once both the elevation and clutter class files have been saved, the
larger GIS elevation and clutter files need to be replaced with the
newly created smaller elevation and clutter class files that are within
the computational zone. This is done by modifying the Project Archive
File *.zip.
iProtect: Internal
Page 42
5.2.1.
A single base station can be created leveraging the station template and positioned via
the map as follows:
1. In the Radio toolbar, select a template from the list. In Figure 14, the drop-down
menu for base station templates is shown. Note the presence of various
Motorola products labeled by product name, band, channel bandwidth, and
number of sectors.
2. Click the New Base Station button (
3. In the map window, move the pointer over the map to where the new station is to
be placed. The exact coordinates of the pointers current location are visible in
the Status bar.
4. Click to place the station. The base station will appear within the map and its
objects (site, transmitters, and cells) will also be created and placed into their
respective folders in the Explorer window.
Revision 1.3
iProtect: Internal
Page 43
With the pointer resting over the base station, Atoll displays a tool tip with the base
stations exact coordinates, allowing the user to verify that the location is correct (refer
to Figure 15). To place the base station more accurately, zoom in (use Ctrl+A or
)
on the map prior to placing the new station or moving an already placed station (see
Section 5.2.5). Alternatively, a base station can be placed more accurately by opening
the Site properties window for the particular site and typing the exact coordinates into
the General tab.
Figure 15: Site 12 Positioned via Map
5.2.2.
Placing Multiple Base Stations Using a Station Template via the Map
A series of base stations can also be placed using a station template. This is done by
defining an area on the map to place the base stations. Atoll calculates the placement of
each base station according to the defined hexagonal cell radius in the station template.
To place a series of base stations within a defined area:
1. In the Radio toolbar, select a template from the list.
2. Click the Hexagonal Design button (
), to the left of the template list. A
hexagonal design is a group of base stations created from the same station
template.
Revision 1.3
iProtect: Internal
Page 44
Note: Sites produced using the Hexagonal Design button as, described above,
will all be associated with a newly created hexagon group (e.g. Group 1 in
Figure 17). For more information on the benefits of hexagonal design refer to
Section 5.2.3.
3. Using the mouse, draw a zone (polygon) delimiting the area in which to place the
series of base stations.
Atoll fills the delimited zone with new base stations and their hexagonal shapes. Base
station objects such as sites and transmitters are also created and placed into their
respective folders in the Explorer window.
5.2.3.
Hexagonal Design
As stated in the previous section, Atoll can produce a group of base stations which are
uniformly distributed per a hexagonal grid layout. This can serve as the basis for a
study based on a uniform distribution of sites or, alternatively, it can serve as the
starting place for a real system design.
The hexagonal radius used to create the layout is specified within the base station
template and can be modified by the user prior to employing the template for base
station creation. It should be noted that the hexagonal radius employed within Atoll
refers to a hexagon used to represent the coverage area of a single sector (i.e.
transmitter) and, thus, is different from the usage employed within Motorola where the
hexagon is used to represent site coverage. Consequently, some conversion will be
required. If Rsector is used to represent the Atoll sector hexagonal radius and Rsite is
used to represent the Motorola site hexagonal radius, then the following are true:
Rsite = 3 Rsector
DISTANCEsite to site = 3 Rsector = 3 Rsite
Revision 1.3
iProtect: Internal
Page 45
Rsite
DISTANCE site-to-site
Rsector
The tilt of the hexagonal grid layout is controlled by the first sector azimuth of the base
station template employed. Refer to Section 5.2.8 on Managing Station Templates to
learn how to modify the station templates.
Figure 17: Hexagon Group of Sites
In addition to the benefit associated with being able to lay out a grid of 3-sector sites,
another benefit of hexagonal design is that the sites produced will all be associated with
a newly created hexagon group (e.g. Group 1 in Figure 17). Whenever a hexagon
groups check box is checked under Hexagon Design, then its sectors will all display
their hexagons. The hexagon group can be selected via the map which can facilitate
repositioning the entire group, if desired. Individual base stations can be modified (e.g.
having position or bearing changed) and still remain a member of the same hexagon
group.
5.2.4.
If the project is large and data already exists, then this data can be imported into the
current Atoll document to create a group of base stations.
Revision 1.3
iProtect: Internal
Page 46
NOTE:
When data is imported, the coordinate system of the imported data must match the
display coordinate system used in the document. If the coordinate system of the
source data cannot be changed, the display coordinate system of the Atoll document
can be temporarily changed to match the source data.
Base station data can be imported in the following ways:
Copying and pasting data: If base station data is available in table form, either in
another Atoll document or in a spreadsheet, a copy-paste into the data tables of
the current Atoll document can be performed.
Important: The source and destination of the copy-paste must have the same
dimensions and column order.
Whether data is brought in via copy-paste or import, site data must be entered
into the Sites table, transmitter data into the Transmitters table, and cell data into
the Cells table, in that order.
To facilitate importing data, it may be efficient to create an external database that
leverages the base station template. The first step is to create a base station or base
stations using the template of interest. Then, export the site, transmitter, and cell
databases. These files can be imported into Excel and used as the basis for forming a
custom database that can be imported back into Atoll.
If only site locations need to be customized, then it may be most efficient to first create a
group of base stations using the base station template. Then, the locations can be
modified either by copy-pasting or importing new position information into the sites table
overriding the existing information. The benefit of this approach is that there is no need
to bother with transmitter or cell data tables. The site names must be identical to those
of the created sites for the import to work. For the copy-paste to work, the order of the
source must match the order of the site data table.
5.2.5.
Moving Sites
A site can be moved by editing the coordinates on the General tab of the Site Properties
dialog, or by using the mouse.
To move a site using the mouse:
1. Click and drag the site to the desired position. As the site is dragged, the exact
coordinates of the pointers current location are visible in the Status bar.
Revision 1.3
iProtect: Internal
Page 47
2. Release the site to place it. By default, Atoll locks the position of a site. When the
position of a site is locked, Atoll asks the user to confirm the move.
3. Click Yes to confirm.
While the mouse method allows the user to place a site quickly, the location can be
adjusted more precisely by editing the coordinates on the General tab of the Site
Properties dialog.
If a group of sites needs to be moved and the sites all belong to the same hexagon
group, then re-positioning them is as simple as moving a single site. With the hexagon
group checkbox selected, the hexagon group is selected within the map and dragged to
its new location. More precise positioning can be obtained via the database (e.g.
copying the locations out to Excel, adjusting them appropriately, and pasting them back
in).
To improve the location of a site, in terms of reception and transmission, Atoll can find a
higher location within a specified radius from the current location of the site.
To have Atoll move a site to a higher location:
1.
Right-click the site in the map window. The context menu appears.
2.
3.
In the Move to a Higher Location dialog, enter the radius of the area in
which Atoll should search and click OK. Atoll moves the site to the highest
point within the specified radius.
Note: A site which is part of a hexagon group will still remain part of the
group after being moved to a higher location.
5.2.6.
Deleting Sites
Sites, with all associated transmitters and cells, can be deleted from either the Explorer
window or the map.
To delete a site:
1.
Right-click the site either in the Explorer window or on the map. The
context menu appears.
2.
Select Delete from the context menu. The selected site is deleted.
Note that when a site is selected from the Explorer window, it can also be deleted by
hitting the delete key. If the delete key is held down during this process, it quickly
deletes the selected site and all sites listed below it in the Explorer window.
Deleting all the sites of a hexagon group is accomplished by selecting the hexagon
group via the map (hexagon group check box must be enabled) and then performing
Right-click>Delete.
Sites can be deleted from within the sites data table by first double-clicking on the Sites
folder. Within the Sites data table, the user can select a single site by clicking to the left
of the desired site name. Multiple sites can also be selected. If the sites are adjacent
within the table, they can be selected similar to the single site by first clicking on one
Revision 1.3
iProtect: Internal
Page 48
site and then dragging the cursor to include all of the desired sites. If the desired sites
are not adjacent within the table, then the user can select the sites using the controlclick functionality. Once the site or sites are selected, they can be deleted by clicking
the Delete key on the keyboard.
Multiple methods exist for looking at subsets of a data file (e.g. sorting, group by,
filtering, lists). For example, by right-clicking on the Sites folder, a user can select Filter
Inside a Polygon>Draw and then draw a polygon around the sites to be deleted (which
can be a very irregular shape). Double-clicking on the Sites folder would now bring up
only those sites, after which using Ctrl-A (select all) and then hitting the Delete key
would discard them all. Select Remove the Polygon Filter (by right-clicking on the
Sites folder) to return to the normal view.
5.2.7.
Display Hints
Atoll allows the user to display information about base stations in a number of ways.
This enables the user not only to display selected information, but also to distinguish
base stations at a glance.
The following tools can be used to display information about base stations:
Label: Information can be displayed about each object, such as each site or
transmitter, in the form of a label that is displayed with the object. The label is
always displayed.
Tooltips: Information about each object, such as each site or transmitter, can be
displayed in the form of a tooltip that is only visible when the pointer is placed
over the object.
Transmitter color: The transmitter color can be set to display information about
the transmitter.
For information on defining labels, tooltips, colors, and symbols, refer to Display
Properties of Objects in the Atoll User Manual.
5.2.8.
Users may modify existing station templates or create new ones. When a new station
template is created, Atoll bases it on the station template selected in the Station
Template Properties dialog. The new station template starts with the same parameters
as the one it is based on. Therefore, by selecting the existing station template that most
closely resembles the station template to be created, only the parameters that differ
need to be modified. Station template changes/modifications described here only apply
to the active project (i.e. are saved into the projects atl file). For the new set of station
templates, reflecting the changes/modifications, to be accessible to other new projects,
they need to be saved as part of a new project template (refer to Section 4.3).
To create or modify a station template:
Revision 1.3
iProtect: Internal
Page 49
1.
In the Radio toolbar, click the arrow to the right of the Station Template
list.
2.
Select Manage Templates from the list. The Station Template Properties
dialog appears.
3.
4.
5.
Revision 1.3
When finished with setting the parameters for the station template, click
OK to close the dialog and save the changes.
iProtect: Internal
Page 50
Alternatively, the Base Station Template parameters can also be modified (added,
deleted, or changed) through the Station Template table. This table can be accessed
through the Data tab by right-clicking on the Transmitters folder then selecting Network
Settings and then Station Templates, as seen in the figure below. Further information
regarding the Station Template table can be found in Section 7.2.2.5.
Revision 1.3
iProtect: Internal
Page 51
Revision 1.3
iProtect: Internal
Page 52
Terrain Data
Building Data
Road Data
The terrain and land use/land cover data are used within the propagation modeling. The
proper mapping projection must be used with the geographic data. The projection
describes how the data samples (taken from the curvature of the earth) are to be
projected onto the flat map window of Atoll. This topic is covered in Section 5.1.1.
Studies can be run using only terrain and land use / land cover (LULC, a.k.a. Clutter)
data. The building data and road data can be used as visual location reference aids in
displaying Atoll predictions.
NOTE: Geographic data needs to be brought into a project before placing sites.
Please see Section 5.2 for further information regarding site placement.
Antenna pattern data is also discussed in this section. It is not connected to the
geography of the service area, but needs to be present for a propagation run. It
provides information concerning the horizontal and vertical patterns of the specific
antenna.
Atoll is able to work with several different formats of geographic data. The process of
importing these databases is similar (and sometimes less involved) to importing NetPlan
formatted data. The following subsections describe the process used for working with
NetPlan formatted geographic data.
In addition to the NetPlan / Planet data format, the following terrain and clutter files are
also supported within Atoll:
GeoTiff (*.tif)
Vertical Mapper (*.grd for terrain files and *.grc for clutter files)
Revision 1.3
iProtect: Internal
Page 53
Navigate the directories and select the file named index located in the directory where
the NetPlan terrain/elevation data is stored for the current document.
NOTE: NetPlan formatted data that is used in Hydra uses a file name of d_index for
the terrain file and l_index for the clutter file. If this data is to be used in Atoll, both of
these files need to be renamed to just index. This also requires that the files be put
into two different directories, a terrain directory and a clutter directory, since the two files
will now have identical names.
Click the Open button. This will open the Data Types window.
Revision 1.3
iProtect: Internal
Page 54
Click on the Altitudes button and click OK. Atoll will load the terrain data and place an
entry in the Explorer window under the Geo tab named Digital Terrain Model.
Figure 22: Digital Terrain Model
The terrain image will be displayed in the map window once the terrain data has been
successfully imported.
Revision 1.3
iProtect: Internal
Page 55
Expanding the Digital Terrain Model folder within the Explorer window displays the
individual digital terrain files included in the terrain index file. The precedence of which
digital terrain file is used when two or more terrain files overlap in areas is a function of
the order in which they appear under the Digital Terrain Model label. The files listed
higher on the list take precedence over those further down the list. Dragging and
dropping a listed file to a different location within this list is the method of changing the
data files precedence status for the document.
Right clicking on the Digital Terrain Model label and selecting properties opens the
Digital Terrain Model Properties window.
Revision 1.3
iProtect: Internal
Page 56
The shading, colors and transparencies of the terrain image are adjusted using this
window. Refer to the Atoll User Manual for more information on how to modify the
display properties of objects.
Clutter Classes
Clutter Classes define what type of land cover (building, forest, water, etc.) is present
over a given location. From the main tool bar, select File > Import. This opens up the
Open window.
Navigate the directories and select the file named index located in the directory where
the NetPlan LULC/Clutter data is stored for the current document.
NOTE: NetPlan formatted data that is used in Hydra uses a file name of d_index for
the terrain file and l_index for the clutter file. If this data is to be used in Atoll, both of
these files need to be renamed to just index. This also requires that the files be put
into two different directories, a terrain directory and a clutter directory, since the two files
Revision 1.3
iProtect: Internal
Page 57
will now have identical names. Additionally, there is a clutter_menu.txt file that is used
with Hydra NetPlan data. This file needs to be renamed to menu and placed in the
same directory as the clutter index file to be used within Atoll.
Click the Open button. This will open the Data Types window.
Figure 25: Data Types
Click on the Clutter Classes button and click OK. Atoll will load the clutter data and
place an entry in the Explorer window under the Geo tab named Clutter Classes.
Figure 26: Clutter Classes
The Clutter Classes image will be displayed in the map window once the clutter data
has been successfully imported. Each unique clutter designation is assigned a random
color. These colors can be adjusted by the user.
Revision 1.3
iProtect: Internal
Page 58
Expanding the Clutter Classes label within the Explorer window displays the individual
clutter files included in the clutter index file. The precedence of which digital clutter file
is used when two or more clutter files overlap in areas is a function of the order in which
they appear under the Clutter Classes label. The files listed higher on the list take
precedence over those further down the list. Dragging and dropping a listed file to a
different location within this list is the method of changing the data files precedence
status for the document.
Right clicking on the Clutter Classes label and selecting properties opens the Clutter
Classes Properties window.
Revision 1.3
iProtect: Internal
Page 59
The shading, colors and transparencies of the clutter class image are adjusted using
this window.
6.2.2.
Clutter Heights
Clutter heights are typically defined as an average value per clutter class in the Clutter
Classes properties interface as shown in Figure 29. Please see Section 8.1.3 for details
regarding clutter heights that should be used with the recommended propagation
models. (Further information regarding Clutter Classes properties can be found in
Section 7.4.)
Revision 1.3
iProtect: Internal
Page 60
Alternatively, if a clutter height file is available, then the height of land cover present
over a given location can be defined by the Clutter Heights data. The steps for importing
the clutter heights data is much the same as for importing the cutter classes.
From the main tool bar, select File > Import. This opens up the Open window.
Navigate the directories and select the file named index located in the directory where
the NetPlan LULC/Clutter data is stored for the current document.
Click the Open button to open the Data Types window.
Revision 1.3
iProtect: Internal
Page 61
Click on the Clutter Heights button and click OK. Atoll will load the clutter height data
and place an entry in the Explorer window under the Geo tab named Clutter Heights.
The Clutter Heights image will be displayed in the map window once the clutter data has
been successfully imported.
Revision 1.3
iProtect: Internal
Page 62
Expanding the Clutter Heights label within the Explorer window displays the individual
clutter files included in the clutter index file. The precedence of which digital clutter file
is used when two or more clutter files overlap in areas is a function of the order in which
they appear under the Clutter Heights label. The files listed higher on the list take
precedence over those further down the list. Dragging and dropping a listed file to a
different location within this list is the method of changing the data files precedence
status for the document.
Right clicking on the Clutter Heights label and selecting properties opens the Clutter
Heights Properties window
Revision 1.3
iProtect: Internal
Page 63
The shading colors and transparencies of the clutter height image are adjusted using
this window.
Road Data
Road data are vector files which represent the highways, streets, and roads for the Atoll
document. From the main tool bar, select File > Import. This opens up the Open
window.
Navigate the directories and select the road data file. Only the road data file with the
suffix (.shp) will appear on the menu. All the files associated with this shapefile will be
imported.
Click the Open button. This will open the Vector Import window.
Revision 1.3
iProtect: Internal
Page 64
Verify that the Coordinate System settings used for the document are represented in the
two boxes or make the appropriate adjustments in these boxes to match the projection
used for the document. Click the Import button when these settings are correct. Atoll
will load the road data and place an entry in the Explorer window under the Geo tab with
the name of the shape file used.
The Road data image will be displayed in the map window once the road data has been
successfully imported.
Revision 1.3
iProtect: Internal
Page 65
Right clicking on the Road data label and selecting properties opens the Road data
Properties window. The weighting of the road lines can be adjusted using this window.
6.3.2.
Building data
Building data are vector files which represent outlines and heights of buildings for the
Atoll document. From the main tool bar, select File > Import. This opens up the Open
window.
Revision 1.3
iProtect: Internal
Page 66
Navigate the directories and select the building data file. Only the building data file with
the suffix (.shp) will appear on the menu. All the files associated with this shapefile will
be imported.
Click the Open button. This will open the Vector Import window.
Figure 37: Vector Import
Verify that the Coordinate System settings used for the document are represented in the
two boxes to match the projection used for the document. Click the Import button
when these settings are correct. Atoll will load the building data and place an entry in
the Explorer window under the Geo tab with the name of the shape file used.
Revision 1.3
iProtect: Internal
Page 67
The Building data image will be displayed in the map window once the building data has
been successfully imported.
Revision 1.3
iProtect: Internal
Page 68
Right clicking on the building data label and selecting properties opens the Building
data Properties window.
Revision 1.3
iProtect: Internal
Page 69
The shading colors and transparencies of the building data image are adjusted using
this window.
iProtect: Internal
Page 70
placement restrictions that are important when using these index, MapProjectionFile
and Menu files within Atoll.
NetPlan formatted data can also be provided in the form of a binary file (*.bil) and a
header file (*.hdr). The header and binary file can be imported directly into Atoll (please
see Sections 6.1 and 6.2 for further details). However, sometimes the header file cannot
be interpreted correctly. If this is the case, then an index file can be created from the
header file. Please see Section 6.4.2 for details on how to create an index file from a
header file.
6.4.1.
Files named index and MapProjectionFile are provided along with NetPlan formatted
terrain data. These two files must have these names and must reside in the same
directory as the terrain data. Similarly, files with the same names (index and
MapProjectionFile) are provided along with NetPlan formatted clutter data. These two
files (along with a third file named menu) must have these names and must reside in
the same directory as the clutter data.
NetPlan formatted raster data for terrain and clutter data must be placed in separate
directories because the index files for the terrain and clutter hold different information
yet have identical names. The individual binary terrain and clutter data files are not
restricted in naming convention.
The index file is an ASCII file that contains a list of all terrain/clutter data files for the
Atoll document along with the Cartesian coordinates within each file.
Figure 41: index file
l_mexico_mwz.bin
Revision 1.3
iProtect: Internal
Page 71
The menu file is an ASCII file that contains clutter codes and names for the NetPlan
binary clutter data.
Figure 43: menu File Example
1 Dense Urban-Commercial
2 Urban-High Density
3 Urban-Low Density
4 Suburban-High-Density-Residential
5 Suburban-Low-Density-Residential
6 Suburban-Dense Vegetation
7 Industrial-Low-Density
13 Inland Water
16 Quasi-open/roads/barren
18 Forest
19 Low-trees/Low-density_woodland
20 Agriculture/Rangeland/Grasses
21 Village
6.4.2.
In cases where the header file cannot be interpreted by Atoll, an index file can be
created from the header file information and the index file can be used instead. The
following provides details on how to create an index file from a header (*.hdr) file.
Revision 1.3
iProtect: Internal
Page 72
As shown in Figure 41, the index file is made up of 6 items that are space delimited.
The information in this file helps define the projection of the binary map file. The layout
of the 6 items of information within the index file is shown in the figure below.
The following image provides an example of a binary map file layout. The reference grid
shows how the information within the index file relates to the map file.
Pixel Size
The information from the header file can be used to determine the proper settings to
create an index file. The following figure contains an example of data from a header
file.
Revision 1.3
iProtect: Internal
Page 73
ULXMAP 459002.500000
ULYMAP 4442997.500000
XDIM 5.000000
YDIM 5.000000
BYTEORDER M
LAYOUT BIL
NROWS 8200
NCOLS 8800
NBANDS 1
NBITS 16
Where:
ULXMAP = upper left X map location, which equates to the minimum X value
ULYMAP = upper left Y map location, which equates to the maximum Y value
XDIM = resolution or pixel dimension in the X direction
YDIM = resolution or pixel dimension in the Y direction
NROWS = number of rows (or Y entries) within the map file
NCOLS = number of columns (or X entries) within the map file
NBITS = number of bits; It is important that this value be 16 for use in Atoll
As shown in the information above, the header file contains some of the information
needed in the index file: the Xmin value (i.e. ULXMAP), the Ymax value (i.e.
ULYMAP), and the PixelSize (XDIM or YDIM, since these are both the same).
The remaining two values that are needed within the index file, the Xmax and the
Ymin values (which define the lower right corner of the map), can be calculated using
the information from the header file.
To calculate the Xmax value (lower right X map location), use the following formula:
LRXMAP = ULXMAP + ( NCOLS * XDIM)
Using the header information shown above, this value would be calculated as:
LRXMAP = 459002.500000 + ( 8800 * 5)
LRLXMAP = 503002.5
Revision 1.3
iProtect: Internal
Page 74
To calculate the Ymin value (lower right Y map location), use the following formula:
LRYMAP = ULYMAP - ( NROWS * YDIM)
Using the header information shown above, this value would be calculated as:
LRYMAP = 4442997.500000 - ( 8200* 5)
LRYMAP = 4401997.5
Once these values have been calculated, the index file can be created. This is done
by creating a text file named index. Within this file is a single line consisting of the
following data:
BinaryFileName.bil Xmin Xmax Ymin Ymax PixelSize
Using the information from the above header file, the index file should look like the
following:
BinaryMapFile.bil 459002.5 503002.5 4401997.5 4442997.5 5
Where BinaryMapFile.bil would be replaced by the name of the specific file
(*.bil) that contains the binary map data.
iProtect: Internal
Page 75
shapefile (.shp) format and include fields describing each buildings perimeter, base
height and building height.
Vector shapefiles depicting detailed state & county boundaries and highways for the
United States, and similar data for Canada & Mexico can also be provided by the
Motorola GDS organization.
A wide variety of shapefile data is available on the Internet, either for free or for a
nominal charge. A starting point is ESRI's web site, Census 2000 TIGER/Line Data (free
download only in the United States). Internet search engines can locate sources using
search keywords such as shapefile" & your location. Mapping data in other GIS formats
(for example, ArcInfo *.e00 files, MapInfo *.MIF files, AutoCAD *.DXF or *.DWG files,
etc.) can also be found using an Internet search. Freeware and commercial GIS file
translators exist that generate shapefiles from most formats. Contact GDS for advice
(http://gds.mot.com or maps@motorola.com).
Revision 1.3
iProtect: Internal
Page 76
To view the antenna data for a given antenna model, right click on the antenna label
and select the Properties option. This opens the antenna properties window.
Figure 48: Antennas properties
Revision 1.3
iProtect: Internal
Page 77
6.6.1.
BTS Antennas
The base station antenna names listed in Figure 47 depict the horizontal beam width,
antenna gain referred to an isotropic source, and frequency of operation. Antenna
patterns for Smart Antenna have not been defined as of the release of this document
The antennas used with the various base stations are ordered as ancillary equipment
and not included with the FNE equipment package. The system designer must make
sure that appropriate antennas are selected for the deployment design goals. The
parameters would include the number of antennas encapsulated within the panel (ports)
to support the number of transmit and receive antennas needed by the base site, the
frequency of operation, the gain of the antenna, the horizontal Beamwidth, the front to
back ratio (isolation), the vertical beam width and any fixed electrical downtilting
required. Once the antenna is chosen, its pattern data must be entered as a new
antenna into the Atoll project (see section 6.6.3)
6.6.2.
Subscriber Antennas
The last two antennas listed in Figure 47 are for use with the subscriber devices.
MS Antenna 0 dBi
The names of these antenna selections match the two categories of subscriber devices,
with suffix for the CPE antenna indicating the antenna gain. For some CPEs, the
antenna gain may vary depending upon the frequency of operation and model.
It is also important to note that the effective gain of the antenna at the CPE device may
be less than the antenna gain specification due to the placement of the CPE in a nonline-of-sight scattering environment and non-optimal orientation of the device. Section
7.3.1 provides further discussion on adjustments that should be made to address the
CPE antenna gain correction factor and orientation loss.
To edit the subscriber antenna gain for a given antenna model, right click on the
antenna label and select the Properties option. This opens the antenna properties
window as seen in the figure below.
Revision 1.3
iProtect: Internal
Page 78
Enter the appropriate antenna gain into the Gain field. If the CPE is located in a nonline-of-sight scattering environment or has a non-optimal device orientation, then the
antenna gain may need to be reduced by the antenna gain correction factor and
orientation loss depending on whether the engineer desires to account for these
adjustments as described in Section 7.3.1. It is recommended that the user enter
comments to document the gain selection to avoid future confusion. Click OK to apply
this gain value.
6.6.3.
New Antennas
Antennas can be created from Tabular data or imported from an antenna pattern that is
in Planet format. It is important to note that when an antenna is imported or created, the
antenna pattern is stored with the ATL file. If a new project is created from the Motorola
Template, the antenna will have to be imported again if it is desired to use this pattern
within the new project.
6.6.3.1. Creating Antenna Pattern
The following steps describe how to create a new antenna pattern for a project.
Click on the Data tab; then Right click on the Antennas folder.
This will bring up a pop up window. Select New to open the Antenna Properties
window, as seen in Figure 49.
Within the General tab of the Antenna Properties window, enter information into the
following fields:
Revision 1.3
iProtect: Internal
Page 79
Name
Manufacturer
Gain
Within the Horizontal Pattern and Vertical Pattern tabs, Atoll allows horizontal and
vertical pattern attenuations (respectively) to be entered for as many as 720 angles.
Attenuation values can also be defined for angles other than integer values from 0 to
359. If the horizontal and vertical pattern data is in spreadsheet or text documents, the
data can be copied directly from the source files into the Atoll horizontal or vertical
pattern tables.
Within the Other Properties tab, the user can define the beamwidth and frequency
range for the antenna, as well as other antenna parameters. These fields are used for
filtering and not used in any calculations. The following is a list of the antenna
information that can be defined in this tab:
Beamwidth
TILT
Atoll checks whether the vertical and horizontal patterns are correctly aligned at the
extremities. The antenna patterns are correctly aligned when:
Atoll can import Planet formatted antenna patterns. The following steps describe how to
do this.
Click on the Data tab; then Right click on the Antennas folder.
This will bring up a pop up window. Select Import to bring up the Open interface.
Revision 1.3
iProtect: Internal
Page 80
From within the Open interface, select Planet 2D Antenna Files (index) from the
Files of type drop-down menu.
In the File name field, select the index file from the directory that contains the Planet
formatted antenna patterns and then click Open. The antenna patterns will be
imported and made available in the Antennas window.
Atoll checks whether the vertical and horizontal patterns are correctly aligned at the
extremities. The antenna patterns are correctly aligned when:
Revision 1.3
iProtect: Internal
Page 81
Sites
The site information defines the geographic location of the site. The site parameters can
be found in the Sites Properties dialog window (i.e. by right clicking on a Site and
selecting Properties).
There are three tabs within the Site Properties window: General, Pylon (used with
microwave studies and will not be discussed further in this document), and Display.
The following figure shows an example of the parameters within the General tab.
Revision 1.3
iProtect: Internal
Page 82
1
3
NOTES:
Note. 1.
Atoll automatically enters a default name for each new site. This Name
field allows the user to change the name, if desired. (If it is desired to
change the default name that Atoll gives to new sites, please see the Atoll
Administrator Manual.)
Note. 2.
The Position field provides the X and Y coordinates for the site. (The
example figure above shows the longitude and the latitude of the site.)
Note. 3.
The Altitude field is composed of a Real and a DTM setting. The altitude of
the site (i.e. the elevation at the base of the site, not the height of the
antennas), as defined by the Digital Terrain Map, is given as the DTM
setting. If desired, the user can define another altitude under the Real
setting. If the Real setting has a specified altitude, then Atoll will use this
value for calculations. It is recommended to use the DTM setting for this
field.
Note. 4.
The Comments text box allows the user to enter comments regarding this
site, if desired.
The following figure shows an example of the parameters that can be set within the
Display tab of the Site Properties window.
Revision 1.3
iProtect: Internal
Page 83
2
3
NOTES:
Note. 1. The Symbol Style allows the user to modify the style of the symbol that is
used to represent the site in the display.
Note. 2. The Display Name with Style checkbox allows the user control over
whether or not to display the site name. If the checkbox is selected, the
name will appear in the display. The AaBbYyZz box allows the user to
modify the font and style that is used when displaying the Site name in the
display.
Note. 3. The Display Radial Grid checkbox allows the user control over whether
they wish to display a radial grid around the site. If this checkbox is
selected, a radial grid will appear around the selected site. The
Parameters option allows the user to define the number of radials and
circles that will appear in the radial grid. This is done by defining the
maximum radius for the grid, the spacing between the circles, and the
angle between the radials. This feature can be used in conjunction with a
coverage image to get a quick distance estimate of the coverage range
around a site.
Revision 1.3
iProtect: Internal
Page 84
7.1.2.
Transmitters
The Transmitters Properties windows define the specific parameters for each sector
(e.g. power levels, gains, losses, antenna parameters, etc.). These parameters can be
found in the Transmitters Properties dialog windows or in the Transmitters Table
(Transmitters Open Table).
7.1.2.1. Entering Transmitter Data
The Transmitter Properties dialog window can be found from the Data tab by rightclicking on a Transmitter and selecting Properties, as shown in the next figure.
Figure 52: Accessing Transmitter Sector Properties
The General tab in the Transmitter Properties window provides information regarding
the name and location of a sector relative to the associated site.
Revision 1.3
iProtect: Internal
Page 85
1
2
3
4
NOTES:
Note. 1. The Name of the transmitter (sector) is automatically assigned by Atoll.
This field allows the user to enter a different name for the transmitter.
However, for the sake of consistency, it is recommended to let Atoll assign
the name. (If it is desired to change the default name that Atoll gives to
new transmitters, please see the Atoll Administrator Manual.)
Note. 2. The Site parameter indicates the site with which this transmitter is
associated. The button to the right of this field allows the user to
access the properties of the site on which the transmitter is located.
Note. 3. The Position relative to the site field allows the user to modify the
transmitters location relative to the site, if desired. For example, if a site is
located on a rooftop and it is desired to locate one of the sector antennas
on the opposite side of the roof from the other antennas, this parameter
can be used to position the antenna. However, it is generally easier to
position the antennas relative to the site by dragging and dropping them in
the map display, rather than entering X-Y offsets into these fields.
Note. 4. The Comments text box allows one to enter comments regarding this
transmitter, if desired.
Revision 1.3
iProtect: Internal
Page 86
7.1.2.1.2.
The Transmitter tab within the Transmitter Properties window provides information
regarding transmission/reception gains and losses, as well as providing information
regarding the antennas that are associated with this transmitter.
If the Motorola base station templates are used to create sites, then many of these
parameters are set automatically. However, these parameters need to be reviewed to
make sure that the settings are appropriate for the given market. For example, the
default settings for parameters such as the antenna height, azimuth, and downtilt may
not be appropriate for a specific transmitter and will need to be modified.
3
4
6
7
9
8
10
11
12
NOTES:
Revision 1.3
iProtect: Internal
Page 87
Note. 1. The Active checkbox allows the user to select whether this transmitter will
be considered active. Only active transmitters are taken into consideration
during calculations. (Please note that the checkboxes in the Explorer
window next to each site/sector do not affect what sites are included in a
prediction study. The checkboxes only affect what sites are displayed in
the Atoll workspace.)
Note. 2. The Transmitter Type field allows the user to define how the transmitter
will be modeled by selecting between two types: Intra-network (Server
and Interferer) or Extra-network (Interferer Only). If the transmitter is
defined as an Intra-network (Server and Interferer), the transmitter will be
modeled as both a transmitting and interfering source. However, if the
transmitter is defined as an Extra-network (Interferer Only), it will only be
modeled as an interfering source, not a server. This feature allows the
user to model the impact of neighboring networks by including these sites
as interferers but not sources within a design.
Note. 3. The Total losses (Real) field allows the user to enter the total transmission
loss or total reception loss for the eNB. This field would include losses
such as transmission line loss, connector losses, filter losses, etc.
The Motorola base station template sets this value to 0.5 dB for the
Remote Radio Head eNB. The Motorola template for Frame Based eNB
products include a 3 dB loss setting. This value needs to be adjusted to
correspond to the actual line and connector loss for the sector, so it is
likely that it will need to be modified to something other than 3 dB for
Frame Based and 0.5 dB for RRH.
Note. 4. The BTS Noise Figure (Real) field allows the user to enter the noise figure
value associated with the given BTS. The Motorola eNB templates have
this set to 4 dB, which is the typical noise figure for Motorola eNB
products.
Note. 5. The Transmission/Reception portion of the window allows the user to
enter or have the tool calculate the Total losses and BTS Noise Figure
associated with the sector. The Equipment and Details buttons are used if
the tool is to calculate these values. The Equipment button allows the user
to enter the relevant information regarding the site equipment (e.g.
transmission line equipment). It then uses this information to calculate the
associated losses and noise figure information, which are then displayed
as the Computed values for the Total losses and BTS Noise Figure. The
Details button then displays the calculation for the total uplink loss.
The Motorola base station templates do not use these detailed equipment
input windows to calculate the Total losses or BTS Noise Figure.
Note. 6.
Revision 1.3
Page 88
If a Motorola base station template was used to place the site within the
system, please note that this template uses a default of 30 m for the base
station antenna heights. This value needs to be reviewed and modified as
necessary for the particular market being designed.
Note. 7. The Main Antenna portion of the Transmitter tab dialog window allows the
user to define the Model, the Azimuth, the Mechanical Downtilt and
Additional Electrical Downtilt parameters associated with the main
antenna.
The Model is selected from a pull-down list. The button allows the
user to access the properties of a given antenna, as seen in the following
figure.
If the Motorola base station template is used within Atoll, then a generic
antenna model is provided based on the selected site configuration. This
generic antenna pattern should be replaced with the actual antenna
pattern that is planned for use in the system deployment. Refer to Section
6.6.3 for information on creating new antenna patterns in Atoll.
Revision 1.3
iProtect: Internal
Page 89
Note. 8. The Azimuth field allows the user to set the orientation of antenna. The
Motorola base station templates assume a sector orientation of 90, 210,
and 330 degrees for 3-sector sites.
Note. 9. The Mechanical Downtilt and Additional Electrical Downtilt fields allow the
user to define any downtilting that is required for the antenna. These
downtilt parameters that are defined for the main antenna are also used
for the calculations using the smart antenna equipment.
The Motorola base station templates assume that the antennas are not
downtilted, so the parameter will need to be updated in cases where
downtilting is desired.
Note. 10. The Number of Antenna Ports portion of the Transmitter tab allows the
user to define the number of transmission and reception antennas that will
be used for MIMO. These values determine which MIMO configuration will
be used. This can be found by clicking Transmitters Equipment LTE
Equipment. Doing this opens the LTE Equipment window which lists the
BTS configurations available. Selecting the appropriate BTS name and
double clicking on the arrow next to the name will open the properties
window for that BTS. Selecting the MIMO tab in this window will display
the number of TX and TX ports associated with the chosen BTS
equipment.
When using the Motorola base station templates, these parameters are
set automatically to 2 Tx and 2 Rx antennas. In order to model a
configuration other than 2 Tx and 2 RX antennas, the appropriate number
of TX and RX antennas must be entered. For example, to model a
Remote Radio Head product with 4 Tx and 4 RX antennas, a value of 4
should be selected for Transmission and Reception. This will result in the
correct indexing into the MIMO configuration table when Atoll applies
MIMO gains.
Note: In Atoll 2.8.1 (build 3095 and later), 8 receive antennas can be
specified. The Motorola 2.8.1 template has been updated accordingly.
Any further use of the previous practice of referencing 1 receive antenna
in place of 8 at the eNB should be discontinued. Problems were
experienced when predicting UL capacity correctly when utilizing the older
approach.
Note. 11. The Secondary Antennas portion of the Transmitters tab allows the user to
select one or more secondary antennas in the Antenna column and enter
their Azimuth, Mechanical Downtilt, Additional Electrical Downtilt, and %
Power, which is the percentage of power reserved for this particular
antenna. For example, for a transmitter with one secondary antenna, if
40% of the total power is reserved for the secondary antenna, 60% is
available for the main antenna.
Revision 1.3
iProtect: Internal
Page 90
This portion of the GUI window will not typically be used. (For information
on working with data tables, please see the Atoll Users Guide.)
Note. 12. The |<, <<, >>, >| buttons allow the user to easily navigate from the
properties window for one transmitter sector to the properties window for
another. The user can either move to the beginning or end of the
transmitter list or move one by one through the list in the backwards or
forwards direction by using these buttons.
7.1.2.1.3.
The Cells tab provides detailed information regarding various LTE parameters and RF
channel characteristics associated with the sector (such as the frequency, power levels,
traffic load, noise rise, etc.). The following describes the parameters associated with the
Cells tab.
The parameters that appear in the Cells tab are dependent upon the technology that
was chosen when the user opens a new project. If the user selects the Motorola specific
LTE template, many of these parameters are set based on Motorola equipment.
Revision 1.3
iProtect: Internal
Page 91
NOTES:
Note. 1. The Name entry, by default, is filled in by Atoll to name the cell after its
transmitter, adding a suffix in parenthesis. This field allows the user to
change the cell name. However, for consistency sake, it is recommended
this name field be assigned by the Atoll tool. (If it is desired to change the
default name that Atoll gives to new cells, please see the Atoll
Administrator Manual.)
Revision 1.3
iProtect: Internal
Page 92
Note. 2. The Active field designates whether this cell is active (i.e. whether the cell
will be included in calculations). The box must be checked to make the cell
active.
Note. 3. The Frequency Band field allows the user to enter the sectors frequency
band from the Frequency Band list. If the Motorola base station templates
are used to place the sites, then this field is set to a default band that must
be changed to the correct band for the system being designed. The drop
down menu contains a list of the most likely bands to be supported by
Motorola products. However, as of the writing of this document, concrete
product plans have not been established regarding supported frequency
bands and bandwidths; therefore, it is necessary to check with WiBB
Product Management for actual or planned availability of eNBs supporting
the frequency band and channel bandwidth being considered for the
design.
Note. 4. The Channel Number field allows the user to enter the channel from the
list of available channels. The available channels in the pull-down list are
dependent upon the frequency band that has been selected for the study.
This field needs to be set by the user to correspond to the channel that will
be used in this sector. See Section 7.2.2.1 for additional information on
frequency band numbering.
Note. 5. The Channel Allocation Status is the status of the current channel
allocated to the cell for use with the AFP. The AFP is a separate module
within Atoll. For information regarding the AFP, please see the Atoll Users
Manual.
Note. 6. Physical Cell ID is the physical cell ID of the cell. It is an integer value from
0 to 503. The physical cell IDs are defined in the 3GPP specifications.
There are 504 unique physical-layer cell identities. The physical cell IDs
are grouped into 168 unique cell ID groups (called S-SCH IDs in Atoll),
with each group containing 3 unique identities (called P-SCH IDs in Atoll).
An S-SCH ID is thus uniquely defined by a number in the range of 0 to
167, and a PSCH ID is defined by a number in the range of 0 to 2. Each
cells reference signals transmit a pseudo-random sequence
corresponding to the physical cell ID of the cell.
Note. 7. Physical Cell ID Status is the status of the physical cell ID currently
assigned to the cell for use with automated cell ID planning. Automated
cell ID planning functionality is not covered in this document. For
information regarding automated cell ID planning, please see the Atoll
Users Manual.
Note. 8. The Min Reuse Distance (m) field is used by the Automatic Frequency
Plan (AFP) algorithm to determine the minimum distance between this cell
and when the channel assigned to this cell can be used again. The AFP is
a separate module within Atoll. For information regarding the AFP, please
see the Atoll Users Manual.
Revision 1.3
iProtect: Internal
Page 93
Note. 9. Max Power (dBm) is the cells maximum transmission power. Note that the
power entered here is not the exact power used in computing the base
station EIRP for signal strength prediction; rather, Atoll uses this power
value as a starting point for calculating power levels for each of several
different channel types. The calculated power level used in signal strength
prediction depends on the number of resource elements for the given
channel type, where the number of resource elements is determined
internally by Atoll. The calculated power also depends on the values of
SCH & PBCH EPRE Offset/RS (dB) (described in Note. 10 below) and
PDSCH & PDCCH EPRE Offset / RS (dB) (described in Note. 12 below).
If using the Motorola template, Max Power (dBm) will be set for the
selected eNB product assuming two transmit antennas. The following
table shows the Max Power (dBm) values contained in the template. The
two EPRE Offset values are set to 0 in the template. Motorolas design
procedure involves analysis of the PDSCH. By setting the Max Power
(dBm) values as shown in the table and setting the two EPRE Offset
values to 0, the PDSCH power used in signal strength and CINR
predictions will be as shown in the table (PDSCH Power (dBm)).
The Max Power (dBm) Values in the template include 3 dB of TX diversity
gain, again assuming 2 TX antennas. If 4 TX are to be used, then an
additional 3 dB should be added to Max Power (dBm).
Table 2: Max Power (dBm)
LTE AP
Product
eNB Tx Power
per antenna
(dBm)
TX
Combining
Gain
Max
Power
(dBm)
PDSCH
Power
(dBm)
Frame Based
46
2x2 RRH
43
4x4 RRH
40
4x8 RRH
40
Horizon II
43
3
3
6
6
3
3
3
49.26
46.26
46.26
46.26
46.26
46.26
46.26
49
46
46
46
46
46
46
SC7224
43
UBS
43
Note. 10. The SCH & PBCH EPRE Offset / RS (dB) is the difference in the energy of
a resource element belonging to the SCH or the PBCH with respect to the
energy of a reference signal resource element. This value is used to
calculate the transmission power corresponding to the primary and
secondary synchronization channels and the physical broadcast channel.
If using the Motorola template, this value will be set to 0 dB. Motorolas
design procedure is focused on the PDSCH and setting the EPRE Offset
to 0 will ensure that the correct output power is used for the PDSCH.
Note. 11. The PDSCH & PDCCH EPRE Offset / RS (dB) is the difference in the
energy of a resource element belonging to the PDSCH or the PDCCH with
respect to the energy of a reference signal resource element. This value is
Revision 1.3
iProtect: Internal
Page 94
iProtect: Internal
Page 95
and - for a special subframe with guard period. Atoll 2.8.1 is currently
scheduled to add one more selection option for the half frame periodicity,
which is D-UUU D-UUD. If the networks switching point periodicity is set
to "1-Frame", a frame configuration of type D-UUU DDDDD, D-UUD
DDDDD, or D-UDD DDDDD can be selected. The associated DL/UL split
percentages for these configurations are as shown in the following table.
DL%/UL%
Split
D-UUU D-UUU
D-UUD D-UUD
D-UDD D-UDD
D-UUU D-UUD
(Atoll v2.8.1)
D-UUU DDDDD
D-UUD DDDDD
D-UDD DDDDD
25/75
50/50
75/25
37/63
67/33
78/22
89/11
If using the Motorola template, the TDD frame configuration field is left
blank, indicating FDD as the default operation. If the system being
designed is TDD, then the appropriate TDD Frame Configuration must be
selected and the frequency band for the cell must be a TDD band (refer to
Section 7.2.2.1 for further information on configuring frequency bands).
The choice of TDD frame configuration should coincide with the actual
expected DL/UL traffic usage as dictated by the planned services for the
network. The choice of frame configuration should also consider
coexistence requirements with other non-LTE TDD systems. The purpose
for having two different DL/UL switching point periodicities (i.e. 5ms and
10ms) is to accommodate coexistence between a TDD LTE system and
other non-LTE TDD systems.
Channel throughput estimations will be scaled on the basis of the TDD
configuration selection according to the number of subframes for the
direction.
Note: Both ML-CAT and Atoll estimate TDD capacity by taking FDD
capacity and scaling it by DL and UL factors which represent the number
of subframes (and consequently the fraction of subframes) utilized by the
particular direction. Within ML-CAT, those DL & UL percentages are
54.3% and 40%, respectively, for TDD config #1. This corresponds to 4
subframes for the UL and 4 subframes for the DL plus a fraction of the
special subframes for the DL as well (that number is 10 symbols out of 14
corresponding to special subframe configuration #7). But, within Atoll, the
DL & UL percentages are both 40%, i.e. no special consideration is given
Revision 1.3
iProtect: Internal
Page 96
the fraction of DL traffic that can fit into the special subframes. This means
the DL traffic within Atoll is scaled down too much (40% instead of only
54.3%).
Forsk has acknowledged this scaling inaccuracy (FR #24542) and the
fix is planned for v3.1.0. Until the fix arrives, it is reasonable to take
the resultant DL TDD capacity from Atoll and scale it up to account
for the special subframes, i.e. scale by 54.3/40 or 1.36 (for TDD
configuration #1, special sub-frame configuration #7).
Note. 17. Diversity Support (DL) is the type of antenna diversity technique (None,
Transmit Diversity, SU-MIMO, or AMS) supported by the sector in the
downlink. The following table describes the impact of this selection. Note
that Atoll will only apply the selected eNB TX scheme in an analysis if the
selected terminal for the analysis has its diversity support set to MIMO
(refer to Section 7.3 for information on terminal settings).
The recommended setting is a function of the transmission mode being
modeled (refer to Table 7). This field is set to a single appropriate value
for both coverage and capacity analysis.
Table 4: Diversity support
Revision 1.3
Effect on Analysis
Transmit Diversity
SU-MIMO
AMS
None
iProtect: Internal
Page 97
Note. 18. Diversity Support (UL) is the type of antenna diversity technique (None,
Receive Diversity, SU-MIMO, AMS, or MU-MIMO) supported by the cell in
uplink. MU-MIMO is the one additional option for the uplink as compared
to the selection options described in the table above. If MU-MIMO is
selected, then the MU-MIMO Capacity Gain value from the Cells interface
(refer to Note. 20 below for additional information on MU-MIMO Capacity
Gain) will be used to scale the uplink throughput.
If the Motorola template is used, then the diversity support field will be set
to Receive Diversity. This is the recommended setting for coverage
analysis. SU-MIMO and AMS is not supported in the UL, since the
subscriber equipment typically only has one transmitter. The MU-MIMO
option can be selected if the goal is to scale the uplink throughput to
model UL spatial division multiple access.
Note. 19. In the case of AMS, the AMS & MU-MIMO Threshold (dB) field defines the
reference signal threshold for switching from spatial multiplexing and
Transmit Diversity as the reference signal conditions get worse than the
given value. The recommended setting is a function of the transmission
mode being modeled (refer to Table 7).
(For more information on Adaptive MIMO switching, please see the Atoll
Users Manual.)
Note. 20. The MU-MIMO Capacity Gain (UL) field defines the uplink capacity gain
due to multi-user (collaborative) MIMO. In uplink throughput calculations,
the throughput will be multiplied by this gain at the pixels where MU-MIMO
is used.
Within the Motorola template, the MU-MIMO gain is set to a value of 1,
indicating no gain. If it is desired to include MU-MIMO gain, in this value
must be changed to something greater than 1. Further information
regarding MU-MIMO gain well be forthcoming in a subsequent release of
this document.
Note. 21. Max Traffic Load (UL) (%) is the uplink traffic load not to be exceeded.
This limit can be taken into account during Monte Carlo simulations. If the
cell traffic load is limited by this value, the cell will not be allowed to have
an uplink traffic load greater than this maximum traffic load.
Note. 22. Max Traffic Load (DL) (%) is the downlink traffic load not to be exceeded.
This limit can be taken into account during Monte Carlo simulations. If the
cell traffic load is limited by this value, the cell will not be allowed to have a
downlink traffic load greater than this maximum traffic load.
Note. 23. The Traffic Load (UL) (%) field defines the uplink traffic load percentage.
The Motorola base station templates assume 100% as the default, so that
the system design is based on modeling a fully loaded system. (If the
Motorola base station templates are not used, Atoll sets the uplink traffic
load to 100%, by default.)
Revision 1.3
iProtect: Internal
Page 98
Note: The values for uplink and downlink traffic loads, and the uplink noise
rise can be set manually to actual network values or the values computed
during Monte Carlo simulations can be used. Monte Carlo simulation
results can be stored in the cells by clicking the Commit Results button in
the simulation results dialog.
Note: This field is an output and, consequently, purely informational. It
reflects its source which is either Monte Carlo simulations or userspecified values. For further information regarding values derived from
Monte Carlo simulations, refer to the Section 10 introduction and Section
10.7.
Note. 24. The Traffic Load (DL) (%) field defines the downlink traffic load
percentage. By default, the downlink traffic load is set to 100%. The
Motorola base station templates assume 100% as the default, so that the
system design is based on modeling a fully loaded system. (If the
Motorola base station templates are not used, Atoll sets the downlink
traffic load to 100%, by default.)
Note: The values for uplink and downlink traffic loads, and the uplink noise
rise can be set manually to actual network values or the values computed
during Monte Carlo simulations can be used. Monte Carlo simulation
results can be stored in the cells by clicking the Commit Results button in
the simulation results dialog.
Note: For further information regarding values derived from Monte Carlo
simulations, refer to the Section 10 introduction and Section 10.7.
Note. 25. The UL Noise Rise (dB) field defines the uplink noise rise in dB used for
the UL interference when running static plots.
Atoll does not compute interference from co-channel UEs when running
static UL CINR plots since the UE locations are not known. Rather, for
static UL CINR plots, it is up to the end user to define the level of
interference received. The Motorola base station templates assume a
setting of 3 dB; however, this is only an estimate and, as such, the UL
CINR plot must be considered as approximate only. Unique and more
accurate per-cell values of UL noise rise can be taken from capacity
simulation outputs (see Section 10.7.4).
The UL noise rise is impacted by the number of UL Resource Blocks
being used for the UEs. Atoll automatically accounts for the number of UL
RBs used on the UL while the recommended approach of producing
throughput images to represent system coverage is being followed (see
Section 9.3.1.1). The allocation of RBs will depend on the selected
scheduler parameters (see Section 7.2.2.4).
Revision 1.3
iProtect: Internal
Page 99
Note. 26. The Inter-technology UL Noise Rise (dB) field defines the uplink noise rise
that will be used in the calculations of uplink inter-technology interference.
This value represents the uplink interference from external transmitters or
mobiles. This noise rise is added to any calculation of uplink interference.
The effect of this uplink interference can be seen in any prediction for
which uplink interferences may have an effect. This value is normally set
at the template default of 0 dB.
Note. 27. The Inter-technology DL Noise Rise (dB) field defines the downlink noise
rise that will be used in the calculations of downlink inter-technology
interference. This value represents the downlink interferences from
external mobiles on the mobiles in the system. This noise rise is added to
any calculation of the mobile downlink interferences. The effect of these
downlink interferences can be seen in the predictions for which downlink
interferences may have an effect. This value is normally set at the
template default of 0 dB.
Note. 28. The Max Number of Intra-technology Neighbors field defines the
maximum number of neighbors from within the same Atoll document
(project) that the sector can have. If the Motorola base station templates
are used, this field is automatically set to the Motorola recommended
value of 32.
Note. 29. The Max Number of Inter-technology Neighbors field defines the
maximum number of neighbors from other technology documents
(projects) that the cell can have. If the Motorola base station templates are
used, this field is automatically set to the Motorola recommended value of
32.
Note. 30. The Comments field allows the user to enter comments regarding this
sector, if desired.
Note. 31. The Layer field defines the order of the cell among all the cells of the
transmitter. This must be a positive integer value. This value is
automatically assigned when creating a new cell, but can be modified
afterwards. The order is used during calculations for selecting the service
cell. Additional information regarding Serving Cell Selection can be found
in the section on Global Transmitter Parameters (Section 7.2.1).
Note. 32. The Neighbors field provides access to a dialog window where the intratechnology and inter-technology neighbors can be set. This dialog window
is accessed by clicking on the browse button (). Note that the browse
button may not be visible in the Neighbors box if this is a new cell. The
browse button will appear if Apply is clicked. (For information regarding
defining neighbors, please see the Atoll User Manual.)
7.1.2.1.4.
The Propagation Tab within the Transmitter Properties window defines the propagation
models that are associated with the given sector. Atoll uses the propagation model
Revision 1.3
iProtect: Internal
Page 100
defined for each transmitter to calculate losses along the transmitter-receiver path. Atoll
either calculates the path loss at any point of the map in real time (e.g. Point Analysis
calculations) or it calculates a path loss matrix for each transmitter that will be
considered in predictions.
The path loss matrix contains a set of path loss values calculated on each pixel over a
specified area. It is calculated based on a set of three parameters defined for the
transmitter:
o The propagation model
o The calculation radius
o The resolution
By using the calculation radius, Atoll limits the scope of calculations to a defined area.
Atoll enables calculations to be made for two path loss matrices: a main matrix and an
extended matrix. By using two sets of calculation parameters, Atoll allows the user to
calculate high resolution path loss matrices closer to the transmitter with one
propagation model, while reducing calculation time and storage size by using an
extended matrix with a lower resolution and another propagation model further from the
site. Atoll will calculate the extended matrix only if all three parameters (propagation
model, calculation radius, and resolution) are defined for the extended matrix.
If the calculation radius for the main propagation model is not defined and if the
extended propagation model is not defined, Atoll uses the prediction minimum
threshold to define the calculation radius for each transmitter. However, this can lead to
lengthy calculation times.
Note that when creating coverage predictions, the user can define a coverage
resolution that is different from the resolution defined for the path loss matrices. (See
Section 9 for more information regarding coverage resolution.)
Revision 1.3
iProtect: Internal
Page 101
1
2
3
5
NOTES:
Note. 1. The Main Matrix portion of the Propagation tab defines the Propagation
Model, Radius and Resolution for the main propagation matrix.
The Propagation Model pull-down menu allows the user to choose the
appropriate propagation model from the list of available models. The
recommended propagation model for use in most LTE designs is the
Standard Propagation Model (SPM) or a version of this SPM model. This
model takes terrain elevation and clutter into account. For best results, the
SPM should be tuned to the particular environment of the market that is
being designed.
For cases where drive test data is not yet available to tune the model, a
set of default parameters for use with the SPM model has been
developed. These default parameter settings are incorporated into several
different propagation model options that are included in the Motorola
Revision 1.3
iProtect: Internal
Page 102
template. A separate model is included for each LTE frequency band. The
use of one of these Motorola models is recommended until drive-test data
is available to tune the SPM model for the given market. (Further
information regarding these propagation models can be found in Section
8.1.) The Motorola base station templates include a propagation model for
a default frequency band. This default model in the template will need to
be changed if the frequency for the system under design is different than
the default.
Other propagation models are also available within Atoll, such as several
statistical models that the user can select when running budgetary
coverage studies (e.g. Cost-Hata, Erceg-Greenstein (SUI), etc.). (Please
see Section 8 of this document and the Atoll User Manual for further
information regarding the propagation models.)
Note. 2. The Radius field allows the user to specify a maximum cell range. This
value affects the speed with which Atoll results are generated. The smaller
the site radius, the faster the speed. However, the radius needs to be
large enough to adequately model the coverage and interference
surrounding the site.
Within the Motorola base station templates, the default radius is set to 5
km. This value will need to be adjusted based on the expected cell range
required to get accurate C/(I+N) calculations (e.g. encompassing 2-3 rings
of sites) or based on speed if trying to just get a quick estimate of RSSI
values.
Note. 3. The Resolution field defines the resolution corresponding to the path loss
calculations within Atoll. If the Motorola base station templates are used,
this parameter is set to 25 m resolution. This value can be modified as
required.
It may be advantageous to use higher values in this resolution field for
quick, initial coverage estimates. Then, for more detailed or final studies,
the resolution can be set to match the terrain resolution.
Note. 4. The Extended Matrix portion of the Propagation tab defines the
Propagation Model, Radius and Resolution for the extended propagation
matrix. As mentioned above, the use of both the main matrix and
extended matrix allows the use of higher resolution closer to the site
location and lower resolution farther out from the site. This can be used as
a technique to improve the speed of the calculations.
If the Motorola base station templates are used, only the main matrix
settings are given by default.
Revision 1.3
iProtect: Internal
Page 103
Note. 5. Atoll automatically checks the validity of the path loss matrices before
calculating any coverage prediction. The Available Results portion of this
window reports the results of this validity check. For further information on
this topic, please see the Atoll User Manual.
7.1.2.1.5.
The Display Tab within the Transmitter Properties window defines how the sector will be
displayed.
Figure 58: Transmitter Properties - Display Tab
As can be seen in the figure above, the Display tab provides the access to the display
parameters for this sector. The Display Parameters dialog window allows the user to
change the color, size, and symbol for the object that represents the sector within the
display.
Atoll can be set to automatically use different colors for the sectors (transmitters) in a
system. Automatically setting the transmitter colors helps in displaying the sites since
each transmitter will have a different color (though colors from one site to another may
be reused). Also, setting the transmitter colors before running images ensures that the
images will also be colored (rather than shades of gray), such as the Coverage by
Transmitter image. The following steps can be used to automatically set the coloring of
all transmitters:
1. Right-click the Transmitters folder and select Properties, as seen below.
Revision 1.3
iProtect: Internal
Page 104
2. Select the Display tab and set the Display type to Automatic, as seen in the
following figure.
Figure 60: Transmitter Properties Automatic Display
3. This step and the following two steps are not required for automatically coloring
the transmitters. However, these steps are included to show how to change the
transmitter display symbol, if desired. Click on the symbol shown under the
Display Type and a Display parameters dialog window will appear.
Revision 1.3
iProtect: Internal
Page 105
4. In the Symbol pull-down list, select the last symbol from the list (i.e. the
beamwidth related transmitter symbol).
Figure 62: Changing the Transmitter Display Symbol
As seen in the previous subsections, the parameters for a specific site can be changed
through the Transmitter Properties window for that specific site/sector. However, if the
user wants to make global changes to the parameters for several sites/sectors at once,
then it is necessary to open the Transmitters and/or Cells Tables. This section will
provide information regarding making changes to the Transmitters Table. Similar types
of changes can be made to the Cells Table, which is discussed further in Section
7.2.4.1.
Revision 1.3
iProtect: Internal
Page 106
To open the Transmitters Table, right-click on the Transmitters folder and select Open
Table, as seen in the following figure.
Figure 63: Accessing the Transmitters Table
As can be seen in this figure, the transmitter related fields (not including the cell table
fields) are contained within this table. This table is especially useful when making global
changes to a field or when making changes for a group of sectors. For example, if it is
desired to change the height of all of the antennas, the user can change the antenna
height of the first sector within the table and then copy this value to all of the other
sectors. Similar to Excel spreadsheets, a shortcut method to copy the first value in a
column of an Atoll table to the rest of the rows is to click in the column heading field to
select the column and then hit Ctrl-d.
Revision 1.3
iProtect: Internal
Page 107
For information on how to more easily make group changes, refer to Copying and
Pasting in Tables and Grouping, Sorting, and Filtering Data in the Atoll User Manual.
The Global Transmitter Parameters define the frame structure, TDD, and Power Control
parameters for the system. The Motorola template contains default settings for these
parameters. However, these settings need to be reviewed and updated by the user to
ensure that they are set appropriately for the given market configuration.
The Transmitter Global Parameters are accessed by right-clicking on the Transmitters
folder and selecting Properties, as shown in the following figure.
This opens up the Transmitters Properties dialog window. The following figure shows
the Global Parameters tab within this dialog window.
All of the values in the Frame Structure section of this interface impact the estimated
throughput values that are produced by Atoll.
Revision 1.3
iProtect: Internal
Page 108
1
2
3
4
5
6
7
8
NOTES:
Note. 1. LTE supports two cyclic prefix types: normal and extended. The Default
Cyclic Prefix is set to 0 Normal in the Motorola template, which is the
initial cyclic prefix supported by Motorola LTE eNodeBs. Using the
default, normal cyclic prefix results in 7 OFDM symbols per slot being
used in the throughput calculations whereas selecting the extended cyclic
prefix results in only 6 OFDM symbols per slot being used in the
throughput calculations.
Note. 2. The Physical Downlink Control Channel (PDCCH) can take up to 3 symbol
durations for PDCCH Overhead in each subframe in the downlink. In Atoll,
the PDCCH is considered to include the PCFICH, PHICH, and PCH as
well. The PBCH, P-SCH, S-SCH, and the downlink reference signals
consume a fixed amount of resources in the downlink. Their
corresponding overheads are hard-coded in Atoll in accordance with the
3GPP specifications. When using the Motorola template, PDCCH
overhead is set to a default value of 3.
Revision 1.3
iProtect: Internal
Page 109
Note. 3. PUCCH Overhead is the number of resource blocks in the uplink that are
used for the Physical Uplink Control Channel (PUCCH). The uplink
demodulation and sounding reference signals consume a fixed amount of
resources in the uplink. Their corresponding overheads are hard-coded in
Atoll in accordance with the 3GPP specifications. However, the end user
must directly enter the PUCCH overhead. The following table contains
recommended typical values of PUCCH overhead as a function of
bandwidth.
Table 5: PUCCH RB's
Bandwidth
(MHz)
PUCCH RBs
1.4
10
15
12
20
16
Note. 4. The Switching Point Periodicity (TDD only) can either be after each halfframe or each frame. You can select the frame configuration, i.e., the
configuration of uplink and downlink subframes in a frame, for each cell
according to the selected switching point periodicity.
The following global parameters are accessed via the Advanced button.
Note. 5. The Reference Signal EPRE is set to 0 in the template to specify that its
value is derived from Max Power and EPRE Offsets.
Note. 6. The Serving Cell Layer Selection Method is set to Random.
Note. 7. Uplink Power Control Margin is the margin (in dB) that will be added to the
bearer selection threshold, for safety against fast fading, when performing
power control in the uplink.
Note. 8. The Adaptive MIMO Switching Criterion is set to Reference Signal C/(I+N).
7.2.2.
Network Settings
The following subsections describe the input settings that define the network (i.e.
frequency band, bearer information, quality indicators, schedulers, and MIMO
configurations). Most of these parameters are set within the Motorola template and
should not need to be changed.
Revision 1.3
iProtect: Internal
Page 110
7.2.2.1. Frequencies
This opens up the Frequency Bands dialog window. The following figure shows the
window with the values that are set within the Motorola template. These values should
not need to be changed.
Revision 1.3
iProtect: Internal
Page 111
10
11
The input for the frequency bands can be entered directly into this table. Alternately, if
the user desires to update one frequency band, a dialog window for that particular band
can be opened by double-clicking in the column that precedes that frequency.
NOTES:
Note. 1.
The Name field provides the name of the frequency band. Since each LTE
frequency band has a specific channel bandwidth, it is recommended that
the channel bandwidth be included as part of the frequency band name.
This name will appear in other dialog windows where a frequency band is
selected.
Note. 2.
The Channel Width (MHz) field defines the channel bandwidth for the
given frequency band.
Check with WiBB Product Management for actual or planned availability
dates as the APs supported bands and channel bandwidths may change
over time.
Revision 1.3
iProtect: Internal
Page 112
Note. 3.
The First Channel field defines the number of the first channel in the given
frequency band. The recommended setting for the first channel is 0.
Note. 4.
The Last Channel field defines the number of the last channel in the given
frequency band. If the frequency band has only one carrier, enter the
same number as entered in the First Channel field. If using the Motorola
template with Atoll, this value is already set for the given bands that are
supported by Motorola equipment.
Note. 5.
The Excluded Channels field defines the channel numbers which do not
constitute the frequency band, if any.
Note. 6.
The TDD: Start Frequency, FDD: DL Start Frequency (MHz) field defines
the start frequency for TDD frequency bands and the downlink start
frequencies for FDD frequency bands. The start frequency is determined
by adding the bandwidth from the edge of the frequency band. For
example, if the frequency band is 2.3 GHz (i.e. 2300 MHz at the lower
edge) and the channel bandwidth is 10 MHz, then the start frequency is
2300 MHz + 5 MHz, or 2305 MHz. If the Motorola template is used with
Atoll, this value is set appropriately.
Note. 7.
The FDD: UL Start Frequency (MHz) field defines the uplink start
frequencies for FDD frequency bands.
Note. 8.
The Adjacent Channel Suppression Factor (dB) field defines the adjacent
channel interference suppression factor in dB. Interference received from
adjacent channels is reduced by this factor during the calculations.
This value is set to default provided by Forsk of 28.23 dB in the Motorola
template. This value only impacts channel overlap, and since there is no
overlap, this value does not affect the results.
Note. 9.
The Sampling Factor field defines the sampling factor for converting the
channel bandwidth into the sampling frequency. If using the Motorola
template within Atoll, this value is already set based on the LTE
specifications.
Note. 10.
The Duplexing Method field defines the duplexing method used in the
frequency band. This method is chosen from the duplexing method list
(FDD or TDD).
This value should be set accordingly for the system
being designed. If using the Motorola template, this value is already set
correctly for each frequency band.
Note. 11.
The Number of Frequency Blocks (RB) field defines the number of 180
KHz wide frequency blocks contained within the channel bandwidth. The
values in the Motorola template are set according to the LTE
specifications and should not need to be changed.
Revision 1.3
iProtect: Internal
Page 113
The LTE bearer table defines the modulation and coding schemes that are used within
Atoll for uplink and downlink.
If the Motorola template is used within Atoll, the values for the LTE bearer parameters
are set within the tool to match what is supported by Motorola products. The coding
rates are slightly different on the downlink as compared to the uplink for LTE; therefore,
the LTE bearer table contains two sets of bearers with 29 bearers in each set. The first
set of bearers is numbered 1 29 for the downlink and the second set of bearers is
numbered 30 58 for the uplink.
The LTE Bearers parameters are accessed by right-clicking on the Transmitter folder in
the Data tab and selecting Network Settings LTE Bearers, as seen in the following
figure.
This accesses the following LTE Bearers parameters dialog window. In this window,
each row represents a separate bearer. The information in the following figure is based
on the Motorola template settings and is for the downlink bearers.
Revision 1.3
iProtect: Internal
Page 114
NOTES:
Note. 1. The Radio Bearer Index field provides the index that is used to identify the
bearer in other tables (e.g. the bearer selection thresholds and the quality
graphs in the LTE reception equipment tables).
Note. 2. The Name field provides the name given to the specific bearer. This name
appears in other dialog windows and results.
Note. 3. The Modulation field provides the modulation that is used for the bearer
(QPSK, 16 QAM or 64 QAM).
Note. 4. The Channel Coding Rate field provides the coding rate for the bearer.
Revision 1.3
iProtect: Internal
Page 115
Note. 5. The Bearer Efficiency (bits/symbol) field provides the number of useful bits
that the bearer can transfer in a symbol. This information is used in
throughput calculations.
The Bearer Efficiency is calculated using the following formula:
Bearer Efficiency = (1-BLER) * r * Log2(M)
where BLER is the block error rate, r is the channel coding rate, and M is
the modulation rate.
As an example, assuming that BLER=0, the bearer efficiency of a QPSK
0.12 bearer is (1-0)*0.117188 * Log2(4) = 0.234375 bits/symbol.
The information in the following figure is based on the Motorola template settings and is
for the uplink bearers.
Figure 71: UL Bearers Dialog Window
Revision 1.3
iProtect: Internal
Page 116
Quality indicators are used in Atoll as part of the Effective MAC Channel Throughput
Calculation. The Quality Indicators table lists the quality indicators that are used in Atoll.
If the Motorola template is used within Atoll, the values for the Quality Indicator
parameters are set within the tool to match what is supported by Motorola products.
Only the BLER row is included in the template. BLER is synonymous with FER. The
values in this table should not need to be changed.
The Quality Indicators table can be accessed by right-clicking on the Transmitter folder
in the Data tab and selecting Network Settings Quality Indicators, as seen in the
following figure.
This accesses the Quality Indicators table as shown in the following figure.
Revision 1.3
iProtect: Internal
Page 117
NOTES:
Note. 1. The Name field provides the name of the Quality Indicator (bit error rate,
block error rate, frame error rate, packet error rate).
Note. 2. The Used for Data Services field checkbox indicates whether this quality
indicator is used for data services. If this checkbox is selected, this quality
indicator is used for data services.
Note. 3. The Used for Voice Services field checkbox indicates whether this quality
indicator is used for voice services. If this checkbox is selected, this quality
indicator is used for voice services.
7.2.2.4. Schedulers
In Atoll, schedulers perform resource allocation. Within Atoll, the scheduler will prioritize
users, assign bearers, and determine the fraction of the channel capacity that the user
will be allowed to consume. In the UL direction, the scheduler will also allocate the
number of frequency blocks and transmit power to be used. Different scheduling
methods and parameters influence how the allocation of resources is performed and the
resultant capacity.
Basic definitions for all scheduler parameters along with detailed procedures for
accessing and modifying the scheduler table are found in Defining LTE Schedulers
(Section 12.7.6 of the Atoll 2.8.1 User Manual). The balance of this section will provide
Motorola recommendations/suggestions for the various parameters.
Revision 1.3
iProtect: Internal
Page 118
The Schedulers table can be accessed by right-clicking on the Transmitter folder in the
Data tab and selecting Network Settings Schedulers. The table, as shown below, is
filled with the default template values.
Figure 74: Schedulers Window
Names/Scheduling Method
The names found within the template are created to match the scheduling method.
Scheduling methods are applied in the effort to satisfy the Max Throughput Demand
(MaxTD), but only after satisfying the Min Throughput Demand (MinTD). The Max
Aggregate Throughput method is not recommended for use inasmuch as it prioritizes
users solely on the basis of signal quality and, although this would yield a high capacity,
it will be too detrimental to cell edge performance. Proportional Demand (PD) is a
scheduling method that seeks to equalize throughput across users regardless of signal
quality (i.e. a harmonic mean across the MPR/CINR distribution). Note that, effectively,
PD is the scheduling method automatically used in satisfying the MinTD. When invoked,
the resultant capacity can be seen as a lower bound on capacity. Proportional Fair (PF)
is a scheduling method that seeks to equalize the number of resources (i.e. resource
elements) across users. With this method, a user with an MPR of 5 would enjoy a
throughput that is 5 times better than that of user with an MPR of 1. When invoked, PF
will yield a capacity that is a mix of PD (for MinTD) and PF (for MaxTD). Were the
services parameters to be set as non-constraining (i.e. very low MinTD and high
MaxTD), then the resultant capacity from invoking PF would approximate a Full Buffer
model and would represent an upper bound on capacity.
As an estimation of real-world modeling of capacity, the use of the PF scheduler method
in conjunction with realistic service parameters for MinTD and MaxTD is recommended.
In the following figure, note how the PF scheduler, parameterized to approximate Full
Buffer, allocates resources (%Res, the fraction of total resources) in a fairly uniform
fashion across all the bearers (represented by their DL Channel Throughput (CTP)
values).
Revision 1.3
iProtect: Internal
Page 119
8%
7%
%Res
6%
5%
4%
3%
2%
%Res
Avg %Res
1%
0%
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
CTP (kbps)
In the figure below, note how the PD scheduler allocates resources (%Res, the fraction
of total resources) in a non-uniform fashion across bearers (represented by their DL
Channel Throughput values) in an effort to equalize user throughputs.
Figure 76: Example of PD Scheduling
DL CTP vs %Res
20%
%Res
18%
Avg %Res
16%
14%
%Res
12%
10%
8%
6%
4%
2%
0%
0
5,000
10,000
15,000
20,000
25,000
30,000
35,000
CTP (kbps)
iProtect: Internal
Page 120
here. The choice must be consistent across all voice type services and across all data
type services. Although, generally, the difference between Peak and Effective
throughputs is a fixed 10%, there is a difference at the lowest bearer where HARQ gain
is being employed and Peak and Effective throughputs diverge beyond 10%. With that
in mind, it is recommended that Peak targets not be used for specifying data services.
The Application layer may be specified to make the target throughputs more
recognizable or to be closer in value to those throughputs specified by the customer.
For example, for the full rate AMR (Adaptive Multi-rate) vocoder, the coding rate of 12.2
kbps may be directly specified as the target throughput as long as an appropriate
Application Throughput Scaling Factor is specified to account for the overheads
between Layer 1 and the application layer (e.g. a scaling factor of 3.2 / (12.2 + 3.2) =
21% would be sufficient to account for 3.2 kbps or ~8 bytes of overhead).
Bearer Selection Criterion
Bearer selection involves first establishing a set of candidate bearers. The candidate
bearers would be those that a) are less than or equal to the highest bearer specified for
the service and b) have bearer selection thresholds that are lower than the CINR that
the subscriber experiences (assuming use of all frequency blocks). Of the candidates,
the best bearer is selected based on the criterion specified via this scheduler
parameter. The three options available include: Bearer Index, Peak RLC Throughput,
and Effective RLC Throughput. For the downlink, there would be no real significant
difference regardless of which option is selected. This is because both the peak and
effective throughputs are increasing with CINR and the bearer indices are also chosen
to increase in number with increased bearer efficiency; therefore, no matter which
option is selected, the same bearer is chosen as best. On the other hand, the
difference for the UL can be very significant. This is because the bandwidth allocation
on the UL can vary (depending on the option selected for UL Bandwidth Allocation
Target) and, therefore, it is not only possible but likely that a lower bearer with a larger
bandwidth allocation will actually achieve a higher throughput than a higher bearer with
a smaller bandwidth allocation. Refer to the description below of UL Bandwidth
Allocation Target for additional information related to this topic.
It is strongly recommended that the Bearer Index not be used as the Bearer Selection
Criterion. The default of Peak RLC Throughput is proposed for use.
Uplink Bandwidth Allocation Target
The three options available include: Full Bandwidth, Maintain Connection, and Best
Bearer. The default (template) value of Best Bearer is recommended for use in
conjunction with the Peak RLC Throughput bearer selection criterion. The Full
Bandwidth option is not to be used.
Full Bandwidth requires that the entire bandwidth, i.e. all frequency blocks, be utilized
by the subscriber. This Full Bandwidth requirement will drive subscribers on the cell
edge into outage unnecessarily as the devices will not be allowed to trade off Frequency
Blocks to increase power-per-subcarrier and, in this manner, extend or maintain
coverage. This is exactly what is accomplished with the Maintain Connection (MC)
option. The Best Bearer (BB) option performs like the MC option, but also evaluates
whether a higher order bearer with fewer frequency blocks can be preferred to a lower
Revision 1.3
iProtect: Internal
Page 121
order bearer with more frequency blocks. BB is the only option that can search bearers
beyond the original set of candidates. This is because the set was formed on the
assumption of the entire bandwidth being utilized and the BB option changes this
assumption.
In the figure below, the chart in the lower right shows Best Bearer in conjunction with
the Bearer Index selection method. Note how the highest order UL MCS (represented
by the high Channel Throughput) has been allocated in nearly all of the cases.
Conversely, the chart in the upper left shows Best Bearer with Peak Throughput
selection method.
This last distribution is more realistic and leads to the
recommendation to use this combination.
Figure 77: Bearer Selection Criterion
UL CTP vs FB
60
50
40
FB
UL CTP vs FB
60
30
FB
Avg FB
50
20
40
10
FB
FB
0
0
2,000
4,000
6,000
8,000
Avg FB
30
10,000
CTP (kbps)
12,000
14,000
16,000
18,000
20
10
0
0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
16,000
18,000
CTP (kbps)
As discussed in Section 5.2, there are several LTE Base Station templates within Atoll
that allow the user to set the parameters for various base stations so that the user can
then create new sites with these specific parameters. Section 5.2.8 described how the
user can access and modify the base station parameters using the Station Template
Properties dialog. However, the user can also access the base station template
parameters through the Station Templates table.
The Station Templates table can be accessed by right-clicking on the Transmitter folder
in the Data tab and selecting Network Settings Station Template, as seen in the
following figure.
Revision 1.3
iProtect: Internal
Page 122
When using the Motorola-specific project template, the base station template table
reflects the Motorola AP products. However, please note that product availability is
subject to change. Product management should be consulted to determine eNB
availability for the specific frequency band and configuration desired.
Revision 1.3
iProtect: Internal
Page 123
7.2.3.
Equipment Settings
Several dialog windows within Atoll allow the user to define the base station and
associated equipment (e.g. tower mounted amplifier and feeder cables).
Atoll uses the associated equipment properties to calculate the downlink and uplink
losses and BTS noise figure of the transmitter. These properties can be automatically
calculated by Atoll from the properties of the components or they can be defined by the
user.
When using the Motorola template, the losses and noise figures are defined and not
calculated from the parameters within the TMA, feeder, or BTS equipment configuration
windows.
7.2.3.1. TMA Equipment
If tower mounted amplifiers are being used, the equipment needs to be defined in the
TMA Equipment interface. The TMA Equipment interface can be accessed by rightclicking on the Transmitter folder in the Data tab and selecting Equipment TMA
Equipment, as seen in the following figure.
This opens up the TMA Equipment dialog window as seen in the following figure:
Revision 1.3
iProtect: Internal
Page 124
NOTES:
Note. 1. The Name field provides the name of the TMA equipment. This name will
appear in other dialog windows when selecting TMA equipment.
Note. 2. The Noise Figure (dB) field provides the noise figure associated with the
TMA equipment.
Note. 3. The Reception gain (dB) field provides the reception (uplink) gain for the
TMA equipment. A positive value must be entered in this field.
Note. 4. The Transmission loss (dB) field provides the transmission (downlink)
losses (i.e. insertion loss) for the TMA equipment. A positive value must
be entered in this field.
If the user desires to have Atoll automatically calculate the feeder losses based on
specific feeder equipment and cable lengths, then the user needs to define this
equipment and associated cable lengths within the appropriate dialog windows.
Otherwise, the user can define the overall losses for the feeder cables. The Motorola
template contains typical cable loss values for various cable diameters in the LTE
frequency bands.
The following figure shows how to access the Feeder Equipment dialog window (i.e. by
right-clicking on the Transmitter folder in the Data tab and selecting Equipment
Feeder Equipment).
Revision 1.3
iProtect: Internal
Page 125
This opens up the Feeder Equipment dialog window as seen in the following figure:
Revision 1.3
iProtect: Internal
Page 126
NOTES:
Note. 1. The Name field provides the name of the Feeder Equipment. This name
will appear in other dialog windows when selecting Feeder Equipment.
Note. 2. The Loss per length (dB/m) field provides the loss per meter associated
with the specified feeder cable. A positive value must be entered in this
field. This value will be used in conjunction with the user-defined cable
lengths to calculate the feeder loss values. These loss rates are based on
the following Andrew Heliax cables: LDF4-50A 1/2, AVA5-50 7/8, AVA650 1-1/4, and AVA7-50 1-5/8 .
Revision 1.3
iProtect: Internal
Page 127
Note. 3. The Connector reception loss (dB) field provides the connector loss
associated with the reception (uplink) path. A positive value must be
entered in this field.
Note. 4. The Connector transmission loss (dB) field provides the connector loss
associated with the transmission (downlink) path. A positive value must be
entered in this field.
The BTS equipment is modeled using the BTS Equipment dialog window. This interface
can be accessed by right-clicking on the Transmitter folder in the Data tab and selecting
Equipment BTS Equipment, as seen in the following figure.
This opens up the BTS Equipment dialog window as seen in the following figure:
Revision 1.3
iProtect: Internal
Page 128
NOTES:
Note. 1. The Name field provides the name of the BTS Equipment. This name will
appear in other dialog windows when selecting BTS Equipment.
Note. 2. The Noise Figure (dB) field provides the noise figure associated with the
specified BTS equipment. As described in Section 7.1.2.1.2, the typical
Noise Figure for Motorola eNBs is 4 dB.
Note. 3. The Downlink Losses due to the configuration (dB) field provides the
losses on the downlink based on the BTS configuration.
Note. 4. The Uplink Losses due to the configuration (dB) field provides the losses
on the uplink based on the BTS configuration.
Note. 5. The Rho factor (%) field provides the Rho factor associated with the BTS
equipment as a percentage. The Rho factor enables Atoll to take into
account self-interference produced by the BTS.
This field is not used at this time. For further information on this
parameter, please see the Atoll User Manual.
Revision 1.3
iProtect: Internal
Page 129
The LTE Equipment interface provides the reception characteristics of cells and user
terminals. Bearer selection thresholds, channel quality indicator graphs, and MIMO
configuration information are defined in the reception equipment.
The main LTE Equipment window is shown in the following figure. This figure and the
remainder of figures in this section assume the use of the Motorola template.
Revision 1.3
iProtect: Internal
Page 130
The Motorola UE Reception (DL) contains the reception characteristics of the default
subscriber terminals (i.e. CPE and MS) contained in the Motorola template. The
Motorola LTE Reception (UL) contains the reception characteristics of the eNodeBs.
Double clicking on the area to the left of the Name column for any one of the LTE
Equipment entries will open up the reception equipment properties dialog window for
the selected equipment, as shown in Figure 88. The reception equipment properties
window has three tabs: Bearer Selection Thresholds, Quality Graphs, and MIMO.
7.2.3.4.1.
The Bearer Selection Thresholds tab provides Bearer Selection Thresholds for different
mobility types. A bearer is selected for data transfer at a given pixel if the received
C/(I+N) ratio is higher than its selection threshold. The Bearer Selection Thresholds
interface for the Motorola UE Reception (DL) is shown in the figure below. The
information in the Motorola template is based on the bearer threshold information and
includes AWGN SNR + fast fading for the specific mobility profile.
A graph showing the C/(I+N) thresholds for each of the bearers can be accessed from
the Bearer Selection Thresholds tab by clicking on the mobility type that is of interest
Revision 1.3
iProtect: Internal
Page 131
and then clicking on the Best Bearer Thresholds button. The C/(I+N) Thresholds window
shows both a chart and a graph of the C/(I+N) thresholds that are associated with each
bearer. The bearers are listed by the bearer index (as discussed in the LTE Bearers
interface, Section 7.2.2.2).
Each mobility type has two sets of bearer selection thresholds provided, one for
coverage and one for capacity. The capacity set is distinguished by having the suffix
_Capacity appended to its mobility type name. For example, the mobility type PB3 will
access the coverage set while the mobility type PB3_Capacity will access the capacity
set. In particular, when specifying mobility types for Monte Carlo simulations, the
capacity sets ought to be invoked.
The Quality Indicator Graphs are used in the computation of Effective MAC Channel
Throughput. The graphs show the relationship of CINR to BLER for each bearer within
each mobility type. Figure 89 below shows a single example. The BLER begins at 10%
(i.e. 0.1) at the bearer selection threshold CINR of 3.0194 dB. The BLER then
decreases as CINR increases. These BLER curves are customized to the specific
bearers and mobility types involved. BLER would ideally be 10% for most values of
CINR (see Ideal MPR versus EFF curves in Figure 90). But, within Atoll, the BLER have
been adjusted to scale the static peak efficiencies to effective efficiencies (see MPR
versus EFF curves in Figure 90). Because of this translation, users should not be
surprised to find some negative BLER values and also instances where the effective
efficiency exceeds the peak efficiency.
Figure 89: Quality Graph
Revision 1.3
iProtect: Internal
Page 132
Efficiency (bits/symbol)
1.0
0.9
MPR
0.8
EFF
0.7
Ideal
MPR
0.6
0.5
4.0
5.0
6.0
7.0
8.0
9.0
10.0
CINR (dB)
It is expected that BLER values will deviate from ideal 10% values for the lowest and
highest bearers. At the lowest bearer (MCS0), the BLER curves reflect a HARQ gain
which correlates to an increase in BLER above 10% as increased retransmissions and
de-rated effective throughput is traded for extended coverage. This BLER range is only
used by the DL capacity curves which automatically include HARQ gain. At the highest
bearer, increased CINR reduces BLER below 10% and eventually down to 0%.
NOTE: If new bearer thresholds are needed, perhaps for a new mobility type, then
the Planning & Design group should be contacted to assist in the creation of new
customized BLER curves.
7.2.3.4.2.
MIMO Configurations
The third tab within the LTE reception equipment properties is the MIMO tab. This tab
defines MIMO and Diversity gains that will be applied depending on the specific
equipment configuration for a given downlink or uplink path (i.e. specific combinations of
number of transmission and reception antennas, mobility type, radio bearer index and
Max BLER). Each row in this tab represents a different downlink or uplink path
configuration with an associated Max MIMO and Diversity gain.
Spatial multiplexing gains are modeled in Atoll using MIMO configurations. A MIMO
configuration contains MIMO graphs of capacity gain versus RS C/(I+N)3 for different
numbers of transmission and reception antennas. The MIMO capacity gain (Max SU-
The correlation to RS CINR as opposed to RS C/N is dependent on the setting of a transmitter global parameter.
Refer to Section 7.2.1.
Revision 1.3
iProtect: Internal
Page 133
MIMO gain) is defined as the increase in channel capacity compared to a SISO system
(i.e. the increase in throughput due to MIMO).
When using the Motorola template, the Diversity gain field is used to represent Rx
Diversity (MRC) gain.
The structure of this MIMO tab can be illustrated further with an example. Take the case
between a Frame Based eNB and a CPE subscriber. The Frame Based eNB has 2
transmission antennas and 2 reception antennas, while the CPE subscriber has 1
transmission antenna and 2 reception antennas, as seen in the figure below.
Figure 91: Example Downlink and Uplink Paths between eNB and CPE
Frame Based eNB
Example
2 TX antennas
2 RX antennas
Downlink case:
2 TX antennas at eNB,
2 RX antennas at sub
Uplink case:
1 TX antennas at sub,
2 RX antennas at eNB
CPE
Example
1 TX antennas
2 RX antennas
Given this example, the downlink path from the eNB to the CPE contains 2 transmission
antennas (at the eNB) and 2 reception antennas (at the subscriber). The associated
Max MIMO and Diversity gains for this path would be represented in the Motorola UE
Reception (DL) equipment properties MIMO table in a row that contains 2 transmission
antennas and 2 reception antennas. The row that represents the downlink path for this
example is seen in the following figure.
Revision 1.3
iProtect: Internal
Page 134
In the DL, the use of both Diversity Gain and Max MIMO Gain fields requires that the
terminal type be specified to support MIMO. Consequently, the DL Diversity Gain field
will almost always be used. The use of Max MIMO Gains also requires that the cells
DL Diversity Support indicate AMS. Table 6 below shows some example Max MIMO
Gains specifications. These values must be set by the user on the basis of the
transmission mode, mobility, and number of Tx antennas. Following are some notes
pertinent to the use of this table.
The R7 release of this design procedure represents Motorolas first use of the
Max MIMO Gain field to model MIMOs capacity benefit. When 2 data streams
are being transmitted simultaneously using the same symbol resources (termed
rank 2 processing), then the CINR is said to be shared. The gain values in
the table are throughput scalars. How much of the theoretical 2X maximum
benefit is being captured for any particular RS CINR? A value of 1.32, for
example, means that 32% of the theoretical maximum is being obtained or 32%
of the time rank 2 processing is being performed. While 68% of the time,
processing as a single stream (rank 1) is assumed.
The table only shows a subset of the actual table sets. The complete set
represents 8 combinations transmission modes (TM3 and TM4), mobility (PB3
and VA30), and number of Tx antennas (2Tx and 4Tx). The 4 combinations
shown below correspond to the more likely scenarios because the performance
of TM3 is best for vehicular mobility while TM4 is best for pedestrian. The
complete set of 8 cases along with instructions for copying them into the projects
database can be found in the spreadsheet AtollR282Params.xls located at
Revision 1.3
iProtect: Internal
Page 135
The tables represent gain curves that have been derived from Minisim
simulations.
Revision 1.3
iProtect: Internal
Page 136
Table 7 below shows the recommended Diversity Gain settings for different
combinations of transmission mode, mobility, and number of Tx antennas. Also
included are the recommended values for Diversity Support and AMS Threshold.
Following are some notes pertinent to the use of this table.
Revision 1.3
iProtect: Internal
Page 137
o AMS Threshold (dB) [more fully termed "AMS & MU-MIMO Threshold"
within Atoll] is found in the Cells database.
o Diversity Gain (dB) is found under the MIMO tab of the "Motorola UE
Reception (DL) properties" window
o Mobility, for coverage purposes, is specified under the Conditions tab of
the prediction properties window.
o Mobility, for traffic (Monte Carlo) purposes, is specified in various
manners, e.g. under the Traffic tab of the traffic map properties window.
Consult with PdM on which Transmission Modes (TM) are available and to be
used.
o Generally, a customer is interested in either Beamforming (TM7) or MIMO
(TM3/4) (highlighted in green).
o When the choice is MIMO, Open Loop (OL) MIMO (TM3) performs better
at vehicular speeds (VA30) while Closed Loop (CL) MIMO performs better
at pedestrian speeds (PB3).
A difference between TM6 and TM7 is that TM7 utilizes UE-specific RS while
TM6 uses cell-specific RS. TM7 applies more classical beamforming (strives to
form 1 localized beam in physical space) while TM6 applies the newer concept of
pre-coded beamforming (where weights are chosen to form a beam in vector
space). Beamforming could be considered as a special case of the extremely
generic notion of (channel dependent) precoding.
The tables represent values adjusted from the standard 3 dB and have been
calibrated based on Minisim simulations to obtain alignment of CINR
distributions. The adjustments are generally modest, i.e. 3 dB +/- 1 dB. TM 6
(pre-coded beamforming) and TM 7 (beamforming) both show somewhat higher
diversity gains which CINR improvement is consistent with a TxAA like benefit.
Revision 1.3
iProtect: Internal
Page 138
Continuing with this example, the uplink path from the CPE to the eNB contains 1
transmission antenna (at the subscriber) and 2 reception antennas (at the eNB). The
associated Max MIMO and Diversity gains for this path would be represented in the
Motorola eNB Reception (UL) equipment properties MIMO table in a row that contains 1
transmission antenna and 2 reception antennas. The row that represents the uplink path
for this example is seen in the following figure.
Revision 1.3
iProtect: Internal
Page 139
The following figure shows the MIMO tab for the Motorola UE Reception (DL) properties
window.
Revision 1.3
iProtect: Internal
Page 140
NOTES:
Note. 1. The Radio Bearer Index field provides the corresponding radio bearer
index from a pull-down menu. This field allows the user to set up different
MIMO and Diversity gain parameters based on different radio bearer index
settings. This field is set to All in the Motorola template since the MIMO
and Diversity gains will be applied for all of the radio bearer index settings.
This means that the MIMO and Diversity parameters are not set based on
different radio bearer index settings (i.e. for a set antenna combination,
there is not a separate set of parameters for each radio bearer index). The
parameter values are applied regardless of the radio bearer index..
Note. 2. The Mobility field provides the corresponding mobility type from a pulldown menu (e.g. PB3, VA30, etc.). This field allows the user to set up
different MIMO and Diversity gain parameters based on different mobility
settings. This field is set to All in the Motorola template since the MIMO
and Diversity gains will be applied for all of the mobility settings. MIMO
and Diversity gain parameters will, in fact, vary based on mobility, but,
given constraints in Atolls interface and database structure, the user will
need to change these parameters manually, as required.
Note. 3. The Number of Transmission Antenna Ports field provides the number of
transmission antennas that are used for MIMO. This field is set within the
Motorola template.
Revision 1.3
iProtect: Internal
Page 141
Note. 4. The Number of Reception Antenna Ports field provides the number of
reception antennas that are used for MIMO. This field is set within the
Motorola template.
Note. 5. The Max MIMO Gain field provides the maximum MIMO gain values that
correspond to specific RS C/(I+N) levels for the given number of transmit
and receive MIMO antennas. This field impacts the throughput results.
Refer to Table 6 for recommended values.
Note: In the UL, these curves are not expected to be used since current
product doesnt support UL MIMO (i.e. the UL Diversity Support will only
specify Receive Diversity).
The MIMO Gain graphs provide an easier way to view this information.
The MIMO Gain graphs can be seen by clicking on a specific row in the
MIMO table and then clicking the Max MIMO Gain Graphs button. The
following figure shows an example of one of these graphs.
Note. 6. The Max BLER field provides the corresponding Max BLER setting. This
field allows the user to set up different MIMO and Diversity gain
parameters based on different maximum BLER settings. This field is set to
1 in the Motorola template since the MIMO and Diversity gains will be
applied for BLER settings up to a maximum of 1 (i.e. all BLER settings).
This means that the MIMO and Diversity parameters are not set based on
different BLER settings (i.e. for a set antenna combination, there is not a
separate set of parameters for various maximum BLER settings). The
parameter values are applied regardless of the BLER setting.
Revision 1.3
iProtect: Internal
Page 142
Note. 7. The Diversity Gain (dB) field allows the user to provide a receive diversity
gain for the path with the specified number of MIMO transmission and
reception antennas, as well as the specified mobility, radio bearer index,
and Max BLER settings. In the cases where this MIMO table is
representing a downlink path, the number of MIMO transmission antennas
will represent the number of antennas at the eNB and the number of
MIMO reception antennas will represent the number of antennas at the
subscriber. In the cases where this MIMO table is representing an uplink
path, the number of MIMO transmission antennas will represent the
number of antennas at the subscriber and the number of MIMO reception
antennas will represent the number of antennas at the eNB.
When using the Motorola template, the Diversity gain field is used to
represent Rx diversity (i.e. MRC) gain. The spatial transmit diversity gain
is not included here, but is included in the transmit power. For the uplink
path, the Diversity Gain field is used to incorporate the eNB Rx diversity
gain so that it will impact the C/(I+N) calculations appropriately (since the
Diversity gain field affects the C/(I+N) calculations in both the images and
Monte Carlo simulations).
Refer to Table 7 for recommended values. A TxAA gain is included under
TM 7. The Diversity Gain (dB) field can be adjusted to account for TXAA,
depending on the environment.
Although Atoll includes a specific field for entering base station diversity
gain in the Transmitter Equipment interface, that field only adjusts the
total transmit losses by adding a negative loss. Although this will produce
the desired results for UL C/(I+N) and throughput images, it will not
produce the desired results when doing Monte Carlo simulations. The UL
C/(I+N) image, which also drives the throughput images, does not
calculate interference from other subscribers. It uses the user-defined
uplink noise rise. The use of the base station diversity gain (negative loss)
will result in higher signal strength and higher C/(I+N) images values.
However, when running Monte Carlo simulations, the uplink noise rise is
calculated by incorporating the interference from each subscriber,
including diversity gain. By incorporating the base station Rx diversity gain
into the Diversity gain field of the MIMO interface, the gain will impact the
C/(I+N) calculations in both the images and Monte Carlo simulations.
7.2.4.
Cell Settings
Within the Transmitter folder, the information from the Cells Table and the Neighbors
table can be accessed. The following sections discuss these tables briefly.
Revision 1.3
iProtect: Internal
Page 143
All of the information that was seen in the Cells tab of the Transmitters Properties
window (see Section 7.1.2.1.3) can be accessed in the Cells Table. This table provides
the Cells parameter values for all of the sectors in the project. Similar to the
Transmitters Table (discussed in Section 7.1.2.2), this table allows the user to easily
make changes to settings in multiple sites/sectors.
To open the Cells Table, right-click on the Transmitters folder and select Cells Open
Table, as seen in the following figure.
Figure 96: Accessing the Cells Table
Revision 1.3
iProtect: Internal
Page 144
As can be seen in this figure, the fields from the Cells tab of the Transmitter Properties
are contained within this table. This table is especially useful when making global
changes to a field or when making changes for a group of sectors.
7.2.4.2. Neighbors
Revision 1.3
iProtect: Internal
Page 145
The Neighbors table allows the user to specify the neighbors for each sector. The
neighbor relation between sites can be set up as symmetric, if desired.
Further information on the creation and use of neighbors can be found in the Atoll User
Manual.
Revision 1.3
iProtect: Internal
Page 146
By selecting a specific terminal type, the properties dialog window for that terminal will
open, as seen in the following figure.
Revision 1.3
iProtect: Internal
Page 147
1
2
3
4
5
6
7
8
9
10
11
12
NOTES:
Note. 1. The Name field provides the name of the terminal. This name will appear
in other dialog windows when selecting terminal equipment.
Note. 2. The Min Power field provides the minimum power level associated with
this terminal. Within the Motorola template, the minimum power level for
the terminals are set to 63 dB below the maximum power level to provide
a range of 63 dB for power control.
Note. 3. The Max Power field provides the maximum power level associated with
this terminal. Within the Motorola template, the maximum power levels are
set to the representative values for the generic terminal equipment. These
values should be changed if necessary for the specific UE equipment in
accordance with the system being designed.
Note. 4. The Noise Figure field provides the noise figure that is associated with this
terminal. Within the Motorola template, the noise figure values are set to
representative values for the specific terminal equipment .
Note. 5. The Losses field allows the user to enter any losses associated with this
terminal. Within the Motorola template, no losses are associated with any
of the subscriber equipment. This field can also be used to account for
antenna gain correction factors and orientation losses, as described in
Section 7.3.1, assuming that the subscriber antenna gain has not been
Revision 1.3
iProtect: Internal
Page 148
iProtect: Internal
Page 149
another terminal type. The user can either mover to the beginning or end
of the terminal list or move one by one through the list in the backwards or
forwards direction by using these buttons.
7.3.1.
Within a system design, one must consider the antenna characteristics of the CPE and
where the CPE will be located. The effective gain of the antenna at the CPE device may
be less than the antenna specification due to the placement of a CPE in a non-line-ofsight (NLOS) scattering environment and non-optimal orientation of the device.
Variations between different CPE devices and how they are placed within the system
may require an adjustment to the antenna gain, orientation, and lognormal fade margin
standard deviation.
This section describes the antenna gain correction factor, the antenna orientation loss
and the lognormal fade margin standard deviation adjustments that may be necessary
to model the CPEs within the system.
7.3.1.1. Antenna Gain Correction Factor
The Antenna Gain Correction Factor (AGCF) is a reduction of the antenna gain due to
the installation of the subscriber antenna in an NLOS scattering environment.
The RF Planning Guide (http://compass.mot.com/go/310442223) provides details
regarding this topic.
If a CPE antenna is placed within a NLOS scattering area, the CPEs effective antenna
gain in Atoll should be reduced by the AGCF provided above. This can be accomplished
either by adding the AGCF value in the Losses field of the terminal or by modifying the
gain associated with the antenna. For example, if a CPE antenna is placed in a NLOS
scattering environment then a value of 2.86 could be entered in the terminals Losses
field or the antenna gain should be reduced by 2.86 dB (i.e. 7 2.86 dB).
In order to reduce the antenna gain, the user needs to open the specific antenna that is
associated with the subscriber device and modify the gain. Using the example above,
the user would need to reduce the antenna gain of the CPE Antenna model. (The
figure below shows the properties of the CPE, where the antenna model is set to CPE
Antenna 7dBi with a gain of 7 dBi.)
Revision 1.3
iProtect: Internal
Page 150
Continuing this example, the user would then reduce the antenna gain for the CPE
Antenna model by 2.86 dB, as seen in the figure below.
Revision 1.3
iProtect: Internal
Page 151
Alternatively, instead of reducing the antenna gain by the AGCF, the user could add this
AGCF to the losses associated with the subscriber device and achieve the same
results. To follow the example above, instead of reducing the antenna gain by 2.86, the
user could add 2.86 dB to the losses associated with the CPE device, as seen in the
figure below.
Revision 1.3
iProtect: Internal
Page 152
The antenna orientation loss is a reduction in the performance of the antenna due to the
antenna not being oriented in an optimal direction. This primarily applies to the case of a
fixed CPE that has some directionality to the antenna pattern (i.e. not perfectly omni).
Antenna orientation loss should be included in the RF design if:
Devices are being randomly installed (i.e. not optimally placed to insure
orientation for maximum performance).
Devices are not fixed to the installed location (i.e. the device can be
rotated or moved).
Revision 1.3
iProtect: Internal
Page 153
Both the antenna gain correction factor and the antenna orientation loss parameters
have a mean and standard deviation. As seen above, the mean values are used directly
to reduce the CPE antenna gain parameter. To account for the standard deviation is not
as straightforward. The following information regarding adjusting the lognormal fade
margin standard deviation due to subscriber antenna gain correction factor and the
antenna
orientation
loss
is
taken
from
the
RF
Planning
Guide
(http://compass.mot.com/go/310442223).
The following calculation can be used to derive a joint lognormal fade margin standard
deviation that incorporates the antenna gain correction factor and the orientation loss. A
new lognormal fade margin can be obtained after a new standard deviation is calculated
using the following equation.
xyz 2 = x 2 + y 2 + z 2 + 2 xy x y + 2 xz x z + 2 yz y z
Where
xy
xz
Revision 1.3
iProtect: Internal
Page 154
yz
xyz
Example:
Device
CPE
8 dB
xy
xz
yz
Revision 1.3
iProtect: Internal
Page 155
This opens the Clutter Classes Properties window, as seen in the following figure.
NOTES:
Note. 1. The Code field contains the clutter class code.
Note. 2. The Name field provides a descriptive name of the clutter class field.
Note. 3. The Height (m) field provides the average height for the clutter class.
Further information regarding setting the clutter class heights can be found
in Section 8.1.3.
Revision 1.3
iProtect: Internal
Page 156
Note. 4. The Model Standard Deviation (dB) field provides the standard deviation
value that is used when computing the shadow loss portion of the path
loss. This value is only used when the Shadowing taken into account
and Cell Edge Coverage Probability parameters are used when
generating predictions.
The per-clutter model standard deviation value (if not defined, then the
default value within the default tab) is used when the Shadowing taken
into account and Cell Edge Coverage Probability parameters are set
(refer to Section 9.2.2).
For capacity simulations, no model standard deviation is desired and the
model standard deviation value must be zero (0) to, effectively, disable its
use (since standard deviations are always applied within Atoll
simulations).
Note. 5. The C/I Standard Deviation (dB) field provides the standard deviation that
is used when computing shadowing losses on the C/(I+N) values, as
related to the user-defined Cell Edge Coverage Probability parameters
within the prediction parameters.
As mentioned in the model standard deviation note above, the C/I
Standard Deviation value is used when the Shadowing taken into
account and Cell Edge Coverage Probability parameters are set.
The per-clutter C/I standard deviation value for this parameter (if not
defined, then the default value within the default tab) is used for coverage
predictions, (refer to Section 9.2.2).
For capacity simulations, no model standard deviation is desired and the
C/I standard deviation value must be zero (0) to, effectively, disable its use
(since standard deviations are always applied within Atoll simulations).
Note. 6. The Indoor Loss (dB) field allows the user to provide a building penetration
loss value for the clutter class. This value is applied to the path loss and is
used in coverage predictions, point analysis, and Monte Carlo simulations.
If it is desired to apply a specific building loss throughout a coverage area,
then this loss would be included in each clutter class.
Building penetration loss is highly variable and is a function of items such
as construction material, building layout, user location inside the building,
proximity to the base station, and direction from the base station. It is
recommended that whenever possible, actual field data for the particular
environment be used to determine the building penetration loss.
Note. 7. The SU-MIMO Gain Factor field provides a factor that is applied to the
spatial multiplexing gain value that is obtained from the Max MIMO Gain
graphs in the MIMO tab within the LTE Equipment Reception properties.
Revision 1.3
iProtect: Internal
Page 157
The SU-MIMO Gain Factor is used to adjust the Max MIMO Gain. The
user needs to enter a value between 0 and 1. A 0 indicates that no SUMIMO gain will be included and a 1 indicates that the maximum SU-MIMO
gain from the curve will be included. A 0 is used for mainly LOS cases
(such as in a rural environment), a 1 is used for NLOS cases (such as in a
dense urban environment), and a value between 0 and 1 is used for a
mixture of LOS and NLOS.
The Max MIMO Gain and the SU-MIMO Gain factor are used in the Atoll
throughput calculations. The throughput is adjusted by the following factor:
[1 + SU-MIMO Gain Factor * (Max MIMO Gain 1)]
For example, assume that the CINR at a pixel is 15 dB and the MAC
channel throughput without including MIMO considerations is 1000 kbps.
Based on the information in the MIMO tab of the LTE Equipment
Reception properties interface, the CINR of 15 dB equates to a Max MIMO
Gain of 1.21082. This gain is then adjusted by the SU-MIMO Gain Factor
that is associated with the clutter class of the given pixel, as demonstrated
below:
SU-MIMO Gain Factor = 1
If the SU-MIMO Gain Factor for that pixel is 1, then the maximum SUMIMO gain from the Max MIMO Gain curve would be incorporated into the
throughput results. In this case, the throughput would be 1210.82kbps (i.e.
1000 * (1 + 1 * (1.21082-1))).
Note: Factor = 1 is the default for all clutter and is the recommended
setting.
SU-MIMO Gain Factor = 0
If the SU-MIMO Gain Factor for that pixel is 0, then no SU-MIMO gain
would be applied to the throughput, resulting in a throughput of 1000 kbps
(i.e. 1000 * (1 + 0 * (1.21082-1))).
SU-MIMO Gain Factor = 0.5
If the SU-MIMO Gain Factor for that pixel is 0.5, then an SU-MIMO gain
between the maximum SU-MIMO gain from the Max MIMO Gain curve
and no SU-MIMO gain would be applied to the throughput results. In this
case, the throughput would be 1105.41 kbps (i.e. 1000 * (1 + 0.5 *
(1.21082-1))).
Note. 8. The Additional Transmit Diversity Gain (dB) field provides a value that is
added to the users downlink C/(I+N) in cases where the user and its
reference cell support Diversity. This is set to 0 dB in the Motorola
template and should not need to be changed. As discussed in Section
7.2.3.4.2, the MRC diversity is handled in the MIMO tab of the LTE
Equipment Reception properties interface (within the Diversity Gain
Revision 1.3
iProtect: Internal
Page 158
Revision 1.3
iProtect: Internal
Page 159
Atoll offers a number of propagation models to choose from. The available propagation
models are accessed under the Modules tab of the Explorer window as shown in Figure
107.
Revision 1.3
iProtect: Internal
Page 160
The primary Atoll model that can be automatically tuned using drive-test data is the
Standard Propagation Model (SPM). Model tuning is required for a commercial
system design in order to produce accurate signal strength estimates (i.e. <2 dB
mean error and <8.5 dB error standard deviation). Since model tuning will eventually
be needed during the design process, the recommendation is to start with the SPM
model. Reasonable default parameter settings can be used for the earlier phases of
system design where drive-test data is typically not available.
The purpose of this section of the document is to describe a set of default parameters
for use with the SPM when drive test data is not available. These default settings are
saved in the LTE Motorola template as the eight different propagation model options
highlighted in Figure 107. A separate model is available for each of the LTE bands of
interest. All of these models use the Atoll SPM configured with Motorolas
recommended parameter settings.
Using the prescribed default parameters in the Motorola versions of the SPM model will
result in reasonable propagation predictions when the base station antenna heights are
above the height of the surrounding clutter. Section 8.1.4 provides some options for
predicting pathloss when the base station antennas are below the clutter height. The
default parameters described in this section of the document are only recommended for
use in the initial phases of system design to obtain budgetary results. As noted earlier,
Revision 1.3
iProtect: Internal
Page 161
model tuning with drive-test data is required for accurate commercial system
design.
This section of the document does not cover all the available propagation models or
even all of the details of the SPM. Please refer to the internal document entitled Atoll
Propagation Model Parameter Settings and Validation for additional information on the
SPM equation, the rationale behind the selection of the default parameter settings, and
the results of accuracy validation testing. The Forsk documents entitled Atoll User
Manual and Atoll Technical Reference Guide can be referenced for additional detail
on the available propagation models.
If drive-test data is available, then it should be used to tune the SPM employing the
procedure found in the Forsk document entitled Measurements and Model Calibration
Guide. Section 8.2 of this document also provides additional guidelines on propagation
model tuning.
8.1.2.
The following image shows the recommended parameter settings for the 2.5 GHz band.
Settings for the other bands are the same with the exception of the k1 intercept related
parameter, which is unique to each band. The diffraction loss component of the overall
pathloss is also a function of the operating frequency and will therefore be inherently
different for the various LTE bands of interest. As previously noted, these parameters
are only valid when the base station antenna is above the clutter. Pathloss predictions
may be on the order of 20 dB too high if the base station antenna is below the
surrounding clutter. The SPM is not designed for below-rooftop propagation prediction.
Revision 1.3
iProtect: Internal
Page 162
8.1.3.
A set of clutter parameters that produce reasonable results is shown in Figure 109. Note
that the clutter heights are in parentheses next to the clutter category name.
Revision 1.3
iProtect: Internal
Page 163
The clearance shown in Figure 109 must be set to 10m. It is important to leave the
clearance at 10m. Changing the clearance distance requires a coordinated change of
other parameters in order to obtain valid results.
The clutter heights for the open categories such as Low Vegetation,
OpenBarren_Land, Water Bodies and Transportation_Infrastructure should be set
to 0. Other parameters related to the exponent-based loss are set to values that will
produce reasonable pathloss estimates when the clutter height is 0 for open areas.
The clutter losses shown in Figure 109 are all set to zero. This is consistent with Forsks
recommendations when using clutter heights in diffraction (i.e. Clutter taken into
account in diffraction set to yes as seen in Figure 109). However, clutter loss for
foliage categories deserves additional consideration. The foliage categories do not
typically require additional loss because Atoll treats foliage the same as other clutter
categories and computes diffraction loss over the foliage. As an example, the Forest
category in Figure 109 is set to a clutter height (i.e. 8 m) that is greater than most of the
other solid clutter categories, so there is an increased loss associated with tree
categories, which is typically desirable. However, in the case where the signal must
propagate through a significant distance of foliage between the transmitter and
receiver, additional loss on the order of 5 8 dB should be added to the foliage
clutter categories. Unfortunately, this is not an exact science, and again, it is
necessary to tune the model with drive test data in order to obtain more accurate
results.
It is important to use high quality, accurate clutter data. Part of configuring and running
the SPM is to check the clutter data using Google Earth and local knowledge of the area
being designed. This can be as simple as a visual check comparing land use in Google
Earth to the clutter image in Atoll. If there are inconsistencies in the clutter
classifications, then Atolls clutter editor feature can be used to modify the
classifications. Please refer to the Atoll User Manual for information on using the clutter
editor feature. The clutter heights themselves may also need to be adjusted based on
Revision 1.3
iProtect: Internal
Page 164
local knowledge of the areas being modeled. The predicted pathloss scales directly with
clutter height, so increasing clutter height will increase predicted pathloss and
conversely decreasing clutter height will reduce the predicted pathloss.
8.1.4.
As noted earlier, the SPM is designed for modeling pathloss when the base station
antenna height is above the clutter height. To illustrate the issue, Figure 110 shows a
site where several isolated areas of high clutter (circled in red) have been added using
Atolls clutter editor. The height of the base station is 30m and the height of the isolated
high clutter is 50m. Figure 111 shows the resulting signal strength prediction plot. As
seen in this image, long shadows are cast beyond the high clutter height obstructions.
These predicted diffraction shadows are typically unrealistic, given the amount of
reflection that occurs off of surrounding clutter. The SPM is not capable of considering
the reflections in detail, so the pathloss prediction has significant error when the base
station antenna height is below the clutter height.
Revision 1.3
iProtect: Internal
Page 165
Figure 111: Signal Strength with Base Station Antenna Height Below Clutter
A possible solution for modeling systems where the base station height is below the
surrounding clutter height is to use one of the third party ray-tracing add-in modules that
are available for Atoll. Siradel Volcano and WaveCall WaveSight are the primary
options for ray-tracing. These tools do consider reflections in detail and would
presumably do a much better job of predicting signal strength for low antenna height,
micro-cellular, dense urban systems. Unfortunately, evaluation of these tools has not
been prioritized at this time. As such, a recommendation for which ray-tracing tool to
select has not been decided and this procedure will not provide any detail on using a
ray-tracing propagation model. Recommendations and design procedures for raytracing will be available in a future release of this document, once the ray-tracer
evaluation is prioritized.
In the meantime, until a full evaluation of ray-tracing tools is complete, there needs to be
some way of making a reasonable estimate of pathloss in dense urban environments
with below rooftop base station antennas when drive-test data is not available. As such,
the recommendation for now is to use Atoll Hata Metropolitan Center for predicting
pathloss in uniform, dense urban environments where the base station antenna is below
the surrounding clutter height. To obtain more accurate results, drive-test data should
Revision 1.3
iProtect: Internal
Page 166
be collected from the dense urban areas and used to tune an SPM for this specific
scenario.
The Atoll Hata Metropolitan center approach was employed to analyze measured
pathloss versus predicted pathloss for six sites in downtown Chicago. The mean
prediction error was -2.1 dB and the prediction error standard deviation was 8.1 dB for
all six sites combined together. Figure 112 illustrates the use of Atoll Hata
Metropolitan center for predicting pathloss in downtown Chicago. The plot is for one of
the six sites where data was collected and shows the relatively close match between
the Atoll Hata predictions and the measured data. Please refer to the document entitled
Atoll Cost-231 Hata Urban Prediction Accuracy Analysis for Downtown Chicago for
additional information on the Chicago propagation pathloss analysis.
Figure 112: Measured versus Predicted Pathloss in Dense Urban Area Using Hata
Cost-231 Hata for a given environment can be applied over the entire coverage area by
setting the formula for every clutter class to the same Hata environment as seen in
Figure 113. In this case, Metropolitan center was used everywhere. This was
applicable because the cell sites were immersed in a uniform dense urban environment.
The goal was to model pathloss with a straight Hata formula and not vary the formula
according to clutter class. If the cell sites are in a uniform, dense urban environment
with base station antenna heights below the clutter, then using Atolls Cost-Hata model
configured as in Figure 113 should produce reasonable results. The results will
definitely be better than using an un-tuned SPM with clutter heights in the diffraction.
Note that the first parameter in Lu is set to 46.3. This is 3 dB lower than the default
Revision 1.3
iProtect: Internal
Page 167
value of 49.3 that Atoll uses. 49.3 corresponds to COST-231 Hata Dense Urban
whereas 46.3 corresponds to Urban. For the Chicago testing described above, Urban,
using 46.3, was the best fit.
The next several sections provide information on collecting the drive-test data that will
be used in model tuning.
8.2.1.1. CW Versus Test CPE
The SPM can be tuned using either Continuous Wave (CW) data or RSS from an LTE
test CPE. The recommendation is to use narrowband CW test equipment for model
tuning. CW test equipment is the best choice for the following reasons:
-
The signal strength averaging algorithm is controlled by the end user and can be
set to ensure collection of local mean signal strength using the Lee criteria (i.e.
Revision 1.3
iProtect: Internal
Page 168
The Gator transmitter and Coyote receiver products from Berkely Varitronics have
proven to be good tools for transmitting and receiving the required CW test signals for
propagation measurement. See the link below for additional information on these tools.
http://www.bvsystems.com/Products/LTE/LTE.htm
If a test UE is used, then there are several important considerations:
-
UEs are typically diversity receive. If both antennas are used during the drivetest, then this adds uncertainty in the measurement result because the diversity
gain is variable as a function of the environment. As such, only one antenna port
of the UE should be used and the other antenna port should be terminated with a
50 ohm load.
The UE antenna may not be perfectly omni-directional and may also be a high
gain antenna with a compressed vertical pattern. Furthermore, the antenna is
typically connected to the UE directly, which is not ideal for drive-testing. As
such, the recommendation is to use a separate external low gain (e.g. 0 dBd)
omni-directional antenna that is connected by a cable to the UE, which resides in
the drive-test vehicle. The omni antenna should be a mag-mount that is
specifically designed to operate on the vehicle roof.
Revision 1.3
iProtect: Internal
Page 169
As per the Forsk guidelines, a minimum of approximately 8 sites are required per area
type for model tuning. However, it is likely that some of the sites will be deemed
unacceptable after analyzing the collected data, so it is highly recommended to gather
drive test data from at least 10 sites per area type.
Separate propagation models should be tuned for each unique area type within the
service area. Then, for propagation prediction in Atoll, the appropriate tuned model is
selected on a per sector basis within Atoll. Characteristics that should be considered in
identifying the area types are building heights and density, foliage heights and density,
street width, and terrain flatness. As an example, Figure 114 illustrates the need for
separate models based on foliage density. The site to the south in Figure 114 is clearly
in a more densely foliaged area than the nearby site to the north. The graphs of
measured pathloss for these two sites show a large difference in the slope and intercept
of the measured pathloss best-fit lines. In order to accurately account for this large
difference in pathloss, separate tuned propagation models would be needed for sites in
the densely foliaged areas and for sites in the less densely foliaged areas
Revision 1.3
iProtect: Internal
Page 170
Atolls propagation model auto-tuner uses a linear least squares error algorithm to fit a
pathloss versus distance line to the collected pathloss data. As such, it is important to
collect equal amounts of drive-test data near the site and far from the site. The reason is
that the least squares error algorithm will always result in a solution that minimizes the
mean square error between the best fit line and the collected data points. If there is only
a small number of data points collected near the site, then the result of the best fit
Revision 1.3
iProtect: Internal
Page 171
algorithm will be weighted more heavily towards the data points collected far from the
site. This often results in a tuned model with a slope that is lower than it should be.
The following two graphs illustrate the issue in accurately calculating the pathloss slope
using the least squares method. In the first image, only the measured drive-test points
are used to create the graph. Looking at Figure 115, the slope of the least squares
trendline appears shallow as compared to a visual inspection of the data. The
calculated slope shown in the legend is 29.2 dB/decade, which also seems low given
that this data was collected in a dense urban area. The trendline appears to be getting
pulled towards data points at greater distances and away from data points closer to the
site. Since the trendline is calculated to minimize the mean square error between all of
the measured points and the trendline itself, the trendline will be biased towards areas
where there are more sample points. Near the site, there are fewer samples, as clearly
seen by the lower density of blue points at smaller distances. As such, the trendline is
being skewed towards points at greater distances.
The graph in Figure 116 shows the case where the dataset of Figure 115 is used, but in
this case, each drive test point at a distance of 400m or less was replicated 100 times to
increase the weight of those points near the site. The trendline in Figure 116 now
appears to do a better job of fitting the entire dataset from near to the site all the way to
the furthest range from the site. The calculated slope of the trendline shown in the
legend has increased from 29.2 dB to 33.9 dB, which is more consistent with
expectations for a dense urban area. While the difference of 29.2 db/decade versus
33.9 dB/decade may not seem overly significant, the predicted CINR is extremely
Revision 1.3
iProtect: Internal
Page 172
sensitive to slope. This difference in slope would translate into a significant reduction in
predicted CINR.
Figure 116: Weighted Drive Data with Least Squares Trendline
The above example illustrates the need to either collect approximately equal amounts of
data across all distances between the site and the outer edge of the drive routes or
when post processing the data to add weight to areas where fewer points have been
collected. The preferred approach is to configure the drive routes to collect
approximately equal amounts of data as a function of distance from the test site.
The next consideration in selecting drive routes is that it is important to uniformly
sample the test area. The pathloss is impacted by the environment (including foliage
density, street width, building height/density, terrain height, etc.). Collecting data in only
a small part of the coverage area will bias the results to those particular areas. The goal
is to uniformly sample the entire testing area. The drive test routes should be configured
to equally cover cross streets and parallel streets.
Figure 117 gives a good example of how drive routes should be configured. As seen in
the image, the drive routes are evenly spaced, equally cover north-south and east-west
streets, and cover the entire service area, extending as far as possible until reaching the
noise floor of the measurement equipment.
During post processing, it will be possible to segregate the drive data according to area
type or other differentiating factors. As such, the best approach for collecting the data is
to collect everywhere and then leave the filtering to the post processing steps described
in Section 8.2.3.
Revision 1.3
iProtect: Internal
Page 173
As described in the Forsk model tuning document, it is necessary to create a log sheet
for each site tested to record all pertinent information that will be needed later when
processing the data to obtain the tuned model. Pictures similar to those shown in Figure
118 should also be included in the information to obtain for each site tested. The
pictures should capture a 360 degree view from the site. These photographs will help in
analyzing the drive-test data to determine if some of the data should be filtered. For
example, the pictures may help to recommend removing areas that are blocked by
equipment, etc. on the roof where the test transmitter is deployed.
Revision 1.3
iProtect: Internal
Page 174
8.2.2.
In order to produce a valid propagation model from the drive-test data, Atoll must predict
received signal strength that is consistent with the measured received signal strength.
This means that the predicted and measured signal strength take the same end-to-end
gain and loss components into consideration. Typical gains and losses that must be
properly accounted for include:
-
TX Power
TX Cable/Connector Loss
TX Antenna Gain
RX Antenna Gain
RX Cable/Connector Loss
When using data collected from a test UE, there are additional factors that must be
properly accounted for. The RSS that is recorded in the log file may represent different
values depending on the UE being used. It must be understood exactly what the RSS
measurement represents and make sure to either setup Atoll to match this or post
Revision 1.3
iProtect: Internal
Page 175
One of the most important steps in the model tuning process is filtering the collected
drive-test data. The tuned model will likely be in error if the drive-test points are not
properly filtered prior to running the automated model tuning algorithm. Refer to Forsks
model tuning document for detailed information regarding the filtering requirements.
Some key points are as follows.
8.2.3.1. Filtering for Linear Least Squares Analysis
As noted earlier in Section 8.2.1.3, Atoll uses a linear least squares algorithm to
calculate a best-fit line to the collected drive-test data. In order for the algorithm to work
properly, the input data must have approximately linear pathloss versus log-distance.
Prior to filtering, the drive-test data will most likely not have linear pathloss versus logdistance. Even a small number of erroneous or outlier points can cause the results of
the tuning algorithm to be non-optimal. Figure 119 shows an example of measured RSS
versus log-distance prior to filtering. An approximate best-fit line has been drawn on the
graph for reference. There are a number of candidates for filtering that are circled on the
graph in red and described as follows:
Note. 1. A high gain omni-directional base station antenna was used to collect this
data. As such, the antenna pattern has high attenuation and high variability
near the site. As seen in the image, the points circled and labeled Note 1
are near the site and deviate significantly from the best-fit line. These points
should be filtered from the analysis to avoid error.
Note. 2. There will often be groups of points that appear to be offset from the main
trend. If the points have significantly higher signal strength than the trend,
then they are likely associated with an area that has line-of-sight or near lineof-sight to the base station. The issue is that the clutter database is typically
not accurate enough to consistently identify line-of-sight versus non line-ofsight areas; therefore, these areas have potential to introduce error in the
optimization result. When there are only small areas like this, its best to filter
them out of the optimization. The goal is not to optimize the model for these
few small areas; rather, the goal is to optimize for the majority of the area
where the CPE units will actually be deployed.
Note. 3. There will also often be groups of points that are offset from the main trend
towards lower measured signal strength. These areas are associated with
higher than typical loss such as in densely foliaged areas. If there are only a
few such places, they should be removed from the optimization since, again,
the goal is to optimize for the majority of locations where UEs will be
deployed.
Revision 1.3
iProtect: Internal
Page 176
Note 1
Note 2
Note 3
Figure 120 shows the same drive-test data after filtering. As shown circled in this image,
about 5% of the data has been filtered leaving the remaining 95% of the data that most
closely follows the linear trend.
Revision 1.3
iProtect: Internal
Page 177
Figure 121 shows an example where the RSS at a given distance has reached the
minimum measurement level of the receiver. One approach that is often used to
account for the receiver sensitivity is to apply a minimum signal strength filter. However,
the issue with this approach is that it tends to skew the optimization results towards
higher signal strength or, equivalently, lower loss.
Figure 121: Example of Measurements at the Receiver Noise Floor
Revision 1.3
iProtect: Internal
Page 178
A more accurate solution is to filter on distance (i.e. enter a distance in the Min Distance
box) where the distance is selected to ensure that the low end of the signal strength
versus distance is not being clipped by the receiver minimum measurement threshold.
Figure 123 shows the correct filter distance as indicated by the red vertical line to the
right. This is the distance at which the receivers minimum measurement threshold has
just been reached.
Figure 123: Maximum Distance Filter to Avoid Clipping
Revision 1.3
iProtect: Internal
Page 179
If a directional antenna is used for the transmitter under test, then it is important to apply
an angle filter to ensure that only drive-test points within the main beamwidth of the
antenna are included in the analysis. The antenna pattern typically changes rapidly
away from the main beamwidth which results in high prediction error that tends to
introduce additional error in model tuning.
Filtering on angle is also advisable when there is an obstruction near the test antenna,
for example, if there was a large equipment penthouse on the roof where the test
transmitter is located.
As noted earlier, the vertical antenna pattern typically changes rapidly near the site;
therefore, it is necessary to filter test points that are within approximately 200 to 250m
from the site. However, rather than just selecting a fixed minimum filter distance, the
preferred approach is to use the Filtering Assistant tool in Atoll to view the graph of
pathloss versus distance and select a minimum distance such that the remaining data
has essentially linear pathloss versus distance.
8.2.3.5. Filtering Clutter Classes
As described next in Section 8.2.4, it is not recommended to tune clutter losses per
clutter category when using clutter heights in the diffraction loss calculation. As such,
filtering clutter categories is not so much based on the number of samples per clutter
category as it is on filtering clutter categories that do not match with your model tuning
goals. For example, if the drive route includes both urban and dense urban areas and
the goal is to tune a model for urban areas, then the filter to select the points in the
dense urban clutter categories should be used.
8.2.4.
Calibration results are dependent on the starting values for the tuning parameters;
therefore, the recommendation is to make a duplicate of the Motorola model by right
clicking the model and selecting Duplicate. Double click this copy and rename it to
reflect an appropriate name for the tuned model. Next, begin the calibration of this
model by right clicking and selecting Calibration. After selecting the drive-test data to
be used in the calibration, the following screen in Figure 124 will be presented. Note
that the starting parameters in this image are for the Motorola 2.5 GHz (SPM) V2
model and will be slightly different for the other frequencies. Also note that the status of
the check boxes in this image are based on the Atoll defaults and need to be changed
as described in the following sections.
Revision 1.3
iProtect: Internal
Page 180
Atoll offers a number of options for calculating the virtual base station antenna height
that is used in computing the exponent based pathloss. These various methods
primarily apply when clutter heights are not used in the diffraction calculation. The
Motorola models use clutter height in diffraction; therefore, the recommendation is to
use the Height above the ground method, where the virtual height is the same as the
actual height of the antenna above ground level. Allowing Atoll to optimize with the HTx
method may result in slightly better accuracy in the areas with the drive-test data;
however, may produce unexpected results in areas where drive-test data was not
collected. The HTx method checkbox should be unchecked for model tuning.
8.2.4.2. Diff. Method
Atoll offers a number of methods for computing diffraction loss. Some of the methods
use a single knife edge approach and others use a multiple Knife-Edge approach. The
recommendation is to fix the approach to Deygout with correction (ITU526-5). This is a
multiple-knife-edge diffraction method with an additional distance based correction
factor. The Diff. method checkbox should be unchecked for calibration so that the
selection remains at the Motorola default of Deygout with correction (ITU526-5).
8.2.4.3. K1 and K2
K1 and K2 are the intercept and slope related parameters, respectively, for the
exponent based loss portion of the overall pathloss. These are the primary factors to be
adjusted by the auto-tuner. The default range for K1 is 0 100. This range makes
sense when clutter heights are not used in diffraction; however, when clutter heights are
Revision 1.3
iProtect: Internal
Page 181
used in diffraction, as is the case with the Motorola models, then K1 can be even less
than 0 due to the extra diffraction loss associated with the clutter. Therefore, the
recommended range for K1 is -20 to 100. The range for K1 is set by clicking in the K1
row and then clicking Define Range .
The default range for K2 is 20 70 and is acceptable as a starting point. However, as
noted in Section 8.2.5, that follows, the model tuning results will need to be validated to
ensure, for example, that K2 did not get erroneously tuned to such a low value that the
slope of the predicted pathloss versus distance is lower than the measured slope. The
K1 and K2 checkboxes should be checked for calibration.
8.2.4.4. K3
K3 adjusts the exponent based loss intercept as a function of the log of the base station
virtual height. As noted above, selecting the Height above the ground HTx method
means that the base station virtual height is actually the height above ground level. The
default range of -20 to +20 is acceptable for this parameter. However, this parameter
should only be tuned if the input data was collected at multiple base station antenna
heights that cover the full range of antenna heights expected for the final system
deployment. If the measured RSS data was collected from sites where the antenna
heights do not cover the expected range of antenna heights for the final deployment,
then the K3 checkbox should be unchecked for model tuning and the default Motorola
value should be used.
8.2.4.5. K4
K4 is a multiplication factor for the calculated diffraction loss. The valid range is 0 to 1,
where 0 means that no diffraction loss will be included in the overall pathloss result and
1 means that the full calculated value of diffraction loss will be included in the overall
pathloss result. All values between 0 and 1 will serve to scale the calculated diffraction
loss from 0 to its full value. The issue with optimizing K4 is that the Atoll auto-tuner will
often adjust K4 down to a low value such as 0.1. This may result in good prediction
error standard deviation; however, low K4 will produce unrealistic predictions for
shadowed areas (such as behind hills, etc). High values of K4, above 0.6, will result in
ever increasing prediction error standard deviation when using the typical clutter
databases that are available at reasonable cost. The prediction error standard deviation
increases with increasing K4 because the databases have only approximate clutter
heights and the clutter classification itself has limited accuracy; therefore, the diffraction
loss errors associated with the database are magnified at higher K4 values. As noted
above, lower K4 values are also an issue because, for example, if there is a large hill in
the service area and K4 is set very low, then the calculated diffraction loss over the hill
will be too low. Therefore, the goal in selecting a value for K4 is to achieve a balance
between the errors at high K4 and the errors at low K4. A K4 value of 0.6 has been
deemed to be an optimal choice to reach the desired balance. The K4 checkbox should
be unchecked for calibration.
Revision 1.3
iProtect: Internal
Page 182
8.2.4.6. K5
K5 scales the slope of the exponent based loss as a function of the log of the base
station antenna height. The default range of -10 to 0 is acceptable for this parameter. As
is the case with K3, K5 should only be tuned if the input data includes data from base
station antennas that cover the full range of heights expected for the final system
deployment. If the input data does not cover the full range of antenna heights, then the
K5 checkbox should be unchecked for calibration.
8.2.4.7. K6
K6 is a straight multiplier to the receiver effective height, where the effective height of
the receiver is calculated as the difference between the ground level at the transmitter
and the ground level at the receiver plus the height above ground of the receiver
antenna itself. This parameter is mainly applicable when the SPM is being configured as
a statistical propagation model without clutter heights used in diffraction. When clutter
heights are used in diffraction, as is the case with the Motorola settings, there is an
inherent accounting of the effect of the receiver height in the diffraction loss calculation.
If the receiver height is high, for example above the clutter, then the diffraction loss will
be low. Conversely, the diffraction loss will increase as the receiver height relative to the
base station antenna height and clutter is reduced. K6 should be set at the default of 0
and the K6 checkbox should be unchecked for calibration.
8.2.4.8. K7
K7 adjusts the exponent based loss intercept as a function of the log of the effective
receiver height, where the effective receiver height is calculated as the difference
between the ground level at the transmitter and the ground level at the receiver plus the
height above ground of the receiver antenna itself. K7 should be set at the default of 0
and the K7 checkbox should be unchecked for calibration.
8.2.4.9. Clutter Losses
If the Clutter Losses checkbox is checked, then Atoll will automatically optimize the
clutter loss per clutter category. The recommendation is to leave the Clutter Losses
checkbox unchecked during calibration. This is consistent with Forsks recommendation
to not use clutter losses when clutter heights are included in diffraction loss. While
better results would likely be possible if the clutter heights could be automatically tuned
per clutter category, tuning K1 and K2 does a good job of producing a nearly optimal
result. If desired, clutter heights can be manually adjusted in an effort to reduce the
mean prediction error and standard deviation. The mean prediction error and standard
deviation per clutter category are displayed after running the prediction calculations for
the drive routes by right clicking on CW Measurements and selecting to display
statistics. An iterative process of manually adjusting clutter heights, running the model
tuner, and calculating statistics to view the impact on the mean prediction error and
standard deviation can be done to optimize the prediction error and standard deviation.
Revision 1.3
iProtect: Internal
Page 183
One key issue with tuning on a per clutter category basis is that the newer clutter
databases typically have roads burned into the clutter and, as such, the vast majority of
collected drive-test data ends up being ascribed to the road category. The idea of tuning
per clutter category is that there should be some correlation in pathloss versus distance
as a function of the clutter category. However, this typically does not apply with the road
category because it passes through numerous other types of clutter. There may be little
or no correlation in pathloss versus distance for the data points in the road category.
This leads back to the procedure of simply tuning K1 and K2 and not focusing on trying
to tune per clutter category. However, if there is a desire to tune per clutter category,
then this road issue can be overcome by reclassifying the drive-test points that are on
the roads. The procedure to do this is as follows:
a. Use Atolls clutter editor tool to change the clutter coding for the roads
where the drive-test data is located. This is done by selecting the desired
clutter category in the clutter editor interface and drawing polygons around
the drive-test data.
b. Right click on CW Measurements and select to Refresh Geo Data.
c. Select all of the clutter polygons that were drawn in Step 1 and delete
them.
By following these steps, the drive-test points will have been reclassified according to
the clutter classes drawn using the clutter editor. Once the drive-test geo data has been
refreshed, the new classifications will remain in effect until another refresh of the geo
data is performed. Even if new clutter data is loaded or additional clutter edits made, the
drive-test classification will not change until select Refresh Geo Data is performed
again. Deleting the drawn clutter polygons as in Step c, ensures that the proper clutter
classification is used for the propagation predictions; however, removing the clutter
polygons will have no affect on the drive-test point classification. In the end, the correct
propagation predictions will be obtained, as well as, the desired classification of drivetest points.
8.2.4.10.
After following the above procedures, the final configuration screen for the model tuning
run will be as depicted in Figure 125. This is for the case where drive-test data was
collected for various test transmitter heights that cover the full range of expected
antenna heights for the final deployment. If data was not collected across various
antenna heights, then K3 and K5 would also be unchecked.
Revision 1.3
iProtect: Internal
Page 184
8.2.5.
There are many things that can go astray in tuning the propagation model. The main
issues are related to the input data used to tune the model and whether or not the data
was properly gathered, post processed, and filtered. In order to validate that the tuned
model is working correctly, it is necessary to analyze the prediction results.
As described in the Forsk model tuning document, at least two sites per area type
should be used to validate the results of model tuning. These two sites would not have
been used in the model tuning. Rather, the tuned model is applied to these two sites
and then the resulting prediction error statistics are reviewed (please refer to the Forsk
SPM Calibration Guide for the steps required to generate the validation statistics). The
prediction error should typically be within +/- 2.5 dB and the standard deviation should
be approximately 8.5 dB. If the prediction error is significantly outside of this range, then
there is likely some anomaly in the input data, filtering of the data, or other area that will
need to be investigated.
Revision 1.3
iProtect: Internal
Page 185
A good way to validate the tuned model is to plot the predicted RSS versus distance on
a graph. One of the main things to look for on this graph is whether or not the slope of
the predictions matches closely with the slope of the measured RSS versus distance.
This can be done by exporting the drive test table after calculating predictions using the
tuned propagation model and then analyzing the data with a data analysis tool ( please
refer to the Forsk SPM Calibration Guide for more information on working with drive
test data tables). For example, Figure 126 shows an example where the measured and
predicted RSS is plotted using Microsoft Excels X-Y scatter plot. Excel allows the user
to select the data series, right click, and choose to have a trendline added to the graph.
The trendlines in this plot are useful to show how closely the slope of the predictions
match with the measured data. In this case, the predicted trend matches closely with
the measured. This result serves to validate that the tuned model is working correctly.
Excels trendline function produces an equation that is in the form of Aln(x) + B, where
A is the slope of the natural logarithm and B is the 1 m intercept. While it is more
conventional to see propagation model equations in terms of logarithm base 10, the
Excel output is still useful for comparing the relative slope between predicted and
measured pathloss. The goal is to determine if the slope of the measured RSS versus
distance is at least close to the slope of the predicted RSS versus distance. If the slope
in terms of log base 10 is desired, then multiply Excels trendline slope by 2.303 to
convert from natural log to log base 10.
Revision 1.3
iProtect: Internal
Page 186
Figure 127 shows an example using a different statistical analysis tool to plot the
predicted pathloss versus measured pathloss along with the associated trendlines and
reference lines for the Hata and free space loss propagation models. This example
shows a case where the predicted slope is much lower than the measured slope (i.e.
39.6 dB/decade for measured and only 27.7 dB/decade for the predicted). This result
would serve to invalidate the tuned model and would be cause for further investigation
into the model tuning process. Questions should be asked, such as; was the drive data
collected uniformly across the service area, are there parts of the service area where
data should be filtered out (e.g. due to dense foliage, open areas, water, hills, etc.), is
there enough data near the site or are the results being skewed towards data further
from the site, have proper distance filters been applied to avoid erroneous data under
the base station antenna and to avoid data clipping at the edge of the receivers
sensitivity, and the various other concerns that have been raised in this propagation
model tuning section of this document.
Figure 127: Example of Model with Low Slope
Looking at combined statistics for all transmitters used in model tuning will typically
show 0 dB mean error and low standard deviation. It is useful to plot prediction error
separately for each transmitter, using a bar graph in Excel for example, in order to see
how the mean error varies from site-to-site. Please refer to the Forsk SPM Calibration
Guide for information on generating error statistics per transmitter. If there are sites
with a large mean prediction error, then that would warrant additional investigation into
the model tuning results and the input data itself. Figure 128 shows an example of a plot
of mean prediction error versus test site number. It illustrates that there are several sites
Revision 1.3
iProtect: Internal
Page 187
with a high prediction error. These sites should be investigated further to better
understand the cause of the prediction error.
Figure 128: Mean prediction error per test site
Revision 1.3
iProtect: Internal
Page 188
8.3.1.
Each of the different zones can be created using a variety of methods, such as:
1. Drawing a zone using the polygon tool
2. Using an existing polygon (e.g. an administrative boundary map) within
the project (except Hot Spot Zone)
3. Fitting a zone to the Map Window size
4. Importing a polygon from a variety of sources (MIF, Shape, DXF, etc).
Make sure the imported data shares the same coordinate system as the
project.
Revision 1.3
iProtect: Internal
Page 189
Revision 1.3
iProtect: Internal
Page 190
8.3.2.
Filtering Zone
A Filtering Zone (represented with a Blue Line) can be defined from the Geo tab. A
Filtering Zone restricts the objects displayed on the map and on the Data tab of the
Explorer window to only include the objects that are within the Filtering Zone. It also
restricts which objects are used in calculations (such as coverage predictions,
simulations, etc.). Refer to Figure 132 for an example.
One use of the Filtering Zone would be to run a study of a portion of the system. One
could define a Filtering Zone around this portion of the system and then only the sites
within that zone would be included in any study that is run while the filter is included (i.e.
only the sites that are within the zone are displayed and active). If the user later wants
to run a study of the entire system, the Filtering Zone definition can be deleted and all
active sites would once again be included in a subsequent study.
8.3.3.
Computation Zone
A Computation Zone (represented with a Red Line) defines a region where calculations
(path loss matrices, coverage studies, etc.) will be performed. Pixels within the
Computation Zone are included in the calculations. Pixels outside the zone are not
included. The calculations in the Computation Zone include predictions from base
stations which are active, filtered (i.e. filtered in), and whose propagation zone
intersects a rectangle containing the Computation Zone. Figure 132 shows a prediction
study where sites outside of the Computation Zone still impact the study. A propagation
zone for a site is bounded by a square centered on the site with an area of 2R x 2R
where R is the maximum radius specified for the propagation model (as seen in Figure
133). For a site to be included in the Computation Zone calculations, it is sufficient for
Revision 1.3
iProtect: Internal
Page 191
its propagation zone to intersect the rectangle encompassing the Computation Zone
(i.e. the propagation zone does not necessarily need to intersect the Computation Zone
polygon). Refer to Figure 133. Within this figure, the dashed green line represents the
rectangle that encompasses the red Computation Zone polygon. All of the sites whose
blue propagation zone squares intersect this green rectangle would be included in the
Computation Zone calculations.
If there is no Computation Zone specified, Atoll will use all active transmitters in its
calculations. Use of Computation Zones is recommended for studies involving large
networks to reduce the time needed for calculations.
Figure 132: Example of Filter Zone and Computation Zone
Revision 1.3
iProtect: Internal
Page 192
Within this figure, the blue polygons represent the propagation zones for each of the
individual sites, the red polygon represents the Computation Zone, and the green
rectangle represents the rectangle that encompasses the Computation Zone.
8.3.4.
A Focus Zone (represented with a Green Line, as seen in the following figure) allows
the selection of areas of coverage predictions or other calculations on which reports,
statistics and results are generated.
If there is no Focus Zone defined, then the Computational Zone will be used.
There can only be ONE Focus Zone per project.
Hot Spot Zones (represented with a Black Line) are similar to Focus zones in most
respects, except that there can be multiple Hot Spot Zones throughput the project.
An existing polygon can also be used as a Hot Spot Zone by selecting the original
polygon under the Geo tab of the Explorer window and right clicking on the zone type.
This opens a context window from which Export is selected. Export the zone to a file.
The exported file can then be imported as a new Hot Spot zone by right clicking on the
Hot Spot icon, selecting Import from context window, and selecting the recently saved
polygon file.
Figure 134 below shows a Focus Zone and two Hot Spot Zones within it. By using a
Focus Zone for the report, a specific set of base stations can be included in the report,
Revision 1.3
iProtect: Internal
Page 193
instead of creating a report for every site that has been calculated. Figure 135 shows
that the generated report includes statistics for the Focus Zone and each of the Hot
Spot Zones.
Figure 134 : Focus & Hot Spot Zone Polygons
Focus Zone
Computation Zone
Revision 1.3
iProtect: Internal
Page 194
8.3.5.
Printing Zone
The Printing Zone (represented with a Light Blue line) will define the area that is shown
when the user selects the Print Option. If no print area is defined, by default the
Computation Zone will be used.
If a user chooses to print, the Print Setup should be run to select the layout of the
project (File > Print Setup).
8.3.6.
The Coverage Export Zone (represented with a Purple line) is used to export only a
portion of the coverage prediction to a raster or vector file. Once the area has been
delimited, the user can export the area.
All coverage types can be exported. However, only certain types of coverage
predictions can be exported in raster format. For example, if the coverage prediction
was made per transmitter (e.g. coverage predictions with the display type set by
transmitter, by a transmitter attribute, by signal level, by path loss, or by total losses),
then it cannot be exported in raster format. In this case, only the coverage area of a
single transmitter can be exported in raster format.
In the example below, if Coverage by Transmitter is selected and exported, the results
will be a vector based file. If Site0_1 is selected (from within the expansion of the
Revision 1.3
iProtect: Internal
Page 195
Coverage by Transmitter prediction folder), the user is able to export the results as
either a vector or raster based file.
To export the coverage, select the DATA tab, then the Predictions Folder. Expand the
prediction of interest.
Right click to bring up the menu and select Export the Coverage. This brings up
another window where the user can select the export type desired.
Revision 1.3
iProtect: Internal
Page 196
Revision 1.3
iProtect: Internal
Page 197
Click on the Receiver tab at the top of the Predictions properties window. The user
may now enter an antenna height to be globally applied to all the subscriber units
throughout the system.
The subscriber antenna height can be set based on each clutter classification when
using the Standard Propagation Model or propagation models based on the SPM
Click on the Modules tab at the top of the Explorer window and expand the
Propagation Models folder (click on the [+] box next to the folder) to display the
propagation models. Right click on a propagation model (this needs to be an SPM
based model) and select the Properties option. This opens the properties window for
the propagation model.
Click on the Clutter tab at the top of the propagation model properties window. The
user may now enter antenna heights in the Rx Height (m) field for each of the clutter
classifications.
Revision 1.3
iProtect: Internal
Page 198
The following provides a brief discussion on the windows that are to be populated when
a new prediction is created. Refer to the Atoll manuals for further information.
1. Right-click the Predictions folder in the Data tab to obtain the context menu. Select
New and the Study Types dialog box appears.
Figure 139: Selecting New Predictions
2. Select the desired coverage image type from the Study Types dialog.
Revision 1.3
iProtect: Internal
Page 199
3. Once the desired coverage image type is selected, a dialog window will appear with
three tabs: General, Condition, and Display. These dialogs change slightly
depending on which image was selected. However, the process for setting up these
images is very similar and will be explained here.
4. Click on the General tab. From within this tab the user can change the default Name
and Resolution of the coverage prediction image, as well as the storage folder
location for the prediction. The user can also add Comments, if desired. Under the
Configuration section, the user can create a Filter to select which sites to display in
the results. (For further information regarding grouping, filtering and sorting
functionality in the prediction generation process, please see the Atoll manuals.)
Figure 141: Predictions General Tab
Revision 1.3
iProtect: Internal
Page 200
The coverage prediction resolution does not have to be the same as the resolution
of the path loss matrices or the geographic data, and can be defined separately for
each coverage prediction.
5. Under the Condition tab, the user can define the signals that will be considered for
each pixel. The Condition window will be different based on the study type (i.e.
prediction) that has been selected. The following figure shows the different views
that can be observed.
Figure 142: Predictions Condition Tab
For some predictions, the first line of the Condition window allows the user to set
the range that will be considered. This range is typically based on Signal Level,
but the user can also select to have the range set by Path Loss or Total Loss.
For some predictions, the Server line allows the user to determine what servers
to consider: All, Best Signal Level, or Second Best Signal Level. Selecting All
or Best signal level will provide the same results because Atoll displays the
results of the best server in either case.
For some predictions, the user needs to select the Terminal, Mobility and Service
settings to reflect the prediction that is being made, as well as defining the load
conditions (i.e. based on simulations or data in the cells table). For example, one
study (i.e. prediction) could assume the CPE device for an indoor prediction,
whereas a second study may assume the MS device for an outdoor prediction.
Revision 1.3
iProtect: Internal
Page 201
Turning on the Shadowing taken into account checkbox causes Atoll to include
a lognormal (i.e. shadow) margin in the coverage plots in accordance with the
selected Cell Edge Coverage Probability and the user defined lognormal
standard deviations per clutter category. This option is recommended and will be
discussed further in Section 9.2.2.1.
The Cell Edge Coverage Probability allows the user to select the probability for
the cell edge coverage. This field is enabled when the previous checkbox is
checked. Refer to Section 9.2.2.1 for further discussion.
Selecting With a Margin (which is available for certain prediction images, such
as Coverage by Transmitter) is used to specify an amount (i.e. dB) of coverage
overlap between sectors.
The Indoor Coverage check box can be selected to add indoor losses to the
prediction. The indoor losses are defined per clutter class. Refer to Section 7.4.
6. The Display dialog window allows the user to define the thresholds, thus defining
how the image will be displayed on the screen. Refer to Sections 9.3 and 9.4 for
further information concerning the levels to be set for various predictions.
Figure 143: Predictions Display Tab
The Actions button lets the user further define the scale and shading used.
7. Once the prediction properties have been set within the General, Condition, and
Display windows and the user has clicked OK, the predictions are ready to be run.
To execute the prediction, right-click the Predictions folder to obtain the context
menu. Then select either Calculate or Force Calculate to start generation of the
images. (Force Calculate will regenerate the pathloss files needed for the images.)
Revision 1.3
iProtect: Internal
Page 202
Further details regarding creating prediction images can be found in the Atoll User
Manual.
9.2.2.
If the user elects to check the Shadowing taken into account box, several additional
steps must be taken for the appropriate lognormal margin to be applied. The user
should first check the Shadowing taken into account box; this will activate the Cell
Edge Coverage Probability percentage as shown in the following figure.
Figure 144: Predictions Condition Tab with Shadowing for RSSI
Revision 1.3
iProtect: Internal
Page 203
The percentage displayed can be calculated using the Shadow Fade Margin calculator
(Atoll > Explorer > Data > Predictions, Right mouse click on Predictions > Shadow
Margins).
Figure 145: Accessing the Shadow Fade Margin Calculator
The Shadow Fade Margins are calculated independently for the Model and C/I standard
deviations (set in the Clutter Classes Properties interface) but using the same Cell Edge
Coverage Probability value. The Cell Edge Coverage Probability percentage is
incremented or decremented until the margin is at the desired level. The margin values
shown in the following two figures are matched to those calculated by ML-CAT
(assuming a 90% area reliability, 8 dB standard deviation, 35.22 dB/decade slope and
60 degrees antennas). See following table for 90% and 95% area reliability.
Cell Edge
Coverage
Probability
Standard
Deviation:
From Model
Standard
Deviation: C/I
Lognormal
Fade Margin
(CINR)
90%
76.6%
5.81 dB
1 dB
1 dB
95%
87.4%
9.16 dB
1.6 dB
1.6 dB
Note: In ML-CAT, the user supplies an area reliability value for deriving the lognormal
fading value, whereas in Atoll, a cell edge reliability value is used for obtaining a
lognormal fading value. Thus the area reliability percentage can not be taken directly
from ML-CAT and used in the Cell Edge Coverage Probability field.
Revision 1.3
iProtect: Internal
Page 204
The formula for the Shadow Fade Margin calculator can be found in the Atoll Technical
Reference Guide in the section on Shadow Margin Calculation.
If the desired Cell Edge Coverage Probability and standard deviation are known, the
approximate fade margin value can be obtained using the following formula inside
Microsoft Excel
= NORMINV(probability,mean,standard_deviation)
Where
Probability = Cell Edge Coverage Probability
Mean = zero (0)
Revision 1.3
iProtect: Internal
Page 205
In the Clutter Class properties window, select the Description tab to find the fields for
the Model and C/I standard deviations. By default the Atoll tool puts in a value of 7 dB
for both of the Model and C/I standard deviations. The Model (RSSI) standard deviation
should be changed to a value of 8 dB or a value that matches what was assumed in
ML-CAT.
It is recommended that a value of 1.4 dB be used for the C/I standard deviation
(assuming 90% area reliability is desired). This will provide a 1 dB lognormal margin
when the Cell Edge Coverage Probability is set to 76.6%. 95% area reliability can be
modeled providing a 1.6 dB lognormal margin when the Cell Edge Coverage Probability
is set to 87.4%. The C/I value can be changed based on local market needs and
customer inputs.
Note: If shadowing is employed for coverage predictions, then model and CINR
standard deviations should be reset to 0 prior to performing any capacity analysis. For
simulations, no standard deviations are desired and the value must be zeroed to,
Revision 1.3
iProtect: Internal
Page 206
effectively, disable their use (since standard deviations are always applied within Atoll
simulations).
Should a customer require that individual clutter classes have different lognormal fade
margins (i.e. shadow fade), the user will have to modify the clutter class Model and C/I
standard deviations in the Clutter Class table on a clutter class basis. Once the
adjustment has been made, please make sure to verify Shadow Fade Margin with the
built in calculator.
Be aware that some images (e.g. Signal Level, Signal Quality) use the shadow margin
resulting from the Model standard deviation and other images (e.g. Traffic C/(I+N), Best
Bearer) use the shadow margin resulting from the C/I standard deviation.
The following two figures illustrate where the Model and C/I standard deviation values
are set.
Figure 149: Clutter Class Standard Deviation
The standard deviation values will also need to be modified in the Default Values tab.
Revision 1.3
iProtect: Internal
Page 207
The lognormal shadow margin will be different between the CINR and RSSI based
images due to the different Model and C/I standard deviation values that are used. If the
standard deviation values are set the same there will be no difference in the resulting
shadow margin that is applied to the images.
Once the user has decided on which Model and C/I standard deviation values to have in
the Clutter Class table, the Cell Edge Coverage Probability should be adjusted so that
the desired Shadow Fade Margin is calculated (i.e. Lognormal Fade Margin).
This section describes two images that will be used most often in the system design
process. The first image described is the Coverage by Channel Throughput. This image
will be used to evaluate the coverage of a system. The second image that is included in
this section is the Effective Signal Analysis image. This image will be used to show the
RSSI levels for a design.
Revision 1.3
iProtect: Internal
Page 208
Downlink and uplink channel throughput coverage predictions calculate and display the
median channel throughputs based on C/(I+N) and bearer calculations for each pixel.
The coverage by throughput image can be displayed by Peak RLC Channel
Throughput. Atoll calculates the Peak RLC Channel Throughputs from the information
provided in the Global Parameters (see Section 7.2.1) and in the terminal and mobility
properties (see Section 7.3) for the terminal and mobility selected in the coverage
prediction (see Figure 151).
The Peak RLC Channel Throughput image does not allow the user to set a threshold to
include a margin for the lognormal fading. If the user wishes that the lognormal fading is
taken into account, the Shadowing taken into account must be turned on. Refer to
Section 9.2.2 on how to adjust for lognormal fading via this method. The Coverage by
Throughput image will use the C/I Standard Deviation from the Clutter Classes for the
calculation of the lognormal fading margin.
Atoll determines the bearer at each pixel and multiplies the bearer efficiency by the
number of symbols in the frame to determine the Peak RLC Channel Throughputs.
Refer to Figure 153.
Revision 1.3
iProtect: Internal
Page 209
The Peak RLC Channel Throughput image displays areas colored by throughput in
kbps increments set in the Display tab of the Coverage by Throughput properties
window, as seen below.
For the image to incorporate reliability, the Shadowing taken into account check box
should be selected. The image Display tab should be set so the lowest throughput
displayed is the targeted edge rate of the system design. Effective throughput images
(post-HARQ) and Application throughput images are covered in Sections.9.3.2.1.1 and
9.3.2.1.2.
An example downlink Peak RLC throughput image that results from settings such as
these is seen in the following figure.
Revision 1.3
iProtect: Internal
Page 210
Downlink and uplink Effective Signal Analysis plots display the signal levels of different
types of LTE signals, such P-SCH, S-SCH, PDSCH, PUSCH etc., in the part of the
network being studied. These images are recommended for use in the design process
to show RSSI levels throughout the system.
As seen in the following figure, the Field menu is used to define the type of signal that
is used in the Effective Signal Analysis image. Typically, the system design will focus on
the PDSCH (traffic) signal. When generating these images to show the RSSI for a given
design, it is recommended to set the Field to the Best PDSCH Signal Level (DL)
(dBm).
Revision 1.3
iProtect: Internal
Page 211
In the downlink direction, Atoll calculates the best server for each pixel depending on
the downlink signal level. Then it calculates the effective signal level (received carrier
power (C) or carrier-to noise ratio (C/N)). Pixels are colored if the display threshold
condition is met.
The following figure shows an example Effective Signal Analysis (DL) image for the
Best Traffic Signal.
Revision 1.3
iProtect: Internal
Page 212
The RSSI legend that is shown in this figure is just an example. When evaluating an
RSSI image for a system, it is essential that this legend be modified to reflect the
specific signal levels that are applicable for the given design.
When evaluating an RSSI image, the system designer needs to show that the RSSI
values meet or exceed the desired threshold value throughout the customers desired
service area (i.e. in 100% of the service area). Note that the coverage area reliability is
taken into account by looking at the % of covered area results of an image, which
depicts the percent of area at or above a given threshold. The following equation should
be used to determine the proper RSSI threshold for the downlink direction:
RSSI Threshold (DL) = kTB + NF + SNR + Fast Fade Margin Diversity Gain
Adaptive Array Gain + Interference Margin
The lognormal fade margin will be based on the Cell Edge Coverage Probability
percentage and the Model Standard Deviation of the clutter classes. The Cell Edge
Coverage Probability value that provides the desired model margin result from the
Shadow Margin Calculator should be entered into the Cell Edge Coverage Probability
box in the predictions Condition window (refer to Section 9.2.2).
The diversity gain is subtracted here because it is not included in the RSSI image.
Similarly, in cases of TXAA configurations, the adaptive array gain is subtracted since it
is not included in the RSSI image. The diversity gain and adaptive array gain (which are
included in the Diversity Gain in the Atoll MIMO configurations interface) are only
applied to the C/(I+N) image.
Revision 1.3
iProtect: Internal
Page 213
The same equation is used on the uplink, except that there is no adaptive array gain
included and the values used for various parameters are different for uplink than for
downlink.
RSSI Threshold (UL) = kTB + NF + SNR + Fast Fade Margin Diversity Gain +
Interference Margin
Again, the lognormal fade margin is based on the Cell Edge Coverage Probability
percentage and the Model Standard Deviation of the clutter classes. The Cell Edge
Coverage Probability value that provides the desired model margin result from the
Shadow Margin Calculator should be entered into the Cell Edge Coverage Probability
box in the predictions Condition window.
Please see Section 9.4 for further information regarding evaluating images and
recommended values to use in these RSS coverage thresholds.
9.3.2.
This section describes several other images that can be helpful in the system design
process since they provide additional perspectives on the design. For example, the
Coverage by Channel Throughput image provides the throughput results in the system,
the Coverage by Transmitter provides a best server perspective, the Coverage by Best
Bearer provides the achieved bearer rates, and the Overlapping Zones image provides
the number of transmitting servers for each area, which can assist in interference
analysis.
9.3.2.1. Coverage by Channel Throughput DL and UL (Additional Images)
Additional channel throughput images (other than the Peak RLC Channel Throughput
described in Section 9.3.1.1) can be generated. These coverage images display
Effective RLC Channel Throughput, Application Channel Throughput, Peak RLC Cell
Capacity, Effective RLC Cell Capacity, or Application Cell Capacity. Downlink and uplink
channel throughput coverage predictions calculate and display the channel throughputs
based on C/(I+N) and bearer calculations for each pixel. Atoll calculates the channel
throughputs from the information provided in the Global Parameters (see Section 7.2.1)
and in the terminal and mobility properties (see Section 7.3) for the terminal and mobility
selected in the coverage prediction.
Revision 1.3
iProtect: Internal
Page 214
The following subsections also include information on how to display throughput levels.
9.3.2.1.1.
The Effective RLC Channel Throughputs are the Peak RLC throughputs reduced by
retransmission due to errors, or the Block Error Rate (BLER). Atoll uses the block error
rate curves of the reception equipment defined in the selected terminal reception
equipment of the cell of the serving transmitter (see Section 7.2.3.4). Each uniquely
configured device could have a different Effective RLC Channel Throughput rate for a
given location.
9.3.2.1.2.
The Application Channel Throughput is the Effective RLC Throughput reduced by the
overheads of the different layers between the RLC and the Application layers. The
overheads such as PDU/SDU header information, padding, encryption, coding all
reduce the available throughput.
Revision 1.3
iProtect: Internal
Page 215
9.3.2.1.3.
Cell Capacity
The Peak RLC Cell Capacity will generate the same image as the Peak RLC Channel
Throughput as long as the Maximum Traffic Load is set to 100 percent. The Maximum
Traffic Load is defined in the Cells table as Max Traffic Load (UL) % and Max Traffic
Load (DL) %. It is not recommended that a value of less than 100% be used for these
fields.
The relationships of Effective RLC Cell Capacity to Effective RLC Channel Throughput
and Application Cell Capacity to Application Channel Throughput are comparable to that
described above for Peak RLC Cell Capacity to Peak RLC Channel Throughput.
9.3.2.1.4.
The Allocated Bandwidth throughputs are only available in the uplink. The predictions
consist of Peak RLC Allocated Bandwidth Throughput, Effective RLC Allocated
Bandwidth Throughput, or Application Allocated Bandwidth Throughput.
The allocated bandwidth throughputs are the throughputs corresponding to the number
of frequency blocks allocated to the terminal at different locations. Atoll automatically
accounts for the number of UL RBs used on the UL. The allocation of RBs will depend
on the selected scheduler parameters (see Section 7.2.2.4)
For the image to incorporate reliability, the Shadowing taken into account check box
should be selected.
9.3.2.2. Coverage by C/(I+N) Level DL and UL
The Coverage by C/(I+N) level images show the C/(I+N) for each pixel. This image can
be run either for the downlink or uplink perspective. The system coverage is defined
using the Peak RLC Throughput image (see Section 9.3.1.1).
For the image to incorporate reliability, the Shadowing taken into account check box
should be selected.
For the downlink, Atoll calculates the best server for each pixel depending on the
downlink signal level. Then it calculates the interference from other cells, and finally
calculates the C/(I+N). The color of the pixel depicts the C/(I+N) level of that pixel.
The following figure shows an example Coverage by C/(I+N) Level DL image.
Revision 1.3
iProtect: Internal
Page 216
The C/(I+N) legend that is shown in this figure is just an example. When evaluating
coverage for a system, it is essential that this legend be modified to reflect the specific
C/(I+N) levels that are applicable for the given design.
When evaluating a C/(I+N) image, the system designer needs to show that the C/(I+N)
values meet or exceed the desired threshold value (refer to Table 10 and Table 11)
throughout the customers desired service area (i.e. in 100% of the service area).
The lognormal fade margin will be based on the Cell Edge Coverage Probability
percentage and the C/I Standard Deviation of the clutter classes. The Cell Edge
Coverage Probability value that provides the desired C/I margin result from the Shadow
Margin Calculator should be entered into the Cell Edge Coverage Probability box in the
predictions Condition window (refer to Section 9.2.2).
Please see Section 9.4 for further information regarding evaluating images and
recommended values to use in this CINR coverage threshold.
Note that the Coverage by C/(I+N) Level image includes the Diversity gain from the
MIMO table within the LTE Equipment interface.
For the uplink, Atoll sets the interference component I of C/(I+N) according to the userdefined Uplink Noise Rise (traffic interference). It is best to use the Noise Rise results
produced by Monte Carlo simulations though estimated values for Uplink Noise Rise are
given in Section 7.1.2.1.3.
The noise component N of C/(I+N) depends on the noise bandwidth, which is
automatically computed by Atoll as part of its UL subchannelization algorithm. The UL
Resource Blocks at the cell edge for C/(I+N) is computed depend on the selected
scheduler parameters (see Section 7.2.2.4)
Revision 1.3
iProtect: Internal
Page 217
For the image to incorporate reliability, the Shadowing taken into account check box
should be selected.
Running a Monte Carlo simulation using multiple drops can provide the UL noise rise
required for each cell in a detailed system study (see Section 10.7.4).
Refer to Table 11 for selecting the proper UL C/(I+N) threshold.
The coverage prediction by transmitter is basically a best server image. This image
shows the transmitter, via varying colors, that has the strongest reference signal for
each pixel, as seen in the following example figure. (Please note that in order to see
varying colors in this image, rather than shades of gray, the user needs to set the
automatic coloring of the transmitters. See Section 7.1.2.1.5 for further information on
setting the transmitter color display.)
Revision 1.3
iProtect: Internal
Page 218
The following figure is identical to the previous figure except that a 5 dB margin was
supplied.
Figure 159: Sample Coverage by Transmitter Image with Margin
The downlink and uplink best radio bearer coverage predictions calculate and display
the best LTE radio bearers based on the C/(I+N) for each pixel. The Coverage by Best
Bearer image uses the C/I Standard Deviation from the Clutter Classes for the
calculation of the lognormal fading when shadowing is checked at the time the image
is generated.
The Coverage by Best Bearer generates a CINR image (Section 9.3.2.2) and then
compares it against the Bearer Selection Thresholds (Section 7.2.3.4). The settings for
the scheduler determine method used to arrive at the best bearer for each pixel. For
more information, please look for Bearer Determination in the Atoll Technical Reference
Guide.
The Best Bearer refers modulation and coding scheme used in the prediction. The
legend seen in Figure 161 refers to the Radio Bearer Index value and modulation name
as shown in Figure 160.
Revision 1.3
iProtect: Internal
Page 219
Revision 1.3
iProtect: Internal
Page 220
There are a total of 58 bearers and the Motorola template, 29 for the downlink and 29
for the uplink. The modulation and coding scheme combinations are slightly different on
the uplink as compared to the downlink, which is why there are 29 separate entries in
the template for each link direction. This creates somewhat of an issue in Atoll when
plotting the best bearer image. When using the default configuration for the best bearer
image, Atoll populates the image ranges to include all of the bearers in the bearer table.
The legend automatically includes the bearer index number and the modulation and
coding scheme as illustrated in Figure 162.
Revision 1.3
iProtect: Internal
Page 221
However, if the goal is to display only a subset of the bearers, for example to plot only 1
29 for the DL bearers, then it would seem straightforward to simply change the image
range for the plot to 1 29. However, once the range is changed, Atoll no longer
displays the modulation and coding scheme in the legend; rather, only the bearer index
is shown as seen in Figure 161. Another approach might be to select the rows for the
bearers to be excluded from the plot and choose Actions Delete. This would delete
the undesired bearers while retaining the detailed legend information; however, the
resulting color scheme is not ideal. This issue has been reported to Forsk and is in their
bug database to be fixed. In the meantime, one work around to facilitate the best bearer
plot creation is to store the desired plot configuration information in an Atoll
configuration file and then import this configuration when creating the best bearer plot.
Configuration files have been created for the standard UL and DL best bearer plots and
can be downloaded from the following link:
http://compass.mot.com/go/326569766
To use the configuration file, select ActionsConfigurationImport, as illustrated in
Figure 163, and browse to the appropriate configuration file (UL or DL).
Revision 1.3
iProtect: Internal
Page 222
Revision 1.3
iProtect: Internal
Page 223
The Tip Text for Coverage Predictions can be used to help analyze coverage or
determine problems by displaying the coverage values at specific points. The Tip Text
works by displaying the values of the coverage layers that are turned on. If more than
one layer is turned on, the tip box will display the values for all the coverage layers that
Revision 1.3
iProtect: Internal
Page 224
are turned on (as seen in the following figure). By moving the cursor over specific points
of interest, the pop up display will show the values for the selected coverage layers.
The amount of information that is displayed in the Tip Text pop up can be controlled
from the display properties for each prediction layer. In the figure below, the tip text
setting is showing default values of the Prediction Name and Legend. Other values can
be selected from the tip text box for display. The geographic layers of elevation, clutter
heights and clutter classes are not displayed when there is a coverage layer displayed.
In order to see the underlying coverage predictions, it may be necessary to adjust the
transparency via the slide control, as seen in the figure below. Moving the transparency
slide control to the right makes the display more transparent and moving it to the left
makes it less transparent.
Revision 1.3
iProtect: Internal
Page 225
9.4.2.
iProtect: Internal
Page 226
design goal is to show adequate signal strength and no significant interference in all of
the required regions within the service area. For example, if a system is being designed
for 90% coverage reliability, the lognormal fade margin values that are used in the
Coverage Throughput image and RSSI threshold (assuming the lognormal fade margin
is being accounted for in the threshold settings and not based on the Cell Edge
Coverage Probability) would be based upon 90% coverage reliability. Then when the
resulting Coverage Throughput image and Effective Signal Analysis for the Best Traffic
Signal Level image are evaluated, the user needs to show that the entire service area
is at or above the calculated thresholds, not just 90% of the service area. (If a
percentage of area less than 100% is shown, then only the colored area meets the
coverage area reliability value. For example, if 95% of the service area meets the
calculated threshold level which includes a lognormal fade margin for 90% reliability,
then only 95% of the area would be considered as 90% reliable.)
The following subsections will describe how to determine the proper signal strength
thresholds to use when evaluating the images.
If relatively large areas between sites lack coverage or show high interference, then
system design adjustments need to be examined, such as:
The Point Analysis Tool within Atoll can be used in the evaluation and troubleshooting
process to help determine which sites/sectors are associated with a coverage problem
area. It can be used to examine the signals from the surrounding sites and to examine
possible obstructions in the area. (See Section 9.4.3 and the Atoll manuals for further
information on the use of the Point Analysis Tool).
Poor C/(I+N) performance may be due to shadowing by large obstructions in the
signals path. It may also be caused by an unusually strong signal from the neighboring
sites. If this is the case, downtilting the offending sectors antenna is typically the best
approach to controlling the interference problem.
9.4.2.1. Coverage Images
iProtect: Internal
Page 227
based on the Cell Edge Coverage Probability percentage and the Model Standard
Deviation of the clutter classes.
9.4.2.2. RSS Images
As mentioned in Section 9.3.1.2 the Effective Signal Analysis images for the Best Traffic
Signal Level are used to evaluate the traffic signal levels within a system. The system
designer needs to show that the RSSI values meet or exceed the desired RSSI
threshold throughout the customers service area (i.e. in 100% of the service area). The
following equations are used to determine the downlink and uplink RSSI thresholds:
RSSI Threshold (DL) = kTB + NF + SNR + Fast Fade Margin Diversity Gain
Adaptive Array Gain + Interference Margin
RSSI Threshold (UL) = kTB + NF + SNR + Fast Fade Margin Diversity Gain +
Interference Margin
Verify the Shadowing taken into account option was checked in the predictions
Condition window, as described in Section 9.2.2.1. The lognormal fade margin will be
based on the Cell Edge Coverage Probability percentage and the Model Standard
Deviation of the clutter classes.
Please see Section 9.4.2.3 to determine the values to use in this equation.
The diversity gain is subtracted because it is not included in the RSSI image. Similarly,
in cases of TXAA configurations, the adaptive array gain is subtracted from the downlink
threshold since it is not included in the RSSI image. The diversity gain and adaptive
array gain (which are incorporated in the Diversity Gain in the Atoll MIMO configurations
interface) are only applied to C/(I+N) images.
9.4.2.3. RSSI Threshold Parameter Values
The previous sections provide equations to use in calculating the RSSI thresholds. The
values used in these equations depend upon the given design configuration. The
following subsections provide values for these parameters based on various
configurations.
9.4.2.3.1.
kTB
iProtect: Internal
Page 228
Channel
Bandwidth,
MHz
1.4
Maximum Maximum
Resource
DL
Number of
UL
kT
element
Occupied
UL
Occupied
(dBm/Hz) Bandwidth, Resource Resource Resource
Hz
Elements
Blocks
Blocks
-174
15000
72
6
5
Downlink kTB
(dBm)
Uplink kTB
(dBm)
*
-113.7
-114.5
-174
15000
180
15
13
-109.7
-110.3
-174
15000
300
25
21
-107.5
-108.2
10
-174
15000
600
50
42
-104.5
-105.2
15
-174
15000
900
75
63
-102.7
-103.5
20
-174
15000
1200
100
84
-101.4
-102.2
* Assumes that all Resource Blocks are used for a subscriber. However, it is possible that a smaller
allocation of Resource Blocks will be used, which will alter the uplink kTB value (as seen in the equation
above). The minimum number of uplink Resource Blocks should not be less than two.
Revision 1.3
iProtect: Internal
Page 229
9.4.2.3.2.
In the downlink direction, the Subscriber Noise Figure is used in the RSSI threshold
calculation. The subscriber noise figure should be available from the UE vendor.
In the uplink direction, the eNB Noise Figure is used in the RSSI threshold calculation.
For Motorola base stations, the Noise Figure is typically 4 dB.
9.4.2.3.3.
Effective SNR
The RSSI threshold equation includes the SNR + Fast Fade Margin terms, so the
Effective SNR value can be used for the combination of these two parameters within
this equation. The following tables provide the Effective SNR for both the DL and UL.
The first table provides the downlink effective SNR values and the second table
provides the uplink effective SNR values. The values in these tables are the same as
the bearer selection threshold values found within Atoll (see Section 7.2.3.4). The
values in Table 10 are the same as the values in the Motorola UE Reception (used for
DL), the values in Table 11 are the same as the values in the Motorola eNB Reception
(used for UL).
Table 10: DL Effective SNR Values (i.e. bearer selection thresholds)
Bearer
Index
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Revision 1.3
Modulation
QPSK 0.12
QPSK 0.15
QPSK 0.19
QPSK 0.25
QPSK 0.30
QPSK 0.37
QPSK 0.44
QPSK 0.51
QPSK 0.59
QPSK 0.66
16 QAM 0.33
16 QAM 0.37
16 QAM 0.42
16 QAM 0.48
16 QAM 0.54
16 QAM 0.60
16 QAM 0.64
64QAM 0.43
64QAM 0.46
64QAM 0.50
64QAM 0.55
64QAM 0.60
64QAM 0.65
PB3
-5.3
-4.3
-3.3
-2.0
-0.9
0.3
1.5
2.7
3.7
4.6
4.6
5.3
6.4
7.6
9.0
10.0
10.8
10.8
11.4
12.5
13.6
14.5
15.4
iProtect: Internal
VA30
-5.3
-4.3
-3.3
-2.0
-0.9
-0.2
1.8
3.1
4.1
5.0
5.0
5.8
6.8
8.2
9.5
10.8
11.5
11.6
12.3
13.4
14.4
15.3
16.2
VA30R1
-5.3
-4.3
-3.3
-2.0
-0.9
-0.2
1.6
3.0
4.0
4.9
4.9
5.8
7.3
9.1
10.7
12.1
12.8
12.9
13.6
14.5
15.4
16.5
17.4
Page 230
23
24
25
26
27
28
64QAM 0.70
64QAM 0.75
64QAM 0.80
64QAM 0.85
64QAM 0.89
64QAM 0.93
16.2
17.0
19.2
40.0
40.0
40.0
16.8
17.8
19.8
40.0
40.0
40.0
18.1
18.9
19.9
40.0
40.0
40.0
Note: These DL values have been calibrated with Minisim simulations. The R282
template (Nov10) contains the bearer selection curves for all mobilities. Should an
existing project need to be updated with the new curves, the complete set along with
instructions for copying them into the projects database can be found in the
spreadsheet AtollR282Params.xls located at
http://compass.mot-solutions.com/go/318588510.
Refer to sheet BST (for Bearer Selection Thresholds).
Table 11: UL Effective SNR Values (i.e. bearer selection thresholds)
BEAREX
INDEX
Revision 1.3
Modulation
30
QPSK 0.10
31
QPSK 0.13
32
QPSK 0.16
33
QPSK 0.21
34
QPSK 0.25
35
QPSK 0.31
36
QPSK 0.37
37
QPSK 0.43
38
QPSK 0.49
39
QPSK 0.56
40
QPSK 0.62
41
16 QAM 0.31
42
16 QAM 0.35
43
16 QAM 0.40
44
16 QAM 0.45
45
16 QAM 0.50
46
16 QAM 0.54
47
16 QAM 0.57
48
16 QAM 0.63
49
16 QAM 0.69
iProtect: Internal
PB3
-0.088
VA30
&
VA30R1
0.612
0.981
1.681
1.743
2.409
2.909
3.109
4.235
5.134
5.192
6.050
5.950
6.687
6.577
7.431
7.145
8.068
7.771
8.511
8.285
8.921
8.285
8.921
8.993
9.688
9.857
10.405
10.516
11.114
11.383
12.032
12.097
12.322
12.393
12.634
12.899
13.306
13.676
14.263
Page 231
50
16 QAM 0.75
51
64QAM 0.50
52
64QAM 0.54
53
64QAM 0.59
54
64QAM 0.63
55
64QAM 0.67
56
64QAM 0.71
57
64QAM 0.74
58
64QAM 0.77
14.634
15.160
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
40.0
Note: These UL values have been calibrated with Minisim simulations. The R282
template (Dec10) contains the bearer selection curves for all mobilities. Should an
existing project need to be updated with the new curves, the complete set along with
instructions for copying them into the projects database can be found in the
spreadsheet AtollR282Params.xls located at
http://compass.mot-solutions.com/go/318588510.
Refer to sheet BST (UL) (for Bearer Selection Thresholds).
9.4.2.3.4.
Diversity Gain
Diversity gain is not included in the RSSI images (i.e. Effective Signal Analysis images).
As mentioned previously, the diversity gain needs to be accounted for in the RSSI
threshold value. In the downlink direction, the diversity gain is determined by the
subscriber equipment and the receive diversity type that is supported by that equipment,
as well as the MCS and channel profile assumptions. Similarly, for the uplink direction,
the diversity gain is determined by the base station receive diversity type and the MCS
and channel profile assumptions. UL Diversity gain is currently modeled in the Atoll LTE
template as 10*Log10(Num Rx Antennas), so 3 dB gain for two-branch RX diversity, 6
dB for four-branch RX diversity, and 9 dB for eight-branch. For DL Diversity gain
recommendations, refer to Table 7. (Receive diversity gain values are included in the
Diversity Gain fields within the MIMO table of the LTE Equipment interface, which are
incorporated in the C/(I+N) images.)
9.4.2.3.5.
The adaptive array gain needs to be incorporated into the RSSI threshold value in the
downlink direction. This is only a factor in systems where smart antennas are used. A
TxAA array gain of 2 to 5 dB is included, depending on the environment being modeled
(i.e. 2 dB is used in dense urban settings with a high degree of scattering, 3 to 4 dB is
used in urban or suburban settings with a medium degree of scattering, and 5 dB is
used in rural or suburban settings with a low degree of scattering). Further information
regarding the TxAA gain can be found in the LTE RF Planning Guide
(http://compass.mot.com/go/310442223) or in the LTE ML-CAT User Guide
(http://compass.mot.com/go/310448858).
Revision 1.3
iProtect: Internal
Page 232
9.4.2.3.6.
Interference Margin
The topic of Interference Margin is described within the UL Noise Rise discussion in
Section 7.1.2.1.3. The noise rise values discussed in this section represent the
interference margin that can be used for the uplink or downlink interference margin in
the RSSI threshold calculations.
9.4.2.4. Additional Image Evaluations
Overlapping Zones
interference areas.
can
provide
additional
insight
into
possible
Further information regarding these images can be found in Section 9.3.2 and in the
Atoll manuals.
9.4.3.
The Point Analysis Tool can be useful in the process of evaluating or troubleshooting a
design. The Point Analysis Tool is activated by clicking on the Point Analysis Tool
button in the Atoll toolbar, as shown below.
Revision 1.3
iProtect: Internal
Page 233
The Point Analysis Tool is useful to see the path profile that includes the pathloss,
terrain elevations, and clutter losses / obstructions.
Figure 167: Path Profile
7
5
1
6
In the profile window (item 1 in the previous figure), the Transmitter field (item 2)
specifies the source of the signal from which the path is generated. The numbers
adjacent to it (item 3 above) are the received signal strength of the transmitter, the
Propagation Model that was used, and the distance from the Transmitter. Also, if the
Shadowing taken into account field is checked in the Analysis Properties interface,
then the shadow margin and the cell edge coverage probability used for calculating the
shadow fade margin are also shown here.
The blue ellipsoid indicates the Fresnel zone and the green line indicates the Line of
Site between the transmitter and the receiver. (Note that when there is an obstacle
along the path, the green line is drawn from the transmitter to the obstacle.) The angle
Revision 1.3
iProtect: Internal
Page 234
of the LOS read from the vertical antenna pattern is also displayed (item 4 in the figure
above). Along the profile, if the signal meets an obstruction, the diffraction is displayed
by a red vertical line (assuming the propagation model used takes diffraction into
account). The total attenuation is displayed in the profile (item 5 in the figure above).
As the cursor is dragged around the map, the path profile will change due to variations
in terrain and clutter values. The values shown below the Profile window (item 6 in the
figure above) provide the Latitude / Longitude, the elevation value and the clutter type.
Checking the Geographic profile box (item 7 in the figure above) turns off all of the
propagation reporting in the profile tab window and only shows the blue Fresnel zone
ellipsoid and the geographic information (terrain and clutter) between the transmitter
and the receiver.
Right Clicking in the Profile window allows the user to bring up the Properties, (as seen
in Figure 168), or Link Budget details (as seen in Figure 169). The Link Budget details
window will show the various values that are being reported at the location of the cursor.
The information in the Link Budget window will change as the cursor is dragged around
the map.
Figure 168: Path Profile Analysis Properties
Revision 1.3
iProtect: Internal
Page 235
The Reception tab, 2nd tab of the Point Analysis window, displays the signal strength
levels of the surrounding transmitters. As the cursor is dragged around the map, the
reception values will vary as the distance from the transmitter changes. Multiple arrows
connecting the cursor location to each transmitter will be displayed and colored the
same as the transmitter color. This can be useful for determining most likely interferers
in areas with high C/(I+N). The analysis point will remain in a fixed location by releasing
the left mouse button. The cursor can then be moved (do not depress the mouse
buttons) to any of the connection lines on the display to reveal the transmitter
identification associated with the connection line.
Revision 1.3
iProtect: Internal
Page 236
The Signal Analysis tab, 3rd tab of the Point Analysis window, shows information on the
reference signal, downlink traffic, and uplink signal levels, C/(I+N), bearers, and
throughputs. Only the best server link will have a black arrow between the
measurement point and the serving cell as seen in the following figure.
Revision 1.3
iProtect: Internal
Page 237
NOTES:
Note. 1. The reference signal strength bars are shown with the best server at the top
and the interfering cells below in descending order.
Note. 2. The solid portions of the reference signal reception bars indicate signal
levels above the preamble C/N threshold. The clear portions indicate signal
levels below the preamble C/N threshold.
Note. 3. The Load Conditions field allows the user to define whether the load is from
the Cells Table or from simulations (if simulations have been run).
Note. 4. The Terminal field pull-down allows the user to select the subscriber
equipment used for the analysis (from the list of all available terminal
types).
Note. 5. The Service field pull-down allows the user to select the subscriber
application being used for the analysis (from the list of defined services).
Note. 6. The Mobility field pull-down allows the user to select the subscriber mobility
model being used for the analysis (from the list of defined mobility types).
Note. 7. This area of the Point Analysis window shows the connection status of the
SCH & PBCH, Uplink and Downlink at the selected point. A green
to any of these titles indicates a working connection; a red
of these titles indicates a bad connection.
Revision 1.3
iProtect: Internal
next
next to any
Page 238
A reference signal reception strength bar will be shown for all links which have signal
levels above the reference signal C/N threshold (see below).
Figure 172: Preamble Reception Strength Bars
The SCH & PBCH, Downlink, and Uplink portion of the Signal Analysis window (see
note 7 above) offers additional information about each of these links. Double clicking
on any of these names will bring up a data window with information about that link at
that measurement location (see the following three figures).
Revision 1.3
iProtect: Internal
Page 239
The Results tab, the 4th tab of the Point Analysis window, displays multiple arrows
connecting the cursor location to each transmitter, while the Point Analysis window
shows a table of numeric signal strength C (dBm) values and distances to each
transmitter from the analysis point as seen in the following figure.
Revision 1.3
iProtect: Internal
Page 240
9.4.4.
Number of
Allocated
Subframes
CP Duration
(s)
GT Duration
(s)
Max Delay
Spread (s)
103.13
96.88
6.25
14.53
684.38
515.63
16.67
77.34
203.13
196.88
6.25
29.53
684.38
715.63
16.67
100.16
Revision 1.3
iProtect: Internal
Maximum Cell
Radius (km)
Page 241
The TDD guard time can be configured to accommodate cell ranges up to the
prescribed 100 km requirement for LTE. Please refer to the LTE RF Planning guide for
additional information on the topic of timing based coverage limitations
(http://compass.mot.com/go/310442223).
Reports
The Reports are generated from previously created Predictions. On the Data tab click
on Predictions to expand it. Right click on a generated prediction and select Generate
Report.
Figure 178: Predictions Generate Report
Revision 1.3
iProtect: Internal
Page 242
Once the Generate Report option has been selected, a new window will open allowing
the user to select which columns (e.g. data) are to be reported.
Figure 179: Generate Report Data
Once the desired columns have been selected, the report will be generated.
For further analysis, the table can be copied into Excel by selecting all the columns and
rows and then copying and pasting them into Excel.
If a Focus Zone has been created to match the customers desired service area, the
statistics for a given image can provide some indication as to the coverage of the
service area. As mentioned in previous sections, when evaluating a Coverage by
C/(I+N) image, a calculated CINR threshold is used. This CINR threshold includes the
lognormal fade margin (whether applied as a margin to the threshold or selected by
checking Shadowing taken into account when the prediction is performed) that
accounts for the market-specific coverage area reliability percentage. In this case, the
design goal is to show that 100% of the service area (i.e. focus zone) is at or above the
Revision 1.3
iProtect: Internal
Page 243
CINR threshold value. Similarly, the design goal for an Effective Signal Analysis for Best
Traffic Signal Level is to show that 100% of the service area (i.e. focus zone) is at or
above the RSSI threshold.
9.5.2.
Histograms
The Histograms are generated from previously created Predictions. On the Data tab
click on Predictions to expand it. Right click on a generated prediction and select
Histograms.
Figure 181: Histogram of Best Signal Level
The histogram can also be viewed as a CDF or as an Inverse CDF (refer to the Atoll
User Manual for further information). Depending on the Type of Prediction that was
generated, there will be statistics generated in the box below the Histogram.
iProtect: Internal
Page 244
In the Data tab of the Explore window, right click on the Transmitter folder, and then
select the properties. A new window will open with the Transmitter Properties. In the
table within the Propagation tab, right click and Select All. Then right click again, select
Export and the Calculation Results Export window will open.
In this new window, the user can specify the path in which to write the pathloss planes.
The values inside the planes can be defined (dB, dBm, dBuV, and dBuV/m). Finally, the
user can specify if they would like to have pathloss planes as a Binary Format (BIL) or
as a Text formatted (tab or comma delimited).
Revision 1.3
iProtect: Internal
Page 245
Revision 1.3
iProtect: Internal
Page 246
There are a few noteworthy changes that accompany the introduction of the capacity
analysis. These changes are highlighted here:
The bearer selection thresholds associated with the definition of LTE Equipment
(refer to Section 7.2.3.4) are expanded to include a set of capacity curves to be
used in Monte Carlo simulations. The capacity curves have been calibrated
(aligned) with Minisim simulations.
The DL MCS0 bearer threshold is lowered to allow for up to 2.5 dB of additional
HARQ gain. This is only true for capacity curves.
BLER curves (relating CINR to BLER on a per-mobility, per-bearer basis) are
introduced to de-rate peak throughputs to effective throughputs. Refer to Section
7.2.3.4.1.
Model (RSS) and CINR standard deviations, in general, need to be disabled
(zeroed) for simulation work. Refer to Section 9.2.2 and Section 7.4.
SU-MIMO Gains (a function of CINR) are defined for 2x2 and 4x2 DL antenna
schemes. Refer to Section 7.2.3.4.2.
The following list provides the sections where settings that will impact the simulations
are discussed in further depth.
Sections 10.1 through 10.3 describe Services, Mobility Types, and Terminals.
Sections 10.4 through 10.5 describe User Profiles and Environments.
Section 10.6 describes the Traffic Maps and Subscriber Lists.
Section 7.2.2.4 describes Schedulers.
Section 10.7 describes the fundamental Atoll simulation process including the
algorithm, procedure (Section 10.7.1), output statistics (Section 10.7.2), traffic
map displays (Section 10.7.3) and method of applying load conditions to
coverage images (Section 10.7.4).
Section 10.8 describes the overall recommended Motorola procedure including
checks to perform, definition of capacities and exit criteria, and post-processing
of statistics (Section 10.8.1).
Section 10.8.2 summarizes the assumptions to adopt in making a quick
assessment of capacity. This should be useful when detailed customer inputs
are lacking.
Section 10.8.3 outlines the procedure for generate a density traffic map
constrained by coverage.
iProtect: Internal
Page 247
are available to the user can be either voice or data services. These services then are
defined further by parameters that set the priority, the upper limit bearer, the maximum
and minimum throughput, the average requested throughput, and the application
throughput parameters.
The Services within Atoll are accessed through the Services folder within the LTE
Parameters folder in the Data tab, as seen in the following figure.
As seen within this figure, the Motorola template defines four Services: FTP Download,
Video Conferencing, VoIP, and Web Browsing. The parameters that are used in
defining these services, along with their default values, are shown in the following table.
Note: The Video Conferencing service parameters should not be considered
recommended. They are simply placeholders.
Revision 1.3
iProtect: Internal
Page 248
Full
FTP
Video
Web
Download
Conf
Browsing
Data
Voice
Data
Voice
Data
Type
Priority
VoIP
Buffer
UL
DL
UL
DL
UL
DL
UL
DL
UL
DL
Activity Factor
0.5
0.5
0.5
0.5
Highest Bearer
50
29
50
29
50
29
50
29
50
29
256
1000
64
64
256
1000
12.2
12.2
1000
2200
64
100
64
64
64
100
12.2
12.2
180
360
64
64
180
180
12.2
12.2
360
360
95
95
95
74
95
The following figure shows an example of the GUI window set up for an FTP service.
Revision 1.3
iProtect: Internal
Page 249
1
3
4
5
6
7
8
9
9
10
NOTES:
Note. 1. The Name field allows the user to provide a name for the given service.
Note. 2. The Type field allows the user to define the type of service as either Voice
or Data. The Activity Factor field will appear within the interface when
Voice is selected. For further explanation of how the selection of voice or
data types impact simulations, refer to Figure 187, Note 4.
Note. 3. The Priority field allows the user to define the priority associated with the
service (0 being the lowest priority).
Note that the template default values are set so that the VoIP service has
the highest priority, followed by the Video Conferencing service, and that
the FTP Download and Web Browsing share the lowest priority.
Note. 4. The Activity Factor fields define, by direction, the probability of activity for
voice type services. These fields are not utilized for data services. For
further explanation of how the Activity Factor impact simulations, refer to
Figure 187, Note 4.
Revision 1.3
iProtect: Internal
Page 250
Note: The field may or may not appear for data services depending on the
release. Nevertheless, it is never applied for data services.
Note. 5. The Highest Bearer fields define, by direction, the highest bearer that can
be used by the service. This establishes an upper limit that is used during
bearer determination.
The Motorola template includes the same default settings across all
defined services. The default values match, by direction, the maximum
MCS and coding rate levels. Specifically, the UL is constrained to bearer
index 50 which corresponds to MCS 20 (16QAM with coding rate of 0.75).
This represents the highest bearer supported in Motorolas initial LTE
product offering. It is anticipated that a future product release will extend
UL support to 64QAM.
Table 13: Highest Bearer Settings
Highest Bearer
Template
Future
Uplink
50
(MCS 20, 16QAM 0.75)
58
(MCS 28, 64QAM 0.77)
Downlink
29
(MCS 28, 64QAM 0.93)
29
(MCS 28, 64QAM 0.93)
Note. 6. The Max Throughput Demand fields define, by direction, the maximum
throughput that the service can demand.
Note. 7. The Min Throughput Demand fields define, by direction, the minimum
throughput that the service can demand.
Note. 8. The Average Requested Throughput fields define, by direction, the
average requested throughput. These values are used in the simulation
during user distribution to calculate the number of users attempting a
connection. For further explanation of how the Average Requested
Throughput impacts simulations, refer to Figure 187, Note 4.
Note: In defining the services parameters Max Throughput Demand (MaxTD), Min
Throughput Demand (MinTD), and Average Requested Throughput (ART),
throughput values are specified. But, it is only in the scheduler definition that the
layer to which these target throughputs apply is specified. This means that target
throughputs can be specified at any layer within the services as long as the
corresponding layer is identified in the scheduler. The choice must be consistent
across all voice type services and across all data type services. Refer to the
scheduler description for more detail (Section 7.2.2.4).
Revision 1.3
iProtect: Internal
Page 251
Note. 9. The Application Throughput Scaling Factor and Offset fields allow the user
to enter parameters to be used when calculating the application
throughput from the effective throughput. These fields are used to account
for overhead associated with protocol headers as well as any other factors
which may lead to de-rating of the throughput. The application level
channel throughput is calculated in Atoll as follows:
Application Level Channel Throughput = Effective Channel Throughput * (Application
Throughput Scaling Factor/100) Application Throughput Offset
Note. 10. The Body Loss field allows the user to account for the body loss at the
subscriber device on a per-service basis. For example, if a handheld
device was used for a voice call, then a body loss (e.g. 2 dB) would be
entered to account for the head of the person holding the subscriber
device. Conversely, the same handheld device acting as a modem may
be used to access email and, consequently, exhibit a different body loss.
Note: Alternatively, this loss could be moved from this field and
incorporated into the Losses field of the Terminal properties instead (refer
to Figure 101, Note 5). In this case, the loss would be applied across all
services employing the terminal. Be careful not to double count the loss.
Revision 1.3
iProtect: Internal
Page 252
The following figures show example Mobility Types interfaces within Atoll. It allows the
user to enter the Name and associated Average Speed with each defined Mobility Type.
The properties window is accessed by double-clicking on the Mobility Type or by rightclicking on Mobility Types and selecting New for a new Mobility Type. This information
can also be viewed for all Mobility Types at the same time by looking within the Mobility
Types table, which can be accessed by right-clicking on Mobility Types and selecting
Open Table.
Revision 1.3
iProtect: Internal
Page 253
The parameters that are used in defining these Mobility Types are described below.
NOTES:
Note. 1. The Name field allows the user to provide a name for the given Mobility
Type.
Note. 2. The Average Speed field allows the user to define the average speed that
will be associated with that particular Mobility Type. (This speed is not
used in any calculations, it is just provided for information.)
Note: To utilize Subscriber Lists, it is required that an associated Mobility Type of
Fixed be defined. Refer to Section 10.6.4 for further information on Subscriber Lists.
iProtect: Internal
Page 254
The User Profiles within Atoll are accessed through the User Profiles folder within the
LTE Parameters folder in the Data tab, as seen in the following figure.
As seen in the figure above, there are two user profiles that are included in the Motorola
template: Business User and Standard User. This allows for defining a typical user and
a second, more demanding user. Names can be easily changed and new user profiles
easily added. The parameters that are used in defining these services are described
below.
Figure 187: Example User Profiles Window (Business User)
NOTES:
Note. 1. The Name field allows the user to provide a name for the given User
Profile.
Revision 1.3
iProtect: Internal
Page 255
Note. 2. The Service field allows the user to define the service or services that are
associated with the given User Profile. For example, in the figure above,
the Business User Profile is made up of four different Services: FTP
Download, Voice Conferencing, VoIP, and Web Browsing. The Services
that are available for this field are defined in the Services interface (as
described in Section 10.1).
Note. 3. The Terminal field describes the type of terminal that is associated with
the Service listed for this given User Profile. For example, in the figure
above, the CPE terminal is associated with each of the Services except
VoIP which is associated with the MS terminal. The Terminals that are
available for this field are defined in the Terminals interface (as described
in Section 10.3 and Section 7.3).
Note. 4. The Calls/hour field has a different meaning depending upon whether it is
used with a voice or data service.
In the case of a voice service (i.e. a service with type voice), this field is
used to define the busy hour call attempts (or call arrival rate). When
multiplied by the duration (or average hold time) and normalized by 3600
(seconds within the sample period), it yields the Erlangs of voice traffic
which is also the probability of use of the service.
In Figure 187 above, the VoIP service shows 0.2 busy hour call attempts
and a 240 second average hold time which yields 0.013 Erlangs or a 1.3%
probability for use of the voice service. Note furthermore, that for Monte
Carlo simulations, the voice activity factor defined for the VoIP service will
also be applied to determine the probability of being active (bursting) in
each direction.
In the case of a data service (i.e. a service with type data), this field is
used to define the busy hour session attempts (or session arrival rate).
When multiplied by the data volume (kB/session attempt), scaled to bits,
and normalized by average requested throughput (defined for the data
service) and 3600 (seconds in the sample period), it yields the probability
of being active (bursting) in each direction.
In Figure 187 above, the Web Browsing service shows 0.1 busy hour
session attempts and 4500 kBytes/session attempt which yields 0.0055
(0.1 x 4500 x 8 / 3600 / 180 kbps) or a ~0.6% probability of being active
(bursting) in the DL direction (assuming an average requested throughput
of 180 kbps, see Table 12). In the case of an interactive service like web
browsing, the data activity factor is low and it is likely the session data
volume assumed above is distributed over several separate downloads
corresponding to different web pages with significant think time or
reading time in between downloads.
Note: In order for all the services defined for a User Profile to be taken into
account during traffic scenario elaboration, the sum of activity probabilities
must be lower than 1. Expressing this differently, Atoll doesnt model a
Revision 1.3
iProtect: Internal
Page 256
Revision 1.3
iProtect: Internal
Page 257
As seen within this figure, there are four Environments that are included in the Motorola
template: Dense Urban, Urban, Suburban, and Rural. The parameters that are used in
defining these environments, along with their default values, are described below.
There are two tabs within the Environments properties interface: a General tab and a
Clutter Weighting tab. The following figure describes the parameters within the General
tab.
Figure 189: Example Environments Window (Urban) General Tab
Revision 1.3
iProtect: Internal
Page 258
NOTES:
Note. 1. The Name field allows the user to provide a name for the given
Environment.
Note. 2. The User field defines the User Profile(s) associated with the given
environment. For example, in the figure above, both the Business User
and Standard User profiles are associated with the Urban environment.
(Within the Motorola template, Business Users are associated with the
Dense Urban and Urban environments, Standard Users are associated
with the Dense Urban, Urban, Suburban, and Rural environments.)
Note. 3. The Mobility field defines the Mobility type that is associated with the
selected User Profile for the given Environment. For example, in the figure
above, the PB3_Capacity Mobility Type is associated with both the
Business User and Standard User profiles. Note that for capacity studies,
the _Capacity mobility types need to be selected in producing traffic
maps so that the correct bearer thresholds are indexed.
Note. 4. The Density (Subscribers/km2) field defines the user density associated
with the selected User Profiles for the given Environment. For example, in
the figure above, the subscriber density for both the Business User and
Standard User profiles is 400 subscribers per square kilometer. This
assumes equal subscriber density for these two user profiles, but for a
specific design the assumptions could be that there will be twice as many
business users as standard users. The density settings characterizing the
default Environments found within the template are simply placeholders.
The systems designer is responsible for setting inputs to correspond to the
actual customer traffic projections.
The following figure describes the parameters within the Clutter Weighting tab. The
Clutter Classes that are listed in this tab are defined in the Clutter Class properties as
described in Section 7.4.
Revision 1.3
iProtect: Internal
Page 259
NOTES:
Note. 1. The Weight field allows the user to assign a weight to each clutter class to
adjust the user distribution. For example, using the clutter classes shown
in the figure above, if a weight of 1 is used for Dense Forest and a
weighting of 9 is used for High Density Urban, then the user distribution
would have 9 times the users in the High Density Urban area than in the
Dense Forest area. Assume a given area is 50 square kilometers with a
user density of 800 subscribers per square kilometer. This would equate
to 40,000 subscribers in the area. Further assume that this area is made
up of only High Density Urban and Dense Forest clutter classes and that
these clutter classes have been assigned weights as previously
mentioned (9 for High Density Urban and 1 for Dense Forest). Given these
weightings, this would equate to 4,000 subscribers in the Dense Forest
clutter class and 36,000 subscribers in the High Density Urban clutter
class.
Note that the Motorola template provides equal weighting to each clutter
class using the default setting of 1. The user may adjust these to
represent the distribution for the market being modeled.
Note. 2. The % Indoor field allows the user to specify the percentage of indoor
subscribers for each clutter class, if desired. In the Monte-Carlo
simulations, an additional indoor loss will be added to the indoor users.
This additional indoor loss is specified within the Clutter Class properties
(as described in Section 7.4). The default setting for this field is 0%, as
seen in the figure above and within all Environments specified in the
Motorola template.
Revision 1.3
iProtect: Internal
Page 260
The New Traffic Map interface is accessed by right-clicking on the Traffic folder under
the Geo tab and selecting New Map. Three traffic map classes, as shown in the figure
above, are made available and include: user profile, sector, and user density. The user
profile class is further sub-divided into user profile (user profile densities) and
environments (user profile environments).
Some general comments on traffic maps include the following:
Generally, the geometry of traffic maps are best specified via imported data files
supplied by the customer. Raster file formats are used for environment and user
density traffic maps while vector file formats are used for user profile traffic maps.
Sector maps utilize the Atoll geo data file format. Alternatively, vector editing
tools within Atoll allow for manually creating and modifying polygons.
Revision 1.3
iProtect: Internal
Page 261
Within the Motorola template, mobility types used in traffic maps should be
selected from those which index capacity curves, i.e. have the suffix _Capacity.
User profile traffic maps are well suited towards traffic projections which are
marketing-based.
The subscriber density, i.e. subscribers / km2, should be known for the service
region(s).
One or more user profiles are defined which characterize the services, terminals,
and offered load. (Refer to Section 10.4 for details on defining user profiles.) The
probability of activity for a service is derived from the load parameters within the
user profile together with parameters which characterize the service.
A single user profile can be mapped to a region (polygon) in a user profile traffic
map. Alternatively, a set of user profiles can be mapped to a region via the use
of environment traffic map. (Refer to Section 10.5 for details on defining
environments.)
The user profile traffic map properties window, shown in the figure below, provides an
example of basic map parameters. In this example, both the Business User user
profile and the PB3_Capacity mobility type have been specified globally for the traffic
map (i.e. they have been selected by value from a pull-down menu of available
choices). The density is user-specified via the Density field within the traffic map table.
Each row of the traffic map table corresponds to a polygon and each polygon may have
a different density value.
Revision 1.3
iProtect: Internal
Page 262
An option exists for differentiating the probability of user distribution within the region
based on clutter type (although, typically, all weights are set to 1 and no clutter
differentiation is used). Similarly, the option exists to specify the average percentage of
indoor users on a per clutter class basis.
The environment traffic map may be the option best suited to system design work when
marketing information is available. Regions, such as in the Urban environment
properties window seen below, are defined by specifying the subscriber density, i.e.
subscribers / km2, of user profiles and mobility pairings. The user profiles themselves
specify the mix of services and terminals. The environment traffic map allows users to
label regions (polygons) by environment (e.g. Urban, Suburban, etc.). When creating
an environment map, Atoll supplies an Environment Map Editor specifically for this task.
Environment traffic map tables are not accessible. This means that once a polygon is
assigned a particular environment (e.g. Suburban) at creation, it cannot be changed to
be a different environment. It must be deleted and re-created. The geometry (shape) of
polygons may be modified. Subscriber densities are specified as part of the
environment definitions and not within the environment traffic map directly.
Revision 1.3
iProtect: Internal
Page 263
Sector traffic maps are well suited towards traffic projections which are live
data-based, i.e. where a network management system provides empirical insight
into the actual load being carried by the system.
To exploit this traffic map, it is likely that the system has already gone
commercial and is past initial system design. But, this is not necessarily the
case. In instances where the LTE broadband system is being layered on top of
an older technology, the live statistics from the incumbent technology can be
used to derive insight into the traffic distribution to be expected on the new
system. Although the magnitude of the traffic may require scaling, the traffic
proportions among the sectors would be correct. This approach, of course,
depends on the validity of the assumption that the two systems have comparable
traffic distributions.
Sector traffic maps require best server images corresponding to the sectors for
which traffic is available.
Revision 1.3
iProtect: Internal
Page 264
and downlink in the pull-down menu associated with the Sector traffic map
selection of the New traffic map window (see Figure 191).
The sector traffic map properties window, shown below, provides an example of basic
map parameters. In this example, the distribution of terminals and mobility types are
specified globally as 100% CPE and 100% PB3_Capacity. As with user profile based
traffic maps, options exist for differentiating based on clutter class and indoor/outdoor.
Figure 194: Sector Traffic Map Properties
Referring to the example sector traffic map table below, the density is user-specified for
each sector by specifying the number of active users on a per-service, per-direction
basis. Note that for a service such as VoIP, a realistic distribution would have some
traffic for downlink, uplink, and uplink + downlink. The services present within the table
automatically reflect all defined services (found under the Services folder of the Data
tab, refer to Section 10.1).
Revision 1.3
iProtect: Internal
Page 265
As a point of contrast, note that user profile based maps specify a density that
corresponds to all users and then the number of active users for each direction is
determined based on probabilities derived from the service characteristics and the
offered load per user. This is different from sector traffic maps where the number of
active users is supplied directly.
10.6.3. User Density Maps
The third class of traffic maps are those based on user density. The user density maps
have the following characteristics.
User density maps are a logical choice should the customer supply a geo data
set where the number of subscribers is specified on a per-pixel basis. The input
file must be in a raster file format (either 16 or 32 bit).
All users are considered active. The user density map properties allow for
classifying the users activity status as downlink-only, uplink-only, both uplink and
downlink, or all (i.e. the aggregate of all directions). The activity status of users
is specified at the time of creating the traffic map (via the pull-down menu
associated with the User density traffic map selection of the New traffic map
window, see Figure 191), but can be changed at any time within the properties
window. When All activity statuses is selected, the users will be decomposed
into the various directions based on activity factors derived from the services
definitions.
Note: The activity status of inactive present in the interface is ignored for LTE.
Multiple user density maps can be defined and simultaneously employed to fully
characterize the traffic load.
Although the user density map can be created internally by specifying polygons
and assigning them densities, this is not recommended, unless there are only a
few polygons. It is preferable to leverage user profile traffic maps where greater
flexibility is present. User profile traffic maps allow for importing vector file
formats and, also, specifying non-globally the mix of services, terminals, and
mobility types.
Revision 1.3
iProtect: Internal
Page 266
The user density traffic map properties window, shown below, provides an example of
basic map parameters. In the case of a user density map, the distribution of all the
attributes (i.e. services, terminals, and mobility) is specified globally. Density values
that are imported within a raster file are not visible since they are variable on a per-pixel
basis. For manually created polygons, the density is supplied on a user per km2 basis
via a Density field within a table which is accessed via a subfolder of the user density
map. Both the subfolder and table are labeled density values by default. Each row of
the table corresponds to a polygon and each polygon may have a different density
value. The subfolder only appears once the map is edited, i.e. once polygons are
created. For greater detail, review Section 12.3.2.3.2, Creating a User Density Traffic
Map, of the Atoll User Manual.
Figure 196: Density Map Properties
Subscriber lists define the exact number and location of subscribers as opposed
to a random distribution based on a mean probability as with traffic maps.
Since subscriber lists depend on real, fixed locations, they are to be applied to
commercial markets where the user locations are established.
The mobility for subscriber lists is not specified by the user, but, rather, is
expected to be named Fixed.
For simulations, the mix of services and terminals (likely to be a single terminal
for fixed users) is specified via a user profile. Calculations can be performed in
Revision 1.3
iProtect: Internal
Page 267
the absence of simulations and, in this case, the service and terminal type are
specified separately within the database.
Subscriber lists can be created by going to the Data tab, right-clicking on the
Subscribers folder and selecting New List, or a list can be imported. The subscriber list
will then appear in the Subscribers folder. Refer to the Atoll User Manual for further
discussion on subscriber lists.
Revision 1.3
iProtect: Internal
Page 268
In the balance of this section, some key aspects of the simulation process will be
highlighted.
Revision 1.3
iProtect: Internal
Page 269
For each subscriber dropped into the simulation, CINRs are derived and best
bearers determined. For this determination, the scheduler parameters Bearer
Selection Criterion and Uplink Bandwidth Allocation Target are important (refer to
Section 7.2.2.4).
If a subscriber cannot connect to the system even at the lowest bearer, then it is
given a connection status of No Service. Subscribers are required to have a
connection for each direction in which they are active. For example, if a
subscriber has an activity status of DL+UL, then bearers must be allocated in
each direction. A failure to connect to the system corresponds to a coverage
outage. When CINR standard deviation is enabled, then No Service statistics
should correspond to expectations for coverage reliability established via
coverage predictions. It is the normal practice to disable CINR standard
deviations for capacity studies and to establish coverage reliability via coverage
predictions. The percentage of users in outage corresponds to a probability of
coverage and will not increase with load, but, rather, will converge with greater
accuracy.
Once bearers are selected, channel throughputs are derived. The basic formula
for peak channel throughput is: CTP = R x / D. The variable R corresponds
to the number of resource elements available for use by the shared channel.
The overheads for control channels, reference signals, etc. have been
discounted in deriving R. The variable represents the peak efficiency (bits per
resource element) associated with the specific bearer. Multiplying R by yields
bits per frame and dividing by the frame duration, D (0.01 sec/frame), yields bps.
Effective throughput is derived by scaling by (1 BLER) and application
throughput takes the effective throughput and applies a user-defined scalar and
Revision 1.3
iProtect: Internal
Page 270
offset. Note that the channel throughput assumes the use of the entire available
bandwidth even in the uplink. For the uplink, the allocated bandwidth throughput
(ABTP = CTP x allocated frequency blocks) is also derived and represents the
upper bound on what the subscriber can achieve on the UL. For UL coverage
predictions, the ABTP is preferred to CTP.
The primary outputs of the simulation process are the DL Traffic Load, UL Traffic
Load, and the UL Noise Rise. These resultant values can be fed back into
coverage predictions. For the DL Traffic Load, it is considered advisable to
simply produce coverage predictions while retaining the assumption of 100% TL.
The UL Traffic Load is not actually employed in UL calculations and, therefore, is
purely informational. Instead, the UL Noise Rise (NR) is used to generate UL
calculations. Without the benefit of simulations to generate realistic UL NR
values, UL coverage predictions depend on user-specified values which are likely
to exhibit greater error. For this reason, it is recommended that simulations be
performed and that the resultant UL NR values be applied and UL coverage reevaluated.
A large set of statistics are output from the simulations. Each subscriber is
classified with a connection status indicating the direction of activity (i.e. DL, UL,
or UL+DL), if connected, or the cause for lack of connection (i.e. No Service,
Scheduler Saturation, or Resource Saturation). These statistics will be used
to establish whether or not the capacity criterion has been met and also to derive
system and sector capacities.
Revision 1.3
iProtect: Internal
Page 271
Revision 1.3
iProtect: Internal
Page 272
effort to reduce the time of simulation and to identify more appropriate bounds for the
simulation.
Stop Calculations
Any calculations in progress may be stopped by clicking the Stop Calculations button
(
) in the toolbar.
In the top section of the Statistics tab, Request (offered) traffic statistics are provided.
The number of users trying to connect reflects the random draw of active subscribers
for this simulation and the breakdown is given by direction (UL, DL, and UL+DL). Each
service definition contains minimum and maximum throughput demands and these are
aggregated across all dropped subscribers within the simulation to provide boundaries
for the offered load. These statistics are provided overall for the computation zone and
also broken down on a per-service basis.
In the bottom section of the Statistics tab, Results (carried) traffic statistics are
provided. The number and percentage of rejected users is provided in the aggregate
Revision 1.3
iProtect: Internal
Page 273
and by cause. The number of connected users is then given, in the aggregate and by
direction. The aggregate user throughputs at the peak, effective, and applications
levels are also provided in both the DL and UL directions. These statistics are provided
overall for the computation zone and also broken down on a per-service basis.
The percentage of users rejected for No Service should be reviewed to verify that it
corresponds to an acceptable or expected level of system coverage outage. No
scheduler saturation is expected (with Max Users set to null). Percent Resource
Saturation should be reviewed to verify that system blocking is at an acceptable level
(<2%).
The Sites tab statistics provide, on a per-site basis, throughputs at peak, effective, and
application levels by direction (DL and UL) and in the aggregate as well as by-service.
In addition, the number of subscribers rejected for each cause is provided. The Cells
tab statistics provide the same statistics as the Sites, but on a cell (i.e. sector) basis.
Additionally, the DL Traffic Load (%), UL Traffic Load (%), and UL Noise Rise (dB) are
provided.
The Mobiles tab statistics provide detailed information on the location and state of each
active mobile (subscriber) dropped in the simulation. Information includes, but is not
limited to: Activity Status, Connection Status, DL/UL CINRs, DL/UL bearers, DL/UL
peak/effective/application channel and user throughputs, and allocated bandwidth (UL
only).
The Initial Conditions tab summarizes the parameters used for the simulation, e.g. max
number of iterations, global scaling factor, convergence parameters, and the traffic
map(s) employed.
A set of average statistics representing the average for a group of simulations can be
viewed by right-clicking on the group folder and selecting Average Simulation. All tabs
are recreated as discussed above except for the Mobiles tab.
10.7.3. Displaying Traffic Distributions
Atoll allows for graphically displaying Mobiles statistics from simulations on the map. To
accomplish this, first access the display properties for the LTE Simulations folder and
then select a display type (e.g. Discrete values). A specific Mobiles statistic (e.g.
Connection Status) can be selected for display on the map from the Field menu. (Note
that the statistics made available for selection are constrained by the choice of display
type.) By this means, a user can easily display all mobiles with the activity status
uniquely color-coded. For further details, refer to the LTE chapter of the Atoll User
Manual under the section called Displaying the Traffic Distribution on the Map.
10.7.4. Coverage Predictions based on Simulation Results
The primary outputs of the simulation process are the DL Traffic Load, UL Traffic Load,
and the UL Noise Rise. These resultant values can be fed back into coverage
predictions. For the DL Traffic Load, it is advisable to produce coverage predictions
while retaining the assumption of 100% TL. The UL Traffic Load is not actually
employed in UL calculations and, therefore, is purely informational. Instead, the UL
Noise Rise (NR) is used to generate UL calculations. Without the benefit of simulations
Revision 1.3
iProtect: Internal
Page 274
iProtect: Internal
Page 275
Revision 1.3
Identify the limiting sector. The limiting sector is that which blocks with
the highest %RS.
Page 276
that
leverages
the
Note: Excels limit of ~65K rows (Excel 2003 and earlier) for the worksheet size
may constrain the ability of post-processing the statistical data via this method.
Excel 2007s limit is ~1M rows (which doesnt present a problem).
Note: All derived data and charts dependent upon Mobiles data described herein
will not be generated when the source data comes from a set of Average
simulation statistics. Mobile statistics are not included with Atolls average
statistics.
1. Open the AtollStatsTemplate.xls spreadsheet. This spreadsheet, with the latest
version macros, is located at: http://compass.mot.com/go/318588510.
2. Within Atoll, open the simulation properties window. This contains the 5 tabs
with statistics.
Note: It is likely that interaction will take place across platforms where the
spreadsheet will be on a desktop compute while Atoll will be running remotely on
a server.
3. Copy-paste the data from the properties window over to the spreadsheet as
follows:
Revision 1.3
iProtect: Internal
Page 277
From the Statistics tab in Atoll to the Sheet1 tab in Excel. Separate
transfers for the Request and Results data will be needed. This data is
copied for informational purposes and to have a complete record within the
spreadsheet, but it will not be post-processed. A Ctrl+A will not work to
capture all the data within a section; rather, a click and drag approach to
selecting all of the data will be needed.
From the Sites tab in Atoll to the Sheet2 tab in Excel. Select the upper-left
corner of the table will select the entire set of statistics (as in Excel). A Ctrl+C
will copy the data and a Ctrl-V into the upper-left corner (cell A1) of the Excel
sheet will paste the data.
From the Cells tab in Atoll to the Sheet3 tab in Excel, following the same
process used for Sites data.
From the Mobiles tab in Atoll to the Sheet4 tab in Excel, following the same
process used for Sites data. Note that due to the size of the data, the copy
may take a few seconds. Atoll will provide progress of the copy on the status
bar.
From the Initial Conditions tab in Atoll to the Sheet5 tab in Excel. This data
is copied for informational purposes and to have a complete record within the
spreadsheet, but it will not be post-processed. A Ctrl+A will work to capture
all the data within a section.
Note: Atoll provides export options for its statistical data, but the approach
outlined here is just as expeditious as any.
4. Within the spreadsheet, invoke the FmtAll macro by using the shortcut Ctrl+a
(for all). Prior to invoking the macro, it is advisable to close any other open
spreadsheets. Also, perform a Save As to rename, appropriately, the
spreadsheet to reflect the assumptions under which the data was generated.
The following functions will be performed by the FmtAll macro.
Summary statistics are provided for each numerical data field. These include
Average, Count, Max, Min, and Sum all of which dynamically reflect the
filtered rows. The 10th and 90th percentiles are also provided across all data
rows (no filtering). These statistics can represent the system when the filtered
rows correspond to the entire system.
The numerical site and sector identifications are extracted from their
alphanumeric representations and provided in their own separate fields. This
facilitates filtering based upon site and sector numbers.
A Zone field is added that is arbitrarily set to the value 1. This new field can
be user-defined and is intended to be used in creating special filters.
New data fields have been derived for each of the data sets as follows:
Revision 1.3
iProtect: Internal
Page 278
For Mobiles
DL Connected Users
Edge User Tput (DL) and Edge User Tput (UL) The 5th percentile
user throughput.
%No Svc and %Res Sat The percentage of users rejected for No
Service or Resource Saturation.
Four Site charts (found on sheet Site Charts) show key statistics across all
sites of interest (which reflect filtering dynamically).
Connected Users
Six Sector charts (found on sheet Sector Charts) show key statistics across
all sectors of interest (which reflect filtering dynamically).
Revision 1.3
iProtect: Internal
Page 279
5. If statistics are desired for any subset of sectors or sites, then the appropriate
filtering ought to be introduced to the Sites, Sectors, and Mobiles sheets. The
Zone field is provided as a placeholder to facilitate more complex or custom
filtering.
As an example, it is possible to filter on rows where the Zone field equals 1 when
a function has been introduced into the Zone column that returns a 1 whenever
the row belongs to a site of interest determined per some lookup table.
6. Within the Mobiles sheet, select any cell on the header row (i.e. row 8, where
statistics names are provided) and invoke the KeyMobileCharts macro by using
the shortcut Ctrl+m (for mobiles). Prior to invoking the macro, it is advisable
to close any other open spreadsheets. The following functions will be performed
by the KeyMobileCharts macro. Eleven charts with accompanying data tables
are produced to reflect various key distributions and relationships. This data
reflects the particular mobiles of interest selected at the time of their generation,
i.e. it may represent a single sector, a group of sites, or the entire system. The
tables and charts are statically generated (i.e. they will not change when filtering
is changed on the Mobiles sheet). The macro can be invoked again to produce a
new set of charts when filtering is changed should the user so desire. The new
charts and data tables, are classified as follows:
Revision 1.3
iProtect: Internal
Page 280
For distributions, statistical data is provided for both PDF and CDF charts for both
counts as well as percentages.
Note that the use of CTP (Channel Throughput), as found in various X-Y charts,
can be interpreted as separate bearers. Each vertical band of data corresponds
to the distribution (e.g. of a user throughput) for a particular bearer allocation.
7. A macro named GenericDist can be invoked to generate distribution charts for
any column of data on the Sites, Sectors, or Mobiles sheets. The data collected
represents both CDF and PDF of absolute and relative (percentage) values. The
macro will automatically select appropriate bins based on data type. For
numerical data, it will automatically choose the number and size of bins. For
string data (such as Activity Status), it will automatically report on all values
present. For Bearer data (a special type of string data), it will create bins that
correspond to all the valid bearers. To invoke this macro, select the cell
containing the statistics name (at the head of the column of data) and apply the
shortcut Ctrl+g (for generic).
With respect to assessing capacity in terms of numbers of subscribers, the following
should be considered. First, idle users are not represented among the Mobile
statistics nor any statistic derived from them, e.g. Connected Users. Second, both
idle and active users may be or may not be represented among the load offered to
the system depending on the traffic map selected. Finally, as is the practice within
QCAT, it should be considered normal practice to de-rate the estimate of user
Revision 1.3
iProtect: Internal
Page 281
capacity to account for additional overhead messaging not already considered within
the modeling.
10.8.2. Assumptions for Quick Assessment of Capacity
In many circumstances, the customer has provided little in terms of detailing the mix of
services or the load per user upon which to make an assessment of capacity. Here are
a recommended set of assumptions to adopt. In presenting results, all assumptions
should be caveated to the customer.
1. Assume the Full Buffer service.
2. Create a user density traffic map that supplies a fixed users/km^2.
The subscriber loading can be derived from total number of subscribers and area
being served. Note that a density map, like a sector traffic map, specifies active
users. Consequently, the traffic should be scaled within the Monte Carlo
simulation through use of the GSF to reflect the over-subscription factor.
If the customer has not supplied an overall target subscriber population for the
service area, then an estimate could be based on 1 active subscriber per MHz of
bandwidth per sector. An initial estimate of sectors is needed.
Alternatively, a sector traffic map could be employed that directly specifies the
number of active users per sector. This could still use the rule-of-thumb of 1 user
per MHz of bandwidth per sector. The difference between a sector traffic map
and the user density map is that the user density map can generate a spatially
uniform traffic distribution. A sector traffic map is roughly uniform, but only to the
degree that sector coverage is uniform.
3. Constrain the traffic map to only include covered areas.
a. For a user density traffic map, refer to Section 10.8.3 for details on how to
accomplish this.
b. For a sector traffic map, the use of split-in-cells can take the coverage
image and split it into different cells which can then be used to generate a
sector traffic map.
4. Do not specify per-clutter weightings so as to exclude certain areas from getting
dropped mobiles. The results are unpredictable.
5. In reviewing the resultant simulation statistics, verify that the system can carry
the predicted load and report the available sector and system capacity.
10.8.3. Applying Coverage Constraint to Density Map
Here is an outline of how to get a density traffic map to reflect a coverage image. The
coverage image should already exist. Don't change the projection coordinate system
(there is no need). You might need to change the display coordinate system if there is a
mismatch between the coverage and traffic map geometries.
1) Export the coverage image as a mif file.
Right-click for "Export the Coverage".
Revision 1.3
iProtect: Internal
Page 282
For resolution, filtering, and smoothing, try 50m, 75%, and 50%, respectively.
The process of exporting takes time. Allow ~5 minutes.
2) Create a user profile traffic map using user profile densities.
Geo>Traffic>New Map
User profile traffic map
User profile densities
"Import" the mif file
Note: The fields of the "properties" window that opens are not important. This
map has been created only to leverage its polygon properties.
OK
3) Create a user density traffic map using Create.
Geo>Traffic>New Map
User density traffic map (no. of users/km^2)
All activity statuses
Create
Note: Set fields on General, Traffic, and Display tabs as appropriate (you can
always come back to revise these settings).
OK
4) Create a simple polygon for the density traffic map.
Right-click on user density traffic map
Select Edit.
Use the Vector Edition toolbar to create a simple polygon.
Deselect the editing tool (so that you get a pointer on the map).
5) Open polygon properties of the user profile traffic map.
Select the polygon within the map image (you might need to make it visible).
Right-click properties
Copy all of the data (Ctrl-A) from the Geometry tab.
Cancel
6) Open the polygon properties of the user density traffic map.
Select the polygon within the map image (you might need to make it visible).
Right-click properties
Select all of the data (Ctrl-A) from the Geometry tab.
Overwrite with all the data previously copied from the other map (using Ctrl-V).
Revision 1.3
iProtect: Internal
Page 283
OK.
7) Delete the user profile traffic map.
Right-click the user profile traffic map folder.
Delete
8) Specify the user density value for the polygon set.
Select the polygon within the map image (you might need to make it visible).
Right-click properties
Specify the Traffic Density field on the General tab.
Alternatively, open the Density values sub-folder under the user density traffic
map.
Right-click on the sub-folder and select Open Table.
Specify the Traffic Density field within the table.
Revision 1.3
iProtect: Internal
Page 284
Revision 1.3
iProtect: Internal
Page 285
The expected result of accounting for these MIMO parameters in the system design is:
Revision 1.3
iProtect: Internal
Page 286
5. Adjust the Clutter Class Parameters as needed. See Section 7.4 for further
information.
a. Enter the appropriate SU-MIMO Gain Factor to adjust the Max MIMO
Gain for SU-MIMO.
Once the system has been configured with MIMO settings, the process of generating
coverage images is the same as what is discussed in Section 9.
Revision 1.3
iProtect: Internal
Page 287
Revision 1.3
Retransmissions
91%
10%
0.5
83%
20%
1.0
78%
29%
1.5
73%
36%
2.0
70%
43%
2.6
66%
50%
iProtect: Internal
Page 288
Revision 1.3
iProtect: Internal
Page 289
Assume that a traffic channel study is being run for a pedestrian environment using the
PB3 channel model. The following figure shows the Bearer Threshold values when no
additional HARQ gain is incorporated.
In order to incorporate additional HARQ gain into the bearer selection thresholds, the
MCS0 C/(I+N) value would need to be reduced by the additional HARQ gain. For
example, assume that 2.0 dB of additional HARQ gain is to be used in the design (i.e.
2.0 dB HARQ gain in addition to the HARQ gain that is included in the SNR values).
The lowest order modulation and coding scheme, identified as Best Bearer 1 in Figure
201, would be reduced by 2 dB. The new value to enter into the table for Best Bearer 1
would be 0.669472 2 = -1.330528.
If the HARQ gain is assumed to be on both the downlink and uplink, then the C/(I+N)
thresholds need to be set for the Motorola eNB Reception (UL) and the Motorola UE
Reception (DL). A different HARQ gain could be assumed for the uplink as compared to
the downlink and therefore each of the C/(I+N) Thresholds tables would need to be
modified accordingly.
Revision 1.3
iProtect: Internal
Page 290
The bearer thresholds can be adjusted by typing in the new C/(I+N) values directly in its
chart value location as shown in the figure above.
For further information regarding setting Bearer Thresholds, please see Section 7.2.3.4.
12.3.2. Adjusting Image Thresholds to Include HARQ for Traffic Channel Studies
When generating images for traffic channels in cases where additional HARQ gain is
used, the image thresholds must be adjusted by the additional HARQ gain.
In cases where additional HARQ gain is used, the image threshold equations are
modified as follows:
The downlink Signal Quality Analysis (DL) threshold is given as follows:
RSSI Cutoff (DL) = kTB + NF + SNR + Fast Fade Margin - Diversity Gain - TXAA
Gain - Additional HARQ Gain + Interference Margin
The uplink Signal Quality Analysis (UL) threshold is given as follows:
RSSI Threshold (UL) = kTB + NF + SNR + Fast Fade Margin - Diversity Gain Additional HARQ Gain + Interference Margin
For further information regarding images, thresholds, and evaluation of images, please
see Sections 9.3.1 and 9.4.2.
12.3.3. Throughput Reduction Associated with Additional HARQ Gain
When additional HARQ gain is included in a study, the resulting throughput images
need to be adjusted to reduce the throughput accordingly. Table 14 shows the effective
PHY rates that are associated with different additional HARQ gains and retransmission
numbers.
In order to account for additional HARQ gain within the throughput images, the user
needs to manually reduce the MCS0 throughput level within the legend based on the
effective PHY rate that is associated with the specific additional HARQ gain that is being
used in the design. For example, if 2.0 dB of additional HARQ gain is being assumed in
the design, this is associated with 70% effective PHY rate (per Table 14). Therefore, the
throughput levels in the throughput image legend for MCS0 would be reduced to 70% of
the PHY rate value.
The following uses a ML-CAT example to show how the throughput legend values
would change to incorporate an additional HARQ gain.
Revision 1.3
iProtect: Internal
Page 291
The following image shows an example ML-CAT screenshot where 2.0 dB of additional
DL HARQ gain is used. As seen in Table 14, 43% retransmissions is entered by the
user, which corresponds to 2 dB of HARQ gain.
Figure 202: Example PHY Data Rates not Accounting for HARQ Gain
The figure below shows a Post-HARQ PDSCH data rates and Information Rate under
the link budget tab in ML-CAT. The Post HARQ rate accounts for the reduction in the
throughput rate due to the additional HARQ gain. As expected, this figure shows that
the Post-HARQ PHY data rate is 70% of the downlink PHY data rate before the HARQ
gain is incorporated (e.g. 1393 kbps * 70% = 975 kbps).
Revision 1.3
iProtect: Internal
Page 292
13. References
1.
2.
3.
4.
5.
6.
7.
Title
Atoll User Manual
Location/Version
http://compass.mot.com/go/atolldo
cs
Atoll Technical Reference Guide http://compass.mot.com/go/atolldo
cs
LTE ML-CAT
http://compass.mot.com/go/lteplan
R2.1.2
LTE RF Planning Guide
http://compass.mot.com/go/lteplan
Version 1.0
LTE ML-CAT User Guide
http://compass.mot.com/go/lteplan
Version 1.0
Supplement Atoll 2.8.1 Features http://compass.mot.com/go/31693
for LTE and WiMAX RF System
6464
Design Procedure
Supplement Atoll 2.8.2 Features http://compass.mot.com/go/31693
for LTE and WiMAX RF System
6464
Design Procedure
Revision 1.3
iProtect: Internal
Date
-
Author(s)
Forsk
Forsk
Aug-2009
Aug-2009
Aug-2009
Jan-2010
Oct-2010
Page 293
14. Glossary
Acronym
Meaning
AAS
AMS
AP
EnodeB
BE
Best Effort
BS
Base Site
BSID
Base Station ID
CATP
CDF
CINR
CPE
CTP
Channel Throughput
DAP
Diversity EnodeB
DL
Downlink
dB
Decibel
dBi
EFS
ERP
GAP
GSF
IAP
Intelligent ENodeB
Kbps
LOS
Line-of-sight
MAC
MAP
MaxTD
Mbps
MCS
MIMO
MinTD
Revision 1.3
iProtect: Internal
Page 294
MMSE
MPR
Mbits
Megabits
NLOS
Non-line-of-sight
nrtPS
PD
Proportional Demand
PDU
PF
Proportional Fair
RLC
RTG
TXAA
SDMA
SDU
SM
Spatial Multiplexing
SNR
SISO
TDD
TMA
TTG
Tx
Transmit
TxAA
UL
Uplink
VOIP
Revision 1.3
iProtect: Internal
Page 295