LTE RF System Design Procedure With - Atoll PDF

LTE
RF System Design Procedure

for use with Atoll
Revision 1.3
Atoll Version 2.8.0
LTE PLANNING AND DESIGN
IPROTECT: INTERNAL
© Copyright 2010 Motorola, Inc. All Rights Reserved

LTE RF System Design Procedure - Atoll
This page is intentionally left blank.
Revision 1.3 iProtect: Internal Page 2

Table of Contents
1. INTRODUCTION................................................................................................ 17
1.1. LTE RF SYSTEM DESIGN PROCEDURE ............................................................... 17
1.2. PROCEDURE FLOW CHART ................................................................................ 17
1.2.1. Budgetary RF System Design Process Flow............................................ 18
1.2.2. RF System Capacity Analysis .................................................................. 20
1.2.3. Detailed RF System Design Process Flow ............................................... 22
2. LTE RF LINK BUDGET ...................................................................................... 25

2.1. ML-CAT .......................................................................................................... 26
3. LTE SYSTEM CAPACITY CALCULATION ........................................................ 29

3.1. USING ML-CAT FOR LTE CAPACITY ANALYSIS ................................................... 29
4. INSTALLING ATOLL .......................................................................................... 30

4.1. COMPUTER CONFIGURATION .............................................................................. 30
4.2. INSTALLATION AND UPGRADE PROCEDURES ......................................................... 30
4.2.1. Installation ................................................................................................ 30
4.2.2. Removing Atoll ......................................................................................... 33
4.3. INSTALLING MOTOROLA TEMPLATE INFORMATION ................................................ 33
5. CREATING PROJECTS/DOCUMENTS IN ATOLL............................................ 34

5.1. WORKING WITH ATOLL PROJECTS ...................................................................... 34
5.1.1. Starting a New Atoll Project...................................................................... 34
5.1.2. Saving, Opening, and Sharing an Atoll Project......................................... 40
5.1.3. Creating a Project Archive........................................................................ 40
5.2. WORKING WITH LTE BASE STATIONS ................................................................. 43
5.2.1. Placing a Base Station Using a Station Template via the Map................. 43
5.2.2. Placing Multiple Base Stations Using a Station Template via the Map..... 44
5.2.3. Hexagonal Design .................................................................................... 45
5.2.4. Importing a Group of Base Stations.......................................................... 46
5.2.5. Moving Sites............................................................................................. 47
5.2.6. Deleting Sites ........................................................................................... 48
5.2.7. Display Hints ............................................................................................ 49

5.2.8. Managing Station Templates.................................................................... 49
6. IMPORTING GEOGRAPHIC DATA AND ANTENNA PATTERNS .................... 53

6.1. TERRAIN DATA.................................................................................................. 54
6.2. LAND USE / LAND COVER DATA ......................................................................... 57
6.2.1. Clutter Classes ......................................................................................... 57
6.2.2. Clutter Heights.......................................................................................... 60
6.3. DISPLAYING VECTOR AND RASTER DATA ............................................................ 64
6.3.1. Road Data ................................................................................................ 64
6.3.2. Building data............................................................................................. 66
6.4. GEOGRAPHIC DATA FILES, DIRECTORIES, AND NAMING CONVENTIONS.................. 70
6.4.1. Using “Index”, “MapProjectionFile”, and “Menu” Files .............................. 71
6.4.2. Creating Index Files from Header Files .................................................... 72
6.5. OBTAINING GEOGRAPHIC DATA .......................................................................... 75
6.6. ANTENNA PATTERN DATA .................................................................................. 76
6.6.1. BTS Antennas .......................................................................................... 78
6.6.2. Subscriber Antennas ................................................................................ 78
6.6.3. New Antennas .......................................................................................... 79
7. SETTING ATOLL SITE/NETWORK/SUBSCRIBER/CLUTTER CLASS INPUTS82

7.1. SITE/SECTOR LEVEL INPUTS .............................................................................. 82
7.1.1. Sites ......................................................................................................... 82
7.1.2. Transmitters ............................................................................................. 85
7.2. NETWORK LEVEL PARAMETERS........................................................................ 108
7.2.1. Global Transmitter Parameters .............................................................. 108
7.2.2. Network Settings .................................................................................... 110
7.2.3. Equipment Settings ................................................................................ 124
7.2.4. Cell Settings ........................................................................................... 143
7.3. SUBSCRIBER (TERMINAL) PARAMETERS ............................................................ 147
7.3.1. CPE Antenna Variations......................................................................... 150
7.4. CLUTTER CLASS PARAMETERS ........................................................................ 155
8. SETTING PROPAGATION INPUTS ................................................................ 160

8.1. PROPAGATION MODELS ................................................................................... 160
8.1.1. Available Propagation Models ................................................................ 160

8.1.2. SPM Parameter Settings ........................................................................ 162

8.1.3. Clutter Heights, Losses and Clearance .................................................. 163
8.1.4. Base Station Antennas Below Clutter..................................................... 165
8.2. PROPAGATION MODEL TUNING......................................................................... 168
8.2.1. Collecting Drive Test Data...................................................................... 168
8.2.2. Post processing RSS.............................................................................. 175
8.2.3. Filtering the Drive-test Data.................................................................... 176
8.2.4. Running the Calibration .......................................................................... 180
8.2.5. Validating the Optimized Model.............................................................. 185
8.3. PROPAGATION ZONES ..................................................................................... 188
8.3.1. Creating and Editing Zones .................................................................... 189
8.3.2. Filtering Zone ......................................................................................... 191
8.3.3. Computation Zone .................................................................................. 191
8.3.4. Focus & Hot Spot Zones ........................................................................ 193
8.3.5. Printing Zone .......................................................................................... 195
8.3.6. Coverage Export Zone ........................................................................... 195
9. GENERATING COVERAGE STUDIES............................................................ 197

9.1. SUBSCRIBER ANTENNA HEIGHT SELECTION ...................................................... 197
9.2. HOW TO GENERATE STUDIES IN GENERAL ........................................................ 199
9.2.1. Creating a New Prediction...................................................................... 199
9.2.2. Generating Predictions with Lognormal Fade Margin............................. 203
9.3. PROPAGATION PREDICTION IMAGES ................................................................. 208
9.3.1. Coverage and RSSI Images................................................................... 208
9.3.2. Additional Design Images....................................................................... 214
9.4. INTERPRETING IMAGES .................................................................................... 224
9.4.1. Tips and Hints for Evaluating Images ..................................................... 224
9.4.2. Evaluating Coverage and Interference ................................................... 226
9.4.3. Use of Profile Analysis Feature in Evaluation......................................... 233
9.4.4. Coverage Range Limitations .................................................................. 241
9.5. GENERATING PROPAGATION PREDICTION STATISTICS ........................................ 242
9.5.1. Reports................................................................................................... 242
9.5.2. Histograms ............................................................................................. 244
9.6. GENERATING PATH LOSS FILES ....................................................................... 244

10. CAPACITY ANALYSIS..................................................................................... 246

10.1. DEFINING SERVICES ........................................................................................ 247
10.2. DEFINING MOBILITY TYPES .............................................................................. 253
10.3. DEFINING TERMINALS ...................................................................................... 254
10.4. DEFINING USER PROFILES ............................................................................... 254
10.5. DEFINING ENVIRONMENTS ............................................................................... 257
10.6. TRAFFIC MAPS AND SUBSCRIBER LISTS ............................................................ 261
10.6.1. User Profile and Environment Traffic Maps ............................................ 262
10.6.2. Sector Traffic Maps ................................................................................ 264
10.6.3. User Density Maps ................................................................................. 266
10.6.4. Subscriber Lists ...................................................................................... 267
10.7. SIMULATION PROCESS .................................................................................... 268
10.7.1. How to Run Simulations ......................................................................... 272
10.7.2. Simulation Output Statistics.................................................................... 273
10.7.3. Displaying Traffic Distributions ............................................................... 274
10.7.4. Coverage Predictions based on Simulation Results ............................... 274
10.8. PROCEDURE FOR CAPACITY ANALYSIS ............................................................. 275
10.8.1. Post-processing Simulation Statistics..................................................... 277
10.8.2. Assumptions for Quick Assessment of Capacity .................................... 282
10.8.3. Applying Coverage Constraint to Density Map ....................................... 282
11. MIMO AND TXAA MODELING ........................................................................ 285

11.1. MIMO MODELING IN ATOLL ............................................................................. 285
11.2. OVERVIEW OF MIMO SETTINGS ....................................................................... 285
11.3. MIMO SETTINGS IN ATOLL .............................................................................. 286
11.4. TXAA MODELING IN ATOLL .............................................................................. 287
12. INCORPORATING ADDITIONAL HARQ GAIN IN ATOLL............................... 288

12.1. DETERMINING IF ADDITIONAL HARQ GAIN IS REQUIRED .................................... 288
12.2. ADDITIONAL HARQ GAIN MODELING APPROACH IN ATOLL ................................. 289
12.3. ACCOUNTING FOR HARQ GAIN IN ATOLL .......................................................... 289
12.3.1. Adjusting the Bearer Threshold Values for Traffic Channel Studies....... 289
12.3.2. Adjusting Image Thresholds to Include HARQ for Traffic Channel Studies
291
12.3.3. Throughput Reduction Associated with Additional HARQ Gain.............. 291

13. REFERENCES................................................................................................. 293
14. GLOSSARY ..................................................................................................... 294

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

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 26: Clutter Classes............................................................................................ 58
Figure 27: Clutter Classes Image................................................................................. 59
Figure 28: Clutter Classes properties ........................................................................... 60
Figure 29: Clutter height definition ................................................................................ 61
Figure 31: Clutter Heights ............................................................................................ 62

Figure 32: Clutter Heights Image ................................................................................. 63
Figure 33: Clutter Heights properties............................................................................ 64
Figure 34: Vector Import............................................................................................... 65
Figure 35: Road data.................................................................................................... 65
Figure 36: Road data Image......................................................................................... 66
Figure 37: Vector Import............................................................................................... 67
Figure 38: Building data ............................................................................................... 68
Figure 39: Building data Image .................................................................................... 69
Figure 40: Building data properties .............................................................................. 70
Figure 41: “index” file.................................................................................................... 71
Figure 42: “MapProjectionFile” file ............................................................................... 72
Figure 43: “menu” File Example ................................................................................... 72
Figure 44: Format for “index” File ................................................................................. 73
Figure 45: Map File Reference Grid ............................................................................. 73
Figure 46: Example Header File Information................................................................ 74
Figure 47: Antennas label ............................................................................................ 76
Figure 48: Antennas properties .................................................................................... 77
Figure 49: Example Antenna Properties Window ......................................................... 79
Figure 50: Site Properties Window - General Tab ........................................................ 83
Figure 51: Site Properties Window - Display Tab......................................................... 84
Figure 52: Accessing Transmitter Sector Properties ..................................................... 85
Figure 53: Transmitter Properties - General Tab........................................................... 86
Figure 54: Transmitter Properties - Transmitter Tab .................................................... 87
Figure 55: Example Antenna Parameters .................................................................... 89
Figure 56: Transmitter Properties - Cells Tab .............................................................. 92
Figure 57: Transmitter Properties - Propagation Tab ................................................. 102
Figure 58: Transmitter Properties - Display Tab.......................................................... 104
Figure 59: Selecting Transmitters Properties ............................................................. 105
Figure 60: Transmitter Properties Automatic Display .................................................. 105
Figure 61: Transmitters Display Parameters ............................................................... 106
Figure 62: Changing the Transmitter Display Symbol ................................................. 106
Figure 63: Accessing the Transmitters Table .............................................................. 107

Figure 64: Example Transmitters Table ..................................................................... 107

Figure 65: Accessing Global Transmitter Parameters ................................................. 108
Figure 66: Global Transmitter Parameters Interface ................................................... 109
Figure 67: Accessing Frequency Band Information..................................................... 111
Figure 68: Frequency Bands Table ............................................................................. 112
Figure 69: Accessing the LTE Bearer Parameters ...................................................... 114
Figure 70: DL Bearers Dialog Window ....................................................................... 115
Figure 71: UL Bearers Dialog Window ........................................................................ 116
Figure 72: Accessing Quality Indicators ..................................................................... 117
Figure 73: Quality Indicators ...................................................................................... 118
Figure 74: Schedulers Window .................................................................................. 119
Figure 75: Example of PF Scheduling (~Full Buffer) ................................................... 120
Figure 76: Example of PD Scheduling......................................................................... 120
Figure 77: Bearer Selection Criterion .......................................................................... 122
Figure 78: Accessing Station Templates Table .......................................................... 123
Figure 79: Station Template Table ............................................................................. 123
Figure 80: Accessing TMA Equipment Parameters.................................................... 124
Figure 81: TMA Equipment Window............................................................................ 125
Figure 82: Accessing Feeder Equipment Parameters ................................................ 126
Figure 83: Feeder Equipment Window ........................................................................ 127
Figure 84: Accessing BTS Equipment Parameters .................................................... 128
Figure 85: BTS Equipment Window ............................................................................ 129
Figure 86: Accessing LTE Equipment Parameters..................................................... 130
Figure 87: LTE Equipment Window............................................................................. 130
Figure 88: LTE UE Reception Equipment Window – Bearer Selection Thresholds..... 131
Figure 89: Quality Graph ............................................................................................. 132
Figure 90: Effective MPR ............................................................................................ 133
Figure 91: Example Downlink and Uplink Paths between eNB and CPE ................... 134
Figure 92: Example Downlink Path Represented in MIMO Tab .................................. 135
Figure 93: Example Uplink Path Represented in MIMO Tab...................................... 140
Figure 94: LTE Reception Equipment – MIMO Tab ................................................... 141
Figure 95: Example MIMO Gain Graph ...................................................................... 142
Figure 96: Accessing the Cells Table .......................................................................... 144

Figure 97: Example Cells Table ................................................................................. 145

Figure 98: Accessing the Neighbours Table................................................................ 146
Figure 99: Example Neighbours Table ....................................................................... 146
Figure 100: Accessing Terminal Parameters ............................................................. 147
Figure 101: Example Terminal Properties Window ..................................................... 148
Figure 102: CPE Device Properties............................................................................ 151
Figure 103: Reducing Antenna Gain by AGCF ........................................................... 152
Figure 104: Alternate Way of Incorporating AGCF ...................................................... 153
Figure 105: Accessing the Clutter Class Parameters ................................................. 156
Figure 106: Sample Clutter Classes Properties Window............................................ 156
Figure 107: Atoll Propagation Models ........................................................................ 161
Figure 108: Motorola Recommended 2.5 GHz Parameter Settings ............................ 163
Figure 109: Recommended Clutter Parameters.......................................................... 164
Figure 110: Isolated High Clutter................................................................................. 165
Figure 111: Signal Strength with Base Station Antenna Height Below Clutter ............ 166
Figure 112: Measured versus Predicted Pathloss in Dense Urban Area Using Hata .. 167
Figure 113: Settings for Uniform Cost-231 Hata ......................................................... 168
Figure 114: Pathloss versus Foliage Density .............................................................. 171
Figure 115: Drive Data with Least Squares Trendline ................................................. 172
Figure 116: Weighted Drive Data with Least Squares Trendline................................. 173
Figure 117: Example of Uniform Drive Routes ............................................................ 174
Figure 118: Antenna Viewpoint Photos ....................................................................... 175
Figure 119: Example of Unfiltered Drive Test Data ..................................................... 177
Figure 120: Example of Filtered Drive-test Data ......................................................... 177
Figure 121: Example of Measurements at the Receiver Noise Floor .......................... 178
Figure 122: Issue with Minimum Signal Strength Filter ............................................... 179
Figure 123: Maximum Distance Filter to Avoid Clipping .............................................. 179
Figure 124: Default Model Calibration Interface .......................................................... 181
Figure 125: Final Model Tuning Configuration ............................................................ 185
Figure 126: Predicted and Measured Signal Strength................................................ 186
Figure 127: Example of Model with Low Slope ........................................................... 187
Figure 128: Mean prediction error per test site............................................................ 188
Figure 129: Propagation Zones Folder........................................................................ 189

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

Figure 163: Import best bearer plot configuration........................................................ 223

Figure 164: Sample Overlapping Zones Image........................................................... 224
Figure 165: Tip Text Display ...................................................................................... 225
Figure 166: Tip Text Display Properties ..................................................................... 226
Figure 167: Path Profile.............................................................................................. 234
Figure 168: Path Profile Analysis Properties .............................................................. 235
Figure 169: Path Profile Link Budget.......................................................................... 236
Figure 170: Path Profile Reception ............................................................................ 237
Figure 171: Path Signal Analysis ............................................................................... 238
Figure 172: Preamble Reception Strength Bars......................................................... 239
Figure 173: SCH & PBCH Reception Window ........................................................... 239
Figure 174: Downlink Window.................................................................................... 240
Figure 175: Uplink Window ........................................................................................ 240
Figure 176: Path Profile Results................................................................................. 241
Table 177: Maximum Cell Range Due to PRACH Timing .......................................... 241
Figure 178: Predictions – Generate Report................................................................. 242
Figure 179: Generate Report Data .............................................................................. 243
Figure 180: Coverage by Best Signal Level Report ................................................... 243
Figure 181: Histogram of Best Signal Level ............................................................... 244
Figure 182: Accessing Services Parameters............................................................... 248
Figure 183: Example Services GUI Window (FTP) ..................................................... 250
Figure 184: Accessing Mobility Types ........................................................................ 253
Figure 185: Example Mobility Types GUI Windows (PB3) .......................................... 254
Figure 186: Accessing User Profiles Parameters........................................................ 255
Figure 187: Example User Profiles Window (Business User)...................................... 255
Figure 188: Accessing Environments Parameters ...................................................... 258
Figure 189: Example Environments Window (Urban) – General Tab.......................... 258
Figure 190: Example Environments Window (Urban) – Clutter Weighting Tab ........... 260
Figure 191: New Traffic Map ....................................................................................... 261
Figure 192: User Profile Traffic Map Properties .......................................................... 263
Figure 193: Environment Properties (example)........................................................... 264
Figure 194: Sector Traffic Map Properties................................................................... 265
Figure 195: Sector Traffic Map Table .......................................................................... 266

Figure 196: Density Map Properties ............................................................................ 267

Figure 197: Simulation Process Flowchart .................................................................. 269
Figure 198: Simulation (Drop) Statistics ...................................................................... 273
Figure 199: Summary Statistics (post-processed)....................................................... 280
Figure 200: Key Mobile Chart Examples ..................................................................... 281
Figure 201: Bearer Threshold Information without Additional HARQ Gain................. 290
Figure 202: Example PHY Data Rates not Accounting for HARQ Gain ..................... 292
Figure 203: Example Post-HARQ PHY Data Rate ...................................................... 292

Revision History
Atoll Revision
Date Author Description
Release
2.8.0 1.0.0 Aug 31-2009 SSE Released for general use
2.8.0 1.0.2 Sept 22-2009 SSE Updated UL bearer selection thresholds

(Table 8)
2.8.0 1.0.3 Sep 29-2009 SSE Updated connector losses for Frame Based
and RRH base stations
2.8.01 1.1 Apr 19-2010 P&D Incorporated capacity analysis using Monte
Carlo simulations (new Section 10) and
summary chapter on MIMO/TxAA (new
Section 11). Updates to Sections 7.2.2.4,
7.2.3.4.1, and Section 12.
2.8.02 1.2 Nov 2-2010 P&D Incorporated DL MIMO modeling (see

Section 7.2.3.4.2).
2.8.03 1.3 Dec 17-2010 P&D Modified reliable coverage assessment to

focus on “shadowing” and coverage by
throughput images.
Document location: http://compass.mot.com/go/318588510
1
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 ).

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.
1.2. Procedure Flow Chart

There are two fundamental LTE RF system design processes defined in this document.
The tools and procedures to follow will depend on the output and detail required.
Budgetary designs are characterized by short turn around time and limited input data.
For budgetary designs, ML-CAT should be chosen (see Section 1.2.1 below) for
estimating a site radius and to perform a capacity study.
Detailed RF system designs will rely upon the Atoll RF design tool (see Section 1.2.3)
and are the main focus for this document. These designs may be produced for contract
purposes and final system deployment designs.
The two process flow diagrams are described in the following sections.

1.2.1. Budgetary RF System Design Process Flow

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 ML-
CAT 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. Neighborhoods are subdivided portions of a system service area. These
neighborhoods exhibit homogeneous topography and land use
characteristics. They have no relationship to political boundaries. The RF
propagation characteristics should be consistent over the surface area of
each neighborhood. This allows a uniform eNodeB placement to be used
throughout the neighborhood. Multiple neighborhood definitions will be
used for each System. Multiple areas throughout the city may be assigned
the same neighborhood definition. Neighborhoods should be defined with

sufficient surface area to accommodate four or more sites (10 Km2

minimum surface area is a typical minimum neighborhood size).
A finite number of neighborhood definitions (5 to 10 definitions) should

serve most system designs. Characteristics to take into account when
defining neighborhoods are:
1. The type of structures (residential, business, industrial, high-rise

buildings)
2. Density and placement of buildings
3. Density and placement of trees and foliage
4. Width of streets.
5. The presence of parking lots
6. Proportions of block length to width.
7. Presence of open ally ways.
Neighborhoods will only be defined where the user population is present.

Lakes, rivers, ravines, open barren land, dense forests, unpopulated
industrial and agricultural areas (e.g. rail road switching yard) will likely be
excluded from assignment to a neighborhood. All areas specified by the
customer for coverage will then be assigned one of the neighborhood
definitions.
Note. 2. A separate tool (such as Google Earth) is needed to determine the surface
area of each neighborhood.

Figure 1: Budgetary Process Flow Chart
ML-CAT
1.2.2. RF System Capacity Analysis

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.

2. Repeat step 1 for each neighborhood within the system.

3. Combine the results for each neighborhood to determine the system throughput
and capacity.
4. Review results. If results do not meet customer requirements, adjust the number
of cells and average cell coverage area and repeat steps 1 through 3.
5. Produce report.
For details on the use of ML-CAT, see ML-CAT Guide document.

(See Figure 2: ML-CAT Capacity Process Flow Chart)
Figure 2: ML-CAT Capacity Process Flow Chart
Start
Determine Site capacity using ML-CAT
Calculate total
Subscribers supported
Review Results
Produce
Report
End

1.2.3. Detailed RF System Design Process Flow

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 eNB’s.
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.

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))
Figure 3: Detailed System Design Flow Chart (A)

Figure 4: Detailed System Design Flow Chart (B)
Enter system/site parameters
Run and analyze coverage study
Coverage N Make any required

Requirements design adjustments
Met?
Y
END

2. LTE RF Link Budget

An RF link budget is the sum of all RF system gains and losses in the RF path
(downlink or uplink). These values are used to determine the maximum allowable
pathloss between the base site and the subscriber. Typical items within an LTE RF link
budget are:
Uplink and Downlink

• Antenna gain
• Transmit power
• Diversity gain
• Noise Figure
• Receiver Sensitivity
• EIRP
Other
• Lognormal Fading
• Fast Fading
• Interference margin
• Number of resource elements
• Power per resource element
• Building loss
• Vehicle loss
• Body loss
• Target SNR
Refer to the LTE RF Planning Guide (http://compass.mot.com/go/310442223) for further

information on the LTE RF link budget and these parameters.
RF prediction tools rely upon values within the link budget for pathloss modeling. The
two tools discussed within this document for LTE RF planning (ML-CAT and Atoll) use
these link budget values in conjunction with a propagation model to estimate coverage.
The specific link budget values used for any given study need to be incorporated within
ML-CAT or in the Atoll application.

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).

Figure 5: ML-CAT GUI
Within this window are several smaller user input windows:

1. RF Design Inputs
2. Base Station Inputs
3. Subscriber Inputs
4. Effective Link Budget
5. Edge Throughput Rate Inputs
6. Mobile or Nomadic Devices
7. Customer Premise Equipment

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.

3. LTE System Capacity Calculation

ML-CAT combines capacity analysis capability with the link budget analysis in one
spreadsheet tool (see Section 2.1). The capacity analysis assumes that the sector is
operating with a full buffer (maximum capacity). ML-CAT capacity analysis is based on
a set of previously run simulation results. The capacity related inputs essentially index
into the tables of simulation results.
3.1. Using ML-CAT for LTE Capacity Analysis
The high level design procedure for using ML-CAT to produce LTE capacity results is
described in Section 1.2.2.
• For further information, refer to the ML-CAT User Guide document
available at the http://compass.mot.com/go/310448858 link.
Additional information concerning the factors that influence LTE capacity can be found
in the LTE RF Planning Guide (http://compass.mot.com/go/310442223).

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.
4.1. Computer configuration

Atoll documentation provides the following requirements for workstations intended for
working with Atoll.
Table 1: Recommended Workstation Configuration

Hardware/Software Minimum Recommended
Processor Intel® Pentium® III Intel® Pentium® IV or Xeon®
RAM 512 MB 2 GB
More than 10 GB
Hard disk space 10 GB free hard disk space (according to the geographic
database)
Graphics 1280 x 1024 with 64000 colors Higher
Operating System Microsoft® Windows® 2000 SP4 or XP SP1 (SP2 supported)
Additional Software Microsoft® Office 2000 or XP
Ports 1 Parallel port (25 pins) or 1 USB port required to plug-in the license key
4.2. Installation and upgrade procedures
4.2.1. Installation
To install Atoll:
• Quit all programs
• Then either:
• Go to http://compass.mot.com/go/Atoll and download the
appropriate release from the Atoll Releases folder
Or:

• Insert the CD-ROM in the appropriate drive and follow the

instructions on the screen
Or:
• Double-click the Setup application.
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.
• Select the type of installation desired:

• Full: Atoll application, Atoll calculation server application, Dongle

driver for fixed license, Development kit
• Compact: Atoll application only
• Custom: select the desired options to install
• Select the destination of the application in the Start menu folder
• Click the Install button to run the installation process.
Notes:
- Help files are automatically installed during Setup
- The User Manual is provided with the software
In some instances, the following error window may be seen during the installation
process:

If multiple licenses are not sharing processing power, this is not an issue. Click OK and
continue.
4.2.2. Removing Atoll

To remove the Atoll application:
• Quit all programs
• Click the Windows Start button, point to Settings, and then click Control
Panel
• Double click the Add/Remove Programs icon
• In the Install/Uninstall tab, select Atoll in the list, and then click
Add/Remove
• Follow the instructions on the screen
4.3. Installing Motorola Template Information

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, etc.) based on development input. The use of this
custom project template will facilitate Motorola-specific system design work. Install the
project template as follows:
1. Retrieve the template file (“LTE_MOTOv282.mdb”) from the compass location
http://compass.mot-solutions.com/go/364172907.
2. Place the mdb file into the Atoll project templates folder:
C:\Program Files\Forsk\Atoll\templates
Note: assumes that Atoll was installed under “C:\Program Files”.
The template can be further customized by opening an existing template, making the
changes necessary to meet the needs and then saving it as a new template. To save
the template, use File>Database>Export and place the file in the Atoll project templates
folder.

5. Creating Projects/Documents in Atoll

In this section, information is provided on how to start an Atoll project. Information on
how to populate and place sites within the project is also supplied.
5.1. Working with Atoll Projects

In this section, the process by which Atoll projects, called “documents”, are created will
be described. Also described is the process by which documents are saved, opened,
and shared.
5.1.1. Starting a New Atoll Project

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 project’s 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.

5.1.1.2. Create a new Atoll “document” from a template

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.

Figure 7: Coordinates Tab from Options Dialog
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.

Figure 8: Coordinate Systems Dialog (Find In list showing)
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.

Figure 9: Coordinate Systems Dialog

(both Cartesian/geographic coordinates showing)
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.

Figure 10: Units Tab from Options Dialog
5.1.1.4. Import required geographic data.

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.

Figure 11: Auto Backup Configuration
5.1.2. Saving, Opening, and Sharing an Atoll Project

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. Creating a Project Archive

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

The zip file will contain

Zip File:
• *.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
• Create a computation zone around the area to be archived or shared
• Right click within the map display window and select “Save As”
Figure 12: Saving GIS Data within a Computation Zone

• 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
• 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.

5.2. Working with LTE Base Stations

In Atoll, a site is defined as a geographical point where one or more transmitters are
located. Once a site has been created, transmitters can be added to it. In Atoll, a
transmitter is defined as the antenna and any other additional equipment, such as the
TMA, feeder cables, etc. In an LTE project, cells must also be added to each
transmitter. A cell refers to the characteristics of an RF channel on a transmitter. In
Atoll, a base station refers to a site with its associated transmitters and cells.
Atoll lets the user create one site, transmitter, or cell at a time, or create several at once
by creating a station template. Using a station template, the user can create one or
more base stations at the same time. The Motorola project template used to create the
project contains within it numerous base station templates which reflect Motorola LTE
products. The balance of this explanation assumes the use of these station templates
as the most efficient means of establishing a baseline from which any required
customization can be performed.
This section will describe how to integrate sites into the project including the placement
of single or multiple base stations using both map and database methods. Also
described is how to move and delete base stations.
NOTE: Geographic data needs to be brought into a project before placing sites.
Please see Section 6 regarding importing geographic data.
5.2.1. Placing a Base Station Using a Station Template via the Map
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 ( ) in the Radio toolbar.

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 pointer’s 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.

Figure 14: Base Station Templates
With the pointer resting over the base station, Atoll displays a tool tip with the base
station’s 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.

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

Figure 16: Hexagon Radius for Site and Sector
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
group’s 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. Importing a Group of Base Stations

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.

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.
• Importing data: If base station data is available in text or comma-separated value
(CSV) format, it can be imported into the tables of the current document. If the
data is in another Atoll document, it can first be exported in text or CSV format
and then imported into the tables of the current Atoll document. When importing,
Atoll allows users to map input columns to destination columns.
For information on importing and exporting table data, see "Exporting Tables to
Text Files" and "Importing Tables from Text Files" in the Atoll User Manual.
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 pointer’s current location are visible in the Status bar.

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. Select Move to a Higher Location.
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

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 control-
click 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.
• Transmitter symbol: One of several symbols can be selected to represent
transmitters.
For information on defining labels, tooltips, colors, and symbols, refer to “Display
Properties of Objects” in the Atoll User Manual.
5.2.8. Managing Station Templates

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 project’s 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:

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. Create a new station template or modify an existing one:
- To create a new station template: Under Station Templates, select the
station template that most closely resembles the station template to be
created and click Add. The Properties dialog appears.
- To modify an existing station template: Under Station Templates, select
the station template whose properties are to be modified and click
Properties. The Properties dialog appears.
4. Modify fields, as appropriate, within the General, Transmitter, LTE, and
Other tabs of the Properties dialog. The Other tab will only appear if there
are user-defined fields. Refer to Figure 18 for an example of the Station
Template Properties dialog box.
The General tab of the Properties dialog contains three fields which are
unique to this interface; namely, Name, Sectors, and Hexagon Radius.
The Name field refers to the name of the station template. The Sectors
field refers to the number of Sectors associated with this base station
template, each with a transmitter. The Hexagon Radius is the theoretical
radius of the hexagonal area covered by this base sector. For
descriptions of all other fields found within the Properties dialog, refer to
Section 7.1.2. More specifically, for transmitter, cell, and propagation
parameters, refer to Sections 7.1.2.1.2, 7.1.2.1.3, and 7.1.2.1.4,
respectively.
5. When finished with setting the parameters for the station template, click
OK to close the dialog and save the changes.

Figure 18: Properties Dialog for Station Templates
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.

Figure 19: Accessing the Station Templates Table

6. Importing Geographic Data and Antenna Patterns

Atoll requires a foundation of geographic data for the area over which propagation
studies will be performed. This section describes four types of geographic data that are
used within Atoll:
• Terrain Data
• Land Use / Land Cover 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)
• Binary Interlaced Files (*.BIL)
• Erdas Imagine (*.img)
• Vertical Mapper (*.grd for terrain files and *.grc for clutter files)

6.1. Terrain Data

Terrain data defines the elevation of the land used in the Atoll document. The following
steps describe how to import terrain data into Atoll:
From the main tool bar, select File > Import. This opens up the Open window.
Figure 20: Open - Import
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.

Figure 21: Data Types
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.

Figure 23: Digital Terrain Image
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 file’s precedence status for the document.
Right clicking on the Digital Terrain Model label and selecting “properties” opens the
Digital Terrain Model Properties window.

Figure 24: Digital Terrain Model properties
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.
6.2. Land Use / Land Cover Data

Land use / land cover (Clutter) data defines the usage of the land in the Atoll document.
Atoll displays two images associated with cutter data (Clutter Classes and Clutter
Heights). These two images are created from the same clutter data files. The following
steps describe how to import and display the clutter data into Atoll:
6.2.1. 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.
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

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.
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.

Figure 27: Clutter Classes Image
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 file’s precedence
status for the document.
Right clicking on the Clutter Classes label and selecting “properties” opens the Clutter
Classes Properties window.

Figure 28: Clutter Classes properties
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.)

Figure 29: Clutter height definition
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.
the NetPlan LULC/Clutter data is stored for the current document.
Click the “Open” button to open the Data Types window.

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.
Figure 31: Clutter Heights
The Clutter Heights image will be displayed in the map window once the clutter data has
been successfully imported.

Figure 32: Clutter Heights Image
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 file’s precedence
status for the document.
Right clicking on the Clutter Heights label and selecting “properties” opens the Clutter
Heights Properties window

Figure 33: Clutter Heights properties
The shading colors and transparencies of the clutter height image are adjusted using
this window.
6.3. Displaying Vector and Raster Data

Vector and Raster data incorporate useful information such as Roads and Buildings.
The following subsections describe how to import and display these data types.
6.3.1. 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.

Figure 34: Vector Import
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.
Figure 35: Road data
The Road data image will be displayed in the map window once the road data has been
successfully imported.

Figure 36: Road data Image
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.

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.

Figure 38: Building data
The Building data image will be displayed in the map window once the building data has
been successfully imported.

Figure 39: Building data Image
Right clicking on the building data label and selecting “properties” opens the Building
data Properties window.

Figure 40: Building data properties
The shading colors and transparencies of the building data image are adjusted using
this window.
6.4. Geographic Data Files, Directories, and Naming Conventions

All geographic data is addressed by absolute directory path within Atoll. This allows the
data to be placed anywhere within the computer directory structure and facilitates
sharing common geographic data between multiple users. To share geographic data, all
users must either be on the same workstation or have access to the same folders
across a network.
The following subsection provides naming restrictions and directory placement
restrictions regarding terrain and clutter data. There are no naming restrictions or
directory placement restrictions for Building data or Road data.
Various information files can be provided along with NetPlan formatted terrain and
clutter files (binary data). For example, an “index” and “MapProjectionFile” can be
provided with the terrain and clutter data, as well as a “Menu” file provided with the
clutter data. Section 6.4.1 provides details on the type of information that is contained
within these files. It also provides details on the naming conventions and directory

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. Using “Index”, “MapProjectionFile”, and “Menu” Files

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 473149 483999 2151801 2166006 5
The “MapProjectionFile” file is an ASCII file that contains geographic projection

parameters for the NetPlan binary data.

Figure 42: “MapProjectionFile” file
ctN_Radius 6378137.00
ctN_Eccentricity 0.081819191
ctN_ParaCntr 0.00
ctN_MeridCntr -99.00
ctN_ScaleCntr 0.9996
ctN_NorthingCntr 0.00
ctN_EastingCntr 500000.00
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. Creating Index Files from Header Files

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.

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.
Figure 44: Format for “index” File
BinaryFileName.bil Xmin Xmax Ymin Ymax PixelSize
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.
Figure 45: Map File Reference Grid
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.

Figure 46: Example Header File Information
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

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.
6.5. Obtaining Geographic Data

Atoll supports several geographic data formats including NetPlan and Planet. A full
listing of the supported data formats is given in the Atoll Users Manual under the
Supported Geographic Data Formats section. Atoll users may acquire geographic data
from the Motorola Graphical Data Services organization (GDS), contact
maps@motorola.com). GDS can convert many forms of existing geographic data into
data formats supported by Atoll.
The United States Geological Service offers 30 meter resolution Ultra High-Res Terrain,
NLCD Land Cover, and TIGER 2000/2006 shapefile Roads data for the United States
free of charge. The GDS organization can quickly convert this data into Atoll compatible
formats for a minimal charge.
Higher resolution geographic data produces propagation predictions of greater accuracy
(assuming that the data itself is accurate) and is recommended for all but urgent
budgetary RF studies. To ensure further propagation prediction accuracy, the
propagation model should be tuned for the given area.
Higher resolution data is obtained by GDS from other sources requiring more time to
process which incurs higher expenses. The time required by GDS to produce high
resolution geographic data should be factored into the total time required for the RF
design project.
Building files can be purchased from GDS (http://gds.mot.com, contact
maps@motorola.com) or from CyberCity LLC (contact name Jacqui Swartz
310.760.2560 jswartz@cybercityllc.com). The vector building data should be in

“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).
6.6. Antenna Pattern Data

The base station and the subscriber terminals require the presence of antenna
performance data for RF predictions to run. This data is in the form of frequency of
operation, peak antenna gain, horizontal antenna response pattern, and vertical
antenna response pattern. This data is contained in a single text file called the antenna
pattern file.
Generic 70 degree Antenna patterns are included in the LTE template that was selected
when creating the LTE document (see Section 5). However, these generic patterns
should be replaced with the actual antenna patterns that are planned for use in the
system being designed.
To view the available antennas embedded within the Motorola LTE template, click on
the Data tab at the top of the Explorer window and expand the “Antennas” label.
Figure 47: Antennas label

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

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.
• CPE Antenna – 7 dBi
• 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 non-
line-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.

Figure 49: Example Antenna Properties Window
Enter the appropriate antenna gain into the “Gain” field. If the CPE is located in a non-
line-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:

• Name
• Manufacturer
• Gain
• Pattern Electrical Tilt
• Comments : Any other information
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
• FMin: Minimum frequency for the pattern
• FMax: Maximum frequency for the pattern
• Frequency: the design frequency of the antenna
• V WIDTH: the vertical beamwidth of the antenna
• H_WIDTH: the horizontal beamwidth of the antenna
• FRONT_TO_BACK: the front to back ratio of the antenna
• TILT
Atoll checks whether the vertical and horizontal patterns are correctly aligned at the
extremities. The antenna patterns are correctly aligned when:
• The horizontal pattern attenuation at 0° is the same as the vertical pattern
attenuation at the pattern electrical tilt angle, and
• The horizontal pattern attenuation at 180° is the same as the vertical
pattern attenuation at the 180° less the pattern electrical tilt angle.
6.6.3.2. Importing Antenna Data

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.

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:
• The horizontal pattern attenuation at 0° is the same as the vertical pattern
attenuation at the pattern electrical tilt angle, and
• The horizontal pattern attenuation at 180° is the same as the vertical
pattern attenuation at the 180° less the pattern electrical tilt angle.

7. Setting Atoll Site/Network/Subscriber/Clutter Class Inputs

This section discusses the parameters that need to be set to define a system within
Atoll. This includes parameters that define the site/sector configurations, the subscriber
configurations, the associated equipment, and the system or network configurations.
This section provides descriptions of the parameters, as well as recommended settings,
where possible.
It is recommended that the Motorola specific LTE template be used within Atoll since
many of these parameters are set within the template based on Motorola products. For
example, many site/sector configuration parameters can be set by choosing one of the
provided base station templates (e.g. “Frame Based eNB”, “Remote Radio Head”, etc.).
When using the Motorola template, it is important to review the parameters (e.g.
antenna heights, azimuths, etc.) and modify them as necessary for the specific market
that is being designed. For example, the default site antenna height used in the
template is 30 m. However, this value will not be appropriate in all situations.
The following sections include information regarding the parameter values that are set
within the templates and which parameters are likely to need modification.
7.1. Site/Sector Level Inputs

Within Atoll, a base station is defined through site, transmitter, and cell parameters. The
site parameters define the location of the site, while the transmitter and cell parameters
define the details of the site such as the antenna and equipment parameters as well as
the characteristics of an RF channel on a transmitter.
Most of the input windows can be accessed in two ways: either through selection from
the Explorer window under the Data tab, or by right-clicking on the object in the map
window.
7.1.1. Sites
The site information defines the geographic location of the site. The site parameters can
be found in the Site’s 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.

Figure 50: Site Properties Window - General Tab
1
3
2
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.

Figure 51: Site Properties Window - Display Tab
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.

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 right-
clicking on a Transmitter and selecting Properties, as shown in the next figure.
Figure 52: Accessing Transmitter Sector Properties
The Transmitter Properties window consists of 5 tabs: General, Transmitter, Cells,

Propagation, and Display. The parameters in each of these tabs will be described
below.
7.1.2.1.1. Transmitter Properties - General Tab

The General tab in the Transmitter Properties window provides information regarding
the name and location of a sector relative to the associated site.

Figure 53: Transmitter Properties - General Tab
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
transmitter’s 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.

7.1.2.1.2. Transmitter Properties - Transmitter Tab

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.
Figure 54: Transmitter Properties - Transmitter Tab
1 2
5
3
7
9
8
10
11
12
NOTES:

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. The Antennas Height/Ground entry defines the height of the antenna
above the ground. (If the transmitter is located on top of a building, this
height must include the height of the building.)

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.
Figure 55: Example Antenna Parameters
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.

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.

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. Transmitter Properties - Cells Tab

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.

Figure 56: Transmitter Properties - Cells Tab
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.)

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 sector’s 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 User’s
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
cell’s 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
User’s 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 User’s Manual.

Note. 9. Max Power (dBm) is the cell’s 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. Motorola’s 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 eNB Tx Power TX Max PDSCH
Product per antenna Combining Power Power
(dBm) Gain (dBm) (dBm)
Frame Based 46 3 49.26 49
2x2 RRH 43 3 46.26 46
4x4 RRH 40 6 46.26 46
4x8 RRH 40 6 46.26 46
Horizon II 43 3 46.26 46
SC7224 43 3 46.26 46
UBS 43 3 46.26 46
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. Motorola’s
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

used to calculate the transmission power corresponding to the physical

downlink shared channel (PDSCH) and the physical downlink control
channel (PDCCH). If using the Motorola template, this value will be set to
0 dB. Motorola’s 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. 12. The Reference Signal C/N Threshold (dB) defines the minimum reference
signal C/N required for a user to be connected to this sector. This
parameter acts as a boundary threshold for the downlink and uplink
coverage area. If the C/(I+N) level at a pixel is below this threshold, the
pixel will not be included in the C/(I+N) coverage area. If the Motorola
base station templates are used, this field is set to -20 dB. A setting of -20
dB ensures that the Reference Signal C/N Threshold will not override the
Prediction coverage threshold.
Note. 13. The LTE Equipment field specifies the reception equipment from an LTE
Equipment list. The reception equipment parameters are used in uplink
calculations. When using the Motorola base station templates, this field is
automatically set to “Motorola eNB Reception (UL)”.
Note. 14. The Scheduler field defines the scheduler that is used by the sector for
resource allocation during Monte Carlo simulations. The appropriate
scheduler is chosen from a Scheduler list. (For more information regarding
scheduler lists, please see the Atoll User’s Manual.)
If the Motorola base station templates are used, this field is set to
Proportional Fair by default.
Note. 15. The Max Number of Users field defines the maximum number of
simultaneous users supported by the sector.
The Motorola base station template sets this field to null which is the
recommended setting. This field is used in the simulation process and
setting this to null disables it from serving as an upper limit on users being
scheduled. Refer to Section 10.7 for more information.
Note. 16. The TDD Frame Configuration is the frame configuration used when the
selected frequency band for the cell is designated as a TDD band in the
Transmitters Æ Network Settings Æ Frequencies Æ Bands interface. The
choice of TDD Frame Configuration determines the number of DL and UL
subframes per frame, which impacts the DL and UL throughput values that
are displayed in the throughput plots as well as the throughput values
reported in Monte Carlo simulation results.
If the network’s switching point periodicity is set to "0-Half Frame" in the

TransmittersÆ Properties Æ Global Parameters interface, a frame
configuration of type D-UUU D-UUU, D-UUD D-UUD, or D-UDD D-UDD
can be selected in Atoll v2.8.0, where the pattern represents subframe
usage with “D” being a downlink subframe, “U” being an uplink subframe,

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 network’s 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.
Table 3: TDD configurations

TDD Configuration DL%/UL%
Split
D-UUU D-UUU 25/75

D-UUD D-UUD 50/50
D-UDD D-UDD 75/25
D-UUU D-UUD 37/63
(Atoll v2.8.1)
D-UUU DDDDD 67/33
D-UUD DDDDD 78/22
D-UDD DDDDD 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

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

Diversity Support (DL) Effect on Analysis
Transmit Diversity Diversity Gain (dB) value from the
Equipment MIMO interface is applied to
the C/(I+N) calculations
SU-MIMO MIMO Gain curve from the Equipment
MIMO interface is applied to Tput
calculations. Diversity Gain (dB) is not
applied to the CINR calculations.
AMS If the reference signal CINR is above the
AMS & MU-MIMO Threshold (dB) from the
Cells interface, then the MIMO Gain curve
from the Equipment MIMO interface is
applied to Tput calculations. If the
reference signal CINR is below the AMS &
MU-MIMO Threshold (dB), then the
Diversity Gain (dB) value from the
Equipment MIMO interface is applied to
the C/(I+N) calculations.
None No gain is applied to either the Tput or
CINR calculations.

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
User’s 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 we’ll 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.)

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 user-
specified 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 UE’s 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).

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 intra-
technology 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. Transmitter Properties - Propagation Tab

The Propagation Tab within the Transmitter Properties window defines the propagation
models that are associated with the given sector. Atoll uses the propagation model

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.)

Figure 57: Transmitter Properties - Propagation Tab
4
1
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

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.

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. Transmitter Properties - Display Tab

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.

Figure 59: Selecting Transmitters Properties
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.

Figure 61: Transmitters Display Parameters
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
5. Click OK within the Display parameters.

6. Click OK within the Transmitter parameters window.
7.1.2.2. Making Global Changes to Transmitter Data

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.

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
This opens up the Transmitters Table as seen in the following figure.
Figure 64: Example 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.

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.
7.2. Network Level Parameters

Various LTE parameters are set on a network level within Atoll. These parameters
define information such as the network frequencies, bearer information, quality
indicators, schedulers, MIMO configurations, cell information, and equipment settings.
The Motorola template contains default settings for these parameters.
7.2.1. Global Transmitter Parameters

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.
Figure 65: Accessing Global Transmitter Parameters
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.

Figure 66: Global Transmitter Parameters Interface
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 eNodeB’s. 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.

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 PUCCH RB’s
(MHz)
1.4 1
3 2
5 4
10 8
15 12
20 16
Note. 4. The Switching Point Periodicity (TDD only) can either be after each half-
frame 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.

7.2.2.1. Frequencies
The Frequency Band information is accessed by right-clicking on Transmitter folder in
the Data tab and selecting Network Settings Æ Frequencies Æ Bands, as seen in the
following figure.
If the Motorola template is used within Atoll, the values for the frequency band
parameters are set according the Motorola eNB product road map. However, as of the
time of writing this document the product plans for frequency band support have not
been solidified; therefore, please contact PdM to check on the availability of eNB
equipment in the desired frequency band for the system being designed.
Figure 67: Accessing Frequency Band Information
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.

Figure 68: Frequency Bands Table

1 2 3 4 5 6 7 8 9 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 AP’s supported bands and channel bandwidths may change
over time.

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.
7.2.2.2. LTE Bearers

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.
Figure 69: Accessing the LTE Bearer Parameters
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.

Figure 70: DL Bearers Dialog Window
1 2 3 4 5
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.

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

7.2.2.3. Quality Indicators

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.
Figure 72: Accessing Quality Indicators
This accesses the Quality Indicators table as shown in the following figure.

Figure 73: Quality Indicators
1 2 3
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.

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).

Figure 75: Example of PF Scheduling (~Full Buffer)
DL CTP vs %Res
9%
8%
7%
6%
5%
%Res
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%
12%
%Res
10%
8%
6%
4%
2%
0%
0 5,000 10,000 15,000 20,000 25,000 30,000 35,000
CTP (kbps)
Target Throughput for Voice Services &

Target Throughput for Data Services
In defining the services parameters Max Throughput Demand (MaxTD), Min Throughput
Demand (MinTD), and Average Requested Throughput (ART), throughput values were
specified. But, it is only here in the scheduler definition that we specify the layer to
which these target throughputs apply. This means that target throughputs can be
specified at any layer within the services as long as the corresponding layer is identified
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

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
UL CTP vs FB
60
FB
30 FB
Avg FB
50
20
40
10
FB
FB
30 Avg FB
0
0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000
CTP (kbps) 20
10
0
0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000
CTP (kbps)
7.2.2.5. Station Templates

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.

Figure 78: Accessing Station Templates Table
This accesses the following Station Templates table.
Figure 79: Station Template Table
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.

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 right-
clicking on the Transmitter folder in the Data tab and selecting Equipment Æ TMA
Equipment, as seen in the following figure.
Figure 80: Accessing TMA Equipment Parameters
This opens up the TMA Equipment dialog window as seen in the following figure:

Figure 81: TMA Equipment Window

1 2 3 4
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.
7.2.3.2. Feeder Equipment

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).

Figure 82: Accessing Feeder Equipment Parameters
This opens up the Feeder Equipment dialog window as seen in the following figure:

Figure 83: Feeder Equipment Window
1 2 3 4
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”, AVA6-
50 1-1/4”, and AVA7-50 1-5/8” .

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.
7.2.3.3. BTS Equipment

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.
Figure 84: Accessing BTS Equipment Parameters
This opens up the BTS Equipment dialog window as seen in the following figure:

Figure 85: BTS Equipment Window

1 2 3 4 5
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.

7.2.3.4. LTE Equipment

The LTE Equipment interface can be accessed by right-clicking on the Transmitter
folder in the Data tab and selecting Equipment Æ LTE Equipment, as seen in the
following figure.
Figure 86: Accessing LTE Equipment Parameters
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.
Figure 87: LTE Equipment Window

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 eNodeB’s.
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. Bearer Selection Thresholds and Quality Graphs

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.
Figure 88: LTE UE Reception Equipment Window – Bearer Selection Thresholds
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
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

Figure 90: Effective MPR
Effective MPR
1.0
0.9 EFF = (1-10%) x Ideal MPR

Efficiency (bits/symbol)
MPR
0.8
EFF
0.7 Ideal
MPR
EFF > MPR
0.6
(negative BLER)
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-
3
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.

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
Downlink case:
Frame Based eNB 2 TX antennas at eNB,
2 RX antennas at sub
Example
2 – TX antennas
Uplink case: CPE
2 – RX antennas 1 TX antennas at sub, Example
2 RX antennas at eNB
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.

Figure 92: Example Downlink Path Represented in MIMO Tab
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 cell’s
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 Motorola’s first use of the
Max MIMO Gain field to model MIMO’s 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 project’s
database can be found in the spreadsheet “AtollR282Params.xls” located at

http://compass.mot-solutions.com/go/318588510. Refer to sheet “MIMO Tput

Scalars”.
• The tables represent gain curves that have been derived from Minisim
simulations.
• Atoll’s interface and database structure doesn’t facilitate the specification of
different MIMO gain curves to reflect different mobilities for the same path
configuration (e.g. PB3 and VA30 for 2x2 MIMO). For this reason, user entering
of these table values is needed.

Table 6: Max MIMO Gains
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.
• Four fields (highlighted in orange) correspond to Atoll parameters which must be
specified per the antenna configuration desired.
o Diversity Support (DL) is found in the Cells database.

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).
• 2x2 MIMO implemented on 4Tx using CSD (Drop D) should be considered
equivalent to 2x2 MIMO. It is not the same as true 4x2 MIMO.
• 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.
• TM3/4Tx/PB3 (highlighted in grey) is a poor performing scenario and the
scheduler, when given the freedom to mode switch, will select TM4 in
preference. Generally, don't select this option.
• 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.

Table 7: DL MIMO Parameter Settings
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.

Figure 93: Example Uplink Path Represented in MIMO Tab
The following figure shows the MIMO tab for the Motorola UE Reception (DL) properties
window.

Figure 94: LTE Reception Equipment – MIMO Tab

1 2 3 4 5 6 7
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 pull-
down 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 Atoll’s 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.

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 doesn’t 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.
Figure 95: Example MIMO Gain Graph
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.

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.

7.2.4.1. Cells Table

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
This opens up the Cells Table as seen in the following figure.

Figure 97: Example Cells Table
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
The Neighbors table is accessed by right-clicking on the Transmitters folder and
selecting Cells Æ Neighbors and then either Intra-technology Neighbors or Inter-
technology Neighbors, as seen in the following figure. (Although the Neighbors table is
not required in the RF system design process, a brief description is included here for
reference.)

Figure 98: Accessing the Neighbours Table
This opens up the Neighbors Table as seen in the following figure.
Figure 99: Example Neighbours Table
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.

7.3. Subscriber (Terminal) Parameters

The parameters associated with the subscriber units are located in the Terminals
portion of the Data tab. Each subscriber type is listed separately within the Terminals
folder and has its own set of parameters.
The Motorola template contains to default subscriber units (CPE and MS) along with
their recommended parameter settings.
This section will go through the parameters that are associated with a subscriber unit. It
also includes information regarding adjustments that may need to be made to the
subscriber antenna gain due to the placement of the CPE in a non-line-of-sight
environment and non-optimal orientation of the device.
To access the subscriber parameter information, expand the Terminals folder within the
LTE Parameters folder in the Data tab and then choose the desired terminal type, as
seen in the figure below. The parameters can also be accessed by right-clicking on the
Terminals folder and selecting Open Table. This table contains the parameters for all of
the terminals that are included in the project.
Figure 100: Accessing Terminal Parameters
By selecting a specific terminal type, the properties dialog window for that terminal will
open, as seen in the following figure.

Figure 101: Example Terminal Properties Window
2
3
4
6 5
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

modified to account for these factors. Body losses may be incorporated

here on a per-terminal basis or, preferentially, be applied on a per-service
basis (refer to Figure 183, Note 10). In either case, care should be taken
to avoid double counting the body loss.
Note. 6. The LTE Equipment field specifies the reception equipment for this
terminal. Within the Motorola template, this field is set to “Motorola UE
Reception (DL)” (refer to Section 7.2.3.4).
Note. 7. The Antenna Model field specifies the antenna model that is associated
with this terminal. Within the Motorola template, this field is set to a
representative antenna pattern. This parameter should be changed to the
actual antenna model being used in the system design. Please refer to
Section 6.6.3 for additional information on importing to patterns in Atoll.
Note. 8. The Antenna Gain field shows the gain that is associated with the selected
Antenna Model. The subscriber antenna gain value that is set within the
Motorola template is a representative value and should be changed to the
actual antenna gain for the device being modeled.
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 non-line-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. As discussed in
Section 7.3.1, these adjustments can be made to the antenna gain or to
the terminal Losses field.
Note. 9. The Antenna Diversity Support field specifies the type of antenna diversity
technique that is supported by the terminal. Terminals capable of certain
antenna diversity (i.e. None or MIMO) will be allocated to cells that support
the same type of antenna diversity.
Within the Motorola template, MIMO was selected as the antenna diversity
support for all terminals, so that the Rx diversity gain values will be used
from the Diversity Gain fields in the MIMO table (see Section 7.2.3.4.2).
Note. 10. The Number of Antenna Ports Transmission field specifies the number of
antennas that will be used by the subscriber terminal for transmission with
MIMO. Within the Motorola template, this value is set to 1 for all terminals
since the signal is typically only transmitted on one antenna for the
subscribers.
Note. 11. The Number of Antenna Ports Reception field specifies the number of
antennas that will be used by the subscriber terminal for reception with
MIMO. Within the Motorola template, this value is set to 2 to represent a
typical diversity receive device.
Note. 12. The “|<”, “<<”, “>>”, >|” buttons allow the user to easily navigate from the
properties window for one terminal type to the properties window for

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. CPE Antenna Variations

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-of-
sight (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 CPE’s 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 terminal’s 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.)

Figure 102: CPE Device Properties
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.

Figure 103: Reducing Antenna Gain by AGCF
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.

Figure 104: Alternate Way of Incorporating AGCF
If a non-Motorola subscriber device is being used, further information regarding this

device and its antenna will be required to determine the appropriate antenna gain
correction factor to be applied to the design.
7.3.1.2. Antenna Orientation Loss

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).
• RF environment is likely to change.
• New sites added which could change optimal orientation
• New construction or changes in foliage which may change optimal
orientation
• Changes in nearby obstructions (e.g. people, furniture, etc.)

The RF Planning Guide (http://compass.mot.com/go/310442223) provides details

regarding this topic. In order to quantify the antenna orientation loss, measurements are
required for each antenna type; however, a typical value of antenna orientation loss is 1
dB with 2 dB standard deviation.
Similar to the antenna gain correction factor, if the antenna orientation loss is used in
the design, either the CPE antenna gain within Atoll is reduced by this orientation loss
or this orientation loss is added to the Losses field of the terminal. For example, if a an
with 2 dB of orientation loss is not optimally oriented within a system, then the CPE
antenna gain should be reduced by 2 dB in addition to the reduction for the AGCF (i.e. 7
– 2.86 – 2 dB) or the 2 dB should be added to the terminal’s Losses field.
As described in the previous section, the antenna gain can be reduced for the specific
antenna that is associated with the subscriber device, or the AGCF and antenna
orientation losses can be added to the losses associated with the subscriber device.
See the previous section for further details on how to adjust the antenna gain or the
subscriber device losses.
7.3.1.3. Lognormal Fade Margin Standard Deviation

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
σx Lognormal fading margin standard deviation
σy Antenna gain correction factor standard deviation
σz Orientation loss standard deviation

ρ xy Correlation of lognormal fading margin and antenna gain correction factor
ρ xz Correlation of lognormal fading margin and orientation loss

ρ yz Correlation of Antenna gain correction factor and orientation loss
σ xyz Joint probability standard deviation
Example:
Device CPE
σx 8 dB
ρ xy 0.25 (a weak positive correlation)
ρ xz 0.25 (a weak positive correlation)

ρ yz -0.5 (a moderate negative correlation)
If the CPEs are randomly placed:

σ xyz 2 = 82 + 1.042 + 1.852 + 2(0.25)(8)(1.04 ) + 2(0.25)(8)(1.85) + 2(− 0.5)(1.04 )(1.85) = 781.4
σ xyz = 8.84 dB
If the CPEs are optimally placed:

σ xy 2 = 82 + 1.042 + 2(0.25)(8)(1.04) = 69.24
σ xyz = 8.32 dB
This new standard deviation along with the desired area reliability can be used to
determine a new lognormal fade margin that addresses slow fade, antenna gain
correction and orientation loss.
For further information regarding the lognormal fade margin, please see Section Error!
Reference source not found..
7.4. Clutter Class Parameters

The clutter class parameters must also be defined before running coverage studies. The
parameters for the Clutter Classes can be accessed in the Geo tab by double clicking
on the Clutter Classes field, as seen in the following figure.

Figure 105: Accessing the Clutter Class Parameters
This opens the Clutter Classes Properties window, as seen in the following figure.
Figure 106: Sample Clutter Classes Properties Window

1 2 3 4 5 6 7 8 9
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.

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.

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 SU-
MIMO 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 SU-
MIMO 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 user’s 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

settings) so additional Diversity gain offset is not needed in the clutter

table.
Note. 9. The Additional Receive Diversity Gain (dB) field provides a value that is
added to the user’s uplink 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
settings) so additional Diversity gain offset is not needed in the clutter
table.

8. Setting Propagation Inputs

This section of the document pertains to the propagation models in Atoll and running
propagation. First, Section 8.1 describes the available propagation models and provides
recommendations for the default parameter settings for the Atoll “Standard Propagation
Model”. Next, Section 8.2 describes a number of considerations in tuning the
propagation prediction model with drive-test data. Finally, Section 8.3 describes the
various propagation zones that are used to identify propagation and analysis extents.
8.1. Propagation Models

The propagation model selected for a prediction can have a large impact upon how
closely the results of the prediction will match what is actually seen in the field. To
minimize the difference between prediction and field results, the following subsections
provide information on the recommendations for a propagation model prior to collecting
data from the field and tuning a model specific for the market. (For information regarding
model tuning, please see Section 8.2.)
8.1.1. Available Propagation Models

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.

Figure 107: Atoll Propagation Models
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 Motorola’s
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,

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. SPM Parameter Settings

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.

Figure 108: Motorola Recommended 2.5 GHz Parameter Settings
8.1.3. Clutter Heights, Losses and Clearance

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.

Figure 109: Recommended Clutter Parameters
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 Forsk’s
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 Atoll’s 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

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. Base Station Antennas Below Clutter

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
Atoll’s 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.
Figure 110: Isolated High Clutter

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 ray-
tracing 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

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 Atoll’s 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

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.
Figure 113: Settings for Uniform Cost-231 Hata
8.2. Propagation Model Tuning

Forsk maintains a detailed model tuning document entitled “SPM Calibration Guide”.
The purpose of this section of the document is not to replicate all of the information in
Forsk’s manual; rather, it is meant to augment Forsk’s manual with additional
information and guidelines, as well as, to stress some of the key aspects of the model
tuning procedure that have a significant impact on the results. Please refer to Forsk’s
“SPM Calibration Guide” for the model tuning procedure and to this document for the
additional required information.
8.2.1. Collecting Drive Test Data

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.

>=50 samples over 40 wavelengths). In contrast, the RSS logged by a test UE

uses an averaging algorithm that is proprietary to the LTE chip manufacturer.
Since the signal processing algorithms are proprietary, the exact meaning of
what the RSS represents may not be known. It can only be assumed that it is
meant to reflect local mean signal strength.
- Accurate CINR prediction is very important for modeling LTE coverage,
throughput, etc. In order to tune the propagation model for interference, it is
necessary to collect drive-test data at the locations where the LTE signal from
the test location would interfere with signals from other LTE base stations. These
areas are at relatively further distances from the cell site than just the cell site’s
best server area. Using a test UE may limit the range over which the RSS
measurements can be taken if the test UE is handing off between base stations.
The test UE will also typically be less sensitive than a narrow band CW receiver,
which again will limit the range over which the RSS measurements can be made.
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:
- UE’s are typically diversity receive. If both antennas are used during the drive-
test, 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.
- There are additional considerations regarding the interpretation of the RSS
values stored in the drive test log file. These considerations are addressed in the
post processing section of this document, Section 8.2.2.

8.2.1.2. Selecting Sites

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

Figure 114: Pathloss versus Foliage Density
Propagation pathloss is a function of antenna height, so it is important to select sites

that cover the full range of expected antenna heights for the base stations to be
deployed. For example, if the base station antenna heights within a given area type are
expected to range between 20 and 65 meters, then test locations should be selected
that include a 20m antenna height, a 65m antenna height, and additional sites that
equally cover the range of antenna heights between 20 and 65 meters. In addition to the
dependence on the base station antenna height, the propagation pathloss will also
depend on the subscriber station antenna height. This document is aimed at the typical
LTE use case of UE antennas at approximately first floor window height. Other
scenarios will need to be addressed on a case-by-case basis.
8.2.1.3. Drive Routes

Atoll’s 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

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.
Figure 115: Drive Data with Least Squares Trendline
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

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.

Figure 117: Example of Uniform Drive Routes
8.2.1.4. Additional Deliverable Data

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.

Figure 118: Antenna Viewpoint Photos
8.2.2. Post processing RSS

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

process the collected RSS to match Atoll’s implementation. The equipment

manufacturer for the specific UE used for data collection will need to be contacted to
find the required information on RSS measurement.
8.2.3. Filtering the Drive-test Data

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 Forsk’s
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 log-
distance. 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 line-
of-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-of-
sight areas; therefore, these areas have potential to introduce error in the
optimization result. When there are only small areas like this, it’s 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 UE’s will be
deployed.

Figure 119: Example of Unfiltered Drive Test Data
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.
Figure 120: Example of Filtered Drive-test Data

8.2.3.2. Filtering for Receiver Noise Floor

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
As an example, if a Min Measurement filter of -107 dBm is used, which is 10 dB above

the measurement floor of -117 dBm, then the remaining sample points would be as
shown in Figure 122. Looking at this graph, it can see that the remaining sample points
do not accurately reflect the expected distribution of points between the two red vertical
lines. The red triangular area between the vertical lines depicts an area on the graph
where drive-test points would intuitively be expected if the Min Measurement filter was
not in place and the receiver was capable of measuring at lower signal levels.
The yellow dashed line in Figure 122 depicts a possible solution to the least squares
best fit when the input data is filtered for minimum signal strength. The solid light blue
line shows a possible solution that might be obtained if the additional data points in the
red triangular area were available. The difference between these two solutions
illustrates the impact of using the minimum signal strength filter. The yellow dashed line
has a shallower slope because it is being fit to the available data, which is skewed
towards higher signal levels at further distances because of the minimum signal
strength filter. The yellow dashed line is in error because of the missing data.

Figure 122: Issue with Minimum Signal Strength Filter
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 receiver’s minimum measurement threshold has
just been reached.
Figure 123: Maximum Distance Filter to Avoid Clipping

8.2.3.3. Filtering on Angle of Arrival

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.
8.2.3.4. Filtering for Minimum Distance

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. Running the Calibration

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.

Figure 124: Default Model Calibration Interface
8.2.4.1. HTx Method

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

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.

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 Forsk’s 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.

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 Atoll’s 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 drive-
test points.
8.2.4.10. Final Model Tuning Configuration

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.

Figure 125: Final Model Tuning Configuration
8.2.5. Validating the Optimized Model

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.
8.2.5.1. Analyzing Prediction Error for Validation Sites

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.

8.2.5.2. Plotting RSS versus Distance

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 Excel’s 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.
Excel’s 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 Excel’s trendline slope by 2.303 to
convert from natural log to log base 10.
Figure 126: Predicted and Measured Signal Strength

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 receiver’s
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
8.2.5.3. Analyzing Per-Transmitter Statistics

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

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
8.3. Propagation Zones

There a four Propagation Zones that are used by Atoll. Each zone has a specific
purpose that will be explained below. The Propagation zones can be found under the
Geo tab, in the Zones folder, as seen in the figure below.
The Propagation zones are the Filtering Zone, Focus Zone, Computational Zone and
Hot Spot Zone. The Printing and Coverage Export zones are used in the generation of
presentations; these zones will be covered later.

Figure 129: Propagation Zones Folder
8.3.1. Creating and Editing Zones

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.

Figure 130: Menu Options for Creating or Importing Zones
Once a zone has been created, it can be modified by two methods.

The first method is to right click on the desired zone, then select the Properties. A
Properties window will be revealed with the coordinates for each point in the zone.
Modifying the location of the points will change the shape and area of the zone. It is
possible to copy the coordinates of one zone/polygon and paste them into another
zone/polygon via the properties window. By this means, two zones/polygons can share
the exact same shape.
The second method is to have the desired zone selected in the Zone Folder, and then
left click on the zones line within the display. This action will highlight the intersection
points, allowing the user to insert/move/delete a point and move/delete the zone, as
seen in the following figure.
Important: Zones are taken into account whether or not they are visible on the Atoll
display (i.e. even if the display checkbox is not selected in the Zones folder of the Geo
tab).
Atoll provides several different ways of editing computation, focus, hot spot, and filtering
zones. For example, several polygons can be combined. Also, the computation, focus
and filter zone polygons can be made to contain holes. For more information on these
special editing features, refer to “Using Polygon Zone Editing Tools” in the Atoll User
Manual.

Figure 131: Menu Options for Editing a Zone
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

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
sites outside Filter Zone are not

seen in map or explorer window
and do not influence studies
prediction study is performed sites outside the computation zone

inside computation zone may impact the prediction study

Figure 133 : Propagation Zone and Computation Zone
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. Focus & Hot Spot Zones

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,

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
Hot Spot Zones
Computation Zone

Figure 135: Focus & Hot Spot Zone Reports
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. Coverage Export Zone

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

“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.
Figure 136: Exporting a Coverage Prediction

9. Generating Coverage Studies

Atoll has the ability to generate numerous images which can be utilized in evaluating the
RF performance of a system design. This section describes how to generate the images
and includes descriptions of some of the images that are most important in the LTE
system design process, as well as information regarding how to evaluate these images.
It also includes a section regarding the use of the Profile Analysis Feature in the image
evaluation process. Additionally, there is information provided regarding the generation
of reports and histograms based on the predictions.
NOTE: When printing an image from Atoll, the Forsk logo is included by default. To
include the Motorola logo instead, please use the logo.bmp file that is located at
http://compass.mot.com/go/267706168. This file needs to be placed within the following
directory: C:\Program Files\Forsk\Atoll.
9.1. Subscriber Antenna Height Selection

Image generation is impacted by many user settings. One important setting is the height
of the subscriber antenna. The subscriber antenna height can be set globally or for each
clutter type (depending on the propagation model being used).
The subscriber antenna height can be set globally by clicking on the “Data” tab at the
top of the “Explorer” window, then right-clicking on the “Predictions” folder and
selecting the “Properties” option. This opens the “Predictions properties” window.
Figure 137: Predictions Properties – Subscriber Antenna Height

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.
Figure 138: Propagation Model Properties – Clutter
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.

9.2. How to Generate Studies in General

The following provides the process that is followed when generating propagation
images. Section 9.2.1 provides general information on creating a new prediction study.
Section 9.2.2 provides further information concerning two approaches for applying a
lognormal fade (i.e. slow fade or shadowing) margin to the prediction results.
9.2.1. Creating a New Prediction

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.

Figure 140: Selecting Prediction Type
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

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.

- 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.)

Further details regarding creating prediction images can be found in the Atoll User
Manual.
9.2.2. Generating Predictions with Lognormal Fade Margin

The recommended approach to generating predictions is to apply a lognormal (i.e.
shadow) fade margin when specifying the Conditions for the prediction image by
checking the “Shadowing taken into account” box. . The values for model and CINR
standard deviations are located within the Clutter Classes Properties interface (see
Figure 149 and Figure 150 ). A second option is to not apply a lognormal fade margin
and produce images that represent the average levels.
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,
effectively, disable their use (since standard deviations are always applied within Atoll
simulations).
9.2.2.1. Lognormal Fade Margin Set in Prediction Properties

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

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.
Table 8: Lognormal Fade Margin (CINR)
Cell Edge Standard Lognormal

Area Standard
Coverage Deviation: Fade Margin
Reliability Deviation: C/I
Probability From Model (CINR)
90% 76.6% 5.81 dB 1 dB 1 dB
95% 87.4% 9.16 dB 1.6 dB 1.6 dB
Note: these values are based on an 8dB lognormal standard deviation.
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.

Figure 146: Shadow Fade Margin Calculator for RSSI
Figure 147: Shadow Fade Margin Calculator CINR
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)

Standard deviation = value from the Clutter Classes description

(see below)
If the desired margin and standard deviation are known, the edge probability can be
obtained using the following Microsoft Excel formula.
= NORMDIST(x,mean,standard_deviation,TRUE)
Where
x = amount of fade margin desired
Mean = zero (0)
Standard deviation = value from the Clutter Classes description
The Shadow Fade Margin calculator uses two fields from the Clutter Classes properties
interface (Atoll > Explorer > Geo > Clutter Classes, Right mouse click > Properties).
Figure 148: Accessing the Clutter Classes Properties
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,

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.

Figure 150: Clutter Class Default Values
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).
9.3. Propagation Prediction Images

This section provides descriptions and sample plots of some of the prediction coverage
images. The first subsection focuses on the images that will be used the most in the
evaluation of coverage and RSSI. The second subsection includes descriptions of
several other images that can be helpful in the design process, such as best server
images, throughput images, and best bearer images.
For further details regarding these images, please see the Atoll User Guide and the
Atoll Technical Reference Guide.
9.3.1. Coverage and RSSI Images

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.

9.3.1.1. Coverage by Channel Throughput – DL and UL

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.
Figure 151: Setting Condition Tab
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.

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.
Figure 152: Setting Throughput Display Information
An example downlink Peak RLC throughput image that results from settings such as
these is seen in the following figure.

Figure 153: Sample Coverage by Throughput – DL – Peak
9.3.1.2. RSSI Images – Effective Signal Analysis – DL and UL

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).

Figure 154: Effective Signal Analysis – DL – Options
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.

Figure 155: Sample Effective Signal Analysis Best Traffic Signal – DL
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 customer’s 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 prediction’s 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.

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 prediction’s 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. Additional Design Images

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.

Figure 156: Coverage by Throughput – DL – Options
The following subsections also include information on how to display throughput levels.
9.3.2.1.1. Effective MAC Channel Throughput

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. Application Channel Throughput

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.

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. Allocated Bandwidth Throughput - UL

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)
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).
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.

Figure 157: Sample Coverage by C/(I+N) Level Image – DL
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 customer’s 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
prediction’s 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 user-
defined 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)

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.
9.3.2.3. Coverage by Transmitter (Best Server)

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.)
Figure 158: Sample Coverage by Transmitter Image
If the option of using a margin was selected when generating the image (see Figure
142), it is possible to define the potential areas where a handover may occur since it
depicts the overlap between sectors by a given margin. This is dependent on the
network definition of handover and the criteria (e.g. the handover could be triggered
based on a C/(I+N) level or an RSSI level) for it to take place.

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
9.3.2.4. Coverage by Best Bearer – DL and UL

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.

Figure 160: Best Bearer Modulation Scheme

Figure 161: Sample Coverage by Best Bearer Image – DL
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.

Figure 162: Atoll generated best bearer ranges
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:
To use the configuration file, select ActionsÆConfigurationÆImport, as illustrated in

Figure 163, and browse to the appropriate configuration file (UL or DL).

Figure 163: Import best bearer plot configuration
9.3.2.5. Overlapping Zones

The Overlapping Zones coverage image provides an indication of the number of
transmitting servers that cover a pixel, based on the conditions defined when the image
is generated. This image can be based on reference signal level, path loss or total
losses within a defined range. The colors within the image indicate the number of
transmitters that are covering a given pixel.
The images generated to show Overlapping Zones may be used to help evaluate
adequate coverage and determine if there are too many interferers that appear in
various locations of the network design.

Figure 164: Sample Overlapping Zones Image
9.4. Interpreting Images

LTE images produced by Atoll provide powerful tools for system designers, but do not
automate the design process. The images provide visual feedback on the RF
performance of the system design in its current state. The images do not warn the
designers of existing problems or direct them to the solutions. Ultimately, the system
designers need to apply their own skills and make deployment decisions to arrive at the
final design. Interpreting the system performance feedback given through the Atoll
images is a part of the process. Some images or combination of images, for use in the
LTE design process will be suggested below. They are not intended to be totally
inclusive as designers will find their own set of images that provide insights to unique
design situations encountered.
This section also provides information regarding the use of Atoll’s Profile Analysis
Feature. This feature is useful when evaluating and gathering detailed information
regarding an image.
Additionally, this section provides information regarding coverage range limitations that
should be kept in mind when evaluating images.
9.4.1. Tips and Hints for Evaluating Images

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

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.
Figure 165: Tip Text Display
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.

Figure 166: Tip Text Display Properties
9.4.2. Evaluating Coverage and Interference

A good understanding of the customer’s expectations is primary to planning LTE system
coverage. For example, it is important to understand the area that the customer wants
to cover (i.e. the service area). Often within the customer’s defined service area, there
will be regions that are essential to cover and other regions where coverage is not
required. The goal of providing coverage in a design is to ensure all desired geographic
locations within the service area are given RF coverage at performance levels that meet
or exceed the customer’s coverage and throughput expectations.
By nature, an LTE system design will typically have some small coverage shadows
behind obstructions (e.g. buildings, foliage, and abrupt geographic features). The design
goal is to provide coverage over a desired region knowing these small shadows will
exist. The designer will need to explain the coverage to the customer, setting their
expectations and gaining their acceptance of the design. Attempting to provide RF
coverage to every square meter of a region (outdoor and indoor) is cost prohibitive and
beyond the scope of reasonable LTE deployment.
The coverage and interference images need to be reviewed to ensure that the service
area is covered with adequate signal strength and that there is no significant
interference. Since the coverage area reliability is taken into account by including the
lognormal fade margin by specifying a Cell Edge Coverage Probability, the design goal
is to ensure that 100% of the service area is covered with adequate signal strength (i.e.
at or above the RSSI threshold throughout the service area) and that there is no
significant interference (i.e. at or above the CINR threshold throughout the service
area). As mentioned above, there are often regions within the customer’s service area
that are essential to cover and other regions where coverage is not required. This

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:
• Adjusting antenna downtilt in sites/sectors to address coverage or
interference issues.
• Adjusting antenna azimuth to address coverage or interference issues
• Selecting a different site deployment pattern or using alternate site
locations for key sites that affect the coverage problem area.
• Adding sites to fill the coverage hole.
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
signal’s path. It may also be caused by an unusually strong signal from the neighboring
sites. If this is the case, downtilting the offending sector’s antenna is typically the best
approach to controlling the interference problem.
9.4.2.1. Coverage Images

As mentioned in Section 9.3.1.1, the Coverage by Channel Throughput images are
used to evaluate the coverage of a system. When evaluating this image, the system
designer needs to show that the downlink and uplink meet or exceed the desired cell
edge throughput value throughout the customer’s service area (i.e. in 100% of the
service area).
Verify the “Shadowing taken into account” option was checked in the prediction’s
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.
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 customer’s 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 prediction’s
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
kTB is calculated as follows:
Downlink kTB = kT + 10log(Resource Element bandwidth * DL occupied Resource
Elements)
Uplink kTB = kT + 10log(UL Resources Blocks * 180 kHz )

And kT (dBm/Hz) = -174
The following table contains downlink and uplink kTB values for the different channel
bandwidths. The uplink kTB value will need to be modified (using the equation above)
based on the number of UL Resource Blocks that are assumed per user for the given
market.
Table 9: Downlink/Uplink kTB Values

Maximum Maximum
Resource DL Number of UL
kT Downlink kTB Uplink kTB
Channel element Occupied UL Occupied
Bandwidth, (dBm/Hz) Bandwidth, Resource Resource Resource (dBm) (dBm)
MHz Hz Elements Blocks Blocks *
1.4 -174 15000 72 6 5 -113.7 -114.5
3 -174 15000 180 15 13 -109.7 -110.3
5 -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.

9.4.2.3.2. Noise Figure (NF)

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 Modulation PB3 VA30 VA30R1
0 QPSK 0.12 -5.3 -5.3 -5.3
1 QPSK 0.15 -4.3 -4.3 -4.3
2 QPSK 0.19 -3.3 -3.3 -3.3
3 QPSK 0.25 -2.0 -2.0 -2.0
4 QPSK 0.30 -0.9 -0.9 -0.9
5 QPSK 0.37 0.3 -0.2 -0.2
6 QPSK 0.44 1.5 1.8 1.6
7 QPSK 0.51 2.7 3.1 3.0
8 QPSK 0.59 3.7 4.1 4.0
9 QPSK 0.66 4.6 5.0 4.9
10 16 QAM 0.33 4.6 5.0 4.9
11 16 QAM 0.37 5.3 5.8 5.8
12 16 QAM 0.42 6.4 6.8 7.3
13 16 QAM 0.48 7.6 8.2 9.1
14 16 QAM 0.54 9.0 9.5 10.7
15 16 QAM 0.60 10.0 10.8 12.1
16 16 QAM 0.64 10.8 11.5 12.8
17 64QAM 0.43 10.8 11.6 12.9
18 64QAM 0.46 11.4 12.3 13.6
19 64QAM 0.50 12.5 13.4 14.5
20 64QAM 0.55 13.6 14.4 15.4
21 64QAM 0.60 14.5 15.3 16.5
22 64QAM 0.65 15.4 16.2 17.4

23 64QAM 0.70 16.2 16.8 18.1

24 64QAM 0.75 17.0 17.8 18.9
25 64QAM 0.80 19.2 19.8 19.9
26 64QAM 0.85 40.0 40.0 40.0
27 64QAM 0.89 40.0 40.0 40.0
28 64QAM 0.93 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 project’s database can be found in the
spreadsheet “AtollR282Params.xls” located at
Refer to sheet “BST” (for Bearer Selection Thresholds).
Table 11: UL Effective SNR Values (i.e. bearer selection thresholds)

VA30
BEAREX &
INDEX Modulation PB3 VA30R1
-0.088 0.612
30 QPSK 0.10
0.981 1.681
31 QPSK 0.13
1.743 2.409
32 QPSK 0.16
2.909 3.109
33 QPSK 0.21
4.235 5.134
34 QPSK 0.25
5.192 6.050
35 QPSK 0.31
5.950 6.687
36 QPSK 0.37
6.577 7.431
37 QPSK 0.43
7.145 8.068
38 QPSK 0.49
7.771 8.511
39 QPSK 0.56
8.285 8.921
40 QPSK 0.62
8.285 8.921
41 16 QAM 0.31
8.993 9.688
42 16 QAM 0.35
9.857 10.405
43 16 QAM 0.40
10.516 11.114
44 16 QAM 0.45
11.383 12.032
45 16 QAM 0.50
12.097 12.322
46 16 QAM 0.54
12.393 12.634
47 16 QAM 0.57
12.899 13.306
48 16 QAM 0.63
13.676 14.263
49 16 QAM 0.69

14.634 15.160
50 16 QAM 0.75
40.0 40.0
51 64QAM 0.50
40.0 40.0
52 64QAM 0.54
40.0 40.0
53 64QAM 0.59
40.0 40.0
54 64QAM 0.63
40.0 40.0
55 64QAM 0.67
40.0 40.0
56 64QAM 0.71
40.0 40.0
57 64QAM 0.74
40.0 40.0
58 64QAM 0.77
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 project’s database can be found in the
spreadsheet “AtollR282Params.xls” located at
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. Adaptive Array Gain

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

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

In addition to evaluating coverage and signal strength within a system, other
performance aspects of the system need to be evaluated. Various other images are
available to assist with this evaluation, such as:
• Coverage by Channel Throughput is used in evaluating throughput results
in the system
• Coverage by C/(I=N) is used in evaluating regions of high interference.
• Coverage by Best Bearer provides information regarding the achieved
bearer rates in the system.
• Coverage by Transmitter provides a best server analysis of the system
• Overlapping Zones can provide additional insight into possible
interference areas.
Further information regarding these images can be found in Section 9.3.2 and in the
Atoll manuals.
9.4.3. Use of Profile Analysis Feature in Evaluation

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.
This will open the Point Analysis window.

9.4.3.1. Path Profile Analysis

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
2 3
4 7
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
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

Figure 169: Path Profile Link Budget
9.4.3.2. Reception Analysis

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.

Figure 170: Path Profile Reception
9.4.3.3. Signal Analysis

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.

Figure 171: Path Signal Analysis
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 next
to any of these titles indicates a working connection; a red next to any
of these titles indicates a bad connection.
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).
Figure 173: SCH & PBCH Reception Window

Figure 174: Downlink Window
Figure 175: Uplink Window
9.4.3.4. Results Analysis

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.

Figure 176: Path Profile Results
9.4.4. Coverage Range Limitations

Coverage range in an LTE system, as well as other technologies, can be limited by
timing considerations. For LTE, the PRACH for FDD and TDD Systems as well as the
guard period for TDD systems serve to limit the cell range. The following table provides
the cell radius limitation as a function of the PRACH configuration.
Table 177: Maximum Cell Range Due to PRACH Timing

Number of CP Duration GT Duration Max Delay
Maximum Cell
Preamble Format Allocated (μs) (μs) Spread (μs) Radius (km)
Subframes
0 1 103.13 96.88 6.25 14.53
1 2 684.38 515.63 16.67 77.34
2 2 203.13 196.88 6.25 29.53
3 3 684.38 715.63 16.67 100.16

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
9.5. Generating Propagation Prediction Statistics

Propagation prediction statistics are generated for the Focus and / or Hot Spot Zones.
If Focus or Hot Spot Zones do not exist, the reports will be generated for the
Computation Zone. These zones can be created from existing polygons or drawn onto
the project area. (See Section 8.3 for further information regarding zones.) To generate
prediction statistics for a given service area, it is recommended to generate a Focus
zone (see Section 8.3.4) corresponding to the service area before generating
predictions.
The prediction statistics are useful in determining if changes that the user has made
have improved the overall system performance. The most typical uses would be for
sector modifications (e.g. azimuth or downtilt changes) and the addition or removal of
sites within the system.
9.5.1. 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

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.
Figure 180: Coverage by Best Signal Level Report
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 customer’s 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

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.
9.6. Generating Path Loss Files

The pathloss planes of Atoll can be exported as either a binary (bil) or as a text file (Tab
or comma delimited). When exported, the pathloss planes will be in the projection
system defined in the Atoll project and the Displayed Map Projection. Each transmitter
will generate its own pathloss plane.

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).

10. Capacity Analysis

This section describes the process by which Monte Carlo simulations are used to derive
DL and UL Traffic Loads and UL Noise Rise. These simulation outputs can be fed back
into coverage predictions. Also, simulation results are used to verify that the capacity
criterion for the system design is met.
The overall process of assessing system capacity is outlined at a high level as follows:
1. Define Services, Mobility, Terminals, and Schedulers
2. Create Traffic Map(s)
These will describe the subscriber density and define the load being offered to
the system. Subscriber lists may be used to characterize fixed subscribers.
3. Run Monte Carlo Simulations
a. A “Group” of “Simulations” are made.
b. Each simulation has a load of active subscribers “dropped” into the
simulation. The number and position are determined randomly, but
reflect, in their average across simulations, the probabilities established
via the traffic maps for subscriber density, mixture of services, and
probabilities of activity.
c. Sectors (channels) will be loaded with traffic.
i. First, in a manner that satisfies the Minimum Throughput Demand
(aka Minimum Reserved Rates) for the services.
ii. Secondly, remaining capacity is distributed among users according
to the manner that reflects the scheduler.
Note: “Resource Saturation” occurs whenever the Minimum Throughput
Demands of the users cannot be satisfied. These are reflected in the
resultant statistics and constitute capacity “outages”.
d. Resultant statistics are produced.
4. The resultant statistics are reviewed to verify that the system (including each
individual sector) can carry its load (i.e. Resource Saturation is at acceptable
levels). This constitutes an exit criterion.
Should the exit criteria not be met, the systems designer can look at alternatives
such as improving site capacity (e.g. optimizing antenna tilt and azimuth,
adopting a different antenna technology) or increasing the site count.
This process verifies that the projected system load can be supported. It may
also be desirable to determine the system capacity (i.e. the maximum load per-
sector that the system can carry). Different system capacities can be defined
including “maximum user”, “maximum throughput”, and “available”. Optimizing
system capacity may also involve adjusting the system design around limiting
sites.

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.
10.1. Defining Services
Services, together with Mobility Types and Terminals, need to be defined to produce
Monte Carlo simulations that characterize the traffic load submitted to the system. This
section describes how the Services are defined within Atoll. The type of services that

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.
Figure 182: Accessing Services Parameters
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.

Table 12: Template Services Parameters
FTP Video Web Full

Name VoIP
Download Conf Browsing Buffer
Type Data Voice Data Voice Data
Priority 0 2 1 3 1
UL DL UL DL UL DL UL DL UL DL
Activity Factor 1 1 0.5 0.5 1 1 0.5 0.5 1 1
Highest Bearer 50 29 50 29 50 29 50 29 50 29
Max Throughput Demand (kbps) 256 1000 64 64 256 1000 12.2 12.2 1000 2200
Min Throughput Demand (kbps) 64 100 64 64 64 100 12.2 12.2 0 0
Average Requested Throughput

180 360 64 64 180 180 12.2 12.2 360 360
(kbps)
Application Throughput Scaling

95 95 95 74 95
Factor (%)
Application Throughput Offset

0 0 0 0 0
(kbps)
Body Loss (dB) 0 0 0 2 0
The following figure shows an example of the GUI window set up for an FTP service.

Figure 183: Example Services GUI Window (FTP)
1
2 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.

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 Motorola’s 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
Uplink Downlink
Template 50 29
(MCS 20, 16QAM 0.75) (MCS 28, 64QAM 0.93)
Future 58 29
(MCS 28, 64QAM 0.77) (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).

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.

10.2. Defining Mobility Types
Mobility Types, together with Services and Terminals, need to be defined to produce
Monte Carlo simulations that characterize the traffic load submitted to the system. The
primary purpose for defining Mobility Types is as a means for indexing the appropriate
bearer selection threshold and quality curves. Note that should a new mobility type
need to be defined, it will require adding new curves.
This section describes how the Mobility Types are defined within Atoll. The Mobility
Types within Atoll are accessed through the Mobility Types folder within the LTE
Parameters folder in the Data tab, as seen in the following figure.
Figure 184: Accessing

Mobility Types
As seen within this figure, the Motorola template
defines three basic mobility types: PB3 (Pedestrian
B @ 3 kmph), VA30 and VA30R1 (Vehicular A @
30 kmph). Typical designs use the PB3 mobility
type which is appropriate even for a fixed CPE
scenario, as there will be movement in the
environment (trees swaying, vehicles passing, etc.).
VA30 (for TM 3/4) and VA30R1 (for TM2/6/7) are
for systems that are mobile. Systems which contain
both pedestrian and vehicular traffic should be
characterized by whichever mobility type is limiting.
Note that there are “_Capacity” versions of each of
these mobility types. They are identical to their
counterparts in their speed and exist so as to be
able to access, for capacity purposes, another set
of bearer selection thresholds and quality scalars.
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 right-
clicking 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”.

Figure 185: Example Mobility Types GUI Windows (PB3)
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.
10.3. Defining Terminals
Terminals, together with Services and Mobility Types, need to be defined to produce
Monte Carlo simulations that characterize the traffic load submitted to the system. The
Atoll LTE Parameters within the Data tab also include Terminals. The Terminal
properties define how the subscriber equipment is modeled within Atoll (power level,
noise figure, antenna parameters, etc.). Terminals are described in Section 7.3.
10.4. Defining User Profiles
User Profiles characterize subscribers in terms of their service usage. Each service is
paired with a specific terminal type which permits for defining, for example, web
browsing to be done assuming a modem card while a VoIP call might assume a
handheld device. Each service/terminal pair is then correlated to a specific per-user
load (arrival rate and voice average hold time or session data volume). When
marketing-based traffic data is available for the system design, then the use of User
Profile traffic maps would be very appropriate.
Note: It should be understood that the parameters characterizing the default User
Profiles found within the template are simply placeholders. The systems designer is
responsible for setting inputs to correspond to the actual customer traffic projections.

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.
Figure 186: Accessing User Profiles Parameters
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)
2 3 4 5 6 7
NOTES:
Note. 1. The Name field allows the user to provide a name for the given User
Profile.

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 doesn’t model a

user employing two different services simultaneously. Should it become

significant to model simultaneous services (e.g. a CPE with multiple VoIP
lines that sustains greater than 1 Erlang of busy hour voice traffic), then
the load per user, as represented within the user profile, should be scaled
down to the point where the probability of activity is now less than 1 and
the user density, as represented in traffic map, correspondingly scaled up
so that the total offered load remains the same.
Note. 5. The Duration (sec.) field is only used for voice services. This field provides
the average duration of a call (in seconds) for the given type of service. If
the given service is a data service, then this field is left blank.
Note. 6. The UL Volume (Kbytes) field is only used for data services. This field
provides the average uplink volume per session (in kilobytes) for the given
type of service. If the given service is a voice service, then this field is left
blank.
Note. 7. The DL Volume (Kbytes) field is only used for data services. This field
provides the average downlink volume per session (in kilobytes) for the
given type of service. If the given service is a voice service, then this field
is left blank.
10.5. Defining Environments
Environment classes are defined to facilitate the creation of environment traffic maps.
Each environment class corresponds to a mix of user profiles where each profile is
associated with a mobility type and user density (i.e. subscribers/km2). In this manner,
environment traffic maps can easily be created by drawing a polygon and associating
an environment with it. When marketing-based traffic data is available for the system
design, then the use of Environment traffic maps will be best.
Options exist to further specify the user distribution on the basis of clutter and
indoor/outdoor.
Note: It should be understood that the parameters 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 Environments within Atoll are accessed through the Environments folder within the
LTE Parameters folder in the Data tab, as seen in the following figure.

Figure 188: Accessing Environments Parameters
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
2 3 4

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.

Figure 190: Example Environments Window (Urban) – Clutter Weighting Tab
1 2
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.
10.6. Traffic Maps and Subscriber Lists
To perform Monte Carlo simulations as part of a traffic study, it is required to derive the
number of active (bursting) users in any given region. Deriving this number is
accomplished via traffic maps. Users also need to be characterized by their services,
mobility type, and terminals.
Procedures for creating or importing traffic maps, definitions of map parameters, as well
as procedures for accessing and modifying map parameters are to be found within the
Atoll user manual (see Section 12.3.2 of the Atoll 2.8.1 User Manual). This section does
not reproduce these Atoll user manual descriptions, but assumes that the reader is
already familiar with them. The balance of this section will describe the various traffic
maps available and their use. The use of subscriber lists is also described in this
section (see Section 12.3.4 of the Atoll 2.8.1 User Manual for detailed creating,
accessing, and modifying procedures).
Figure 191: New Traffic Map
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.

• 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”.
• Reference to “active” users typically refers to bursting users. Any exceptions in
this section will be explicitly noted.
10.6.1. User Profile and Environment Traffic Maps

The first class of traffic maps are those based on user profiles. The user profile class is
sub-divided into user profile (“user profile densities”) and environment (“user profile
environments”) traffic maps. Options to create either type are available in the pull-down
menu associated with the “User profile traffic map” selection of the “New traffic map”
window (see Figure 191). These maps have the following characteristics.
• 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.)
• Population databases, which correlate regions to subtending populations (e.g.
census geo datasets) can be leveraged to create user profile traffic maps.
Additional fields can be added to the database that allow for scaling the
population by a target penetration to magnitudes that correspond more directly to
the number of active subscribers. This approach can be readily applied to user
profile traffic maps because they accept vector file formats (e.g. shp or mif).
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.

Figure 192: User Profile Traffic Map Properties
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.

Figure 193: Environment Properties (example)
10.6.2. Sector Traffic Maps

The second class of traffic maps are those based on sector traffic. The sector traffic
maps have the following characteristics.
• 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.
• Sector coverage is mapped to specific per-sector traffic specifications. The
number of active users is specified on a per-service, per-direction basis. The
distribution (probability) of mobility types and terminals is globally specified
across all sectors. To use this means of traffic specification, select “Number of
users per activity status” in the pull-down menu associated with the “Sector traffic
map” selection of the “New traffic map” window (see Figure 191).
• Alternatively, throughput demand can be used to specify the load instead of
specifying active users directly. In this case, the demand is normalized by the
average requested throughput for the service to derive the number of active
users. To use this means of traffic specification, select “Throughputs in uplink

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).

Figure 195: Sector Traffic Map Table
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 user’s 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.
• The distribution (probability) of services, mobility types, and terminals is globally
specified for each user density map.
• 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.

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
10.6.4. Subscriber Lists

Atoll also includes a subscriber database for modeling fixed user distributions in a
network. Subscriber lists have the following characteristics.
• 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.
• Subscriber lists may be used in conjunction with traffic maps.
• 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

the absence of simulations and, in this case, the service and terminal type are
specified separately within the database.
• Pathloss calculations are performed independently for each subscriber because
antenna heights can be subscriber-specific. This is in contrast to the treatment of
mobiles dropped from traffic maps. In this case, antenna heights are fixed for the
simulation and all mobiles dropped leverage the pathloss matrices that are
generated for the simulation.
• Each individual user can be characterized as indoor or outdoor.
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.
10.7. Simulation Process
A description of the Monte Carlo simulation process is provided within the Atoll User
Manual (within the LTE chapter, refer to the section titled “LTE Traffic Simulation
Algorithm”) and a detailed description within the Atoll Technical Reference (within the
LTE chapter, refer to the section titled “Simulation Process”). For reference, the overall
simulation process is represented in the following flow chart.

Figure 197: Simulation Process Flowchart
In the balance of this section, some key aspects of the simulation process will be
highlighted.
• During the initialization phase, a realistic user distribution is obtained as a
function of the traffic map(s) supplied as input for the simulation. The overall
number of users is obtained from density and surface area. User profiles provide
insight into the probability of using a particular service and/or of being active in a
particular direction within a service. Note that these probabilities of activity are
used as means for random draws; consequently, the actual number of users
employing a service or exhibiting an activity status will vary about the mean
across drops. Randomness is also present in determining locations within the
service area (as a function of different weightings per clutter) and in assigning
whether the subscriber device is indoor or outdoor.
• As an example of deriving probabilities of activity, consider the following voice
and data examples:
o Assume a voice service with 2 busy hour call attempts of 180 seconds
each and a voice activity factor in each direction of 40%. Then, the
probability of using the voice service would be 10% (= 2 x 180 / 3600).

This also corresponds to the Erlangs of traffic (0.1 Erlangs). Subscribers
are classified as either bursting DL, UL, or both DL and UL and the
probability of being in one state or the other is based on the voice activity
factor. In this case, there is a 24% probability [40% x (1-40%)] of being
DL (and the same for UL) while there is a 16% probability [40% x 40%] of
being active in both directions (which leaves a 36% probability
[(1-40%) x (1-40%)] of being inactive).
Note: Inactive subscribers, even though associated with a service, don’t

show up in the resultant statistics from simulations since they don’t
transfer any data.
o Assume a data service with 0.1 busy hour data sessions pushing 15,000
kBs DL each session with an average requested throughput of 200 kbps.
The probability of being active in the DL direction is 1.67% [0.1 x 15000 kB
x 8 bits/byte / 200 kbps / 3600 sec/hr]. The formula can be seen to take
the kilobits transferred in the busy hour (0.1 x 15000 x 8) and dividing this
by the average throughput (200 kbps) to derive the busy hour bursting
seconds (60s). When this is divided by 3600s, this yields the probability of
bursting, i.e. of being active.
• 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

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.
• Radio Resource Management (RRM) is next performed to determine how
resources are allocated among users. Potentially, subscribers can be excluded
immediately due to limits on the number of simultaneous users supported by the
scheduler. This is represented by the Cells parameter, Max Number of Users
(refer to Section 7.1.2.1.3). Subscribers that are excluded due to this limit are
said to be in “Scheduler Saturation” and are not deemed “connected”. It is
recommended that the Max Number of Users parameter be null so as not to
apply any limit.
• As part of RRM, sectors (channels) are loaded with traffic.
First, in a manner that satisfies the Minimum Throughput Demand (aka
Minimum Reserved Rates) for the services. “Resource Saturation” occurs
whenever the Minimum Throughput Demands of the users cannot be
satisfied. These are reflected in the resultant statistics and constitute
capacity “outages”. Subscribers that satisfy the MinTD are, by definition,
“connected”.
Secondly, remaining capacity is distributed among users according to the
manner that reflects the scheduler method selected. Refer to Section
7.2.2.4 for a description of the Proportional Fair and Proportional Demand
scheduling methods.
• 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 re-
evaluated.
• 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.

10.7.1. How to Run Simulations

Refer to the LTE chapter of the Atoll user manual under the heading “Creating
Simulations” for a detailed description of the procedure to run simulations. Key
elements are highlighted here.
Number of Simulations
In specifying the Number of Simulations, employ only a single drop. In this manner,
quicker feedback can be obtained upon which to assess whether adjustments in the
design need to take place. Later, the number of drops can be increased (~10 to 30) to
obtain a larger sample and greater confidence in the results. Average statistics can be
produced for the group of simulations.
Max Traffic Load
DL and UL Max Traffic Loads should be globally set to 100%. It is not clear how this
parameter corresponds to any limiting mechanism within the product.
Global Scaling Factor
The Global Scaling Factor (GSF) is used to scale the number of users in the simulation
either up or down. Assuming that the offered load established via the traffic map
properly reflects the customer’s projection, then the GSF would be 1. Once this offered
load is determined to be carried by the system, then the GSF can be increased to
identify a system capacity (i.e. some load which establishes a sector or group of sectors
as limiting any further load increase).
Generator Initialisation
The generator initialization parameter establishes the seed for random number
generation during the simulation. The number should always be set to a consistently
applied non-zero, integer value. In this manner, the results will be random, but capable
of being duplicated.
Convergence
The recommended Convergence parameter values are 50 for Max Number of Iterations,
0.2% for DL and UL Traffic Load Convergence Threshold, and 1 dB for UL Noise Rise
Convergence Threshold. Note that the smaller the sample size, the larger the number
of iterations required to achieve convergence.
Note: Beginning in R282, Forsk modified their internally hard-coded convergence
parameter defaults to different values; namely, 100 for Max Number of Iterations and
5% for DL and UL Traffic Load Convergence Thresholds. It is recommended to
continue employing the original, tighter constraints. This will require manually setting
these values for each simulation.
It is unusual for simulations to require as many as 50 iterations to converge. If
simulation statistics show that all 50 iterations, then it is likely that the simulation didn’t
converge. Under these circumstances, the convergence parameters above should be
relaxed (e.g. 1.0% for the traffic load thresholds and 2 dB for the UL noise rise) in an

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.
10.7.2. Simulation Output Statistics

Within a group of simulations, each simulation (drop) has a corresponding set of
statistics produced. These statistics are accessed by opening the simulation properties.
The properties, as shown in the following figure, contain 5 tabs. The details for all
statistics found are described in the LTE chapter of the Atoll user manual under the
heading “Displaying the Results of a Single Simulation”. A summary is provided here
along with some highlighting of key elements.
Figure 198: Simulation (Drop) Statistics
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

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

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 re-evaluated. It is advisable that final UL NR values produced from Monte
Carlo simulations should come from averages across a larger number of drops.
To leverage the simulation results when producing, for example, a Coverage by C/(I+N)
Level prediction, simply specify the simulation group for the Load Condition under the
Condition tab. To actually carry the simulation results into the Cell table fields on a
permanent basis, the fields are “committed”. Select the Commit Results button found
on the Cells tab of simulation properties (either for an individual drop or for a group
average).
10.8. Procedure for Capacity Analysis
What follows is a Motorola recommended procedure for performing LTE capacity

analysis.
1. An initial assessment of coverage reliability should have already been
established. For the DL, this assumes 100% Traffic Load. For the UL, this
assumes user defined UL noise rise. UL coverage can be re-evaluated after
more realistic UL noise rise values are produced via simulations.
2. Prior to running simulations, verify that all inputs have been defined.
a. Needed Services should be defined (Section 10.1).
Although the template is intended to provide a realistic set of parameters
for VoIP, FTP, and Web Browsing, the services may still require further
customization. Furthermore, a service approximating full buffer is
provided.
The level at which throughput parameters for services are defined (i.e.
Peak, Effective, or Application) should correspond to the target
throughputs defined for voice and data services within the Scheduler.
b. Needed Mobility Types should be defined (Section 10.2).

Mobility types explicitly intended for use in capacity simulations are
included within the template.
If Subscriber Lists are to be employed, then a Fixed mobility type will need
to be added.
c. Needed Terminals should be defined (Section 10.3).
d. Scheduler should be defined (Section 7.2.2.4). Generally, the
Proportional Fair scheduler and associated default template parameters
should be sufficient.
e. User Profiles and Traffic Map(s) should be defined (Sections 10.4, 10.5,
and 10.6). This will always require customization. Default template

definitions for user profiles cannot be accepted as appropriate. The user

profiles will establish the voice and data service loads exhibited by typical
users in accordance with customer inputs for the traffic load. The traffic
maps will define the user profile density (users per km2) for the service
area(s). The maps will also associate with the user profile the appropriate
capacity mobility type.
Alternatively, other traffic map types (environment, sector, density) can be
employed.
f. Model and CINR standard deviations, both default and per-clutter class,
should be disabled (zeroed). Note that within simulations, standard
deviations are always applied; therefore, their values must be set to zero
(as they are in the template) to, effectively, disable them.
3. Run Monte Carlo simulations. A single simulation can be employed for initial
assessments and more simulations (10-30) for greater confidence in final work.
4. Export and post-process the simulation statistics. To facilitate the post-
processing of simulation statistics, a spreadsheet (AtollStatsTemplate.xls) is
provided with associated macros. A detailed description is provided in Section
10.8.1.
5. Review the simulation statistics, either Atoll’s or post-processed, to determine
whether simulation goals have been achieved. Repeat steps 3 and 4, as
required. Different insights into capacity can be obtained via simulations and
these are discussed below. For the following explanation, assume the traffic
map and services reflect the projected load for a planning period (e.g. EOY2010).
a. If the statistics show that the percentage of rejections due to Resource
Saturation (%RS) for all sectors is ≤2%, then this indicates that the system
capacity is sufficient to satisfy the traffic load requirements for the planning
period. This result is considered the minimal exit criterion for capacity. For
some design work, it may be sufficient to establish that the projected load
is satisfied and no further capacity analysis is required, but it is more likely
that some better and more accurate definition of the system capacity is
desired.
b. Vary the system load (through use of the global scaling factor). Consider
the following:
• The GSF may act as an oversubscription factor (OSF) to scale a total
subscriber population down to the active subscriber population.
Conversely, the subscriber population can be scaled upwards to model
the system closer to full loading.
• Identify the limiting sector. The limiting sector is that which blocks with
the highest %RS.
• If it appears that relieving the congestion for just a few limiting
sites/sectors will allow for sufficiently increased system capacity to
justify it, then relief options (e.g. down-tilting, cell splitting, etc.) should
be explored.

• Trade-offs between sector capacity and average or edge user

throughput can be observed as user load is modified. Under heavier
user load, the scheduler behavior will move towards being completely
PD. Conversely, as user load lightens, a greater influence of PF
allocation will be noted.
c. For real-world scenarios where traffic is very non-uniform, it is likely that
many sectors will be exhibiting traffic loading at levels less than 100%.
Reporting the system capacity without explicitly acknowledging this can be
misleading by underestimating the available system capacity. To
approximate the available system capacity, sector loading is divided by
the sector %traffic load to derive available sector capacity and then these
are summed across sectors of the system. The available sector capacity
is derived via post-processing and statistics are termed “Throughput
Capacity”.
Note: For a TDD frame configuration, Atoll scales DL and UL throughputs.
Currently, the DL scaling applied within Atoll is in not optimal, and,
consequently, requires further adjustment. Refer to Note. 16 in Section
7.1.2.1.3 for details.
6. Once simulations are complete, the UL CINR coverage prediction can be re-run
with the simulation referenced as the Load Condition (rather than the Cells
Table). This will allow for verifying UL coverage reliability using the more
accurate UL noise rise from the Monte Carlo simulation.
10.8.1. Post-processing Simulation Statistics

The procedure for post-processing simulation statistics that leverages the
AtollStatsTemplate.xls spreadsheet is described below.
Note: Excel’s 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 2007’s limit is ~1M rows (which doesn’t 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 Atoll’s 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:

• 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.
• Sheets 1 through 5 will be renamed to “Atoll Stats”, “Sites”, “Sectors”,
“Mobiles”, and “Init Conds”.
• Auto-filtering is enabled. This makes it possible to look at subsets of the rows
of data based on different user-defined filtering criteria.
• 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:

• For Mobiles
• DL %Resources and UL %Resources – The percentage of the
channel resource consumed by the user.
• For Sectors & Sites
• DL Connected Users
• Avg User Tput (DL) and Avg User Tput (UL)
• 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”.
• Peak Throughput Capacity (DL), Effective Throughput Capacity
(DL), Peak Throughput Capacity (UL), and Effective Throughput
Capacity (UL).
• Four Site charts (found on sheet “Site Charts”) show key statistics across all
sites of interest (which reflect filtering dynamically).
• DL & UL Peak Tputs
• DL & UL Avg User Tputs
• “%No Svc” & “%Res Sat”
• Connected Users
• Six Sector charts (found on sheet “Sector Charts”) show key statistics across
all sectors of interest (which reflect filtering dynamically).
• The four site charts generated at the sector level.
• DL & UL Traffic Load (%)
• UL Noise Rise (dB)
• A “Summary” sheet brings together key statistics. These statistics are
dynamically linked to reflect, in general, the average values across all filtered
rows among the Sites, Sectors, and Mobiles data. An example is provided in
the following figure.

Figure 199: Summary Statistics (post-processed)
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:
• “No Service” CINR distributions (DL and UL)
• CINR distributions for Connected Users (DL and UL)
• Bearer distributions (DL and UL)
• CTP (Channel Throughput) vs FB (Frequency Blocks allocated) (UL only)
• CTP (Channel Throughput) vs UTP (User Throughput) (DL and UL)
• CTP (Channel Throughput) vs %Res (%Resources) (DL and UL)

Figure 200: Key Mobile Chart Examples
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 statistic’s 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

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…".

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 all of the data (Ctrl-A) from the Geometry tab.
Overwrite with all the data previously copied from the other map (using Ctrl-V).

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.
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.

11. MIMO and TXAA Modeling

The purpose of this section of the document is to summarize the procedures for
modeling MIMO and TXAA with Motorola’s LTE products in Atoll. Although this
information is contained in other portions of this LTE RF System Design Procedure (e.g.
in sections for the specific input parameters), it is summarized here to show the overall
process for MIMO and TXAA modeling.
11.1. MIMO Modeling in Atoll
Atoll supports three TX Diversity/MIMO modes as follows:
TX Diversity: A Diversity Gain (dB) value from the Equipment MIMO interface is
applied to the C/(I+N) calculations.
SU-MIMO: A throughput gain related to CINR and is modified using a user-defined

capacity multiplier per clutter category. Within Atoll, the MIMO throughput gain related to
CINR is set through the Max MIMO Gain field in the MIMO Configurations interface. The
user-defined capacity multiplier is set per clutter category through the Clutter Classes
SU-MIMO Gain Factor parameter.
AMS: If the reference signal CINR is above the AMS & MU-MIMO Threshold (dB) from
the Cells interface, then the MIMO Gain curve from the Equipment MIMO interface is
applied to Tput calculations. If the reference signal CINR is below the AMS & MU-MIMO
Threshold (dB), then the Diversity Gain (dB) value from the Equipment MIMO interface
is applied to the C/(I+N) calculations.
Refer to Table 7 for the recommended setting for DL Diversity Support as a function of
transmission mode.
11.2. Overview of MIMO Settings

Several aspects of a MIMO system design that must be considered when setting the
input parameters and modeling approach are:
• Subscriber device MIMO capabilities (MIMO or None)
• Base station and subscriber MIMO configuration settings (both need to be
configured for MIMO in order for MIMO to be accounted for in the modeling)
• Number of MIMO transmit antennas at the base station

• Number of MIMO receive antennas at the subscriber device

• Threshold for switching between TX Diversity and SU-MIMO
The expected result of accounting for these MIMO parameters in the system design is:
• Increased downlink traffic channel per-user and per-sector throughput based on

the SU-MIMO parameters. This increase will depend on the level of interference
and scattering in the region.
11.3. MIMO Settings in Atoll

This section outlines the settings within Atoll that are used to account for TX Diversity
and SU-MIMO and points to the section in this document containing additional details.
1. Configure the number of AP MIMO transmit antennas in the Transmitters. See

Section 7.1.2.1.2 for further details.
2. Ensure that cell property parameters are set correctly.
a. Ensure that the CINR threshold for switching between TX Diversity and
SU-MIMO is set. This threshold is represented in Atoll as the AMS
Threshold in the cell properties. Further details can be found in Section
7.1.2.1.3.
b. Ensure that the DL Diversity Support is set correctly per Table 7.
3. Ensure that the MIMO Configurations table is properly set. See Section 7.2.3.4.2
for further information regarding MIMO Configurations settings.
a. Ensure the proper entry within the MIMO Configurations table for the
number of transmit and receive antennas (i.e. 2 eNB transmit and 2
subscriber receive antennas: the 2x2 case).
b. Ensure the SU-MIMO throughput gain related to CINR is set through
the Max MIMO Gain field in the MIMO Configurations interface.
c. Ensure the Diversity Gain is set correctly per Table 7.
4. Ensure the proper subscriber terminal settings for MIMO. See Section 7.3 for
further information.
a. Ensure that the subscriber terminal Antenna Diversity Support is set to
MIMO.
b. Ensure that the number of MIMO Rx antennas is set properly. Within
the Motorola template, the number of MIMO Rx antennas depends on
the terminal type and was set based on general assumption of two
receive antennas. See Section 6.6.2.

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.
11.4. TXAA Modeling in Atoll

TXAA for LTE is only available in the TDD product. This is because downlink
beamforming requires channel information that is measured on the uplink. This channel
information would not be valid for FDD because of the large difference in operating
frequency between the uplink and downlink for FDD.
Motorola’s approach to modeling TXAA in Atoll for LTE is to account for the expected
increase in CINR that is associated with beamforming. The Motorola template does not
inherently contain additional TXAA gain. Therefore, to account for TXAA gain, the
Diversity Gain (dB) field in the MIMO configuration interface can be adjusted by
increasing the default value by 2 – 5 dB, depending on the environment. 2 dB would be
appropriate for dense urban environments and 5 dB would be used for open areas.
Please refer to Section 7.2.3.4.2 for additional information on setting Diversity Gain.
Refer to Table 7 for recommended values of Diversity Gain for TM 7 that will reflect the
TxAA gain.

12. Incorporating Additional HARQ Gain in Atoll

This section describes a set of input parameters and procedures for modeling additional
HARQ gain in Atoll.
HARQ gain accounts for the benefit of retransmissions, where each retransmission
repeats the first transmission or part of it. The HARQ gain is obtained by combining the
first transmission with the retransmission.
The SNR values within ML-CAT and within the Motorola template for Atoll assumes a
level of HARQ gain that is associated with a 10% BLER threshold that assumes a single
HARQ re-transmission which results in an effective BLER of less than 1%.
There can be up to four retransmissions, such that additional HARQ gain can be
assumed. However, it is important to understand that additional HARQ gain will reduce
the cell edge data rates for MCS0.
12.1. Determining if Additional HARQ Gain is Required

As is discussed in the LTE ML-CAT User Guide, it is recommended that a link budget
design be done assuming no additional HARQ gain for the purposes of increasing the
coverage range (i.e. no HARQ gain beyond what is assumed in the SNR values). From
this initial design, obtain the range and edge data rates. If the resulting CINR coverage
in Atoll is less than the customer’s requirement, there will be a benefit (e.g. increase in
CINR coverage) if additional HARQ gain is added to the Atoll threshold for MCS0.
However, any additional HARQ gain will reduce the cell edge peak physical data rate
(as shown in the PostHARQ PHY data rates within ML-CAT), so this tradeoff needs to
be evaluated.
The following table shows the data rate reduction that is associated with different HARQ
gains:
Table 14: HARQ Gain Effective Data Rate Impact

Additional HARQ Gain Effective PHY Rate Retransmissions
0 91% 10%
0.5 83% 20%
1.0 78% 29%
1.5 73% 36%
2.0 70% 43%
2.6 66% 50%

12.2. Additional HARQ Gain Modeling Approach in Atoll

HARQ gain is only applied to the downlink and uplink traffic channels. If the design
scenario is being limited by one of the overhead channels, there will be no improvement
to the overall coverage of a site by adding HARQ gain.
Within Atoll, when analyzing the traffic channels, any additional HARQ gain needs to be
incorporated into the appropriate parameters so that it is accounted for in the results.
The details of these parameter adjustments are provided in the following subsections.
However, when analyzing non-traffic channels, these parameters are not adjusted for
the additional HARQ gain.
12.3. Accounting for HARQ Gain in Atoll

This section outlines the settings within Atoll that are used to account for additional
HARQ gain. The following subsections provide details regarding these settings.
For cases where traffic channel studies are being run:

1. Within Atoll, to see the affect of the additional HARQ gain on the downlink and
uplink traffic channels, the Bearer Threshold tables for MCS0 (i.e. the lowest
order modulation and coding scheme (QPSK 0.12)) need to be adjusted to
incorporate the additional HARQ gain. See Section 12.3.1 for further details.
2. When evaluating the images that are generated with the additional HARQ gain
incorporated, the image thresholds for MCS0 need to include this same
additional HARQ gain. See Section 12.3.2 for further details.
3. When additional HARQ gain is included in a study, the resulting throughput
images need to be adjusted to reduce the throughput for MCS0 accordingly. See
Section 12.3.3 for further details.
For cases where non-traffic channel studies are being run, since the additional HARQ
gain only impacts the traffic channels:
1. No adjustments are required to the Bearer Threshold tables to incorporate any
additional HARQ gain.
2. The image thresholds do not need to include this same additional HARQ gain.
3. No adjustments need to be made to the resulting throughput images to reduce
the throughput.
12.3.1. Adjusting the Bearer Threshold Values for Traffic Channel Studies
When running traffic channel studies, the MCS0 Bearer Threshold values need to be
adjusted to account for any additional HARQ gain that is to be included in the study.

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.
Figure 201: Bearer Threshold Information without Additional HARQ Gain
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.

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.

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).
Figure 203: Example Post-HARQ PHY Data Rate

13. References
Title Location/Version Date Author(s)

1. Atoll User Manual http://compass.mot.com/go/atolldo - Forsk
cs
2. Atoll Technical Reference Guide http://compass.mot.com/go/atolldo - Forsk
cs
3. LTE ML-CAT http://compass.mot.com/go/lteplan Aug-2009 LTE Planning and
R2.1.2 Design
4. LTE RF Planning Guide http://compass.mot.com/go/lteplan Aug-2009 LTE Planning and
Version 1.0 Design
5. LTE ML-CAT User Guide http://compass.mot.com/go/lteplan Aug-2009 LTE Planning and
Version 1.0 Design
6. Supplement – Atoll 2.8.1 Features http://compass.mot.com/go/31693 Jan-2010 LTE Planning and
for LTE and WiMAX RF System 6464 Design
Design Procedure
7. Supplement – Atoll 2.8.2 Features http://compass.mot.com/go/31693 Oct-2010 LTE Planning and
for LTE and WiMAX RF System 6464 Design
Design Procedure

14. Glossary
Acronym Meaning
AAS Adaptive Antenna System
AMS Adaptive MIMO Switching
AP EnodeB
BE Best Effort
BS Base Site
BSID Base Station ID
CATP Coverage Acceptance Test Plan
CDF Cumulative Distribution Function
CINR Carrier to interference plus noise ratio
CPE Customer Premises Equipment
CTP Channel Throughput
DAP Diversity EnodeB
DL Downlink
dB Decibel
dBi Decibels relative to an isotropic radiator
EFS Effective Faded Sensitivity
ERP Effective Radiated Power
GAP Ground mounted EnodeB
GSF Global Scaling Factor
IAP Intelligent ENodeB
Kbps Kilobits per second
LOS Line-of-sight
MAC Medium Access Control layer
MAP Mobile Application Part, Media Access Protocol
MaxTD Max Throughput Demand
Mbps Megabits per second
MCS Modulation and Coding Scheme
MIMO Multiple Input Multiple Output
MinTD Min Throughput Demand

MMSE Minimum Mean Square Error

MPR Modulation and coding Product
Mbits Megabits
NLOS Non-line-of-sight
nrtPS Non-Real Time Polling Service
PD Proportional Demand
PDU Protocol Data Unit
PF Proportional Fair
RLC Radio Link Control
RTG Receive Transition (or Time) Gap
TXAA Smart Antenna ENodeB
SDMA Spatial Division Multiple Access
SDU Service Data Unit
SM Spatial Multiplexing
SNR Signal to Noise Ratio
SISO Single Input Single Output
TDD Time Division Duplexing
TMA Tower Mounted Amplifier
TTG Transmit Transition (or Time) Gap
Tx Transmit
TxAA Transmit Adaptive Antenna
UL Uplink
VOIP Voice Over Internet Protocol

LTE RF System Design Procedure With - Atoll PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE RF System Design Procedure With - Atoll PDF

Uploaded by

Copyright:

Available Formats

LTE

RF System Design Procedure

Atoll Version 2.8.0

LTE PLANNING AND DESIGN

© Copyright 2010 Motorola, Inc. All Rights Reserved

This page is intentionally left blank.

Revision 1.3 iProtect: Internal Page 2

2. LTE RF LINK BUDGET ...................................................................................... 25

3. LTE SYSTEM CAPACITY CALCULATION ........................................................ 29

4. INSTALLING ATOLL .......................................................................................... 30

5. CREATING PROJECTS/DOCUMENTS IN ATOLL............................................ 34

Revision 1.3 iProtect: Internal Page 3

5.2.8. Managing Station Templates.................................................................... 49

6. IMPORTING GEOGRAPHIC DATA AND ANTENNA PATTERNS .................... 53

7. SETTING ATOLL SITE/NETWORK/SUBSCRIBER/CLUTTER CLASS INPUTS82

8. SETTING PROPAGATION INPUTS ................................................................ 160

Revision 1.3 iProtect: Internal Page 4

8.1.2. SPM Parameter Settings ........................................................................ 162

9. GENERATING COVERAGE STUDIES............................................................ 197

Revision 1.3 iProtect: Internal Page 5

10. CAPACITY ANALYSIS..................................................................................... 246

11. MIMO AND TXAA MODELING ........................................................................ 285

12. INCORPORATING ADDITIONAL HARQ GAIN IN ATOLL............................... 288

Revision 1.3 iProtect: Internal Page 6

13. REFERENCES................................................................................................. 293

14. GLOSSARY ..................................................................................................... 294

Revision 1.3 iProtect: Internal Page 7

Table 1: Recommended Workstation Configuration ...................................................... 30

Revision 1.3 iProtect: Internal Page 8

Figure 1: Budgetary Process Flow Chart...................................................................... 20

Figure 31: Clutter Heights ............................................................................................ 62

Revision 1.3 iProtect: Internal Page 10

Figure 64: Example Transmitters Table ..................................................................... 107

Revision 1.3 iProtect: Internal Page 11

Figure 97: Example Cells Table ................................................................................. 145

Revision 1.3 iProtect: Internal Page 12

Revision 1.3 iProtect: Internal Page 13

Figure 163: Import best bearer plot configuration........................................................ 223

Revision 1.3 iProtect: Internal Page 14

Figure 196: Density Map Properties ............................................................................ 267

Revision 1.3 iProtect: Internal Page 15

2.8.0 1.0.0 Aug 31-2009 SSE Released for general use

2.8.0 1.0.2 Sept 22-2009 SSE Updated UL bearer selection thresholds

2.8.02 1.2 Nov 2-2010 P&D Incorporated DL MIMO modeling (see

2.8.03 1.3 Dec 17-2010 P&D Modified reliable coverage assessment to

Document location: http://compass.mot.com/go/318588510

Revision 1.3 iProtect: Internal Page 16

1.1. LTE RF System Design Procedure

1.2. Procedure Flow Chart

Revision 1.3 iProtect: Internal Page 17

1.2.1. Budgetary RF System Design Process Flow

For details on the use of ML-CAT, see ML-CAT Guide document.

Revision 1.3 iProtect: Internal Page 18

sufficient surface area to accommodate four or more sites (10 Km2

A finite number of neighborhood definitions (5 to 10 definitions) should

1. The type of structures (residential, business, industrial, high-rise

Neighborhoods will only be defined where the user population is present.

Revision 1.3 iProtect: Internal Page 19

Figure 1: Budgetary Process Flow Chart

1.2.2. RF System Capacity Analysis

1. Calculate the number of users supported by each cell within a neighborhood

Revision 1.3 iProtect: Internal Page 20

2. Repeat step 1 for each neighborhood within the system.