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

Revision 1.3 iProtect: Internal

This page is intentionally left blank.



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 Release

Revision Date Author Description

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-CATML-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. http://compass.mot.com/go/310448858 (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 totalSubscribers supported

Review Results

Start

End

Calculate totalSubscribers supported

Review Results

Produce Report



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)

Make any required design adjustments

Run and analyze coverage study

Enter system/site parameters

N

B

Coverage Requirements

Met?

Y

Make any required design adjustments

Run and analyze coverage study

END

Enter system/site parameters

N

BB


Met?


Met?

Y



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

Hard disk space 10 GB free hard disk space More than 10 GB

(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:

sitesectorsitetosite

sectorsite

33

3

RRDISTANCE

RR

×=×=

×=

−−



Figure 16: Hexagon Radius for Site and Sector

Rsector

DISTANCE site-to-site Rsite

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. Navigate the directories and select the file named “index” located in the directory where the NetPlan LULC/Clutter data is stored for the current document. NOTE: NetPlan formatted data that is used in Hydra uses a file name of “d_index” for the terrain file and “l_index” for the clutter file. If this data is to be used in Atoll, both of these files need to be renamed to just “index”. This also requires that the files be put into two different directories, a terrain directory and a clutter directory, since the two files



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. Navigate the directories and select the file named “index” located in the directory where the NetPlan LULC/Clutter data is stored for the current document. Click the “Open” button to open the Data Types window.




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

The “MapProjectionFile” file is an ASCII file that contains geographic projection parameters for the NetPlan binary data.

l_mexico_mwz.bin 473149 483999 2151801 2166006 5



Figure 42: “MapProjectionFile” file

The “menu” file is an ASCII file that contains clutter codes and names for the NetPlan binary clutter data.

Figure 43: “menu” File Example

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.

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

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



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 SizePixel 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.500000XDIM 5.000000YDIM 5.000000BYTEORDER MLAYOUT BILNROWS 8200NCOLS 8800NBANDS 1NBITS 16

ULXMAP 459002.500000ULYMAP 4442997.500000XDIM 5.000000YDIM 5.000000BYTEORDER MLAYOUT BILNROWS 8200NCOLS 8800NBANDS 1NBITS 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 [email protected]). 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 [email protected]) or from CyberCity LLC (contact name Jacqui Swartz 310.760.2560 [email protected]). 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 [email protected]).

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

11

2233

44

11

2233

44

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

11

22

33

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

11

22

33

44

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

6

7

10

11

3

4

5

89

11

12

2

6

7

10

11

3

4

5

89

11

12

2

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 Product

eNB Tx Power per antenna

(dBm)

TX Combining

Gain

Max Power (dBm)

PDSCH Power (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

(Atoll v2.8.1) 37/63

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

11 44

55

22

33

11 44

55

22

33

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.

1

2

3

4

5

6

7

8



Note. 3. PUCCH Overhead is the number of resource blocks in the uplink that are used for the Physical Uplink Control Channel (PUCCH). The uplink demodulation and sounding reference signals consume a fixed amount of resources in the uplink. Their corresponding overheads are hard-coded in Atoll in accordance with the 3GPP specifications. However, the end user must directly enter the PUCCH overhead. The following table contains recommended typical values of PUCCH overhead as a function of bandwidth.

Table 5: PUCCH RB's Bandwidth

(MHz) PUCCH RB’s

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 1111 22 33 44 55 66 77 88 99 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 511 22 33 44 55

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

11 22 3311 22 33

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

0%

1%

2%

3%

4%

5%

6%

7%

8%

9%

0 5,000 10,000 15,000 20,000 25,000 30,000 35,000

CTP (kbps)

%R

es

%ResAvg %Res

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

0%

2%

4%

6%

8%

10%

12%

14%

16%

18%

20%

0 5,000 10,000 15,000 20,000 25,000 30,000 35,000

CTP (kbps)

%R

es

%ResAvg %Res

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

0

10

20

30

40

50

60

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000

CTP (kbps)

FB

FBAvg FB

UL CTP vs FB

0

10

20

30

40

50

60

0 2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,000

CTP (kbps)

FB

FBAvg FB

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

11 22 33 44

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 411 22 33 44

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

11 22 33 44 55

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

0.5

0.6

0.7

0.8

0.9

1.0

4.0 5.0 6.0 7.0 8.0 9.0 10.0

CINR (dB)

Effic

ienc

y (b

its/s

ymbo

l)

MPR

EFF

IdealMPR

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.

EFF = (1-10%) x Ideal MPR

EFF > MPR (negative BLER)



MIMO gain) is defined as the increase in channel capacity compared to a SISO system (i.e. the increase in throughput due to MIMO). When using the Motorola template, the Diversity gain field is used to represent Rx Diversity (MRC) gain. The structure of this MIMO tab can be illustrated further with an example. Take the case between a Frame Based eNB and a CPE subscriber. The Frame Based eNB has 2 transmission antennas and 2 reception antennas, while the CPE subscriber has 1 transmission antenna and 2 reception antennas, as seen in the figure below.

Figure 91: Example Downlink and Uplink Paths between eNB and CPE

Frame Based eNBExample 2 – TX antennas 2 – RX antennas CPE

Example 1 – TX antennas 2 – RX antennas

Downlink case: 2 TX antennas at eNB,2 RX antennas at sub

Uplink case: 1 TX antennas at sub,2 RX antennas at eNB

Frame Based eNBExample 2 – TX antennas 2 – RX antennas CPE

Example 1 – TX antennas 2 – RX antennas

Downlink case: 2 TX antennas at eNB,2 RX antennas at sub

Uplink case: 1 TX antennas at sub,2 RX antennas at eNB

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

66

77

55

11

22

4433

88

1010

1111

99

1212

66

77

55

11

22

4433

88

1010

1111

99

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

zyyzzxxzyxxyzyxxyz σσρσσρσσρσσσσ 2222222 +++++=

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:

( )( )( ) ( )( )( ) ( )( )( ) 4.78185.104.15.0285.1825.0204.1825.0285.104.18 2222 =−+++++=xyzσ84.8=xyzσ dB

If the CPEs are optimally placed:

( )( )( ) 24.6904.1825.0204.18 222 =++=xyσ

32.8=xyzσ 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 91 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 1Note 2

Note 3

Note 1Note 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 inside computation zone

sites outside the 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

Computation Zone

Focus Zone

Hot Spot Zones



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)

Area Reliability

Cell Edge Coverage

Probability

Standard Deviation:

From Model Standard

Deviation: C/I Lognormal

Fade Margin (CINR)

90% 76.6% 5.81 dB 1 dB 1 dB

95% 87.4% 9.16 dB 1.6 dB 1.6 dB

Note: 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) For the image to incorporate reliability, the “Shadowing taken into account” check box should be selected.

9.3.2.2. Coverage by C/(I+N) Level – DL and UL

The Coverage by C/(I+N) level images show the C/(I+N) for each pixel. This image can be run either for the downlink or uplink perspective. The system coverage is defined using the Peak RLC Throughput image (see Section 9.3.1.1). For the image to incorporate reliability, the “Shadowing taken into account” check box should be selected. For the downlink, Atoll calculates the best server for each pixel depending on the downlink signal level. Then it calculates the interference from other cells, and finally calculates the C/(I+N). The color of the pixel depicts the C/(I+N) level of that pixel. The following figure shows an example Coverage by C/(I+N) Level – DL image.



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)



For the image to incorporate reliability, the “Shadowing taken into account” check box should be selected. Running a Monte Carlo simulation using multiple drops can provide the UL noise rise required for each cell in a detailed system study (see Section 10.7.4). Refer to Table 11 for selecting the proper UL C/(I+N) threshold.

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: http://compass.mot.com/go/326569766 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

kT Downlink kTB Uplink kTB(dBm/Hz) (dBm) (dBm)

* 1.4 -174 15000 72 6 5 -113.7 -114.53 -174 15000 180 15 13 -109.7 -110.35 -174 15000 300 25 21 -107.5 -108.210 -174 15000 600 50 42 -104.5 -105.215 -174 15000 900 75 63 -102.7 -103.520 -174 15000 1200 100 84 -101.4 -102.2

Maximum UL

Occupied Resource

Blocks

Channel Bandwidth,

MHz

Resource element

Bandwidth, Hz

DL Occupied Resource Elements

Maximum Number of

UL Resource

Blocks

* 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 http://compass.mot-solutions.com/go/318588510. Refer to sheet “BST” (for Bearer Selection Thresholds).

Table 11: UL Effective SNR Values (i.e. bearer selection thresholds)

BEAREX INDEX Modulation PB3

VA30 &

VA30R1

30 QPSK 0.10 -0.088 0.612

31 QPSK 0.13 0.981 1.681

32 QPSK 0.16 1.743 2.409

33 QPSK 0.21 2.909 3.109

34 QPSK 0.25 4.235 5.134

35 QPSK 0.31 5.192 6.050

36 QPSK 0.37 5.950 6.687

37 QPSK 0.43 6.577 7.431

38 QPSK 0.49 7.145 8.068

39 QPSK 0.56 7.771 8.511

40 QPSK 0.62 8.285 8.921

41 16 QAM 0.31 8.285 8.921

42 16 QAM 0.35 8.993 9.688

43 16 QAM 0.40 9.857 10.405

44 16 QAM 0.45 10.516 11.114

45 16 QAM 0.50 11.383 12.032

46 16 QAM 0.54 12.097 12.322

47 16 QAM 0.57 12.393 12.634

48 16 QAM 0.63 12.899 13.306

49 16 QAM 0.69 13.676 14.263



50 16 QAM 0.75 14.634 15.160

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

Note: These UL values have been calibrated with Minisim simulations. The R282 template (Dec10) contains the bearer selection curves for all mobilities. Should an existing project need to be updated with the new curves, the complete set along with instructions for copying them into the project’s database can be found in the spreadsheet “AtollR282Params.xls” located at http://compass.mot-solutions.com/go/318588510. Refer to sheet “BST (UL)” (for Bearer Selection Thresholds).

9.4.2.3.4. Diversity Gain

Diversity gain is not included in the RSSI images (i.e. Effective Signal Analysis images). As mentioned previously, the diversity gain needs to be accounted for in the RSSI threshold value. In the downlink direction, the diversity gain is determined by the subscriber equipment and the receive diversity type that is supported by that equipment, as well as the MCS and channel profile assumptions. Similarly, for the uplink direction, the diversity gain is determined by the base station receive diversity type and the MCS and channel profile assumptions. UL Diversity gain is currently modeled in the Atoll LTE template as 10*Log10(Num Rx Antennas), so 3 dB gain for two-branch RX diversity, 6 dB for four-branch RX diversity, and 9 dB for eight-branch. For DL Diversity gain recommendations, refer to Table 7. (Receive diversity gain values are included in the Diversity Gain fields within the MIMO table of the LTE Equipment interface, which are incorporated in the C/(I+N) images.)

9.4.2.3.5. 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 (http://compass.mot.com/go/310448858).



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

5

3

7

6

2

4

1

55

33

77

66

22

44

11

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

Preamble Format Number of Allocated

Subframes

CP Duration (μs)

GT Duration (μs)

Max Delay Spread (μs) Maximum Cell

Radius (km)

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 (http://compass.mot.com/go/310442223).

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

Name FTP

Download

Video

Conf

Web

Browsing VoIP

Full

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 (kbps) 180 360 64 64 180 180 12.2 12.2 360 360

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

Application Throughput Offset (kbps) 0 0 0 0 0

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)

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.

2

1

4 5

6 7

8

9

10

3

9



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 (MCS 20, 16QAM 0.75)

29 (MCS 28, 64QAM 0.93)

Future 58 (MCS 28, 64QAM 0.77)

29 (MCS 28, 64QAM 0.93)

Note. 6. The Max Throughput Demand fields define, by direction, the maximum throughput that the service can demand.

Note. 7. The Min Throughput Demand fields define, by direction, the minimum throughput that the service can demand.

Note. 8. The Average Requested Throughput fields define, by direction, the average requested throughput. These values are used in the simulation during user distribution to calculate the number of users attempting a connection. For further explanation of how the Average Requested Throughput impacts simulations, refer to Figure 187, Note 4.

Note: In defining the services parameters Max Throughput Demand (MaxTD), Min Throughput Demand (MinTD), and Average Requested Throughput (ART), throughput values are specified. But, it is only in the scheduler definition that the layer to which these target throughputs apply is specified. This means that target throughputs can be specified at any layer within the services as long as the corresponding layer is identified in the scheduler. The choice must be consistent across all voice type services and across all data type services. Refer to the scheduler description for more detail (Section 7.2.2.4).



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)

NOTES:

Note. 1. The Name field allows the user to provide a name for the given User Profile.

1

2 3 5 6 7 4



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

1

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 21 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 the polygon within the map image (you might need to make it visible). Right-click properties Select all of the data (Ctrl-A) from the Geometry tab. Overwrite with all the data previously copied from the other map (using Ctrl-V).



OK. 7) Delete the user profile traffic map.

Right-click the user profile traffic map folder. Delete

8) Specify the user density value for the polygon set. Select the polygon within the map image (you might need to make it visible). Right-click properties Specify the Traffic Density field on the General tab.

Alternatively, open the Density values sub-folder under the user density traffic map. Right-click on the sub-folder and select Open Table. Specify the Traffic Density field within the table.



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

cs - Forsk

2. Atoll Technical Reference Guide http://compass.mot.com/go/atolldocs

- Forsk

3. LTE ML-CAT http://compass.mot.com/go/lteplanR2.1.2

Aug-2009 LTE Planning and Design

4. LTE RF Planning Guide http://compass.mot.com/go/lteplanVersion 1.0


5. LTE ML-CAT User Guide http://compass.mot.com/go/lteplanVersion 1.0


6. Supplement – Atoll 2.8.1 Features for LTE and WiMAX RF System Design Procedure

http://compass.mot.com/go/316936464

Jan-2010 LTE Planning and Design

7. Supplement – Atoll 2.8.2 Features for LTE and WiMAX RF System Design Procedure

http://compass.mot.com/go/316936464

Oct-2010 LTE Planning and Design



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

Documents

Transcript of LTE RF System Design Procedure with_Atoll.pdf