Cdma Rf Design v 6 1

Release 6.1

Table of Contents

CDMA RF System Design Procedure

1 - 3

1 - 3

1 - 5

1 - 51 - 51 - 5

- 6

- 7 - 71 - 81 - 81 - 91 - 91 - 9

- 9

0

- 11- 11 - 12 - 12

2

- 13

13

1 Introduction

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 RF System Design Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Link Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 NetPlan Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.4.1 NetPlan Inputs Based on the Link Budget . . . . . . . . . . . . . . . . .1.4.2 Optimizing Clutter Data and Antenna Patterns . . . . . . . . . . . . . .

1.5 Generate Propagation Studies and Verify Coverage . . . . . . . . . . . . . . 1

1.6 CDMA Simulation Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.6.1 Determine Traffic (Distribution) and Speed Maps . . . . . . . . . . . 11.6.2 System Level Simulator Parameters . . . . . . . . . . . . . . . . . . . . . .1.6.3 Site Level Simulator Parameters . . . . . . . . . . . . . . . . . . . . . . . . .1.6.4 Simulator Path Loss Creation . . . . . . . . . . . . . . . . . . . . . . . . . . .1.6.5 Modeling Inter-System Interference . . . . . . . . . . . . . . . . . . . . . .1.6.6 Neighbor List Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7 Running the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.8 Analyzing Simulator Outputs (Statistics and Images) . . . . . . . . . . . . . 1 - 11.8.1 Meeting Defined Requirements and Minimum System

Performance Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8.2 Analyzing Time-sliced Simulation Outputs . . . . . . . . . . . . . . . . 1 1.8.3 Treating Pilot Pollution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8.4 CDMA Statistical Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.9 Comparison of Simulator Coverage vs. Path Loss Only Coverage. . . 1 - 1

1.10 Final Design Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.11 Quick Guide to Contents of Each Chapter . . . . . . . . . . . . . . . . . . . . . . 1 -

iCDMA RF System Design ProcedureApr 2002

Table Of Contents - continued

2 - 3

- 4

- 4

- 52 - 8 - 10

2 - 11 - 12 - 16 - 20 - 21 - 21

4 - 25 - 26 - 29

4

3 - 3

- 33 - 33 - 6

- 15 - 16 - 163 - 18

19

2 Link Budgets and Associated NetPlan Inputs

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 RF Link Budget Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 RF Link Budget Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.4 RF Link Budget Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.1 Subscriber Unit Tx Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4.2 Antenna Gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.3 Penetration Losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4.4 Line Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.5 Base Station Rx Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.6 Interference Margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.7 Ambient Noise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.8 Shadow Fade Margin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.5 Determining NetPlan Inputs to Estimate Coverage . . . . . . . . . . . . . . . 2 - 22.5.1 Example Calculations of NetPlan Values . . . . . . . . . . . . . . . . . . 22.5.2 Entering NetPlan Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.5.3 NetPlan Image Parameters and Multiple Level Plots . . . . . . . . . 2

2.6 Utilizing Link Budget Assumptions in Simulations . . . . . . . . . . . . . . . 2 - 3

3 Optimizing Clutter Data and Antenna Patterns

3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Clutter Code Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2.1 Brief Background on Clutter Codes . . . . . . . . . . . . . . . . . . . . . .3.2.2 Altering Clutter Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Antenna Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3.1 Antenna Pattern Distortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3.2 Proposed Methods to Account for Ground Clutter Reflections. . 33.3.3 Issues Regarding the Above Proposed Methods . . . . . . . . . . . . .

3.4 Clutter Environment Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 -

ii CDMA RF System Design Procedure Apr 2002


4 - 3

4 - 3

4 - 64 - 6

4 - 6

4 - 74 - 8

5 - 3

5 - 6 - 7 - 9

- 11 15 16 - 194- 26- 29- 38 38- 39 - 40 - 4246 48

- 4950 - 52- 58 - 59- 60

5 - 61

4 Verify Coverage and Identify Problem Areas

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 NetPlan Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Existing System Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.1 Generating Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.2 Verifying Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 New System Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.4.1 Placing Cells and Generating Coverage . . . . . . . . . . . . . . . . . . .

5 Traffic (Distribution) and Speed Maps

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Traffic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2.1 Creating the Carrier Independent Traffic (Distribution) Map . . . 5

5.2.1.1 Using Polygons With Traffic Data . . . . . . . . . . . . . . . . . . . . . . 55.2.1.2 Using Existing System Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55.2.1.3 New CDMA System With Projected Traffic . . . . . . . . . . . . . . . . . 5 -5.2.1.4 CDMA System with Commercial Traffic . . . . . . . . . . . . . . . . . . . 5 -5.2.1.5 Importing Traffic Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55.2.1.6 Application of Exclusion Mask for Traffic Distribution . . . . . . . 5 - 25.2.1.7 Weighting Traffic By Roads and Clutter Types . . . . . . . . . . . . . . . 5 5.2.1.8 Viewing Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.2.2 Determining Multiple Carrier Requirements. . . . . . . . . . . . . . . . 5 5.2.2.1 Multi-Carrier RF Design Methodology . . . . . . . . . . . . . . . . . . . . . 5 -5.2.2.2 Determining the Number of Additional Carriers . . . . . . . . . . . . . . 5 5.2.2.3 Selecting Sites to Receive the Additional Carrier . . . . . . . . . . . . . 55.2.2.4 Inter-Carrier Hard Handoff Management . . . . . . . . . . . . . . . . . . . 55.2.2.5 Choosing MAHHO or DAHHO for Transition Zone Sites . . . . . . 5 -

5.2.3 Multiple Carrier - Traffic Carrier Map Set . . . . . . . . . . . . . . . . . 5 -5.2.3.1 Multi-Carrier Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2.3.2 TCMS Traffic Distribution Algorithm . . . . . . . . . . . . . . . . . . . . . . 5 - 5.2.3.3 Creating the Traffic Carrier Map Set . . . . . . . . . . . . . . . . . . . . . . . 55.2.3.4 Displaying and Validating the TCMS . . . . . . . . . . . . . . . . . . . . . . 5 5.2.3.5 Using the TCMS in Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55.2.3.6 Modifying the TCMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.3 Speed Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iiiCDMA RF System Design ProcedureApr 2002


6 - 3

- 3 - 36 - 5 - 6

6 - 8 - 9 - 12 - 17- 17 - 23 - 25

- 25 - 38 - 41 - 44

7 - 3

7 - 37 - 57 - 8

8 - 3

- 3

4

- 5

8

6 Setting Simulator Input Parameters - System Level

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Setting the Simulation Input Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 6.2.1 Defining Carrier Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.2.2 Defining the CDMA Parameters . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.2.1 CDMA Parameters - Simulation Model Tab . . . . . . . . . . . . . . . . . . 66.2.2.2 CDMA Parameters - Radio Access Network Tab . . . . . . . . . . . . . .

6.2.2.2.1 Configuration Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.2.2.2.2 Supplemental Channels Tab . . . . . . . . . . . . . . . . . . . . . . 6

6.2.2.3 CDMA Parameters - Data Services Tab . . . . . . . . . . . . . . . . . . . . . 66.2.2.3.1 Call Models Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2.2.3.2 TCP Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

6.2.2.4 CDMA Parameters - Subscribers Tab . . . . . . . . . . . . . . . . . . . . . . . 66.2.2.4.1 Defining Subscriber Classes. . . . . . . . . . . . . . . . . . . . . . 66.2.2.4.2 Assigning Traffic to the Subscriber Classes. . . . . . . . . . 6

6.2.2.5 CDMA Parameters - RF Environment Tab . . . . . . . . . . . . . . . . . . . 66.2.2.6 CDMA Parameters - Images Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

7 Setting Simulator Input Parameters - Site Level

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Edit Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7.2.1 Antenna Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7.2.2 Carrier Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 Simulator Path Loss Creation

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2 NetPlan Path Loss File Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

8.3 NetPlan Path Loss (CDMA Antenna Gain) Image Display . . . . . . . . . 8 -

8.4 Creating an Exclusion Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

8.5 Application of Exclusion Mask for Generating Images . . . . . . . . . . . . 8 -

iv CDMA RF System Design Procedure Apr 2002


9 - 3

9 - 3 - 4 - 4 - 5 - 5 - 6- 6 - 79 - 7

9 - 7

9 - 7

9 - 9

- 15 - 17 28- 30 - 32

- 34 - 389 - 41 43- 44 - 519 - 53 - 54 - 55 - 55 - 59 - 61 - 64 - 67 - 69 - 72 - 75 - 76 - 76 - 77 - 789 - 79- 79 - 80- 80

9 NetPlan CDMA Simulator Statistical Output and Analysis

9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2 NetPlan Statistics Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.2.1 CellStat_XX (IS-95 and IS-2000 1X non time-sliced) . . . . . . . . 99.2.2 MobileStat_XX (IS-95 and IS-2000 1X non time-sliced). . . . . . 99.2.3 CellStatTS_XX and CellStatTSRev_XX (IS-2000 1X time-sliced) 99.2.4 MobileStatTS_XX (IS-2000 1X time-sliced) . . . . . . . . . . . . . . . 99.2.5 SectorTputStat_XX (IS-2000 1X time-sliced) . . . . . . . . . . . . . . 99.2.6 MobileTputStat_XX (IS-2000 1X time-sliced). . . . . . . . . . . . . . 9 9.2.7 GlobalStatTS_XX (IS-2000 1X time-sliced) . . . . . . . . . . . . . . . 99.2.8 SectorMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.2.9 CallModelMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.3 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4 Data Graph Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5 Statistical Analysis Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.1 NetPlan Raw Statistics Definitions . . . . . . . . . . . . . . . . . . . . . . . 99.5.2 IS-2000 1X Time-Sliced Simulation Warm-up Time . . . . . . . . . 9 -9.5.3 IS-2000 1X Time-Sliced Simulation Length. . . . . . . . . . . . . . . . 9 9.5.4 RF Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.4.1 RF Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.4.2 Walsh Code Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.4.3 Reverse Noise Rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.4.4 FWD & REV Subscriber Class FER Distribution . . . . . . . . . . . . . 9 -9.5.4.5 Soft Handoff Factor and Soft + Softer Handoff Factor . . . . . . . . . 9 9.5.4.6 Pilot Ior/Ec Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.4.7 Reverse Saturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.4.8 Blocked Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.5 RF Voice and Data Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.1 Total Erlangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.2 Active Erlangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.3 Bursting Erlangs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.4 End User Throughput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.5 Sector Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.6 Effective Sector Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.7 Data Rate Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.8 High Speed Channel Request Failure Probability . . . . . . . . . . . . . 99.5.5.9 SCH Limit Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.6 Data Call Model Characterization . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.1 Think Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.2 Download Size and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.3 Reverse Request Size and Time. . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.6.4 Forward Data Activity Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.6.5 Reverse Data Activity Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.6 Probability of Going Dormant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

vCDMA RF System Design ProcedureApr 2002


- 81- 81 - 81 - 81 - 82 - 84

9 - 86 - 87 - 88

- 97 - 98 - 98

- 99- 101- 103 - 104 - 104 - 106

0 - 3

- 3

0 - 50 - 5

10 - 6 - 6

0 - 7

0 - 8

1 - 311 - 31 - 7

1 - 81 - 9

1 - 11 - 12 - 13 - 14 - 15 - 17

9.5.6.7 Length of the Dormant Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.8 Think Time While Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.6.9 Fraction of Data Subscribers Who are Dormant . . . . . . . . . . . . . . . 9

9.5.7 Simulation Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.7.1 Subscriber Speed Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.8 Channel Card Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.8.1 General Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.8.2 IS-95A Channel Card Determination . . . . . . . . . . . . . . . . . . . . . . . 99.5.8.3 IS-2000 High Speed Packet Data Channel Card Determination . . . 9

9.5.9 Power Amplifier Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.9.1 PA Equipment Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.9.2 Simulator Power Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.9.3 CDMA Signal Power Distribution Characteristics . . . . . . . . . . . . . 9 9.5.9.4 Comparing Power Requirements to BTS Specifications. . . . . . . . . 9

9.5.10 IS-2000 Backhaul Sizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.10.1 General Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.10.2 IS-2000 Packet Pipe Size Determination. . . . . . . . . . . . . . . . . . . . . 99.5.10.3 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

10 NetPlan Cell/Mobile Analysis

10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

10.2 Cell/Mobile Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

10.3 Mobile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110.3.1 Handoff Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110.3.2 Server Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10.3.3 Mobile Marker Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

10.4 Cell Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

10.5 Edit Coloring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

11 NetPlan CDMA Simulator Images Output and Analysis

11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.1 Image Creation and the Image Probe . . . . . . . . . . . . . . . . . . . . .11.1.2 Image Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

11.2 Simulator Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.1 Best Ec/Io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.2 Best Ec/Io Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3 Nth Best Ec/Io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.4 Nth Best Ec/Io Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.5 Pilots > T-DROP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.6 Soft Handoff State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.7 Forward Required Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

vi CDMA RF System Design Procedure Apr 2002


1 - 19 - 20 - 22

1 - 231 - 24 - 26 - 271 - 28 - 31

2 - 3

- 3

2 - 52 - 52 - 712 - 8

- 8 - 9 - 10

14 - 15 - 16

)

3 - 3

- 43 - 63 - 93 - 18

- 193 - 213 - 21 - 22

3 - 24

11.2.8 Reverse Required Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.9 Forward TCH Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.10 Forward Achieved FER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.11 Reverse Achieved FER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.12 Forward F Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.13 Mobile Received Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.14 Pilot Pollution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.15 Supplemental Channels (HSPD Supp Chnl) . . . . . . . . . . . . . . . . 111.2.16 IS-2000 Achieved Data Rate Image (Active Probe) . . . . . . . . . . 11

12 Treating Pilot Pollution

12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

12.2 The Pilot Pollution Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

12.3 NetPlan Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 CDMA Image Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 NPINIT File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Creating Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12.4 Analysis of Output Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.4.1 Viewing the Pilot Pollution Image. . . . . . . . . . . . . . . . . . . . . . . . 1212.4.2 Data Query - Pilot Pollution Sites . . . . . . . . . . . . . . . . . . . . . . . . 12

12.5 Correcting Pilot Pollution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 -12.5.1 Pilot Pollution Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.5.2 Pilot Pollution Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

13 NetPlan CDMA Composite & Statistical Images (Coverage vs. Path Loss

13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

13.2 CDMA Composite Images & Coverage Plots . . . . . . . . . . . . . . . . . . . . 13 13.2.1 CDMA Composite Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Using the CDMA Composite Images Feature. . . . . . . . . . . . . . . 113.2.3 Simulator Coverage vs. Path Loss Coverage. . . . . . . . . . . . . . . . 1

13.3 CDMA Statistical Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.3.1 Uses For Average Statistical Images . . . . . . . . . . . . . . . . . . . . . . 113.3.2 Uses For Standard Deviation Statistical Images . . . . . . . . . . . . . 113.3.3 Using the CDMA Statistical Images Feature . . . . . . . . . . . . . . . 13

13.4 Composite Ec/Io and Subscriber Unit Transmit Power . . . . . . . . . . . . 13 - 213.4.1 Using the CDMA Composite Images Feature. . . . . . . . . . . . . . . 13

viiCDMA RF System Design ProcedureApr 2002


- 29 - 29 - 30

31 38

4 - 3

- 3 - 3

4 - 9 - 9

- 10

- 10

- 11

- 3

- 81 - 91 - 9

- 9

- 32 - 42 - 62 - 8

13.5 Useful Shell Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313.5.1 Pollution-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313.5.2 Ec/Io-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

13.6 Verifying Inter-Carrier Transition Zone Coverage . . . . . . . . . . . . . . . 13 - 3113.6.1 Verifying MAHHO Transition Zone Coverage . . . . . . . . . . . . . . 13 -13.6.2 Verifying DAHHO Transition Zone Coverage . . . . . . . . . . . . . . 13 -

14 CDMA Handoff Candidates & PN Offsets

14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

14.2 CDMA Handoff Candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.2.1 Automatic Handoff List Generation . . . . . . . . . . . . . . . . . . . . . . 1414.2.2 Manual Handoff List Generation. . . . . . . . . . . . . . . . . . . . . . . . . 114.2.3 Manual Handoff List Editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.2.4 Applying a Handoff List to the Simulation . . . . . . . . . . . . . . . . . 14 14.2.5 Reviewing Candidate List Statistics in the

Operational Analysis Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

14.3 PN Offset Capabilities of NetPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

APPENDICES:

A1 Tower Top Amplifiers - Design Considerations

A1.1 Impact of a Tower Top Mounted Amplifierto the RF Link Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1

A1.2 Incorporating a Tower Top Amplifier into theNetPlan CDMA Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1 A1.2.1 Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA1.2.2 Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A1.3 Benefits and Drawbacks of TTAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1

A2 Atypical Cell Site Configurations

A2.1 Implementation of an Omni Siteas a pseudo two-sector Highway Site . . . . . . . . . . . . . . . . . . . . . . . . . . . A2A2.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA2.1.2 Antenna Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA2.1.3 NetPlan Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

viii CDMA RF System Design Procedure Apr 2002


3 - 3

- 3 - 43 - 4

53 - 53 - 5

3 - 53 - 53 - 63 - 73 - 73 - 73 - 7

3 - 73 - 8 - 9 - 9

- 11 - 12

- 1314- 14

1415- 15

5 - 16 - 17 - 17 - 17 - 17- 18 - 18 - 18

A3 WiLL System Design

A3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A3.2 Subscriber Unit (FWT) Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 A3.2.1 In-Building FWT Antenna Placement. . . . . . . . . . . . . . . . . . . . . A3A3.2.2 External FWT Antenna Placement . . . . . . . . . . . . . . . . . . . . . . . A

A3.3 Link Budget Differences for a Fixed System Versus a Mobile System A3 - A3.3.1 Frequency Band. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.2 Vocoder Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.3 Subscriber Unit Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.4 Subscriber/FWT Antenna Gain . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.5 Subscriber Unit Line Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.6 Body Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.7 Vehicle Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.8 Building Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.9 Base Station Antennas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.10 Base Station Sensitivity - Eb/No . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.11 Interference Margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.12 Fade Margin/Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.3.13 Example Fixed Subscriber Link Budget . . . . . . . . . . . . . . . . . . . A3

A3.4 Determining NetPlan Inputs from Link Budgets . . . . . . . . . . . . . . . . . A3 - 11

A3.5 NetPlan Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.5.1 Propagation Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3

A3.6 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.6.1 CDMA WiLL Call Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 - A3.6.2 Impact of System Configuration on Capacity . . . . . . . . . . . . . . . A3

A3.7 Traffic Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 -A3.7.1 Uniform Versus Non-Uniform Distribution . . . . . . . . . . . . . . . . A3 - A3.7.2 Generating a Traffic Distribution Map . . . . . . . . . . . . . . . . . . . . A3

A3.8 Simulator Input Parameter Differences . . . . . . . . . . . . . . . . . . . . . . . . A3 - 1A3.8.1 Antenna Gain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.2 Penetration Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.3 Fading Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.4 Maximum Reverse Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.5 Speed Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.6 Traffic Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 A3.8.7 Subscriber Unit Noise Figures. . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.8 Probe Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3

ixCDMA RF System Design ProcedureApr 2002


- 20

4 - 34 - 4

4 - 8 - 10- 13

14- 14 - 17 - 18 23 - 23

- 24- 254 - 30- 33

- 35

43- 43- 44- 44 - 45

- 45- 46

46- 46 - 52 - 54 - 56

A3.9 NetPlan CDMA Simulator Statistical Output for Fixed Systems . . . . A3 - 19

A3.10 NetPlan CDMA Simulator Images Output for Fixed Systems . . . . . . A3 - 19

A3.11 WiLL Design Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3

A4 Data Services System Design

A4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA4.1.1 Fundamental and Supplemental Channels. . . . . . . . . . . . . . . . . . AA4.1.2 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA4.1.3 Supplemental Channel Allocation. . . . . . . . . . . . . . . . . . . . . . . . A4A4.1.4 RF Channel Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4

A4.2 Link Budget Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 -A4.2.1 IS-95B Link Budget Considerations . . . . . . . . . . . . . . . . . . . . . . A4 A4.2.2 IS-2000 Link Budget Considerations . . . . . . . . . . . . . . . . . . . . . A4A4.2.3 General HSPD Design Considerations . . . . . . . . . . . . . . . . . . . . A4A4.2.4 Determining NetPlan Inputs from Link Budgets. . . . . . . . . . . . . A4 -A4.2.5 NetPlan Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4

A4.3 Call Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4A4.3.1 General Attributes of the Data Call Model . . . . . . . . . . . . . . . . . A4 A4.3.2 Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA4.3.3 Example Call Model for a Given Data Service . . . . . . . . . . . . . . A4 A4.3.4 Translation of Call Model Information into

Simulation Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4

A4.4 Simulation Input Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 -A4.4.1 Radio Access Network - Configuration. . . . . . . . . . . . . . . . . . . . A4 A4.4.2 Radio Access Network - Supplemental Channels [IS-2000 only] A4 A4.4.3 Data Services - Call Models [IS-2000 only] . . . . . . . . . . . . . . . . A4 A4.4.4 Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4A4.4.5 Supplemental Channel Image Parameter [IS-95B only] . . . . . . . A4A4.4.6 IS-2000 Achieved Data Rate Image [IS-2000 only] . . . . . . . . . . A4

A4.5 Simulation Output Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 -A4.5.1 IS-95B Statistical Output and Analysis. . . . . . . . . . . . . . . . . . . . A4 A4.5.2 IS-2000 Statistical Output and Analysis . . . . . . . . . . . . . . . . . . . A4A4.5.3 IS-95B HSPD Images Output and Analysis . . . . . . . . . . . . . . . . A4A4.5.4 IS-2000 Images Output and Analysis (HSPD) . . . . . . . . . . . . . . A4

x CDMA RF System Design Procedure Apr 2002


- 3

- 45 - 5 - 6

- 8

10

- 3

- 3

- 36 - 36 - 56 - 5

- 5

7 - 3

- 3

- 4

- 5

- 6

- 11- 11 - 12- 14

- 15

A5 Application Data Delivery Service Considerations

A5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5

A5.2 ADDS Over the Traffic Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5 A5.2.1 ADDS Subscriber Class Erlangs . . . . . . . . . . . . . . . . . . . . . . . . . AA5.2.2 ADDS Subscriber Class Activity Factors . . . . . . . . . . . . . . . . . . A5

A5.3 ADDS Over the Traffic Channel (during an active call) . . . . . . . . . . . A5 - 8A5.3.1 ADDS Activity Factor Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . A5

A5.4 Evaluating the ADDS load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5 -

A6 Running canal.pl

A6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6

A6.2 Loading canal.pl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6

A6.3 Running canal.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6A6.3.1 Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA6.3.2 Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA6.3.3 Output files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A6.4 canal.pl Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6

A7 Modeling Inter-System Interference

A7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A7.2 Inter-System Interference Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . A7

A7.3 Generate CDMA ISI Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7

A7.4 Inter-System Interference Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . A7

A7.5 Interpreting Simulator Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7

A7.6 Analysis of System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7 A7.6.1 Drive Test Data - New AMPS ERP. . . . . . . . . . . . . . . . . . . . . . . A7 A7.6.2 AMPS Channelization - Kavg - Samps . . . . . . . . . . . . . . . . . . . . A7A7.6.3 Additional Images Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . A 7A7.6.4 Corrective - Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A7

xiCDMA RF System Design ProcedureApr 2002


This page left intentionally blank

xii CDMA RF System Design Procedure Apr 2002

Release 6.1

List of Figures


1 - 4 - 13 - 15 - 272 - 28 - 29 - 30 - 31 - 323 - 7 - 10 - 123 - 143 - 15 - 17

- 174 - 4

4 - 55 - 7 - 10 - 12

5 - 135 - 14 - 22 - 23 - 25 - 27 - 30- 315 - 31- 32- 33 33

- 34 - 35 36- 36

Figure 1-1: Procedure Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 2-1: Typical Components in the RF Cabling Run. . . . . . . . . . . . . . . . . 2Figure 2-2: SC6xx Two Carrier Site with the Outdoor Pilot Beacon. . . . . . . . 2Figure 2-3: Edit Site - Pull Down Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Figure 2-4: Edit Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 2-5: Edit Site - Rv ERP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Figure 2-6: Output Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Figure 2-7: Minimum Signal Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Figure 2-8: Setting Image Cutoff Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Figure 3-1: Edit Land Use/Cover Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 3-2: Editing Clutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Figure 3-3: Displaying Land Use/Land Cover . . . . . . . . . . . . . . . . . . . . . . . . . 3Figure 3-4: Selecting Geo Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 3-5: Assigning Geo Sets to Antennas . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 3-6: Example Manufacturer’s Antenna Pattern. . . . . . . . . . . . . . . . . . . 3Figure 3-7: Example Pattern with Front-to-Back Ratio Modified . . . . . . . . . . 3 Figure 4-1: Propagation Boundaries and Parameter Set. . . . . . . . . . . . . . . . . .Figure 4-2: Hexagon Cell Radius and Distance . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-1: Traffic Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-2: Create Map from Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-3: Edit Traffic Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-4: Traffic Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-5: Create Map from Parameter Set. . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-6: Import Traffic Parameters Menu . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-7: Importing Traffic Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-8: Select Exclusion Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-9: Weighted Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-10: Display Image - Offered Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-11: Offered Traffic Image Utilizing Best Ec/Io Server/Sector . . . . . . 5 Figure 5-12: Select Color Intervals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-13: Offered Traffic Displayed with Arcs . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 5-14: Numeric Display of Offered Traffic . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 5-15: Offered Traffic Image Combined with Numeric Display . . . . . . . 5 -Figure 5-16: Viewing Traffic Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-17: Example Traffic Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-18: Example Traffic (Distribution) Map Coloring. . . . . . . . . . . . . . . . 5 -Figure 5-19: Example Traffic Map Given More Weighted Clutter . . . . . . . . . . 5

xiiiCDMA RF System Design ProcedureApr 2002

List of Figures - continued

- 38 - 42 - 43 - 45 - 46 - 47

- 515 - 52 - 53

- 54- 55 - 57 - 58- 605 - 62

5 - 636 - 46 - 5

6 - 6 - 9

- 13 - 18

- 20

- 23 - 24

6 - 26 - 27 - 32 - 35 - 36

6 - 376 - 38 - 426 - 447 - 37 - 47 - 5

7 - 67 - 77 - 9 - 10

Figure 5-20: Proper Carrier Deployment - Cn . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-21: Improper Carrier Deployment - Cn . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-22: Corrected Carrier Deployment - Cn. . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-23: Carrier Deployment - Cn Beyond Estimated Growth . . . . . . . . . . 5Figure 5-24: MAHHO Pilot Beacon Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-25: DAHHO Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-26: TCMS Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-27: TCMS Creation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-28: Un-constrained Ec/Io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-29: Constraining Polygon for Cn using MAHHO . . . . . . . . . . . . . . . . 5 Figure 5-30: Constraining Polygon for Cn using DAHHO . . . . . . . . . . . . . . . . 5 Figure 5-31: Traffic Carrier Map Set Dialog Box . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-32: TCMS Layer Viewing Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 5Figure 5-33: AIM build.report Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 5-34: Create Speed Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 5-35: Display Image - Speed Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6-1: Carrier Table Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6-2: CDMA Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6-3: CDMA Parameters - Simulation Model . . . . . . . . . . . . . . . . . . . .Figure 6-4: CDMA Parameters - Radio Access Network - Configuration Tab 6Figure 6-5: CDMA Parameters - Radio Access Network - Supplemental

Channels Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Figure 6-6: Call Model State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Figure 6-7: CDMA Parameters - Data Services - Call Models Tab

(left portion of screen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Figure 6-8: CDMA Parameters - Data Services - Call Models Tab

(right portion of screen) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Figure 6-9: CDMA Parameters - Data Services - TCP Tab . . . . . . . . . . . . . . . 6Figure 6-10: Access to Subscriber Class Editor . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6-11: Subscriber Class Editor - left portion of the sliding screen . . . . . . 6Figure 6-12: Subscriber Class Editor - middle portion of the sliding screen . . . 6Figure 6-13: Subscriber Class Editor - right portion of the sliding screen. . . . . 6Figure 6-14: Normal Speed Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Figure 6-15: Speed List Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6-16: CDMA Parameters - Subscribers. . . . . . . . . . . . . . . . . . . . . . . . . .Figure 6-17: CDMA Parameters - RF Environment. . . . . . . . . . . . . . . . . . . . . . 6Figure 6-18: CDMA Parameters - Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 7-1: Edit Site - Pull Down Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 7-2: Edit Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 7-3: Edit Site Antenna Parameters - Area - B (view 1). . . . . . . . . . . . .Figure 7-4: Selecting Parameter Sets and Geo Sets . . . . . . . . . . . . . . . . . . . . .Figure 7-5: Edit Site Antenna Parameters - Area - B (view 2). . . . . . . . . . . . .Figure 7-6: Edit Site Carrier Parameters - Area - C (view 1) . . . . . . . . . . . . . .Figure 7-7: Edit Site Carrier Parameters - Area - C (view 2) . . . . . . . . . . . . . . 7

xiv CDMA RF System Design Procedure Apr 2002


- 138 - 48 - 58 - 78 - 89 - 89 - 9 - 10

9 - 119 - 129 - 129 - 139 - 139 - 149 - 149 - 28 - 29 - 309 - 31 - 32 - 399 - 419 - 42 - 44

9 - 46 - 56

9 - 71 - 72 - 83 - 99

0 - 410 - 510 - 60 - 610 - 70 - 81 - 311 - 411 - 511 - 811 - 91 - 111 - 121 - 13

Figure 7-8: Edit Site Carrier Parameters - Area - C (view 3) . . . . . . . . . . . . . . 7Figure 8-1: Display CDMA Path Loss Images. . . . . . . . . . . . . . . . . . . . . . . . .Figure 8-2: CDMA Antenna Gain Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 8-3: Creating Exclusion Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 8-4: Select Exclusion Mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-1: Reports - CDMA Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-2: Open Data Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-3: Load Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 9-4: Select Graph Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-5: Graph - 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-6: Open Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-7: NetPlan Graph Properties - 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-8: NetPlan Graph Properties - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-9: Graph - 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-10: NetPlan Graph Properties - 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-11: FwdBurstTot versus ElapsedTime. . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-12: Warm-up Time Estimation (Example 1) . . . . . . . . . . . . . . . . . . . . 9Figure 9-13: Warm-up Time Estimation (Example 2) . . . . . . . . . . . . . . . . . . . . 9Figure 9-14: Mean System Sector Throughput Per Second . . . . . . . . . . . . . . . .Figure 9-15: Example Spreadsheet Computation of Normal Confidence Interval 9Figure 9-16: Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 9-17: Reverse Noise Rise Versus Percent Load.. . . . . . . . . . . . . . . . . . .Figure 9-18: Noise Rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-19: Mobile Class FER CDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 9-20: SHO Factor (JMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-21: NumMob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 9-22: End User Throughput Per Frame . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 9-23: Effective Sector Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 9-24: Speed Distribution (JMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 9-25: FwdPwrTot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 10-1: Cell/Mobile Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 10-2: Handoff Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 10-3: Server Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 10-4: Mobile Marker Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 10-5: Cell Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 10-6: Edit - Coloring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-1: CDMA Parameters / Non Time-Sliced . . . . . . . . . . . . . . . . . . . . . 1Figure 11-2: Create Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 11-3: Image Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 11-4: Display Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 11-5: Best Ec/Io. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 11-6: Best Ec/Io Server Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-7: 2nd Best Ec/Io Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-8: 3rd Best Ec/Io Server Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

xvCDMA RF System Design ProcedureApr 2002


- 141 - 151 - 171 - 19 - 20

1 - 221 - 231 - 241 - 26 - 27

1 - 291 - 301 - 321 - 33 - 34 - 352 - 42 - 62 - 72 - 82 - 9 - 102 - 112 - 122 - 13 - 15 - 173 - 53 - 83 - 93 - 12 - 13

3 - 13 - 133 - 153 - 16 - 17 - 20 - 22 - 243 - 27 - 28 - 32

3 - 33

Figure 11-9: Pilots > T-DROP Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 11-10: Soft Handoff State Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-11: Forward Required Power Image . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-12: Reverse Required Power Image. . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-13: Forward TCH Threshold Image. . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 11-14: Forward Achieved FER Image . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-15: Reverse Achieved FER Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-16: Forward F Factor Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-17: Mobile Received Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-18: Pilot Pollution Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 11-19: CDMA Parameters / Supplemental Channel Image . . . . . . . . . . . 1Figure 11-20: HSPD Supp Chnl Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 11-21: CDMA Parameters / Achieved Data Rate Image . . . . . . . . . . . . . 1Figure 11-22: Image Create - Achieved Data Rate Image . . . . . . . . . . . . . . . . . . 1Figure 11-23: Upper Bound Data Rate Image (Traffic Load w/FCHs only) . . . . 11Figure 11-24: Lower Bound Data Rate Image (Traffic Load w/SCHs) . . . . . . . . 11Figure 12-1: Pilot Pollution Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 12-2: CDMA Image Parameters Relating to Pilot Pollution. . . . . . . . . . 1Figure 12-3: NPINIT Entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 12-4: Creating Images for Pilot Pollution Studies . . . . . . . . . . . . . . . . . 1Figure 12-5: Pilot Pollution Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 12-6: Pilot Pollution Image Close - Up. . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 12-7: Launching Data Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 12-8: Data Query Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 12-9: Data Query Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 12-10: Pilot Pollution Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 12-11: Pilot Pollution Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 13-1: TCH Max Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-2: CDMA Composite Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-3: CDMA Composite Images Window . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-4: Reverse Required Power Image. . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-5: Forward TCH Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-6: Forward and Reverse Achieved FER. . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-7: Pilot Pollution (Mobile Received Power) . . . . . . . . . . . . . . . . . . . 13Figure 13-8: Display Coverage Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-9: Composite Coverage Image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-10: Reliability File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-11: CDMA Statistical Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-12: CDMA Statistical Images Window . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-13: CDMA Composite Images Window . . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-14: Reverse Required Power Image. . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-15: Best Ec/Io (Mobile Received Power) . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-16: Best Ec/Io Server/Sector for the Pilot Beacon Carrier. . . . . . . . . . 13Figure 13-17: Launching Data Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

xvi CDMA RF System Design Procedure Apr 2002


3 - 343 - 353 - 37 - 393 - 404 - 514 - 64 - 9 - 11 - 12 - 52 - 52 - 52 - 72 - 711

- 11

- 134 - 25 - 39 - 41 - 48- 50- 50 - 55

7 - 47 - 67 - 7

7 - 9 - 10 - 13

Figure 13-18: Data Query Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-19: Data Query Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-20: Corrected Transition Zone Coverage. . . . . . . . . . . . . . . . . . . . . . . 1Figure 13-21: Pilots Above T-Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 13-22: Data Query Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 14-1: CDMA Handoff Candidate Generator . . . . . . . . . . . . . . . . . . . . . . 1Figure 14-2: Generate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Figure 14-3: Edit Handoff List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Figure 14-4: Example PN Offset File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 14-5: Import PN Offset Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure A1-1: Example of Two Different Receive Path Configurations . . . . . . . A1Figure A2-1: SC611 Omni Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AFigure A2-2: SC611 Pseudo Two-Sector Configuration. . . . . . . . . . . . . . . . . . . AFigure A2-3: Wide Beam Antenna Pattern for a Two-Sector Coverage. . . . . . . AFigure A2-4: Narrow Beam Antenna Pattern for a Two-Sector Coverage . . . . . AFigure A2-5: NetPlan CDMA Simulator View of an Omni Configuration. . . . . A2 - Figure A2-6: NetPlan CDMA Simulator View of a Pseudo

Two-Sector Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A2 Figure A3-1: Estimating Where External Directional

Antennas Would be Useful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3Figure A4-1: Packet Data Call. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AFigure A4-2: Call Model States. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4Figure A4-3: Pareto Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4Figure A4-4: IS-95B HSPD Channelization . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4Figure A4-5: IS-95B HSPD Supplemental Channel Distribution (JMP) . . . . . . A4 Figure A4-6: IS-95B HSPD Supplemental Channel Distribution (JMP) . . . . . . A4 Figure A4-7: HSPD Supplemental Channel Image. . . . . . . . . . . . . . . . . . . . . . . A4Figure A7-1: Generate CDMA ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AFigure A7-2: Inter-System Interference Modeling . . . . . . . . . . . . . . . . . . . . . . . AFigure A7-3: Baseline Ec/Io Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AFigure A7-4: Ec/Io with ISI and no Attenuation Pad . . . . . . . . . . . . . . . . . . . . . AFigure A7-5: Ec/Io with ISI and Attenuation Pad . . . . . . . . . . . . . . . . . . . . . . . . A7Figure A7-6: Kavg vs. AMPS Channels/Sector . . . . . . . . . . . . . . . . . . . . . . . . . A7

xviiCDMA RF System Design ProcedureApr 2002


This page left intentionally blank

xviii CDMA RF System Design Procedure Apr 2002

Release 6.1

List of Tables


- 5

- 62 - 7

2 - 82 - 8 - 12 - 14 - 182 - 20- 22 - 25 - 25 - 26

- 33 - 34

3 - 53 - 133 - 13 - 17 - 19

- 205 - 285 - 41 - 41

6 - 17 - 40

- 11 - 11 - 129 - 3 - 16 - 17 - 33 - 359 - 40 40

Table 2-1: Example of an IS-95 CDMA RF Link Budget - Uplink for 1.9 GHz 2 Table 2-2: Example of an IS-2000 1X CDMA

RF Link Budget - Uplink for 1.9 GHz. . . . . . . . . . . . . . . . . . . . . . 2 Table 2-3: Reverse RC4 Differences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 2-4: Subscriber Unit Transmit Power at 800 MHz . . . . . . . . . . . . . . . .Table 2-5: Subscriber Unit Transmit Power at 1.9 GHz . . . . . . . . . . . . . . . . .Table 2-6: Example of Building Penetration Losses. . . . . . . . . . . . . . . . . . . . 2Table 2-7: Example of Main Transmission Line Losses: . . . . . . . . . . . . . . . . 2Table 2-8: Reverse Link Eb/No Values for Different Chipsets . . . . . . . . . . . 2Table 2-9: Processing Gain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 2-10: Single Cell Fade Margins Required for Various Area Reliabilities 2 Table 2-11: NetPlan Minimum Signal Strength Parameter . . . . . . . . . . . . . . . 2Table 2-12: NetPlan Rv “ERP” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Table 2-13: Double Check of NetPlan Values . . . . . . . . . . . . . . . . . . . . . . . . . 2Table 2-14: Rv “ERP” Adjustment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2Table 2-15: Adjusted Minimum Signal Strength Parameter . . . . . . . . . . . . . . 2Table 3-1: Standard USGS LU/LC for Xlos . . . . . . . . . . . . . . . . . . . . . . . . . .Table 3-2: Urban Corrections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 3-3: Dense Urban Corrections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 5-1: Weighted Traffic per Sector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Table 5-2: NumMob Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Table 5-3: Sample Traffic Data Import File . . . . . . . . . . . . . . . . . . . . . . . . . . 5Table 5-4: Standard Clutter Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 5-5: Determine Sectmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 5-6: Determining the Number of Carriers per Sector . . . . . . . . . . . . . . 5Table 6-1: Recommended Forward SCH Gain Settings . . . . . . . . . . . . . . . . .Table 6-2: Poisson or Constant Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . 6Table 7-1: Auto Proportion Settings (% of Pilot Power) . . . . . . . . . . . . . . . . 7Table 7-2: Page and Sync Settings Used With ISI Problems (% of Pilot Power) 7Table 7-3: IS-2000 Power Settings (% of Pilot Power) . . . . . . . . . . . . . . . . . 7Table 9-1: NetPlan Statistics Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 9-2: CDMA Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 9-3: Raw Statistics Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 9-4: Options to Improve RF Performance. . . . . . . . . . . . . . . . . . . . . . . 9Table 9-5: RF Reliability Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 9-6: Walsh Code Scaling Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 9-7: FwdLinks_X for “64 chip” Walsh Code Example . . . . . . . . . . . . 9 -

xixCDMA RF System Design ProcedureApr 2002

List of Tables - continued

9 - 479 - 499 - 499 - 53 - 57 - 59 - 60

- 62 - 63

9 - 76 - 78

- 9111 - 7 - 16

3 - 36 - 38A1 - 61 - 71 - 8 - 8

- 9 - 104 - 64 - 74 - 7

- 27- 314 - 31- 33 - 374 - 42 - 46 - 6 - 10

Table 9-8: SHOF Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 9-10: SSHOF Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 9-9: Required Modulator Resources Per SCH Data Rate . . . . . . . . . . .Table 9-11: Reverse Saturation Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 9-12: Non Time-Sliced Total Erlangs Equations . . . . . . . . . . . . . . . . . . 9Table 9-13: Time-Sliced Total Erlangs Equations . . . . . . . . . . . . . . . . . . . . . . 9Table 9-14: Active Erlangs Equations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 9-15: Forward Link Bursting Erlangs Equations . . . . . . . . . . . . . . . . . . 9Table 9-16: Reverse Link Bursting Erlangs Equations . . . . . . . . . . . . . . . . . . . 9Table 9-17: XsFlg Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 9-18: Example Sorted MobileTputStat_XX File. . . . . . . . . . . . . . . . . . . 9Table 9-19: R16.0 MCC1X-48 Forward/Reverse Resources

(Example Provisioning) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Table 11-1: Quantity of Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Table 11-2: Soft Handoff State Criteria for Images . . . . . . . . . . . . . . . . . . . . . 11Table 13-1: Example Ec/Io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Table 13-2: DAHHO Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Table A1-1: Receive Path Noise Figures and Gains . . . . . . . . . . . . . . . . . . . . .Table A1-2: Link Budget Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATable A1-3: NetPlan CDMA Simulator Parameter Inputs. . . . . . . . . . . . . . . . . ATable A2-1: Example Link Budget Changes for Voice Path Uplink . . . . . . . . . A2Table A2-2: Example NetPlan ERP Calculations

Based on Receive Voice Link Budgets (13 Kbps Vocoder) . . . . . A2Table A3-1: Fixed Subscriber Link Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3Table A4-1: Forward RC3 and RC4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATable A4-2: Forward RC5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATable A4-3: Reverse RC3 and RC4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATable A4-4: Voice & Data Activity Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 Table A4-5: Approximation of Throughput. . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 Table A4-6: IS-2000 Data Rates (base rate = 9.6 kbps). . . . . . . . . . . . . . . . . . . ATable A4-7: High-Speed Web Browsing Call Model Example. . . . . . . . . . . . . A4 Table A4-8: Example of Erlang Calculations . . . . . . . . . . . . . . . . . . . . . . . . . . A4Table A4-9: Service Type Default Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . ATable A6-1: IS-2000 1X Data Rate to “mindatarate” Mapping. . . . . . . . . . . . . A6Table A6-2: canal.pl Output Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATable A6-3: Statistics Column Headings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6

xx CDMA RF System Design Procedure Apr 2002

Release 6.1

List of Acronyms


Acronym Definition

ACK AcknowledgeADDS Application Data Delivery ServiceAIM Automatic Image MakerAmb. No. Ambient NoiseAMI Alternate Mark InversionAMPS Advanced Mobile Phone SystemAMSL Above Mean Sea LevelARP Average Rated PowerASCII American Standard Code for Information InterchangeATCH Actual Traffic ChannelB8ZS Binary 8 Zero Substitution - technique to achieve 64

kbps clear channel data per T-carrierBBX Broadband TransceiverBSM Base Station Device Module chipsetBSS Base Station SubsystemBTS Base Transceiver StationCAD Computer Aided DesignCBSC CDMA Base Station ControllerCCP CDMA Channel ProcessorCDF Cumulative Distribution FunctionCDMA Code Division Multiple AccessCE Channel ElementCM Cache ManagerCMA Cell and Mobile Analysis mode in NetPlanCRC Cyclic Redundancy CodeCSM Cell Site Modem chipsetDAHHO Database-Assisted Hard HandOffdBd decibels referenced to a dipole antennadBi decibels referenced to an isotropic antennadBm decibels referenced to one milliwattDCCH Dedicated control channel

xxiCDMA RF System Design ProcedureApr 2002

List of Acronyms - continued

DS0 Single 64 kbps channel in a T-1 systemDTX Discontinuous transmissionDXCDR Data TranscoderEb/No Energy per bit of information divided by the effective

noise spectral density. For example, where effectivenoise = total noise in 1.23 Hz BW due to thermal noiseand ambient noise and noise from other channels (spec-tral density refers to effective noise in 1 Hz BW).

Ec/Io Pilot energy accumulated over one PN (pseudo-noise)chip period (Ec) divided by the effective noise spectraldensity.

Ec/Ior A measure for a given sector of the ratio of the sector’spilot power (Ec) to the total forward link power allocat-ed, including pilot, page, sync and all traffic channelpowers (Ior)

ECAM Extended Channel Assignment MessageEIB Erasure Indicator BitEIRP Effective Isotropic Radiated PowerERP Effective Radiated PowerERXDC Expansion Receive Distribution CardETCH Effective Traffic ChannelEV-DO Evolution - Data OnlyEV-DV Evolution - Data VoiceEVRC Enhanced Variable Rate CoderF/B or FB Front-to-Back ratioFCH Fundamental ChannelFER Frame Erasure RateFFPC Fast Forward Power ControlFRP Fractional Recovered PowerFRU Field Replaceable UnitFTP file transfer protocolFWT Fixed Wireless TerminalGHz GigahertzGOS Grade of ServiceGUI Graphical User InterfaceHPAR High Power Alarm RatingHS High SpeedHSPD High Speed Packet DataHTTP Hypertext Transfer Protocol

Acronym Definition

xxii CDMA RF System Design Procedure Apr 2002


Hz HertzIC Integrated CircuitIF Intermediate FrequencyIM Inter-ModulationIo Interference energyIor Total forward link power allocatedIor/Ec A measure for a given sector of the ratio of the total for-

ward link power allocated, including pilot, page, syncand all traffic channel powers (Ior), to the sector’s pilotpower (Ec)

IP Internet ProtocolIS-2000 3G CDMA air interface specification defining several

radio configurations and higher maximum data rates.Backward compatible with IS-95A/B.

IS-95 Interim Standard 95IS-95A 2G CDMA air interface specifications defining funda-

mental links at 9.6 and 14.4 Kbps.IS-95B 2G CDMA air interface specifications defining funda-

mental links at 9.6 and 14.4 Kbps, and supporting con-catenated traffic channels.

ISI Inter-system InterferenceIWU Interworking Unitkbps Kilobits Per Secondkph Kilometers Per Hourksps Kilosymbols Per SecondkTB Kelvin Bandwidth limited Noise floorLPA Linear Power AmplifierLS Low SpeedLSPD Low Speed Packet DataLTU Logical Transmission UnitLU/LC Land Use/Land CoverMAC Medium Access ControlMAHHO Mobile-Assisted Hard HandOffMAWI Motorola Advanced Wideband Interface cardMbps Megabits Per SecondMCC Multi-channel CDMA Controller CardMCC1X Multi-channel CDMA Controller Card - 1XMHz MegahertzMPC Multicoupler Preselector Card

Acronym Definition

xxiiiCDMA RF System Design ProcedureApr 2002


mph Miles Per HourMSC Mobile Switching CenterMUX MultiplexerNACK Negative AcknowledgeNCU Network Communications UnitNF Noise FigureNo Noise Spectral DensityNPINIT NetPlan Initialization FileNTS Non Time-SlicedOCNS Other Cell Noise SourceOMC-R Operations Maintenance Center - RadioOTASP Over the AirOTD Orthogonal Transmit DiversityPA Power AmplifierPB Pilot BeaconPCB Power Control BitPCF Packet Control FunctionPDF Probability Distribution FunctionPDSN Packet Data Serving NodePG Processing GainPMRM Power Measurement Report MessagePN Pseudo NoisePSI-SDU Packet Subrate Interface - Selector Distribution UnitPSMM Pilot Strength Measurement MessagePTCH Physical Traffic ChannelQoS Quality of ServiceQPCH Quick Page ChannelRAN Radio Access NetworkRAS Reduced Active SetRC Radio Configuration for IS-2000 mobilesRC3, RC4, RC5 Radio ConfigurationR-DCCH Reverse Dedicated Control ChannelRF Radio FrequencyR-FCH Reverse Fundamental ChannelRFLM Radio Frequency Load ManagerRLC Radio Link Control.

Acronym Definition

xxiv CDMA RF System Design Procedure Apr 2002


RLP Radio Link Protocol. RLP provides an octet streamtransport service over forward and reverse traffic chan-nels.

R-PICH Reverse Pilot ChannelRS Rate Set for IS95A/B mobilesR-SCH Reverse Supplemental ChannelRSSI Received Signal Strength IndicationRX ReceiveRXDC Receive Distribution CardSCH Supplemental ChannelSDU Selector Distribution UnitSHO Soft HandoffSMS Short Message ServiceSMTP Simple Mail Transfer ProtocolSNR Signal-to-Noise RatioSSHO Soft Plus Softer HandoffSTTD Space-Time Transmit DiversityT-ADD Threshold above which a cell becomes an active hand-

off candidateT-DROP Threshold below which a cell is no longer an active

handoff candidateTCH Traffic ChannelTCMS Traffic Carrier Map SetT-COMP Threshold for comparing a candidate pilot to the maxi-

mum pilot in the active setTCP Transmission Control ProtocolTDMA Time Division Multiple AccessTMAP Traffic MapTMPC Tower Top Amplifier Multicoupler PreselectorTRX Transmit / Receive ModuleTS Time SlicedTSM Time Slice ManagerTTA Tower Top AmplifierTX TransmitUDP User Datagram ProtocolUSGS United State Geological SurveyVAF Voice Activity FactorWAM Wireless Access Manager

Acronym Definition

xxvCDMA RF System Design ProcedureApr 2002


WAP Wireless Application ProtocolWiLL Wireless Local LoopW-TCP Wireless - Transmission Control ProtocolXCDR TranscoderXlos NetPlan proprietary pathloss model

Acronym Definition

xxvi CDMA RF System Design Procedure Apr 2002

Introduction
Chapter
1
Table of Contents
1 - 3

1 - 3

1 - 5

1 - 51 - 51 - 5

- 6

- 7 - 71 - 81 - 81 - 91 - 91 - 9

- 9

0

- 11- 11 - 12 - 12

2

- 13

13

1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 RF System Design Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Link Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 NetPlan Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1.4.1 NetPlan Inputs Based on the Link Budget . . . . . . . . . . . . . . . . .1.4.2 Optimizing Clutter Data and Antenna Patterns . . . . . . . . . . . . . .

1.5 Generate Propagation Studies and Verify Coverage . . . . . . . . . . . . . . 1

1.6 CDMA Simulation Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.6.1 Determine Traffic (Distribution) and Speed Maps . . . . . . . . . . . 11.6.2 System Level Simulator Parameters . . . . . . . . . . . . . . . . . . . . . .1.6.3 Site Level Simulator Parameters . . . . . . . . . . . . . . . . . . . . . . . . .1.6.4 Simulator Path Loss Creation . . . . . . . . . . . . . . . . . . . . . . . . . . .1.6.5 Modeling Inter-System Interference . . . . . . . . . . . . . . . . . . . . . .1.6.6 Neighbor List Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.7 Running the Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.8 Analyzing Simulator Outputs (Statistics and Images) . . . . . . . . . . . . . 1 - 11.8.1 Meeting Defined Requirements and Minimum System

Performance Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8.2 Analyzing Time-sliced Simulation Outputs . . . . . . . . . . . . . . . . 1 1.8.3 Treating Pilot Pollution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.8.4 CDMA Statistical Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.9 Comparison of Simulator Coverage vs. Path Loss Only Coverage. . . 1 - 1

1.10 Final Design Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.11 Quick Guide to Contents of Each Chapter . . . . . . . . . . . . . . . . . . . . . . 1 -

1 - 1CDMA RF System Design ProcedureApr 2002

1

Chapter 1: Introduction

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

1 - 2 CDMA RF System Design Procedure Apr 2002

1


ure tould bees the

ogies:tPlan

pecifichat arerentnt theused

ion 6.1e of

the2000iate.

temion of

1.1 Overview

The purpose of this document is to provide CDMA system design engineers with a procedfollow when designing CDMA RF systems. The procedure addresses those steps which shotaken to select CDMA cell sites and predict their performance. The procedure also addresssteps that should be taken to simulate and evaluate the effects of different CDMA technolIS-95A, IS-95B, and IS-2000. The process achieves this goal through the use of the NeVersion 6.1 planning tool with its CDMA Static System Simulator.

General RF considerations for CDMA system design are addressed, as well as frequency sconsiderations (800 MHz and 1.9 GHz). The procedure also addresses considerations tneeded to properly model different subscriber types: voice (including the effects of diffevocoder rates), data (circuit or packet), or a combination of types. Throughout this documeterms 800 MHz and cellular may be used interchangeably, 1.9 GHz and PCS may beinterchangeably, and NetPlan Version 6.1 and NetPlan may be used interchangeably.

It is assumed that the user of this procedure is thoroughly versed in the use of NetPlan Vers(Motorola propagation prediction tool including the simulator). This document aids in the usthe NetPlan CDMA Simulator but is not intended to be the user’s guide for the tool.

Users familiar with the “CDMA RF System Design Procedure” will notice that this version ofdocument is laid out a little differently than in the past. Since NetPlan Version 6.1 supports IS-1X, the chapters of this document are separated into IS-95A/B and IS-2000 where appropr

1.2 RF System Design Process

Figure 1-1 details the procedure flow to be followed while performing the CDMA RF sysdesign. The steps are mirrored by the chapters within this document. A summary descripteach step is listed after the procedure flow diagram.


1


Figure 1-1: Procedure Flow Diagram

Link

Bud

get

CD

MA

Non

Tim

e-sl

iced

Par

amet

ers

Verif

y C

over

age

Net

Pla

n P

ropa

gatio

nS

tudi

esP

hase

I D

esig

n R

eview

Link

Bud

get

-R

F R

ever

se L

ink

Onl

y-

Initi

al A

llow

able

Pat

h Lo

ss C

over

age

Rev

iew

-S

impl

istic

- R

ever

se L

ink

Onl

y-

Allo

wab

le P

ath

Loss

Opt

imiz

eC

lutte

r&

Pro

p. M

odel

Pre

pare

ISI

Inpu

t

RU

NS

imul

ator

-M

ultip

le P

lots

-P

A P

ower

- E

quip

men

t Typ

e -

MC

C C

ards

-IS

I Im

pact

-P

PS

, Nei

ghbo

rs-

Cel

ls W

hich

are

Blo

ckin

g-

Cov

erag

e an

d In

terf

eren

ce-

Dat

a T

hrou

ghpu

t

Mod

ify A

nt. F

/BR

atio

if N

eces

sary

Det

erm

ine

Net

Pla

n In

puts

for

Sig

Str

engt

h S

tudi

es

-E

RP

-M

inim

um S

igna

l Str

engt

h

Pha

se II

Des

ign

Revi

ewP

ath

Loss

Cov

erag

e

Sim

ulat

or P

ath

Loss

crea

tion

Det

erm

ine

Traf

ficD

istr

ibut

ion.

Ana

lyze

Sim

. Out

puts

Sta

ts. &

Imag

esM

eet R

equi

rem

ents

&M

in. S

ys. P

erf.

Sta

ndar

ds

N

Pro

duce

Nei

ghbo

r Li

st

Rep

eat p

roce

ss w

here

nec

essa

ry

Y

IsN

eigh

bor

List

Des

ired?

CD

MA

Tim

e-sl

iced

Par

amet

ers

Com

pare

Sim

. Cov

erag

e vs

.P

ath

Loss

Onl

y C

over

age

-U

nder

stan

d C

DM

A e

ffect

s on

Cov

erag

e-

Inte

rfer

ence

-S

HO

-C

apac

ity

Pha

se II

I Des

ign

Rev

iew

(F

inal

)

NN

Y

Run

Tim

e-sl

iced

Sim

ulat

ion?


1


cienterage,

en theh. Thisnd thewableation

nd theason, ithe next

sary tobudget

tes aresed in

)

tPlanpendent

1.3 Link Budget

A system design is usually based on trying to maximize coverage while still ensuring suffisignal strength for calls. The system design needs to balance the requirements for covcapacity, and call quality, since each of these factors are interrelated in a CDMA system.

The first step in a system design is setting up the link budget to model the RF path betwesubscriber unit and the base station, accounting for all of the gains and losses along the patlink budget is used to establish system design assumptions which are used in NetPlan asimulation portion of the design process, as well as to establish an estimate for maximum allopath loss. This maximum allowable path loss is then used in conjunction with the propagmodel in NetPlan to estimate coverage.

Since the system design assumptions in the link budget are used in the NetPlan tool asimulator, it is important that these assumptions be discussed and agreed upon. For this reis recommended that the link budget and its assumptions be reviewed before proceeding to tdesign step.

(For more details on link budgets, please see Chapter 2.)

1.4 NetPlan Inputs

After the link budget has been established, the next step is to prepare all of the inputs necesrun propagation estimates via NetPlan. These inputs include parameters based on linkassumptions, as well as clutter database inputs and antenna pattern inputs.

1.4.1 NetPlan Inputs Based on the Link Budget

Some of the values used in NetPlan when generating path loss based coverage estimadetermined by using the link budget parameters. Specifically, these parameters are ucalculating the ERP and minimum signal strength levels for NetPlan.

(For more details on determining NetPlan inputs from a link budget, please see Chapter 2.

1.4.2 Optimizing Clutter Data and Antenna Patterns

In addition to using the link budget information within NetPlan, there are databases within Nethat are used when generating coverage studies. The accuracy of the system design is deupon the accuracy of this information.


1


currenter datans. Itsarilybe uplutioner datastudies.ata, it

ve tests thisata so

variousrticalthe

l worldturer’s

please

ta haveother, etc. areverageit canlyzingements,theseugh thete onsed by

arefullyonly”

). Based

pter 4.)

One of the databases used within NetPlan is the clutter (morphological) database. The morethe clutter data, the more accurate the coverage estimates will be. A common source of cluttis the U.S. Geological Survey (USGS). However, the USGS clutter data has certain limitatiocategorizes the land by how it is used (commercial, industrial, etc.) which does not necescoincide with categorizing by its propagation characteristics. Also, the USGS data may notto date (may not account for newly developed areas). In order to obtain the highest resoclutter data and the best determination for coverage, it is recommended that enhanced cluttbased on satellite imagery and aerial photography be used when generating propagationAlthough this data is more expensive and requires more time to acquire than the USGS dprovides more accurate results.

Once the enhanced clutter data is available, it may be used in conjunction with accurate dridata in the process of optimizing NetPlan’s propagation predictions. This process useinformation to adjust the virtual heights and loss data associated with the enhanced clutter dthat the predicted propagation matches closely with the drive test data.

Another database that is used within NetPlan is the antenna pattern database. There arecharacteristics that will impact the coverage for a cell, such as the gain, horizontal and vebeamwidth, and the front-to-back (F/B) ratio. As with the clutter data, it is important to usemost accurate antenna data that is available when designing a system. For example, if reaperformance data is available for an antenna, this should be used in place of the manufacantenna pattern information.

(For more details on optimizing clutter data, the propagation model, and antenna patterns,see Chapter 3.)

1.5 Generate Propagation Studies and Verify Coverage

When all of the inputs to NetPlan have been determined (enhanced clutter and drive test dabeen used to optimize the virtual heights associated with the prediction tool, and allparameters such as antenna placement, antenna type, site ERP, propagation parametersset), the next step is to use NetPlan to estimate the coverage of the system. Generating coplots based on a maximum allowable path loss from a RF link budget is a useful step sincebe used to identify potential system design deficiencies early in the design process. Anathese plots can help determine major issues such as coverage holes, non-ideal cell site placterrain obstruction issues, and sites which may cause excess interference. By identifyingissues early in the design process, some of these issues can be resolved before going throtime and effort of simulations. This allows the simulation process to be used to concentraissues that can only be analyzed with the simulator rather than issues that can be addrescoverage plots based on path loss only.

Once coverage estimates have been run and analyzed, it is suggested that the plots be creviewed. This step is important to make sure that the system coverage from a “path lossperspective meets the design expectations (ensure coverage in all areas that are importanton this review, parameters can be altered to adjust the coverage if necessary.

(For more details on generating propagation studies and verifying coverage, please see Cha


1


DMAh thed, softandinputs

ers)

evingaffic

mapsachaveling

n. Thismenteering

refer

1.6 CDMA Simulation Inputs

After the initial coverage has been reviewed, the next step is to begin the process of Csimulations. This is required in completing a CDMA system design since it analyzes botforward and the reverse links and accounts for CDMA effects (such as subscriber speehandoff, voice activity, pilot settings, etc.). Before beginning to run simulations, the input filesparameters must be defined for either non time-sliced or time-sliced analysis. Some of theseinclude:

• traffic distribution map(s) for voice and data subscribers

• speed map (optional)

• path loss information

• simulation input parameters (some of which are based on the link budget paramet

• inter-system interference input files (optional)

• neighbor list (optional)

1.6.1 Determine Traffic (Distribution) and Speed Maps

The usage of a traffic distribution map and a speed map with the simulator is important in achiviable results. The traffic distribution map should closely represent the real-world trdistribution density as best as can be determined. For multiple carrier systems, a set of trafficcalled a Traffic Carrier Map Set (TCMS) is used to define the traffic distribution for eindividual carrier. The speed map should represent the speed at which system users are trwhen located on defined clutter and road types.

These maps impact the placement and speed of the “dropped” subscribers into a simulatioin turn impacts the system capacity, power amplifier sizing, coverage, and cell site equiprequirements. NetPlan provides the means to produce these maps through its Traffic EnginTool. The use of this tool is addressed in the procedure.

(For further details on producing a traffic distribution and speed maps for simulations, pleaseto Chapter 5.)


1


ined in

g theough thethesefor the

ust be

tation

1.6.2 System Level Simulator Parameters

In addition to path loss and traffic data, there are numerous parameters which must be deforder to simulate the “real world”. These parameters include such information as:

• carrier information

• noise figures

• required number of drops

• delay spread information

• maximum power levels for the subscriber units

• voice/data activity factors

• subscriber speed

• required traffic load

• FER target and outage criteria

• call modeling information

• packet data information

These values will vary depending on the particular requirements of the system includinsystem’s base frequency and the vocoder data rate. These parameters can be entered thrCDMA Parameters input menu. This document discusses recommended values forparameters. These recommendations can be used directly or can be modified if necessaryspecific system that is being designed.

(For further details on these parameters, please see Chapter 6.)

1.6.3 Site Level Simulator Parameters

In addition to the system level simulator parameters, there are cell site parameters which mdefined. These parameters include such information as:

• carrier information

• antenna gains

• line losses

• handoff parameters

• power levels (pilot, page, sync, Min_TCH, and Max_TCH)

These values will vary from site to site and must be entered to correctly reflect the implemenin the system being studied.


1


ignalell siteetPlantion of

r 8.)

stemMPSm ofnon-ducts. AMA

thethoseons, itmance

p is tolicedeling

stem

(For further details on these parameters, please see Chapter 7.)

1.6.4 Simulator Path Loss Creation

Another major input into the simulator is the path loss data. This data does not contain sstrength values (dBm) as in analog studies, but strictly the path attenuation (dB) from each cto all system locations. This attenuation does not include the antenna gain or line losses. Ncreates path loss data to be used in conjunction with the simulator. Issues impacting the creathe path loss data are addressed in the procedure.

(For further details on creating the path loss data for use in simulations, please see Chapte

1.6.5 Modeling Inter-System Interference

Another input file which can be used in the simulator is one which addresses inter-syinterference. There are several forms of inter-system interference (ISI). Of these forms, Abase site to CDMA subscriber interference at 800 MHz is one of the most significant. This forinterference occurs when strong AMPS signals force the CDMA subscriber’s receiver into alinear region of operation. These AMPS signals can mix together producing odd order prowhich fall within the CDMA signal bandwidth and contribute to the background noiseprocedure for modeling AMPS-ISI using the Generate ISI feature within the NetPlan CDSimulator is presented within this document.

(For further details on modeling ISI within the simulator, please refer to Appendix A7.)

1.6.6 Neighbor List Generation

The final input which is used in running static system simulations is the neighbor list. Withinstatic simulation process, adding a neighbor list restricts candidates for soft handoff to onlysectors which are neighbors to the best sector. Before placing this restriction on the simulatiis recommended that the system be generally optimized to meet the minimum system perforstandards. Once this is completed, a neighbor list can be introduced into the simulations.

(For more details on generating neighbor lists, please see Chapter 14.)

1.7 Running the Simulator

Once all of the input files and parameters have been defined for the simulations, the next steactually run the simulator. There are two types of IS-2000 simulations within NetPlan, time-ssimulations or non time-sliced simulations. Each simulation type uses a different data modtechnique. These two simulation types will be explained further in later chapters.

(For further details regarding running simulations, please see the “NetPlan CDMA Static SySimulation User’s Manual”.)


1


yzed tog justics must

1.8 Analyzing Simulator Outputs (Statistics and Images)

The simulator produces various images and statistical outputs. These outputs must be analdetermine if a given design is operating properly. It is important to understand that analyzinstatistics or images alone does not validate a good system design. Both coverage and statistbe used to validate a system design.

Some of the statistical outputs that are evaluated in the system design analysis are:

• number of subscribers per sector

• number of channel elements per sector

• number of links per sector

• percent soft handoff

• percentage of good links

• cell noise rise

• total forward power

Some additional statistical outputs that are used to evaluate IS-2000 1X systems are:

• active and bursting Erlangs

• sector throughput

• effective sector throughput

• end user throughput

• data rate distribution

• high speed channel request failure probability

• forward data activity factor

(For further details on simulator statistical outputs, please refer to Chapter 9.)

Some of the images that are analyzed are:

• Best Ec/Io

• Best Ec/Io Server/Sector

• Reverse Required Power

• Forward Required Power

• Forward TCH Threshold


1


o havepon

city andcity

arestem iss thedesignultiplemance

imum

oss)

ts tostitutes

• Reverse Achieved FER

• Forward Achieved FER

• Soft Handoff State

• Pilots > T-DROP

• Pilot Pollution

• Forward F Factor

• IS-95B Supplemental Channels

• Achieved Data Rate

(For further details on simulator output images, please refer to Chapter 11.)

1.8.1 Meeting Defined Requirements and Minimum System Performance Standards

In analyzing the simulator outputs to determine if the system design is good or not, one has tan idea in mind as to what constitutes “good”. For IS-95A/B much of this is dependent udefined expectations such as, the desired area coverage and the requirements for capaquality. However, with IS-2000 1X time-sliced simulations, the user will find that RF capaexpectations are the key to a successful design - particularly data throughput.

With both IS-95A/B and IS-2000 1X time-sliced and non time-sliced simulations, thererecommended minimum system performance standards that are used to determine if the syoperating properly or not. While evaluating a system design, it is important to see if it meetdesign requirements and minimum system performance standards. If it does not, then theneeds to be modified and simulations repeated until it meets the defined expectations. For mcarrier systems, an evaluation of the design requirements and the minimum system perforstandards should be performed for each carrier.

For further details on analyzing the simulator outputs to meet design requirements and minsystem performance standards, please see the following chapters:

• Chapter 9, NetPlan CDMA Simulator Statistical Output and Analysis.

• Chapter 10, NetPlan Cell/Mobile Analysis.

• Chapter 11, NetPlan CDMA Simulator Images Output and Analysis.

• Chapter 13, NetPlan CDMA Composite & Statistical Images (Coverage vs. Path L

1.8.2 Analyzing Time-sliced Simulation Outputs

As in the case of non time-sliced outputs, when analyzing the time-sliced simulator outpudetermine if the system design is good or not, one has to have an idea in mind as to what con


1


RFt RFzed are,ended

erating

esign

ayn beimage). Byerity,

t oneance.

wer.

thatfrom

erseR and

rage”

ss onlyuchwhere

re not

path

“good”. As always, much of this is dependent upon maintaining a specified level ofperformance and coverage. However, with time-sliced simulations, the user will find thacapacity expectations are the key to a successful design. Some of the statistics to be analyactive/bursting Erlangs, data throughput, and data rate distribution. Also, there are recommminimum system performance standards that are used to determine if the system is opproperly or not.

(For further details on analyzing the time-sliced simulator outputs to meet packet data drequirements and minimum system performance standards, please refer to Chapter 9.)

1.8.3 Treating Pilot Pollution

Pilot Pollution (also known as a “non-dominant pilot condition”) is a condition which takes awfrom CDMA System Coverage. The condition exists when multiple pilots (more than cahandled by the subscriber unit rake receiver) have comparable signal strength levels. Threetypes are used to investigate pilot pollution (Pilot Pollution, Best Ec/Io, and Best Ec/Io Serverviewing the first image while querying on the others, insight can be gained as to the sevsource, and solution to the pilot pollution.

(For further details on treating pilot pollution, please refer to Chapter 12.)

1.8.4 CDMA Statistical Images

Each image viewed from a simulation run represents the system performance for thaplacement of “dropped” subscribers. No one image represents the “average” system performThe NetPlan “CDMA Statistical Images” post processing feature gives the designer this po

(For further details on statistical images, please refer to Chapter 13.)

1.9 Comparison of Simulator Coverage vs. Path Loss Only Coverage

It is useful to compare the coverage results achieved with the NetPlan CDMA Simulator withdetermined by path loss only coverage. In order to do this, a “coverage” plot must be createdthe simulator image results. A location is considered “covered” if both the forward and revlinks can be established while meeting the desired FER targets. Forward and Reverse FEPower images are used in conjunction with the Pilot Pollution image to create the “coveimage. This is done by invoking the NetPlan CDMA Composite Images feature.

Comparing the coverage based on the simulator results with the coverage based on path lowill highlight the areas where “CDMA” effects impact the coverage environment. Senvironments exist where path loss coverage is different from the simulator based coverage,inter-system interference exists and where pilot pollution is taken into account. These amodeled at all in the path loss only case.

(For additional information regarding comparing simulator coverage to coverage based onloss only, please refer to Chapter 13.)


1


systemthat this

the

1.10 Final Design Review

Once the system has been optimized to meet the design requirements and minimumperformance standards, and the coverage plots have been analyzed, it is recommendedinformation be reviewed thoroughly. This will verify that the system design indeed meetsdefined performance expectations.

1.11 Quick Guide to Contents of Each Chapter

The table below briefly outlines key features of each chapter in this procedure.

ChapterNumber

Chapter Title Overview of Chapter Contents

1 Introduction2 Link Budgets and

Associated NetPlanInputs

Describes link budget parameters and how todetermine the associated NetPlan inputs forcoverage estimates.

3 Optimizing Clutter Dataand Antenna Patterns

Describes how to enhance predicted path lossthrough the utilization of satellite clutter data and thealteration of antenna patterns to reflect real worldperformance.

4 Verify Coverage andIdentify Problem Areas

Describes the use of Signal Strength and Best Serverimages in verifying coverage, evaluating siteplacements, and identifying problem areas.

5 Traffic (Distribution)and Speed Maps

Describes creating the subscriber probability andspeed distribution inputs for simulation.

6 Setting Simulator InputParameters - SystemLevel

Describes entering CDMA simulation inputparameters on a system wide level.

7 Setting Simulator InputParameters - Site

Describes entering CDMA cell site inputparameters.

8 Simulator Path LossCreation

Describes creating simulation path loss. It alsodiscusses exclusion masks and additional lossesassociated with lognormal shadowing.

9 NetPlan CDMASimulator StatisticalOutput and Analysis

Describes the most relevant data outputs to bestudied and their impact on design decisions.

10 NetPlan Cell/MobileAnalysis

Describes the Cell/Mobile Analysis tool forinvestigating the data outputs and facilitating designdecisions.

11 NetPlan CDMASimulator Images Outputand Analysis

Describes the images produced from simulationsand how to interpret them.


1


12 Treating Pilot Pollution Describes the images and process used to detect andeliminate pilot pollution.

13 NetPlan CDMAComposite & StatisticalImages (Coverage vs.Path Loss)

Describes the CDMA Composite Images featurethat is used to produce coverage plots and how tocompare these plots to path loss plots. It alsodescribes the use of the Statistical Images feature.

14 CDMA HandoffCandidates

Describes the CDMA Handoff Candidates featurewhich uses simulation results to produce a neighborlist.

A1 Tower Top Amplifier -Design Considerations

Describes the TTA impact to the reverse link budgetand how to simulate TTAs using NetPlan.

A2 Atypical Cell SiteConfigurations

Describes various special design considerationswhen implementing a pseudo two-sector siteconfiguration.

A3 WiLL System Design Describes the process to follow when designing aWiLL system using NetPlan.

A4 Data Services SystemDesign

Describes the process to follow when designing aCircuit or Packet Data system using NetPlan.

A5 Application DataDelivery ServiceConsiderations

Describes the Application Data Delivery Service(ADDS) impact to the system (for example, ShortMessage Service) and how to simulate the ADDStraffic load using NetPlan.

A6 Running Canal.pl Describes the use of the canal.pl script for postprocessing IS-2000 time-sliced statistical outputs.

A7 Modeling Inter-SystemInterference

Describes the procedures for investigating ISIwithin the simulator.

ChapterNumber

Chapter Title Overview of Chapter Contents


Link Budgets and AssociatedNetPlan Inputs

Chapter

2
Table of Contents
2 - 3

- 4

- 4

- 52 - 8 - 10

2 - 11 - 12 - 16 - 20 - 21 - 21

4 - 25 - 26 - 29

4

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2 RF Link Budget Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 RF Link Budget Assumptions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.4 RF Link Budget Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.1 Subscriber Unit Tx Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4.2 Antenna Gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.3 Penetration Losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2.4.4 Line Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.5 Base Station Rx Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.6 Interference Margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.7 Ambient Noise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.8 Shadow Fade Margin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.5 Determining NetPlan Inputs to Estimate Coverage . . . . . . . . . . . . . . . 2 - 22.5.1 Example Calculations of NetPlan Values . . . . . . . . . . . . . . . . . . 22.5.2 Entering NetPlan Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.5.3 NetPlan Image Parameters and Multiple Level Plots . . . . . . . . . 2

2.6 Utilizing Link Budget Assumptions in Simulations . . . . . . . . . . . . . . . 2 - 3


2

Chapter 2: Link Budgets and Associated NetPlan Inputs

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


2


cientqualityn, them, thell three

en thelosses

firstF pathower,budgeth losserage.

designaced toorenceearlyd effortn onlyased on

all ofide”rating

od, thehow

tPlantary

2.1 Overview

A system design is usually based on trying to maximize coverage while still ensuring suffisignal strength for calls. The coverage design has to be balanced with the requirements forand capacity within the system. Although all three factors are important in an analog desiganalog RF coverage is not dependent upon the number of traffic channels. In a CDMA systecoverage and capacity are interrelated. With higher capacity, the site coverage is reduced. Aprinciples (coverage, capacity, and quality) must be factored into a CDMA system design.

The first step in a system design is setting up the RF link budget to model the RF path betwesubscriber unit and the base station. This RF link budget accounts for all of the gains andalong this RF path.

There are two main purposes for establishing an RF link budget for CDMA designs. Thepurpose is to establish system design assumptions for all of the gains and losses in the R(such as vehicle loss, building loss, ambient noise margin, maximum subscriber transmit petc.) which are used as inputs to NetPlan in the design process. The second purpose of a linkis to establish an estimate for the maximum allowable path loss. This maximum allowable patvalue is used in conjunction with the propagation model in NetPlan to estimate the site cov

Analyzing the coverage based on a maximum allowable path loss is an important step in theprocess since it can help determine major issues such as site placement problems (sites spclose or too far apart), terrain obstruction issues, and sites which may present interfeproblems (sites on mountain tops or near large bodies of water). By identifying these issuesin the design process, some of these issues can be resolved before going through the time anof simulations. This allows the simulation process to be used to concentrate on issues that cabe analyzed with the simulator rather than issues that can be addressed by coverage plots bpath loss only.

A detailed discussion of the IS-95 (cdmaOne) and IS-2000 (cdma2000) RF link budget andits parameters can be found in Chapter 4 of the “CDMA/CDMA2000 1X RF Planning Gu(March 2002). It is recommended that this section of the planning guide be read before genean RF link budget or producing a propagation study. Once the parameters are understofollowing information can be used to determine initial RF link budget values and to showthese values are used to determine the inputs into NetPlan.

Note: This document assumes a detailed design process is followed using the Nemaximum allowable path loss step as well as the NetPlan CDMA Simulator. Budgedesigns are not addressed.


2


eed. The

bothlation

getwillinget, the

s withn willrves of

eachuildingliability,everal

2.2 RF Link Budget Parameters

As mentioned in the “CDMA/CDMA2000 1X RF Planning Guide”, the system designer will nto determine the specific link budget parameters to be used when designing the systemfollowing lists some of these parameters:

• Propagation Related Parameters:

Building LossVehicle LossBody LossAmbient Noise MarginRF Feeder LossesAntenna Gain

• CDMA Specific Parameters:

Interference MarginEb/NoProcessing Gain (ratio of bandwidth to data rate)

• Product Specific Parameters:

Product Transmit PowerProduct Receiver SensitivityProduct Noise Figure

• Reliability Parameter (Shadow Fade Margin)

The values within the link budget provide the designer with input parameters to be used withinthe NetPlan maximum allowable path loss procedure step as well as the NetPlan CDMA simuprocedure step.

2.3 RF Link Budget Assumptions

Due to the variability of the forward link (base station to subscriber), the CDMA RF link budin this procedure will model only the reverse link (subscriber to base station). The forward linkbe accounted for within the simulation step. In addition, CDMA RF link budgets make simplifyassumptions regarding noise rise and Eb/No requirements. For instance, in the RF link budgEb/No value is considered a constant. In actuality, Eb/No is not a constant value but varierespect to speed, delay spread and other factors. Again, the simulation model within NetPlachoose an appropriate Eb/No value for each subscriber to base station connection from cuEb/No values.

An RF link budget must be determined for each sector of each site. The RF link budget forsector must incorporate any specific parameters that have been supplied (such as bpenetrations, antenna heights, antenna gains, cable losses, coverage criteria, coverage reetc.). It is common that all sectors of a given site may have the same link budget or even that s


2


If thisctors.udgets

maygiven

y basedtained

get.

sites may have the same link budget due to common installation practices being followed.is the case, then the same link budget can be used for all of the similarly configured seHowever, if the parameters change from sector to sector and site to site, then separate link bwill need to be calculated for each sector.

2.4 RF Link Budget Example

The following table shows an example of an IS-95 (cdmaOne) RF Link Budget. Differencesexist between the values shown in this table and values required for specific sectors in asystem. For instance, antenna gains, line losses, building losses, etc. may be set differentlupon the system design requirements. Additional information for the parameters can be obfrom the section of this chapter listed in the column of the table labeled Reference.

Table 2-1: Example of an IS-95 CDMA RF Link Budget - Uplink for 1.9 GHz

* These values are used as input into the NetPlan CDMA Simulator.

The introduction of IS-2000 1X (cdma2000) will impact several parameters of the RF link budThe affected parameters are the:

Parameter Unit Reference Example13 kbps

Example8 kbps

Subscriber Unit Tx PowerdBm a * Section 2.4.1 23 23

Subscriber Unit AntennaGain

dBd b * Section 2.4.1& Section 2.4.2

-2.1 -2.1

Body Loss dB c * Section 2.4.3 2 2

Vehicle Loss dB d * Section 2.4.3 6 6

Building Loss dB e * Section 2.4.3 0 0

Base Antenna Gain dBd f * Section 2.4.2 14.5 14.5

Line Loss dB g * Section 2.4.4 2 2

kTB dBm h Section 2.4.5.1& Section 2.4.5.2

-113.1 -113.1

Noise Figure dB j * Section 2.4.5.3 6 6

Eb/No dB k Section 2.4.5.4 7.3 7.0

Processing Gain dB l Section 2.4.5.5 19.3 21.1

Base Rx Sensitivity= h+j+k-l

dBm m Section 2.4.5 -119.1 -121.2

Interference Margin dB n Section 2.4.6 3 3

Ambient Noise Rise dB p * Section 2.4.7 0 0

Shadow Fade Margin dB r * Section 2.4.8 5.6 5.6

Max. Allowable Path Loss= a+b-c-d-e+f-g-m-n-p-r

dB 135.9 138.0


2


adiodata

H

• Subscriber Unit Tx Power

• Eb/No

• Processing Gain

The following table shows an example of an IS-2000 1X RF Link Budget for reverse link RConfiguration 3 (RC3). Multiple columns are shown to address the impact that the variousrates will have upon the path loss.

Table 2-2: Example of an IS-2000 1X CDMA RF Link Budget - Uplink for 1.9 GHz

Parameter Unit Reference 9.6kbps

19.2kbps

38.4kbps

76.8kbps

153.6kbps

Reverse Traffic Channel FCH SCH SCH SCH SC

Total Subscriber Unit TxPower

mW PT * Section 2.4.1 200 200 200 200 200

Subscriber Unit R-FCH orR-DCCH Tx Power

mW PFCH Section 2.4.1 200 90 63 41 25

Subscriber Unit R-SCHTx Power

mW PSCH Section 2.4.1 - 110 137 159 175

Subscriber Unit Tx Power(for the specified reversetraffic channel)

dBm a Section 2.4.1 23 20.4 21.4 22.0 22.4

Subscriber Unit AntennaGain

dBd b * Section 2.4.1& Section 2.4.2

-2.1 -2.1 -2.1 -2.1 -2.1

Body Loss dB c * Section 2.4.3 2 2 2 2 2

Vehicle Loss dB d * Section 2.4.3 6 6 6 6 6

Building Loss dB e * Section 2.4.3 0 0 0 0 0

Base Antenna Gain dBd f * Section 2.4.2 14.5 14.5 14.5 14.5 14.5

Line Loss dB g * Section 2.4.4 2 2 2 2 2

kTB dBm h Section 2.4.5.1& Section 2.4.5.2

-113.1 -113.1 -113.1 -113.1 -113.1

Noise Figure dB j * Section 2.4.5.3 6 6 6 6 6

Eb/No dB k Section 2.4.5.4 5.6 3.5 3.0 2.5 2.1

Processing Gain dB l Section 2.4.5.5 21.1 18.1 15.1 12.0 9.0


dBm m Section 2.4.5 -122.6 -121.6 -119.1 -116.6 -114.0

Interference Margin dB n Section 2.4.6 3 3 3 3 3

Ambient Noise Rise dB p * Section 2.4.7 0 0 0 0 0

Shadow Fade Margin dB r * Section 2.4.8 5.6 5.6 5.6 5.6 5.6

Max. Allowable Path Loss= a+b-c-d-e+f-g-m-n-p-r

dB 139.4 135.8 134.3 132.4 130.2


2


ata ratetes. Forrse linkgationond tokbps

RC3.4. Toe 9.6

te ondatard linke linkitingrds

woulds thaton the

kbpserseystemIf dataidered.

5 orployeday notatathe

ld bed in

* These values are used as input into the NetPlan CDMA Simulator.

An observation of the preceding table shows that the allowable path loss decreases as the dincreases. This means that a smaller site radius would be required to support higher data raexample, more sites would be required if a system was to be designed based on an RF reveassuming 76.8 kbps than if the system requirement was for 9.6 kbps. Assuming a propaexponent of 3.5, the 7 dB path loss difference between these two data rates would correspthe 76.8 kbps scenario requiring approximately 2.5 times the number of sites as the 9.6scenario.

As previously mentioned, Table 2-2 provides example parameter values for reverseMotorola’s infrastructure and NetPlan will also support the fundamental rate of reverse RCmodel the fundamental reverse RC4 channel, the following parameters from Table 2-2 for thkbps reverse RC3 would be altered.

Table 2-3: Reverse RC4 Differences

IS-2000 provides for the ability to have asymmetrical data transmission. That is, the data rathe forward link can be different than the data rate employed on the reverse link. Initialapplications for IS-2000 are assumed to demand more data to be transferred on the forwathan on the reverse link (i.e. the forward link data rate will need to be faster than the reversdata rate). Additionally, it is viewed that for most cases, the reverse RF path will be the limlink with regards to coverage, whereas the forward link will be the limiting RF path with regato capacity. It is possible that an RF reverse link based on a fundamental rate of 9.6 kbpsallow for sufficient path loss so that a forward link of 76.8 kbps could be achieved. This meanthe coverage to support 9.6 kbps on the reverse RF link may provide for sufficient coverageforward link to support a user needing 76.8 kbps. This is not saying that a user rate of 153.6is not supported. A user, in close proximity to the site, could have a forward and/or revsupplemental channel at 153.6 kbps, but not at the fringe of the site. Given these views, a sbased on the RF reverse link for data rates above 19.2 kbps may not be necessary.applications require a high volume of reverse data, then higher data rates need to be cons

If IS-2000 is to be overlaid (additional carrier) onto existing sites currently equipped with IS-9used to replace an existing IS-95 carrier at a site, then the existing sites have already been debased on a site separation dictated by the IS-95 RF link budget. Furthermore, the operator mbe willing to add additional sites initially to support the highest IS-2000 reverse link dcapabilities. If the IS-2000 carrier is to be deployed in only the existing IS-95 sites, thenexisting RF link budget may suffice. The IS-2000 coverage for the various data rates coushown on a multiple level coverage plot. Multiple level coverage plots are discusseSection 2.5.3.

Parameter14.4 kbps

FCH

Eb/No 5.6Processing Gain 19.3Base Rx Sensitivity -120.8Max. Allowable Path Loss 137.6


2


mum). Theer ford to an

tennativedipole) forRP isP is

h the

er an. The

r EIRPnsmitt ber andm andatelyverse

2.4.1 Subscriber Unit Tx Power

The subscriber unit’s output power is specified in the standards (Recommended MiniPerformance Standards for cdmaOne or cdma2000 Spread Spectrum Mobile Stationsstandard defines multiple classes and the associated minimum and maximum transmit poweach of the classes. Furthermore, the standards mention that the power may be referenceeffective radiated power (ERP) or to an effective isotropic radiated power (EIRP), i.e. the anis included in the specification. For example, with 800 MHz cellular, the minimum effecradiated power (ERP) for a Class III personal station is listed as 23 dBm, referenced to aantenna. However, for 1.9 GHz PCS, the minimum effective isotropic radiated power (EIRPa Class II personal station is listed as 23 dBm, referenced to an isotropic reference. The Ecalculated with respect to a dipole antenna (antenna gains given in dBd) while the EIRcalculated with respect to an isotropic reference (antenna gains given in dBi). Consult witsupplier of the subscriber units to obtain the specifications of the subscriber unit.

Note: dBd = dBi - 2.14

To illustrate this further, consider the following ERP and EIRP calculations:

As these tables show, if care is not taken to specify all of the values with respect to eithisotropic antenna or a dipole, the path loss calculation can easily be off by approximately 2 dBstandard combines the subscriber’s transmitter power and antenna gain to yield an ERP ovalue. Whereas, Table 2-1 and Table 2-2 show a separate line for the subscriber unit’s trapower (a) and the subscriber unit’s antenna gain (b). Within the initial link budget it may noimportant to have the lines differentiated. For example, having 23 dBm for the transmit powe0 dBd for the antenna gain would yield the same path loss as if the transmit power was 21 dBthe antenna gain was 2 dBi. The differentiation is required in the simulations to approprimodel the forward and reverse links. The subscriber transmitter power will only impact the re

Table 2-4: Subscriber Unit Transmit Power at 800 MHz

with respect to anisotropic antenna

with respect to a dipole

Subscriber Unit Tx Power 23 dBm 23 dBm

Subscriber Unit Antenna Gain 2.14 dBi 0 dBd

25.14 dBm EIRP 23 dBm ERP

Table 2-5: Subscriber Unit Transmit Power at 1.9 GHz

with respect to anisotropic antenna

with respect to a dipole

Subscriber Unit Tx Power 23 dBm 23 dBm

Subscriber Unit Antenna Gain 0 dBi -2.14 dBd

23 dBm EIRP 20.86 dBm ERP


2


ow theand tonitions

versea

adiowithn thats the

of an of

n.

andrafficup toerseCode

on thescriberEb/Nohen ato beCH.ed on. Therious

link, whereas the subscriber antenna gain will impact both links.

In Table 2-2, two additional rows have been added to the RF link budget as a means to shamount of power that would be dedicated to the fundamental or dedicated control channelthe supplemental channel (for reverse data rates greater than 9.6 kbps). The following defiwere obtained from the IS-2000 specifications.

• The Reverse Fundamental Channel (R-FCH) corresponds to a portion of the ReTraffic Channel which carries higher-level data and control information fromsubscriber station to a base station.

• The Reverse Supplemental Channel (R-SCH) corresponds to a portion of RConfiguration 3 through 6 Reverse Traffic Channel which operates in conjunctionthe Reverse Fundamental Channel or the Reverse Dedicated Control Channel iReverse Traffic Channel. The R-SCH will provide higher data rate services, and ichannel on which higher-level data is transmitted.

• The Reverse Dedicated Control Channel (R-DCCH) corresponds to the portionRadio Configuration 3 through 6 Reverse Traffic Channel used for the transmissiohigher-level data and control information from a subscriber station to a base statio

• The Reverse Traffic Channel corresponds to a traffic channel on which datasignaling are transmitted from a subscriber station to a base station. The Reverse TChannel is composed of up to one Reverse Dedicated Control Channel (IS-2000),one Reverse Fundamental Channel (IS-95A/B or IS-2000), zero to two RevSupplemental Channels (IS-2000), and zero to seven Reverse SupplementalChannels (IS-95B).

The subscriber unit transmit power associated with the R-FCH or R-DCCH is dependent upprocessing gain and Eb/No requirements associated with the fundamental channel. The subunit transmit power associated with the R-SCH is dependent upon the processing gain andrequirements associated with the data rate of the R-SCH (19.2, 38.4, 76.8 or 153.6 kbps). Wsupplemental channel is required, some of the subscriber unit’s transmit power needsallocated for the R-FCH or R-DCCH. The remaining transmit power can be utilized for the R-SThe difference in the transmit power between the R-SCH and the R-FCH or R-DCCH is basthe difference of the processing gain and Eb/No requirements of the different channelsfollowing set of equations provide a method to determine the transmit powers for the vareverse traffic channels.

PT = PFCH + PSCH

PSCH = 10^[(Processing_Gain_DeltadB + Eb/No_DeltadB)/10] * PFCH

PT = PFCH + 10^[(Processing_Gain_DeltadB + Eb/No_DeltadB)/10] * PFCH

PFCH = PT / {1 + 10^[(Processing_Gain_DeltadB + Eb/No_DeltadB)/10]}


2


eW)

e

wers, wererates.

adioill be

iven in

otentialto an

e, so itn. Thisortunitynge ofother

erticalhe RFPlan isposed

esired.

Where:

PT is the total subscriber unit transmit power available (mW)

PFCH is the portion of the total subscriber unit transmit power available for threverse fundamental channel or reverse dedicated control channel (m

PSCH is the portion of the total subscriber unit transmit power available for threverse supplemental channel (mW)

The following set of calculations provide an example of how the subscriber unit transmit poassociated with the R-FCH and R-SCH for the 19.2 kbps data rate, represented in Table 2-2obtained. A similar approach would be followed for each of the other supplemental channel

PT = 200 mW

PFCH = 200 /{1+10^[(10*Log(19200/9600)+(3.5-5.6))/10]}

= 89.7 mW

PSCH = 200 - 89.7 = 110.3 mW

a = 10 * Log(PSCH) = 20.4 dBm

The various columns of Table 2-2 reflect reverse link radio configuration 3. Reverse link rconfiguration 3 and only the fundamental channel of the reverse link radio configuration 4 wsupported with Motorola’s first implementation of IS-2000 1X.

2.4.2 Antenna Gains

The subscriber and base station antenna gain values shown in Table 2-1 Table 2-2 are gterms of dBd sinceNetPlan requires calculations to be done using antenna values in dBd(dBd= dBi - 2.14). Since antennas are located at both the base station and the subscriber unit, a perror of approximately 4.3 dB could exist if the antenna gains are referenced with respectisotropic reference instead of to a dipole antenna.

The issue of antenna selection is one which will have a large impact on system performancmust be treated with care. The subscriber unit antenna was discussed in the previous sectiosection will focus on the base station antennas. The base station antennas have more oppfor varying within a design than the subscriber antenna. For example, there exists a wide rahorizontal beamwidths that are available, commonly ranging from 30 to 360 degrees. Someantenna parameters that will impact the RF coverage provided with the antenna are the vpattern, gain and electrical downtilt. Depending on the area that is desired to be covered, tsystem planner can choose between a multitude of antennas. Performing simulations in Netone of the best ways to measure the impact of the given antenna specifications on a prosystem design. Consult with the system operator to determine if a preferred antenna is d


2


or the

d aretrollingapart,

the

will

e ofeenandoffasing

n atlly

ratio

t theGHz

y, iftion of

cle and

it, andof the

. Theof datang the

used inended

Then, consult with the various antenna vendors to obtain the antenna specifications fpreferred antenna.

The density of the sites and the density of the city in which the sites are being implementefactors in determining the type of base station antenna to use. For densely packed sites, conpilot pollution may be of a higher concern than gaining coverage. For sites spaced farensuring adequate coverage will be more of the driving factor.

The following points should be considered when selecting the base station antenna:

• The size and weight of the antenna will impact tower loading or the ability to placeantenna in the optimum position.

• Typically, antenna patterns with narrower horizontal and/or vertical beamwidthsresult in a higher antenna gain, assuming similar lengths.

• The horizontal and vertical beamwidths will have an impact upon the performancthe site. The larger horizontal beamwidths will result in more overlap of signal betwsectors and thus increase the amount of softer handoff between sectors and soft hwith other sites. This increases the amount of interference seen (thus decrecapacity) and reduces the ability to contain pilot pollution.

• The front to back ratio of the antenna will impact the amount of interference seeother sites and the ability to minimize pilot pollution. A high front to back ratio typicadecreases interference and increases capacity. Conversely, a low front to backtypically increases interference and decreases capacity.

• The frequency over which the antenna specifications can operate may impacnumber of antennas required. For example, if the antenna is designed for the 1.9frequency band, it can not be shared with carriers in the cellular band. Additionallthe antenna is able to be used for both the transmit and receive bands, then the opduplexing the transmit and receive signals onto one antenna is possible.

2.4.3 Penetration Losses

Three forms of penetration loss can be applied to an RF system design. They are body, vehibuilding loss margins.

A high percentage of subscriber units sold are portable. This implies that the subscriber untherefore the antenna of the subscriber unit, will be placed near to the person’s body. Someenergy being radiated from the antenna will be absorbed and shielded by the bodyrecommended value, if no body loss value is specified by the operator, is 2 dB. For the caseusers, as the subscriber unit may be held in the hand, away from the head (to allow seeiscreen), the body loss could be reduced to 0 dB.

Since a high percentage of subscriber units sold are portables and these units are oftenvehicles, it is recommended that a vehicle loss factor be included in all designs. The recomm


2


signnot be

RFiablee thes canea, aline in

hiclet wouldfor aould

and thepowerare

y notseveralline

issionitters,

as thewillths oforting

ennas.

value, if no vehicular loss value is specified by the operator, is 6 dB. If the RF system deaccounts for building losses, discussed next, then a separate vehicle loss margin shouldnecessary.

A requirement of the RF system design may be to provide for some level of in-buildingcoverage. The building loss factor is used to account for this. The building loss is highly varand is a function of such items as: construction material, building layout, user location insidbuilding, proximity to the base station, and direction from the base station. Building losserange anywhere from 5 to 40 dB or more. If actual field data is not available for a given arvalue of building penetration may be assumed. The following table can be used as a guidethe absence of field data for the particular environment.

Table 2-6: Example of Building Penetration Losses

The RF link budget should contain either a loss for the building penetration or for the vepenetration but not both. If there is a loss associated with both of these parameters then thaimply that the subscriber is inside a car that is inside of a building. This may be the caseparking garage, but it is probably unlikely that a system design requirement of this nature wbe needed.

2.4.4 Line Loss

Line loss includes all of the losses that are encountered between the base station cabinetbase station antenna, or with respect to a subscriber unit, all of the losses between itsamplifier (PA) and antenna. Since a majority of subscriber units for a mobility systemportables, there is minimal line loss; therefore, RF line loss at the subscriber unit is typicallconsidered in the link budget. However, the line loss at the base site can be considerable (dB of loss). The example RF link budget provided in Table 2-1 or Table 2-2 only reflects theloss at the base site.

The base station RF line loss calculations include such losses as: top jumper, main transmline, bottom jumper, lightning arrestors (surge protector), connectors, duplexers, splcombiners, and couplers (see Figure 2-1).

From a budgetary or approximation viewpoint, one RF line loss value could be assumedtypical value for all of the sites. In real world situations, however, it is rare that one loss valuebe common for all of the sites. Some sites (and sectors) may have longer or shorter lengtransmission line due to the BTS equipment being placed at the bottom of a tall antenna suppstructure or due to the BTS equipment being located on the top of a building nearer to the ant

Environments Building Penetration Loss (dB)

Dense Urban 20Urban 15

Suburban 10Rural 8


2


uratelythe RFe baselisted

ting atat the0 feet

uencye mayingof theeter of

In performing propagation predictions, it is important that each sector is represented as accas possible. Therefore, an analysis should be done for each particular sector to determineline loss. This calculation should include all losses between the base station antenna and thstation cabinet such as those components depicted in Figure 2-1. The value of the line lossin Table 2-1 or Table 2-2 is an example which assumes that the base station will be opera1.9 GHz and the main transmission antenna run is 100 feet. Additionally, it is assumed thmain transmission line is a 1-5/8” heliax cable which has approximately 1.25 dB loss per 10at 1.9 GHz. Another 0.75 dB was assumed for jumpers and connectors.

Figure 2-1: Typical Components in the RF Cabling Run

When estimating the amount of transmission line loss, keep in mind that the line loss is freqdependent. Transmission cables are more lossy at higher frequencies. At 800 MHz, a 7/8” linsuffice, but a 1-5/8” line for 1.9 GHz may be required to maintain a similar loss. The followtable shows an example of the difference that can exist in transmission line loss as a functionoperating frequency. Also, the table shows that the amount of loss is dependent on the diamthe cable, such that the loss increases as the diameter decreases.

Antenna

(A) Top Jumper

(B) Main Transmission Line

(C) Antenna Surge Protector

(D) Jumper to Directional Coupler

(E) Directional Coupler

(F) Jumper to Duplexer

(H) Jumper to Tx and Rx Antenna Port

BTS

Waveguide Entry Port

Note: Each Jumper consists of:Two connectors andOne line

(G) Duplexer


2


or the

e, theationsre atBTScatedneed

mesg orwith

ing

’s linkf the

f onect the

eaconuse ato anh thesplitterf the

r pilot

with aoes it

Consult the transmission line vendor for the specifications of the installed transmission linesystem operator if actual field measurements have been made.

Additionally, the reference point used in the BTS specifications should be known. For instancduplexer loss and its jumpers/connectors to the BTS may already be included in the specificfor the base station’s noise figure and PA output. Typically, the specifications for the BTS athe top of the frame. Therefore, if the duplexer or other components are located within theframe, additional loss would not need to be factored in. If, on the other hand, the device is loexternal to the BTS frame and not already included in the BTS specification, this loss wouldto be added into the line loss.

For sites with multiple CDMA carriers, the Rx signal distribution and the Tx combining scheare typically addressed within the equipment specifications of the BTS frame. If combininsplitting of the RF signal is being performed external to the BTS frame, the loss associatedthe combining or splitting would need to be added to the link budget.

The previous line loss information reflects more conventional site installations. The followthree scenarios reflect less conventional site configurations that may exist in a system.

2.4.4.1 Pilot Beacon

Installing a stand-alone pilot beacon at the site may impact the conventional co-located sitebudget. If the stand-alone pilot beacon has its own transmit antenna, the link budget oconventional site will not be impacted. However, if the pilot beacon transmits its signal out oof the conventional site’s antennas, the loss associated with the combining device will impalink budget of the conventional site.

There are several types of devices that can be used to combine the signals from the pilot band the conventional site onto the same antenna. Typical installations of pilot beaconsdirectional coupler. Another option is to use a circulator, as long as it is used to connectexisting receive only antenna that is currently not being used to transmit signals (althougantenna does need to be able to support the transmit spectrum for the pilot beacon signal). Acould also be used but may have too much loss, thus sacrificing the performance oconventional site. Figure 2-2 portrays a two carrier site with SC6xx equipment and an outdoobeacon with a directional coupler used to share an existing Tx/Rx antenna.

NetPlan can not properly model the scenario of a stand-alone pilot beacon sharing antennasco-located site. NetPlan does not allow for differentiation between Tx and Rx paths, nor d

Table 2-7: Example of Main Transmission Line Losses:

Loss @ 850 MHz Loss @ 1.9 GHz

7/8” Foam Dielectric Coaxial Cable 1.23 dB/100’ 1.97 dB/100’

1-5/8” Foam Dielectric Coaxial Cable 0.767 dB/100’ 1.25 dB/100’


2


MAsamethe

ouldd withever,same

dget,ce, thes. The

rencese pilotduce

ation.worthensate

withinst case

allow for modeling each Rx path (main and diversity) separately. Additionally, the NetPlan CDSimulator does not allow for different carriers on two separate antennas associated with thesector. Referring to Figure 2-2, the introduction of the pilot beacon (Carrier 3) causestransmission paths associated with Carrier 1 and Carrier 2 to now be different. Ideally, this wbe modeled by assigning a different effective gain value to the transmission path associateCarrier 1 and the transmission path associated with Carrier 2 and the pilot beacon. HowNetPlan does not allow for the user to assign different carriers to different antennas in thesector.

Within NetPlan, to try and account for the pilot beacon’s impact to the co-located site’s link buvarious manipulations to the conventional site’s parameter values could be made. For instanbase station noise figure could be adjusted to compensate for an imbalance in the Rx pathbase station noise figure and the pilot power could be adjusted to compensate for any diffein the Tx paths and differences between the Rx and Tx paths. However, compensating for thbeacon in this way (by adjusting some of the site parameters) is fairly complex and may proresults that need to be interpreted differently than results from a conventional site configurSince the loss associated with the directional coupler is typically less than a dB, it may not bethe additional complexity and concerns that are involved in adjusting the parameters to compfor the pilot beacon impacts. Instead, it may be better to ignore the pilot beacon impacts.

Figure 2-2: SC6xx Two Carrier Site with the Outdoor Pilot Beacon

There are a couple of approaches that can be used to model this type of site configurationNetPlan. For a best case scenario, the impact of the pilot beacon could be ignored. As a wor

Main RxCarrier 1 Tx

TRX

LPA

Diversity Rx

Duplexer

TRX

LPA

Duplexer

ERXDC RXDC ERXDC RXDC

Carrier 2 Tx

Pilot BeaconSC6xx SC6xx

Directional Coupler(10 dB Coupling Loss)(0.7 dB Insertion Loss)

ERXDC - Expansion Receive Distribution CardLPA - Linear Power Amplifier

RXDC - Receive Distribution Card

PB - Pilot BeaconTRX - Transmit / Receive Module

PB (Carrier 3) TxNote: Both antennaare associated withthe same sector.


2


ler orts all

2, the

d thedent

iseo bemperof the000gn

ere isThecribertenna, thustenna

e lossdix 3:ion

scenario, the loss associated with the pilot beacon (insertion loss of the directional coupcirculator and any additional RF jumpers) could be viewed as additional line loss that impacof the antennas in the sector. For instance, using the configuration shown in Figure 2-following would be added to the line loss of the co-located site for a worst case.

• The loss associated with the RF cabling between the duplexer in the SC6xx andirectional coupler in the pilot beacon unit. The amount of loss would be depenupon the length and characteristics (dB loss per length) of the cable.

• The insertion loss associated with the directional coupler (0.7 dB).

2.4.4.2 Tower Top Amplifier

If the sector is utilizing Tower Top Amplifiers (TTA), sometimes referred to as Low NoAmplifiers or Mast Mounted Amplifiers, then a cascaded noise figure calculation will need tperformed. Roughly, for sectors with TTAs, the line loss can be reduced to the loss of the juand connectors between the antenna and the TTA for the receive path. The full impacttransmission run still applies to the transmit path. Refer to Chapter 4 of the “CDMA/CDMA21X RF Planning Guide” (March 2002) and Appendix A1: “Tower Top Amplifiers - DesiConsiderations” of this document for further information.

2.4.4.3 Subscriber Line Loss

As mentioned in Section 2.4.4, the majority of subscriber units are portables. Therefore, thminimal RF line loss at the subscriber unit and it is typically not considered in the link budget.RF link budget shown in Table 2-1 or Table 2-2 does not contain a separate entry for subsline loss. For a fixed wireless system, the Fixed Wireless Terminal (FWT) may have an anconnected directly to the unit or the antenna may be installed on the outside of the buildingrequiring a transmission run from the FWT to the antenna. For the case with an external anconnected to an FWT, this line loss needs to be accounted for in the RF link budget. This linwould be the total loss encountered from the FWT to the external antenna. Refer to Appen“WiLL System Design” for further discussion on fixed systems. This type of FWT configuratwould also utilize an appropriate antenna gain value associated with the external antenna.

2.4.5 Base Station Rx Sensitivity

Base Rx Sensitivity = kT + B + NF + Eb/No - PGwhere:

kT is the Thermal Noise level in dBm/HzB is the Bandwidth of the CDMA carrier in dB-HzNF is the noise figure of the equipment (base station) in dBEb/No is the acceptable energy over noise (in dB) to yield a desired % FERPG is the processing gain in dB


2


s to

outputl baseramesBTSa sixTop

uired.for

plier6 for

F linkd upondinglly usedmationThey), with

s thatthe FER

2.4.5.1 Thermal Noise (kT)

The term ’k’ is Boltzmann’s constant [1.38 x 10-23 W/(Hz K)].

The term ’T’ is room temperature expressed in degrees Kelvin [290 K].

The thermal noise, kT, would be 4 x 10-21 W/Hz or -204 dBW/Hz or -174 dBm/Hz.

2.4.5.2 Bandwidth (B)

The bandwidth of the IS-95 or IS-2000 1X CDMA carrier is 1.2288 MHz, which correspond60.9 dB-Hz [(10 x log (1.2288 x 106)].

The bandwidth limited noise floor, kTB, based on the values provided above, would be4.918 x 10-15 W or -143 dBW or -113 dBm.

2.4.5.3 Noise Figure (NF)

Noise figure is a measure of the degradation in signal to noise ratio between the input andports of a network (receiver). The noise figure is dependent upon the equipment. Typicastation noise figures can be in the 4 to 4.5 dB range. This means that some of the BTS fshipped from the factory will have a noise figure greater than 4 to 4.5 dB and some of theframes will have a noise figure less than this. A higher noise figure of 6 to 7 dB (representingsigma value) is normally used in a design to provide for a higher level of confidence. If TowerAmplifiers are used, a BTS system noise figure (cascaded noise figure) value will be reqRefer to Appendix A1: “Tower Top Amplifiers - Design Considerations” discussing TTAsadditional information.

A subscriber noise figure of 10 dB is typically used for the downlink path. Consult with the supof the subscriber units to obtain the specifications for the subscriber unit. Refer to Chapteradditional information for entering the subscriber noise figure into NetPlan.

2.4.5.4 Reverse Link Eb/No

In initial CDMA system design phases, an estimate is made for the Eb/No value used in the Rbudget. The reverse link Eb/No values that are used in the RF link budget calculations depenmany factors (i.e. the FER (as a function of the type of service), the bit rate, multipath fachannel, receive antenna diversity, subscriber speed, etc.). The Eb/No values that are typicain the RF link budgets are shown in the Table 2-8. These values are used as a first approxito gain an insight into the reverse RF path coverage prior to performing CDMA simulations.assume flat fading and worst case speed (30 km/h @ 1% FER for voice and 5% FER for datadiversity and perfect decorrelation.

More detailed design phases use the NetPlan CDMA Simulator to incorporate Eb/No valueare obtained from a set of curves based upon the speed of the subscriber, the delay spread,


2


ders.

idestPlan

tware

ofarve athe

XXmentes a.8 dBg. anor

target criteria, chipset, and air interface.

Table 2-8: Reverse Link Eb/No Values for Different Chipsets

Note:

• RS1 signifies rate set 1 (8 kbps) vocoders and RS2 is for rate set 2 (13 kbps) voco

• RC3 signifies IS-2000 reverse link radio configuration 3.

• RC4 signifies IS-2000 reverse link radio configuration 4. The IS-2000 standard provfor multiple supplemental rates based on the 14.4 kbps fundamental rate, but Neand Motorola infrastructure will initially support only the fundamental RC4 rate.

• MCC4s are no longer supported after CBSC release R2.5. If the system has sofnewer than this, there should be no MCC4s installed in the RF BTS system.

• Motorola has incorporated its own receiver channel IC (MAXX) within some modelsthe modem channel cards (MCC and MAWI). This MAXX chipset will provide similperformance as the CSM chipset. The NetPlan CDMA Simulator does not haseparate set of Eb/No curves for the MAXX chipset. If the BTS equipment hasMAXX chipset, the user will want to choose the CSM Eb/No curves.

• Further advances by Motorola to the MAXX chipset have resulted in the EMAchipset. Motorola’s SC4812, SC4840, and SC2440 CDMA base station equiputilize the MCC channel cards that have this chipset. The EMAXX design providreduction in the reverse Eb/No requirements. This reduction corresponds to a 1improvement in the CDMA reverse link budget as compared to the CSM chipset (e.Eb/No value of 5.5 dB for 13 kbps using the BTS with EMAXX versus 7.3 dB fCSM).

IS-95 IS-95 IS-95 IS-95 IS-2000

RS1 Eb/No (dB) 9.0 7.0 7.0 5.2 -RS2 Eb/No (dB) 9.3 7.3 7.3 5.5 -RC3 - 9600 Eb/No (dB) - - - - 5.6RC3 - 19200 Eb/No (dB) - - - - 3.5RC3 - 38400 Eb/No (dB) - - - - 3.0RC3 - 76800 Eb/No (dB) - - - - 2.5RC3 - 153600 Eb/No (dB) - - - - 2.1RC4 - 14400 Eb/No (dB) - - - - 5.6Chipset BSM CSM MAXX EMAXX CSM5000Channel Element Card MCC-4 MCC-8 MCC-8M

MAWIMCC-24EMCC-8E

(Only found in theSC4840, SC2440,

SC4812 BTS)

MCC-1X


2


r the

ich

the

cthipbe

000

videdvaluesmental, anentalocolsERfactording

on the

5 ratease is

s rate

• Some of the EMAXX benefits over the CSM chipset are:

1. Better indoor coverage (provided forward link PA is large enough to compensate foreverse link improvement).

2. Potentially larger site RF footprint allowing sites to be placed further apart (whrequires a higher power forward link PA).

3. More reverse link margin for pilot optimization (allowing for a better balance offorward and reverse handoff regions).

4. Substantially reduced probability of being reverse link capacity limited.5. Extended subscriber unit (portable) battery life.

• From an RF link budget consideration, the EMAXX chip performance will only affethe reverse link. In order to match the reverse link improvement of the EMAXX cset, the forward link will require additional power. Therefore, it will need todetermined if there is sufficient PA power to support the reverse link increase.

• The MCC-1X multi channel card contains the CSM5000 chipset. The CSM5provides for the IS-2000 forward modulation and reverse demodulation.

• For IS-2000 reverse link radio configuration 3, there are separate Eb/No values profor the fundamental channel rate and each supplemental channel rate. The Eb/Nofor the supplemental channel rates (19.2 kbps and greater) are less than the fundaEb/No. Two main factors are contributing to this. With the fundamental channelFER of 1% is assumed. The control channel information carried on the fundamchannel requires the better error rate. Whereas, it is viewed that the radio link prot(RLP) will allow for relaxed FER requirements for the supplemental channel. An Fof 5% is assumed for the supplemental channel rates. Turbo coding is the othercontributing to the lower Eb/No value for the supplemental channels. Turbo coimproves upon the error correction at the higher data rates.

The appropriate Eb/No value to be used in the RF link budget should be selected based upsystem design assumptions (BTS equipment and vocoder rate).

2.4.5.5 Processing Gain (PG)

The processing gain is the result of the bandwidth (B) divided by the data rate (R). For IS-9set 1 (8 kbps vocoder), the data rate is 9600 bps. The resulting processing gain for this cobtained as follows:

PG = 1228800 / 9600 = 128

PGdB = 10 * Log (128) = 21.1 dB

The following table provides the data rate (R) and the resulting processing gain for the variousets and radio configurations that will be available in NetPlan.


2


usersthat is

is anucingacityuationadingrder

ered.will beveragers or

, basede theargerwould

linkystemith the

Table 2-9: Processing Gain

2.4.6 Interference Margin

The interference margin accounts for the increase of the operating noise floor due to otherappearing as noise to the BTS. The interference margin is estimated using a calculationbased on the expected loading of the system. The calculation that is typically used is:

-10 * log(1- % loading)

For example, assuming 50% loading, the interference margin would be 3 dB. The 50%approximation used in this example link budget to maximize coverage at the expense of redcapacity. This approximation will vary depending on the specific design requirements (capand coverage). Expected noise rise is better estimated from simulation studies, but this eqprovides an initial estimate. The system should be designed for no greater than 75 to 80% loof a CDMA carrier (corresponding to approximately 6 to 7 dB of interference noise rise) in oto avoid the instabilities of operating too close to the reverse pole.

The system may initially be lightly loaded, but the future load requirements should be considFor instance, if a design assumes that the sites are lightly loaded, the interference noise riselow and therefore the sites can be spaced further apart. When traffic demands increase, coof the sites will shrink thereby causing holes in the coverage to appear. Additional RF carriesites would be required to gain the coverage back. A better design approach is to determineon projected traffic, the amount of traffic load that would be desired and to use this to placsites closer together at the beginning. Initially, with the sites lightly loaded, there would be a lamount of overlap between adjacent sites. As traffic levels increase, the coverage of the sitesshrink but there would still be sufficient overlap of the adjacent sites.

Lab results indicate that the EMAXX chipset in CDMA BSS Release 2.8 provides a reversecoverage improvement of approximately 3.0 dB over the CSM chipset in Release 2.7 for a swith an average or greater rise (average rise greater than 2 dB). This 3.0 dB improvement w

Air Interface Reverse Link Radio Configurations Data Rate (bps) Processing Gain (dB)

IS-95 Rate Set 1 - Standard 8 kbps Vocoderor EVRC (Enhanced Variable RateCoder)

9600 21.07

IS-95 Rate Set 2 - 13 kbps Vocoder 14400 19.31IS-2000 1X Reverse Link Radio Configuration 1 9600 21.07IS-2000 1X Reverse Link Radio Configuration 2 14400 19.31IS-2000 1X Reverse Link Radio Configuration 3 9600 21.07IS-2000 1X Reverse Link Radio Configuration 3 19200 18.06IS-2000 1X Reverse Link Radio Configuration 3 38400 15.05IS-2000 1X Reverse Link Radio Configuration 3 76800 12.04IS-2000 1X Reverse Link Radio Configuration 3 153600 9.03IS-2000 1X Reverse Link Radio Configuration 4 14400 19.31


2


eavy

e 1.8dB

et forge by

erage

B of, 1.8

n theported

e linkmentilable

rseillwer

r. Theat thegatherat 800

to theills orarea

EMAXX chipset can be summarized as follows:

• 1.8 dB decrease in Eb/No requirement (discussed in Section 2.4.5.4)

• 1.2 dB potential decrease in Interference Margin (for a system with an average to htraffic load)

With a lightly loaded system, the second bullet above is not as significant. In this case, only thdB of Eb/No benefit is gained. Therefore, EMAXX improves reverse coverage by 3 dB (1.8Eb/No plus 1.2 dB interference margin improvements) when compared to the CSM chipssystems that are designed for average rise levels of 2 dB or greater. It improves coveraapproximately 1.8 dB (only Eb/No improvement) for systems designed to sustain lower avrise levels of less than 0.5 dB.

For example, assume a system initially designed with the CSM or MAXX chipset and 3 dinterference margin. If the assumed BTS was replaced with a BTS that supports the EMAXXdB (3 - 1.2 dB of interference margin improvement) of interference margin would be used iRF link budget instead of 3 dB. This is assuming that the same traffic per sector would be supwith the EMAXX as by the CSM or MAXX chipset.

While about 3 dB improvement (Eb/No plus interference margin) can be achieved in reverscoverage comparing CSM to EMAXX, given the same system and system load, the improveto capacity can only be 1.8 dB (due to decreased Eb/No). The rise improvement is only avaif the same capacity is assumed for CSM and EMAXX.

From an RF link budget consideration, the EMAXX chip performance will only affect the revelink. In order to match the reverse link improvement of the EMAXX chip set, the forward link wrequire additional power. Therefore, it will need to be determined if there is sufficient PA poto support the reverse link increase.

2.4.7 Ambient Noise

The ambient noise defines the environmental noise that is in excess of kTB for the sectoaccepted norm for this value is 0 dB at 1.9 GHz and 2.0 dB at 800 MHz. If the ambient noisesector is known, it should be added to the link budget. Noise floor tests can be performed toa sufficient amount of data to determine an appropriate value to use. This is more of an issueMHz as opposed to 1.9 GHz.1

2.4.8 Shadow Fade Margin

The shadow fade margin (also known as slow or log-normal fading margin) correspondsvariation in mean signal level caused by the subscriber passing through the shadows of hbuildings. The fade margin is the amount of margin necessary to achieve the requiredreliability (as per Jakes’ equations2) for a given standard deviation.

1. Lee, William C.Y., “Mobile Communications Engineering”, Copyright 1982 McGraw-Hill Inc., pp. 33-40


2


sicallyed RFary by

typeses.

esired

in the

also

,

The standard deviation is a measured value that is obtained for various clutter types. It barepresents the variance (log-normally distributed around the mean value) of the measursignal strengths at a certain distance from the site. Therefore, the standard deviation would vclutter type. Typical standard deviation values range from 4 to 8 dB. Rural or open clutterwould typically have lower standard deviation levels than the suburban or urban clutter typ

The following table provides several examples of the fade margin required to achieve a dsingle cell area reliability as determined from Jakes’ single cell reliability equations.

The following observations can be made concerning the fade margin:

• As the standard deviation increases, the amount of fade margin required to maintasame area reliability also increases, assuming the same propagation slope.

• As the level of area reliability increases, the amount of fade margin requiredincreases, assuming the same standard deviation and propagation slope.

2. Jakes, W.C., “Microwave Mobile Communications”, IEEE Press Reissue 1993 (Wiley, New York, 1974)pp. 125-127

Table 2-10: Single Cell Fade Margins Required for Various Area Reliabilities

Propagation Slope Std. Dev.

Shadow Fade Margin to Yield Single Cell AreaReliability

90% 95% 97%

30 dB/decade 10 dB 8.2 dB 12.1 dB 14.5 dB
















2


arginandard

ndoffa linkup tosincet canor areaingles. For40 dBargin

at arein

95%f theumed.ally5% or

arginity ofof 40l areald be.

. Thisis willumberbeingre be

ming arading

itledty”ur”fore,

• As the propagation slope (path loss exponent) increases, the amount of fade mrequired to maintain the same area reliability decreases, assuming the same stdeviation.

The fade margins provided in Table 2-10 are for a single site. When multiple sites and soft haare accounted for, there is an increased probability of meeting a given signal strength. Inbudget spreadsheet analysis, the benefit from multiple sites and soft handoff can beapproximately 3.5 dB for a cluster of sites. For isolated sites, there would be no improvementthere would be no sites to enter into soft handoff with. Soft handoff is not an absolute gain bube viewed as a reduction in the fade margin requirement needed to meet a desired edgereliability goal. For the RF link budget approach, the composite fade margin would be the ssite shadow fade margin minus the benefit associated with soft handoff and multiple siteexample, assuming a 8.3 dB shadow fade margin (95% reliability, 8 dB standard deviation,path loss slope) and 2.7 dB benefit from soft handoff and multiple sites, the composite fade mwould be 5.6 dB (8.3 minus 2.7).

Motorola has performed various simulations and generated some area reliability curves threpresented in the “CDMA/CDMA2000 1X RF Planning Guide” (March 2002). The curvesFigure 4-11 within that document show that 4.7 to 5.6 dB fade margin is required to reacharea reliability for a sector site. The curves show that the area reliability is a function oconfiguration of the site, as well as the standard deviation and site-to-site correlation assThese curves include the benefits of soft handoff and multiple sites. Motorola typicrecommends the 5.6 dB shadow fade margin to design systems with an area reliability of 9slightly better.

The shadow fade margin value shown in Table 2-1 and Table 2-2 is an example of the fade mrequired. It includes the effects of soft handoff and multiple sites to achieve an area reliabil95 to 97%. (An 8 dB standard deviation for log-normal shadowing and a propagation slopedB per decade were used in the simulation.) This value will vary depending on the actuareliability that the system is designed to achieve. The minimum area reliability that shouassumed is 90%. A typical recommendation is to design the system for 95% area reliability

If a larger fade margin value is assumed, the maximum allowable path loss would be reducedwould result in the sites having a smaller radii and therefore being located closer together. Thlikely increase the number of good connections in the simulation step (assuming that the nof subscribers has not changed), thus resulting in a higher RF reliability, which is what wassought. Smaller fade margin values mean that the sites will have larger radii and therefoplaced further apart. Thus, the number of good connections will be lower.

The number of good connections can be improved by placing the sites closer together (assularger fade margin) or by reducing the number of users being served by the sector/site (tcapacity for coverage).

Note: Within the Edit>Site editor window in NetPlan, the Propagation tab includes a box t“Reliability Contour”. Inside this box is a parameter listed as “Coverage Reliabiliwhich has a default value of 90%. The two parameters within the “Reliability Contobox are only used when Contour Reliability plots (polygons) are generated. There


2


ity”

odelhe RFesignthe

to the

ld notns toor

dgetf theaconduceare co-e wouldudedtheree pilot

t intos, therage)

ngthThesentennaehiclevalue.tenna

ratevaluemetereivertor’s

there will be no differences produced in the CDMA images if the “Coverage Reliabilvalue is changed since this value has no impact on CDMA images or statistics.

2.5 Determining NetPlan Inputs to Estimate Coverage

The information contained within the link budget is used in conjunction with a propagation mto estimate the coverage of each site. As mentioned before, NetPlan is used along with treverse link information in a CDMA system design to estimate the system coverage. This dis followed by a more detailed design using the NetPlan CDMA Simulator to analyze bothforward and reverse links. Many of the link budget parameters are also used as inputssimulation studies.

When determining an initial estimate of coverage, the coverage from pilot beacon sites shoube included. Pilot beacon sites, by definition, do not support traffic channels but are a meatransition the call from one CDMA carrier to another CDMA carrier on a different frequencyfrom a CDMA Base Transceiver Station (BTS) to an Analog BTS. Therefore, the RF link buinformation concerning the pilot beacon is not required for generating the initial estimates ocoverage that can carry traffic. As mentioned in Section 2.4.4.1, the impact of the pilot becombining hardware on the co-located site’s RF link budget can be ignored, in order to promore of a best case scenario for the coverage prediction. If that is the case, those sites thatlocated with a stand-alone pilot beacon should be analyzed to ensure that adequate coveragstill exist if the effects of the pilot beacon combining losses on the co-located site were incl(i.e. if the maximum allowable path loss was reduced slightly). For the majority of cases,should be sufficient RF coverage overlap between adjacent sites, such that the inclusion of thbeacon impacts would not produce any noticeable effects.

Much of the link budget information is used to determine the specific values that are inpuNetPlan. Specifically, when generating coverage based on maximum allowable path losinformation is used to calculate the system cutoff level (used when viewing or plotting coveand sector “ERP” levels.

Since NetPlan allows for only one cutoff value for the entire system (Minimum Signal Streparameter), all sector specific variables need to be accounted for in the sector’s “ERP” term.variations include such parameters as noise rise, building loss, vehicle loss, line losses, and agains. “ERP” is referred to here in quotes because if all of the variables of a sector, such as vlosses or building losses, are accounted for in this term, then it is really no longer a true ERPA true ERP (effective radiated power) refers to the power that is being radiated from an an(which includes only the power out of the base station, the line losses, and antenna gain).

All of the terms in a link budget must be accounted for within NetPlan to obtain an accucoverage prediction. Therefore, the link budget terms must either be included in the cutoffor in the sector’s “ERP”. In order to make it easier to determine where each link budget parashould be accounted for (cutoff level or “ERP” value), it is recommended to use the BTS recsensitivity value as the cutoff value and account for all other link budget terms in the sec“ERP”.


2


twotPlan-1 and

n, thehen

le 2-1

2.5.1 Example Calculations of NetPlan Values

Using the IS-95 and IS-2000 link budgets provided in Table 2-1 and Table 2-2, the followingtables show the Minimum Signal Strength and Rv “ERP” values that would be used for the Nemaximum allowable path loss coverage studies. Only a subset of the columns from Table 2Table 2-2 are shown here for discussion purposes.

Table 2-11: NetPlan Minimum Signal Strength Parameter

Table 2-12: NetPlan Rv “ERP”

As a double check to make sure that the proper values have been calculated for NetPlaNetPlan Rv “ERP” (Table 2-12) and the Minimum Signal Strength parameter (Table 2-11) wcombined should equal the maximum allowable path loss calculated in the link budget (Tabor Table 2-2).

Reverse Link Parameter Unit Example13 kbps Link

Budget

Example8 kbps Link

Budget

Example19.2 kbps

R-SCH LinkBudget

kTB dBm h -113.1 -113.1 -113.1

Noise Figure dB j 6 6 6

Eb/No dB k 7.3 7.0 3.5

Processing Gain dB l 19.3 21.1 18.1


dBm m -119.1 -121.2 -121.6

Minimum Signal Strength Parameter dBm y -119.1 -121.2 -121.6

Reverse Link Parameter Unit Example13 kbps Link

Budget

Example8 kbps Link

Budget

Example19.2 kbps

R-SCH LinkBudget

Subscriber Unit Tx Power dBm a 23 23 20.4

Subscriber Unit Antenna Gain dBd b -2.1 -2.1 -2.1

Body Loss dB c 2 2 2

Vehicle Loss dB d 6 6 6

Building Loss dB e 0 0 0

Base Antenna Gain dBd f 14.5 14.5 14.5

Line Loss dB g 2 2 2

Interference Margin dB n 3 3 3

Ambient Noise Rise dB p 0 0 0

Shadow Fade Margin dB r 5.6 5.6 5.6

NetPlan Rv “ERP”= a+b-c-d-e+f-g-n-p-r

dB x 16.8 16.8 14.2


2


editor.

2.5.2 Entering NetPlan Values

The NetPlan Rv “ERP” values may be entered via the Site editor window. Access to the Sitewindow is gained through a pull down menu (see Figure 2-3: "Edit Site - Pull Down Menu")

Table 2-13: Double Check of NetPlan Values

Parameter Unit Example13 kbps Link

Budget

Example8 kbps Link

Budget

Example19.2 kbps

R-SCH LinkBudget

NetPlan Rv “ERP” dB x 16.8 16.8 14.2

Minimum Signal Strength dBm y -119.1 -121.2 -121.6

Calculated Path Loss from NetPlan Values= x-y

dB 135.9 138.0 135.8

Max. Allowable Path Loss fromthe RF Link Budget

dB 135.9 138.0 135.8


2


beent beationnna

. Seeenterbeenite and

Figure 2-3: Edit Site - Pull Down Menu

This action opens up the Site editor window as seen in Figure 2-4: "Edit Site". Two areas havecircled in this figure. The area marked “Area - A Common Input” denotes inputs which musdefined whether the site is analog or CDMA. These include name, location, propagboundaries, etc. (Note that AMSL in not a required field.) The area marked “Area - B AnteInput” denotes inputs which are specific to each sector “antenna”. It is in Area - B that the NetPlanRv “ERP” values calculated for each sector will be entered into the Rv ERP boxes for the siteFigure 2-5: "Edit Site - Rv ERP". The Analog Active button needs to be selected in order todata in the Rv ERP fields. If the fields are not displayed, verify that AMPS technology hasselected (Configure>Context). Also, the other parameters: antenna model, height, bore sdowntilt, plus the Parameter Set and GEO Set need to be set properly.


2


Figure 2-4: Edit Site

Area - ACommon Input

Area - BAntenna Input


2


ERP,system

lationenusutput

s.

s thees. Inimumw the

streetugh soehiclemumg “on-

servert are

cally,imumble asent

Figure 2-5: Edit Site - Rv ERP

2.5.3 NetPlan Image Parameters and Multiple Level Plots

In order to generate coverage for a system within NetPlan, the site specific values (such asantenna parameters, etc.) need to be set as well as certain system parameters. Theparameters include the Output Resolution (found via the pull-down menus Configure>SimuParameters>Geographic) and the Minimum Signal Strength (found via the pull-down mConfigure>Simulation Parameters>Combined Site Propagation). See Figure 2-6: "OResolution" and Figure 2-7: "Minimum Signal Strength" for details.

An output resolution of 100 meters or less is required for images to provide accurate result

The Minimum Signal Strength parameter is an important parameter since it determinethreshold below which signal strength data will not be available in best server/sector imagother words, regardless of whether the site propagation data was obtained for lower minsignal strengths, the best server/sector image will contain no data for signal strengths belodefined minimum. Therefore, when designing a system to include in-vehicle loss but on-subscriber coverage is also desired, then the minimum signal strength is to be set low enothat the on-street values are included. [For example, when designing a system with 6 dB in-vloss and a signal strength level of -119 dBm (to show in-vehicle coverage), then the minisignal strength value would need to be at least -125 dBm to view a best server plot showinstreet” levels.]

Since the Minimum Signal Strength parameter determines the extent to where bestpropagation data is available, it may have an impact upon the traffic distribution maps thagenerated. Refer to Chapter 5 for additional information on the creation of traffic maps. Basithe traffic will be distributed over the area where there is best server propagation data. A minsignal strength value of -125 dBm will have a larger area where propagation data is availacompared to a value of -119 dBm. The traffic load to be simulated in the CDMA environmwould be spread across a larger region with the -125 dBm value versus the -119 dBm.

Rv ERP (dBm)Analog Active

Button


2


Figure 2-6: Output Resolution


2


age,ehiclent cutoffvia thenextvals”toff

Figure 2-7: Minimum Signal Strength

By setting different levels when viewing or plotting a Receive Voice Best Signal Strength imdifferent coverage regions can be shown such as areas of in-building coverage, in-vcoverage, or on-street subscriber coverage. These levels are accessed by selecting differepoints when assigning colors and values to the image sliders. The sliders are accessed“Layer” button to open the Layers window. With the image displayed, the ellipsis button [...],to the Image button, is selected to open the “coloring” window. From there select the “Interbutton which will open the window with the coloring sliders. From here, different colors and cu


2


etails.

uildingis 10

showhicles.) Toifferent

settings can be assigned for the image. See Figure 2-8: "Setting Image Cutoff Levels" for d

Figure 2-8: Setting Image Cutoff Levels

As an example, assume the loss factors being used in the system design are as follow: in-bloss factor in the dense urban region is 20 dB, in-building loss factor for a residential regiondB, and in-vehicle loss factor of 6 dB. Assume further that the level being used for a cutoff toin-vehicle coverage is -119 dBm. (This assumes that the “ERP” calculations include the in-veloss but not the 20 dB and 10 dB building loss values for dense urban and residential regionshow a plot that highlights the areas where coverage is expected to be good based on the d

1

2

3

4


2


iber),mage

riousata ratee has ahavet data. Theto bech ofto the

Resk

Su

Su

Bo

Ve

Bu

Ba

Lin

Inte

Am

Sh

Ne= a

Re

Ad= z

loss factors (in-building dense urban, in-building residential, in-vehicle, on-street subscrdifferent levels would be set up as depicted by the noted values in Figure 2-8: "Setting ICutoff Levels":

Note Area Type Image Cutoff Level1 in-building dense urban -105 dBm2 in-building residential -115 dBm3 in-vehicle -119 dBm4 on-street subscriber -125 dBm

A similar approach could be done to reflect the coverage differences that might exist for the vacdma2000 1X data rates. For instance, there could be a cutoff level associated with each d(9.6 kbps, 19.2 kbps, 38.4 kbps, 76.8 kbps and 153.6 kbps). For this situation, each data ratdifferent subscriber unit transmit power, Table 2-2 and by virtue of Section 2.5.1 would thena different Rv “ERP” value. To generate one image that reflects the coverage of the differenrates, one common Rv “ERP” value would be required to reflect one of the data speedsdifferences of the subscriber unit transmit powers for the various data rates would needreflected in the Minimum Signal Strength level. Table 2-14 shows an example of setting eathe data rates to a common Rv “ERP” value. Table 2-15 shows the adjustment value appliedMinimum Signal Strength level.

Table 2-14: Rv “ERP” Adjustment

verse Link Parameter Unit Example9.6 kbps

R-FCH LinkBudget

Example19.2 kbps

R-SCH LinkBudget

Example38.4 kbps

R-SCH LinkBudget

Example76.8 kbps

R-SCH LinkBudget

Example153.6 kbp

R-SCH LinBudget

bscriber Unit Tx Power dBm a 23 20.4 21.4 22.0 22.4

bscriber Unit Antenna Gain dBd b -2.1 -2.1 -2.1 -2.1 -2.1

dy Loss dB c 2 2 2 2 2

hicle Loss dB d 6 6 6 6 6

ilding Loss dB e 0 0 0 0 0

se Antenna Gain dBd f 14.5 14.5 14.5 14.5 14.5

e Loss dB g 2 2 2 2 2

rference Margin dB n 3 3 3 3 3

bient Noise Rise dB p 0 0 0 0 0

adow Fade Margin dB r 5.6 5.6 5.6 5.6 5.6

tPlan Rv “ERP”+b-c-d-e+f-g-n-p-r

dB x 16.8 14.2 15.2 15.8 16.2

ference Rv “ERP” dB z 16.8 16.8 16.8 16.8 16.8

justment-x

dB 0 2.6 1.6 1.0 0.6


2


utoff

usedrisk inplease

Table 2-15: Adjusted Minimum Signal Strength Parameter

These five adjusted Minimum Signal Strength values would then be used as the Image CLevels to represent the five different data rates.

2.6 Utilizing Link Budget Assumptions in Simulations

As mentioned before, the system design assumptions within the RF link budget are alsoduring the simulation portion of the design process. These values are listed with an asteTable 2-1 and Table 2-2. For more details on how these values are used within the simulator,refer to Chapters 6 and 7.

Reverse Link Parameter Unit Example9.6 kbps

R-FCH LinkBudget

Example19.2 kbps

R-SCH LinkBudget

Example38.4 kbps

R-SCH LinkBudget

Example76.8 kbps

R-SCH LinkBudget

Example153.6 kbps

R-SCH LinkBudget

kTB dBm -113.1 -113.1 -113.1 -113.1 -113.1

Noise Figure dB 6 6 6 6 6

Eb/No dB 5.6 3.5 3.0 2.5 2.1

Processing Gain dB 21.1 18.1 15.1 12.0 9.0

Base Rx Sensitivity dBm -122.6 -121.6 -119.1 -116.6 -114.0

Minimum Signal StrengthParameter

dBm -122.6 -121.6 -119.1 -116.6 -114.0

Adjustment dB 0 2.6 1.6 1.0 0.6

Adjusted Minimum SignalStrength Parameter

dB -122.6 -119.0 -117.5 -115.6 -113.4


Optimizing Clutter Dataand Antenna Patterns

Chapter

3
Table of Contents
3 - 3

- 33 - 33 - 6

- 15 - 16 - 163 - 18

19

3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2 Clutter Code Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2.1 Brief Background on Clutter Codes . . . . . . . . . . . . . . . . . . . . . .3.2.2 Altering Clutter Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 Antenna Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3.1 Antenna Pattern Distortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.3.2 Proposed Methods to Account for Ground Clutter Reflections. . 33.3.3 Issues Regarding the Above Proposed Methods . . . . . . . . . . . . .

3.4 Clutter Environment Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 -


3

Chapter 3: Optimizing Clutter Data and Antenna Patterns

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


3


sociatedbasesa. Land

formser andsite orboth)virtual

aerialregion.p givesused

r type

mostineddatasarilymay

on foraerial

). Thiss more

tPlan

eightsns ofand-(Xlos

3.1 Overview

The accuracy of a system design is dependent on the accuracy of the many databases aswith a planning tool. This chapter discusses how to optimize the accuracy of two of the dataused within the NetPlan design tool. The two databases discussed here are the clutter (a.k.Use/Cover Set) and antenna database.

3.2 Clutter Code Classification

There are various sources of clutter (morphological) data. Clutter refers to obstructions orthat are on top of the terrain (buildings, trees or other vegetation, oceans, bays, etc.). Cluttterrain data are used in conjunction with a propagation model to estimate the coverage for asystem. Once the clutter type is identified for each region, a virtual height or a loss factor (orare associated with each clutter type. The propagation model factors in the loss or associatedheight for each type of clutter in the area.

Clutter for a given region can be determined from such sources as maps or satellite andphotography. These sources are studied to determine the type of clutter that exists in eachIn the cases where maps are used as the only source of clutter data, the coloring of the maan indication of the clutter in a region (e.g. green is often used to indicate foliage, blue is oftento indicate water, etc.). The satellite and aerial photography give a better indication of cluttesince it is a more detailed depiction of what is on the terrain.

The more current the clutter data, the more accurate the propagation predictions will be. Thecommon source of clutter data is from the U.S. Geological Survey (USGS). It is easily obtaand is available digitally. However, there are certain limitations with this data. The USGScategorizes the land by how it is used (commercial, industrial, etc.), which does not necescoincide with categorizing the land by its propagation characteristics. Also, the USGS datanot account for newly developed areas. In order to obtain a more accurate determinaticoverage, it is recommended that enhanced clutter data based on satellite imagery andphotography be used when generating propagation studies (for both 800 MHz and 1.9 GHzdata is more expensive and requires more time to acquire than the USGS data, but providereliable results.

The following sections give more detail on clutter data and how to adjust the data within Neso that more accurate coverage predictions can be generated.

3.2.1 Brief Background on Clutter Codes

Before attempting to describe a procedure for altering clutter data and the associated virtual hin NetPlan, it is necessary first to provide a brief historical perspective. In the earlier versioMotorola propagation tools, all clutter data was created by Motorola's CAD department by hreading maps. The color of a map region determined the classification. Only 7 categoriescodes) existed:


3


ting inwheresignal

S usesUSGS

ominante USGSce, the

o thee same

eights

U - UrbanS - SuburbanF - ForestR - RuralW - WaterQ - Quasi-openO - Open

Virtual heights were assigned to each of these classifications based on extensive drive tesWashington-Baltimore, San Francisco, Houston and Schaumburg. The process was iterativethe heights were adjusted until the predicted signal strength converged to the measuredstrength at a collection of points.

Subsequently, Motorola began using USGS Land-Use/Land Cover data for clutter. The USG39 codes. Since the process of drive testing areas in all 39 categories was not practical, thecodes were mapped into one of the seven Xlos codes based on some knowledge of the predusage of that USGS code. This process was not an exact science. To complicate matters, thclassifies data points in urban areas based more on usage than building type. For instanChicago loop has data points in the following categories:

Commercial and ServicesTrans., Comm., and UtilitiesOther Urban and Built-up LandTransitional Areas

Most of the high-rise areas are classified as “Commercial and Services”.

The virtual heights used in Xlos are an indication of not only the height of the clutter, but alsaverage density. So a sparse forest will provide a different loss value than a dense forest of thtree height.

Table 3-1 lists the different Land Use/Land Cover categories along with the corresponding hused for Xlos. The standard virtual heights used at both 800 MHz and 1.9 GHz are shown.


3


Table 3-1: Standard USGS LU/LC for Xlos

800 MHz 1.9 GHz

USGS Old OV Virtual Hgt Virtual Hgt

USGS LU/LC Code Name Code # Code (ft) (ft)

Central Business Dist. of Large Cities 10 U 45 45

Residential, Suburban Areas 11 S 32 29

Commercial and Services 12 S 32 29

Industrial 13 S 32 29

Trans., Comm., and Utilities 14 Q 9 9

Industrial and Commercial Complexes 15 S 32 29

Mixed Urban and Built-up Land 16 S 32 29

Other Urban and Built-up Land 17 S 32 29

Cropland and Pasture 21 Q 9 9

Orchards, Groves, Vineyards,... 22 R 26 23

Confined Feeding Operations 23 R 26 23

Other Agricultural Land 24 Q 9 9

Herbaceous Rangeland 31 Q 9 9

Shrub and Brush Rangeland 32 O 0 0

Mixed Rangeland 33 Q 9 9

Deciduous Forest Land 41 F 32 32

Evergreen Forest Land 42 F 32 32

Mixed Forest Land 43 F 32 32

Ocean 50 O 0 0

Streams and Canals 51 O 0 0

Lakes 52 O 0 0

Reservoirs 53 O 0 0

Bays and Estuaries 54 O 0 0

Forested Wetland 61 F 32 32

Non-forested Wetland 62 W 19 19

Dry Salt Flats 71 Q 9 9

Beaches 72 Q 9 9

Sandy Areas Other than Beaches 73 Q 9 9

Bare Exposed Rock 74 O 0 0

Strip Mines, Quarries, and Gravel Pits 75 Q 9 9

Transitional Areas 76 Q 9 9

Mixed Barren Land 77 Q 9 9

Shrub and Brush Tundra 81 Q 9 9

Herbaceous Tundra 82 Q 9 9

Bare Ground 83 Q 9 9

Wet Tundra 84 Q 9 9

Mixed Tundra 85 Q 9 9

Perennial Snowfields 91 Q 9 9

Glaciers 92 Q 9 9


3


nd anr fileswere

stingto be

e/Coveralter

SGS,veral

ithind thatancedology.

tellite

ize theccurateveragest datavalues

theanced

is will

please

valuesvirtual

priate

Currently, the clutter or Land Use/Cover Sets have both an associated virtual height aassociated loss value for each clutter classification. The standard Land Use/Land Coveshown above contain only virtual height values and no loss values (loss values of 0 dB). Theyoriginally set up for use with the Xlos propagation model. However, the user can modify exipropagation models or create new propagation models which may require loss valuesassociated with certain clutter classifications. In these cases, the user must create a Land UsSet which assigns the loss values to each clutter classification. Further details on how toclutter data can be found in the next section.

3.2.2 Altering Clutter Data

Due to the limitations of using the standard Land Use/Land Cover data obtained from the Uit is often desirable to modify the existing clutter database. The following sections describe seways in which the clutter database can be modified to improve the design results.

3.2.2.1 Using Enhanced Clutter Data

There are multiple sources of Land Use/Land Cover (LU/LC) data which can be used wNetPlan. For the highest resolution and best determination of coverage, it is recommendeenhanced clutter data from satellite imagery and aerial photography be obtained. This enhclutter data is much more current and therefore, more accurate than other sources of morphPlease contact the GIS group (http://gis.cig.mot.com/) for more information on obtaining sabased land cover.

The enhanced clutter data can be used in conjunction with accurate drive test data to optimNetPlan propagation model. The drive test data needs to be obtained in a very careful and away, making sure that the data contains information that is representative of the system coarea and that it includes each clutter and terrain type that exists in the system. The drive teneeds to be validated before it is used in the process of adjusting the virtual heights or lossassociated with the clutter data to optimize the propagation model.

Once the drive test information is verified as being accurate, it is used in conjunction withenhanced clutter data to adjust the virtual heights or loss values associated with the enhclutter data so that the predicted propagation matches closely with the drive test data. Thimprove the accuracy of the predictions from the NetPlan Xlos propagation model.

For details on optimizing the propagation model using enhanced clutter and drive test data,contact the NetPlan development group.

3.2.2.1.1 Adjusting Virtual Heights or Loss Values Associated With Clutter Classifications

Once the propagation model has been optimized and the required virtual heights and lossassociated with the clutter data have been determined, the user needs to input these newheights and loss values into the NetPlan tool. This is done within NetPlan by editing the approLand Use/Cover Set. For details, please see Figure 3-1: "Edit Land Use/Cover Sets".


3


(this

Figure 3-1: Edit Land Use/Cover Sets

NOTES:

Note: 1. In the NetPlan main window, select the menu list to edit the Land Use/Cover Setis done by selecting Land Use/Cover Set from the Edit pull down window).

2

1

3

5 6 7 48


3


btain

ver Setverwith

electhand

d Use/

pedue is

intoue is

d toutter

Users

od fornce of. OnerrentCover

andardareas.

ng thelter theusefulSGS

Note: 2. Within the Land Use/Cover Set window, choose “Open” under the File menu to oa list of existing Land Use/Cover Sets.

Note: 3. Select the desired Land Use/Cover Set from the list.

Note: 4. Once the desired Land Use/Cover Set has been selected, the Land Use/Cowindow should display the information that is associated with that Land Use/CoSet. This includes the code, virtual height, loss value, and description associatedeach clutter classification. To adjust the values for a certain classification, first sthe appropriate classification so that the description appears in the bottom rightbox.

Note: 5. Once the appropriate clutter classification has been selected, the associated LanCover Set code will appear in this box.

Note: 6. To modify the virtual height for this clutter classification, the new value can be tyinto this box or the “adjust” arrows above the box can be used until the desired valdisplayed.

Note: 7. To modify the loss value for this clutter classification, the new value can be typedthis box or the “adjust” arrows above the box can be used until the desired valdisplayed.

Note: 8. Once the values have been modified, either the “Add” or “Update” button is usesave the changes. The “Update” button is used when modifying an existing clclass and the “Add” button is used when introducing a new clutter classification.

For further details regarding editing Land Use/Cover Sets, please refer to the NetPlanmanuals.

3.2.2.2 Improving the Clutter Database in the Absence of Enhanced Clutter Data

The use of enhanced clutter data along with detailed drive test data is the preferred methmodifying the clutter database to produce the most accurate results. However, in the abseenhanced clutter data, there are still ways to improve upon the accuracy of the given dataoption is to edit the clutter classifications in an existing clutter database to make it more cuand accurate. Another option in the case of systems at 1.9 GHz is to use the Land Use/Landdata obtained from the USGS but to alter the virtual heights for the urban areas since the stvirtual heights do not necessarily represent an accurate model for urban and dense urban

These options are explained in further detail below.

3.2.2.2.1 Editing Clutter Classifications in a Clutter Database

If enhanced clutter and drive test data are not available for the designer to use in adjusticlutter database, another method for improving the accuracy of the clutter database is to aclutter classifications for certain locations to make the database more current. This option isif the existing USGS Land Use/Land Cover data is out of date. For example, if the existing U


3


odified

ailedg the

e the

area.ven tons arewill also

tter

Land Use/Land Cover data does not show a new housing subdivision, the database can be mto include this information.

Modification of the clutter classifications associated with a particular location requires detinformation or familiarity regarding the area that is being designed. For example, before addinpreviously mentioned housing subdivision, the designer needs to know exactly whersubdivision is and roughly how to classify it in terms of clutter classifications.

The clutter editor within NetPlan is used to customize and update the clutter in a geographicWhen editing clutter data, it is highly recommended that a new clutter database name be githe modified data. If the editor is used to edit an existing clutter database and the modificatiosaved under the current clutter database name, then all sites that use that clutter databasebe forced to use the modifications.

The following diagram (Figure 3-2: "Editing Clutter") details the steps required to edit a cludatabase:


3


Figure 3-2: Editing Clutter

Start

Paint

2

13

4

5

6

7


3


se/withand

en the

viewsplayand

lutter

o add

paint”ain

er Setl sites/

.

S canified asor thisowinge.

oriestheistingbe atvirtualrage

NOTES:

Note: 1. Select the Layers button to open the Layers window.

Note: 2. Turn on the Land Use/Cover Set layer which will then display the given Land UCover Set. The ellipsis (...) button should be used to display the colors associatedeach clutter classification. For further detail, please see Figure 3-3: "Displaying LUse/Land Cover".

Note: 3. Once the desired Land Use/Cover Set is displayed, select the Tools button to opTools Palette.

Note: 4. Select the Clutter Editor button on the Tools Palette. However, the windowshould be adjusted before depressing the Clutter Editor button so that the dicontains all areas that will be edited. The clutter editor allows the user to zoom inpan but not to zoom out.

Note: 5. Select the appropriate resolution (such as 100m) and then click OK to open the ceditor.

Note: 6. Within the clutter editor, the user selects the desired clutter type that they wish tby depressing the ellipsis button (...) to open the list of available clutter types.

Note: 7. Select the desired clutter type. Then select the cursor size that will be used to “the clutter display. Use the mouse to modify the existing clutter for certgeographical regions.

NOTE: Once the clutter has been edited, save the modifications under a new Land Use/Covname. If the modifications are saved under an existing Land Use/Cover Set name, then alanalysis that use that Land Use/Cover Set will be affected by the modifications.

For further details regarding editing clutter data, please refer to the NetPlan Users Manuals

3.2.2.2.2 Alterations for Urban Clutter in a 1.9 GHz System

In the absence of enhanced clutter data, Land Use/Land Cover data obtained from the USGbe used. However, this data does not truly represent areas within the design that are classdense urban (such as downtown Chicago or Manhattan) or those classified as urban. Freason, if detailed drive test data and enhanced clutter data are unavailable, the follalterations to the virtual heights are recommended to improve determination of cell coverag

1 To help in analysis of coverage, color each of the Land Use/Land Cover categwithin NetPlan by the virtual height used within the tool (i.e. all categories that usesame virtual height should be colored the same). (See Table 3-1.) Since the 39 exLand Use/Land Cover categories map into 7 different virtual heights, there shouldmost 7 colors representing the clutter data. Since propagation is dependent uponheight, the resultant color map will help illustrate why certain areas within the cove


3


" for

urbansedctors.e/Land

arend

e at ail thed.

have varying signal strength. See Figure 3-3: "Displaying Land Use/Land Coverfurther details.

Figure 3-3: Displaying Land Use/Land Cover

Note: The method to more closely represent coverage of sites in urban and/or denseenvironments is to first create two new Land Use/Land Cover files. One file to be ufor all dense urban cells and sectors, and the second file for all urban cells and se(See Tables 3-2 and 3-3.) The remaining areas should use the standard Land UsCover files as detailed in Table 3-1. (The NetPlan files corresponding to Table 3-1defined within the tool as “Standard [below 1.8 GHz]” and “Standard HF [1.8 GHz aabove]”.)

The following two tables (Tables 3-2 and 3-3) were generated by propagating a sit30 meter antenna height and altering the virtual height of the clutter categories untexpected COST 231 Hata radius for urban and dense urban environments resulte

NOTE: One should verify these virtual heights if a different antenna height ischosen.


3


Withn.

areasheseusing

ysisomee for

Table 3-2: Urban Corrections

Table 3-3: Dense Urban Corrections

Please see Section 3.2.2.1.1 Adjusting Virtual Heights or Loss Values AssociatedClutter Classifications for details regarding modifying Land Use/Cover Set informatio

2 In order to apply the appropriate virtual heights to the Land Use/Land Cover data,of dense urban, urban, suburban, and rural must be identified. Identification of tareas should be done by either viewing aerial photographs, satellite images, or bya combination of maps and visits to the specific area under consideration.

NOTE: It is very difficult to determine areas of urban versus suburban from analof maps alone. Determination of these areas can be fairly subjective but sconsistency can be achieved by using the descriptions in Section 3.4 as a guiddetermining each environmental area.

LU/LCCode

Virtual Hgt (m)1.9 GHz

Residential, Suburban Areas 11 17.07

Commercial and Services 12 17.07

Industrial 13 17.07

Industrial and Commercial Complexes 15 17.07

Mixed Urban and Built-up Land 16 17.07

Other Urban and Built-up Land 17 2.7

LU/LCCode

Virtual Hgt (m)1.9 GHz

Residential, Suburban Areas 11 19.5

Commercial and Services 12 19.5

Industrial 13 19.5

Industrial and Commercial Complexes 15 19.5

Mixed Urban and Built-up Land 16 19.5

Other Urban and Built-up Land 17 2.7


3


amedand

Openiatedther

First, the newly created Land Use/Land Cover sets must be assigned to a newly nGeo Set. This is done in NetPlan through the pull down menu Edit>Geo Setsselecting a Geo Set (either an existing one that can be modified by using the File>pull down menu or a new one by using the File>New pull down menu) and assocLand Use/Land Cover definition. See Figure 3-4: "Selecting Geo Sets" for furdetails.

Figure 3-4: Selecting Geo Sets


3


This issiteg Geo

gain,it is.

Second, the newly named Geo Set should be assigned to the appropriate sectors.done in NetPlan through the pull down menu Edit>Site. From within the editwindow, the user then selects a Geo Set for each sector. See Figure 3-5: "AssigninSets to Antennas" for further details.

Figure 3-5: Assigning Geo Sets to Antennas

3.3 Antenna Patterns

There are various characteristics of antennas that will impact the coverage for a cell:horizontal and vertical beamwidth, and the front-to-back (F/B) ratio. As with the clutter data,important to use the most accurate antenna data that is available when designing a system


3


rer’snts in anin theantennact tow the

fectttern.te, the

tor innna’sect is

these

n thethis infront-. A

ite by

he risklimitithinular

ments.backcan beed toreas tourbanas where

-back

3.3.1 Antenna Pattern Distortion

The real world performance of an antenna is different from that listed in the manufactuantenna pattern specifications. The manufacturer’s specifications are based on measuremeideal environment of an antenna range. However, the actual implementation of the antennasystem is not the same as on the antenna range. In the real system, factors such as how theis mounted (such as on the side of a building or tower), or its relative location with respesurrounding clutter have an effect on the antenna pattern. If the antenna is mounted belomajority of the surrounding clutter, the signal will be reflected due to this clutter, which in efdistorts the antenna pattern, reducing the effective protection from the directivity of the paSince the mounting of the antennas and the surrounding ground clutter vary from site to siantenna pattern distortion will also vary from site to site, as well as from sector to sector.

The ground clutter type and location, with respect to the antenna, is the important facdetermining ground clutter reflections. The amount and placement of tall buildings in the antemain lobe will affect the amount of reflections which propagate behind the antenna. This effseen most often in dense urban and urban areas since there are more tall buildings inenvironments.

The antenna pattern distortion can affect the capacity of a site. If significant clutter exists iarea of an antenna’s main lobe causing reflections which propagate behind the antenna,effect reduces the front-to-back ratio of the antenna. Studies have shown that by changing theto-back ratio from 25 dB to 20 dB, the capacity of the site is reduced approximately 3 -13%change in the antenna front-to-back ratio from 25 dB to 15 dB reduces the capacity of the sapproximately 10 - 40%.

3.3.2 Proposed Methods to Account for Ground Clutter Reflections

One method that has been proposed to account for ground clutter reflections (and reduce tof over estimating the capacity) is to modify the horizontal antenna pattern within NetPlan tothe front-to-back ratio. This is done by creating a new horizontal antenna file that is used wNetPlan. If the actual real world performance for this antenna is known for a particenvironment or site, the antenna file should be modified to reflect these actual field measureIf real world performance data is not available, and it is believed that the real world front-to-ratio will not be as good as the manufacturer’s ratings, then the horizontal antenna patternmodified to reduce the front-to-back ratio. For instance, the front-to-back ratio could be reduc10-15 dB for antennas used in the dense urban areas or reduced to 15-20 dB for urban acompensate for the fact that the signal will be scattered by ground clutter. Only the denseand urban areas are chosen because the antenna pattern distortion occurs more often in arethe antenna center line heights are at or below the surrounding ground clutter heights.

The following example illustrates an antenna that has been modified for a maximum front-toratio of 15 dB.


3


Figure 3-6: Example Manufacturer’s Antenna Pattern

Figure 3-7: Example Pattern with Front-to-Back Ratio Modified

270

000

030

060

090120

150

180

210

240 300

330

5 dB per ring

270

000

030

060

090120

150

180

210

240 300

330

5 dB per ring


3


fy the

ing

aps.

as, itt in a

lobe,ate

be ae, thesite iss apartdoffo-back

3.3.3 Issues Regarding the Above Proposed Methods

There are several issues that should be kept in mind while trying to decide whether to modiantenna patterns to account for clutter reflections.

• Since the amount of directivity or front-to-back ratio reduction is not known, modifyan antenna pattern by a certain value may over or under estimate the effects.

• One cannot tell which sites or sectors will be effected by just looking at the clutter m

• Although ground clutter reflections occur most often in dense urban and urban areis possible for a few tall buildings surrounding the antenna to also cause this effecsuburban area.

• Since the amount and placement of buildings is not uniform in the antenna’s mainmodifying the antenna’s front-to-back ratio in a uniform way will over or under estimthe effects in certain areas behind the antenna.

• The results from using the antenna patterns with modified front-to-back ratios maybit different from the results using the manufacturer’s antenna patterns. For examplsoft handoff results might not be what is expected. To illustrate this, assume that aconfigured as a three sector site (oriented so that the main beams are 120 degreefrom each other). A plot of the soft handoff regions may show that 3-way soft hanregions exist between the sectors since all three sectors may have the same front-tratio in these areas.


3


s).the

s ofo cell

entialbesize

as of

ks.gs.antties

ajoreas.e to

3.4 Clutter Environment Descriptions

Dense Urban: Consists of densely built areas with mainly high buildings (over 20 storieTypically there are few or no trees and vegetation within this area due todensity of buildings. Central parts of Chicago and New York are exampledense urban areas. In these environments, even 100 foot cells have micrpropagation which is dominated by building location.

Urban: Consists of metropolitan regions, industrial areas and closely spaced residhomes and multi storied apartments. Building density is high but mayinterspersed with trees and other vegetation. Business centers of mediumcities such as Tulsa and Indianapolis as well as portions of the outer areNew York and Chicago are examples of this environment.

Suburban: Consists mainly of single family homes, shopping malls and office parSignificant vegetation, trees and parking lots are intermixed with buildinMost buildings are 1 to 3 stories but significant exceptions do occur. Significareas within small and medium cities along with suburban communisurrounding major cities are examples of this environment.

Rural: Consists generally of open space with few buildings or residences. Minterconnecting highways, farms, and barren land are found within rural arThe largest variations in cell coverage area are found in rural areas dudifferences in vegetation and terrain.


3


_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


Verify Coverage andIdentify Problem Areas

Chapter

4
Table of Contents
4 - 3

4 - 3

4 - 64 - 6

4 - 6

4 - 74 - 8

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 NetPlan Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3 Existing System Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.1 Generating Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.3.2 Verifying Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 New System Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.4.1 Placing Cells and Generating Coverage . . . . . . . . . . . . . . . . . . .


4

Chapter 4: Verify Coverage and Identify Problem Areas

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


4


ate thefrom adressximumas cellnd sitesater).ningimum

for thedictedfyingng andsomethat the

budgetothertypes,

gation

h theclude

tudied.o enter2.5.2,

low

4.1 Overview

Once the inputs to NetPlan have been determined, the next step is to use NetPlan to estimcoverage of the system and then verify that the coverage matches the requirementsmaximum allowable path loss perspective only. (Later the simulator will be used to adcoverage studies beyond a path loss only perspective.) Analyzing the coverage based on maallowable path loss only is an important step since it can help determine major issues suchsite placement problems (sites spaced too close or too far apart), terrain obstruction issues, awhich may present interference problems (sites on mountain tops or near large bodies of wBy addressing these problems at this point, it will avoid having to address them after runsimulation studies since most of the problems exhibited by the coverage plot based on maxallowable path loss only would still exist after simulations.

This chapter discusses using the data from the previous chapters to generate the coveragesystem based on maximum allowable path loss calculations only, and then review the preoutputs. This process will be broken into two different categories: 1) generating and vericoverage studies for an existing system or verifying another engineers design, or 2) generativerifying coverage for a new system. These two approaches are similar, but each haveseparate issues that need to be addressed. For either process, the first step is to make sureappropriate files and values are set up for NetPlan.

4.2 NetPlan Inputs

Generating propagation requires that the input values have been determined from the linkcalculations, and the clutter data and propagation model have been optimized. Also, allrequired parameters must be set within the NetPlan tool such as site coordinates, antennaantenna height, antenna orientation, site “ERP” values, propagation cutoff levels and propaboundaries.

It is important to keep in mind when setting the propagation boundaries (the extent to whicpropagation will be run) that the boundaries need to be large enough so that a system will inenough propagation so that the impact of interference to and from distant sites can be sThese boundaries can be set on a per-site basis or globally applied to the entire system. Tthe boundaries, the user accesses the “Edit Site” window as described in Chapter 2 Section“Entering NetPlan Values”. A blow up of the boundary entry area of the window is shown bein Figure 4-1: "Propagation Boundaries and Parameter Set".


4


y. Thisxagon.

Figure 4-1: Propagation Boundaries and Parameter Set

It is recommended that a site be propagated a distance of at least three hexagon rings awaequates to roughly 7 times the distance between the center of the cell and the face of the heSee Figure 4-2: "Hexagon Cell Radius and Distance".


4


site isrefore,

ld alsois to

t there. Theill be

ing the100 mree, theation

ic for 1

Figure 4-2: Hexagon Cell Radius and Distance

In some cases, propagating a site out to three rings may not be far enough. For example, if aon a hill top or near a large body of water, the site may propagate beyond this distance. Thethe propagation boundaries must be evaluated on a site by site basis.

Not only should one be concerned with how far each individual site propagates, but one shoube aware of the boundaries of the system. An efficient method to exclude outlying areascustomize the Combined Image Boundary to the size of the system. This will guarantee thawill be no propagation outside of the Combined Image Boundary and thus no traffic eitherCombined Image Boundary then becomes the area over which simulation images wgenerated. Exclusion masks can then be used later to fine tune the simulation boundary.

As mentioned in Chapter 2, other parameters that need to be set within NetPlan include settminimum signal strength to an appropriate level and the resolution for the generated data tofor every 1 degree (360 radials). To ensure that the spacing between radials is at most 1 degparameter is set within NetPlan in the Edit Site Data section (see Figure 4-1: "PropagBoundaries and Parameter Set") by choosing the proper “parameter set” (one that is specifdegree radials).

d

r b

a

a

d = 7 * rb


4


stemsstemantennais dataiewing

t data tool.

losses

utoffbeen

erated.ots can

reviewERP”ld be

4.3 Existing System Coverage

An existing system is a system that already has the cell sites installed. It can also apply to sythat are being designed by another party and Motorola is performing a verification of the sydesign. In either case, the locations of the cell sites, the line losses and any other losses, thetypes, and the antenna heights are known for each cell site. It is only a matter of entering thinto NetPlan to produce coverage plots based on maximum allowable path loss, and then revthese plots.

4.3.1 Generating Coverage

Generating the coverage for a system is basically accomplished by gathering the pertinenfrom the existing system and using this data to determine the proper inputs for the NetPlan

The pertinent data required is:

• Latitude and Longitude of each cell site

• Antenna models for each sector

• Antenna heights (above ground level) for each sector

• Antenna orientation (relative to North) for each sector

• Antenna downtilt

• Line losses and other losses and/or gains for each sector (summation of thebetween the top of the base station rack to the input of the antenna)

• In-building or vehicle losses to assume

• Shadow Fade Margin allowance

• Source of other parties morphology data (clutter)

Once this information is obtained, a link budget can be utilized to determine the “ERP” and clevels to be entered into NetPlan (The area reliability and Shadow Fade Margin should havechosen in Chapter 2). Each site’s data is entered into NetPlan, then coverage plots are genThe typical plots to produce are signal strength and best server. (Also, second best server plbe generated to assist in studying the overlap between cells.)

4.3.2 Verifying Coverage

Once the data is entered into NetPlan and the various propagation plots have been created, aof the design can take place. (Refer to Chapter 2 for a discussion on setting the proper “values and cutoff levels when viewing and analyzing coverage.) The following checks shoumade in verifying the coverage:


4


into

unt ofauses), a

thes anheightin),b in

agationneeds

in the

eview. Anyve thee to beilable.ng an

es fora new

ecified.to thisarea. Itnters,Also,st be

• Ensure that all of the data obtained for the system has been correctly enteredNetPlan.

• Analyze the best server plot to ensure that each cell/sector has a sufficient amocoverage from the site. If the best server plot shows very little coverage, possible cinclude: an error in the antenna height (too low), an error in the “ERP” (too lowmisplacement of the site (in a deep valley), a problem with the clutter data, orneighbor site’s coverage is dominating this site. If the best server plot showexcessive amount of coverage, possible causes include: an error in the antenna(too high), an error in the “ERP” (too high), a misplacement of the site (on a mountaa problem with the clutter data, or the neighbor site is not doing an adequate jocovering an area. These various areas should be checked to ensure that the proplooks proper. If not, the necessary corrections need to be made and the predictionto be run again.

• Analyze the signal strength plot to ensure that there are no unexpected holesdesired coverage area.

4.3.2.1 Design Review

Once the plots have been produced, verified, and justified, it is now time to conduct a design rto discuss the system coverage from a “maximum allowable path loss only” perspectiveconcerns can be discussed at this time, such as suggestions of possible ways to improcoverage or discussions of areas that are not that important to cover. If any suggestions arpresented for improving the coverage, “what if” scenarios should be prepared and avaVarious options that can be explored are: adding a new site(s), removing a site(s), moviexisting site(s), changing the orientation of an antenna(s), and altering the downtilt.

4.4 New System Coverage

A new system has no existing sites, therefore the RF Engineer has numerous alternativstarting the design. However, there are a few items required prior to beginning the design ofsystem.

The desired coverage area (the geographic locations where service is desired) should be spThis may consist of a core area to be covered in addition to covering the highways leading incore area. In future years, additional sites may be required to increase the size of the coreis also important to know where the hot spots will be. For instance, airports, convention cehotels, various roads, various intersections, the company’s president’s home, etc.information used in the link budget, such as building loss, vehicle loss, fade margin, etc. muprovided.


4


oselyn be

may beisitionearch.. Afteretter

otheresign

veragefor the

. Thebesites

cessiveerviceethods.

withs untilspider

illed

s owndgetnce on

andr. Thisvirtualwereoosinge fairlyor on

code is

In producing a new system design, it is quite possible that the RF Engineer will be working clwith a Site Acquisition person. The site acquisition person will locate possible sites that caused in the design and will also be able to feed back the possible heights of antennas thatallowed in given areas. However, this is somewhat a paradox since prior to the site acquperson being able to locate a site, they first need to know the areas in which to perform their sSo, the first step for the RF Engineer is to generate a coverage plot with realistic assumptionstime, as the site acquisition team’s work progresses, the site information will become bdefined. This information is then incorporated into the design, which may require certainmodifications to be made to other sites. Modifications are continually made to a system duntil all of the data is known and fixed.

4.4.1 Placing Cells and Generating Coverage

Since there are no established sites in a new system design, a starting point is required. Cocould be generated one cell at a time, or at the other extreme, coverage could be generatedentire system by first laying out a grid of sites that is anticipated to cover the entire areaproblem with one cell at a time is that it will require a lot of time if there is a large area tocovered. The problem with laying out the entire system at once is that it is possible that theare either too close together (resulting in too much overlap between sites and therefore an exnumber of sites) or the sites are too far apart (resulting in coverage holes within the desired sarea and therefore not enough sites). The recommended approach is between these two m

The recommended approach for cell placement in determining coverage is to beginpropagation for a few sites at a time and then continue to add sites around this core of sitethe desired geographic area has been covered. It could be envisioned somewhat like aspinning its web. The spider will start at the center and work its way out until the web has fthe area desired by the spider.

The following steps can be used to aid in developing the new system design.

4.4.1.1 Run example Sites

The first step is to determine a typical coverage area for an individual site. Each site has itunique characteristics. All cell site parameters must be properly entered including link buparameters described in Section 4.3.1 and in Chapter 2. One such factor that has an influethe coverage of the site is the clutter in which the site is located.

A useful step in estimating typical site coverage is to first display the clutter within NetPlancolor code it so that all clutter categories that use the same virtual height are the same colois useful since the coverage is impacted by the virtual height and not the code itself. For eachheight grouping that exists, run several test sites using the ERP and cutoff levels thatdetermined for that particular area type (dense urban, urban, suburban, rural, etc.). When chsample site locations, terrain should be taken into consideration so that the sites chosen arrepresentative of the overall area for that clutter type (e.g. avoid placing sites in deep valleysmountain peaks). Also, the sample locations should be placed in areas where one clutterdominant.


4


e werethese

mineone of

ncessites

ing in

in thehould

n thells in aced

vious

theerver

erage).whenlocatedxagon

4.4.1.2 Determine Hexagon Radii

For each clutter code that exists, determine the best fit hexagon radius. For example, if ther5 sample sites run in the “quasi-open” clutter type, determine the hexagon size that best fits5 sites. If the sites have widely varying hexagon radii, look at the underlying terrain to deterif the sites picked were perhaps not representative of the majority of the area (i.e. perhapsthe test sites was located in a valley or on the top of a mountain).

Note: If site radii vary widely in size because the majority of the area has significant variain terrain, the use of hexagons to quickly place sites may be invalid. In this casemay need to be added one by one.

At the end of this step, there should be a different hexagon size for each virtual height groupeach of the area types.

4.4.1.3 Set up Hexagon Grid for a Few Cells

Using the hexagon size determined in the previous step, place a grid for several (5-10) sitesdensest area of the system (within the same clutter category, if possible). Only a few cells sbe placed at one time to minimize the possibility of excessive overlap between sites.

4.4.1.4 Place Cells in the Hexagons

Place cells within these hexagons. During this step, it is useful if the terrain is displayed oscreen so that the user can place the cells more wisely (for example, avoid placing the cedeep valley). This will help minimize the optimization required later. The cells should be plaas close to the center of the hexagon as possible (within 25% of the cell radius).

4.4.1.5 Run Propagation for the System

Run Receive Voice Best Signal Strength and Best Server plots for the cells placed in the prestep.

Note: To assist in determining the amount of overlap between cells when analyzingcoverage in the next step, it may be useful to also run the Receive Voice 2nd Best Splot.

4.4.1.6 Analyze Coverage

Display the coverage and determine areas that need optimizing (areas of inadequate cov(Refer to Chapter 2 for a discussion on setting the proper “ERP” values and cutoff levelsviewing and analyzing coverage.) If there is inadequate coverage, the sites may need to becloser together. If there is too much overlap, the sites could be further spaced apart. The heradius can be changed accordingly and the last three steps repeated.


4


s) and

and/esort..

ut as. Ifld be

ay betion.

red.besthas

l isithlso,, the

illed

e intwo

minatece thenalver, itblemsto berun.

typekingr no

ver,ages.y toeredstem

Note: Optimizing coverage is necessary for both inadequate coverage (significant holeexcessive coverage (overlap).

4.4.1.7 Optimize Coverage

When optimizing coverage, the system engineer’s goal is to first modify the site configurationor location. The addition of new sites to fill in coverage holes should only be done as a last rThe following lists some of the techniques available to the designer for optimizing coverage

• Determine if significant coverage holes exist in-between many cells or througholarge portion of the system, or if poor coverage exists only between a few cellcoverage holes exist between many cells, the grid size used to place cells shoure-evaluated and new site locations chosen.

• If coverage holes exist between just a few cells, then the overall grid size chosen msufficient. The coverage can be optimized by modifying site location and configura

- View terrain and clutter profiles between cell centers and the area not coveDetermine the most viable cell to provide coverage to the uncovered area. Thecell may be the one with the least amount of terrain obstructions or the cell whichthe lowest clutter losses.

- For the cell which is most likely to fill in the coverage hole, determine if the celoptimally placed within a search radius (25% of the hex center for example) wrespect to clutter and terrain (i.e. make sure the cell is not in a deep valley). Adetermine if enough overlap exists in the area away from the coverage hole. If socell location may be moved toward the hole such that the coverage hole is fwithout creating a hole in the other direction.

- If changing the site location cannot fill the coverage hole, determine if a changantenna height can fill in the hole. Increases in antenna height generally haveeffects on coverage and path loss: one is that antenna height increases may elior reduce terrain obstructions, and two is that antenna height increases can reduslope and intercept of your path loss model which will result in higher sigstrengths. (This is dependent upon the type of propagation model used.) Howeshould be noted that excessive increases in antenna height may create produring the site acquisition process. Also, the transmission line loss may needmodified if the antenna height changes require a change in the length of cable

- Another technique available is changing antenna type and/or downtilt. Antennachanges may affect the link budget and should be carefully analyzed before maany final changes. Systems in relatively flat areas should be designed with little odowntilt so that coverage is maximized (i.e. number of cells minimized). Howein rugged terrain, the tilt of the antenna can provide significant coverage advantHill top or hill side sites are a good example where down tilting is necessarprovide coverage along highways. However, hill top sites should also be considfrom an interference stand point such that it does not dominate your overall sy


4


itesite

dingis not

m sowhen

without

ge istails.

quire

interference.

-When optimizing coverage, don’t be afraid to make modifications to sconfigurations for several sites within an area. Minor modifications to severallocations may be necessary to fill in just one coverage hole.

- If all else fails, add sites to fill coverage holes. However, adjustments to surrounsites (such as locations) is most likely necessary to ensure excessive overlapcreated by site additions.

4.4.1.8 Rerun sites

Rerun the few sites and repeat the previous two steps until coverage is adequate.

4.4.1.9 Expand System a Few Sites at a Time

Add a few cells at a time (perhaps in a ring around the initial cells, for example) and run thethat the system can be optimized as it is designed. The hexagon size will need to be modifiedchanging between virtual height groupings.

4.4.1.10 Analyze Coverage as Sites are Added

As cells are added, display the coverage to see if the new sites provide adequate coveragegiving too much cell overlap.

4.4.1.11 Complete Initial System Design

Repeat the above two steps until adequate system coverage is provided.

4.4.1.12 Design Review

As in the case of a CDMA design for an existing system, once the initial system coveracomplete and verified for accuracy, it should be reviewed. See Section 4.3.2.1 for more de

4.4.1.13 Final Design for System Deployment or Design for Coverage Warranty

More detailed designs to be used for warranty of coverage or for system deployment will refurther analysis using the NetPlan CDMA Simulator.


4


_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


Traffic (Distribution) andSpeed Maps

Chapter

5
Table of Contents
5 - 3

5 - 6 - 7 - 9

- 11 15 16 - 194- 26- 29- 38 38- 39 - 40 - 4246 48

- 4950 - 52- 58 - 59- 60

5 - 61

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.2 Traffic Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5.2.1 Creating the Carrier Independent Traffic (Distribution) Map . . . 5

5.2.1.1 Using Polygons With Traffic Data . . . . . . . . . . . . . . . . . . . . . . 55.2.1.2 Using Existing System Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55.2.1.3 New CDMA System With Projected Traffic . . . . . . . . . . . . . . . . . 5 -5.2.1.4 CDMA System with Commercial Traffic . . . . . . . . . . . . . . . . . . . 5 -5.2.1.5 Importing Traffic Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55.2.1.6 Application of Exclusion Mask for Traffic Distribution . . . . . . . 5 - 25.2.1.7 Weighting Traffic By Roads and Clutter Types . . . . . . . . . . . . . . . 5 5.2.1.8 Viewing Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.2.2 Determining Multiple Carrier Requirements. . . . . . . . . . . . . . . . 5 5.2.2.1 Multi-Carrier RF Design Methodology . . . . . . . . . . . . . . . . . . . . . 5 -5.2.2.2 Determining the Number of Additional Carriers . . . . . . . . . . . . . . 5 5.2.2.3 Selecting Sites to Receive the Additional Carrier . . . . . . . . . . . . . 55.2.2.4 Inter-Carrier Hard Handoff Management . . . . . . . . . . . . . . . . . . . 55.2.2.5 Choosing MAHHO or DAHHO for Transition Zone Sites . . . . . . 5 -

5.2.3 Multiple Carrier - Traffic Carrier Map Set . . . . . . . . . . . . . . . . . 5 -5.2.3.1 Multi-Carrier Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2.3.2 TCMS Traffic Distribution Algorithm . . . . . . . . . . . . . . . . . . . . . . 5 - 5.2.3.3 Creating the Traffic Carrier Map Set . . . . . . . . . . . . . . . . . . . . . . . 55.2.3.4 Displaying and Validating the TCMS . . . . . . . . . . . . . . . . . . . . . . 5 5.2.3.5 Using the TCMS in Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55.2.3.6 Modifying the TCMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.3 Speed Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


5

Chapter 5: Traffic (Distribution) and Speed Maps

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


5


fficppedandrately

apat a

(Then theraffic,

arkserway

s orhet aafficrmally

userted

, theours

5.1 Overview

A traffic map, as used in CDMA simulations, defines the geographical distribution of the trafor the CDMA system. The traffic map determines the probability that a subscriber will be droin a given location during the simulation. A traffic map is a required input for the simulatorneeds to mirror real-world traffic density distribution as closely as possible. The more accuthe traffic map portrays the distribution of the traffic, the better the results of the simulation.

The Traffic (Distribution) Map should model the real-world traffic distribution density. This mdoes not tell the simulator how much traffic is in the system, but rather the probability thsubscriber will be placed in a bin within the simulation space during a simulation drop.number of Erlangs entered in the CDMA Parameters window specifies how much traffic is isystem. See Section 6.2.2.4.2.) By defining the probability ratios for each map location, the T(Distribution) Map effectively defines thedistributionof the traffic in a given system. For instancein a given city, there is a higher probability that traffic is distributed along roadways, in office pand in residential areas, as compared to the lower probability that traffic is located on a wator in farmland.

Using a uniform traffic distribution, as opposed to weighting the traffic by clutter type, roadpolygons, will not show a true indication of CDMA performance. It is highly unlikely that ttraffic, in reality, would be uniformly distributed throughout the system. It is more likely thahigher percentage of the traffic would be found on the roads, for example. Also, if a uniform trdistribution is assumed, then subscribers may be placed in areas where traffic is not noexpected, such as on mountain tops or on water.

Generally, the level of accuracy for a Traffic Map improves in the following order:

• Uniform Traffic Distribution - least accurate

• Polygons with traffic based on Census or other data sources - may not reflectprofile. For example, Census data will show the majority of the population locawithin the suburban or urban areas, and little population in city centers. In realitycity center may carry a heavy traffic load during business hours and even after h(nightclubs, special events, etc.).

• Traffic based upon underlying wireless system usage - most accurate


5


These oftainsibutionsed

edffic totheis not

ce this

ner may

s (seepeed

/Noen thepectedto be

ichfor eachnd inndardscriber

in thects ofnce topacts:

ance

ation

tion of

level

The NetPlan Traffic Engineering Tool is used to produce the Traffic (Distribution) Map.distribution of the traffic is a function of a city’s population density and road usage. Becauthis, the Traffic (Distribution) Map can be created from data that locates population or conroad usage (Census data, Zip Code data, etc.). One good source of subscriber distrinformation is the traffic statistics available from the existing cellular system for the propoCDMA market. Using the Traffic Engineering Tool within NetPlan will allow the expectcoverage footprint of these existing cell sites to be used along with the associated carried tradefine the Traffic (Distribution) Map. Note that NetPlan coverage will need to be run for all ofexisting sites associated with the traffic data (using actual ERPs, locations, heights, etc.). Itimportant that these cell sites be the same as the sites used in the CDMA system sininformation is just being used to define the traffic density.

There are cases where traffic data is not easily accessible. In these cases, the system designeed to re-visit the Traffic Map and improve it as higher quality data is collected.

Several methods are available within NetPlan to assign speed values to subscriberSection 6.2.2.4.1). A Speed Map is preferred to all other methods. Using a uniform sdistribution may potentially result in the selection of overly optimistic (or pessimistic) Ebvalues, and therefore is not recommended. It is expected that a correlation exists betwelocation of a subscriber and its inherent speed. Subscribers located on highways would be exto be moving at highway speeds, while subscribers located in buildings would be expectedmoving slowly, if at all. The NetPlan CDMA Simulator is able to employ a “Speed Map” whgeographically defines the speed assigned to a subscriber based on the speed map valuelocation. The actual value assigned to an individual subscriber can vary from the value foueach Speed Map location in a normally distributed fashion based on the setting of the stadeviation percentage. The Speed Map standard deviation value is set when defining subclasses (see Section 6.2.2.4.1).

The accurate distribution of traffic and the accurate assignment of subscriber speeds withsimulator are imperative to achieving accurate results. The accuracy of these two aspedefining subscriber behavior and the accuracy of the predicted path loss are of equal importathe overall simulation accuracy. The subscriber behavior defined by these two attributes im

• System capacity - achieved during the simulation based on the minimum performcriterion

• Power amplifier sizing - determined by whether a sector’s amplifier reached saturduring a simulation run

• Coverage - impacted by the noise (interference) generated by the amount and locathe traffic load

• Cell site equipage - traffic channel elements required to sustain the expected traffic


5


tioned of

ons.ns onre that

o or morepeed

peeds thathightter isssignedho areation

f dataofferdata

ata, in-wo orysical

lation. Forscriberssettingit.

zero

raffic

NetPlan provides the ability to define a unique Traffic (Distribution) Map and Speed DistribuMap for each subscriber class in a simulation. This facilitates tailoring the position and speeach subscriber class to more accurately model the subscriber behavior in a real system.

Individual Traffic (Distribution) Maps are recommended for different subscriber classificatiThis approach ensures that in-vehicle subscribers will only be placed in desired locatiostreets, highways and parking areas. A corresponding Speed Map would be used to ensuthese subscribers are assigned speeds that best reflect the speeds found in these areas. Twclassifications of subscribers who are in automobiles could use the same Traffic/SDistribution Maps if their physical location and speeds are the same.

Pedestrian subscribers or in-building subscribers should have their own unique Traffic/SMaps. In-building subscribers would only be placed on areas that are comprised of buildingmatch their particular profile. For example, a subscriber class that is defined to include adegree of building penetration loss would only be placed on areas where dense urban clupresent. A corresponding Speed Map would be used to ensure that these subscribers are aspeeds that best reflect pedestrian movement. Two or more classifications of subscribers wpedestrians or in-building users could use the same Traffic/Speed Maps if their physical locand speeds are the same.

Data subscribers should also have their own unique Traffic/Speed Maps. The location osubscribers may be differentiated from voice subscribers. The operator may choose todifferent grades of data service in different geographic locations. Within each category ofsubscriber, there may exist many mobility sub categories (such as mobile data, pedestrian dbuilding data, etc.). The Traffic/Speed Maps should reflect these patterns and objectives. Tmore classifications of data subscribers could use the same Traffic/Speed Maps if their phlocation and speeds are the same.

The use of an exclusion mask during the generation of a traffic map may impact the simuresults. Use of an exclusion mask is often linked to the system’s geographical locationinstance, if the system has many mountains, an exclusion mask can be used to keep the subfrom being dropped on the mountain tops, where coverage is not desired. In other systems,the clutter type to zero will suffice. (For example, consider a city with a river flowing throughIt would be difficult to paint an exclusion mask on the river. Setting the water clutter types toweight would ensure a properly prepared traffic map.)

This chapter is laid out in two major sections. The first, (Section 5.2), handles the creation of tmaps. The second, (Section 5.3), handles the creation of speed maps.


5


ltipleken

thatorateow tool ofp to

ystemarriersr-carrier

t thehm.lidatessary,

5.2 Traffic Maps

This section of the chapter explains how to create traffic maps for both single carrier and mucarrier CDMA systems. The treatment of creating traffic maps for CDMA Simulations is brointo three primary steps. These steps are:

• Creating the Carrier Independent Traffic Map

• Determining Multiple Carrier Requirements

• Creating Multiple Carrier - Traffic Carrier Map Sets

The first step (Section 5.2.1: Creating the Carrier Independent Traffic Map) is laid out suchthe system designer will first learn the various sources of traffic input data and how to incorpthem when generating a Traffic Map (for a single carrier system). This step then explains happly exclusion masks and how to weight traffic by roads and clutter type for better contrsubscriber placement. Lastly, this step explains how to view the Traffic (Distribution) Maverify that it meets the designer’s needs.

The second step (Section 5.2.2: Determining Multiple Carrier Requirements) aids the sdesigner in determining when additional carriers are required in a system and how many cshould be implemented in each site/sector. The step then addresses the management of intehandoffs and the design of handoff transition zones.

The third step (Section 5.2.3: Multiple Carrier - Traffic Carrier Map Sets) is laid out such thasystem designer will first learn multi-carrier definitions and the traffic carrier map set algoritThis step then describes the how to create a Traffic Carrier Map Set (TCMS), display and vathe TCMS results. Finally, this step explains how to use the TCMS in an analysis and, if necehow to modify it.


5


ons.affic

5.2.1 Creating the Carrier Independent Traffic (Distribution) Map

The Traffic Engineering Tool is a utility embedded within NetPlan which serves many functiThe only three functions used in a CDMA design are the Traffic Map, Speed Map and TrCarrier Map Set functions. This section deals with the Traffic Map generation function.

To access the tool, the user clicks on the Traffic Engineering icon (shown to the right)which opens the Traffic Engineering dialog box. Inside the Traffic Engineering dialogbox, pull down the “Edit” menu to “Traffic Map” which will open the Traffic Mapwindow. See Figure 5-1: "Traffic Map" below:

Figure 5-1: Traffic Map


5


Ifted” canap

10 andcriberght ofhich is

e thetems.for an

raffic

hey use

Four choices are given in the Traffic Map window:

• Grow Current Traffic Map

• Redistribute Current Traffic Map

• Create Map from Parameter Set

• Create Map from Polygons

The first option, “Grow Current Traffic Map” is not normally used for CDMA simulations.growth is required, more traffic (Erlangs) will be placed in the simulation. If growth is predicin an isolated area (i.e. city center) then the second option, “Redistribute Current Traffic Mapbe used to alter the weight per sector. For CDMA simulations, “growing” the entire Traffic Mby a given percentage will not change the results. For instance, if the roads have a weight ofthe forests have a weight of 1, then there is a 10:1 ratio between the probability that a subswill be dropped on a road as compared to a forest. If this system grows by 20%, then the weithe roads increases to 12 and the forest increases to 1.2. This gives us a 12:1.2 ratio wequivalent to a 10:1 ratio.

The next two options, “Create Map from Parameter Set” and “Create Map from Polygons”, arfocus of this chapter. These options are used to create Traffic Maps for new or existing sysPolygons are useful when traffic data does not exist either for the system being studied orexisting underlying system.

From here, the system designer may proceed to one of the following methods of creating a TMap:

• Polygons with Traffic Data

• Existing Wireless System Traffic

• New CDMA System with Projected Traffic

• CDMA System with Commercial Traffic

The desired outcome is to create a map that defines where subscribers are located while ttheir phones.


5


criberhese, etc.).same

ion forll beenaphics

ishedfic

5.2.1.1 Using Polygons With Traffic Data

Polygons with traffic data are useful in situations where the designer desires subsdistributions which are not linked to RF coverage of an existing or projected system. Tsubscriber distributions are geographically defined (such as Census data, Zip Code dataNetPlan currently does not directly accept this geographically linked input data, though theresult may be achieved through the use of the NetPlan Polygons utility.

5.2.1.1.1 Drawing the Polygons

The first step is to create the polygons within the system to represent each geographic regwhich traffic will be assigned. The polygons should be saved to the analysis once they have adrawn and labeled. For instructions on the creation of polygons, see Chapter 5 “Grids and GrObjects” of the NetPlan Basic Concepts User’s Manual.

5.2.1.1.2 Creating the Traffic (Distribution) Map Using Polygons

The second step is to create the Traffic Map. The generation of the Traffic Map is accomplby opening the Traffic Map window via the pull down menu Traffic Engineering>Edit>TrafMap. See Figure 5-2:


5


t

isit

n

g

r

-r

raffic

Figure 5-2: Create Map from Polygons

From this window, the “Create Map fromPolygons” button should be selected.

A list of the polygons by name will bepresented. Initially, all polygons will beassigned a default traffic value of “0”.Clicking upon a polygon name will bring itdown to an editing box directly below the lisof names.

The desired traffic weighting value for thepolygon can be entered in this box. Repeat thprocess of selecting a polygon and assigninga traffic value until all the polygons have beeassigned their traffic weighting values.

Set the resolution value for the resultinTraffic Map. (There is little point in using ahigher resolution for this map than is used fothe creation of the path loss data.)

Note: Traffic can be weighted to appear predominantly on roads or by clutter types. Refeto Section 5.5: “Weighting Traffic By Roadsand Clutter Types” for more details.

To generate the Traffic Map, click on the“Apply” button.

When the processing is complete, save the Traffic Map using the Traffic Engineering>Edit>TMap>File>Save As menu selection within the Traffic Map window.


5


ay best beDMA,. This

m

of therage.reflectestrictsionver/e. Once

rafficin the

.1.5:

5.2.1.2 Using Existing System Traffic

This method uses traffic data from an existing wireless system. The existing system mdissimilar to the new CDMA system. (However, the coverage of the new CDMA system mua subset of the existing system coverage.) It is not necessary for the existing system to be Chave the same quantity or location of cell sites or operate on the same frequency rangemethod will use two basic types of input information.

• The Best Server/Sector or Best Ec/Io Server/Sector image from the existing syste

• The traffic measured from the existing system

5.2.1.2.1 Best Server/Sector Image

The first step is to create a Best Server/Sector image. This image must model the coverageexisting system from which the traffic statistics were gathered and not model the CDMA coveThe cell site data used in the creation of this Best Server/Sector image should be defined tothe operational condition of the existing cellular system. An exclusion mask can be used to rthe image to areas where CDMA traffic is expected (see Section 5.2.1.6: “Application of ExcluMask for Traffic Distribution”). Any exclusion mask to be used in the creation of the Best SerSector image should be made and selected prior to generating the Best Server/Sector imagthe Best Server/Sector image has been created, save the analysis before continuing.

5.2.1.2.2 Traffic Parameters

The second step is to create a traffic parameters file. This is accomplished by opening the TParameters window via the pull down menu Traffic Engineering>Edit>Parameters as shownfollowing figure.

Note: Traffic data which exists in a file for the system can be imported (see Section 5.2“Importing Traffic Data”).


5


affic

Figure 5-3: Edit Traffic Parameters

Traffic can also be hand edited via the Traffic Parameters window (see Figure 5-4: "TrParameters").


5


/

gse,on.by

(a

heicg

]

n

em.

d used

ortantrviceraffic

Figure 5-4: Traffic Parameters

There are two choices for technology, AnalogCDMA or TDMA. In this example, Analog/CDMAis selected.

For non-uniform traffic, as is the case for an existinsystem, parameters will be set per sector. In this cathe user should click on the Selected Sectors buttThen select a sector in the existing system imageusing the left mouse button to click on a sector.

Erlang B is the model normally chosen for CDMAsimulations.

The desired grade of service must be populatedtypical value of 2 may be used).

A value of “0” is used for the growth percentage.

The measured traffic for the selected sector in texisting system is then entered in the Offered Traffbox. [Units are not important (Erlangs, etc.) as lonas the same units are used from sector to sector.

The remainder of the boxes will self calculate whethe Apply button is clicked.

The user should follow these steps for all the sectors with traffic data from the existing syst

Finally, the parameters file should be saved via the File>Save As menu.

It is recommended that a report be produced (via the Traffic Parameters>Report option) anto verify the information entered into the parameter set.

Although the tool calculates items such as Carried Traffic, Channels Equipped, etc., it is impto understand that this data is superfluous to the CDMA Traffic Map. Desired Grade of Se(GOS), Growth Percentage and Offered Traffic are the only fields of concern. The Offered Tfield is the traffic weight for a given sector.


5


lectedrafficffic

r.

ageon theaveon.

orld

5.2.1.2.3 Create the Traffic (Distribution) Map

The third step is to create the Traffic Map. The parameter set previously created should be sethrough the Parameter Set ellipsis in the Traffic Engineering window. The generation of the TMap is accomplished by opening the Traffic Map window via the pull down menu TraEngineering>Edit>Traffic Map.

Figure 5-5: Create Map from Parameter Set

From this window, the “Create Map fromParameter Set” button should be selected.

Note: Traffic can be weighted to appeapredominantly on roads or by clutter typesRefer to Section 5.2.1.7: “Weighting Traffic ByRoads and Clutter Types” for more details.

Click on the “Apply” button

A new window will open with a list of Best Server/Sector images from which the desired imcan be selected (in this case, the Best Server/Sector image for the existing system). Clicking“OK” button will launch the creation of the Traffic Map. When the processing is complete, sthe Traffic Map using the Traffic Engineering>Edit>Traffic Map>File>Save As menu selecti

The user should view the resulting Traffic Map to verify that it is representative of the real wtraffic distribution. Refer to Section 5.2.1.8: “Viewing Traffic” for instructions.


5


arketd willl use

stem.s beens Best>BestOP

ed forow,ters inttingss willk cansion

c/Io/Sector

fic percreate

n thisured

newor thisate the

5.2.1.3 New CDMA System With Projected Traffic

This method relies on estimating the expected traffic loads for a new CDMA system in a mwhere measured traffic is not available. In this approach, the CDMA system to be deployeprovide the coverage image to be used for defining the traffic distribution. This method wiltwo basic types of input information.

• The Best Ec/Io Server/Sector image for the new CDMA system

• The expected traffic per sector for the new CDMA system

5.2.1.3.1 Best Ec/Io Server/Sector Image

The first step is to create a preliminary Best Ec/Io Server/Sector image for the new CDMA syThis image should model the constrained coverage of the loaded system. As no simulation harun, the impact of a traffic load on the coverage must be assumed. In NetPlan, the first pasEc/Io Server image can be created using the Images>Create>CDMA Simulator>UnloadedEc/Io Server menu selection. Prior to running the unloaded simulation, the T-ADD/T-DRvalues within the system should be set to -10 dB. T-ADD and T-DROP can easily be changall carriers at one time using the Edit>Carrier menu selection. From within the “Carrier” windquery the system and then click on “Update All” to display the “Carrier Update All” window. En-10 for T-ADD and T-DROP and then click “OK” to apply these updates to all of the carrierthe system. Remember to change the T-ADD and T-DROP values back to their original seprior to running the loaded system simulations. These elevated T-ADD and T-DROP valueresult in reduced coverage which will approximate a load on the system. An exclusion masbe used to restrict the image to areas with traffic (see Section 5.2.1.6: “Application of ExcluMask for Traffic Distribution”). Any exclusion mask to be used in the creation of the Best EServer/Sector image should be created and selected prior to creating the Best Ec/Io Serverimage.

5.2.1.3.2 Traffic Parameters

The second step is to create a traffic parameters file. It is assumed that expectations of trafsector have been agreed upon and that this information is ready for use. The procedure tothe traffic parameters file is the same as in Section 5.2.1.2.2: “Traffic Parameters” (except icase, the traffic values in the “Offered Traffic” field are expected values instead of measvalues).

5.2.1.3.3 Creating the Traffic (Distribution) Map

The third step is to create the Traffic Map using the Best Ec/Io Server/Sector image for theCDMA system and the traffic parameters that are based on the expected traffic per sector fsystem. The procedure to create the Traffic Map is the same as in Section 5.2.1.2.3: “CreTraffic (Distribution) Map”.


5


for anaffic

h isragenput

te a.3.1:

rafficas theof thefrom

sectortraffic

ageTraffic

bers”)ystemn of

5.2.1.4 CDMA System with Commercial Traffic

This method is to be used in situations where no prior NetPlan simulation has been runexisting CDMA system. In this instance, a Traffic Map would not already exist and a new TrMap would need to be generated.

This method relies on actual traffic loads available from the CBSC for a CDMA system whicin commercial service. In this approach, the deployed CDMA system will provide the coveimage to be used for defining the traffic distribution. This method will use two basic types of iinformation.

• The Best Ec/Io Server/Sector image for the existing CDMA system

• The derived weighted traffic per sector from the existing CDMA system

5.2.1.4.1 Create Best Ec/Io Server/Sector Image

The first step (as in Section 5.2.1.3: “New CDMA System With Projected Traffic”) is to creapreliminary Best Ec/Io Server/Sector image. To do this, follow the procedure in Section 5.2.1“Best Ec/Io Server/Sector Image”.

5.2.1.4.2 Create Traffic Parameters from CBSC Statistics

The second step is to create a traffic parameters file as described in Section 5.2.1.2.2: “TParameters”. However, when creating this file, a weighted traffic per sector value is usedamount of offered traffic per sector. The CBSC statistics do not provide a measurementoffered traffic per sector. Therefore, a weighted traffic per sector number should be derivedother CBSC traffic statistics, such as origination attempts. Replacing the offered Erlangs perwith the weighted traffic per sector based on origination attempts has the same impact on thedistribution since this is based on the weighting per region.

5.2.1.4.3 Create the Traffic Map

The third step is to create the Traffic Map using the preliminary Best Ec/Io Server/Sector imand the traffic parameters that are based on the CBSC statistics. The procedure to create theMap is the same as in Section 5.2.1.2.3: “Create the Traffic (Distribution) Map”.

5.2.1.4.4 Run Preliminary Simulation

The number of Erlangs for the system (see Section 6.2.2.4.2: “CDMA Parameters - Subscrican be determined from the traffic carried between the CBSC(s) and the MSC (switch). The sdesigner can obtain this information from the CBSC(s) statistics. A preliminary simulation ru50 to 100 drops can now be made.


5


afficMobe the

in theared torafficelationwill

tem:

ctor)the

veralraffic

. Ther for

5.2.1.4.5 Verify Traffic Map Accuracy

The results of the preliminary simulation run can be used to verify that the NetPlan trdistribution is similar to the field/CBSC measurements. The NetPlan statistical results of Num(number of subscribers) per sector from the CellStat_xx files, can be used to determinpercentage of traffic carried per sector with respect to the total number of subscriberssimulation. The sectors can then be ranked according to this percentage and the result compthe ranking obtained from the CBSC(s) statistics. It may be necessary to adjust the TParameters, generate new Traffic Maps and verify their accuracy before a reasonable corrwill exist between the preliminary simulation results and CBSC(s) statistics. The Traffic Mapbe used for further simulation work once the correlation is achieved.

5.2.1.4.6 Example

The following example illustrates the process of creating a Traffic Map for a four omni cell sys

Step 1: Create a preliminary Best Ec/Io Server/Sector Image

Create the Best Ec/Io Server/Sector image for the four cell system.

Step 2: Create Traffic Parameters from CBSC Statistics

Obtain the origination attempts per site/sector (for an omni site, there is only 1 seduring the busy hour from the CBSC statistics. This number is most indicative oftraffic since it does not incorporate soft/softer handoff. It is recommended that seweeks of busy hour statistics be averaged together. In this way, any anomalies in tfrom one day to the next will be averaged out.

Table 5-1 shows the CBSC statistics for an example system of four omni cell sitessecond column in Table 5-1 presents the Busy Hour Origination Attempts per Sectothis example.

Table 5-1: Weighted Traffic per Sector

Omni Cell SitesBusy Hour Origination Attempts

per Sector

Weighted Traffic per Sector =[Busy Hour Origination Attempts per Sector/Total

System Busy Hour Origination Attempts]

ALPHA 100 0.133

BETA 200 0.267

GAMMA 50 0.067

DELTA 400 0.533

750= [Total System Busy HourOrigination Attempts]


5


n beents

mber

’s of. Ther thestem.

hesetrafficen

.2.2:

c/Io).

ation

ob)ults

Once the origination attempts per sector are known, a weighted traffic number cacalculated to create the NetPlan Traffic Map. The third column of Table 5-1 represthe Weighted Traffic per Sector calculation. This calculation is used as NetPlan’s nuof Erlangs per sector of the Best Ec/Io Server/Sector image.

If the number of origination attempts per sector for a particular system is small (tenattempts), there should be no need for a calculation of Weighted Traffic Per Sectororigination attempts would then become NetPlan’s number of offered Erlangs fosector. Neither these numbers or their sum are the actual effective Erlangs for the syThey represent the proportional traffic distribution for the system.

As seen in Table 5-1, the value for Weighted Traffic per Sector can be quite small. Tnumbers should be scaled to ease their use. For instance in Table 5-1 the weightedvalues could all be scaled up by a common factor of 100. The GAMMA site will thhave 6.7 Erlangs instead of 0.067.

Using this information, create a traffic parameters file as described in Section 5.2.1“Traffic Parameters”.

Step 3: Create the Traffic Map

Create the Traffic Map using the Traffic Parameters set and preliminary Best EServer/Sector image (see Section 5.2.1.2.3: “Create the Traffic (Distribution) Map”

Step 4: Preliminary Simulation Run Using New Traffic Map

Assuming that in this example system the CBSC(s) traffic is 50 Erlangs, run a simulof 50 to 100 drops with the number of Erlangs per drop equivalent to 50.

Step 5: Verify Initial Results With Field/CBSC Data

Check the NetPlan statistical results and determine the subscriber (NumMdistribution. Then, compare this distribution to the field distribution. The NetPlan resmight look as in Table 5-2: "NumMob Results".


5


fieldtrafficce,herionata.

the

PSanceed uponc data

olumn,theet. Thee firstondusedis an

s, the

.

The results indicated in Table 5-2 represent a perfect NetPlan representation of thedata. In reality, these results may vary. Varying results are acceptable as long as thedistribution projects a similar weighted distribution to the one in the field. For instanif the simulation shows that the traffic region surrounding the GAMMA site has a higtraffic density than the region surrounding the BETA site, then the traffic distributdensity should be regenerated to bring the distribution in alignment with the field d

5.2.1.5 Importing Traffic Data

Traffic data can be imported directly into NetPlan. For modeling a CDMA system usingNetPlan CDMA Simulator, the imported data will be used as the Offered Traffic.

The first step is to obtain traffic data from a live system. This data may reflect existing AMsystem data, TDMA system data, CDMA system data (obtained from CBSC performmanagement statistics), or ZIP code and census data. The traffic data per sector may be basinformation such as busy hour call attempts, effective Erlangs, or offered Erlangs. Electroniwill speed the process, although the data format may need to be modified.

Using a spreadsheet, create a table that contains the system/region/site/sector in the first cand the traffic weight (for example: offered traffic) in the second column. A title forspreadsheet, preceded with the # symbol, can be entered in the first line of the spreadshesecond line is the heading line, and it must contain the tab delimited column headings. Thcolumn heading will always be “Sector”. The “S” in Sector must be capitalized. The seccolumn heading can be any descriptive words for the data. In our example, “offered traffic” isas the second column heading. Save the text file using tab delimiters. The following tableexample text file prepared for importing traffic data for 16 sites. For demonstration purposesectors are weighted 1 through 8 repetitively.

Table 5-2: NumMob Results

Omni Cell Site NumMobNumMob

Distribution

ALPHA 6.66 13.3%

BETA 13.3 26.7%

GAMMA 3.33 6.7%

DELTA 26.6 53.3%


5


.

Table 5-3: Sample Traffic Data Import File

# This is a sample report usedto import traffic dataSector offered trafficsystem1/region1/08/1 1system1/region1/08/2 2system1/region1/08/3 3system1/region1/76/1 4system1/region1/76/2 5system1/region1/76/3 6system1/region1/86/1 7system1/region1/86/2 8system1/region1/86/3 1system1/region1/207/1 2system1/region1/207/2 3system1/region1/207/3 4system1/region1/208/1 5system1/region1/208/2 6system1/region1/208/3 7system1/region1/209/1 8system1/region1/209/2 1system1/region1/209/3 2system1/region1/211/1 3system1/region1/211/2 4system1/region1/211/3 5system1/region1/213/1 6system1/region1/213/2 7system1/region1/213/3 8system1/region1/216/1 1system1/region1/216/2 2system1/region1/216/3 3system1/region1/217/1 4system1/region1/217/2 5system1/region1/217/3 6system1/region1/218/1 7system1/region1/218/2 8system1/region1/218/3 1


5


system
Once the spreadsheet has been prepared, place the file into a directory associated with theanalysis.
system1/region1/219/1 2system1/region1/219/2 3system1/region1/219/3 4system1/region1/241/1 5system1/region1/241/2 6system1/region1/241/3 7system1/region1/255/1 8system1/region1/255/2 1system1/region1/255/3 2system1/region1/257/1 3system1/region1/257/2 4system1/region1/257/3 5system1/region1/264/1 6system1/region1/264/2 7system1/region1/264/3 8

Table 5-3: Sample Traffic Data Import File

# This is a sample report usedto import traffic data


5


tingeters

The Traffic Engineering Tool is then used to import this data. This is done by first selecParameters from the Traffic Engineering Edit pull down menu. Then from the Traffic Paramwindow, select File>Import as shown in Figure 5-6.

Figure 5-6: Import Traffic Parameters Menu


5


le.

Figure 5-7: Importing Traffic Parameters

Select the traffic file to import.

Erlangs should be chosen.

When the Offered Traffic buttonis pressed, a window will open whichcontains import choices. The exampfile has one heading, “offered traffic”Therefore, this is the only selectionin the window. Select OfferedTraffic.

Press OK. This sets the path forNetPlan to locate the traffic datarequired.

being changed and the Growth Percentage is set to 0.for all sectors. In this example, Desired GOS is notmenu. At this point, common parameters can be setThe tool will return the user to the Traffic Parameters

Press Apply, then use the pull down menu to savethe new traffic parameters (File>Save As) into adirectory associated with the system analysis.


5


tion)Save1.8:

ementer theTraffic

hting.ghtingt be

ed anlusion

n of theTraffic

lusion

Finally, follow the same procedure used in Section 5.2.1.2.3: “Create the Traffic (DistribuMap” and shown in Figure 5-5: "Create Map from Parameter Set" to create the Traffic Map.the new Traffic Map. To display the image for verification, follow the steps in Section 5.2.“Viewing Traffic”.

5.2.1.6 Application of Exclusion Mask for Traffic Distribution

The use of an exclusion mask during the creation of the Traffic Map serves to restrict the placof subscribers in a simulation drop. This is done by limiting the coverage represented by eithBest Server/Sector or Best Ec/Io Server/Sector images before they are used to generate aMap.

Locations within the service area that should not have subscribers need a zero traffic weigClutter types (such as water, etc.) or small polygons may be used to assign a zero traffic wei(see Section 5.2.1.7: “Weighting Traffic By Roads and Clutter Types”). Areas that can noassigned a zero traffic weighting through the use of clutter types, roads, or polygons will neexclusion mask (for example, mountain tops and drainage ditches). The creation of the excmask is described in the NetPlan RF Engineering User’s Manual.

Once an exclusion mask has been created and saved, it should be selected for the creatioBest Server/Sector or Best Ec/Io Server/Sector images in the early phases of generating theMap. This is accomplished using the Configure>Simulation Parameters>Geographic>ExcMask menus (see Figure 5-8: "Select Exclusion Mask").


5


henlusion

ystemp is

n inn thefrom

Figure 5-8: Select Exclusion Mask

From this window, choose the exclusion mask created for the analysis and press “OK”. Wcreating the Best Server/Sector or Best Ec/Io Server/Sector image, the effects of the excmask will be taken into account.

Note: If an exclusion mask to constrain the simulation images is not desired, then the sdesigner should “deselect” this exclusion mask once the creation of the Traffic Macompleted. To leave it “active” would incorrectly impact all images created later othe system design procedure. To deselect the active exclusion mask, pull dowConfigure>Simulation Parameters>Geographic menu, delete the exclusion maskthe window, and select OK.


5


sedthe

ribers

ffictedandbox

e usedlygonscludespe ise (or. ForecondSector

ectorthanbilityctor Ats are

tingusednsity

f a cityns as-sector

5.2.1.7 Weighting Traffic By Roads and Clutter TypesThe NetPlan Traffic Engineering Tool can modify the traffic density for specific locations baupon their definition as roads or clutter types. This is accomplished by weighting the traffic toroad class or clutter type. Increased weighting for an area increases the probability of subscbeing placed there during simulation.

Access to this feature is accomplished by opening the Traffic Map window via the TraEngineering>Edit>Traffic Map pull down menu. The three operations that allow weighdistributions are, “Redistribute Current Traffic Map”, “Create Map from Parameter Set”,“Create Map from Polygons”. Figure 5-9: "Weighted Distribution" shows the dialogueassociated with this feature.

The standard clutter types are listed in Table 5-4: "Standard Clutter Types". This table can bas a worksheet to determine the desired weightings to be used for each clutter type. Poexisting in the analysis can also be chosen as clutter types. Although the Standard List inmany clutter and road types, it is not necessary to weight each one. If a clutter or road tyselected and a weight is assigned, then within the Traffic Map there will be an increasdecrease) in the probability that a subscriber will be assigned to that clutter or road typeexample, let a given sector (Sector A) have its parameter of Offered Traffic set to 10, and a ssector (Sector B) have its parameter of Offered Traffic set to 5. Therefore, the ratio betweenA and Sector B is 10:5. Now, assume Road Class 1 has been given a weight of 10. Within SA, Road Class 1 will have a 10 times greater probability of having a subscriber assignedelsewhere in Sector A. Within Sector B, Road Class 1 will also have a 10 times greater probaof having a subscriber assigned than elsewhere in Sector B. However, Road Class 1 of Secompared to Road Class 1 of Sector B, will still have a 10:5 ratio. Remember, these weighdistributed over an area.

NetPlan provides the ability to individually redistribute the probability weightings of an exisTraffic Map. This can be done for the coverage area of each sector’s footprint. This may beas an advantage in systems where one clutter or road definition has widely varying traffic deacross the system. For example, Road Class 1 may contain heavy traffic within the center oas compared to the surrounding clutter, yet be sparsely populated in the outlying regiocompared to the surrounding clutter there. This disparity can be addressed on a sector-bybasis.


5


e

”ap

re

ntoe

be.

o

Roadribers

r type.ment.

the

y asy oftributedkeep

ts ander usein arior to

Figure 5-9: Weighted Distribution

The “Redistribute Current Traffic Map”button must be selected to change thexisting weighting for a previouslygenerated Traffic Map.

The “Create Map from Parameter Setbutton must be selected to start a new musing a parameter set.

The “Create Map from Polygons” buttonmust be selected when only polygons aused to generate a Traffic Map.

If the “Redistribute Current Traffic Map”button is selected, then weightings caeither be applied to the entire system orthe sectors in a sub-group by selecting onof these “Scope” buttons.

To select road classes or clutter types toadded to the list, press the “Add” buttonThe “Add” menu will open up. Select theitem of interest from this list and click on“OK”. Repeat this step for each item tbe added.

Clicking on an item will bring it down tothe edit box where the value of theweighting can be changed.

In this example, Road Class 1 will be twice as likely to receive a dropped subscriber thanClass 2. The Central Business Dist. will have an equal probability of receiving dropped subscas Road Class 2.

The “0” value assigned to Lakes prevents any subscribers from being placed on that clutteThis action is much easier than resorting to an exclusion mask for restricting subscriber place

Once all the alterations to the weighting are complete, pressing the “Apply” button will initiategeneration of the Traffic Map.

Note: It is important that the subscriber distribution within a simulation match as closelpossible to the subscriber distribution in the real system. The higher densitsubscribers in housing and business areas mandates that more subscribers be disin these areas. Rapid growth in many communities outpaces the USGS ability totheir Land Use/Land Cover database up to date. As a result, large developmensubdivisions are often missing. It is recommended that the system design enginethe NetPlan Clutter editor (see Section 3.2.2.2.1: “Editing Clutter ClassificationsClutter Database”) to make the necessary updates for any newly developed areas pcreating the Traffic Map.


5


.

Table 5-4: Standard Clutter Types

Clutter Type Weight Clutter Type Weight

Road Class 1 Forested Wetland

Road Class 2 Nonforested Wetland

Road Class 3 Dry Salt Flats

Road Class 4 Beaches

Road Class 5 Sandy Areas Other than Beaches

Road Class Other Bare Exposed Rock

Road Class Rail Strip Mines, Quarries, and Gravel Pits

Central Business Dist. of Large Cities Transitional Areas

Residential, Suburban Areas Mixed Barren Land

Commercial and Services Shrub and Brush Tundra

Industrial Herbaceous Tundra

Trans., Comm., and Utilities Bare Ground

Industrial and Commercial Complexes Wet Tundra

Mixed Urban and Built-up Land Mixed Tundra

Other Urban and Built-up Land Perennial Snowfields

Cropland and Pasture Glaciers

Orchards, Groves, Vineyards Polygon 1

Confined Feeding Operations Polygon 2

Other Agricultural Land ... Polygon n

Herbaceous Rangeland

Shrub and Brush Rangeland

Mixed Rangeland

Ocean

Streams and Canals

Lakes

Reservoirs

Bays and Estuaries


5


ution

. Theap.ing

les.

5.2.1.8 Viewing Traffic

Traffic Map images should be checked to verify that the map represents the traffic distribdesired. There are three display types:

• Image

• Arcs

• Numeric

Numeric and Arcs are most helpful when verifying that the given weight per sector is accurateImage also will verify the weight per sector, but is most often used to view the final Traffic MThis final Traffic Map will show the distributed weight per area including any special weightfor clutter or road types.

The data imported in Section 5.2.1.5: “Importing Traffic Data” is used in the following examp


5


entsplay

r/

st

5.2.1.8.1 Viewing Offered Traffic Image (Weighting Per Sector)

Recall that the sample traffic data imported in Section 5.2.1.5: “Importing Traffic Data” represtraffic weight per sector. To view the data as an image, follow the steps in Figure 5-10: "DisImage - Offered Traffic".

Figure 5-10: Display Image - Offered Traffic

Select the Traffic Map via the “Traffic Map”ellipsis.

“Offered Traffic” is selected.Select the image desired. In this case

Verify the parameter set chosen is correct.

Depress the “Image” button, followed by the“Apply” button. This action will open the ImageSelection window where the user selects thecoverage image to use. Select Best Ec/Io ServeSector. Note: If this is the first Traffic Mapcreated and no simulation has been run, the BeServer/Sector will automatically be selected bythe tool. If the Traffic Map was created usingPolygons, neither of these images will be requiredand the tool will not prompt for Image Selection.Click “OK” to generate the image.


5


ring

Figure 5-11: Offered Traffic Image Utilizing Best Ec/Io Server/Sector

The image colors can be set by selecting Edit>Image Coloring from the Traffic Engineewindow (see Figure 5-12).

Figure 5-12: Select Color Intervals

Traffic per Sector.image colors to reflect OfferedSelect “Intervals” to set the


5


s suchesentsolors,

tton.ge

he arc(see

afficForcanered

By default, the Auto Intervals are applied. Press the Intervals button and set the image colorthat each color represents a range of Offered Traffic weights. In this example, each color repra weighting of one to eight. By comparing the data imported for each sector with the image cthe weighting for each sector can be verified.

To view the same data using Arcs, simply select Offered Traffic beside the Arcs display buPress the “Arcs” display button and then “Apply”. This time there will be no prompt for ImaSelection. The colors applied are identical to the colors in the image shown in Figure 5-11. Tcoloring can be changed by selecting Edit>Arc Coloring from the Traffic Engineering windowFigure 5-12).

Figure 5-13: Offered Traffic Displayed with Arcs

The Numeric option is applied in a similar fashion as the Arc selection. Select Offered Trbeside the Numeric display button. Then press the “Numeric” button followed by “Apply”.Figure 5-14 the Network Elements (Sites) IDs are turned off for clarity. The Numeric optionbe useful if applied simultaneously with a displayed image as shown in Figure 5-15: "OffTraffic Image Combined with Numeric Display".


5


original

Figure 5-14: Numeric Display of Offered Traffic

Figure 5-15: Offered Traffic Image Combined with Numeric Display

These images should be compared to the imported data to verify each sector matches thedata.


5


orld

ic

e

5.2.1.8.2 Viewing the Traffic (Distribution) Map

The user should view the resulting Traffic Map to verify that it is representative of the real wtraffic distribution. This can be done via the Traffic Engineering window.

Figure 5-16: Viewing Traffic Map

Select the new Traffic Map via the “TrafficMap” ellipsis.

Verify the correct Parameter Set is selected.

Select the image desired. In this case “TraffMap” is selected.

Depress the “Image” button, followed by th“Apply” button.


5


ta”,was

stemoticeability

Continuing with the example using the data imported in Section 5.2.1.5: “Importing Traffic Dathe Traffic Map image is displayed below. Recall from Figure 5-9 that special weightingapplied as follows:

• Road Class 1 = 10

• Road Class 2 = 5

• Lakes = 0

• Streams and Canals = 0

• Central Business Dist. of Large Cities = 5

• Residential, Suburban Areas = 3

Figure 5-17: Example Traffic Map

The image color selections are shown in the following figure. Using the Query tool, the sydesigner can verify the traffic density. The units are in milli-Erlangs per square kilometer. Nhow the water and forrest are white (zero weighting) and the roads stand out as high probareas.


5


wing

Figure 5-18: Example Traffic (Distribution) Map Coloring

Using the same data, if more clutter types are selected for weighted distribution, the folloTraffic Map is created.

Figure 5-19: Example Traffic Map Given More Weighted Clutter


5


criberssed to.2.1.6:

s theIo Bestsector

The system designer needs to keep in mind that for each area shown in the Traffic Map, subshave a probability of being dropped (excluding areas which have zero weight). If the area udistribute subscribers is to be limited, exclusion masks should be used (see Section 5“Application of Exclusion Mask for Traffic Distribution”).

These images (Figure 5-17 and Figure 5-19) illustrate the traffic distribution density acrosarea of the sector. For instance, compare a sector whose weight is equal to 8 but whose Ec/Server/Sector area is small, to a sector with the same weight but a larger area. Although theweight is equivalent, the density varies.


5


d in an thennes.

ht toarrierionsesign.. It also

entiret bearrier isfor the

5.2.2 Determining Multiple Carrier Requirements

This section aids the system designer in determining when additional carriers are requiresystem and how many carriers should be implemented in each site/sector. The sectioaddresses the management of inter-carrier handoffs and the design of handoff transition zo

5.2.2.1 Multi-Carrier RF Design Methodology

The RF system design methodology unique to multi-carrier CDMA systems must be brougmind during the traffic map generation phase of the simulation process. To support multi-csimulations in NetPlan, the Traffic Carrier Map Set (TCMS) was developed. All the decisrequired to generate the TCMS revolve around decisions made for the multi-carrier system dThis section helps the RF system designer make these multi-carrier system design decisionsdiscusses what system performance impacts these decisions will have.

This procedure assumes that there will be a minimum of one carrier deployed throughout thesystem (the ubiquitous carrier). A system design which does not follow this criterion will noaddressed here. It is also assumed that the coverage and performance of the ubiquitous cacceptable when it is not subjected to excessive traffic load. This procedure may be usedinitial deployment of a multi-carrier system or for the growth of an existing system.

It is assumed that the sites used for the additional carrier (Cn) will be co-located with sites deployedfor the ubiquitous carrier (Cu). The deployment of sites for the Cn should form continuous coveragegroupings (see Figure 5-20).

Figure 5-20: Proper Carrier Deployment - Cn

= Cu + Cn= Cu


5


a

seekadingign istions

h theservice

ylreadymed

ore ofe the

nds

There are four steps to making the decision on which sites require an additional carrier(s).

1 Determine how many additional carriers are required for the system.2 Make initial selection of which sites receive the additional carrier(s).3 Determine how hard handoffs will be managed (using DAHHO, MAHHO or

combination of them).4 Project growth and incorporate it into the system design.

5.2.2.2 Determining the Number of Additional Carriers

The expected system traffic load is the determining factor that prompts the designer toadditional carriers. The use of additional carriers is often a better choice to alleviate overloof a system as compared to cell splitting. This is especially true when the original system desproviding sufficient RF coverage for in-building users and data users while meeting expectafor capacity on a single carrier.

The system operator should project the total system traffic load for the time period over whicnew system design is expected to operate. The new design should focus on providing goodduring the traffic growth period, and for the final targeted load.

A simulation study of the ubiquitous carrier (Cu) should be run. The traffic map used for this studshould incorporate all the measured/predicted traffic for the current system. If the system is adeployed with multiple carriers, then the traffic for all the carriers in each sector should be sumtogether and used when creating the traffic map for the Cu study. The Cu study starts simulationsusing a moderate traffic load, then increases this load until a point is reached where one or mthe heavily loaded cells/sectors experiences symptoms of traffic overload. This will determinmaximum traffic load one carrier can support for the current system design. (This exercise isindependent of, and not related to, the traffic growth for the operating system.) The traffic overloadsymptoms may include:

• Decreased PcntMobGood (< 90% per sector)

• Running out of available channel elements

• Exceeding power amplifier capabilities

• Opening of new coverage holes associated with the heavily loaded cell/sector

The system Growth Ratio (GR) is determined by taking the projected total system traffic load adividing it by the traffic load just determined by the Cu simulation study. The number of carrierrequired to support the projected traffic is obtained by rounding up GR to the nearest integer.


5


itional

rienceectors

f

ctor

ill be

en ber.

achedic

Example-1

Assume:

• The system is currently deployed using one carrier.

• The Cu simulation study reaches maximum capacity at 750 Erlangs.

• The projected total system traffic will be 1750 Erlangs

• All sites will be growing at the same rate

Then:

System Growth Ratio = 1750 / 750 = 2.3333Num. Req. Carriers = 2.3333 rounded up = 3

The new system will require a total of 3 carriers in the heavily loaded areas. Therefore, 2 addcarriers must be added to the existing design.

5.2.2.3 Selecting Sites to Receive the Additional Carrier

An expected average maximum sector capacity (Sectmax) can be derived from the Cu simulationstudy statistics by averaging the capacity values for the sectors (within a given area that expea similar loading environment) which have reached their maximum capacity. These are the swhich experienced symptoms of traffic overload in the Cu simulation. (In some instances, thesystem operator may select a more conservative value for Sectmaxwhich would be used instead othe calculated value).

Using the Cu simulation study statistics, create a table listing the traffic carried by each se(Trafcu). Trafcu is multiplied by the Growth Ratio GR (determined from the Cu simulation studytraffic load and the projected system traffic load) to estimate the traffic load each sector wsubjected to in the new system (Trafnew).

The number of carriers each sector will require when subjected to the projected load can thcalculated by dividing Trafnew by Sectmax and rounding up the result to the next whole numbe

Carriers-per-sector = round-up |(Trafnew / Sectmax)|

Example-2

For the purposes of this example, we will assume that five sectors of an 8 Kbps system retheir maximum capacity when the Cu simulation study results for these sites exhibit traffoverload symptoms. The five sectors are shown in Table 5-5:


5


ofirue

mberic load

for

Shown is the average value for the numbermobiles for each of the five sectors. Thevalues are then averaged to arrive at the valof Sectmax.

Note: From Example-1, the system Growth Ratio (GR) = 2.3333.

Table 5-6: "Determining the Number of Carriers per Sector" was created to determine the nuof required carriers for each sector in the system. These determinations are based on traffonly.

Note: Only a portion of this table is shown below. A complete table would contain valuesall the sectors in the system

Table 5-6: Determining the Number of Carriers per Sector

Sector Name Avg. NumMob Mult. by GR(2.333)

Div. by Sectmax(15.06)

Round Up =Carriers/Sector

Site 101/1 3.77 8.80 0.58 1

Site 101/2 4.51 10.52 0.70 1

Site 101/3 5.23 12.20 0.81 1

Site 102/1 7.10 16.57 1.10 2

Site 102/2 6.84 15.96 1.06 2

Site 102/3 4.55 10.62 0.71 1

Site 104/1 2.95 6.88 0.46 1

Site 104/2 3.41 7.96 0.53 1

Site 104/3 2.73 6.37 0.42 1

Site 105/1 1.59 3.71 0.25 1

Table 5-5: Determine Sectmax

Sector Name Average NumMob

Site 107/3 15.8

Site 122/1 13

Site 123/3 15.6

Site 157/2 16.2

Site 237/1 14.7

Sectmax 15.06


5


use aavee color,proper

mentrrier

Thisoffs.

5.2.2.4 Inter-Carrier Hard Handoff Management

When determining the inter-carrier hard handoff management for the system, it is helpful toBest Server/Sector image for the Cu simulation study. This Best Server/Sector image should hthe sector colorings changed so that all sectors which need one carrier are assigned the samall sectors which need two carriers are assigned a second color, and so on. Figure 5-21: "ImCarrier Deployment - Cn" represents such an image where two carriers are required.

Figure 5-21: Improper Carrier Deployment - Cn

This deployment of a second carrier would support the underlying traffic load if the manageof the inter-carrier handoffs were not taken into consideration. The goal of a good cadeployment design should try to minimize the number of cells involved in hard handoffs.design, in its current state, is not optimized to limit the number of cells involved in hard handA few instances of problematic second carrier deployments are shown in Figure 5-21.

= Cu + Cn= Cu

Area-1 Area-2 Area-3


5


berserferesecond

r

ed bycribersld be

son forarrierstors/

Figure 5-21 Area-1

An isolated “island” of single carrier coverage (Area-1) is depicted in Figure 5-21. All subscritraveling through this area will be forced to hand down to Cu. Since hard handoffs are morsusceptible to problems than soft handoffs, they should be minimized. This situation also intewith the load balancing between the carriers in the region. Subscribers that originate on the scarrier (Cn) in the surrounding two carrier coverage area will hand down to Cu while the subscribertravels through the one carrier area and will then remain on Cu as they pass back into the two carriecoverage area on the other side. The net effect is to have more users remain on carrier Cu thandesired.

The better deployment choice would be to add the second carrier, (Cn) in Area-1, even though thetraffic load does not warrant it (See Figure 5-22 Area-1).

Figure 5-22: Corrected Carrier Deployment - Cn

Figure 5-21 Area-2

Two isolated “islands” of two carrier coverage (Area-2) are depicted in Figure 5-21, separatthe coverage of one single carrier site. Unless there is a physical barrier preventing subsfrom traveling between these two islands of two carrier coverage, a second carrier shoudeployed on the single carrier site situated between them (See Figure 5-22 Area-2). The reathis is to minimize the number of hard handoffs in the area. The load balancing between the cwill not be significantly improved due to the high number of surrounding single carrier secsites.

= Cu + Cn= Cu

Area-1 Area-2 Area-3


5


lddingd.

pictedribersto

ain onard

The two cell sites assigned carrier Cn should not be designated as DAHHO sites as it wouseverely reduce their traffic handling capability. MAHHO must be implemented in the surrouncell sites to allow the two isolated Cn sites the ability to carry a reasonable traffic loaImplementing the second carrier on the site located between the two isolated Cn sites increases theoverall system capacity and reduces the number of hard handoff occurrences.

Figure 5-21 Area-3

The “harbor” of single carrier coverage surrounded by two carrier coverage (Area-3) as dein Figure 5-21, provides essentially the same problem encountered in Area-1. Subscoriginating on the second carrier (Cn) in the surrounding two carrier coverage area, hand downCu when traveling through the one carrier area. They will then remain on Cu as they pass back intothe two carrier coverage area on the other side. The net effect is to have more users remcarrier Cu than desired. Additionally, this deployment does not minimize the number of hhandoffs.

The better deployment choice would be to add the second carrier (Cn) in Area-3 even though thetraffic load does not warrant it (See Figure 5-22 Area-3).


5


nd themore

er (seehardesign.

stemuested.

Figure 5-23 Beyond Estimated Growth

The example design has evolved to handle both the projected traffic growth for the system adifficulties encountered with hard handoff issues (see Figure 5-22). The conversion of a fewcell sites to two carrier configuration would consolidate the coverage area of the second carriFigure 5-23). The overall load balancing for the system would be better, the number ofhandoffs would be reduced and the system would be ready for traffic growth beyond the dgoal. The additional cost of this choice should be considered when making such a decision

No action should be taken in this direction without close interaction and approval from the syoperator. It represents capital expense and system capacity beyond what was originally req

Figure 5-23: Carrier Deployment - Cn Beyond Estimated Growth

= Cu + Cn= Cu


5


at thisitous-site,nt. The.5.2 to

ctorscarrierallyivesinsuretion

afficdoffoff

5.2.2.5 Choosing MAHHO or DAHHO for Transition Zone Sites

The determination of which sites/sectors will be assigned the new carrier have been madepoint. A decision on how hard handoffs will be managed from the new carrier to the ubiqucarrier in the transition zone must now be made. This decision will be handled on a site-bysector-by-sector basis as trade-offs between cost and underlying traffic are taken into accoutwo types of hard handoff management are described in Section 5.2.2.5.1 and Section 5.2.2give the designer information for making these decisions.

5.2.2.5.1 MAHHO Impacts

Mobile Assisted Hard Handoff is realized by deploying pilot beacon emitters on those sewhere the system designer intends all subscribers to perform a hard handoff from a givento an underlying carrier. The starting point for the pilot power level of the pilot beacon is typicat least 10 dB lower than the pilot power setting for the underlying carrier. This effectively gthe pilot beacon a smaller coverage area than the underlying carrier. This approach helpsthat the underlying carrier will provide sufficient signal strength to reliably maintain a connecwhen the subscriber makes the hard handoff.

If the boundary for a MAHHO lies between two cell sites, then the coverage from the trcarrying site will expand while the coverage of the pilot beacon will contract. The hanboundary from Cn to Cu will occur closer to the pilot beacon site than the underlying handboundary between the two cell sites operating on Cu. (see Figure 5-24)

Figure 5-24: MAHHO Pilot Beacon Coverage

The traffic carrying sectors along such a border which are assigned Cn will carry a full traffic loadout to the edge of the boundary.

= Cu + Cn= Cu

Underlying Carrier Transition Zone

PB = PILOT BEACON

PB


5


f thethesamet (seethe

aseonsload

5.2.2.5.2 DAHHO Impacts

While Pilot Beacon sectors carry no traffic, DAHHO sectors do. This changes the behavior otransition boundary associated with DAHHO. A DAHHO sector will carry a small portion ofoffered traffic. This occurs because the DAHHO sector can support soft handoffs on thecarrier and may allow some origination of subscribers when the DAHHO sector is dominanTable 14-2: “DAHHO Truth Table”). NetPlan will take this into account while generatingTraffic Carrier Map Set.

A DAHHO sector will keep the transition boundary closer to the DAHHO cell site than is the cwith MAHHO. The implementation of DAHHO may save the expense of deploying pilot beacon neighboring sites, but will not allow the sectors defined as DAHHO to carry a large traffic(see Figure 5-25).

Figure 5-25: DAHHO Coverage

= Cu + Cn= Cu

Underlying Carrier Transition Zone

DAHHO

DAHHO


5


dures

andlidatean

on thell beat aremiliarior to

eachafficriers.ardoff in

e theting, or

fficier in a

alysis,that

se the

5.2.3 Multiple Carrier - Traffic Carrier Map Set

This section explains how to generate a Traffic Carrier Map Set and provides the procerequired to perform multi-carrier simulations in NetPlan.

This section is laid out such that the system designer will first learn multi-carrier definitionsthe traffic carrier map set algorithm. The section then describes how to create, display and vaa Traffic Carrier Map Set (TCMS). Finally, this section explains how to use the TCMS inanalysis and if necessary, how to modify it.

Prior to the creation of a TCMS, the system designer must have already made the decisionsnumber of carriers each sector/site will receive and how inter-carrier hard handoffs wimanaged (see Section 5.2.2). Multi-carrier simulations make use of all the procedures themployed in single-carrier simulations. For this reason, it is necessary for the reader to be fawith all of the single-carrier design procedures that are described earlier in this chapter, prproceeding with multi-carrier simulations.

NetPlan models a multi–carrier system by generating separate traffic distribution maps forcarrier from a single carrier–independent traffic distribution. In order to create the trdistributions, the engineer must first associate each CDMA sector with one or more carAdditionally, each carrier type must be identified as traffic, MAHHO (mobile–assisted hhandoff), or DAHHO (database–assisted hard handoff). This allows the effects of Hard Handa multi–carrier system to be modeled.

Once the carriers and traffic types have been defined for each sector, the algorithm will dividtraffic distribution from the carrier–independent traffic map to each carrier using a weighalgorithm. This weighting is in part based on the carrier type of each sector (traffic, MAHHODAHHO). The result of this algorithm is a Traffic Carrier Map Set (TCMS) which is a set of tradistribution maps, one for each carrier. A separate NetPlan analysis is set up for each carrsystem.

Simulations for each carrier are run from these separate analyses. Within each carrier anbefore running simulations, the engineer must specify the desired carrier and the TCMSdefines that carrier’s traffic map. The simulations must include all sites and sectors that uspecified carrier.


5


ation

one

thealysis.sepa-

nalyseslectedme-own

urtherit>Site

. Into astem

rom

tPland asat isd asr/car-sig-

5.2.3.1 Multi-Carrier Definitions

Following are several definitions that are needed to describe the multi-carrier simulprocedure:

Traffic Carrier Map Set (TCMS):

The TCMS is a logical grouping of multiple traffic distribution maps in NetPlan. There istraffic distribution map per carrier in the TCMS.

TCMS Analysis:

The “TCMS Analysis” is the primary analysis used for generating the TCMS and configuringsystem. Every cell site, sector, and carrier in the system must be included in the TCMS anThe TCMS analysis is “carrier independent”. The analysis of each individual carrier is donerately with the “Carrier Dependent” analysis (which is defined next).

Carrier Dependent Analysis:

NetPlan requires a separate analysis for each carrier that is to be simulated. Each of these ais referred to as a “Carrier Dependent Analysis”. The proper carrier frequency must be sewithin each Carrier Dependent Analysis using the Configure>Simulation Paraters>CDMA>System menu selection and then choosing the carrier from the Carrier ID pull dmenu. Each Carrier Dependent Analysis must contain all of the cell sites in the system. As fdescribed in Section 7.2.2: “Sector/Carrier Parameters”, the sector/carrier section of the Edwindow is used to define the carriers that are deployed in a given sector.

Carrier Independent Traffic Map:

The starting point for generating a TCMS is a conventional Traffic Map for the overall systemthe context of multi-carrier simulation, this conventional, single-layer traffic map is referreda “Carrier Independent Traffic Map” since it defines the traffic distribution for the entire sysrather than the distribution for any individual carrier. NetPlan divides the traffic distribution fthis Carrier Independent Traffic Map to create the multi-layer Traffic Carrier Map Set.

Traffic, DAHHO, and MAHHO Sector/Carriers:

As further detailed in Section 7.2.2: “Sector/Carrier Parameters”, each sector/carrier in Nemust be specified as being Traffic, DAHHO, or MAHHO. If the sector/carrier is designateDAHHO, then a user definable scaling factor is employed to determine the portion of traffic thallocated to the DAHHO carrier versus the Traffic carrier. If the sector/carrier is designateMAHHO, modeling a pilot beacon scenario, zero traffic is assigned to the pilot beacon sectorier. A “Traffic” sector/carrier is a conventional traffic bearing sector/carrier that is neither denated as a MAHHO or a DAHHO sector/carrier and does not perform hard handoffs.


5


d the. Net-

nsity

oaded

hich

byf 1,t

rier

the

dis-

tionT).

ey are

5.2.3.2 TCMS Traffic Distribution Algorithm

In order to better understand the multi-carrier simulation process, it is helpful to understanalgorithm that NetPlan uses to distribute the traffic density across the carriers within a sectorPlan distributes the traffic density across sector/carriers using the following approach:

1. A Carrier Independent Traffic Map is established using the procedures described inSection 5.1 - Section 5.2.1.8. The Carrier Independent Traffic Map defines the traffic deon a bin-by-bin basis for the entire simulation space.

2. The coverage area for each sector/carrier in the system is determined from either the UnlEc/Io Server image or from the Best Gain Server image.

3. An intermediate “Carrier Type” mesh is generated internal to NetPlan for each carrier, wcontains the bin-by-bin designation of Traffic Carrier (T), DAHHO (D), or MAHHO (M).

4. An intermediate “Scale Factor” mesh (internal to NetPlan) is generated for each carriercombining the traffic weights for each of the carrier types. A Traffic Carrier has a weight oa DAHHO Carrier has a user defined weight, and a MAHHO Carrier has a weight of 0. Aeach bin in the simulation space, the Scale Factor mesh contains the sum of all the CarType weights from each of the Carrier Type images.

5. The traffic density for each bin in each of the per-carrier traffic maps is calculated usingfollowing formula. Figure 5-26: "TCMS Algorithm" illustrates the use of this formula for acase where the traffic density from the original Carrier Independent Traffic Map is beingtributed over three carriers.

where,

is traffic density for bin coordinatex,y in the traffic map for carrierc.

is the weight obtained for bin coordinatex,y from the Carrier Type mesh for carrierc.

is the traffic map density value for the bin coordinatex,yof the Original Traffic Map,which is the carrier independent traffic map.

is the scale factor for bin coordinatex,y from the Scale Factor Mesh.

This formula, in essence, evenly distributes the original traffic density (OTM) at a loca(bin x,y) across carriers at the bin location and thereby creates a carrier traffic density (

Note: the Scale Factor mesh and the Carrier Type mesh are not provided as final outputs. Thonly used for the computation of the per-carrier traffic maps.

Tcx y,

Wcx y,OTMx y,⋅( )

SFMx y,-----------------------------------------=

Tcx y,

Wcx y,

OTMx y,

SFMx y,


5


r

Figure 5-26: TCMS Algorithm

CarrierX_Best Ec/Io Server/Sector CarrierY_Best Ec/Io Server/Sector CarrierZ_Best Ec/Io Server/Secto

T T M

D T T

MD

D M

TT

T

T

TM

M T T

DDT

T T

2 2

2.1 2.1

1.1

2.1

1.1 20

Original Carrier Independent Traffic Map

OTM1 1,1.1

--------------------OTM1 2,

2-------------------- 0

0.1OTM2 1,2.1

----------------------------OTM2 2,

2.1--------------------

OTM2 3,2.1

--------------------

0 00.1OTM3 2,

1.1----------------------------

0.1OTM1 1,1.1

----------------------------

0.1OTM2 2,2.1

----------------------------0.1OTM2 3,

2.1----------------------------

0 0OTM1 3,

2--------------------

OTM2 1,2.1

--------------------OTM2 2,

2.1--------------------

OTM2 3,2.1

--------------------

OTM1 1, OTM1 2, OTM1 3,

OTM2 1,

OTM3 1, OTM3 2, OTM3 3,

OTM2 2, OTM2 3,Scale Factor

0 0OTM3 3,

2--------------------

OTM1 2,2

--------------------OTM1 3,

2--------------------

OTM2 1,2.1

--------------------

0OTM3 2,

1.1--------------------

OTM3 3,2

--------------------

CarrierX_Traffic Map CarrierY_Traffic Map CarrierZ_Traffic Map

MM M

Carrier TypeMesh

Mesh

Traffic Carrier Map Set


5


andocessss for

alysisbeen

rierTCMSsis as

point.initial

5.2.3.3 Creating the Traffic Carrier Map Set

After identifying the sites requiring multiple carriers, defining the hard handoff sectors,creating the hard handoff boundary polygons, the next step in the multi-carrier simulation pris to generate the TCMS. Figure 5-27: "TCMS Creation Process" depicts the high level procecreating the TCMS.

Figure 5-27: TCMS Creation Process

5.2.3.3.1 Create TCMS Analysis

To start the TCMS creation process, a TCMS analysis must be established. The TCMS anwill contain all of the sites in the system. The carriers in each sector must have previouslydefined as DAHHO, MAHHO, or Traffic, as described in Section 7.2.2: “Sector/CarParameters”. This analysis should be saved using a descriptive name to indicate that it is theanalysis. For example, if the analysis is for a system named Joliet, then save the analyjoliet_TCMS.

5.2.3.3.2 Create Carrier Independent Traffic Map

To generate the TCMS, a standard Carrier Independent Traffic Map is required as a startingThe procedures described in Section 5.1 through Section 5.2.1.8 are used to create theCarrier Independent Traffic Map for the system.

Create TCMSAnalysis

Create Carrier-IndependentTraffic Map

Create HardHandoff

BoundaryPolygons

Copy TCMSAnalysis to Carrier-Dependent Analyses

Select theAppropriate Carrier

in Each Carrier-Dependent Analysis

Run TCMSGeneration Tool inthe TCMS Analysis


5


e hardf thes, ther Bestnd anon-non-

criber

5.2.3.3.3 Create Hard Handoff Boundary Polygons

The next step in generating the TCMS is to create the hard handoff boundary polygons. Thhandoff boundary polygons are used in TCMS generation to limit the geographical area odropped subscribers for a non-ubiquitous carrier. Without the hard handoff boundary polygondropped subscribers would occupy the entire area defined by the Unloaded Ec/Io Server oGain Server image for the non-ubiquitous carrier. This area will typically extend well beyonormal hard handoff boundary, where the subscriber would actually transition off of theubiquitous carrier (see Figure 5-28). A polygon defines the desired handoff boundary for theubiquitous carrier and is used during the generation of the TCMS to constrain the subsplacement for the non-ubiquitous carrier.

Figure 5-28: Un-constrained Ec/Io

Un-constrained sectorsextending out over cell siteswhich do not have this carrier.


5


ouldeen Cer thers allne this

phics

The creation of the constraining polygon should be done from within the TCMS analysis. It shbe created to outline the border where the designer intends hard handoffs to be made betwnand Cu. This process can be facilitated by changing the colors assigned to each sector in eith“Unloaded Ec/Io Server” or “Best Gain Server” images such that the additional carrier sectohave the same distinct color (see Figure 5-29). The polygon should then be created to outliborder between the carriers.

Figure 5-29: Constraining Polygon for Cn using MAHHO

Note: For instructions on the creation of polygons, see Chapter 5 “Grids and GraObjects” of the NetPlan User’s Manual.


5


aconsn, a

MS

The polygon shown in Figure 5-29 best represents the transition borders to use when pilot be(MAHHO) are deployed in surrounding cell sites. If DAHHO were implemented in the desigmore closely fitted polygon would be recommended as shown in Figure 5-30.

Figure 5-30: Constraining Polygon for Cn using DAHHO

The polygon should be saved with the analysis. It will be selected from within the TCgeneration tool menu when creating the TCMS.


5


or eachither anrage

r newfrom

amelyd thenusingvailablealysis

h is a

withinwouldted in

arrier

n thethenbox

5.2.3.3.4 Copy TCMS Analysis to Carrier Dependent Analyses

The TCMS generation process requires the sector and coverage boundaries to be defined fcarrier. Separate carrier dependent analyses are used by the TCMS tool to generate eUnloaded Ec/Io Server plot or a Best Gain Server plot to identify the sector and coveboundaries for each carrier.

A simple way to create the Carrier Dependent Analyses is to save the TCMS analysis undeanalysis names that correspond to the carrier names. Continuing with the exampleSection 5.2.3.3.1, if the system under study is named Joliet and there are two carriers, ncarrier_1 and carrier_2, then first save the joliet_independent analysis as joliet_carrier1 animmediately save this analysis as joliet_carrier2. The “Save As” operation is accomplishedthe File>Save As menu selection. For this example, there are now three separate analyses afor Joliet, corresponding to the main TCMS analysis and a separate Carrier Dependent Anfor each of the two carriers in the system. All analyses will contain the same cell sites, whicrequirement of the multi-carrier simulation procedure.

5.2.3.3.5 Select Appropriate Carrier In Each Carrier Dependent Analysis

Once a separate analysis is created for each carrier, the proper Carrier ID must be selectedeach of these TCMS analyses. In continuing the example, the Carrier ID named Carrier_1be selected in the joliet_carrier1 analysis and the Carrier ID named Carrier_2 would be selecthe joliet_carrier2 analysis. Use the Configure>Simulation Parameters>CDMA>System>CID menu sequence to select the Carrier ID within each analysis.

5.2.3.3.6 Run TCMS Generation Tool

The final step in the TCMS generation process is to run the TCMS generation tool from withiTCMS analysis. The TCMS dialog box is accessed by selecting the Traffic Tool icon andusing the Edit>Traffic Carrier Map Set menu selection. Figure 5-31 depicts the TCMS dialogand the associated procedures for generating the TCMS.


5


d

r

ts

Se

ssn-fe

heier

ese

d

r

e

l-

Figure 5-31: Traffic Carrier Map Set Dialog Box

Used for displaying TCMS images, not useduring TCMS generation.

Click on the ellipsis button to select the CarrieIndependent Traffic Map.

Select either “Unloaded Ec/Io Server” or “BesGain Server”. Unloaded Ec/Io Server irecommended.

Check the carriers to be included in the TCMand click on the ellipsis buttons to select thCarrier Dependent Analysis for each carrier.

Each carrier in the TCMS must be identified aeither “Ubiquitous”, meaning that the carrier iequipped in every sector of the system, or “NoUbiquitous”, meaning that only a subset osectors within the system are equipped with thcarrier. Select each carrier and choose tappropriate radial button to designate the carras Ubiquitous or Non-Ubiquitous.

If the carrier is Non-Ubiquitous, then select thappropriate hard handoff boundary polygon(see Section 5.2.3.3.3 on polygons) from thwindow and click the “Include” button to applythe polygon to the TCMS for the selectecarrier. The caption in the window will changefrom “Not Used” to “Included”.

Enter the DAHHO weighting factor. A startingvalue of 0.1 is recommended, if no otheinformation is available.1

Click on “Generate” to create the TCMS. A“Generate TCMS As” window will appear.Select a descriptive name to be given to thTCMS.

1. Refer to the “Multiple Carrier RF Subsystem Support” Cellular Application Note for more information onthe parameters that will impact the DAHHO weighting factor. The recommendation of 0.1 is based on colected traffic statistics for commercial DAHHO sectors.


5


thatof the

bes

5.2.3.4 Displaying and Validating the TCMS

Once the TCMS is created, it is important to view each carrier (layer) of the TCMS to ensureit matches the design expectation. Viewing the TCMS layers requires the simultaneous use“Traffic Engineering” and “Traffic Carrier Map Set” dialog boxes. Figure 5-32 below descrithe procedure for displaying a previously generated TCMS.

From within the mainNetPlan window, click onthe Traffic Engineeringicon to open the TrafficEngineering dialog box.

Use the Edit>Traffic Carrier Map Setmenu selection to open the TrafficCarrier Map Set dialog box.

Click on the Display Image box andselect TCMS from the image selectionmenu.

Within the Traffic Carrier Map Setdialog box, use the File>Open menuselection to open the previously createdTraffic Carrier Map Set.

Under “Display TCMS Layer”, selectthe desired Carrier ID to display.

Within the Traffic Engineering dialogbox, click on “Apply” to view thetraffic map image for the selectedCarrier ID.

Changing the Carrier ID selection inthe Traffic Carrier Map Set dialog boxwill automatically update the trafficimage to the newly selected Carrier ID.

Figure 5-32: TCMS Layer Viewing Procedure


5


ay as athetionn on

the

thecrosssing aed andMeanin eachsses”

n theof the

screen-33In thisystemrlang

thethe

5.2.3.5 Using the TCMS in Analyses

Once the TCMS is created, it is used within each carrier dependent analysis in the same wconventional carrier independent traffic map. The TCMS is selected usingConfigure>Simulation Parameters>CDMA>Subscribers>Traffic Distribution menu selec(refer to Section 6.2.2.4.2: “Assigning Traffic to the Subscriber Classes” for more informatioselecting the TCMS). NetPlan automatically chooses the appropriate traffic map layer fromTCMS, in accordance with the Carrier ID that is selected for the analysis.

One additional step in multi-carrier simulation is to distribute the Erlang load betweenindividual carrier dependent analyses. The TCMS specifies how traffic is distributed acarriers and geographically across the system. However, since each carrier is simulated useparate and independent analysis, the actual Erlang load per carrier must be determinentered into the analysis. The Configure>Similation Parameters>CDMA>Subscribers>Number of Erlangs menu selection is used to enter the average Erlang load to be simulatedcarrier dependent analysis (refer to Section 6.2.2.4.2: “Assigning Traffic to the Subscriber Clafor more detail on entering the Erlang load).

NetPlan provides a mechanism for determining the distribution of the Erlang load betweecarrier dependent simulations. At the end of the TCMS generation process, the percentagetotal system Erlang load to be entered into each carrier dependent analysis is printed to thein the AIM build.report window and is also printed to a text file for future reference. Figure 5depicts the AIM window message that appears at the end of the TCMS generation process.case, there were only a few cell sites that had Carrier_2. Therefore, only 8.2% of the total sErlang load would be allocated to the analysis for Carrier_2, while 91.8% of the total system Eload would be applied to the analysis of the ubiquitous carrier, Carrier_1. As seen inbuild.report, a file named joliet_tcms.pcnt was automatically generated and saved inappropriate analysis directory for future reference.


5


rs iswhile

y toted torationn thewhen

Figure 5-33: AIM build.report Window

Continuing with the Joliet example, if the total Erlang load for the entire system and all carrie200 Erlangs, then 16.4 Erlangs (200 x 8.2%) would be entered in the Carrier_2 analysis,183.6 Erlangs (200 x 91.8%) would be entered in the Carrier_1 analysis.

5.2.3.6 Modifying the TCMS

The TCMS is a single logical entity comprised of multiple traffic map layers. There is no wamodify a TCMS. If a change is required, the entire TCMS generation process must be repeacreate a new TCMS. However, the parameters that were used in the original TCMS geneprocess are saved and can be seen from the “Traffic Carrier Map Set” dialog box wheappropriate TCMS is opened. This allows the user to change one or all of the parametersgenerating a new TCMS.


5


ed withtheeed atmeters

.2.4.1).

givenn with

sociatedystema Roade with

w to

d Map.r more

5.3 Speed Map

Although the simulator reflects a static environment, each subscriber has a speed associatit. As an analogy, imagine flying over a city, looking down and snapping a picture. Inphotograph, the subscriber units are static. However, for each subscriber unit there is a spwhich it was traveling at the time the photo was taken. Subscriber speeds are one of the paraused by the simulator in determining target Eb/No requirements to meet a desired FER.

The speed distribution method can be set within the Subscriber Class Editor (see Section 6.2The choices for speed distribution are:

• Constant

• Normal (Gaussian)

• Exponential

• Speed List

• Speed Map

Of these choices, the Speed Map gives the greatest control on placing subscribers with aspeed in a given area. For example, should the system designer choose a Normal distributioa mean and standard deviation for the speed, then a subscriber being dropped could have aswith it any speed within these parameters. However, if a Speed Map is created and the sdesigner sets Road Class 1 (highways) to 88 kph (55 mph), then any subscriber dropped onClass 1 (highway) will be assigned a speed of 88 kph, plus or minus some value in accordanca Normal distribution and user defined standard deviation.

Some reasons to use a Speed Map include:

• Simulation of rush hour vs. non-rush hour traffic

• Setting subscriber speed closer to real-world road speeds

• Setting subscriber speed for walking traffic

The Speed Map is created using the Traffic Engineering Tool. The following figures show hocreate and display the Speed Map.

NetPlan provides the ability to view the speed assignments used to create an existing SpeeA new Speed Map may be created from an existing set of speed weightings by altering one ospeed weighting, and saving the resultant Speed Map under a new name.


5


Figure 5-34: Create Speed Map

With the pull down menu of the TrafficEngineering Tool, select Speed Map.

The Speed Map menu requires the systemengineer to Add clutter or road types and assignspeeds (in kilometers per hour) to each.

Press Apply then File>Save As from the SpeedMap window and save the Speed Map.

Clicking on a clutter type willbring it down to the edit boxwhere a speed value can then beset.


5


s

Figure 5-35: Display Image - Speed Map

For further details on using a Speed Map in simulations, please refer to Section 6.3

To display the Speed Map image,select the image required, then select“Speed Map” from the Display Image

Press Apply and the Speed Map will bedisplayed. Note: Arcs and Numericdo not have Speed Map as an option.

The Speed Map shown below had speedsset separately for Road Class 1, RoadClass 2, Road Class 3, and Rest-of-Area.

Example Display of Speed Map Image

The Query tool may also be used to verify

button.

the speed at each clutter or road type.See Section 13, Figure 13-17 for directionto launch the Query tool.


5


_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


Setting Simulator InputParameters - System Level

Chapter

6
Table of Contents
6 - 3

- 3 - 36 - 5 - 6

6 - 8 - 9 - 12 - 17- 17 - 23 - 25

- 25- 38 - 41 - 44

6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 Setting the Simulation Input Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 6.2.1 Defining Carrier Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.2.2 Defining the CDMA Parameters . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.2.1 CDMA Parameters - Simulation Model Tab . . . . . . . . . . . . . . . . . 66.2.2.2 CDMA Parameters - Radio Access Network Tab . . . . . . . . . . . . .

6.2.2.2.1 Configuration Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66.2.2.2.2 Supplemental Channels Tab . . . . . . . . . . . . . . . . . . . . . 6

6.2.2.3 CDMA Parameters - Data Services Tab . . . . . . . . . . . . . . . . . . . . 66.2.2.3.1 Call Models Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.2.2.3.2 TCP Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

6.2.2.4 CDMA Parameters - Subscribers Tab . . . . . . . . . . . . . . . . . . . . . . 66.2.2.4.1 Defining Subscriber Classes . . . . . . . . . . . . . . . . . . . . . 66.2.2.4.2 Assigning Traffic to the Subscriber Classes . . . . . . . . . 6

6.2.2.5 CDMA Parameters - RF Environment Tab . . . . . . . . . . . . . . . . . . 66.2.2.6 CDMA Parameters - Images Tab . . . . . . . . . . . . . . . . . . . . . . . . . . 6


6

Chapter 6: Setting Simulator Input Parameters - System Level

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


6


inputthat are

ionalttingsy theationalso

00).

put

stics offinedthese

carrier

singleationciated

rs thathereurce ofeters

n fromontainningSite”.)

6.1 Overview

The accuracy and usefulness of a simulation depends on setting the proper simulatorparameters in NetPlan. This chapter discusses the carrier information and system variablesset within the NetPlan graphical user interface (GUI).

Example figures are given of all the input fields, accompanied by notes which may offer additinformation on the input fields (including recommended values where appropriate). The seshown in the figures are for a 13 kbps, 1.9 GHz CDMA system. The notes which accompaninput fields also give values that correspond to other system configurations (i.e. any combinof 8 kbps/13 kbps vocoder or 800 MHz/1.9 GHz frequency) when necessary. The notesinclude information regarding parameter settings for data configurations (IS-95B and IS-20

The following sections show how to define the carrier information and the simulation inparameters.

6.2 Setting the Simulation Input Parameters

Within NetPlan, the graphical user interface has many parameters that define the characteria system for simulations. The carrier information and the CDMA parameters must be debefore simulations can be run on a system. The following sections describe how to setparameters.

6.2.1 Defining Carrier Information

NetPlan requires the carrier database that will be used during simulations to be defined. Thisdatabase is defined through the Carrier Table.

The information in the Carrier Table must be defined regardless of whether the system is acarrier or a multi-carrier system. The Carrier Table provides global carrier database informthat is accessible from any analysis in NetPlan. It contains a list of all carriers and their assofrequencies.

Each unique analysis uses the information from the Carrier Table to assign the specific carriewill be used in the simulations for that analysis. There are three windows within NetPlan wcarriers to be used during simulations are assigned. The Carrier Table is used as the socarrier information in these three windows: the Site Data Entry window, the CDMA Paramwindow, and the Traffic Carrier Map Set (TCMS) window.

The Site Data Entry window assigns the carrier(s) for each sector. These carriers are chosethose listed in the Carrier Table. In the case of a multi-carrier system, the site database will cmultiple carriers in the sector/carrier information. (Further information regarding assigcarriers in the site database can be found in Chapter 7, “Setting Simulator Input Parameters -


6


odellysisn the

ow.hentraffic

affic

The Carrier Table information is also accessed through the CDMA Parameters-Simulation Mwindow. The carrier that is defined in this window is used to determine which carrier the anawill represent. A later section of this chapter will explain how the Carrier Table is accessed iCDMA Parameters window.

The final GUI window that accesses the information from the Carrier Table is the TCMS windIn a multi-carrier system, a Traffic Carrier Map Set is used to define the traffic distribution. Wa TCMS is generated, the carrier database is accessed to define the carriers over which thewill be distributed. (Further details regarding the use of the Carrier Table in generating TrCarrier Map Sets can be found in Chapter 5, “Traffic (Distribution) and Speed Maps”.)

To access the Carrier Table, choose Edit>Carrier Table from the NetPlan main window.

Figure 6-1: Carrier Table Editor

2

1


6


alysiscy or

eld

er.Thenter

o the

tion

ferentrs, RFended

these

NOTES:

The Carrier Table provides global carrier database information that is accessible from any anwithin NetPlan. Therefore, changing an entry within this table (such as changing a frequendeleting an entry) will affect all analyses that are using the carrier that was modified.

Note: 1. Carrier ID - The Carrier ID is a name given to the carrier. It is an alphanumeric fiwith a maximum of 20 characters.

Note: 2. Frequency (MHz) - This field represents the center frequency of the CDMA carriThis frequency is used by the simulator when determining Eb/No values.acceptable range for this field is 650-4000 MHz, though the appropriate cefrequency should be chosen from the frequency band of the CDMA system.

(For information regarding how to add, modify, or delete a carrier in this table, please refer t“NetPlan CDMA Static System Simulation User’s Manual”.)

6.2.2 Defining the CDMA Parameters

CDMA parameters are accessed from NetPlan’s main window (Configure>SimulaParameters>CDMA ...) as shown in Figure 6-2.

Figure 6-2: CDMA Parameters

The CDMA parameters are displayed in tabbed format with each tab representing a difcategory of parameters: simulation model, radio access network, data services, subscribeenvironment, and images. Each of these categories will be described here along with recommor typical values for the parameters associated with each category.

NetPlan screen captures of the input dialog windows will be used along with notes regardingdialog windows to present the parameter material.


6


ludesill beime-igure

is.

6.2.2.1 CDMA Parameters - Simulation Model Tab

The simulation model tab contains parameters that define the simulation model. This tab incsimulation information such as the number of simulation drops, the number of images that wproduced, the carrier ID, the type of data simulation that will be used (time-sliced or non tsliced), the simulation length, the cell exclusion radius, and the random seed. The following fshows the CDMA Parameters - Simulation Model screen.

Figure 6-3: CDMA Parameters - Simulation Model

NOTES:

Note: 1. Number of Simulation Drops - All NetPlan simulation runs are Monte Carlo runs. Thvalue determines the number of “drops” which are made during the simulation run

Typical values to use for non time-sliced simulations are:Value Reason20 Early optimization steps100 Statistics200 Coverage Warranty

1

2

3

4

5

6

7


6


(duendedarlyicallices

or allts tohin aof data

sheme ofion ofers -g the

hisIDthe

l beions

that

ns.lected

edthe

gned

atas wellin thequiree a

When running time-sliced simulations, a smaller number of drops is recommendedto the time and disk space requirements of time-sliced simulations). It is recommethat 10 drops be used for time-sliced simulations (with 1-3 drops used for eoptimization steps). Although there are only 10 drops (10 distinct geographdistributions of the subscribers), each of these drops is further subdivided by time-sas a means to better model the call states.

Note that the above values are reasonable when the results will be analyzed fsubscriber types within the system. However, if the RF system designer wananalyze one particular subscriber class at a time (out of all subscriber types witsystem), then these numbers may need to be increased to get a sufficient numberpoints per sector for that one subscriber type for the results to be meaningful.

Note: 2. Restrict Images to First - Selecting this button will restrict the number of imageproduced to that of the firstN-drops specified in the accompanying field. Restricting tcreation of images to the first specified number of drops speeds the processing tithe simulator and reduces disk space. Checking this box does not affect the creatmobile and cell statistics files. (Please refer to Section 6.2.2.6, "CDMA ParametImages Tab", Note 1 regarding the number of drops to use for images when settinimage probe delay spread to vary across the drops.)

Note: 3. Carrier ID - Select the appropriate carrier ID for the analysis from the given list. Tlist is based on the information from the Carrier Table. The chosen carrierdetermines which carrier the given analysis will represent. This, in turn, definesTCMS layer (if a TCMS is used) and the site/sector/antenna information that wilused in simulation runs. For example, if “Carrier A” is selected, then the simulatwill use the “Carrier A” layer of the TCMS (if TCMS is selected in the CDMASubscriber Parameters). Also, the simulations will be run only for the sites/sectorshave “Carrier A” selected in their sector/carrier information.

Note: 4. Data Simulation: Non Time-Sliced or Time-Sliced- There are two types of IS-2000simulations within NetPlan, time-sliced simulations or non time-sliced simulatio(This parameter is only accessible when the IS-2000 technology has been sethrough the Configure>Context window.)

Non Time-Sliced: If the non time-sliced simulation option is selected, all droppsubscribers are considered to be actively transmitting (bursting) data on bothforward and reverse links at the time of the simulation, with data rates being assimaximally according to available capacity.

Time-Sliced: If the time-sliced simulation option is selected, the dropped IS-2000 dsubscribers are stepped through multiple call model states. State transition times aas file sizes and quantities associated with the different states are specified withcall model parameters for the subscriber classes. The time-sliced simulations resignificantly more time to run than non time-sliced simulations since they provid


6


odel

ionlicedhow

. It isontheir

e thet are, theup”

riodr the

of

eter,the

rther

ceribersoulda safe

Theed inangedrun

f theental

ab.

more detailed model of the data calls. (For more information regarding call mparameters or states, please see Section 6.2.2.3.1, "Call Models Tab".)

Note: 5. Simulation Length - This parameter corresponds to how long a time-sliced simulatis to be run per Monte Carlo drop. (This parameter is only accessible if the time-sdata simulation model is selected.) However, the length of time is dependent uponlong it takes the subscribers to reach a steady state condition for their call modelsrecommended that an initial simulation be run with a fairly long simulation length,the order of 500 seconds, so that the time required for the subscribers to reachsteady state condition (referred to as a “warm-up” time) can be estimated. Sincsubscribers have not yet stabilized during this “warm-up” period, the statistics thagathered during this period are not valid and must be discarded. Thereforesimulation length has to be long enough to provide valid data after the “warm-period.

It is recommended that the final simulation length be equal to the “warm-up” peplus 200 seconds. However, a minimum of 300 seconds is recommended fosimulation length.

For further information regarding estimation of the “warm-up” time and calculationsimulation length, please see Sections 9.5.2 and 9.5.3.

The simulation length parameter, in conjunction with the time-slice interval paramdetermines the number of time slices in the simulation run, which also affectssimulation run time. (See Section 6.2.2.2.2, "Supplemental Channels Tab", for fuinformation regarding the time-slice interval.)

Note: 6. Cell Exclusion Radius- The Cell Exclusion Radius field defines the minimum distana subscriber may be placed from a cell site. This feature is meant to keep subscfrom being placed too close to a cell site such that their lowest transmitted power woverpower the cell site receiver. A value of 30 meters has been determined to bedistance for simulation purposes.

Note: 7. Random Seed- The Random Seed field may be populated by any integer number.“seed” is used in the simulation to start the random number generator which is ussuch algorithms as assigning dropped subscriber placements. If the seed is not chfrom run to run, the subscribers will be dropped in the same locations every(assuming no other parameters are changed).

6.2.2.2 CDMA Parameters - Radio Access Network Tab

The Radio Access Network (RAN) tab contains parameters that relate to the RAN portion osystem. These parameters are divided into two categories, configuration and supplemchannels. These two categories have an associated tab within the Radio Access Network t


6


et, thee and

esed insents

thsites

tennaa.)

00, is000.

6.2.2.2.1 Configuration Tab

The parameters in the Configuration tab contain information such as the base station chipshandoff list, N-way soft handoff parameters, and packet data parameters. The following figurnotes describe these parameters further.

Figure 6-4: CDMA Parameters - Radio Access Network - Configuration Tab

NOTES:

Note: 1. IS-95 Base Chipset- This field defines the IS-95 BTS hardware chipset. This field donot apply to IS-2000 hardware. Select the option which represents the chipset usthe base sites of the CDMA system [Phase 1 BSM, Phase 2 CSM (which also reprethe Motorola MAXX chipset), and EMAXX (Motorola)]. If the system has sites widifferent chipsets, select the chipset which is most predominant in the system. Thewhich don’t have this chipset can be set to the correct chipset by using the per anchipset field. (Refer to Chapter 7 for more details on setting the chipset per antenn

Note that the CSM5000 chipset, which is used in base stations that support IS-20not an option for this field. This is because NetPlan does not use this field for IS-2

1

2

34

5


6


ards000willlease

theforTSs

CSM2000ipset

of auldsteminimalailed

wpacketigherng thevalueThe

e is. It is

, this

cket

rs inre ints ofwidein the

However, the BTS products that support the IS-2000 air interface utilize MCC cwith either the EMAXX or CSM5000 chipset. The CSM5000 chipset supports IS-2users, while the EMAXX chipset supports IS-95 users. (The CSM5000 chipsetsupport both the IS-95 and IS-2000 air interfaces in a point release of CBSC reR16.0.) Therefore, for a system that has mainly BTS equipment that supportsIS-2000 air interface, it is recommended that this field be set to EMAXX to allowthe possibility that a mixture of IS-95 and IS-2000 users will be served by the Bwithin the system.

Note that the Phase 2 CSM and the CSM5000 are different chipsets. The Phase 2supports only the IS-95 air interface, whereas, the CSM5000 supports only the IS-air interface in CBSC release R16.0. (With CBSC release R16.1, the CSM5000 chwill support both the IS-95 and IS-2000 air interfaces.)

Note: 2. Apply Handoff List - This button should only be selected in one of the last phasesCDMA simulation study. Once the button is selected, the “Handoff List” ellipsis shobe clicked and a previously generated handoff list file selected. Only after the syhas been optimized should a handoff list be generated. This approach results in mimpact to the handoff list and system performance. See Chapter 14 for detinformation concerning handoff list generation.

Note: 3. IS-95B Packet Ec/Io Offset - This parameter provides the ability to set hoaggressively the supplemental channels are assigned in an IS-95B high speeddata (HSPD) system. (This parameter only applies to IS-95B systems.) Values hthan zero are used to more aggressively assign supplemental channels, improviaverage data rate. A possible negative implication of using an aggressive offsetwould be the deterioration of service provided to the users on the system.simulation results should be checked to verify that the system performancsatisfactory. Presently, a typical offset value of 70 is an acceptable value to usecurrently not recommended to adjust the offset value above 100.

Within NetPlan, this parameter is set on a system-wide basis. In an actual systemoffset parameter is set on a per CBSC basis.

(Please refer to Appendix A4 for further information concerning High Speed PaData simulations.)

Note: 4. N-Way Soft Handoff - This section of the CDMA input parameters allows fomodeling of the N-Way Soft Handoff feature. This feature supports up to six pilotthe active set and provides additional parameters to tailor the handoffs. This featuNetPlan includes modeling of the increased forward link interference and the effecpilot usage limitations. (Note that the following parameters are set on a systembasis within NetPlan. However, in an actual system, these parameters are set withCBSC, allowing different settings to be specified on a carrier-sector basis.)


6


ofth anotSHO

.2.2,

ethe, thenneltheter to

berng aature-Way

annellinkstheter to

imumoder

gspecifyo orare:

The mobile statistics file that results from simulating a system using N-Way SHandoff contains information regarding the state of each pilot [i.e. active witdemodulated TCH (server has a link to the subscriber), traffic channel butdemodulated (server does not have a link to the subscriber), blocked due tolimitations, remaining pilot below T-DROP].

Further information on SHO parameters can be found in Chapter 7 (Section 7“Carrier Parameters”).

Max Active Set Pilots- This field defines the maximum number of pilots allowed in thactive set. Up to six are allowed with the N-Way Complex Handoff feature. Onlytop three pilots are used for subscriber fingers. If there are more than threeadditional traffic channels may add to the forward link interference and the chaelement usage. In the implementation of the N-Way Soft Handoff feature ininfrastructure, if adding a candidate cell to the active set would cause this paramebe exceeded, a Soft Shuffle may be performed.

Prior to the implementation of the N-Way Soft Handoff feature, the maximum numof pilots allowed in the active set was three. Therefore, in NetPlan, when modelisystem that does not have the N-Way Soft Handoff feature or does not have this feenabled, this parameter should be set to 3. When modeling a system that enables NSoft Handoff, the recommended setting for this parameter is 6.

Max BTS per Call - This field specifies the maximum number of BTS allowed forcall. This parameter can be thought of as limiting the maximum number of chaelements (CE) per call. Only one CE is used at each BTS no matter how manythere are to that BTS. In the implementation of the N-Way Soft Handoff feature ininfrastructure, if adding a candidate cell to the active set would cause this paramebe exceeded and BTS Shuffle is enabled, a BTS Shuffle may be performed.

The recommended setting for this parameter is 3. This corresponds to the maxconstraint of three CEs per call (based on the hardware limitation of the transccard).

Max Legs per BTS- This field defines the maximum number of active sector le(links) from a subscriber to a BTS. There are three parameters that can be set to sthe maximum number of legs per BTS depending on the number of BTS (one, twthree) in the Active set. These three parameters and their recommended settings

Parameter Name Recommended Setting1 BTS in Active Set 32 BTS in Active Set 23 BTS in Active Set 2


6


ingmay

00ed toannel

iberthethe

other

entalds

at an

olts and

sures.r ofter inttinging ofsionsetails

t theeverse-2000

In the implementation of the N-Way Soft Handoff feature in the infrastructure, if adda sector leg (link) would cause this parameter to exceed the limit, a Softer Shufflebe performed to keep the best (strongest) active legs per BTS.

Further information regarding the N-Way Soft Handoff feature can be found in the“N-Way Complex Handoff Cellular Application Note”.

Note: 5. Packet Data- This section of the CDMA input parameters is only used when IS-20time-sliced simulations are run. It contains some of the parameters that are usconfigure the time-sliced packet data such as the dormancy timer, the control chmode, and the Radio Link Protocol (RLP) throughput parameters.

Dormancy Timer- This field defines the amount of time that an IS-2000 data subscrcan be inactive in the think state before being placed by the infrastructure intodormant state. Values will typically vary from 20 to 60 seconds and will depend oncustomer requirement. (Further information regarding the call model states andcall model parameters can be found in Section 6.2.2.3.1, "Call Models Tab".)

Control Channel Mode (FCH/Non-DTX or DCCH/DTX)- This field determines thecontrol channel mode which determines the amount of power that the fundamchannel will require when idling (not bursting). The DCCH/DTX mode only senpower control bits, while the FCH/Non-DTX mode keeps the fundamental channeleighth-rate power (and also sends power control bits).

Typically, a setting of FCH/Non-DTX will be used for this field. However, the contrchannel mode selection is determined based on what the subscriber unit supporwhat the operator chooses to set as the preferred method in the CBSC database.

RLP Throughput Degradation (One Retransmission or Two Retransmissions)- Thisfield defines the reduction factor used to model retransmissions due to frame eraThis throughput degradation factor is applied on every frame. The numberetransmissions which are sent after the first erasure is a configurable parameIS-2000. A setting of two retransmissions is recommended for this field. This sesignifies that every time an erasure occurs, two retransmissions are sent. A settone retransmission correlates to a Type 1 RLP scheme and two retransmiscorrelates to a Type 2 RLP scheme. (See appendix A4, Section A4.3.2 for more dregarding RLP schemes.)

6.2.2.2.2 Supplemental Channels Tab

The parameters within the Radio Access Network>Supplemental Channels tab affecmanagement of IS-2000 supplemental channel assignments. They define the forward link, rlink and forward SCH gain parameters that are used by the simulator when assigning IS


6


elected

ntalby thendomectorlingnts, theacity

on theriber,it the

supplemental channels. This tab is only accessible if the IS-2000 technology has been sthrough the Configure>Context window.

Figure 6-5: CDMA Parameters - Radio Access Network - Supplemental Channels Tab

NOTES:

Note: 1. Forward Link - The fields in this section are used to determine how supplemechannels are assigned for the forward link. Supplemental channels are scheduledBTS for each time-slice interval. The supplemental channels are assigned in a raorder to subscribers whose queued forward link data, buffered at the SelDistribution Unit (SDU), exceeds a minimum size requirement (the scheduthreshold). The supplemental rate is assigned based on channel power requiremenumber of bytes to be transferred, Walsh code availability, and available capmargin (Ior/Ec).

The allocation of supplemental channel resources depends first upon need (basedscheduling threshold), and then upon resource availability. For each eligible subscthe system first determines the data rate that would be necessary to transmsubscriber’s queued data (at the SDU) over the next time-slice interval.

1 2

3


6


e. This

ectortree,lablewithFCH/f theis

ndoffannel

his isd with

atednnel

lower

al Iors for

haveIf thes that

next

slice

ental

aretions is

The system then needs to assess whether it can support this estimated data ratassessment is based on the following criteria:

- Walsh code availabilityThe maximum data rate based on Walsh code availability is determined for each sin the mobile’s reduced active set (RAS) of pilots. A Walsh code assignmentmanaged for every sector utilized in the simulation, is referenced. A maximum avaidata rate for this sector is determined. This determination ensures orthogonalityother Walsh codes that have already been assigned from that sector to supportDCCH data, overhead, and voice links, as well as other supplemental channels. Osoft handoff legs available from RAS, the limiting or lowest maximum data rateconsidered. Also, if supplemental channels cannot be assigned to all of the soft halegs, then none are assigned and the subscriber will utilize fundamental chresources (if available) to transfer bearer traffic.

- Traffic channel gainThe required supplemental channel gain with respect to the pilot is determined. Tbased on the current FCH/DCCH fundamental gain, the processing gain associatethe data rate under consideration, and an estimate of the SCH gain. This estimsupplemental traffic channel gain is then compared to the maximum allowed chagain for the rate under consideration. If the power exceeds the maximum, the nextrate is considered.

- Ior/Ec assessmentThe supplemental traffic channel gain is added to the current estimate for the totfor each sector of the RAS. This total Ior estimate considers the FCH/DCCH gainall subscribers, as well as the supplemental channel gains for subscribers thatalready been assigned supplemental channels for the forthcoming time-slice.current supplemental channel gain results in an Ior/Ec for any of the serving sectorexceeds its targeted capacity threshold (the Ior/Ec capacity threshold), then thelower rate is considered until an acceptable rate is found.

(Within the simulator, the SDU-BTS interaction is assumed as occurring at the timeboundary.)

The following parameters are used in the assignment of the forward supplemchannels.

Time-Slice Interval - This field determines how often supplemental channelsscheduled for the forward link. It is only accessible if the time-sliced data simulamodel has been selected in the Simulation Model tab. A value of 320 mrecommended for this parameter.


6


SC.

e-320s, the

kannelnnelthis

s to

been

edithm.ndofflot’s

ennelsyncs inat is

r this

ntalannelloadn the

-Slicefferulingwer

nt on

Note that the duration of the time slice is configurable and changeable per CBHowever, it is set as an analysis wide parameter within NetPlan.The simulation run time is proportional to the simulation length divided by the timslice interval. For example, in a simulation where the simulation length is set toseconds and the time-slice interval is set to the recommended 320 millisecondsupplemental channels are scheduled 1,000 times.

Scheduling Threshold- This parameter defines the minimum amount of forward lindata that must be queued for a particular subscriber in order for supplemental chassignment to be considered. A subscriber is eligible for a supplemental traffic chaassignment if the amount of forward link data buffered at the SDU exceedsminimum amount.

A value of 1000 bytes is recommended for the scheduling threshold. This helpensure that no high speed channels are assigned to WAP calls.

This parameter is only accessible if the time-sliced data simulation model hasselected.

Reduced Active Set Pilot Offset- This value sets the pilot offset threshold criteria usin the Reduced Active Set (RAS) supplemental channel assignment algorSupplemental traffic channels are eligible to be assigned to all soft and softer halinks whose pilot Ec/Io exceeds an Ec/Io value at this offset from the strongest piEc/Io. The current recommended value for this parameter is 6 dB.

Ior/Ec Capacity Threshold (limits data rate)- This parameter corresponds to thmaximum Ior/Ec ratio allowed in any individual sector during the supplemental chaassignment process. [Ior/Ec = (pilot channel power + paging channel power +channel power + sum of all TCH powers) / pilot channel power, where power iWatts.] This ratio is one of the factors that is used to determine the data rate thassigned to the supplemental channel. The current recommended value foparameter is 5.5.

Note: 2. Reverse Link - The fields in this section are used to determine how supplemechannels are assigned for the reverse link. The reverse link supplemental chassignment is similar to the forward link supplemental assignment. However, theestimator on the reverse link is based upon the estimated noise rise (rather thaestimated Ior/Ec used on the forward link).

Reverse link supplemental channel scheduling occurs at the Reverse TimeInterval. The subscriber will request a supplemental channel from the BTS if its bucontains more data than the number of bytes listed in the Reverse SchedThreshold. The subscriber will request the maximum data rate within its transmit poconstraints. (This is in contrast to the forward link where the data rate is depende


6


ratein itsminesg therate.

e sectorrise toe riseate isl the

aredatad for

e-320onds,

thel. Thisected.

ntheorsame

meter

e. The

rdes inpplydata

what is required to transmit the subscriber’s queued data. However, there is nomatching on the reverse link. The subscriber requests the maximum rate withpower constraints, regardless of the amount of queued data.) The BTS then deterif it can support this requested data rate. It makes this determination by assessinestimated noise rise of the cell, including the requesting subscriber at a given dataIt begins the assessment using the subscriber requested data rate. It estimates thnoise rise, including the subscriber at the requested data rate, and compares thisthe noise rise margin (Rise Capacity Threshold) of that sector. If the estimated noisfalls within the noise rise margin, a supplemental channel at the desired data rallocated. If it does not fall within the noise rise margin, the data rate is lowered untinoise rise margin is met.

Time-Slice Interval - This field determines how often supplemental channelsscheduled for the reverse link. This parameter is only accessible if the time-slicedsimulation model has been selected. A value of 640 milliseconds is recommendethis parameter.

The simulation run time is proportional to the simulation length divided by the timslice interval. For example, in a simulation where the simulation length is set toseconds and the reverse time-slice interval is set to the recommended 640 millisecthe supplemental channels are scheduled 500 times.

Scheduling Threshold- This value corresponds to the required amount of data insubscriber data buffer before the subscriber can request a supplemental channeparameter is only accessible if the time-sliced data simulation model has been selA value of 400 bytes is currently recommended for the scheduling threshold.

Reduced Active Set Pilot Offset- This parameter is similar to the RAS Pilot Offset othe forward link except that entire sites are excluded if any link does not meet“pilot” threshold (a value that is a function of RSSI and reverse pilot Ec/Io). Fexample, if one sector from a site meets the threshold but another sector from thesite does not, then this site will be excluded. The recommended value for this parais 6 dB.

Rise Capacity Threshold (limits data rate)- This parameter defines the reverse link risthreshold. This parameter limits the data rate assigned by the SCH schedulercurrent recommended value for this parameter is 4 dB.

Note: 3. Forward SCH Gain - This table defines the maximum and minimum forwasupplemental traffic channel gains for radio configurations RC3 and RC4. The valuthis table are linear multipliers relative to the pilot power. (These parameters only ato IS-2000 subscriber simulations.) The traffic channel gains are assigned for eachrate (19.2, 38.4, 76.8, and 153.6 kbps).


6


dataon the

with

ill beycledpendstes as

tions.(serverbelow:

The recommended settings for these parameters are found in the following table.

6.2.2.3 CDMA Parameters - Data Services Tab

The Data Services tab within the CDMA Parameters window contains detailed packetparameters. This tab is only accessible if the time-sliced simulation model has been selectedSimulation Model tab. The Data Services tab is broken down into two categories (corresponding tabs): Call Models and TCP.

6.2.2.3.1 Call Models Tab

The Call Models tab contains parameters that are used to define different call models that wused during simulations. Within a time-sliced simulation, the subscribers are continuously cthrough their individual call model states. The length of time spent in each call model state deupon the transition times, file sizes and file quantities associated with each of these stadetermined by associated distribution parameters within the Call Model tab.

The following diagram illustrates the call model states that are used in the time-sliced simulaThese states represent different bursting (forward or reverse request states) or non-burstingdelay, think, or dormant) states of the subscriber data call. Each of the states are described

Table 6-1: Recommended Forward SCH Gain Settings

Data Rate (kbps) RC3 RC4Minimum Maximum Minimum Maximum

19.2 0.12 1.5 0.12 1.538.4 0.16 2.0 0.16 2.076.8 0.18 3.0 0.18 3.0153.6 0.20 4.0 0.20 4.0


6


link.t takes

er isver tos), the

n ais statef bothls. Thes per

Figure 6-6: Call Model State Diagram

Reverse Request State- During this state, the subscriber sends a data request on the reverseThe length of time spent in the reverse request state is determined by the amount of time ito transmit the reverse request file.

Server Delay State- After the request has been made on the reverse link, the subscribtransitioned to the server delay state. During this state, the subscriber is waiting for the serrespond to its request. Once the server has responded (i.e. the server delay time expiresubscriber is transitioned to the next call state.

Forward Reference (Download) State- This state represents a subscriber that is bursting ofundamental channel or bursting on both fundamental and supplemental channels. Since thcan have a duration that spans multiple time slices, this state can represent a mixture obursting on the fundamental and bursting on both the fundamental and supplemental channelength of time spent in the forward reference state is dependent upon the number of filedownload, the file size, and the data rate(s) that the subscriber is assigned.

Dormant

ReverseRequest

ServerDelayState

ForwardReference

Think

Inactivity timerexpires beforethink time expires

Think time expires

Think Time - Inactive Time+ Dormant-to-Reverse

ReverseRequestpacket

State

ForwardReference

Serverresponded

State

State

State

packet(s)

Start Call,InitialInactiveTimer

Request Delay time expires

was sent was sent


6


els istivityr non-

ired

the

ivityr thee, armantmental

ationmeters

delayhe sizeequesttionedccess

catedofn-liker thanber

r to ae meanrafficnerate

the

, thea”, “b”,g the

hesee 6-8.)tch the

Think State - After the data transmission on the fundamental and supplemental channcomplete, the subscriber moves to the think state. At this point the think timer and inac(dormancy) timer are started. During this state, the fundamental channel can operate in eitheDTX mode (at 1/8th rate power plus power control bit power) or in DTX mode (just power requto transmit the power control bits).

If the subscriber think time is less than the inactivity timer (i.e. think time < dormancy timer),subscriber is transitioned directly to the reverse request state.

Dormant State- If a subscriber remains in the think state for longer than a user specified inacttime (i.e. think time > dormancy timer), the subscriber transitions to the dormant state foremainder of the think time state (think time - inactive time). During the dormant statfundamental channel is no longer assigned to the subscriber. When transitioning from the dostate to the reverse request state, an additional setup time is required to establish a fundachannel again (dormant-to-reverse request delay).

Within the Call Model window, a new call model(s) can be created or the parameter informcan be chosen from a given set of call model defaults. The call models are defined by parawhich include reverse request parameters (specifying the request size in bytes), serverparameters, forward reference parameters (defining the number of files per download and tof these files), think time parameters, and a parameter to define the dormant-to-reverse rdelay. The dormancy timer parameter is also part of the packet data call model. As menpreviously, the dormancy timer parameter is set within the Packet Data section of the Radio ANetwork>Configuration tab.

Several of these parameters (think time, files per download and file sizes) are defined by TrunPareto distribution parameters (a, b,θ, and T), since it has been determined that this typedistribution characterizes these data traffic variables well. A Pareto distribution has a Gaussiadistribution near the mean, but is characterized by a heavy tailed distribution for values largethe mean. In other words, this distribution allows for the probability that a small, but finite numof values will be considerably larger than the mean. A Truncated Pareto distribution is similaPareto distribution except that the tail has been truncated, so that values much larger than thare not included. The Truncated Pareto distribution is a good fit for several of the data tparameters since the variables are finite. For example, there are no applications which gefiles longer than a certain length (the truncation point).

The “a” and “T” parameters define the minimum and maximum truncation values fordistribution, respectively. The spread of the distribution is governed by the “b” and “θ” parameters.The “θ” parameter correlates to the slope of the Pareto distribution in its tail. Within NetPlanmean values associated with the Truncated Pareto variables are calculated based on the ““θ” and “T” settings. The “b” value can be tuned to converge on a desired mean. (Increasin“b” term will increase the mean.)

A set of default Pareto parameters for various call model types are provided with the tool. (Tdefault parameters are shown in the NetPlan screen captures within Figure 6-7 and FigurOne or more of these defaults may be selected, or other values may be entered to best macall model behavior of the different subscribers in their system.


6


endix

lowing

d theecific

ountlue ofried toerver

Further details regarding call model information and Pareto parameters can be found in AppA4.

Each of these call model parameters is described further in the notes associated with the foltwo figures.

Figure 6-7: CDMA Parameters - Data Services - Call Models Tab (left portion of screen)

NOTES:

The first two notes refer to parameters that apply to all call models (the server delay andormant-to-reverse request delay). All of the other parameters in the Call Models Tab are spto a particular call model.

Note: 1. Server Delay- This field defines the response delay from the server. This is the amof time taken by the server to respond to a data request from the subscriber. A va200 ms is recommended for this parameter. However, the operator should be quedetermine appropriate values based on the operator’s actual network sperformance.

2

7

8

1

3

4

5

6


6


edelaytering4 or 5

is. Theaulttion.DMA

iceeb

typesTTPtion isype.er’s

ltipleple ofr to

loadired

ngleervicengle

viceng of

orfilethat

owerare

Note: 2. Dormant-To-Reverse Request Delay- This field defines the additional setup timrequired to transition from the dormant state to the reverse request state. Thisaccounts for the time required to re-establish the fundamental channel before enthe reverse request state. The current recommended value for this parameter isseconds.

Note: 3. Edit - This pull down menu is used to edit the call model table. The “Insert” optionused to enter new blank rows that can then be filled in to create new call models“Insert w/Defaults” option is used to insert new rows that are populated with defvalues. Other options are also available for cutting, copying and pasting informaFor further details on each of the functions in this menu, please see the “NetPlan CStatic System Simulator User’s Guide”.

Note: 4. Name - This field is used to name a specific call model.

Note: 5. Service Type- This field further defines the specific call models. There are six servtypes to choose from: Email w/attch., Email w/o attch., FTP, Web HTTP 1.0, WHTTP 1.1, and WAP. Some of the distinguishing characteristics of these serviceinclude the number of files per download (one versus multiple) and the version of Hthat is used (1.0 versus 1.1, which indicates whether or not a separate TCP connecused per downloaded file). The following gives a brief description of each service tFor further details, please see the “NetPlan CDMA Static System Simulation UsManual”.

Email w/attch. - The email with attachments service represents the case where muemail messages and their attachments are downloaded at the same time. An examthis case would be the use of Outlook or Netscape mail with a laptop computedownload multiple emails and their attachments all at once. The downcharacteristics are similar to HTTP1.1 in that only a single TCP connection is requto download all the references.

Email w/o attch. - The email without attachments service models the case where siemail messages are downloaded and then read by the user. An example of this swould be using email services through Yahoo! or Hotmail. Downloads contain a sifile (reference), with a think or read time occurring after each file download.

FTP - This service models a user transferring a file or series of files. The serbehavior is the same as for HTTP 1.0 in that TCP slow start occurs at the beginnieach file download.

Web HTTP 1.0 - This service type would likely involve a high speed subscriberlaptop running a web browser. When the web server is running HTTP 1.0, eachdownload (i.e. GIF image, etc.) utilizes a separate TCP connection. The impact isthe TCP slow start mechanism is restarted for each file reference, resulting in a lthroughput rate. The user remains in the forward reference state until all filestransferred, and then will transition to the think state.


6


eptfile. Thisthat

w/ofinedparaterently

erst thets theain

ds ist callmly

each

that

theersequest

ner of

Web HTTP 1.1 - This service is similar to the previous service in TCP behavior, excthat the web server in this case is running HTTP 1.1. In this case, multiplereferences which comprise a web page are sent using a single TCP connectioneliminates the additional slow start periods and resulting throughput degradationoccur with HTTP 1.0.

WAP - The WAP service, or text browsing, has the same TCP behavior as EmailAttachments. There should only be a single file representing each user “call” as deby the number of forward references parameter. Each file download requires a seTCP connection. Note that WAP overhead and packet acknowledgement are curnot modeled. A TCP connection is assumed.

Note: 6. Initial Inactive Time (s) - At the start of the simulation, the dropped data subscribare initially inactive. This field defines the average amount of time (in seconds) thadropped data subscribers remain inactive. However, since this value represenaverage of a uniform, random distribution, the actual time that a subscriber will reminactive will be distributed about this average. For example, if a value of 30 seconused as the initial inactive time for a given call model, then the subscribers of thamodel will remain in the inactive state anywhere from zero to 60 seconds, randodistributed with the average being 30 seconds. This varies the timing of whensubscriber enters the next call state.

The recommended value for this field should correspond to the mean think time forcall model type.

Note: 7. Rev. Request Size (bytes)- These truncated Pareto distribution parameters definereverse request (upload) file size in bytes. (The length of time spent in the revrequest state is determined by the amount of time it takes to transmit the reverse refile.)

Note: 8. # Forward References (Files per Download)- This set of truncated Pareto distributioparameters define the number of files contained in a single download (i.e. the numbweb page files accessed per single mouse click).


6


in

riberquest.

ude thers.

etc.) isCP/IP’s datared in

Figure 6-8: CDMA Parameters - Data Services - Call Models Tab (right portion of screen)

NOTES:

Note: 1. Fwd. Reference Size (bytes)- These fields define the forward reference/file sizebytes, using a truncated Pareto distribution.

Note: 2. Think Time (s) - These parameters correspond to the amount of time that the subscspends inactive (e.g. thinking or reading a web page) before the next reverse reThis is modeled using a truncated Pareto distribution.

Note: 3. Description - This is a text field that is used to describe the specific call model.

6.2.2.3.2 TCP Tab

The TCP tab defines the parameters associated with modeling TCP. These parameters inclmaximum segment size, maximum window size and the acknowledgement delay paramete

During the forward reference state, the user source data (e.g. the actual web page files,broken up into 512 or 1500 byte TCP segments or packets, each containing 4 bytes of Theader information. Unacknowledged packets from this data stream are stored in the SDUbuffer during this state. The maximum quantity of unacknowledged packets that can be sto

12

3


6


ith thewillestionTCPlt fromrade

acket.umesstem).

ure.

ta,e arelient.slow

the SDU’s data buffer is dependent upon the size of the congestion window associated wTCP connection. The congestion window will initially start out with a size of 1 segment andincrease exponentially in size (2, 4, 8, ...) to the maximum congestion window size. The congwindow will increase in size with each packet acknowledgement. This behavior, known asslow start, avoids what would be unnecessary or continuous retransmissions that may resuoverwhelming some intermediate router(s) or slower link(s), which can significantly degthroughput.

After the TCP packet has been transmitted, an acknowledgement delay is applied to the pAfter this delay time has expired, the packet will be cleared out of the SDU’s buffer. This assthat all packets are acknowledged (although this is not always the case in an actual syNetPlan does not currently model unacknowledged packets.

Each of these parameters is described further in the notes associated with the following fig

Figure 6-9: CDMA Parameters - Data Services - TCP Tab

NOTES:

Note: 1. Maximum Segment Size- This field corresponds to the maximum size of a unit of daor segment, that TCP sends to IP. This is set to either 512 or 1500 bytes. Thesconventional values and are typically negotiated between network server and cTCP segment size has significant impact on throughput, as a direct result of TCP

1

2

3


6


thet the

ofs TCPever,e an

oft the

workms)

or theactual

ribers,

r classesistics.

to beifferent

acket

ce,rd

start behavior. The smaller the maximum segment size value, the smallerthroughput. It is recommended that the network operator be queried to find ouappropriate TCP segment size to use for simulation.

Note: 2. Maximum Window Size - This parameter corresponds to the maximum numberoutstanding unacknowledged packets or segments that can be sent. This modelslow start behavior and congestion control. A value of 16 is recommended. Howthe operator of the market being simulated should be contacted to determinappropriate value based on actual TCP performance in the serving networks.

Note: 3. Acknowledgement Delay- This field corresponds to the implied delay (in numberframes) for an acknowledgement for a transmitted packet to be received back atransmitter. This involves subscriber, interim proxy servers, and end server netprocessing delays, as well as RF link feed-through delays. A value of 3 frames (60is recommended for this parameter. However, it is encouraged that the operator fmarket being simulated be queried to determine an appropriate value based onnetwork server performance.

6.2.2.4 CDMA Parameters - Subscribers Tab

The Subscribers tab contains the CDMA parameters which define the properties of the subscas well as the distribution of these subscribers throughout the system.

For each analysis, one or more subscriber classes can be defined. Each of these subscribecan be configured independently, allowing for different combinations of subscriber character

6.2.2.4.1 Defining Subscriber Classes

The main CDMA Parameters - Subscribers screen (as seen in Figure 6-10) allows trafficassigned based on classes of subscribers. However, before traffic can be assigned, the dsubscriber classes that will be used in the particular system design need to be defined.

Detailed information that is needed to define each subscriber class includes:

• subscriber type (e.g. voice, low speed packet data, circuit data, high speed pdata, in-vehicle, in-building, on-street, FWT, etc.)

• antenna gain

• penetration loss

• air interface (IS-95A/B low speed, IS-95B high speed, and IS-2000)

• radio configuration (RS1 or RS2 for IS-95 subscribers; forward link RC3 Voiforward link RC3 Data, forward link RC4 Voice, forward link RC4 Data, or forwalink RC5 (FCH only) Data for IS-2000 subscribers)

• maximum forward data rate (only used for IS-95B and IS-2000 subscribers)


6


ced

ferentEditor

• forward data rate outage (only used for IS-2000 subscribers)

• voice or data activity factor (forward and reverse)

• call model information (only used for IS-2000 data subscribers in time-slisimulations)

• target and outage FER

• fading type (mobile, wall FWT or table FWT)

• maximum forward TCH power

• maximum reverse power

• speed distribution

Once all of the subscriber characteristics information has been gathered, then the difsubscriber classes can be set up within NetPlan. This is done through the Subscriber Classwindow. The following figure shows how to access this window.

Figure 6-10: Access to Subscriber Class Editor

1


6


ow,ndown be

three

to

NOTES:

Note: 1. Subscriber Classes Edit. . .- This button accesses the Subscriber Class Editor windwhich is used to create, edit, and delete individual subscriber classes. The wicontains a scroll bar at the bottom so that all of the fields per subscriber class caaccessed.

Each of the fields and buttons in the Subscriber Class Editor are described with the nextfigures.

Figure 6-11: Subscriber Class Editor - left portion of the sliding screen

NOTES:

Note: 1. Subscriber Class Name - This field is used to name the subscriber class.

Note: 2. Antenna Gain (dBd) - This field defines the subscriber antenna gain which is appliedboth the transmit and receive paths.

1 2 3 4 5 6 7


6


nal.body

s)

r this

h adata

/

Typical values for these gains are:Antenna Gain 900 MHz 1.9 GHzVehicle antenna gain = 3.0 dBd = 3.0 dBdHand-held subscriber antenna gain = 0.0 dBd =-2.14 dBd1

Note: 3. Penetration Loss (dB)- This field represents the estimated attenuation of the sigThis attenuation accounts for factors such as in-vehicle loss, in-building loss andloss.

Total Penetration Loss (dB) = [in-vehicle loss (dB)] + [body loss (dB)]+ [in-building loss (dB)]

Typical values for these individual losses are:In-vehicle loss = 6.0 dBBody loss = 2.0 dBIn-building loss (varies widely)2 = 15.0 dB

Examples of resulting Total Penetration Losses:

Hand held subscriber unit used in a vehicle (assumes in-vehicle and body losses)Total Penetration Loss = 6.0 dB + 2.0 dB = 8 dB

Hand held subscriber unit used on the street (assumes body loss)Total Penetration Loss = 0.0 dB + 2.0 dB = 2 dB

Hand held subscriber unit used in a building (assumes in-building and body losseTotal Penetration Loss = 15.0 dB + 2.0 dB = 17 dB

Note: 4. Air Interface (LS = Low Speed, HS = High Speed)- This defines the air interfacestandard which controls the traffic channel assignment. There are three choices fofield: IS-95A/B LS (low speed), IS-95B HS (high speed), and IS-2000.

IS-95A/B LS:A setting of IS-95A/B LS is used when modeling IS-95 voice subscribers witvocoder rate of 9.6 or 14.4 kbps, or when modeling IS-95 data subscribers with arate of 9.6 or 14.4 kbps.

1. See Section 2.4.1 for further details regarding the subscriber antenna gain.2. For more details on building loss and typical values, please refer to Sect. 4.2.1.1 of the “CDMA

CDMA2000 1X RF Planning Guide” (March 2002).


6


14.4ve the

ned toeferata

sly

it.ice,rd,re

dio

raffic1 (9.6RC)a data

000S orRC3theithin

adionotreaterby theo beentalverse

IS-95B HS:A setting of IS-95B HS is used when modeling IS-95 rates that are higher thankbps. This allows additional (supplemental code) channels to be assigned to achiedesired data rate.

In the case of IS-95B HS subscribers, supplemental code channels are only assigthe forward link. The reverse link is limited to a single 9.6 or 14.4 kbps channel. (Rto Appendix A4 for further information concerning High Speed Packet Dsimulations.)

IS-2000:A setting of IS-2000 is used when modeling IS-2000 subscribers.

Please note that IS-2000 and IS-95B HS data subscribers cannot be simultaneouassigned in the same analysis.

Note: 5. Radio Configuration - This field defines the radio configuration for the subscriber unThe radio configuration options for an IS-2000 subscriber are: RC3 (forward) VoRC3 (forward) Data, RC4 (forward) Voice, RC4 (forward) Data, and RC5 (forwaFCH only) Data. All of these forward link radio configurations except for RC5 apaired with the RC3 reverse link radio configuration. The RC5 forward link raconfiguration is paired with the RC4 reverse link radio configuration.

For an IS-95 subscriber, the radio configuration defines the forward and reverse tchannel rate set for the subscriber. The options for an IS-95 subscriber are: RSkbps) or RS2 (14.4 kbps). For voice subscribers, an 8 kbps vocoder (including EVis modeled using a data rate of 9.6 kbps and a 13 kbps vocoder is modeled usingrate of 14.4 kbps.

Note: 6. Max. Fwd Data Rate (only used for IS-95B HSPD and IS-2000 data subscribers)-This field defines the maximum data rate for an IS-95B HSPD subscriber or an IS-2data subscriber. It can only be set when the Air Interface is defined as IS-95B Hwhen the Air Interface is defined as IS-2000 and the Radio Configuration is set asor RC4 Data. (Since the IS-2000 Radio Configuration RC5 Data is FCH only,maximum forward data rate in this case is 14.4 kbps and is automatically set wNetPlan.)

For IS-95B HS, the options available will depend on the rate set selected in the RConfiguration setting (RS1 or RS2) and will represent the “raw” data rate (accounting for RLP overhead, retransmissions, or TCP slow start). Data rates gthan 9.6 or 14.4 kbps are achieved by concatenating multiple channels as definedIS-95B standards. This HSPD standard allows for a total of 8 CDMA channels tassigned to a subscriber on the forward link (1 fundamental and 7 supplemchannels). A single CDMA channel is assigned to an active subscriber in the redirection.


6


alues76.8

gh 7

alues, andugh 7

d tohedatas (1e SetnelsnderSet 1

rdware

thed for a

When the Radio Configuration is set as Rate Set 1 (9.6 kbps), the possible vavailable for the maximum data rate are: 9.6, 19.2, 28.8, 38.4, 48.0, 57.6, 67.2, andkbps. (These are “raw” air interface data rate values corresponding to 0 throusupplemental channels, respectively.)

When the Radio Configuration is set as Rate Set 2 (14.4 kbps), the possible vavailable for the maximum data rate are: 14.4, 28.8, 43.2, 57.6, 72.0, 86.4, 100.8115.2 kbps. (These are “raw” air interface data rate values corresponding to 0 throsupplemental channels, respectively.)

The table below shows both the raw and RLP-ideal bit rates:

Although the IS-95B standard allows for a total of 8 CDMA channels to be assignea subscriber on the forward link, Motorola’s implementation of IS-95B limits tmaximum number of forward channels to 6. This is due to the fact that thetranscoder (DXCDR) architecture within the CBSC can only assign 6 channelfundamental and 5 supplemental channels). This limits the “raw” data rate for Rat1 to 57.6 kbps. In addition, the current Motorola limitation for Rate Set 2 is 5 chan(1 fundamental and 4 supplemental channels for a “raw” data rate of 72.0 kbps). Uthese conditions, 64 kbps operation after RLP requires Rate Set 2. (Seven Ratesupplemental channels would be needed for 64kbps and this exceeds current halimitations.)

Note that although it is possible to select a maximum data rate which is equivalentto more than 4 supplemental channels in Rate Set 2, the algorithm within NetPlanwill limit the number of supplemental channels to 4.

For Motorola IS-95B infrastructure implementations, it is recommended thatmaximum forward data rate be set so that no more than 6 channels can be assigne

Number ofFundamental

Channels

Number ofSupplemental

Channels

RS1 DataRate (“Raw”

kbps)

RS1 BearerRate (kbpsafter RLPbest case)

RS2 DataRate (“Raw”

kbps)

RS2 BearerRate (kbpsafter RLPbest case)

1 0 9.6 8.0 14.4 12.81 1 19.2 16.0 28.8 25.61 2 28.8 24.0 43.2 38.41 3 38.4 32.0 57.6 51.21 4 48.0 40.0 72 64.01 5 57.6 48.0 86.4 76.81 6 67.2 56.0 100.8 89.61 7 76.8 64.0 115.2 102.4


6


a rateriber (1

aluese that2000fer

rs.anneln aain aage).Fwd.d. Forthis

ovidealso

Rate Set 1 subscriber (1 fundamental and 5 supplemental channels for a “raw” datof 57.6 kbps) and no more than 5 channels can be assigned for a Rate Set 2 subscfundamental and 4 supplemental channels for a “raw” data rate of 72.0 kbps).

For IS-2000 data subscribers with Radio Configuration RC3 or RC4, the possible vfor the maximum forward data rate are: 9.6, 19.2, 38.4, 76.8, and 153.6 kbps. Notthese IS-2000 data rate limits refer only to the supplemental channels. (The IS-FCH will also carry bearer traffic.) In contrast, the data rate limits listed for IS-95B reto both the fundamental and supplemental channels.

Note: 7. Fwd. Data Rate Outage- This parameter is only used for IS-2000 data subscribeThis value specifies the outage criteria for the forward data rate. A high speed chrequest failure (NumHSReqFail located in the CellStatTS_XX file) will result whesubscriber requests a high speed supplemental channel and fails to obtsupplemental channel of at least this defined minimum rate (Fwd. Data Rate OutThe high speed channel request failure is not pegged when the request is below theData Rate Outage, regardless of whether or not the requested rate was assigneinstance, if it is desired to achieve a certain minimum data rate in the system,parameter can be set to that desired data rate. The resulting statistics will then prinsight into how often the minimum data rate could not be achieved, and therebyindicate if additional design optimization is required.


6


ictuallyerse

then

datadata

Figure 6-12: Subscriber Class Editor - middle portion of the sliding screen

NOTES:

Note: 1. Activity Factor (%) - These columns define the activity factor for the specifsubscriber class. The values reflect the percent of time that voice or data is actransmitted on the forward or reverse link. Within NetPlan, the forward and revtransmit power is scaled by the activity factor.

Activity factors may vary between systems. If values for a market are not known,some typical values for activity factors are:

Subscriber Class Forward Activity Factor Reverse Activity FactorVoice (IS-95 or IS-2000) 40% 40%Circuit Data 60% 20%IS-95B LSPD (Low Speed Packet Data) 20% 20%IS-95B HSPD (High Speed Packet Data) 35% 20%

Note that IS-2000 time-sliced simulation uses detailed call model information forsubscribers rather than an activity factor. IS-2000 non time-sliced simulation uses aactivity factor of 100% (this is currently hard coded within NetPlan).

5 61 2 3 4


6


tion

d is, orin thection

FER)

et andl to bens).-95BFER

s areo 3%.ly.

rgetions

hescriberer ofithm

r FER

Further information regarding IS-95B data activity factors can be found in SecA4.3.4.1, “Forward Activity Factor (%) [IS-95A/B only]”.

Note: 2. Call Model - This field assigns a call model to a given subscriber class. This fielonly available for time-sliced simulations of IS-2000 data subscribers (RC3, RC4RC5). The call models that are available for selection are the ones that are set upCDMA Parameters>Data Services>Call Models Tab (as discussed in a Se6.2.2.3.1, "Call Models Tab").

Note: 3. FCH FER (%) - These fields represent the target and outage Frame Erasure Rate (criteria for the fundamental channel.

Please note that although there is not a separate GUI parameter to set the targoutage FER for the IS-2000 Data SCH, these values are set within the NetPlan too5% target and 10% outage (for both time-sliced and non time-sliced simulatioThere is also no separate GUI parameter to set the target and outage FER for ISSCH. Within NetPlan, these values are set to be the same as the IS-95B FCHsettings.

In addition, for IS-2000 simulations, the reverse link target and outage FER valueset within NetPlan. The reverse FCH FER target is set to 1% and the outage is set tFor the reverse SCH, the target and outage FER is set at 5% and 10%, respective

FER Target:The simulator power control algorithms attempt to achieve the FER tapercentage for both the forward and reverse links (within the number of iteratallowed per drop for the dropped subscribers).

FER Outage:This field defines the minimum quality of an acceptable link. This is tworst case frame erasure rate percentage that will be considered as a “good” subconnection by the simulation statistics. This assumes that the maximum numbiterations allowed per drop has been reached without the power control algorachieving the target FER for the dropped subscribers.

Since packet data can be retransmitted to reduce errors, it can tolerate a highevalue.

Some typical FER values:Subscriber Class Target FER Outage FERVoice (IS-95 or IS-2000) 1% 3%Circuit Data 1% 3%IS-95B LSPD (Low Speed Packet Data) 5% 10%IS-95B HSPD (High Speed Packet Data) 5% 10%IS-2000 Data FCH 5% 10%


6


Thetemiber.ther

thenlyeveduld

und

erlinkstionlue isCH

he perRatewr.Set 2et 1

eo theld beher.4.1,ber

Further information regarding FER values can be found in Appendix A4.

Note: 4. Fading Type - This field is used to select a fading type for each subscriber class.fading characteristics for a fixed wireless terminal (FWT) that is used in a WiLL sysare different than the fading characteristics for a mobile/portable subscrAdditionally, the fading characteristics for an FWT are different depending on whethe FWT is mounted on the wall or placed on a table top.

The Fading Type field is used to select the fading model that is appropriate forsubscriber class: Mobile, Wall FWT, or Table FWT. The FWT fading types are oavailable for RS1 subscriber classes. Higher system capacity will typically be achiin a WiLL system design when selecting Table FWT. Wall FWT or Table FWT shobe selected according to the actual FWT installation plan.

Further information regarding the Fading Type for a WiLL system design can be foin Appendix A3.

Note: 5. Max. Fwd. TCH Pwr. (% Pilot Pwr.) Optional - This field is used to specify themaximum forward traffic channel power. This is an optional field. If it is set, this psubscriber class value overrides the per sector Max. TCH setting of the forward(defined in the site parameters) for a subscriber of this type. (Further informaregarding the per sector Max. TCH parameter can be found in Chapter 7.) This vaa percentage which is applied to the pilot power to determine the maximum Tpower.

For example, in a mixed rate system (one with Rate Set 1 and Rate Set 2 users), tsector Max. TCH setting may be set for Rate Set 1 operation (75% of pilot). TheSet 2 users typically operate at a higher Max. TCH (100% of pilot). The Max. TCH Pfor the Rate Set 2 subscriber class could then be set for 100% to allow the Rateusers to achieve the higher Max. TCH level. The Max. TCH Pwr. for the Rate Ssubscriber class could remain unchanged (blank) or set to 75%.

Note: 6. Max. Rev. Power (dBm) - This field defines the maximum power that can btransmitted by the subscriber unit. Consider this as the power which is delivered intantenna system of the phone. The antenna gain and antenna line loss wouaccounted for in the antenna gain field. This field is typically set at 23 dBm. [For furtinformation regarding subscriber unit transmit power, please see Section 2“Subscriber Unit Tx Power”, within this document, or Section 5.2.3.1.1, “SubscriUnit”, in the “CDMA/CDMA2000 1X RF Planning Guide” (March 2002).]


6


eedf that

eods toethod

Figure 6-13: Subscriber Class Editor - right portion of the sliding screen

NOTES:

Note: 1. Speed Distribution - The Speed Distribution parameters are used to specify a spdistribution method for each subscriber class and then define the characteristics ospeed distribution.

Note: 2. Distribution Method - This field defines the speed distribution method that will bassigned to a particular subscriber class. There are five speed distribution methselect from: Constant, Normal, Exponential, Speed List and Speed Map. Each mhas one or more associated fields where entry is required, as described below.

Speed Distribution Method Required field(s)Constant ConstantNormal Mean and Std. Dev.Exponential MeanSpeed List Speed List information defined in Edit Speed ListSpeed Map Speed Map Name and Std. Dev. (%)

1

2 3 4 5 6 7


6


nedof this

robespeed

dtion)

luesround

ationativeiations

d to

eedt areeach

Note: 3. Constant (kph) - This field is required when the speed distribution method is assigas Constant. This field specifies a speed value that is assigned to all subscribersclass.

Note that the subscriber class that will correspond to the image probe (see pcharacteristics under the CDMA Parameters - Image tab) has to have a constantassociated with it.

Note: 4. Mean (kph) and Std. Dev. (kph) - The Mean field is required when the speedistribution method is either Normal or Exponential. The Std. Dev. (standard deviafield is required when the speed distribution is Normal.

When the distribution is Normal (Gaussian) Distribution, the Mean and Std. Dev. vamust be assigned to define the distribution. The mean value defines the speed awhich the normal distribution is centered. The standard deviation defines the variabout the mean for the normal distribution of subscriber speeds. [NOTE: Negspeed values will not be generated and values greater than three standard devfrom the mean are ignored.]

Figure 6-14: Normal Speed Distribution

When using the Exponential distribution method, only the mean value is requiredefine the distribution.

Note: 5. Edit Speed List . . . - The Edit Speed List button is used to create or edit a SpDistribution List. This speed distribution list is applied to all subscriber classes thausing the Speed List distribution method. A separate list cannot be defined forclass.

Depressing the Edit Speed List button will access the following dialog box.

Pro

babi

lity

of S

ubsc

riber

s

Speed of Subscribers

MeanStandard Deviation


6


ned atages

d will

at arefor a

alue ofined

to be

s oflect theed in

Figure 6-15: Speed List Editor

This dialog box is used to specify the percent of subscribers that should be assigcertain speed. Up to 10 different speeds can be defined. The total of all the percenmust add up to 100%. Subscribers that are using the speed list distribution methoonly be assigned the speeds that are entered in this speed list.

Note: 6. Speed Map- The speed map parameters are required for all subscriber classes thusing the speed map distribution method. When using this method, the speedsubscriber is defined according to its position relative to the selected speed map.

The value of the speed map at the position of the subscriber is used as the mean va Normal (Gaussian) distribution. The standard deviation for the distribution is defas a percentage of the mean. This allows a single standard deviation percentageapplied to any mean value in the speed map.

Name . . .- This field is used to select the appropriate speed map for a given classubscribers. Once the speed map has been generated, this button is used to sespeed map from all available speed map files. (The creation of this map is coverChapter 5 “Traffic (Distribution) and Speed Maps”.)


6


theandardspeed, the

ofon or

ughoutd from

ses are

Std. Dev. (%)- This field defines the standard deviation percent to be used bysimulator when assigning a subscriber speed to the dropped subscribers. This stdeviation is applied as a percentage of the mean value that is obtained from themap for the location of the particular subscriber. If the Std. Dev. is set to 0 (zero)speeds assigned will be exactly the value in the speed map.

Note: 7. Description - This field is informational only. It can be used to describe the intentionthe subscriber class being created. The field has no effect on the propagatisimulation.

6.2.2.4.2 Assigning Traffic to the Subscriber Classes

Once the Subscriber Classes are set up, the distribution of these subscribers is defined throthe system. The number of Erlangs that will be assigned to each class of subscribers is definethe CDMA Parameters - Subscribers tab. Also, parameters which apply to all subscriber clasdefined in this window.

Figure 6-16: CDMA Parameters - Subscribers

1

2

3

4

56

7

8

9


6


hisl (or

r of

r ofngstheUsing

-95Bnt alllicedssionata

per

areas:dthodote 5

riberven.

thecriber

NOTES:

Note: 1. Erlangs per Class Calculation- There are several methods for assigning Erlangs. Tdefines the actual dropped traffic load for the simulation and represents the totamean if the “Use Poisson Variation Across Drops” box is selected) numbesubscribers used in each drop of the simulation.

There are three methods of assigning Erlangs:- Percent of Erlangs- Erlangs and Subscribers- Erlangs Only

These three methods will be described further in the following three notes.

When running simulations for a carrier within a multi-carrier system, the numbeErlangs must reflect the traffic load for only the given carrier, not the number of Erlafor the entire system. For further information on determining the distribution ofErlang load between carriers in a multi-carrier system, please see Section 5.8.6, “the TCMS in Analyses”.

For packet data modeling, the traffic load is defined relative to a session. For ISand IS-2000 non time-sliced data subscriber classes, the Erlangs represesubscribers within the active period of the session. In the case of time-ssimulations, however, the Erlangs represent all subscribers with an open se(whether active or dormant). Further information regarding the traffic load for dservices can be found in Appendix A4.

Note: 2. Percent of Erlangs- This Erlang calculation method defines the number of Erlangssubscriber class to be a fixed percentage of the total system Erlangs.

When using this method of assigning Erlangs, the Erlang data is entered into two - theTotal/Mean Number of Erlangsin the system. If the Poisson distribution methois selected, this is the mean value of the distribution. If the Poisson distribution meis not selected, then this field represents the Total Number of Erlangs. (Refer to Nfor further information regarding the Poisson distribution.)- the % of Classcolumn, where the percent of Erlangs is entered for each subscclass. This field defines the fractional portion of the total system traffic that a giclass of subscriber represents. The total percent for all classes must sum to 100%

Note: 3. Erlangs and Subs. - The Erlangs and Subscribers method is used to specifyexpected Erlangs per subscriber and number of total subscribers for each subsclass.


6


the

r of

eutionthef

willd for

rue:

apficationfficet is

n aMAill

When using this method of assigning Erlangs, the Erlang data is entered intofollowing two columns:- Erl/Sub- #Subs.

Note: 4. Erlangs Only - This method of assigning Erlangs is used to specify the numbeErlangs expected for each subscriber class.

When using this method, the information is entered into the following column:- #Erl.

Note: 5. Use Poisson Variation Across Drops- When the Poisson option is selected, thnumber of Erlangs for each subscriber class varies according to a Poisson distribacross the different simulation drops. (If this field is selected, then the Erlang field toright of this becomes the “Mean Number of Erlangs” and represents the mean value othe Poisson distribution.)

The statistical distribution of the subscribers used for the entire Monte Carlo runform a Poisson distribution around the number of Erlangs specified or calculateeach subscriber class.

It is normally expected that a Poisson Distribution is used unless the following is t

Note: 6. Traffic Distribution - This parameter is used to select the appropriate Traffic M(TMAP) or Traffic Carrier Map Set (TCMS) for the given subscriber class. A trafmap defines the probability of a subscriber being placed in a given geographic locfor each drop of the simulation. Areas of the traffic distribution map with higher tradensities have a greater probability of receiving subscribers. A traffic carrier map sa set of traffic maps that define the traffic distribution for each individual carrier imulti-carrier system. If a TCMS is chosen here, the carrier selected in the CDParameters - Simulation Model interface will determine which layer of this TCMS wbe used during simulations.

Table 6-2: Poisson or Constant Distribution

< 10 Sectorsin System

1 sector has > 15%of system load

Use Poisson orConstant Dist.

False False Poisson

False True Constant

True False Constant

True True Constant


6


pe ofe ofces.

on)

byMS

to

ersage

tion.inger

t arespread

RFigure.

Each subscriber class can have a separate TMAP or TCMS. If the traffic for one tysubscriber is expected to be distributed differently than the traffic for another typsubscriber, then multiple TMAPs or TCMSs are created to reflect these differen(The creation of traffic maps and TCMSs is covered in Chapter 5 “Traffic (Distributiand Speed Maps”.)

The TMAP or TCMS that will be associated with a subscriber class is selectedpressing the ellipsis (. . .) button. This button is used to choose the TMAP or TCfrom the available traffic files.

Note: 7. Totals - A Totals field is displayed for the following columns:% of Class, #Subs., #Erl.

Information is not entered here, but the resulting information should be verifiedensure that appropriate results are seen.

Note: 8. Subscriber Noise Figure- This field defines the Noise Figure used by the subscribin the simulation. This value is used for both the dropped subscribers and the improbe. The recommended value for this parameter is 10 dB.

Note: 9. Ec/Io Finger Locking Threshold - This field defines the minimum Ec/Io onto which arake receiver finger may lock and demodulate during a subscriber connecLaboratory measurements of CDMA subscribers have established an effective flocking threshold to be -23.75 dB.

6.2.2.5 CDMA Parameters - RF Environment Tab

The RF Environment tab within the CDMA Parameters window contains parameters tharelated to the RF environment. These parameters include information regarding the delaymodel, the lognormal fading model, and the Inter-System Interference (ISI) model. TheEnvironment parameters are described in detail in the notes associated with the following f


6


ntll theelay

altputse notndardoarseg inrned

Figure 6-17: CDMA Parameters - RF Environment

NOTES:

Note: 1. Delay Spread Model- These fields define the distribution of subscribers with differeray models within a single simulation drop. The settings define the percentage of adropped subscribers that will be randomly assigned a 1-Ray, 2-Ray, or 3-Ray dspread model.

Note: 2. Apply Lognormal Fading - With this feature, NetPlan creates independent lognormshadowing overlay planes for each drop in a simulation run. The statistical oucreated while using this feature are accurate, though the CDMA image results arusable. The lognormal plane randomly biases path loss bins (through the stadeviation). This biasing creates enough variation that all images produced are too cto use. Therefore, in order to better simulate the effect of lognormal shadowinCDMA images, it is recommended that the lognormal shadowing overlay be tuOFF and that the fading be accounted for elsewhere in the simulation.

1

3

2


6


atione isnded(refer

ry is

er ton

isThe

st be

berrencen is

end.

drrent

berore

n

n

To compensate for not activating the lognormal fading feature, an additional attenuvalue should be factored into the path loss. This additional attenuation valusubtracted from the effective gain for each cell/sector antenna. The recommeattenuation value is the same as the fade margin value assumed in the link budgetto Chapter 2, where the example shows 5.6 dB for 95% area reliability). This entcovered in Chapter 7 - “Setting Simulator Input Parameters - Site Level”.

Note: 3. Enable Inter-System Interference Modeling - This button must be selected if theInter-System Interference (ISI) model is to be applied to the system study. RefAppendix A7: “Modeling Inter-System Interference” for further information omodeling ISI and determining when it should be used.

Inter-System Interference File ...- Pressing the Inter-System Interference File ellipswill show the Inter-System Interference files that are available to choose from.steps required to generate the ISI File are described in Appendix A7. An ISI file muselected if the Inter-System Interference Modeling feature is to be used.

Suppression Value- This field defines the attenuation which is used in the subscrireceive antenna path when the interference criteria is met to attenuate the interfethe subscriber receives. The interference at all subscribers in the simulatioattenuated. The value of the subscriber attenuation pad is 20 dB.

Apply Suppression- The suppression value can be applied all of the time or only whspecific criteria are met. This section specifies when the suppression will be applie

When Subscriber (IF) Received Power Exceeds: The suppression value is only appliewhen received subscriber (IF) power exceeds the specified value. This is the cumethodology for subscribers to make the attenuation activation decision.Fill in the accompanying field with -81 (dBm). The range of values for subscrireceived (IF) power (in dBm) is -81.0 through -84.0 (-84.0 dBm is the mconservative value).

When Best Finger Ec/Io Does Not Exceed: The suppression value is applied only whethe Ec/Io of the subscriber receiver’s best finger is below the specified value.

When Inter-System Interference Exceeds: The suppression value is only applied wheinter-system interference (ISI) power exceeds the specified value.

Always: The suppression value is applied in all instances.


6


arerobe as

obees thef thents the

6.2.2.6 CDMA Parameters - Images Tab

The Images tab, as shown in the following figure, includes the CDMA parameters whichspecific to image generation. These parameters include the characteristics for the Image Pwell as different criteria used when generating specific images.

Figure 6-18: CDMA Parameters - Images

NOTES:

Note: 1. Probe Characteristics- Images are generated by sampling the system with the prsubscriber. This probe is placed in the center of each image bin where it measursystem to determine the value for that image at that particular bin. The value omeasurement is dependent upon the characteristics of the probe itself and represeperformance of a subscriber with these physical characteristics.

Probe Properties Derived From Subscriber Class: The probe subscriber’scharacteristics are defined by specifying an existing subscriber class.

1

23

4

5

6


6


rs arebution.fineds. It isprobe,red tosen forrated,

scribers thatan in-

ither

t beriber’serage

chy the

at areibers

MAthe

odel,h 100g the

preadiatethatires a

ions.10%

onaltions.

Any of the subscriber classes which are defined in the CDMA subscriber parametevalid to use for the probe, as long as the class chosen has a constant speed distriHowever, it is recommended that a specific “image probe” subscriber class be dein the subscriber parameters and be used to define the image probe characteristicalso recommended that only voice subscriber classes be chosen for the imageexcept in the case of generating the Achieved Data Rate Images (where it is requihave a data subscriber class for the image probe). If a data subscriber class is chothe image probe and any image other than the Achieved Data Rate Image is genethe image will only represent the fundamental channel for the data subscriber.

The subscriber class chosen for the Probe Characteristics defines the type of subthat the resulting images represent. For example, if it is desired to generate imagerepresent an in-vehicle voice subscriber, then the probe properties need to matchvehicle voice probe subscriber.

Delay Spread: The delay spread parameter for the probe subscriber can be set to eFixed or Vary Across Drops.- Fixed: If the fixed delay spread is chosen, a 1-ray, 2-ray, or 3-ray model musselected. The CDMA images that are produced are dependent on the probe subscray model. A value of 2-ray has been determined to represent an “average” covplot.- Vary Across Drops: If this parameter is set, the delay spread model will vary for eadrop of the simulation using the same mix of delay spread models as that used bdropped subscribers. For example, assume the Delay Spread Model fields thspecified in the CDMA Parameters - RF Environment tab for the dropped subscrare defined to be:

1-Ray 60%2-Ray 30%3-Ray 10%

and the simulation was run making images for 100 drops (defined in the CDParameters - Simulation Model tab). If the Vary Across Drops field is selected, thenimage probe would produce images 1 through 60 using a 1-ray delay spread mimages 61 through 90 using a 2-ray delay spread model, and images 91 througusing a 3-ray delay spread model. These images can then be examined usinNetPlan Statistical Images post-processing feature.

Varying the image probe delay spread to match the dropped subscriber delay sdistribution requires a certain minimum number of drops to get the approproutcome. This minimum number of drops depends on the delay spread distributionis being used for the dropped subscribers. For instance, the above example requminimum of 10 drops in order to get the proper percentage of image probe variatIdeally, 60% of the drops should be 1-ray, 30% of the drops should be 2-ray, andof the drops should be 3-ray. However, if only 5 drops were specified, the fractiportions of the drops could not be assigned the correct delay spread distribu


6


elay

Iothis

ohen 3d third

or theand

gesr the

probepread,

isc/Ioate a

tor at

field

hendentselecttion

tthatallilot

r this

sultiple

Therefore, 5 drops is an inappropriate number of drops to run with this particular dspread distribution.

Note: 2. Nth Best Ec/Io (Pilot and Server) Images- These image types show the best Ec/pilot value and the sector from which that value originated. The parameters insection define specific criteria that is used when these images are generated.

Quantity of Images Generated: This field defines the number (N) of Nth Best Ec/IPilot and Server images to be produced. (For example, if a value of 3 is entered, tpilot images and 3 server images are created that contain the best, second best, anbest Ec/Io pilot and server values respectively.) These images are only produced ffirst drop of a Monte Carlo simulation run and are used to investigate the sourcesmagnitude of interfering pilots when reducing pilot pollution problems. (These imawill represent the delay spread of the image probe, either a fixed delay spread ovariable delay spread. If the delay spread was chosen as “Vary Across Drops”, thesubscriber delay spread will match the first assigned dropped subscriber delay sgenerally 1-ray.)

Server Not Computed When Ec/Io Below: When this option is checked, a thresholdapplied to the Ec/Io Server image. This threshold defines the minimum pilot Eaccepted during the generation of this image. Resulting server images will not indicserver for any bin where the Ec/Io value is below this threshold.

There are two options available for specifying the threshold:T-Drop - This specifies the threshold as the T-DROP value for the best serving seceach image bin.Global - This specifies the threshold at a user defined level. Figure 6-18 shows thisset to the Ec/Io finger locking threshold (-23.75 dB).

Note: 3. Pilot Pollution Image - This section sets the threshold parameter that is used wgenerating Pilot Pollution images. The Pilot Pollution Image generation is indepenfrom the Quantity of Images Generated (see previous Note). It is not necessary toa value of 2 or more in the Quantity of Images Generated in order to have Pilot PolluImages generated.

Count Pilots When Ec/Io Greater Than: This value is used when generating PiloPollution images so that each bin within the image represents the number of pilotshave an Ec/Io value within this dB value of the strongest pilot Ec/Io. The Ec/Io forpilot pollution candidates must be within the threshold value of the strongest pthough they do not need to be above T-DROP. A value of 6 dB is recommended fofield.

Note: 4. IS-95B Supplemental Channel Image- This image is used when designing systemthat include IS-95B high speed packet data subscribers. For these systems, m


6


) are

hannelt the

datate Set

ers are1 andted withet 2.

ts.

cket

entsppednewt the

m binnnel

robeontrol

datas whentime

e thehasved byionsd aly fallelectedthe

channels (a fundamental channel and a number of supplemental channelsconcatenated together to achieve higher data rates.

Image Represents Quantity of Supplemental Channels With Rate Set: This specifiesthe rate set of the supplemental channels represented in the Supplemental Cimage. The resulting image depicts the number of supplemental channels aspecified rate set that can be assigned to a subscriber at a particular bin location.

When selecting the rate set in this field, it is important to match the rate set of thesubscribers in the Subscriber Class editor. For example, if the system contains Ra1 data subscribers, this should be set for Rate Set 1. If Rate Set 2 data subscribused in the system, then the field should be set for Rate Set 2. If both Rate SetRate Set 2 data subscribers are used in the system, then images should be generathis field set for Rate Set 1 as well as images generated with the field set for Rate SBoth sets of images are needed to review the system performance of both rate se

(Please refer to Appendix A4 for additional information concerning High Speed PaData simulations.)

Note: 5. IS-2000 Achieved Data Rate Image (Active Probe)- The IS-2000 Achieved Data RateImage is only available for IS-2000 non time-sliced simulations. This image represthe data rate that the probe subscriber is able to achieve with the existing drosubscriber configuration. The image depicts the available margin or resources for auser. This image is slightly different than other images generated by NetPlan in thaprobe subscriber is an active probe. This means that when the probe is moved froto bin, it adds a user to the load (the Nth+1 user) and the supplemental chaallocation and power control convergence algorithms are applied to the psubscriber. (In other images, a passive probe is used. Algorithms such as power cprocesses are not applied to a passive probe subscriber.)

Since this image represents the data rate available for IS-2000 non time-slicedsubscribers, the image probe must correspond to an IS-2000 data subscriber clasgenerating this image. This image is only created for the first drop due to therequired to generate the image.

There are two different versions of this image that can be generated: one wherunderlying traffic has only FCHs assigned, or another where the underlying trafficSCHs assigned. These images represent the IS-2000 data rate that can be achiethe active probe subscriber at a given location under two specific traffic load condit(described below). These traffic load conditions represent an optimistic anpessimistic scenario. The expected achieved data rate for a data probe would likebetween the results presented in these two images. One of these image types is sbefore running simulations to choose the type of image that will be created forAchieved Data Rate image.


6


tasignedmistic

ted bothimisticty and

ria

torthatluesngerere

Underlying Traffic has only FCHs assigned- This image determines the achieved darate available to an active probe, given that the dropped subscribers have been asa fundamental channel with an associated power. This image represents an optiscenario since there may be supplemental resources available for the probe.

Underlying Traffic has SCHs assigned- This image determines the achieved data raavailable to an active probe, given that the dropped subscribers have been assignefundamental and supplemental channels. This image represents a more pessscenario since the probe subscriber can only be assigned the remaining capaciWalsh codes.

Note: 6. All Passive Probe Images- The parameter specified in this section provides the critethat is used when generating all simulation images.

Do Not Compute Images When Best Ec/Io Below: This criteria specifies theminimum pilot Ec/Io value (in dB) accepted during the generation of any simulaimage. An image will not be computed for any of the bins that have an Ec/Io valuefalls below the specified level. This saves computation time by not calculating vafor bins which do not pass this test. A value of -23.75 dB is recommended (the filocking threshold) since there is no point in calculating values for bins whsubscribers can not possibly maintain a link.


Setting Simulator InputParameters - Site Level

Chapter

7
Table of Contents
7 - 3

7 - 37 - 57 - 8

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.2 Edit Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7.2.1 Antenna Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7.2.2 Carrier Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


7

Chapter 7: Setting Simulator Input Parameters - Site Level

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


7


ulatorampleniedndedsystem

hichtemncy)

enu

7.1 Overview

The accuracy and usefulness of running a simulation is dependent on setting the proper siminput parameters in NetPlan. This chapter addresses input values for the CDMA sites. Exfigures will be given of those input fields which pertain to CDMA site parameters, accompaby notes which may offer additional information on the input fields and some recommesettings for these fields. Some example values can be used directly while others are site orspecific.

The settings shown in the figures will be for a 13 kbps, 1.9 GHz CDMA system. The notes waccompany the input fields will also give values which correspond with other sysconfigurations (i.e. any combination of 8 kbps/13 kbps vocoder or 800 MHz/1.9 GHz frequewhen necessary.

7.2 Edit Site

Access to the “Edit Site” site editor window is gained via the main window Edit pull down m(see Figure 7-1: "Edit Site - Pull Down Menu").

Figure 7-1: Edit Site - Pull Down Menu


7


have

ea ofch asired

foreach

r thector.

roughas.

This action opens up the site editor window as seen in Figure 7-2: "Edit Site". Three areasbeen circled in this figure.

Figure 7-2: Edit Site

These three circled areas are described as follows:

Area A: Common Input - The area marked as “A” in the site editor window denotes the arcommon input. The inputs in this area must be defined. These include inputs suname, latitude, and longitude (Note: AMSL - Above Mean Sea Level is not a requfield).

Area B: Antenna Information - The area marked as “B” contains the Antenna informationthe site. The inputs in this area define the antenna information that is specific tosector.

Area C: Carrier Information - The area marked as “C” contains the Carrier information fosite. The inputs in this area define the carrier information that is specific to each se

The CDMA specific entries for a site are contained in Areas B and C, which are accessible ththe Antennas/Carriers tab. This chapter will focus on the input parameters in these two are

Area - ACommon Input

Area - BAntennaInformation

Area - CCarrierInformation


7


useration ass.

dow.tes arentries/

base.orts

ixedomd. For

tPlana for

ociated

7.2.1 Antenna Parameters

The antenna parameters portion of the site editor window ("Area B" in Figure 7-2) allows theto define the antenna parameters for each sector. These parameters include such informantenna hardware specifications, Geo Set information and specific CDMA technology field

The figures in this section will show the antenna parameters portion of the site editor winThese figures are accompanied by notes to explain each parameter in detail. The nopresented in the same order as the input fields appear in the site editor window. Some of the evalues will be unique to each sector (i.e. sector specific).

Figure 7-3: Edit Site Antenna Parameters - Area - B (view 1)

NOTES:

Note: 1. These input fields define the following antenna hardware specifications:

Sector numberAntenna number within sectorModel of antennaHeight of antenna center line (above ground level)Orientation of antenna (Bore Site)Degree of downtilt

Multiple antennas can be configured for a single sector within the NetPlan dataThe primary purpose for allowing multiple antennas is to handle a site which suppmultiple technologies that utilize different antennas for each technology. In a mtechnology system (i.e. CDMA & Analog), if the analog antennas are different frthe CDMA antennas for the same sector, then separate antennas must be defineexample, Sector 1, Antenna 1 may be an existing analog sector within the Nedatabase, while Sector 1, Antenna 2 could be added as a different CDMA antennthis same sector. The proper antenna must be selected when performing the asstechnology simulations.

1 2 3


7


ionctinge Edit

.

tion“Geo

menu

r

Figure 7-4: Selecting Parameter Sets and Geo Sets

Note: 2. Parameter Set- This field and ellipsis allow the user to select the proper propagatprediction model and resolution for the system under study (see Figure 7-4: "SeleParameter Sets and Geo Sets"). The “Parameter Set” can be created through thParameter Sets window accessed by the pull down menu Edit>Parameter Sets..1.

Note: 3. Geo Set- This field and ellipsis allow the user to select the proper Geo Set definifor the system (see Figure 7-4: "Selecting Parameter Sets and Geo Sets"). TheSet” can be created through the Edit Geo Set window accessed by the pull downEdit>Geo Sets...2.

1. Refer to Chapter 2 of the “NetPlan RF Engineering User’s Manual” for additional information on the otheparameters located within the Parameter Sets window.

2. Refer to Chapter 3 of this procedure for additional information on defining and saving a Geo Set.


7


"n bePS)

tivepleteinkts ineive

aser toPS

ISI

)"is ise

enheom all

t forturedB

n an.7 =

Figure 7-5: Edit Site Antenna Parameters - Area - B (view 2)

NOTES:

Note: 4. Analog Active / ERP (dBm) - The "Analog Active" button and the associated "ERPfields activate the analog technology for this sector’s antenna. These fields caaccessed only if the analysis is configured for an analog technology (such as AMthrough the Context interface (Configure>Context...). They define the EffecRadiated Power (ERP) of the analog antenna. Prior to performing a comdownlink and uplink CDMA simulation, NetPlan can be used along with the uplinformation for a CDMA system design to generate uplink analog coverage ploorder to perform a preliminary estimate of the CDMA system coverage. The recvoice "Rv" ERP is used for conducting these preliminary design steps for CDMAdiscussed in Chapter 4. To determine the proper settings for the "Rv" ERP, refSection 2.5. The transmit voice “Tv” ERP is often used to provide transmitted AMpower for the ISI Generation utility. See Appendix A7 for information regardinggeneration.

Note: 5. CDMA Active - This button activates the CDMA technology (i.e. the "Eff. Gn (dBdfield) for this sector’s antenna. This field can be accessed only if the analysconfigured for CDMA technology through the Context interfac(Configure>Context...).

Note: 6. Eff. Gn (dBd) - This field applies to the CDMA technology and becomes active whthe "CDMA Active" button is applied. This field defines the net effective gain of tsector antenna system. This includes the gain of the antenna and the losses frcabling and combining between the BTS frame and the antenna.

Additional attenuation must also be added to the sector effective gain to accounlog-normal shadowing loss. This assumes that the "Apply Lognormal Fading" feais disabled consistent with the recommendation found in Section 6.2.2.5. A 5.6value for log-normal shadowing loss is used in the link budget which is based o8.3 dB single cell shadow fade margin with a 2.7 dB soft handoff gain (i.e. 8.3 - 2

4 5 6 7


7


ation50%ore

gain,ain

ore thisor thel site.

userwillorarrierower

hesented in

es willtics ofby a

priate.

5.6 dB). The single cell shadow fade margin value is based on a Hata like propagmodel assuming a 40 dB/decade path loss slope, an 8 dB standard deviation withcorrelation, and providing approximately 95% area reliability (see Chapter 2 for minformation regarding shadow fade margins).

The value to enter into this field can be determined with the following equation:

Eff. Gn (dBd) = [Sector Ant. Gain (dBd)]- [Cable loss (dB)] - [Log-normal (dB)]

Assuming the following:Sector Antenna Gain. . . . . . . . . . . . . . . . . . 16.8 dBdCable Loss. . . . . . . . . . . . . . . . . . . . . . . . . . 3.0 dBdLog-normal Fading Margin. . . . . . . . . . . . . 5.6 dB

The effective gain would then be:Eff. Gn (dBd) = 16.8dBd - 3.0dB - 5.6dB = 8.2 dBd

Note: The accuracy of the simulation is enhanced when sector specific antennacable loss, and log-normal fading margin values are applied in the Effective Gcalculation.

Note: 7. Remote Antenna - This button and field activates the ability to define a sectantenna as being placed in a location other than where the site is located. To usfeature, the button is pressed and values for Latitude and Longitude are entered flocation of the remote antenna. This feature may be used to model speciahardware which allows a sector antenna to be located remotely from a base site

7.2.2 Carrier Parameters

The carrier parameters portion of the site editor window (“Area C” in Figure 7-2) allows theto define the carrier information for each sector of a site. This portion of the site editor windowdisplay CDMA specific fields if the analysis is configured for a CDMA technology (IS-95A/BIS-2000) through the Context interface (Configure>Context...). The parameters in the cparameters portion of the site editor include such information as carrier type and ID, psettings, soft handoff parameters, cell noise figure, ambient noise, and base chipset.

The figures in this section will show the carrier parameters portion of the site editor window. Tfigures are accompanied by notes to explain each parameter in detail. The notes are presethe same order as the input fields appear in the site editor window. Some of the entries/valube unique to each sector (i.e. sector specific). Values that represent physical characterisCDMA and Motorola equipment should not be altered unless otherwise directed to do soknowledgeable authority. The associated notes contain recommended values where appro


7


dis

thewilliersor,ryheing

areableffic

ion ison to

theenu

it.t thector/sitese, aer of

Figure 7-6: Edit Site Carrier Parameters - Area - C (view 1)

NOTES:

Note: 1. Carrier Type - This field identifies each carrier as Traffic, MAHHO (Mobile AssisteHard Handoff), or DAHHO (Database Assisted Hard Handoff). The carrier typeused during the creation of a Traffic Carrier Map Set (TCMS) to determine howtraffic is divided between the carriers. A sector that is identified as a traffic carrierreceive a full share of the traffic. For example, if a sector has two traffic carrassigned to it, the traffic will be divided evenly between them. A MAHHO sectused in a sector with a pilot beacon, will carry no traffic. A DAHHO sector will caronly a portion of the traffic. The exact portion of traffic that it carries is defined in tTCMS window when the TCMS is being generated. (Additional information regardcarrier types and TCMS can be found in Chapter 5.)

Note: 2. Carrier ID - This field assigns a specific carrier to a sector. The carriers thatavailable in the drop-down list correspond to the carriers listed in the Carrier T(Edit>Carrier Table...). The Carrier ID fields are used during the creation of a tramap to identify all sites and sectors that use a certain carrier. The carrier informatalso used during simulations to determine which sector and antenna informatiinclude. Only the site and sectors which correspond to the Carrier ID chosen inSimulation Model tab under the Configure>Simulation Parameters>CDMA... mselection will be used during simulations.

Note: 3. LPA (W) - This field defines the maximum power a sector is allowed to transmSystem design investigations require this field to be set much higher than whaBTS LPA hardware can support, in order to collect data points where the sedesires greater power. This enables the user to statistically show which sectorswill reach the limits of the LPA hardware and by how much. In the above examplvalue of 100 W is reasonable for a sector which has a real LPA average rated pow20 W.

1 2 3 4


7


hellowsrafficulatestem

re

wer.f the

Note: 4. OCNS (W) - This button activates the “Other Cell Noise Source” feature. Tassociated field assigns it a transmit power. The OCNS feature of the simulator aa sector to transmit energy which may be used to emulate a forward channel tload on an otherwise unloaded system. This energy may also be used to emuncorrelated transmitted energy from co-channel AMPS sites and adjacent syCDMA operators. Most studies do not require the use of this feature.


NOTES:

Note: 5. Auto Proportion - This field and ellipsis allow the user to select a NetPlan featuwhich automatically calculates values for:

Page (W)Sync (W)Min TCH (W)Max TCH (W)

These settings are based upon proportional relationships to the Pilot (W) poClicking upon the ellipsis offers 4 options. Their relationships as a percentage opilot power should be set up (using “npadmin”) to reflect the following:

75 6 8


7


theseuser

der.andync,theired

sthefornneln.

en a

ated

Note that although these selections may exist in NetPlan, they may not haveproportions associated with them. Before using the auto proportion field, theshould verify that these values are set up in npadmin.

RateSet1 is for the 8 kbps vocoder while RateSet2 is for the 13 kbps vocoActivating the Auto Proportion feature blanks the fields for Page, Sync, TCH MinTCH Max. Entering a value for the Pilot power results in the values for Page, STCH Min and TCH Max being automatically calculated and assigned. LeavingAuto Proportion field empty (de-activated) allows the user to enter any power desinto the Pilot, Page, Sync, TCH Min and TCH Max fields.

Note: 6. Pilot, Page, Sync, TCH Min , andTCH Max - These fields define the power settingand TCH boundaries for these CDMA channel parameters. Most often, utilizingauto proportion feature (see Note: 5) and entering only the pilot power will sufficemaintaining these values. Under certain conditions, the ratios of the various chapowers to the Pilot power should be altered to ensure acceptable sector operatio

The following recommendations for Page and Sync settings may be used whsector is subject to excessive ISI interference:

A paging rate of 9600 is required when Short Messaging Service (SMS) is activfor the system.

Table 7-1: Auto Proportion Settings (% of Pilot Power)

Selection Page Sync TCH Min TCH Max

RateSet1_Page4800 40 10 2 75

RateSet1_Page9600 75 10 2 75

RateSet2_Page4800 40 10 2 126

RateSet2_Page9600 75 10 2 126

Table 7-2: Page and Sync Settings Used With ISI Problems (% of Pilot Power)

Field RateSet1 RateSet2

Page (9600) 100 100

Page (4800) 50 50

Sync 10 10


7


as am:

power

rrieraconwertion.

berr amostation.

oftto be7-7doff

d toOPthefilter

. Thisithto be

by

seden infling,m therough

The following recommendations for Page, Sync, TCH Min and TCH Max settingspercentage of the pilot power may be used when designing an IS-2000 1X syste

When designing a system that uses a Quick Paging Channel (QPCH), the pageshould be increased by 5% per Paging channel associated with the QPCH.

The use of a pilot beacon at a site requires a reduced pilot setting for the caassociated with this pilot beacon. It is usually recommended that the pilot becarrier be set 10 dB below the traffic carriers at that site. The actual pilot posettings to be used in the field will be dependent on the pilot beacon configuraThe pilot beacon carriers are assigned a carrier type of MAHHO (see Note 1).

Note: 7. T-ADD (dB) - This field defines the decision threshold for determining subscriconnectivity to the CDMA system. At least one pilot must be above T-ADD fosubscriber to connect. The value shown in Figure 7-7 is the accepted norm forsituations. It may be changed if access and soft handoff performance needs alter

Note: 8. T-DROP (dB) - This field defines the decision threshold for determining the shandoff status of a subscriber connected to the CDMA system. Pilots are eligibleused for soft handoff links if they are above T-DROP. The value shown in Figureis the accepted norm for most situations. It may be changed if soft hanperformance needs alteration.

The simulator usage of T-ADD and T-DROP thresholds should be manipulateadjust the size of the SHO region of a given system. This results in T-ADD/T-DRvalues which do not necessarily reflect the typical values that would be used inactual operational system. In a real system, the hysteresis created by timers andconstants of the dynamic process alter the soft handoff performance achievedeffect occurs when a given set of T-ADD/T-DROP thresholds, in conjunction wRayleigh fading and lognormal shadowing, cause the Soft/Softer handoff regionslarger than what would be predicted by the simulator. The simulator functionscomparing average pilot Ec/Io to the fixed T-ADD/T-DROP thresholds alone.

When determining the T-ADD, T-DROP, T-TDROP, T-COMP thresholds to be uin the field, one must account for the dynamics of these factors, which are not sea static simulator (hysteresis, fading, message delays, handoff mode, pilot shufcomplex handoffs, hard handoff, etc.). These parameters should be obtained frorecommended default parameters. Then, if necessary, they should be modified thsome field optimization procedure.

Table 7-3: IS-2000 Power Settings (% of Pilot Power)

Page Sync TCH Min TCH Max

IS-2000 1X 75 10 8 63


7


erA

alueer

ofterOP)fieldOP

factor

field,ill

ithmpilot

A starting point for assigning field values is to set the field T-ADD value 2 dB highthan the simulator T-ADD value. Conversely, when modeling an existing CDMsystem with the simulator, the system designer should set the simulation T-ADD v2 dB lower than the field T-ADD value and the simulation T-DROP value 4 dB lowthan the field T-ADD value.

A system designer should try to achieve a desired fraction of subscribers in soft/shandoff by manipulating the T-ADD/T-DROP thresholds. Do not use the MAHHfield settings in the static simulator nor the static simulator SHO (T-ADD/T-DROsettings in the field. The common parameter between the static simulator and theis the soft handoff factor as defined/discussed in Chapter 9. The T-ADD/T-DRthresholds used in the simulator should be set to obtain a desired soft handoff(the same soft handoff factor that is desired in the field).


NOTES:

Note: 9. The IS-95B soft handoff parameters are set through these four fields. The first95B SHO, identifies whether the IS-95B/IS-2000 soft handoff (SHO) algorithm wbe used for this sector during simulations. The IS-95B/IS-2000 soft handoff algorattempts to dynamically reject excess soft handoffs based on the current activeset of the subscriber unit.

9 10 11 12


7


e theent

opswss theser-heset). A

HOSHOSHOdlessn tosoftHO

5B/with

Prease-95Bom

to-32

torom

eters

thetc.)theseent.

When an IS-95A subscriber unit measures a pilot strength value that is abovT-ADD threshold value, it adds that pilot to its active pilot set. When the measuremis below the T-DROP threshold value for a predefined duration (T-TDROP), it drthe pilot from its active pilot set. The IS-95B soft handoff algorithm, however, allothe ADD and DROP thresholds to be calculated dynamically. This algorithm useaggregate signal strength of the pilots in the active set in conjunction with three udefinable parameters to calculate the dynamic ADD and DROP thresholds. Tthree parameters are Soft Slope, Add Intcpt (intercept), and Drop Intcpt (intercepseparate dynamic DROP threshold is calculated for each pilot in the active set.

95B SHO - This toggle button should be selected to enable the IS-95B/IS-2000 Salgorithm. This should only be used in systems that have the IS-95B/IS-2000feature in use. Please note that if this button is selected, the IS-95B/IS-2000algorithm will be used for ALL subscribers that are assigned to this sector, regarof whether they are IS-95B subscribers or not. There is currently no way in NetPladesignate a class of subscribers as being either IS-95A or IS-95B/IS-2000 from ahandoff perspective. Any subscriber that is served by a sector will use the Salgorithm dictated by this toggle button. For a system with both IS-95A and IS-9IS-2000 subscribers, the RF engineer may wish to perform a set of simulationsand without this toggle set to gain an appreciation of the differences.

Soft Slope- The soft slope value is used in calculations for both ADD and DROthresholds. As the soft slope value increases, the ADD and DROP thresholds incand the IS-95B soft handoff region increases. A higher value tends to make ISsoft handoffs act more like IS-95A soft handoffs. The value for this field ranges fr1 to 63. The recommended value for this parameter is 18.

Add Intcpt - This value is used to dynamically calculate the ADD thresholdsdetermine when to add a pilot to the active set. The value for this field ranges fromto 31 dB. The recommended value for this parameter is 6.

Drop Intcpt - This value is used to dynamically calculate the DROP thresholdsdetermine when to drop a pilot from the active set. The value for this field ranges f-32 to 31 dB. The recommended value for this parameter is 6.

(The recommended values for the Soft Slope, Add Intcpt, and Drop Intcpt paramcorrespond with the recommended default settings used in the field.)

Note: 10. Cell NF (dB) - This field defines the cell noise figure. Site specific receive paconfigurations (e.g. shared receiver multi-coupler, losses, Tower Top Amplifiers,may impact the cell noise figure on a per site basis. This entry must account fordifferences. A value of 6 dB to 7 dB is recommended for most equipmconfigurations. Refer to the specific BTS specifications for more accurate values


7


ineter

ise

sis.basision

he userat is

ntainystemat thet the

, the

site/ns forthe

orportfieldilizesetSCair

field).

ity

ase 2y the

the

Note: 11. Amb. No (dB) -This field defines the environmental noise (ambient) which isexcess of the thermal noise (kTB) for the sector. The normal value for this paramis 0 dB at 1.9 GHz and 2.0 dB at 800 MHz. These values may differ if nomeasurements have been made at the prospective sites.

Note: 12. Base Chipset- This field allows the user to define the chipset on a per-antenna baPrior to NetPlan Version 4.0, the base chipset could only be set on a system(from the CDMA Parameters interface). However, beginning with NetPlan Vers4.0, the chipset can be set either on a system basis or on a per-antenna basis. If tdoes not define the chipset for an antenna, the simulator will use the chipset thdefined for the system level in the CDMA Parameters interface.

This field is useful when a system has a variety of BTS equipment types that codifferent chipsets. In such a system, the most predominant chipset used in the scan be set at the system level (see Chapter 6 for details on setting the chipsetsystem level). The per antenna chipset field can then be used to correctly sechipset for any sites which do not use the most prevalent chipset. (Alternativelychipset can be set for each antenna in the system.)

This field allows the user to define the actual chipset that is used at a particularsector in order to best model the BTS equipment in the system. The chipset optiothis field include Default (which directs the simulator to use the setting fromCDMA Parameters interface), EMAXX, Phase 1 (BSM) and Phase 2 (CSMMAXX). Note that the CSM5000 chipset, which is used in base stations that supIS-2000, is not an option for this field. This is because NetPlan does not use thisfor IS-2000. However, the BTS products that support the IS-2000 air interface utMCC cards with either the EMAXX or CSM5000 chipset. The CSM5000 chipsupports IS-2000 users, while the EMAXX chipset supports IS-95 users. (With CBrelease R16.1, the CSM5000 chipset will support both the IS-95 and IS-2000interfaces.) Therefore, for an IS-2000 sector-carrier, it is recommended that thisbe set to EMAXX (or set to Default if the system level setting is set as EMAXXSetting this field to EMAXX for an IS-2000 sector-carrier allows for the possibilthat a mixture of IS-95 and IS-2000 users will be served by this sector-carrier

Also, note that the Phase 2 CSM and the CSM5000 are different chipsets. The PhCSM only supports the IS-95 air interface, whereas, the CSM5000 supports onlIS-2000 air interface in CBSC release R16.0. (With CBSC release R16.1,CSM5000 chipset will support both the IS-95 and IS-2000 air interfaces).


7


_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


Simulator Path LossCreation

Chapter

8
Table of Contents
8 - 3

- 3

4

- 5

8

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.2 NetPlan Path Loss File Creation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

8.3 NetPlan Path Loss (CDMA Antenna Gain) Image Display . . . . . . . . . 8 -

8.4 Creating an Exclusion Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

8.5 Application of Exclusion Mask for Generating Images . . . . . . . . . . . . 8 -


8

Chapter 8: Simulator Path Loss Creation

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


8


eragerageey doThis, Sync

with

e ad. Allen noerent

seemss thetion -ain

tennaeters -en tog withee (360

8.1 Overview

The creation of path loss for use by the simulator portion of NetPlan is separate from the covstudy involving only the maximum allowable path loss conducted in Chapter 4 “Verify Coveand Identify Problem Areas”. No transmitted signal power is used to create these files so thnot contain power levels (dBm) for the grid locations as an analog propagation file would.means that during the simulation phase of a CDMA design, the power settings for Pilot, Pageand Traffic channels can be changed without prompting a path loss recalculation.

The CDMA Antenna Gain images or loss files (namedSystem-Name/Site-Name/Loss_Sector-#_Antenna-#_version-#) take into account:

• Effective gain (antenna gain + cable loss + fade margin)

• Antenna pattern

• Antenna height

• Antenna downtilt

• Antenna bearing

• Propagation model elements such as terrain and clutter

Altering any of the above antenna items will automatically trigger a path loss recalculationsubsequent simulation runs.

8.2 NetPlan Path Loss File Creation

The creation of the path loss files for the simulation will automatically occur the first timsimulation run is made for a new cell site/antenna or when an existing site/antenna is modifiesubsequent runs of the simulator will not re-calculate the path loss files if there has bealteration to the antennas (model, orientation, downtilt, height, new antenna/site, diffpropagation model, altered propagation extents).

The user may create the loss files without running a simulation, though the step maysuperfluous. To create the CDMA Antenna Gain images without running a simulation, acceImage Creator interface from the main NetPlan window (Images>Create>Site PropagaCDMA Antenna Gain). For further information regarding generation of the CDMA Antenna Gimages, please see the “NetPlan CDMA Static System Simulator User’s Guide”.

The CDMA Site and Antenna input data must first be entered through the edit site and edit anmenus. These relevant entries are covered in Chapter 7, “Setting Simulator Input ParamSite”. The use of the proper clutter/morphology file should be verified. Care should be takensure the proper path loss model (800 MHz vs. 1.9 GHz, Xlos, Hata, etc.) is selected alona resolution of 100 meters or less. The path loss should be created using radials every 1 degrradials).


8


e. Theagesp awillDMA

t theCDMA

8.3 NetPlan Path Loss (CDMA Antenna Gain) Image Display

The path loss files (CDMA Antenna Gain images) can be viewed one antenna/sector at a timimages are accessed via the “Display” window which is brought up by pulling down the Immenu and selecting Display (Images>Display). Activating the “All Images” button will bring ulist of all images associated with the CDMA Simulation Analysis. The top entries on this listbe the loss files for each antenna/sector within the system. These files start with the title “CAntenna Gain <file path> site No.[site version No.] / sector No./ antenna No.”See Figure 8-1:"Display CDMA Path Loss Images".

Figure 8-1: Display CDMA Path Loss Images

The images produced will look similar to analog site propagation files with the exception thadata contained in the bins represents adjusted dB path loss and not dBm (see Figure 8-2: "Antenna Gain Image").


8


by thef theot meet

y theuch aspathfiles,

Figure 8-2: CDMA Antenna Gain Image

The path loss files should be inspected to verify that reasonable results were calculatedprediction tool. All the inputs which affect an analog propagation study (with the exception oantenna ERP) apply to the creation of these files and are suspect if the achieved results do nreasonable expectations.

8.4 Creating an Exclusion Mask

An exclusion mask can be applied to the simulator output images which are created bsampling of the probe subscriber. For example, a mask can be used to exclude areas smountain ridges. Exclusion masks are not used for the creation of “CDMA Antenna Gain”loss files. The selection of an exclusion mask will not prompt the regeneration of the path lossthough it will cause CDMA simulation images to be marked out of date.


8


cribermaskositeitewaterwater

roppedent iseedage

s are alllusion

alletthe

The selected mask will only affect the simulator images by controlling where the probe subsis able to make acceptable links. Any image created by the simulator will take this exclusioninto account (individual mesh images such as Ec/Io, SHO, etc., as well as CDMA compimages). This mask will also affect the “Reliability File” calculations for CDMA composcoverage images. For example, if a mask is not used with a system next to a large body of(given no intention to provide coverage over the water), the areas of good coverage over thewill be included in the percent area reliability numbers and thus will skew the results.

The use of this mask in generating simulator images does not affect the placement of the dsubscribers and therefore will not affect system statistics. Control of subscriber placemachieved through the use of the Traffic Map (see Section 5 “Traffic (Distribution) and SpMaps”). If the same exclusion mask is used for both the traffic distribution map and the imgeneration, then the images, placement of the dropped subscribers and the system statisticaffected. However, the exclusion mask used for the generation of the traffic map and the excmask used during CDMA image generation need not be the same.

An exclusion mask is created within NetPlan via the exclusion mask icon in the Tools Pwindow. The Tools Pallet window is opened by clicking on the Tools Icon “wrench” alongright edge of the main NetPlan window (see Figure 8-3: "Creating Exclusion Mask").


8


es inask

ush”ave As

Figure 8-3: Creating Exclusion Mask

Clicking the tools icon opens the Tools Palette. Click on the Exclusion Mask button. Click ythe displayed warning box, then set the resolution to 100m and click “OK” in the Exclusion MResolution window. The Exclusion Mask window will appear, where an appropriate “paint bris selected for painting the mask. When completed, the mask can be saved using the File>Smenu selection from the Exclusion Mask window.

Start


8


clusionsplayy thesion

8.5 Application of Exclusion Mask for Generating Images

Once a mask has been created, it can be applied to the simulator images by selecting the exmask for use with the analysis. This is accomplished by clicking on the Layers button to dithe Layers window. From the Layers window, select the Exclusion Mask ellipses to displaExclusion Mask window. Click on the Exclusion Mask button to display the Select ExcluMask window, where the desired Exclusion Mask can be chosen. (See Figure 8-4).

Figure 8-4: Select Exclusion Mask


NetPlan CDMASimulator StatisticalOutput and Analysis

Chapter

9
Table of Contents
9 - 3

9 - 3 - 4 - 4 - 5 - 5 - 6- 6 - 79 - 7

9 - 7

9 - 7

9 - 9

- 15 - 17 28- 30 - 32

- 34 - 389 - 41 43- 44 - 519 - 53 - 54 - 55 - 55 - 59 - 61 - 64 - 67 - 69 - 72 - 75 - 76 - 76 - 77

9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.2 NetPlan Statistics Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.2.1 CellStat_XX (IS-95 and IS-2000 1X non time-sliced) . . . . . . . . 99.2.2 MobileStat_XX (IS-95 and IS-2000 1X non time-sliced). . . . . . 99.2.3 CellStatTS_XX and CellStatTSRev_XX (IS-2000 1X time-sliced) 99.2.4 MobileStatTS_XX (IS-2000 1X time-sliced) . . . . . . . . . . . . . . . 99.2.5 SectorTputStat_XX (IS-2000 1X time-sliced) . . . . . . . . . . . . . . 99.2.6 MobileTputStat_XX (IS-2000 1X time-sliced). . . . . . . . . . . . . . 9 9.2.7 GlobalStatTS_XX (IS-2000 1X time-sliced) . . . . . . . . . . . . . . . 99.2.8 SectorMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.2.9 CallModelMap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.3 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.4 Data Graph Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.5 Statistical Analysis Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.1 NetPlan Raw Statistics Definitions . . . . . . . . . . . . . . . . . . . . . . . 99.5.2 IS-2000 1X Time-Sliced Simulation Warm-up Time . . . . . . . . . 9 -9.5.3 IS-2000 1X Time-Sliced Simulation Length. . . . . . . . . . . . . . . . 9 9.5.4 RF Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.4.1 RF Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.4.2 Walsh Code Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.4.3 Reverse Noise Rise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.4.4 FWD & REV Subscriber Class FER Distribution . . . . . . . . . . . . . 9 -9.5.4.5 Soft Handoff Factor and Soft + Softer Handoff Factor . . . . . . . . . 9 9.5.4.6 Pilot Ior/Ec Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.4.7 Reverse Saturation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.4.8 Blocked Mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.5 RF Voice and Data Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.1 Total Erlangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.2 Active Erlangs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.3 Bursting Erlangs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.4 End User Throughput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.5 Sector Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.6 Effective Sector Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.7 Data Rate Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.5.8 High Speed Channel Request Failure Probability . . . . . . . . . . . . . 99.5.5.9 SCH Limit Flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.6 Data Call Model Characterization . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.1 Think Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


9

Chapter 9: NetPlan CDMA Simulator Statistical Output and Analysis

- 789 - 79

- 79 - 80- 80 - 81- 81 - 81 - 81 - 82 - 84

9 - 86 - 87 - 88

- 97 - 98 - 98

- 99- 101- 103 - 104 - 104 - 106

9.5.6.2 Download Size and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.3 Reverse Request Size and Time. . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.6.4 Forward Data Activity Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.5 Reverse Data Activity Factor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.6 Probability of Going Dormant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.6.7 Length of the Dormant Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.6.8 Think Time While Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.6.9 Fraction of Data Subscribers Who are Dormant . . . . . . . . . . . . . . . 9

9.5.7 Simulation Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.7.1 Subscriber Speed Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

9.5.8 Channel Card Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.8.1 General Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9.5.8.2 IS-95A Channel Card Determination . . . . . . . . . . . . . . . . . . . . . . . 99.5.8.3 IS-2000 High Speed Packet Data Channel Card Determination . . . 9

9.5.9 Power Amplifier Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.9.1 PA Equipment Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.9.2 Simulator Power Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.9.3 CDMA Signal Power Distribution Characteristics . . . . . . . . . . . . . 9 9.5.9.4 Comparing Power Requirements to BTS Specifications. . . . . . . . . 9

9.5.10 IS-2000 Backhaul Sizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.5.10.1 General Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99.5.10.2 IS-2000 Packet Pipe Size Determination. . . . . . . . . . . . . . . . . . . . . 99.5.10.3 Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


9


theseonly

design.ter 11,site

tep oftep iso arrivell andually

createed iftistics

ddedplexisticaleatistical

sed totisticalr to thethe

9.1 Overview

The NetPlan CDMA Simulator has the ability to generate many statistics. The analysis ofstatistics is essential to determining if a design is operating properly. However, statisticsprovide one measure of the system design and taken alone do not validate a good systemRF Coverage must also be validated through the use of images as described in Chap“NetPlan Simulator Images Output and Analysis” and Chapter 13, “NetPlan CDMA Compoand Statistical Images - Coverage vs. Path Loss”.

The NetPlan CDMA Simulator creates statistical outputs and images in two steps. The first sa simulation run is the placement of “dropped” subscribers into the simulation space. This salways run. Once the dropped subscribers are placed, the simulator goes through iterations tat all their forward and reverse link powers and soft handoff states. It then records the cemobile statistics in separate files. These statistics files are then available for analysis individor for the entire Monte Carlo run.

The second step of a simulation run is the creation of the images. It is not necessary toimages when only statistical output is desired. A faster run time for the simulation is achievthe images are not created. The creation of images does not impact Cell/Mobile stainformation gathered in the first step.

Simple analysis can be performed directly on the Cell/Mobile statistical data using the imbestatistical graphing tool “Data Graph” (see Section 9.4: "Data Graph Tool"). For more comdata analysis and manipulation, the ASCII data files can be used with an external statsoftware package, such asJMP™ or BBN/Cornerstone™. Each of the statistics should bpresented via graphs and may deserve statistical tables, which are possible with these stsoftware packages.

9.2 NetPlan Statistics Files

The NetPlan CDMA Simulator generates a number of statistics files that can be post procesproduce the RF system design metrics. The NetPlan statistics files which are used in the staanalysis procedures that are described in this chapter are summarized in Table 9-1. Refe“NetPlan CDMA Simulator User’s Manual” for a complete listing of the NetPlan files andstatistics contained within each of these files.

Table 9-1: NetPlan Statistics Files

Statistics File Simulator

CellStat_XX IS-95 and IS-2000 1X non time-slicedMobileStat_XX IS-95 and IS-2000 1X non time-slicedCellStatTS_XX IS-2000 1X time-sliced (forward link)CellStatTSRev_XX IS-2000 1X time-sliced (reverse link)MobileStatTS_XX IS-2000 1X time-slicedSectorTputStat_XX IS-2000 1X time-sliced


9


ltingalwaysrun.

f thesub-le

eralhannels4, andMAion

ports")med

lting

or Npath:ch

esmentalental

Planion

9.2.1 CellStat_XX (IS-95 and IS-2000 1X non time-sliced)

CellStat_XX is the output file which contains data relative to the system/sectors/cells resufrom the links established between the cell sites and the dropped subscribers. The simulatorruns in a Monte-Carlo mode which implies multiple drops were enacted during the simulationThe XX in the name is replaced by the drop number. One file is created for each “drop” osimulation run (for N drops, numbered 1 through N). These output files are placed in adirectory (path:Analysis_Name/CDMA_DROP/CellStat). One line of statistics is placed in the fifor each sector within the system.

When running IS-2000 1X non time-sliced simulations, the CellStat_XX file provides sevstatistics that have separate entries for the fundamental channel (FCH) and supplemental c(SCH). Some statistics are further subdivided by data rate and radio configuration (RC3, RCRC5). Refer to Table 9-3, “Raw Statistics Definitions,” on page 9 - 17 and to the “NetPlan CDSimulator User’s Manual” for a complete listing of IS-2000 1X non time-sliced simulatstatistics.

The data from each drop can be studied separately or the “Reports” feature (Section 9.3, "Recan be used to combine all the CellStat_XX files into one file. The combined file is typically naCellStat_All.

9.2.2 MobileStat_XX (IS-95 and IS-2000 1X non time-sliced)

MobileStat_XX is the output file which contains data relative to the dropped subscribers resufrom the links established between the cell sites and the dropped subscribers. TheXX in the nameis replaced by the drop number. One file is created for each “drop” of the simulation run (fdrops, numbered 1 through N). These output files are placed in a sub-directory (Analysis_Name/CDMA_DROP/MobileStat). One line of statistics is recorded in the file for easubscriber in the system for that drop.

When running IS-2000 1X non time-sliced simulations, the MobileStat_XX file providinformation specific to the supplemental channel such as the requested and received supplechannel data rate, FER for the supplemental channel, and Eb/No information for the supplemchannel. Refer to Table 9-3, “Raw Statistics Definitions,” on page 9 - 17 and to the “NetCDMA Simulator User’s Manual” for a complete listing of IS-2000 1X non time-sliced simulatstatistics.

MobileTputStat_XX IS-2000 1X time-slicedGlobalStatTS_XX IS-2000 1X time-sliced (forward link)SectorMap IS-2000 1X time-sliced and non time-slicedCallModelMap IS-2000 1X time-sliced and non time-sliced

Table 9-1: NetPlan Statistics Files

Statistics File Simulator


9


ports")ally

2.1,XXveryinto

neTheath:

me,rs, and

file, andfile

l. Refertor

and

noarate

ionrom

Xs inareata

ps,path:

The data from each drop can be studied separately or the “Reports” feature (Section 9.3, "Recan be used to combine all the MobileStat_XX files into one file. The combined file is typicnamed MobileStat_All.

9.2.3 CellStatTS_XX and CellStatTSRev_XX (IS-2000 1X time-sliced)

CellStatTS_XX is the IS-2000 1X time-sliced simulation version of CellStat_XX (Section 9."CellStat_XX (IS-95 and IS-2000 1X non time-sliced)"). All of the statistics in the CellStat_file are included in the CellStatTS_XX file; however, the statistics are logged to the file for etime-slice. The forward and reverse link time-sliced cell statistics are separatedCellStatTS_XX and CellStatTSRev_XX. TheXX in the name is replaced by the drop number. Ofile is created for each “drop” of the simulation run (for N drops, numbered 1 through N).CellStatTS_XX and CellStatTSRev_XX output files are placed in a sub-directory (pAnalysis_Name/CDMA_DROP/CellStatTS).

Statistics that are unique to the “TS” version of the CellStat_XX file include frame end tinumber of data subscribers who were actively bursting data, number of dormant subscribea peg for high speed channel request failures. The “TSRev” version of the CellStat_XXseparately logs reverse link statistics for the number of mobiles, number of good mobilesnumber of mobiles who were actively bursting data. Also included in the CellStatTSRev_XXis a statistic for the number of channel elements used on the reverse supplemental channeto Table 9-3, “Raw Statistics Definitions,” on page 9 - 17 and to the “NetPlan CDMA SimulaUser’s Manual” for a complete listing of statistics contained in the CellStatTS_XXCellStatTSRev_XX files.

Due to the size of the time-sliced CellStatTS_XX and CellStatTSRev_XX files, there is“Reports” feature (Section 9.3, "Reports") available to combine the files across drops. A sepPerl script named “canal.pl” (refer to Appendix A6 “Running canal.pl” for additional informaton this script) is used to analyze the individual CellStatTS _XX and CellStatTSRev_XX files feach drop.

9.2.4 MobileStatTS_XX (IS-2000 1X time-sliced)

MobileStatTS_XX is the IS-2000 1X time-sliced simulation version of MobileStat_X(Section 9.2.2, "MobileStat_XX (IS-95 and IS-2000 1X non time-sliced)"). All of the statisticthe MobileStat_XX file are included in the MobileStatTS_XX file; however, the statisticslogged to the file for every time-slice. The MobileStatTS_XX file only includes statistics for dsubscribers who were actively bursting data during the time-slice. TheXX in the name is replacedby the drop number. One file is created for each “drop” of the simulation run (for N dronumbered 1 through N). The MobileStatTS_XX output files are placed in a sub-directory (Analysis_Name/CDMA_DROP/MobileStatTS).


9


vicee 9-3,al”

turedualsheet

datan theectored 1

erseticslete

tureamedis

atafile

rtinentervingtheser

, andd forlaced,al”

tureamedis

Statistics that are unique to the “TS” version of the MobileStat_XX file include the data sertype, the state of the subscriber within the call model, and the system time. Refer to Tabl“Raw Statistics Definitions,” on page 9 - 17 and to the “NetPlan CDMA Simulator User’s Manufor a complete listing of statistics contained in the MobileStatTS_XX file.

Due to the size of the time-sliced MobileStatTS_XX files, there is no “Reports” fea(Section 9.3, "Reports") available to combine the files across drops. The indiviMobileStatTS_XX files can be analyzed separately by importing them into a suitable spreador statistical analysis tool.

9.2.5 SectorTputStat_XX (IS-2000 1X time-sliced)

SectorTputStat_XX is an IS-2000 1X time-sliced simulation output file that containsthroughput information from a cell/sector perspective. The primary use for the statistics iSectorTputStat_XX file is to calculate the sector throughput statistic (Section 9.5.5.5, "SThroughput"). One file is created for each drop of the simulation run (for N drops, numberthrough N). These output files are placed in a sub-directory (path:Analysis_Name/CDMA_DROP/SectorTputStat). One line of statistics for the forward link and one line of statistics for the revlink is placed in the file per second of simulation time. Refer to Table 9-3, “Raw StatisDefinitions,” on page 9 - 17 and to the “NetPlan CDMA Simulator User’s Manual” for a complisting of statistics contained in the SectorTputStat_XX file.

Due to the size of the time-sliced SectorTputStat_XX files, there is no “Reports” fea(Section 9.3, "Reports") available to combine the files across drops. A separate Perl script n“canal.pl” (refer to Appendix A6 “Running canal.pl” for additional information on this script)used to analyze the individual SectorTputStat_XX files from each drop.

9.2.6 MobileTputStat_XX (IS-2000 1X time-sliced)

MobileTputStat_XX is an IS-2000 1X time-sliced simulation output file that contains dthroughput information from a subscriber perspective. One line of statistics is written to theeach time that a subscriber changes source model states within the data call model. Peinformation such as duration in the expiring source model state, bytes transferred, and best ssector index are logged in the MobileTputStat_XX file. The primary uses for the data inMobileTputStat_XX file are to calculate end user throughput (Section 9.5.5.4, "End UThroughput"), effective sector throughput (Section 9.5.5.6, "Effective Sector Throughput")call model statistics (Section 9.5.6, "Data Call Model Characterization"). One file is createeach drop of the simulation run (for N drops, numbered 1 through N). These output files are pin a sub-directory (path:Analysis_Name/CDMA_DROP/MobileTputStat). Refer to Table 9-3“Raw Statistics Definitions,” on page 9 - 17 and to the “NetPlan CDMA Simulator User’s Manufor a complete listing of statistics contained in the MobileTputStat_XX file.

Due to the size of the time-sliced MobileTputStat_XX files, there is no “Reports” fea(Section 9.3, "Reports") available to combine the files across drops. A separate Perl script n“canal.pl” (refer to Appendix A6 “Running canal.pl” for additional information on this script)used to analyze the individual MobileTputStat_XX files from each drop.


9


perthe

ctorsis

Theath:

ysisicedandd in

2000e”.

e inelyry

dataPlan

dropn areenteredles as

.pl”isticsfiles

enuthe

9.2.7 GlobalStatTS_XX (IS-2000 1X time-sliced)

GlobalStatTS_XX and GlobalStatTSRev_XX provide system-wide summary informationtime-slice. Unlike the CellStatTS_XX files, which separately log statistics for each sector insystem, the GlobalStatTS_XX and GlobalStatTSRev_XX files provides one statistic for all secombined together per time-slice. TheXX in the name is replaced by the drop number. One filecreated for each “drop” of the simulation run (for N drops, numbered 1 through N).GlobalStatTS_XX and GlobalStatTSRev_XX output files are placed in a sub-directory (pAnalysis_Name/CDMA_DROP/GlobalStatTS).

The primary use of the GlobalStatTS_XX file in IS-2000 1X time-sliced simulation is the analof simulation warm-up time, which is discussed further in Section 9.5.2, "IS-2000 1X Time-SlSimulation Warm-up Time". Refer to Table 9-3, “Raw Statistics Definitions,” on page 9 - 17to the “NetPlan CDMA Simulator User’s Manual” for a complete listing of statistics containethe GlobalStatTS_XX and GlobalStatTSRev_XX files.

9.2.8 SectorMap

SectorMap provides a mapping of the sector index (number) to the cell name in all of the IS-1X statistics files. There are only two columns in this file, namely “SectorIndex” and “CellNamThis output file is placed in a sub-directory (path:Analysis_Name/CDMA).

9.2.9 CallModelMap

CallModelMap provides a mapping of the “CallModelIndex” to the call model and service typall of the IS-2000 1X statistics files. There are only three columns in this file, nam“CallModelIndex”, “CallModel”, and “ServiceType”. This output file is placed in a sub-directo(path:Analysis_Name/CDMA).

9.3 Reports

There are a number of statistics files generated by NetPlan, with each file typically containingfor one Monte Carlo drop. For IS-95 and IS-2000 1X non time-sliced simulations, Netprovides a statistical report that combines all of these separate files from each Monte Carlointo contiguous files for post processing analysis. The individual drops per Monte Carlo runamed using the drop number as the suffix, whereas the names for the contiguous files areby the user when creating the files. A suggested convention is to name the combined fiCellStat_All and MobileStat_All.

For IS-2000 1X time-sliced simulations, the “canal.pl” (refer to Appendix A6 “Running canalfor additional information on this script) Perl script is used to post process the individual statfiles from each drop. The “Reports” feature is not available for the time-sliced statisticsbecause the concatenated files become too large to manage.

The statistical report generator is accessed within NetPlan through the pull down mReports>CDMA Statistics. This opens up the “Get CDMA Statistics” window which allows


9


ell and
user to select the analysis of interest and specify the path and names for the combined CMobile statistics output files (see Figure 9-1).
Figure 9-1: Reports - CDMA Statistics


9


It isGraph

This(see

9.4 Data Graph Tool

A simple statistical graphing tool, “Data Graph”, is available from the main NetPlan window.accessed via the pull down menu Tools>Data Graph. This opens up the main NetPlan Datawindow where the graphs will be displayed (see Figure 9-2).

Figure 9-2: Open Data Graph

The statistical file of interest is then selected via the Data Graph pull down menu File>Load.opens up the “Load Graph Data” window and the “File” ellipsis is pressed to find the data file,Figure 9-3).


9


ataphse Xee tool.

Figure 9-3: Load Data File

Upon choosing a file and pressing “OK”, the “File” window will close and the names of the dcolumns from the selected file will appear in the “Load Graph Data” window. As most graproduced for CDMA simulation studies are X versus Y with the cell/sector number being thaxis, the following examples will reflect this use for plotting data from a CellStat_All file (sFigure 9-4). Statistics from the MobileStat_All file can also be plotted using the Data Graph


9


xis

eachr the

ndll the

thethedata

ess.)

close

Figure 9-4: Select Graph Data

NOTES:

Note: 1 Select the data column which the graph is intended to show on the Y axis.

Note: 2 Click on the “X-Axis” button and select “CellName” as the column to use for the X aof the graph.

Note: 3 Click on the “Average” button to activate the calculation of the average values forcell/sector. The Data Graph tool will average the values for each cell/sector ovemultiple Monte Carlo drops.

Note: 4 Click on the “Min Max” button to display a vertical line for each cell/sector. The top abottom end of these lines represent the maximum value and minimum value of adata points available for the cell/sector. (This choice is a compromise to usingScatter plot option which would show all the data points and give an indication ofdistribution over the entire Monte Carlo run. Unfortunately, connecting the averagepoints in a scatter plot also connects all the data points and makes the graph usel

Once the appropriate selections are made, press “OK”. The “Load Graph Data” window willand a graph will appear in the “NetPlan Data Graph” window (see Figure 9-5).

1 2 3 4


9


indowu. Theies (seeertiesugh

Figure 9-5: Graph - 1

The size and resolution of the graph can be changed by resizing the NetPlan Data Graph wwith the mouse. The appearance of the graph can be altered through the “Properties” menProperties menu can be accessed via the NetPlan Data Graph pull down menu Edit>PropertFigure 9-6). This opens up the “NetPlan Graph Properties” window. There are many propwhich can be set via this window, only a few will be mentioned here (refer to Figure 9-7 throFigure 9-10). It is up to the user to familiarize themselves with the tool’s features.

Figure 9-6: Open Properties


9


rties, and

apherage

Clicking on the Data Group>Data Style>Line Style file tabs within the NetPlan Graph Propewindow allows the user to connect the average value data points on the graph with a linespecify the line’s attributes.

Figure 9-7: NetPlan Graph Properties - 1

Clicking on the Data Group>Data Style>Symbol Style file tabs within the NetPlan GrProperties window allows the user to specify the marker characteristics used to identify the avvalue point.


Settings forspecifyinglineattributes}

Settings forspecifyingsymbolattributes}


9


re 9-5

willl doeser ofsed

If the properties are changed, as reflected by Figure 9-7 and Figure 9-8, the graph from Figuwill appear as follows (see Figure 9-9).

Figure 9-9: Graph - 2

Clicking on the Data Group>Data file tabs within the NetPlan Graph Properties windowdisplay a table with the numeric averages calculated for each point along the X axis. The toonot give the name of the point along the X axis (cell/sector name) but just the numerical ordtheir occurrence. (The data shown in Figure 9-10 is from a different simulation than the data uto generate the graph in Figure 9-9.)


Average Values


9


X RFtics is

-2000hlightre RFation,oughtistics

on toesign.essary

sticalspecific

vide an, the

r cell/f the

ent there bestningausebe too

iteriaia is to). Insuchsectort thetor’s

e. Forbeing

9.5 Statistical Analysis Procedures

This section describes NetPlan CDMA statistical analysis procedures for IS-95 and IS-2000 1system design. Further information unique to IS-95B High Speed Packet Data (HSPD) statisprovided in Section A4.5.1.1, “CellStats” and Section A4.5.1.2, “MobileStats”.

Table 9-2 summarizes the statistics that are of most importance in evaluating IS-95 and IS1X RF system designs. The statistics have been organized into functional categories to higthe purpose of the particular statistic in the design process. The functional categories aperformance, RF voice and data capacity, data call model characterization, simulation validand equipment and interconnect sizing. Section 9.5.4, "RF Performance Metrics" thrSection 9.5.10, "IS-2000 Backhaul Sizing" provide procedures for analyzing each of the stalisted in Table 9-2.

There are a relatively large number of statistics shown in Table 9-2, especially in comparisthe number of statistics that are required to be analyzed for an IS-95A RF system dDepending on the specific design objectives and customer requirements, it may not be necto compute and analyze all of the statistics shown in Table 9-2. However, all of the statianalysis procedures are provided in this chapter, in the event that they are needed to meet aRF design objective. The highlighted rows in Table 9-2 identify the subset of statistics thatmustbe computed in order to ensure that an RF system design is meeting its objectives.

The approach adopted in this chapter to describe the statistical analysis procedures is to proequation or a set of steps required to implement the computation of the statistic. Typicallyequation presented will result in the sector statistic. System-wide averages, minimum pesector, maximum per cell/sector, and statistical distributions are natural extensions oprocedures that are described in this document.

Spreadsheets or other statistical software packages have historically been used to implemstatistical analysis; however, many of the IS-2000 1X procedures described in this section aimplemented using a post processing script such as “canal.pl” (refer to Appendix A6 “Runcanal.pl” for additional information on this script). A post processing script is necessary becthe analysis procedures may require several steps and the time-sliced statistics files maylarge for some spreadsheet tools.

Those familiar with IS-95 RF system design will note the increase in the number of design crthat can be applied to an IS-2000 1X RF system design. In IS-95, the prevalent design critermeet or exceed an established minimum RF reliability limit (e.g. 95% system RF reliabilityIS-2000 1X, the RF reliability requirement remains; however, there may be additional criteriaas meeting a system operator’s specified minimum average end user throughput orthroughput. Where applicable, nominal design criteria have been provided throughoufollowing sections. However, a number of design goals will depend on the system operarequirements and, as such, will need to be provided by the system operator if applicablexample, the average end user throughput requirement will depend, in part, on the servicesoffered by the system operator and, as such, must be provided by the system operator.


9


Note: Statistics thatmust be computed are highlighted and marked with an asterisk (*).

Table 9-2: CDMA Statistics

Statistic Statistic Name IS-95 IS-2000 1X IS-2000 1X

Category non time-sliced time-sliced

RF Performance * RF Reliability X X X

Metrics * Walsh Code Utilization X X X* Reverse Noise Rise X X XForward and Reverse FER X X X* Soft Handoff Factor X X XSoft + Softer Handoff Factor X X X* Ior/Ec Ratio X X XSaturation Distribution X XBlocked Mobiles X X

RF Voice and * Total Erlangs X X XData Capacity Active Erlangs X

Bursting Erlangs X* Sector Throughput X XEffective Sector Throughput X X* End User Throughput X XData Rate Distribution X XHigh Speed ChannelRequest Failure Probability

X X

SCH Limit Flag X XData Call Model Forward Activity Factor XCharacterization Reverse Activity Factor X

Think Time XDownload Size and Time XReverse Request File Sizeand Time

X

Probability of GoingDormant

X

Length of Dormant Interval XSimulationValidation

Subscriber SpeedDistribution

X X X

Equipment and Channel Card Quantity X X XInterconnectSizing

* Total Forward Power (PASizing)

X X X

IS-2000 1X Backhaul Sizing X X


9


cribedin athein theDMA

stics

ord

9.5.1 NetPlan Raw Statistics Definitions

Table 9-3 provides definitions for the raw statistics that are used in the analyses desthroughout the remainder of this chapter. Although an individual statistic may be foundnumber of different files (e.g. many CellStatTS_XX statistics are also found inGlobalStatTS_XX file), Table 9-3 only includes the names of the statistics files that are usedanalysis procedures. The entries are organized in alphabetical order. Refer to the “NetPlan CSimulator User’s Manual” for a comprehensive listing of the NetPlan files and the staticontained within each file.

Note: In the following definitions and throughout the remainder of this chapter, the w“sector” can be replaced by “cell” for omni cell sites.

Table 9-3: Raw Statistics Definitions

Raw Statistic Definition Stats File

BytesTx The number of source bytes transmitted oneither the forward or reverse link.

MobileTputStat_XX

CallModelIndex A numerical index that is used to identify theCallModel and ServiceType from theCallModelMap file.

CallModelMapMobileTputStat_XX

ChElem Total number of channel elements required forthe sector to support the number of best servedsubscribers in the sector, including channelelements for IS-95B data links. ChElemincludes one-way and soft handoff links.

Note that channel elements are shared forsofter links.

CellStat_XX (IS-95)


9


ChElem_X A partial count of the number of channelelements (modulator resources) required tosupport the one-way and soft handoff links inthe best serving (best forward link pilot Ec/Io)sector. The computation of this columnassumes that one channel element can supportone best server link (FCH or SCH) or one softhandoff link. Only one channel element ispegged per SCH, without regard to the actualnumber of physical channel elements requiredto support the higher speed SCH’s.

When a SCH is assigned, both the SCHChElem_X statistic and the FCH statistics arepegged. This is because a FCH or DCCH isrequired for each SCH in use.

There is no peg for the reverse link FCH. TheMCC-1X channel card always couples areverse link FCH with a forward link FCH,therefore, the reverse link FCH channelelement is implied when a forward link FCHstatistic is pegged.

(The X in the statistic name is replaced by“All” for voice plus all data rates and radioconfigurations, “v” for voice, 9.6FCH_RC3,9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC3,19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3,76.8_RC4, 153.6_RC3, and 153.6_RC4)

CellStat_XX (1X)CellStatTS_XX

Class Mobile class assigned by the simulator fromthe Subscribers tab. The mobile class is used toseparate subscribers according to parameterssuch as output power, data call model, andpenetration loss.

MobileStat_XXMobileStatTS_XX

ElapsedTime Amount of time in seconds that has elapsedsince the beginning of the simulation.

CellStatTS_XXCellStatTSRev_XXMobileStatTS_XXSectorTputStat_XXMobileTputStat_XXGlobalStatTS_XX




9


FailedSCHReqs_X FailedSCHReqs_X is pegged each time that ahigh speed SCH of a given rate is requested onthe forward link and the resulting SCHassignment is below a user defined minimumrate (Fwd. Data Rate Outage).FailedSCHReqs_X is not pegged when therequested rate is below the Fwd. Data RateOutage, regardless of whether or not therequested rate was assigned.

CellStatTS_XX

FwdBurstTot In the CellStatTS_XX file, the FwdBurstTotstatistic provides the number of voicesubscribers plus the data subscribers who areactively bursting data on the forward link forthe given time-slice in the best serving sector.

In the GlobalStatTS_XX file, theFwdBurstTot statistic provides the number ofvoice subscribers plus the data subscriberswho are actively bursting data on the forwardlink for the given time-slice over the entiresystem (all sectors combined).

CellStatTS_XXGlobalStatTS_XX

FwdFER Achieved FER for the forward link. MobileStat_XX (IS-95)

FwdFERFCH Achieved FER for the FCH on the forwardlink.

MobileStat_XX (1X)MobileStatTS_XX

FwdFERSCH Achieved FER for the SCH on the forwardlink.





9


FwdLinks_X The number of subscribers who have any typeof connection (one way, soft, or softer) withthe given sector on the forward link. As such,it is equivalent to the number of forward linkWalsh codes active in the sector. When aforward link SCH is assigned, theFwdLinks_X statistics will be pegged in boththe SCH FwdLinks_X column for the givenSCH data rate and in the appropriate FCHcolumn, since there is a separate Walsh codeassigned to the FCH and SCH.



FwdMobGood(FCH)_X The number of subscribers who have the givensector as its best serving (best pilot Ec/Io)sectorAND is meeting its forward FER outagecriteria. For subscribers with forward SCHassignments, both the SCH and FCH FER arechecked to determine if the subscriber is“good” for the FwdMobGood_X statistic. Forthe FwdMobGoodFCH_All statistic, it is theFCH FER only that is used to determine if thesubscriber is “good”. The SCH FER is notconsidered in the FwdMobGoodFCH_Allstatistic.

(The X in the statistic name is replaced by“All” for voice plus all data rates and radioconfigurations, “v” for voice, 9.6FCH,14.4FCH, 19.2, 38.4, 76.8, and 153.6)





9


FwdNumMob_X The number of subscribers who have the givensector as its best serving (best pilot Ec/Io)sector. If the FwdNumMob_X statistic ispegged for a SCH, then it is not pegged for theFCH.



FwdPwrTot(W) Sum of power for all forward channels (TCH,Pilot, Page, and Sync) in units of Watts. TheTCH power is scaled down by the voiceactivity factor.

CellStat_XX (IS-95)

FwdRateSCH The data rate for the forward supplementalchannel.


Fwd/Rev “Fwd” indicates that the row provides forwardlink statistics and “Rev” indicates that the rowprovides reverse link statistics.

SectorTputStat_XX

ID The subscriber identification number startingwith 0.

MobileStat_XXMobileStatTS_XX

Links Total number of Walsh codes assigned fromthis cell to any mobile, including soft andsofter handoffs and IS-95B data links.

CellStat_XX (IS-95)

MobileID The subscriber identification number startingwith 0.

MobileTputStat_XX




9


MobileState An entry is logged in the MobileTputStat_XXfile every time that a subscriber changessource model states within the data call model.The state for which the statistics are beinglogged is identified by “MobileState”.

In the MobileStatTS_XX files, MobileStaterepresents the subscribers state at thebeginning of each time-slice. The subscribermay have transitioned through a number ofstates during the time-slice; however, only theinitial state is logged in the MobileStatTS_XXfiles. Statistics are only written to theMobileStatTS_XX file for data subscriberswho were actively bursting data during thetime slice.

The possible states in the MobileStatTS_XXand MobileTputStat_XX files are inactive idle(IN), reverse burst fundamental (RF), reverseburst supplemental (RS), reverse burst DTX(RD), delay to forward response (DF), forwardburst fundamental (FF), forward burstsupplemental (FS), and dormant (DR).

In the MobileStat_XX (1X) file, MobileStateis used to distinguish forward link and reverselink FCH and SCH as follows:

FCH_FCH - Forward fundamental channelbursting and reverse fundamental channelbursting

FCH_SCH - Forward fundamental channelbursting and reverse supplemental channelbursting

SCH_FCH - Forward supplemental channelbursting and reverse fundamental channelbursting

SCH_SCH - Forward supplemental channelbursting and reverse supplemental channelbursting

MobileStat_XX (1X)MobileStatTS_XXMobileTputStat_XX




9


NumberOfDrops The number of simulation Monte Carlo dropsthat were used to produce the statistics that arebeing analyzed.

NA

NumberOfTimeSlices The number of time slices that were simulatedto produce the statistics that are beinganalyzed. Simulation warm-up time must beexcluded fromNumberOfTimeSlices (refer toSection 9.5.2, "IS-2000 1X Time-SlicedSimulation Warm-up Time").NumberOfTimeSlices can be computed as thetotal amount of simulation time being analyzeddivided by the Time-slice Interval.

NA

NumBlockMob_WC The number of best served subscribers in thesector that were unable to obtain a FCH Walshcode on at least one sector.


NumDormantMob The number of best served subscribers in thesector who are dormant during the given time-slice.

CellStatTS_XX

NumFrames_X The number of frames with data bursts over the1 second reporting interval. The “X” suffix isreplaced by the sector number. The “Fwd/Rev” column in the SectorTputStat_XX file isused to determine if NumFrames_Xcorresponds to the forward (Fwd) or reverse(Rev) link.

SectorTputStat_XX

NumMob The number of subscribers with the givensector as its best server (best pilot Ec/Io).

CellStat_XX (IS-95)

NumMobGoodFCH_All The number of subscribers (data or voice) whohave the given sector as its best serving (bestpilot Ec/Io) sector and is meeting both itsforward and reverse link FER outage criteriaon the fundamental channel. Although an SCHmay be assigned, it is only the FCH FER thatis used in determining if a subscriber is “good”in the NumMobGoodFCH_All statistic.


NumMobGood_v The number of voice subscribers who have thegiven sector as its best serving (best pilot Ec/Io) sector and is meeting both its forward andreverse link FER outage criteria.


PagePwr(W) Page channel power in Watts. CellStat_XX (IS-95)CellStat_XX (1X)CellStatTS_XX




9


PcntMobGood Percentage of subscribers for a given sectorand drop that have both their forward andreverse link FER less than the FER outage.

Note: System RF reliability should not becomputed as the average of PcntMobGoodbecause this approach fails to account for thedifference in the number of subscribers persector.

CellStat_XX (IS-95)

PcntMobGoodFCH_All Percentage of subscribers for a given sectorand drop that have both their forward andreverse link fundamental channel FER lessthan the FER outage. Although an SCH maybe assigned, it is only the FCH FER that is usedin determining if a subscriber is “good” in thePcntMobGoodFCH_All statistic.

Note: System RF reliability should not becomputed as the average ofPcntMobGoodFCH_All because this approachfails to account for the difference in thenumber of subscribers per sector.


PilotPwr(W) Forward pilot channel power in Watts asmeasured at the base station antenna port.

CellStat_XX (IS-95)CellStat_XX (1X)CellStatTS_XX

RevBurstTot The total number of voice subscribers plusdata subscribers that were actively burstingdata on the reverse link.

CellStatTSRev_XX

RevFER Achieved FER percent for the reverse link.MobileStat_XX (IS-95)

RevFERFCH Achieved FER percent for the reverse linkFCH.


RevFERSCH Achieved FER percent for the reverse SCH.MobileStat_XX (1X)MobileStatTS_XX




9


RevLinks_X The number of subscribers who have any typeof connection (one way, soft, or softer) withthe given sector on the reverse link. When areverse link SCH is assigned, the RevLinks_Xstatistics will be pegged in both the SCHRevLinks_X column for the given SCH datarate and in the RevLinks_9.6FCH column.

(The X in the statistic name is replaced by“All” for voice plus all data rates, “v” forvoice, 9.6FCH, 14.4FCH, 9.6SCH, 19.2, 38.4,76.8, and 153.6)

CellStat_XX (1X)CellStatTSRev_XX

RevMobGood(FCH)_X The number of subscribers who have the givensector as its best serving sector and is meetingits reverse FER outage criteria. For subscriberswith reverse SCH assignments, both the SCHand FCH FER are used to determine if thesubscriber is “good” for the RevMobGood_Xstatistic. For the RevMobGoodFCH_Allstatistic, it is the FCH FER only that is used todetermine if the subscriber is “good”. TheFCH FER is not considered in theRevMobGoodFCH_All statistic.



RevNumMob_X The number of subscribers who have the givensector as its best serving sector. If theRevNumMob_X statistic is pegged for a SCH,then it is not pegged for the FCH.






9


RevNumSat_X The number of best served subscribers in thesector whose reverse link power requirementsexceed the maximum power of the subscriberunit. Both the RevNumSat_X and appropriateRevNumMob_X statistics are pegged for asaturated subscriber.



RevRateSCH The data rate for the reverse supplementalchannel.


RevSCHElem_X A partial count of the number of channelelements (modulator resources) required tosupport the one-way and soft handoff links onthe reverse SCH in the best serving sector. Thecomputation of this column assumes that onechannel element can support one best serverlink or one soft handoff link. Only one channelelement is pegged per reverse link SCH,without regard to the actual number ofphysical channel elements required to supportthe higher speed SCH’s.

(The X in the reverse link RevSCHElem_Xstatistic name is replaced by “All” for all SCHdata rates, 9.6SCH, 19.2, 38.4, 76.8, and153.6)


Rise(dB) Reverse link noise rise in dB. CellStat_XX (IS-95)CellStat_XX (1X)CellStatTSRev_XX

SectTput_X The average sector throughput in units of bitsper second over the past 1 second reportinginterval including all links (one-way, soft andsofter) and all overhead bits except for airframe CRC and encoder tail bits. The “X”suffix is replaced by the sector number.Forward and reverse link statistics aredistinguished by “Fwd” and “Rev” in the Fwd/Rev column of the SectorTputStat_XX file.

SectorTputStat_XX




9


ServiceType In the CallModelMap file, the service types areHTTP1.0, HTTP1.1, WAP, EMAIL,LSEMAIL, and FTP. In the MobileStat_XX(1X) file, the service types are DATA orVOICE.

CallModelMapMobileStat_XX (1X)

Srv1 The best serving sector number. MobileStat_XX (IS-95)MobileStat_XX (1X)MobileStatTS_XXMobileTputStat_XX

StateTime In IS-2000 1X time-sliced simulation, theamount of time spent in the given call modelstate.

MobileTputStat_XX

SyncPwr(W) Sync channel power in Watts CellStat_XX (IS-95)CellStat_XX (1X)CellStatTS_XX

TchPwrTot(W) Total traffic channel power for all subscribersin Watts. TchPwrTot(W) includes power forFCH and SCH traffic channels.

CellStat_XX (1X)CellStat_XX (IS-95)CellStatTS_XX

XsFlg This is a six character field that is aconcatenation of the following states:G = The maximum forward link SCH gainallowed for the requested data rate wasexceeded.C = Ior/Ec exceeded the forward link “Ior/EcCapacity Threshold” for the requested SCHdata rate. “Ior/Ec Capacity Threshold” is aninput parameter (refer to Chapter 6).W = No Walsh code available for the requestedSCH data rate.N = Noise rise exceeded the “Rise CapacityThreshold” for the requested reverse link SCHdata rate. “Rise Capacity Threshold” is aninput parameter (refer to Chapter 6).M = Mobile transmit power exceeded themaximum allowed for the requested SCH datarate during the request portion of the reverselink SCH assignment algorithm.S = Saturated. Mobile power exceeded themaximum during the reverse link powerconvergence algorithm.- = For any of the above which is not True





9


liceddata

ls. The. The

ixture

arios.. callon theandTotThisool")

SCII

rstingrns to amustof the

ng the

9.5.2 IS-2000 1X Time-Sliced Simulation Warm-up Time

As a result of the way that time-sliced subscribers are introduced into the IS-2000 1X time-ssimulation, there is a period of time at the beginning of each simulation drop where thesubscribers are in the process of reaching a steady state in their respective call modestatistical data that is logged during this “warm-up” period is invalid and must be discardedamount of time required to reach a steady state condition depends on the call models and mof voice and data subscribers.

A warm-up time of approximately 100 seconds will be adequate for most simulation scenOne method to estimate the warm-up time required for a specific simulation scenario (i.emodels, mix of data and voice subscribers, subscriber load, etc.) is to run a long simulation,order of 500 seconds, and plot “FwdBurstTot” versus “ElapsedTime”. The “FwdBurstTot”“ElapsedTime” statistics are found in the GlobalStatTS_XX file. Figure 9-11: "FwdBurstversus ElapsedTime" provides an example of a “FwdBurstTot” versus “ElapsedTime” plot.plot can be generated using NetPlan’s Data Graph tool (refer to Section 9.4, "Data Graph Tor since the GlobalStatTS_XX file is relatively small, the plot can be created by opening the Astatistics file using a typical spreadsheet, and then graphing the appropriate data.

Figure 9-11: FwdBurstTot versus ElapsedTime

As seen in Figure 9-11, for this example the number of subscribers that are actively buincreases from the beginning of the simulation, reaches a peak, decreases, and then returelatively stable level. All of the statistical data that is logged prior to reaching the stable levelbe discarded from the statistical analysis. If this data is not removed, then the accuracyanalysis results will be reduced.

The amount of data to be removed from the beginning of the simulation can be estimated usifollowing procedure:


9


ctively

g (lastminus

ntially

t be

er oftion istions

ationss andlow theecondsof thebe anilized.

tivelynd mixdoes

zes. In

• Compute the mean and standard deviation of the number of subscribers that are abursting per time-slice for the last 200 seconds of a 500 second simulation.

• Set an upper threshold as the mean number of subscribers that are actively burstin200 seconds) plus three standard deviations and a lower threshold as the meanthree standard deviations.

• Identify the point where the number of bursting subscribers curve crosses and esseremains within the threshold limits.

This point is the warm-up time and all statistical data prior to this simulation time musdiscarded from all time-sliced statistics files and analyses.

Figure 9-12 illustrates this procedure. Referring to this figure, the mean value of the numbsubscribers who are actively bursting per time-slice for the last 200 seconds of the simula584 and the standard deviation for this time period is 13.3. Adding three standard devia

to the mean results in an upper bound of 624. Subtracting three standard devifrom the mean results in a lower bound of 544. A line is drawn at the upper and lower boundthe point where the number of bursting subscribers curve passes and essentially remains beupper bound is chosen as the warm-up time of 100 seconds. There are points after 100 swhere the number of subscribers who are actively bursting slightly exceeds the upper limitwarm-up time threshold range, which is to be expected. The threshold is not meant toabsolute limit, rather, it provides a reference point to estimate where the simulation has stab

Figure 9-12: Warm-up Time Estimation (Example 1)

Figure 9-13 illustrates a case where the curve of the number of subscribers who are acbursting versus time takes on a somewhat different characteristic. For the subscriber load aof call models used in this simulation, the number of subscribers who are actively burstingnot reach a peak as in Figure 9-12, rather it climbs at a steep rate and then gradually stabili

13.3 3 40≅×( )


9


rm-up

thetime-utput

ongerngermum

oyed,conds

rio, a, etc.)be runn can

(seeample

this case, the lower bound of the warm-up time threshold range is used to estimate the watime, which in this example is approximately 94 seconds.

Figure 9-13: Warm-up Time Estimation (Example 2)

9.5.3 IS-2000 1X Time-Sliced Simulation Length

The “Simulation Length” input parameter (refer to Chapter 6 for additional information onSimulation Length parameter) sets the amount of time that is simulated for an IS-2000 1Xsliced drop. A primary concern in setting this parameter is to ensure that there are sufficient ostatistics available, after accounting for the warm-up time, to produce meaningful results. Lsimulation length improves confidence in the output statistics; however, requires a losimulation run-time. Therefore, a goal for selecting the simulation length is to choose the minilength that will provide an acceptable level of confidence in the output statistics.

The required simulation length will depend on, among other things, the call models emplsystem loading, and the mixture of voice and data subscribers. A simulation length of 300 sewill typically provide adequate output statistics for a wide variety of input scenarios.

In order to validate or further refine the required simulation length for a given system scenasample simulation for the given system scenario (i.e. loading, call models, cell configurationsshould be run and key output statistics should be analyzed. This sample simulation shouldusing a relatively long simulation length, on the order of 500 seconds. The sample simulatiobe run for just one drop.

A good output statistic to analyze from the sample simulation is sector throughputSection 9.5.5.5, "Sector Throughput"). The mean sector throughput for all sectors in the ssimulation can be plotted per second as shown in Figure 9-14.


9


condmeanat theeanarm-

r toon

tweento behin then timeghput

rmal isis notde aetweens of the

Figure 9-14: Mean System Sector Throughput Per Second

This plot provides a view of the variability of the mean system sector throughput from one seto the next. Since one of the primary output parameters of the time-sliced simulation issystem sector throughput, a good criteria for setting the simulation length is to make sure thsimulation is run for a sufficient amount of time to result in acceptable confidence in the msector throughput statistic when it is averaged over all sectors and time intervals (excluding wup time).

As seen in Figure 9-14, after the initial 95 second simulation warm-up period (refeSection 9.5.2, "IS-2000 1X Time-Sliced Simulation Warm-up Time" for additional informationcomputing the required warm-up time), the mean sector throughput statistic varies beapproximately 110 kbps and 120 kbps for this particular system scenario. This variability isexpected, since the sector throughput depends on the call models for the subscribers witsector, which are based on Pareto random variables. An approximation for the required rucan be computed using a normal confidence interval computation on the mean sector throustatistic. The assumption that the mean sector throughput per second is approximately nobased on experimental results. Although the mean system sector throughput statisticindependent from one second to the next, the normal confidence interval will still provireasonable estimate of the required run time. However, due to the lack of independence bsamples, the simulation length should not be set to less than 300 seconds, even if the resultconfidence interval computation indicate that a shorter simulation length is acceptable.


9


ndardors per

entiren be

d withd toerseondsfidencein the

is 95quirede.

tigatehenin the

in thisandtion

ere isns forat the

stem

The inputs to the confidence interval computation are the desired confidence, the stadeviation of the mean sector throughput statistic, where the mean is taken across all sectsecond, and the desired accuracy of the mean sector throughput for all sectors over thesimulation length (after the warm-up period). A normal confidence interval calculation caentered in a spreadsheet using the following or similar implementation.

In this example spreadsheet, B1 through B3 are the entry fields and have been populatetypical values that might result from a sample simulation run. The “CEILING” function is useround the results to the next highest integer value. The “NORMSINV” function returns the invof the standard normal cumulative distribution function. For this example, the number of secof mean system sector throughput data that must be averaged to obtain the desired con(98%) in estimating the mean system sector throughput over the simulation length to withdesired accuracy (500 bps) is 149 seconds. The warm-up time for this example simulationseconds; therefore, the total simulation length required is 244 seconds (warm-up time + reaveraging time). In this case, the recommended 300 second simulation length is acceptabl

Additional output statistics of interest from the sample simulation can be analyzed to investheir variability over the simulation time. If a particular statistic of interest is highly variable, tadditional simulation length may be needed to achieve a good degree of confidencesimulation results.

9.5.4 RF Performance Metrics

RF performance metrics are used to assess how the system design is operating. Includedcategory of statistics are RF reliability, Walsh code utilization, reverse noise rise, forwardreverse FER, soft handoff factor, soft + softer handoff factor, Ior/Ec ratio, saturation distribuand blocked mobiles.

RF performance metrics typically begin to degrade when the system is heavily loaded or if thinadequate coverage to support the subscribers. Table 9-4 provides a number of optioimproving system performance when the RF design is not meeting the design goals. Note thimplementation of any of the options in Table 9-4 must be consistent with the actual sy

Figure 9-15: Example Spreadsheet Computation of Normal Confidence Interval

A B1 Percent Confidence Desired 98%2 Sample Standard Deviation (bps) 26173 Desired Accuracy of Mean (bps) 5004 Number of Seconds to Average=CEILING((NORMSINV(B1+(1-B1)/2)*B2/B3)^2,1)


9


t

dlynaal

d

dth

toresedat

yna

,eer

en

s

t

implementation and system operator requirements.

Table 9-4: Options to Improve RF Performance

Action Expected result

Reduce the system load Although there may be a specific system load requirementhat would preclude this option, RF performance metrics willtypically improve with decreased system load in a CDMAsystem.

Adjust antenna height Increased antenna height will extend coverage. Reduceantenna height will decrease coverage and thereby potentialdecrease the load on the given sector. Note that the antenheights entered in NetPlan must be consistent with the actuantenna heights at the sites.

Increase antenna gain Increased antenna gain can improve coverage (extenderange or improved in-building coverage). Cost andavailability of antennas must be considered in the design, anthe antenna gain entered in NetPlan must be consistent withe actual antennas used at a site.

Adjust antenna pattern Narrower horizontal beamwidth will increase capacity bydecreasing interference but may reduce coverage at the secboundaries, depending on the amount of scattering in thpropagation environment. Cost and availability of antennamust be considered in the design, and the antenna pattern usin NetPlan must be consistent with the actual antennas useda site.

Adjust antenna downtilt Larger antenna downtilts can reduce interference, which maresult in increased capacity. Reducing antenna downtilt caimprove coverage at the site edge. Note that the antenndowntilts entered in NetPlan must be consistent with theantenna downtilts used at the sites.

Optimize antenna orientationSince CDMA employs a single cell frequency reuse patternit is not strictly necessary to orient the sector antennas in thsame direction for every site. Sector performance can benhanced through optimization of antenna orientation. Foexample, if the goal is to provide coverage for a majorroadway, it may be beneficial to orient the antenna bore sitwith the road. Note that the antenna orientation entered iNetPlan must be consistent with the actual antennaorientation at the sites.

Adjust soft handoff parametersAdjusting the soft handoff parameters to lower the soft andsofter handoff rate will decrease the number of Walsh codeconsumed and will typically reduce the overall interference inthe system. However, the trade-off is that the diversity benefiof soft and softer handoff will be diminished.


9


wardn ofverseditor

nnelsn the

erseif the

rallyprove

bersin thesectoration.

s. Theectors

a

ate

t

9.5.4.1 RF Reliability

The RF reliability statistic provides a measure of the fraction of subscribers that meet their forand reverse link outage FER requirements. As such, RF reliability indicates the fractiosubscribers who are experiencing good communication links in both the forward and redirections. The FER outage criteria is set in the CDMA Parameters Subscriber Class Ewindow (refer to Chapter 6 for information on setting the FER outage limit).

With the introduction of IS-2000 1X, there may be both fundamental and supplemental chaon the forward and reverse links. If the subscriber is assigned a SCH on the forward link, theforward link SCH FER is used to determine if the forward link is good. Conversely, if the revlink is assigned a SCH, it is the FCH FER rather than the SCH FER that is used to determinereverse link is good.

Poor RF reliability (typically <95% for the entire system or <90% for a given sector) is genethe result of coverage or capacity limitations in the system design. For design options to imRF reliability, refer to Table 9-4.

9.5.4.1.1 IS-95 RF Reliability

Within the IS-95 CellStat_XX file, the “NumMob” statistic represents the number of subscriin the best serving sector and the “MobGood” statistic represents the number of subscribersbest serving sector that were able to meet both the forward and reverse link FER criteria. TheRF reliability statistics can be computed for each sector in the system using the following equ

In this equation, the summations are taken within a given sector and over all simulation dropsystem-wide average RF Reliability statistic is computed by taking the summations over all s

Update traffic or speed map As described in Chapter 5, traffic and speed maps havesignificant impact on simulation performance. In the eventthat the simulation is resulting in poor RF performance, thetraffic and speed maps should be checked to ensure thsubscribers are being placed in the correct locations and at thdesired speeds.

Add a carrier or site(s) As a last option, the addition of a carrier to the system or anew site or sites can be explored. This is considered a lasoption since it will typically have the most significant impacton the system cost.

Table 9-4: Options to Improve RF Performance

Action Expected result

SectorRFReliability

MobGoodAllDrops

∑NumMob

AllDrops∑

---------------------------------------------=


9


Thishise this

ho areresult

, andd a.0.ingectorsntly

hich

edilityward

and drops.

It should be noted that the CellStat_XX file contains a statistic named “PcntMobGood”.statistic provides the fraction of “MobGood” to “NumMob” for a given sector and drop. Tstatistic should not be averaged to determine the system RF reliability statistics becauscomputation method does not account for the differences in the number of subscribers wassigned to each sector. The result of averaging “PcntMobGood” will not be the same as theobtained using the equation above. As an example of this, if Sector A had a “NumMob” of 10“MobGood” of 5, then “PcntMobGood” for the drop would be equal to 0.5. If Sector B ha“NumMob” of 2, and a “MobGood” of 2, then “PcntMobGood” for the drop would be equal to 1Averaging “PcntMobGood” for these two sectors would result in an RF reliability of 0.75. Usthe method described by the equation above, the actual average RF reliability for the two swould be 0.58 ([5+2]/[10+2] = 0.58). In this case, the actual average RF reliability is significalower than that which was computed by averaging the “PcntMobGood” statistics.

The following are recommended minimum criteria levels. These are typical cutoff values wcan be used in the absence of specific requirements from the system operator.

• RF reliability> 95% for the entire system.

• No individual sector should have RF reliability < 90%.

9.5.4.1.2 IS-2000 1X (non time-sliced) RF Reliability

The “FwdMobGood_X”, “FwdNumMob_X”, “RevMobGood_X”, “RevNumMob_X”,“NumMobGood_v”, and “NumMobGoodFCH_All” statistics in the IS-2000 1X non time-slicsimulator CellStat_XX file are used to compute the IS-2000 1X non time-sliced RF reliabstatistics. The equations in Table 9-5 provide a method to compute RF reliability on the forand reverse links for a given sector.

Table 9-5: RF Reliability Equations

Scenario Equation

Forward and reversetogether, voice only

Forward and reversetogether, data and voicecombined together

NumMobGood v_Drops∑

FwdNumMob v_Drops∑

------------------------------------------------------------

NumMobGoodFCH All_Drops∑

FwdNumMob All_Drops∑

-------------------------------------------------------------------------------


9


C3,

s

Forward, all data rates andradio configurations plusvoice combined together

Forward, data only, alldata rates and radioconfigurations combinedtogether

where summations are taken over all drops and all data rates(Y= 9.6FCH, 14.4FCH, 19.2, 38.4, 76.8, and 153.6X=9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC3,19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC4, 153.6_Rand 153.6_RC4)

Forward, data only, allSCH data rates and radioconfigurations combinedtogether

where summations are taken over all drops and all SCH data rate(Y= 19.2, 38.4, 76.8, and 153.6X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3,76.8_RC4, 153.6_RC3, and 153.6_RC4)


Scenario Equation

FwdMobGoodFCH All_Drops∑


------------------------------------------------------------------------------

FwdMobGood Y_AllRates∑

Drops∑

FwdNumMob X_AllRates∑

Drops∑

-------------------------------------------------------------------------------

FwdMobGood Y_AllSCHRates

∑Drops∑

FwdNumMob X_AllSCHRates

∑Drops∑

----------------------------------------------------------------------------------------


9


Forward, separate RFreliability for voice or perdata rate

for voice only

for RC5 only

for RC3 and RC4 only

where “X” is set to the data rate of interest(X= 9.6FCH, 19.2, 38.4, 76.8, or 153.6)

Reverse, all data ratesplus voice combinedtogether

Reverse, data only, alldata rates combinedtogether

where summations are taken over all drops and all data rates(X= 9.6FCH, 14.4FCH, 9.6SCH, 19.2, 38.4, 76.8, and 153.6)


Scenario Equation

FwdMobGood v_Drops∑


------------------------------------------------------------

FwdMobGood 14.4FCH_Drops∑FwdNumMob 14.4FCH RC5_ _

Drops∑

------------------------------------------------------------------------------------------------

FwdMobGood X_Drops∑

FwdNumMob X RC3 FwdNumMob X RC4_ _+_ _( )Drops∑

-------------------------------------------------------------------------------------------------------------------------------------------------------,

RevMobGoodFCH All_Drops∑

RevNumMob All_Drops∑

----------------------------------------------------------------------------

RevMobGood X_AllRates∑

Drops∑

RevNumMob X_AllRates∑

Drops∑

-----------------------------------------------------------------------------


9


ctor RFte the

dime-y for0 1Xons-slicesheardtime-

desalsh

pardy ofbile

s

The summations in these equations are taken within sectors and across drops to compute sereliability statistics. The summations can be taken across all sectors and drops to compusystem-wide RF reliability statistics.

9.5.4.1.3 IS-2000 1X (time-sliced) RF Reliability

The “FwdMobGood_X”, “FwdNumMob_X”, “RevMobGood_X”, “RevNumMob_X”,“NumMobGood_v”, and “NumMobGoodFCH_All” statistics in the IS-2000 1X time-slicesimulator CellStatTS_XX and CellStatTSRev_XX files are used to compute the IS-2000 1X tsliced simulation RF reliability statistics. The procedure used to compute the RF reliabilittime-sliced simulation is the same as for non time-sliced (refer to Section 9.5.4.1.2, "IS-200(non time-sliced) RF Reliability") simulation, with the additional step of taking the summatiacross time-slices as well as drops. It should be noted that the forward and reverse link timetypically will not align with each other in a time-sliced simulation. As such, t“NumMobGood_v” and “NumMobGoodFCH_All” statistics are created by checking the forwand reverse link fundamental channel FER performance for the forward and reverse linkslices that are nearest to each other.

9.5.4.2 Walsh Code Utilization

Within an IS-95 or IS-2000 1X system, there are a limited number of forward link Walsh coavailable. The purpose of the Walsh code utilization statistic is to determine the number of Wcodes that are being consumed per sector and to assess whether or not the design is in jeobecoming Walsh code limited. This is typically not an issue with 13 kbps vocoder IS-95 mo

Reverse, data only, allSCH data rates combinedtogether

where summations are taken over all drops and all SCH data rate(X= 9.6SCH, 19.2, 38.4, 76.8, and 153.6)

Reverse, separate RFreliability for voice or perdata rate

where “X” is set to the data rate of interest or “v” for voice(X= v, 9.6FCH, 14.4FCH, 9.6SCH, 19.2, 38.4, 76.8, or 153.6)


Scenario Equation

RevMobGood X_AllSCHRates

∑Drops∑

RevNumMob X_AllSCHRates

∑Drops∑

---------------------------------------------------------------------------------------

RevMobGood X_Drops∑

RevNumMob X_Drops∑

-----------------------------------------------------------


9


, theome a) andspeedy aretheir

mingve RF

rverer ofr thantistic

codealsh

S-95

filembined

voice systems. However, with the introduction of 8 kbps EVRC and for small WiLL systemsnumber of Walsh codes can become the capacity limit. Walsh code utilization can also becconcern for IS-2000 1X data networks when using Radio Configuration 3 (64 Walsh codeshosting a significant number of low speed data sessions (e.g. WAP). In this case, the lowdata subscribers do not significantly contribute to interference on the air interface since thenot transmitting much data. However, they do consume Walsh codes for the duration ofsessions.

When sectors begin to reach their Walsh code limit, it is an indication that the sector is becocapacity constrained. Refer to Table 9-4 for a list of design options that can be used to improperformance, in the event that the design is experiencing Walsh code blocking.

9.5.4.2.1 IS-95 Walsh Code Utilization

For IS-95, the “Links” statistic in the CellStat_XX file corresponds to the sum of the best selinks, soft handoff links, and softer handoff links in the sector. As such, it identifies the numbWalsh codes that are utilized per sector. The number of links per sector will always be greateor equal to the number of channel elements per sector, “ChElem”, since the “ChElem” stadoes not include softer handoff links. The graph in Figure 9-16: "Links" shows the Walshutilization per sector and should be compared to the Walsh code limit of 61 (assuming 3 Wcodes per sector for overhead channels, which are not included in the “Links” statistic) for Isystems.

Figure 9-16: Links

9.5.4.2.2 IS-2000 1X (non time-sliced) Walsh Code Utilization

For IS-2000 1X non time-sliced simulation, the “FwdLinks_X” statistics in the CellStat_XXare separately reported for voice, each data rate, each radio configuration, and also as a co


9


dioedparedte the000the128The

imum

X”

x16

filen time-ode

aken

statistic called “FwdLinks_All”, which includes voice plus all of the data rates and raconfigurations. As with IS-95, the “FwdLinks_X” statistics for IS-2000 1X non time-slicsimulation represent Walsh code utilization. However, the statistics can no longer be comdirectly to a Walsh code limit since the SCH Walsh codes are of variable length. To calculaequivalent number of “64 chip” (RC3/RC5) or “128 chip” (RC4) Walsh codes from the IS-21X “FwdLinks_X” statistics, it is necessary to first multiply each high speed SCH link byWalsh code scaling factor shown in Table 9-6. It is useful to plot the maximum “64 chip” or “chip” Walsh code utilization across all sectors along with the minimum and average.maximum Walsh code utilization is the statistic of most importance, since exceeding the maxnumber of available Walsh codes corresponds to Walsh code blocking.

As an example of computing the number of “64 chip” Walsh codes from the “FwdLinks_statistic, assume that the number of links for each data rate are as shown in Table 9-7.

For this example, the number of “64 chip” Walsh codes would be 20 (8x1 + 2x2 + 0x4 +1x8 + 0= 20).

9.5.4.2.3 IS-2000 1X (time-sliced) Walsh Code Utilization

For an IS-2000 1X time-sliced simulation, the “FwdLinks_X” statistics in the CellStatTS_XXare reported per time-slice and are used in the same manner described in the IS-2000 nosliced simulation section (refer to Section 9.5.4.2.2, "IS-2000 1X (non time-sliced) Walsh CUtilization"). When computing averages for the time-sliced simulations, the average is twithin sectors and across all drops and time-slices.

Table 9-6: Walsh Code Scaling Factor

Data Rate Walsh code scaling factor

9.6 kbps 114.4 kbps 119.2 kbps 238.4 kbps 476.8 kbps 8153.6 kbps 16

Table 9-7: FwdLinks_X for “64 chip” Walsh Code Example

Data Rate FwdLinks_X

9.6 kbps 819.2 kbps 238.4 kbps 076.8 kbps 1153.6 kbps 0


9


ceivedmula, onlythisssarily

98th-often98th-s, thethat isod of9-17tion.

or the

reduceprovee rise.

9.5.4.3 Reverse Noise Rise

The reverse noise rise statistic corresponds to the amount of multi-user noise that is being reat a sector on the reverse link. It is an indicator of the reverse link loading and stability. The forused to calculate noise rise [-10log (1-X), where X is the load], as discussed in Chapter 2provides a rough estimate and is not applicable for non-uniform distributions of traffic. Forreason, noise rise is evaluated as an output of the NetPlan CDMA Simulator and is not neceused to determine the number of subscribers to place into the simulation.

A generally accepted limit for reverse noise rise in a CDMA system is a mean of 6 dB andpercentile of 10 dB on a sector by sector basis. For IS-95 voice systems, the forward link willlimit system capacity prior to reaching a 6 dB mean noise rise on the reverse link and thepercentile noise rise will typically be less than 7 dB. For IS-95B and IS-2000 1X data systemvariability of the reverse noise rise can be higher due to the increased reverse noise riseassociated with higher data rate transmissions. In this case, there is a greater likelihoapproaching the 10 dB 98th-percentile limit per sector for a fully loaded system. Figureillustrates the reverse noise rise as a function of system loading for a uniform traffic distribuAs seen in this figure, 6 dB mean rise corresponds to a design limit of 75% load, and 10 dB f98th-percentile corresponds to 90% of the pole capacity.

Figure 9-17: Reverse Noise Rise Versus Percent Load.

If sectors in the system are experiencing high noise rise levels, then steps should be taken tothe reverse link loading. Refer to Table 9-4 for a list of design options that can be used to imRF performance, in the event that the design is experiencing high levels of reverse link nois


9


perrage isoise

noisevalues.each

to5 section

uch,r anred onlink

slicedn betwork.liced

9.5.4.3.1 IS-95 Reverse Noise Rise

The “Rise (dB)” statistic in the IS-95 CellStat_XX file provides a measure of the noise risesector in units of dB. This statistic is averaged for each sector across all drops and the aveplotted along with the minimum and maximum values per sector as shown in Figure 9-18: "NRise". In this figure, there are a number of sectors with high noise rise values. A CDF of therise data for each sector can also be created to assess the overall distribution of the noise riseThe design limit for noise rise in an IS-95 design is less than 10 dB for the 98th-percentile forsector.

Figure 9-18: Noise Rise

9.5.4.3.2 IS-2000 1X (non time-sliced) Reverse Noise Rise

The “Rise (dB)” statistic in the IS-2000 1X non time-sliced simulation CellStat_XX file is usedassess the sector noise rise performance using the same procedure as described in the IS-9(refer to Section 9.5.4.3.1, "IS-95 Reverse Noise Rise").

In non time-sliced simulation, the reverse link data load is equivalent to the forward link. As sthe reverse link noise rise levels will typically be higher than what would be expected foasymmetric data service such as web browsing, where the majority of data is being transferthe forward link. If the IS-2000 1X non time-sliced system design is experiencing high reversenoise rise levels, it may be necessary to further investigate this by implementing a time-simulation. The forward and reverse link data call models in a time-sliced simulation caseparately set to more accurately reflect the data services that will be offered on the neWhere a non time-sliced simulation may indicate high reverse link noise rise, a time-s


9


er

a astributeime-

sede IS-95lyzed

in anector.

tes and"RFncefileulars FERn theentiate

canDF)sultsFER

not a

ragee RF

ther each% forucedFER

simulation with low reverse link data requirements will typically result in significantly lowreverse noise rise levels.

Additionally, the variability of the reverse link noise rise can be higher for IS-2000 1X datcompared to IS-95 voice, since high speed channels transmit at high power levels and consignificantly to the reverse noise rise. The design limit for noise rise in an IS-2000 1X non tsliced simulation design is less than 10 dB for the 98th-percentile for each sector.

9.5.4.3.3 IS-2000 1X (time-sliced) Reverse Noise Rise

The “Rise(dB)” statistic in the IS-2000 1X time-sliced simulation CellStatTSRev_XX file is uto assess the sector noise rise performance using the same procedure as described in thsection (refer to Section 9.5.4.3.1, "IS-95 Reverse Noise Rise"). The statistic must be anaacross time-slices and drops for the time-sliced simulator. The design limit for noise riseIS-2000 1X time-sliced simulation design is less than 10 dB for the 98th-percentile for each s

9.5.4.4 FWD & REV Subscriber Class FER Distribution

The primary method to assess FER performance across an entire system and for all data raservices in a NetPlan simulation is to analyze the RF reliability statistics (Section 9.5.4.1,Reliability"). However, these RF reliability statistics do not provide separate performainformation for each subscriber class. By importing the MobileStat_XX or MobileStatTS_XXinto a statistical utility tool, the system designer can filter out the information for a particsubscriber class (or a group of subscriber classes) of interest and separately review itdistributions. This can help determine the individual subscriber class performance whesimulation contains voice and multiple data services subscribers. It can also be used to differthe performance between in-building and on-street subscribers.

Through the use of a statistical analysis tool, the MobileStat_XX or MobileStatTS_XX fileyield information about the Forward and Reverse FER Probability Distribution Function (Pand Cumulative Distribution Function (CDF) for the subscribers in a given cell/sector. The reof the Forward and Reverse link FER PDF and CDF can then be compared with expectedperformance criterion for the system under design (system wide FER performance ismandatory acceptance criterion for all systems).

High FER is typically an indication that the system design is becoming capacity or coveconstrained. Refer to Table 9-4 for a list of design options that can be used to improvperformance, in the event that the design is experiencing high FER levels.

9.5.4.4.1 IS-95 FWD & REV Subscriber Class FER Distribution

The “FwdFER” and “RevFER” statistics in the IS-95 CellStat_XX file are sorted according tosubscriber class in the “Class” column. The CDF of the FER statistics can then be plotted fosubscriber class and compared to the FER outage criteria for that class, which is typically 3voice users. Figure 9-19: "Mobile Class FER CDF" provides an example of the CDF prodfrom the FER analysis. As seen in this figure, the majority of subscribers are experiencing


9


areREV

al andndile.d init is

areREV

al andnd

ile.d init is

ofter

near the target of one percent.

Figure 9-19: Mobile Class FER CDF

9.5.4.4.2 IS-2000 1X (non time-sliced) FWD & REV Subscriber Class FER Distribution

The subscriber class FER distribution statistics for IS-2000 1X non time-sliced simulationcomputed using the same procedures as IS-95 (refer to Section 9.5.4.4.1, "IS-95 FWD &Subscriber Class FER Distribution"). The FER data is separately reported for the fundamentsupplemental channels in the “FwdFERFCH”, “RevFERFCH”, “FwdFERSCH”, a“RevFERSCH” statistics within the IS-2000 1X non time-sliced simulation MobileStat_XX fThe typical FER outage limit for voice is 3% and for data is 10%. Note that “-9999” is recordethe “FwdFERSCH” and “RevFERSCH” column when no SCH is assigned. Therefore,necessary to filter out these values prior to analyzing the FER data.

9.5.4.4.3 IS-2000 1X (time-sliced) FWD & REV Subscriber Class FER Distribution

The subscriber class FER distribution statistics for IS-2000 1X time-sliced simulationcomputed using the same procedures as IS-95 (refer to Section 9.5.4.4.1, "IS-95 FWD &Subscriber Class FER Distribution"). The FER data is separately reported for the fundamentsupplemental channels in the “FwdFERFCH”, “RevFERFCH”, “FwdFERSCH”, a“RevFERSCH” statistics within the IS-2000 1X time-sliced simulation MobileStatTS_XX fThe typical FER outage limit for voice is 3% and for data is 10%. Note that “-9999” is recordethe “FwdFERSCH” and “RevFERSCH” column when no SCH is assigned. Therefore,necessary to filter out these values prior to analyzing the FER data.

9.5.4.5 Soft Handoff Factor and Soft + Softer Handoff Factor

In this section, two related statistics are presented, name “soft handoff factor” and “soft + s


9


ed to. A

as ated toreaset usee totalSHOF

eragecept,7 for

HOFstate”

_XX

sing

F ands, the

.5 to1.7.

handoff factor”. Soft handoff factor (SHOF) can be viewed as the increase in Erlangs requirsupport soft handoff. Therefore, the soft handoff factor will impact the final cost of the systemhigher soft handoff factor implies that more users require links with multiple cell sites andresult will need additional channel elements to support all of the connections. Closely relasoft handoff factor is soft + softer handoff factor (SSHOF). SSHOF can be viewed as the incin Erlangs required to support soft and softer handoffs. Although softer handoff does noadditional channel elements at a site, it does require additional Walsh codes, contributes to thinterference in the system, and consumes additional power amplifier resources. Therefore, Sshould be considered in the RF system design.

High levels of soft and softer handoff can result when there is considerable overlap in RF covbetween sectors or when handoff parameters (T-ADD, T-DROP, Add Intercept, Drop Interand Soft Slope) are set to values that promote soft and softer handoffs (refer to Chapteradditional information on setting soft handoff parameters). In addition to SHOF and SSstatistical analysis, SHOF and SSHOF can be further characterized using the “soft handoffplot. Refer to Chapter 11 for additional information on the “soft handoff state” plot.

9.5.4.5.1 IS-95 Soft Handoff Factor and Soft + Softer Handoff Factor

The calculations that follow indicate which statistics to use from an IS-95 simulation CellStatoutput file to determine the sector SHO factor.

Mean (ChElem) = Act_TCH ErlangsMean (NumMob) = Eff_TCH ErlangsAct_TCH Erlangs = Eff_TCH Erlangs * SHOFSHOF = Act_TCH Erlangs / Eff_TCH Erlangs

Substituting with simulator equivalents from the CellStat_All file, SHOF can be computed uthe following equation:

This equation is modified as follows to compute the SSHOF:

The summations are taken within sectors and across all drops to arrive at the sector SHOSSHOF statistics. To compute the system-wide average SHOF and SSHOF statisticsummations are taken across all drops and sectors.

Typical levels of SHOF for an IS-95 system would range from 1.4 to 1.5 for sector sites and 11.6 for omni sites. Typical levels of SSHOF for an IS-95 system would range from 1.6 to

SHOF

ChElemDrops∑

NumMobDrops∑

-------------------------------------=

SSHOF

LinksDrops∑

NumMobDrops∑

-------------------------------------=


9


t wastisticaluse the

ropf softallyuired).st.

eedtails

esignIS-2000

SCH.f thebe anced bywntilt.7 forwill

hms.d 1.41.6.

Figure 9-20 provides an example plot of soft handoff factor versus sector number. This plogenerated using the JMP™ statistical analysis tool. It can also be created via other stasoftware packages. This chart can not be produced with the NetPlan Data Graph tool becaplotted data is a function of two sets of data.

Figure 9-20: SHO Factor (JMP)

By tuning the values of the soft handoff parameters (T-ADD, T-DROP, Add Intercept, DIntercept, and Soft Slope), adjusting pilot power, or adjusting antenna tilts, the amount ohandoff can be varied within an IS-95 system. Higher values for soft handoff will typicimprove call quality and capacity, but increase equipment cost (more channel elements reqLower values for soft handoff will typically degrade call quality, but decrease equipment co

The SHOF and SSHOF statistics become invalid with the introduction of IS-95B High SpPacket Data (HSPD) users. See Section A4.5.1.1.1: “Soft Handoff Factor” for further deconcerning this issue.

9.5.4.5.2 IS-2000 (non time-sliced) Soft Handoff Factor and Soft + Softer Handoff Factor

As with an IS-95 RF system design, an IS-2000 1X non time-sliced simulation system dmakes use of SHOF and SSHOF statistics to assess system performance. However, for the1X case, the SHOF and SSHOF statistics are separately calculated for the FCH and theSHOF and SSHOF on the FCH provides useful information on the RF design in terms oamount of overlap between cells and sectors. If the SHOF and SSHOF are high, it canindication that there is excessive overlap between cells and sectors which should be reduselecting the appropriate antennas, reducing pilot power settings, and optimizing antenna doSHOF and SSHOF will also be impacted by the SHO input parameters (refer to Chapterinformation on setting the SHO input parameters). The SHOF and SSHOF on the SCHtypically be lower than on the FCH, due to the use of Reduced Active Set (RAS) algoritTypical levels of SHOF for an IS-2000 system would range from 1.3 to 1.4 for sector sites anto 1.5 for omni sites. Typical levels of SSHOF for an IS-2000 system would range from 1.5 to

1

2

3

4


9


Fin theion

csthenelCHs an

3,4,

of

3,

The “ChElem_X”, “FwdNumMob_X”, and “FwdLinks_X” statistics are used to calculate SHOand SSHOF for an IS-2000 1X non time-sliced simulation. These raw statistics are foundIS-2000 1X CellStat_XX file. Soft handoff factor for an IS-2000 1X non time-sliced simulatcan be computed using the equations in Table 9-8:

Table 9-8: SHOF Equations

Scenario Equation

Voice only (The results ofthis computation apply toboth the forward andreverse links)

FCH data only (The resultsof this computation applyto both the forward andreverse links)

Where the denominator is the sum of all FwdNumMob_X statistifor all data rates and radio configurations. The denominator issum of FwdNumMob_X for all data rates because the FCH chanelement statistics in the numerator are pegged for every Fsubscriber and every SCH subscriber, since each SCH also haassociated FCH.(Y=9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5X = 9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC153.6_RC3, and 153.6_RC4)

All data rates, radioconfigurations, and voicecombined (The results ofthis computation apply toboth the forward andreverse links). This is thesame as “base channel”SHOF, which is SHOF forvoice plus 9.6FCH.

(Y= v, 9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5)

Forward, separate SHOFper SCH data rate and radioconfiguration

Where “X” is set to the SCH data rate and radio configurationinterest.(X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC76.8_RC4, 153.6_RC3, or 153.6_RC4)

ChElem v_Drops∑FwdNumMob v_

Drops∑

---------------------------------------------------------

ChElem Y_AllDataFCH

∑Drops∑


Drops∑

----------------------------------------------------------------------------

ChElem Y_AllFCH∑

Drops∑


--------------------------------------------------------------

ChElem X_Drops∑FwdNumMob X_

Drops∑

----------------------------------------------------------


9


ps. Tops andradiotionsradiosired,sed in

entsber of, thesoft

pportactual

sts thefer toannel

adio

3,

tes

In these equations the summations are taken within the sector and across all simulation drocompute the system-wide average SHOF, the summations must be taken across all drosectors. A number of statistics in the CellStatTS_XX file are reported separately for eachconfiguration (RC3, RC4, and RC5). If desired, composite statistics across radio configuracan be created by first adding the raw statistics within a given data rate and acrossconfigurations and then using the composite statistics in the equations. Conversely, if deseparate statistics can be computed for each radio configuration by limiting the raw data uthe equations to the radio configuration of interest.

Voice and FCH SHOF are directly related to the increase in the number of channel elem(modulator resources) required. Conversely, SCH SHOF does not relate directly to the numadditional channel elements required to support soft handoff. As described in Table 9-3“ChElem_X” statistic counts one channel element per best server link (FCH or SCH) orhandoff link. It does not account for the additional MCC-1X channel elements required to suthe higher speed SCH’s. Only one channel element is pegged per SCH, without regard to thenumber of channel elements required to support the higher speed SCH’s. Table 9-9 below liactual number of modulator resources required to support each SCH data rate. ReSection 9.5.8, "Channel Card Sizing" for procedures to compute the required number of ch

Forward, all SCH data ratesand radio configurationscombined together

Where the summations are taken across all SCH data rates and rconfigurations.(X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC76.8_RC4, 153.6_RC3, and 153.6_RC4)

Reverse, separate SHOFper SCH data rate

Where “X” is set to the SCH data rate of interest(X=9.6SCH, 19.2, 38.4, 76.8, or 153.6)

Reverse, all SCH data ratescombined together

Where the summations are taken across all SCH data ra(X=9.6SCH, 19.2, 38.4, 76.8, and 153.6)

Table 9-8: SHOF Equations

Scenario Equation

ChElem X_AllSCHRates

∑Drops∑


∑Drops∑

--------------------------------------------------------------------------------------

RevSCHElem X_Drops∑


-----------------------------------------------------------

RevSCHElem All_Drops∑


∑Drops∑

------------------------------------------------------------------------------------


9


sameinks”ofterHOF

cstheHHhas

3,4,

elements (MCC-1X cards).

Soft + Softer Handoff Factor (SSHOF) is calculated for both the FCH and the SCH using theequations as Soft Handoff Factor (SHOF) except the “ChElem” statistic is replaced by the “Lstatistic. In this case, all links including soft and softer links are considered in the soft + shandoff calculation. The following equations can be used to compute the IS-2000 1X SSstatistics.

Table 9-10: SSHOF Equations

Table 9-9: Required Modulator Resources Per SCH Data Rate

SCH DataRate (kbps)

Required ModulatorResources (RC3)

Required ModulatorResources (RC4)

19.2 2 138.4 4 276.8 8 4153.6 16 8

Scenario Equation

Voice only (The results ofthis computation apply toboth the forward andreverse links)

FCH data only (The resultsof this computation applyto both the forward andreverse links)

Where the denominator is the sum of all FwdNumMob_X statistifor all data rates and radio configurations. The denominator issum of FwdNumMob_X for all data rates because the FCFwdLinks statistics in the numerator are pegged for every FCsubscriber and every SCH subscriber, since each SCH link alsoan associated FCH link.(Y=9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5X = 9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC153.6_RC3, and 153.6_RC4)

FwdLinks v_Drops∑


---------------------------------------------------------

FwdLinks Y_AllDataFCH

∑Drops∑


Drops∑

----------------------------------------------------------------------------


9


ps. Tops and

3,

3,

tes

In these equations the summations are taken within the sector and across all simulation drocompute the system-wide average SSHOF, the summations must be taken across all dro

All data rates, radioconfigurations, and voicecombined together (Theresults of this computationapply to both the forwardand reverse links). This isthe same as “base channel”SHOF, which is SHOF forvoice plus 9.6FCH.

(Y= v , 9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5)

Forward, separate SSHOFper SCH data rate and radioconfiguration

Where “X” is set to the SCH data rate of interest(X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC76.8_RC4, 153.6_RC3, or 153.6_RC4)


Where the summations are taken across all SCH data rates(X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC76.8_RC4, 153.6_RC3, and 153.6_RC4)

Reverse, separate SSHOFper SCH data rate

Where “X” is set to the SCH data rate of interest(X=9.6SCH, 19.2, 38.4, 76.8, or 153.6)


Where the summations are taken across all SCH data ra(X=9.6SCH, 19.2, 38.4, 76.8, and 153.6)

Scenario Equation

FwdLinks Y_AllFCH∑

Drops∑


-----------------------------------------------------------------

FwdLinks X_Drops∑

FwdNumMob X_Drops∑

----------------------------------------------------------

FwdLinks X_AllSCHRates

∑Drops∑


∑Drops∑

--------------------------------------------------------------------------------------

RevLinks X_Drops∑


---------------------------------------------------------

RevLinks X_AllSCHRates

∑Drops∑


∑Drops∑

------------------------------------------------------------------------------------


9


radiotionsradiosired,sed in

duced

tionsand

SHOFtheandoffSoftres).d 1.41.6.

to thebase

link.t on/EcCHd. Ifhichtheas awith

ime-rwardRF

sectors. A number of statistics in the CellStatTS_XX file are reported separately for eachconfiguration (RC3, RC4, and RC5). If desired, composite statistics across radio configuracan be created by first adding the raw statistics within a given data rate and acrossconfigurations and then using the composite statistics in the equations. Conversely, if deseparate statistics can be computed for each radio configuration by limiting the raw data uthe equations to the radio configuration of interest.

SHOF and SSHOF for the SCH should be lower than for the FCH due to the use of a ReActive Set (RAS).

9.5.4.5.3 IS-2000 1X (time-sliced) Soft Handoff Factor and Soft + Softer Handoff Factor

The raw statistics used in the IS-2000 1X time-sliced simulation SHOF and SSHOF calculaare found in the CellStatTS_XX and CellStatTSRev_XX files. The same raw statisticscomputation methods used to determine IS-2000 1X non time-sliced simulation SHOF and Sare used for IS-2000 1X time-sliced simulation. However, for time-sliced simulation,summations are taken across time-slices and drops (refer to Section 9.5.4.5.1, "IS-95 Soft HFactor and Soft + Softer Handoff Factor" and Section 9.5.4.5.2, "IS-2000 (non time-sliced)Handoff Factor and Soft + Softer Handoff Factor" for SHOF and SSHOF computation proceduTypical levels of SHOF for an IS-2000 system would range from 1.3 to 1.4 for sector sites anto 1.5 for omni sites. Typical levels of SSHOF for an IS-2000 system would range from 1.5 to

9.5.4.6 Pilot Ior/Ec Ratio

Pilot Ior/Ec is the ratio of the total base station transmit power spectral density per sectorpilot channel energy per PN chip. The measurement point for this metric is directly at thestation transmit antenna port.

High pilot Ior/Ec ratio is an indication that the system is becoming overloaded on the forwardFor IS-2000 1X, the “Ior/Ec Capacity Threshold” parameter will also have a significant impacthe pilot Ior/Ec statistics (refer to Chapter 6 for additional information on setting the “IorCapacity Threshold”). The “Ior/Ec Capacity Threshold” is used in the forward link Sassignment algorithm to limit data rates so that the forward link will not become overloade“Ior/Ec Capacity Threshold” is set low, then the data rate assignments will be skewed lower wwill result in lower forward link loading and lower Ior/Ec ratio values. It should be noted that“Ior/Ec Capacity Threshold” does not set a hard limit on the system Ior/Ec, rather, it is usedcomponent of the SCH assignment algorithm. As such, there will be sectors in the systemhigher Ior/Ec ratios than the “Ior/Ec Capacity Threshold” value.

An Ior/Ec ratio of 10 (linear) for the 98th-percentile taken over all drops, subscribers, and tslices (for time-sliced simulation) in a given sector indicates that the sector has reached its folink capacity limit. Refer to Table 9-4 for a list of design options that can be used to improveperformance, in the event that the design produces high Ior/Ec ratios.


9


)”nc,er

erage

ute theacross

)”,edsync

e the

ute theacross

acity

andwithtistics

er 6

9.5.4.6.1 IS-95 Pilot Ior/Ec Ratio

Pilot Ior/Ec is computed for IS-95 simulations using the “FwdPwrTot(W)” and “PilotPwr(Wstatistics from the CellStat_XX file. “FwdPwrTot(W)” is the summation of the pilot, page, syand traffic channel power on the forward link in units of Watts. “PilotPwr(W)” is the pilot powfor the sector in units of Watts. The following equation illustrates a method to compute the avpilot Ior/Ec ratio per sector.

The summations are taken within each sector and across all drops in the simulation to compindividual sector statistics. To compute the system-wide average, the summations are takenall sectors and all drops.

9.5.4.6.2 IS-2000 1X (non time-sliced) Pilot Ior/Ec Ratio

Pilot Ior/Ec is computed for IS-2000 1X non time-sliced simulation using the “TCHPwrTot(W“PilotPwr(W)”, “PagePwr(W)”, and “SyncPwr(W)” statistics from the IS-2000 1X non time-slicCellStat_XX file. These statistics represent the total traffic (FCH and SCH), pilot, page, andchannel powers in units of Watts. The following equation illustrates a method to computaverage pilot Ior/Ec ratio per sector.

The summations are taken within each sector and across all drops in the simulation to compindividual sector statistics. To compute the system-wide average, the summations are takenall sectors and all drops. Refer to Chapter 6 for information on setting the “Ior/Ec CapThreshold”.

9.5.4.6.3 IS-2000 1X (time-sliced) Pilot Ior/Ec Ratio

Pilot Ior/Ec is computed for IS-2000 1X time-sliced simulation using the same statisticsprocedures described in Section 9.5.4.6.2, "IS-2000 1X (non time-sliced) Pilot Ior/Ec Ratio",the additional step of taking the summations across time-slices as well as drops. The starequired for the pilot Ior/Ec computation are found in the CellStatTS_XX file. Refer to Chaptfor information on setting the “Ior/Ec Capacity Threshold”.

I or

Ec------

FwdPwrTot W( )Drops∑

PilotPwr W( )Drops∑

-------------------------------------------------------=

I or

Ec------

TCHPwrTot W( ) PilotPwr W( ) PagePwr W( ) SyncPwr W( )+ + +( )Drops∑

PilotPwr W( )Drops∑

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=


9


d nonxceedsof anation

reversedata

ansmitthat

vels of

re

tatisticsto arriven across

9.5.4.7 Reverse Saturation

Reverse saturation is a reverse link statistic that is applicable to IS-2000 1X time-sliced antime-sliced simulations. The reverse saturation statistic is pegged whenever a subscriber eits maximum allowable reverse link transmit power during the power control iteration stageIS-2000 1X simulation. High numbers of saturated subscribers on the reverse link is an indicthat the reverse link load is becoming excessive or that there is a coverage constraint on thelink. Increased reverse saturation would typically be expected for the higher reverse SCHrates, since the processing gain is lower at the higher rates, which necessitates higher trpower from the subscriber unit to close the link. Refer to Table 9-4 for a list of design optionscan be used to improve RF performance, in the event that the design is experiencing high lereverse saturation.

9.5.4.7.1 IS-2000 1X (non time-sliced) Reverse Saturation

“RevNumSat_X” and “RevNumMob_X” in the IS-2000 1X non time-sliced CellStat_XX file aused to compute the reverse saturation statistics.

Table 9-11 provides a set of equations that can be used to compute the reverse saturation sper sector. In these equations, the summations are taken within sectors and across all dropsat the sector statistics. To compute the system-wide average, the summations must be takeall sectors and drops.

Table 9-11: Reverse Saturation Equations

Data Rate or Voice Equation

All data rates plus voicecombined together

Voice only

FCH only

, for RC3

, for RC4

RevNumSat All_Drops∑

RevNumMob All_Drops∑

-------------------------------------------------------------

RevNumSat v_Drops∑

RevNumMob v_Drops∑

-------------------------------------------------------

RevNumSat 9.6FCH_Drops∑

RevNumMob 9.6FCH_Drops∑

--------------------------------------------------------------------------

RevNumSat 14.4FCH_Drops∑

RevNumMob 14.4FCH_Drops∑

-----------------------------------------------------------------------------


9


liced.4.7.1,the

-sliced

licedon at

sectoring is4 has. Referevent

9.5.4.7.2 IS-2000 1X (time-sliced) Reverse Saturation

The procedures to compute the reverse saturation distribution for IS-2000 1X time-ssimulations are the same as those used for non time-sliced simulation (refer to Section 9.5"IS-2000 1X (non time-sliced) Reverse Saturation"), with the additional step of takingsummations across time-slices as well as drops. The statistics used in the IS-2000 1X timereverse saturation distribution computations are found in the CellStatTSRev_XX file.

9.5.4.8 Blocked Mobiles

The blocked mobiles statistic is applicable to IS-2000 1X non time-sliced and time-ssimulations and is pegged any time that a subscriber is unable to obtain a FCH Walsh codeleast one sector. This statistic provides an indication of Walsh code blocking on a sector bybasis. The system design ideally should have no Walsh code blocking. If Walsh code blockoccurring on a particular sector, it is an indication that the sector is becoming overloaded. RCan advantage over RC3 in that there are 128 Walsh codes available as opposed to only 64to Table 9-4 for a list of design options that can be used to improve RF performance, in thethat the design is experiencing Walsh code blocking.

All data rates combinedtogether

where the summations are taken across all data rates(X= 9.6FCH, 14.4FCH, 9.6SCH, 19.2, 38.4,76.8, and 153.6)

All SCH data rates combinedtogether

where the summations are taken across all SCH data rates(X= 9.6SCH, 19.2, 38.4,76.8, and 153.6)

Separate reverse saturation perSCH data rate

where “X” is set to the SCH rate of interest(X= 9.6SCH, 19.2, 38.4,76.8, or 153.6)

Table 9-11: Reverse Saturation Equations

Data Rate or Voice Equation

RevNumSat X_AllRates∑

Drops∑


Drops∑

---------------------------------------------------------------------------

RevNumSat X_AllSCHRates

∑Drops∑


∑Drops∑

------------------------------------------------------------------------------------

RevNumSat X_Drops∑


---------------------------------------------------------


9


rsector

s. Theations

theeslicedthe

in thetainingegoryectorfailure

meetsd in

er ofich ist thethe

p, the

S-95,langs

9.5.4.8.1 IS-2000 1X (non time-sliced) Blocked Mobiles

The “NumBlockMob_WC” and “FwdNumMob_All” statistic in the CellStat_XX file are used fothe blocked mobiles statistical analysis. The fraction of blocked subscribers is calculated perusing the following equation.

In this equation, the summations are taken within each sector and across all simulation dropsystem-wide average PcntBlockedMob statistics can also be computed by taking the summover all sectors and drops.

9.5.4.8.2 IS-2000 1X (time-sliced) Blocked Mobiles

As with IS-2000 1X non time-sliced simulation, the time-sliced simulation provides“NumBlockMob_WC” and “FwdNumMob_All” statistics in the CellStatTS_XX file. ThBlockedMob statistic is calculated using the same method described in the non time-simulation section (Section 9.5.4.8.1, "IS-2000 1X (non time-sliced) Blocked Mobiles"), withadditional step of taking the summations across time-slices as well as drops.

9.5.5 RF Voice and Data Capacity

The RF Voice and Data Capacity statistics relate to the number of subscribers (Erlangs) or,case of data, the data throughput that can be supported by the RF system design, while maina specified level of RF performance. The statistics that are included in the RF capacity catinclude total Erlangs, active Erlangs, bursting Erlangs, sector throughput, effective sthroughput, end user throughput, data rate distribution, high speed channel requestprobability, and SCH limit flag.

9.5.5.1 Total Erlangs

Total Erlangs provides an indication of capacity when the system is loaded to a point that justthe performance limits. The “Use Poisson Variation Across Drops” option is typically selectethe “CDMA Parameters” window under the “Subscribers” tab and, as such, the numbsubscribers per drop will vary according to a Poisson distribution that has a mean value whapproximately equal to the number entered in the “Mean Number of Erlangs” field (note thaname of this field changes to “Total Number of Erlangs” if “Poisson” is not selected). Sincenumber of subscribers in the simulation varies randomly from sector to sector and drop to drototal Erlangs statistic must be evaluated as a simulation output.

The total Erlangs statistic includes all subscribers in the simulation. This statistic applies to IIS-2000 1X non time-sliced, and IS-2000 1X time-sliced simulations. In all cases, the total Er

BlockedMob

NumBlockMob WC_Drops∑


--------------------------------------------------------------------=


9


ludeslicedare onibers,

le RFhan

ofe sector

thatbilestion of

dropsum,

acityits for

statistic represents effective Erlangs. For IS-2000 1X simulation, the total Erlangs statistic incboth active and dormant subscribers. Two additional Erlang statistics apply to time-ssimulation only. These are the active Erlangs statistic, which only includes subscribers whochannel (bursting or idle), and the bursting Erlangs statistic, which only includes voice subscrand data subscribers who are bursting data during the time-slice.

9.5.5.1.1 IS-95 Total Erlangs

For IS-95, total Erlangs equals the capacity when the design is at the limit of acceptabreliability. The recommended RF reliability limit is 95% for the entire system and no lower t90% for any given sector (refer to Section 9.5.4.1.1, "IS-95 RF Reliability").

The number of mobiles per sector “NumMob” from the IS-95 CellStat_XX file is the quantitysubscribers assigned to a best serving sector by the simulator. The best serving sector is ththat provides the highest Ec/Io to the subscriber. Within the simulation, it is assumed“NumMob” will have a Poisson distribution and consequently, the mean number of mo(subscribers) across all drops can be taken as the Erlang traffic load. The Poisson distributhis data has been established through studies showing that a large number of Monte Carlo(> 100 drops) satisfies this requirement. Figure 9-21: "NumMob" illustrates the mean, maximand minimum “NumMob” across sectors in a simulation.

Figure 9-21: NumMob

9.5.5.1.2 IS-2000 1X (non time-sliced) Total Erlangs

The total Erlangs statistic for an IS-2000 1X non time-sliced simulation is an indication of capwhen the system is operating at the established RF performance limits. RF performance lim


9


userd PA

rlangs

ndand

atelyatelyd ton be

ink).

totalrs andationsortedtisticsta ratetions.

miting

,,

an IS-2000 1X non time-sliced simulation can include RF reliability, sector throughput, endthroughput, data rate distribution, Ior/Ec ratio, reverse noise rise, Walsh code blocking, anpower. IS-2000 1X total Erlangs includes both active and dormant subscribers. The total Estatistic represents effective Erlangs.

Within the IS-2000 1X non time-sliced simulation CellStat_XX files, the “FwdNumMob_X” a“RevNumMob_X” statistics are used to compute the total Erlangs statistics for the forwardreverse link respectively. As indicated by the “X” suffix, these statistics are provided separfor voice and all of the SCH data rates. The “FwdNumMob_X” statistics are also separreported for each radio configuration (RC3, RC4, and RC5). The “All” statistics are usecompute the total Erlangs for all subscribers or alternatively the total Erlangs statistic cacomputed separately for voice and each data rate (and radio configuration on the forward l

The following equations (Table 9-12) illustrate a method to compute the non time-slicedErlangs statistic for one sector. The summations in the equations are taken within sectoacross all drops. The system-wide total Erlangs statistic is computed by taking the summacross all sectors and drops. A number of statistics in the CellStatTS_XX file are repseparately for each radio configuration (RC3, RC4, and RC5). If desired, composite staacross radio configurations can be created by first adding the raw statistics within a given daand across radio configurations and then using the composite statistics in the equaConversely, if desired, separate statistics can be computed for each radio configuration by lithe raw data used in the equations to the radio configuration of interest.

Table 9-12: Non Time-Sliced Total Erlangs Equations

Scenario Equation

All (Voice, all data rates, andall radio configurationscombined together. The resultsof this computation apply toboth the forward and reverselinks.)Data (All data rates and radioconfigurations combinedtogether and no voice. Theresults of this computationapply to both the forward andreverse links.) where,

X = 9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC319.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC4153.6_RC3, and 153.6_RC4

Voice (No data. The results ofthis computation apply to boththe forward and reverse links)


NumberOfDrops--------------------------------------------------------------

FwdNumMob X_AllRates

∑Drops∑

NumberOfDrops----------------------------------------------------------------------------


NumberOfDrops---------------------------------------------------------


9


cityits foruserd PA

dlangs

,

,

9.5.5.1.3 IS-2000 1X (time-sliced) Total Erlangs

The total Erlangs statistic for an IS-2000 1X time-sliced simulation is an indication of capawhen the system is operating at the established RF performance limits. RF performance liman IS-2000 1X time-sliced simulation can include RF reliability, sector throughput, endthroughput, data rate distribution, Ior/Ec ratio, reverse noise rise, Walsh code blocking, anpower.

Within the IS-2000 1X time-sliced simulation CellStatTS_XX file, the “FwdNumMob_X” an“NumDormantMob” statistics are used to compute the total Erlangs statistics. The total Er

FCH data only (No SCHassigned. The results of thiscomputation apply to both theforward and reverse links.)

where,X = 9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5

Forward, separate total Erlangsper SCH data rate and radioconfiguration

Where “X” is set to the SCH data rate of interest(X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC376.8_RC4, 153.6_RC3, or 153.6_RC4)


where,X=19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC376.8_RC4, 153.6_RC3, and 153.6_RC4

Reverse, separate total Erlangsper SCH data rate

where, “X” = 9.6SCH, 19.2, 38.4, 76.8, or 153.6Reverse, all SCH data ratescombined together

where, “X” = 9.6SCH, 19.2, 38.4, 76.8, and 153.6

Table 9-12: Non Time-Sliced Total Erlangs Equations

Scenario Equation

FwdNumMob X_AllDataFCH

∑Drops∑

NumberOfDrops-------------------------------------------------------------------------------------

FwdNumMob X_Drops∑

NumberOfDrops----------------------------------------------------------


∑Drops∑

NumberOfDrops--------------------------------------------------------------------------------------


NumberOfDrops---------------------------------------------------------


∑Drops∑

NumberOfDrops------------------------------------------------------------------------------------


9


ly theed forer).

e is norlangsgs")

nd radio

s fore given, dropseachradioacrossely, if

data

ngsta. Thetions

computations produce the same results for the forward and reverse links, therefore, onforward link equations are presented. The total Erlangs computations are only implement“All” (data and voice) and “Data” (all data rates and radio configurations combined togethThere is no significance to computing total Erlangs separately for each data rate since therway to distribute the dormant subscribers over the various data rates. Refer to the active E(Section 9.5.5.2, "Active Erlangs") and bursting Erlangs (Section 9.5.5.3, "Bursting Erlansections for equations that can be used to separately compute Erlangs for each data rate aconfiguration.

The following equations (Table 9-13) illustrate a method to compute time-sliced total Erlanga sector. The summations in the equations are taken across all time-slices and drops for thsector. To compute total system Erlangs, the summations must be taken across all sectorsand time-slices. A number of statistics in the CellStatTS_XX file are reported separately forradio configuration (RC3, RC4, and RC5). If desired, composite statistics acrossconfigurations can be created by first adding the raw statistics within a given data rate andradio configurations and then using the composite statistics in the equations. Conversdesired, separate statistics can be computed for each radio configuration by limiting the rawused in the equations to the radio configuration of interest.

9.5.5.2 Active Erlangs

Active Erlangs is a statistic that is unique to IS-2000 1X time-sliced simulation. Active Erlaincludes subscribers who are bursting data or who are on-channel but are not bursting daonly difference between the active Erlangs and total Erlangs statistics for time-sliced simula

Table 9-13: Time-Sliced Total Erlangs Equations

Scenario Equation

All (Voice, all datarates, and all radioconfigurationscombined together.The results of thiscomputation apply toboth the forward andreverse links.)Data (All data ratesand radioconfigurationscombined togetherand no voice. Theresults of thiscomputation apply toboth the forward andreverse links.)

where,X =9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC3,19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC4, 153.6_RC3,and 153.6_RC4

FwdNumMob All NumDormantMob+_( )Time Slices–∑

Drops∑

NumberOfTimeSlices NumberOfDrops×-----------------------------------------------------------------------------------------------------------------------------------------------------


NumDormantMob+

Time Slices–∑

Drops∑

NumberOfTimeSlices NumberOfDrops×-------------------------------------------------------------------------------------------------------------------------------------------------------------------------


9


andtedtes.

C5).ctivey.

tisticstakenrlangsin the5). Ife rawpositeh radio

rest.

,,

is that active Erlangs does not include subscribers who are dormant.

Active Erlangs are calculated on the forward and reverse links using the “FwdNumMob_X”“RevNumMob_X” statistics from the CellStatTS_XX and CellStatTSRev_XX files. As indicaby the “X” suffix, these statistics are provided separately for voice and all data ra“FwdNumMob_X” is also provided separately for each radio configuration (RC3, RC4, and RThe “All” statistics can be used to compute active Erlangs for all subscribers or alternatively, aErlangs for voice, each data rate, and each radio configuration can be computed separatel

The following equations (Table 9-14) illustrate a method to compute the active Erlangs stafor time-sliced simulations and for a given sector. The summations in the equations arewithin sectors and across all time-slices, sectors, and drops. The system-wide active Estatistics are computed by summing across all sectors and drops. A number of statisticsCellStatTS_XX file are reported separately for each radio configuration (RC3, RC4, and RCdesired, composite statistics across radio configurations can be created by first adding thstatistics within a given data rate and across radio configurations and then using the comstatistics in the equations. Conversely, if desired, separate statistics can be computed for eacconfiguration by limiting the raw data used in the equations to the radio configuration of inte

Table 9-14: Active Erlangs Equations

Scenario Equation

All (Voice, all data rates, andall radio configurationscombined together. The resultsof this computation apply toboth the forward and reverselinks.)Data (All data rates and radioconfigurations combinedtogether and no voice. Theresults of this computationapply to both the forward andreverse links.) where,

X =9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC319.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC4153.6_RC3, and 153.6_RC4

Voice (No data. The results ofthis computation apply to boththe forward and reverse links.)

FwdNumMob All_Time Slices–

∑Drops∑

NumberOfTimeSlices NumberOfDrops×------------------------------------------------------------------------------------------------------------


Time Slices–∑

Drops∑


FwdNumMob v_Time Slices–

∑Drops∑



9


wardd

hedatag (besttheve the

d in theTheverseivity

,

,,

9.5.5.3 Bursting Erlangs

For IS-2000 1X time-sliced simulation, the bursting Erlangs statistic is calculated on the forand reverse links using the “FwdBurstTot”, “RevBurstTot”, “FwdNumMob_X”, an“RevNumMob_X” statistics from the CellStatTS_XX and CellStatTSRev_XX files. T“FwdBurstTot” statistic is a count of the number of voice subscribers plus the number ofsubscribers who were actively bursting data and have the given sector as its best servinEc/Io pilot strength) sector on the forward link. The “RevBurstTot” statistic is a count ofnumber of voice subscribers plus data subscribers who are actively bursting data and hagiven sector as its best serving sector on the reverse link. The voice subscribers are include“FwdBurstTot” and “RevBurstTot” statistics and burst continuously during the simulation.subscriber voice activity is accounted for by applying scaling factors to the forward and relink transmit powers (refer to Chapter 6 for additional information on setting the voice actfactor).


where,X =19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC376.8_RC4, 153.6_RC3, and 153.6_RC4

Forward, separate activeErlangs per data rate and radioconfiguration

where,X =9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC319.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC4153.6_RC3, or 153.6_RC4


where, “X” = 9.6SCH, 19.2, 38.4, 76.8, and 153.6Reverse, separate activeErlangs per data rate

where “X” is the data rate of interest, “X” = 9.6FCH, 14.4FCH,9.6SCH, 19.2, 38.4, 76.8, or 153.6

Table 9-14: Active Erlangs Equations

Scenario Equation


∑Time Slices–

∑Drops∑NumberOfTimeSlices NumberOfDrops×

----------------------------------------------------------------------------------------------------------------

FwdNumMob X_Time Slices–

∑Drops∑



∑Time Slices–

∑Drops∑NumberOfTimeSlices NumberOfDrops×---------------------------------------------------------------------------------------------------------------

RevNumMob X_Time Slices–

∑Drops∑



9


tisticsss allations

n the5). Ife rawpositeh radio

rest.

4,

The following equations (Table 9-15) illustrate a method to calculate the bursting Erlangs stafor time-sliced simulation on the forward link for one sector. The summations are taken acrotime-slices and drops. To compute the system-wide bursting Erlangs statistics, the summmust be taken across all time-slices, drops, and sectors. A number of statistics iCellStatTS_XX file are reported separately for each radio configuration (RC3, RC4, and RCdesired, composite statistics across radio configurations can be created by first adding thstatistics within a given data rate and across radio configurations and then using the comstatistics in the equations. Conversely, if desired, separate statistics can be computed for eacconfiguration by limiting the raw data used in the equations to the radio configuration of inte

Table 9-15: Forward Link Bursting Erlangs Equations

Scenario Equation

All (voice, all datarates, and all radioconfigurationscombined together)Data (all data ratesand radioconfigurationscombined together;no voice)Voice (all voicesubscribers and nodata)

FCH data

Where, =

X=9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5All SCH data ratesand radioconfigurationscombined together

where,X = 19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC153.6_RC3, and 153.6_RC4

FwdBurstTotTime Slices–

∑Drops∑


FwdBurstTot FwdNumMob v_–( )Time Slices–

∑Drops∑

NumberOfTimeSlices NumberOfDrops×----------------------------------------------------------------------------------------------------------------------------------

FwdNumMob v_Time Slices–

∑Drops∑


FwdNumMobAllFCH∑ X FwdNumMobFCHIdle–_

Time Slices–

∑Drops∑

NumberOfTimeSlices NumberOfDrops×---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FwdNumMobFCHIdle

FwdNumMob All FwdBurstTot–_


∑Time Slices–

∑Drops∑NumberOfTimeSlices NumberOfDrops×

----------------------------------------------------------------------------------------------------------------


9


tisticsss allations

4,

The following equations (Table 9-16) illustrate a method to calculate the bursting Erlangs stafor time-sliced simulation on the reverse link for one sector. The summations are taken acrotime-slices and drops. To compute the system-wide bursting Erlangs statistics, the summmust be taken across all time-slices, drops, and sectors.

Separate burstingErlangs per SCH datarate and radioconfiguration

where,X = 19.2_RC3, 19.2_RC4, 38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC153.6_RC3, or 153.6_RC4

Table 9-16: Reverse Link Bursting Erlangs Equations

Scenario Equation

All, voice and all datarates combinedtogether

Data, all data ratescombined togetherand no voice

Voice, all voicesubscribers and nodata

FCH data

Where,

=

and,

=

Table 9-15: Forward Link Bursting Erlangs Equations

Scenario Equation

FwdNumMob X_Time Slices–

∑Drops∑


RevBurstTotTime Slices–

∑Drops∑


RevBurstTot RevNumMob v_–( )Time Slices–

∑Drops∑

NumberOfTimeSlices NumberOfDrops×-------------------------------------------------------------------------------------------------------------------------------

RevNumMob v_Time Slices–

∑Drops∑


RevNumMob FCH RevNumMob FCH_ Idle–_( )Time Slices–

∑Drops∑

NumberOfTimeSlices NumberOfDrops×---------------------------------------------------------------------------------------------------------------------------------------------------------------------

RevNumMob FCH_

RevNumMob 9.6FCH RevNumMob 14.4FCH_+_

RevNumMob FCH_ Idle

RevNumMob All RevBurstTot–_


9


relatedughputin this

nd callhen

re aretion fore), andes the

ics byd by

s usedCH”,”,XX

licedd useribersile)stem is

s and

9.5.5.4 End User Throughput

End user throughput provides an indication of the end user data experience and is directlyto the amount of time it takes to service an end user data request. Higher end user throcorresponds to faster data transfer times. Only the end user application bits are includedthroughput metric.

End user throughput is a function of system loading, the mix of voice and data subscribers, amodels for IS-2000 1X time-sliced simulation. End user throughput typically increases wsystem loading is low (low loading translates to available capacity for higher data rates), thefew data subscribers in the system (fewer data subscribers means that there is less contenthe available data resources and therefore a better probability of receiving a higher data ratthe data file sizes are large (less time spent in TCP slow start and larger files increaslikelihood that SCH’s will be requested).

9.5.5.4.1 IS-2000 1X (non time-sliced) End User Throughput

An estimate of end user throughput can be computed from non time-sliced simulation statistapplying a scaling factor to the air interface data rate to account for overhead bits anappropriately derating the throughput to account for RLP retransmissions. The raw statisticin the non time-sliced simulation end user throughput calculations are “FwdRateS“FwdFERFCH”, “FwdFERSCH”, “RevRateSCH”, “RevFERFCH”, “RevFERSCH“ServiceType”, “ID”, and “Srv1”. These statistics are found in the IS-2000 1X MobileStat_file.

The following equations illustrate a method to estimate end user throughput for non time-ssimulation on the forward and reverse links for one subscriber. To compute the mean enthroughput for a given sector, all of the individual subscriber throughput statistics for subscrin the given sector (where the sector is identified in the “Srv1” column of the MobileStat_XX fmust be averaged together across all drops. The mean end user throughput for the entire syobtained by averaging all of the individual subscriber throughput statistics across all drop

All SCH data ratescombined together

where, “X” = 9.6SCH, 19.2, 38.4, 76.8, and 153.6Separate burstingErlangs per SCH datarate

where, “X” = 9.6SCH, 19.2, 38.4, 76.8, or 153.6

Table 9-16: Reverse Link Bursting Erlangs Equations

Scenario Equation


∑Time Slices–

∑Drops∑NumberOfTimeSlices NumberOfDrops×---------------------------------------------------------------------------------------------------------------

RevNumMob X_Time Slices–

∑Drops∑



9


frame

a rateulated

is9” isfore,hput

s arere

resent

ted perns.

sectors.

Forward radio configurations 3 and 4 with reverse radio configuration 3:

Forward radio configuration 5 with reverse radio configuration 4:

In these equations, “Ovhd” represents the reduction in throughput associated with the airquality indicator bits, encoder tail bits, and MAC overhead bits. “OvhdRate” is 0.875 for all datarates other than 9.6 kbps and 14.4 kbps, which use “Ovhd9.6” set to 0.833 and “Ovhd14.4” set to

0.889 respectively. The factor in the denominator is used to derate the raw datby the estimated RLP retransmission factor, where the estimate is made according to the simFER (“FwdFERFCH”, “FwdFERSCH”, “RevFERFCH”, and “RevFERSCH”). The “k” valueset to 2 for the non-segmented Type 3 RLP that is used with IS-2000 1X. Note that “-999recorded in the “FwdFERSCH” and “RevFERSCH” column when no SCH is assigned. Thereit is necessary to filter out these values prior to implementing the end user througcomputations.

9.5.5.4.2 IS-2000 1X (time-sliced) End User Throughput

The raw statistics used in the time-sliced simulator end user throughput calculation“MobileState”, “StateTime”, “BytesTX”, “CallModelIndex”, and “Srv1”. These statistics afound in the MobileTputStat_XX file.

Time-sliced end user throughput can be computed using two different methods which reptwo different perspectives as follows:

• Average end user experience perspective

• Time-averaged throughput perspective

Using the first method (average end user experience), the end user throughput is compusubscriber per bursting period on the forward and reverse links using the following equatio

EndUserTputFwd

9.6( ) Ovhd9.6( )1 k FwdFERFCH 0.01××+------------------------------------------------------------------------

FwdRateSCH( ) OvhdRate( )1 k FwdFERSCH 0.01××+-----------------------------------------------------------------------+

Kbps=

EndUserTputRev

9.6( ) Ovhd9.6( )1 k RevFERFCH 0.01××+----------------------------------------------------------------------

RevRateSCH( ) OvhdRate( )1 k RevFERSCH 0.01××+---------------------------------------------------------------------+

Kbps=

EndUserTputFwd

14.4( ) Ovhd14.4( )1 k FwdFERFCH 0.01××+------------------------------------------------------------------------Kbps=

EndUserTputRev

14.4( ) Ovhd14.4( )1 k RevFERFCH 0.01××+----------------------------------------------------------------------Kbps=

1 k FER×+


9


stateS”,entire

htedation oft resultriod is

, whered to

urstingF”,

he datathe

ely forrting thelMapenced as

In these equations, the vertical parallel line symbol ( || ) indicates “or”, therefore, the mobilecan equal any of the listed states (“FF” or “FS” are forward link bursting states and “RF”, “Ror “RD” are reverse link bursting sates). The end user throughput experience statistics for thesystem are calculated by separately averagingEndUserTputPerBurstFwd andEndUserTputPerBurstRevover all drops, time-slices, and sectors. This represents an unweigaverage of the end user throughput per bursting period and can be considered as an indicthe average end user throughput experience. However, this computation approach does noin the actual time averaged end user throughput, since the time aspect of each bursting pelost.

Method 2 for computing time-sliced end user throughput uses a weighted average approachthe weighting factor is the burst duration (“StateTime”). The following equations are usecompute the mean end user throughput over the entire system with this approach.

In these equations, the summations are taken across all bursting periods for all drops. The bperiods are identified by the “FF” and “FS” mobile state for the forward link and by the “R“RS”, and “RD” mobile state for the reverse link.

For either computation method, separate statistics can be computed per sector by sorting taccording to the best serving sector, which is recorded in the “Srv1” column inMobileTputStat_XX file. Once the data is sorted, the computations are implemented separateach sector. If desired, separate averages can also be computed per service type by first sodata according to the call model, which is obtained by cross-referencing it from the CallModefile using the number in the “CallModelIndex” column of the MobileTputStat_XX file. Whcomputing mean end user throughput per sector or per call model, the sample size is redu

EndUserTputPerBurstFwd

BytesTxMobileState FF= FS|| 8×StateTime

----------------------------------------------------------------------------- Bps=

EndUserTputPerBurstRev

BytesTxMobileState RF RS RD|| ||=

8×StateTime

---------------------------------------------------------------------------------------- Bps=

EndUserTputFwd

BytesT XMobileState FF FS||=

8×AllFwdBurstingPeriods

∑StateTime

AllFwdBurstingPeriods∑

--------------------------------------------------------------------------------------------------------------------------------

bps=

EndUserTputRev

BytesT XMobileState RF RS RD|| ||=

8×AllRevBurstingPeriods

∑StateTime

AllRevBurstingPeriods∑

-----------------------------------------------------------------------------------------------------------------------------------------

bps=


9


f these

condmittedinks.

and

d callhenapacityP slow

s areX

rward

ta ratesRC4,

nl of the

nherente eventuld beputed

X”

compared to computing the mean for all sectors and call models. Therefore, the accuracy ostatistics will be lower than for the system-wide statistics.

9.5.5.5 Sector Throughput

Sector throughput provides an indication of sector data capacity in units of bits per se(or kbps). The sector throughput metric includes overhead and end user application bits transover the air interface for all links in the sector including best server, soft, and softer handoff lIS-2000 1X non time-sliced sector throughput includes all air frame bits whereas the CRCencoder tail bits are excluded from IS-2000 1X time-sliced sector throughput.

Sector throughput is a function of system loading, the mix of voice and data subscribers, anmodels for IS-2000 1X time-sliced simulation. Sector throughput is typically maximized wsystem loading is moderate, all of the subscribers in the system are data subscribers (no cis being used for voice subscribers), and the data file sizes are large (less time spent in TCstart and larger files increases the likelihood that SCH’s will be requested).

9.5.5.5.1 IS-2000 1X (non time-sliced) Sector Throughput

The raw statistics used in the non time-sliced simulation sector throughput calculation“FwdLinks_X” and “RevLinks_X”. These statistics are found in the IS-2000 1X CellStat_Xfiles. The following equations illustrate a method to estimate the sector throughput on the foand reverse links for one sector for an IS-2000 1X non time-sliced simulation.

In these equations, the summations are taken within sectors, across all drops, and over all daand radio configurations (X=9.6FCH_RC3, 9.6FCH_RC4, 14.4FCH_RC5, 19.2_RC3, 19.2_38.4_RC3, 38.4_RC4, 76.8_RC3, 76.8_RC4, 153.6_RC3, and 153.6_RC4; and Y = 9.6FCH,14.4FCH, 9.6SCH, 19.2, 38.4, 76.8, and 153.6). “Data_Rate” is replaced by the actual data rate ibits per second. The system-wide sector throughput is computed by taking the average of alindividual sector throughput statistics.

The above equations represent an upper bound on sector throughput since there is an iassumption that the links are good and are therefore supporting the given data rates. In ththat a large number of the links are bad (i.e. high FER), then the actual sector throughput wolower than indicated by these equations. A lower bound on the sector throughput can be comby replacing “FwdLinks_X” and “RevLinks_X” in the above equations by “FwdLinksGood_

SectorTputFwd

FwdLinks X_( ) Data Rate_( )×AllRates

∑Drops∑

NumberOfDrops------------------------------------------------------------------------------------------------------------------

bps=

SectorTputRev

RevLinks Y_( ) Data Rate_( )×AllRates

∑Drops∑

NumberOfDrops----------------------------------------------------------------------------------------------------------------

bps=


9


hes iny little

arethe

theheks by

given

ns arein the

resentnd thets), theeragedector isr. Thissector

lowing

age ofed in

and “RevLinksGood_X”. It is recommended to compute these equations using both approacorder to obtain the upper and lower bounds on the sector throughput. There should be verdifference between the two results when the RF reliability is high.

9.5.5.5.2 IS-2000 1X (time-sliced) Sector Throughput

The raw statistics used in the time-sliced simulation sector throughput calculations“SectTput_X”, “NumFrames_X”, and “Fwd/Rev”. These statistics are found inSectorTputStat_XX file.

The forward and reverse link sector throughput statistics are distinguished inSectorTputStat_XX file using the “Fwd” and “Rev” designation in the “Fwd/Rev” column of tfile. Sector throughput is calculated using the same method for the forward and reverse linfirst separating the data according to link. A method to compute sector throughput for asector is illustrated with the following equation:

In these equations, the “X” suffix is replaced by the sector number of interest. The summatiotaken within sectors and across all drops and across all one second reporting intervalsSectorTputStat_XX file.

There are two methods to compute the system-wide sector throughput statistics, which reptwo subtly different perspectives, namely the average of sector throughput perspective aaverage sector throughput perspective. Using the first method (average of sector throughpuindividual sector throughput statistics, as computed using the above equation, are simply avtogether. This approach provides an unweighted average of sector throughput where each streated equally without regard to the amount of data that was actually transmitted in the sectomethod results in the average of sector throughputs but does not provide the averagethroughput.

The second method provides the actual average system sector throughput using the folequation.

In this equation, the mean sector throughput statistic is computed as the weighted averindividual sector throughputs, where the weighting factor is the number of frames transmittthe sector (amount of time transmitting).

AveSecTput

NumFrames X SectTput X_×_( )1SecReportingIntervals

∑Drops∑

NumFrames X_1SecReportingIntervals

∑Drops∑

-----------------------------------------------------------------------------------------------------------------------------------------------------

bps=

AveSysSecTput

NumFrames X SectTput X_×_( )Sectors∑

1SecReportingIntervals∑

Drops∑

NumFramesSectors∑

1SecReportingIntervals∑

Drops∑

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

bps=


9


ludesad bitshputhputhput ofrhead

put of

tation”,1X

endextra

re not

e enduser

t. Refert. Theon are

v1”

er.

in thatdone

ge ofly for

ectorector

9.5.5.6 Effective Sector Throughput

The sector throughput statistic described in Section 9.5.5.5, "Sector Throughput" incapplication bits, overhead bits, and bits associated with frame retransmissions. The overheare comprised of MUX, RLP, and framing overhead. Also included in the sector througstatistic are bits from all one-way, soft, and softer handoff links. As such, this is a raw througstatistic that represents air interface data loading; however, does not represent the througend user application bits. The effective sector throughput statistic removes much of the ovefrom the sector throughput statistic to provide a metric that more closely reflects the throughthe end user application bits.

9.5.5.6.1 IS-2000 1X (non time-sliced) Effective Sector Throughput

The raw statistics used in the IS-2000 1X non time-sliced effective sector throughput compuare “FwdRateSCH”, “FwdFERFCH”, “FwdFERSCH”, “RevRateSCH”, “RevFERFCH“RevFERSCH”, “ServiceType”, “ID”, and “Srv1”. These statistics are found in the IS-2000MobileStat_XX file.

The effective sector throughput statistic for IS-2000 1X non time-sliced simulation includesuser application bits; however, removes MUX, RLP, and air-frame bits and also removes thebits associated with RLP retransmissions. Bits associated with soft and softer handoff aincluded in the effective sector throughput computation.

The approach for estimating effective sector throughput in a given sector is to first compute thuser throughput for all of the best served subscribers in the sector. Once all of the endthroughput values are computed, they are summed together to arrive at the sector throughputo Section 9.5.5.4, "End User Throughput", for the procedure to compute end user throughpusteps used to estimate effective sector throughput for an IS-2000 1X non time-sliced simulatias follows:

• Sort the IS-2000 1X MobileStat_XX file according to the best server sector (“Srcolumn)

• Compute the forward and reverse link end user throughput for each data subscrib

• For each sector, sum the end user throughput for all of the best served subscriberssector. This is the effective sector throughput for that sector and drop. This isseparately for the forward and reverse link.

• To compute a system-wide effective sector throughput statistic, calculate the averathe effective sector throughputs from each individual sector. This is done separatethe forward and reverse link.

9.5.5.6.2 IS-2000 1X (time-sliced) Effective Sector Throughput

Statistics contained in the MobileTputStat_XX files can be used to compute an effective sthroughput for time-sliced simulations. The procedure to compute time-sliced effective s


9


nted.5.5.5,icedquired

timeer ofas onhe

efore,given

userlicedd alsotime-t andghput

figureis 105rt timer frame

throughput from the MobileTputStat_XX statistics is somewhat involved and is best implemeusing a post processing script. In many cases, the sector throughput statistic (Section 9"Sector Throughput") will be sufficient; however, an approach to computing the time-sleffective sector throughput statistic is being presented here in the event that this metric is reto meet a specific RF design objective.

For each upload or download event, there is a record in the MobileTputStat_XX file of the endof the data burst (“ElapsedTime”), the duration of the data burst (“StateTime”), the numbbytes of end user data that were bursted (“BytesTX”), an indication of whether the burst wthe forward or reverse link (“MobileState”), and the best serving sector (“Srv1”). T“ElapsedTime and “StateTime” statistics are logged in increments of 20 ms (one frame); therthe mean end user throughput can be computed per frame for each of the users within asector.

The effective sector throughput statistic for IS-2000 1X time-sliced simulation includes endapplication bits only. Therefore, the effective sector throughput computation for time-ssimulations removes the MAC, RLP (overhead and retransmission), and air frame bits; anaccounts for TCP slow start and scheduling delays. This is in contrast to IS-2000 1X nonsliced effective sector throughput, which does not inherently account for TCP slow starscheduling delays. Soft and softer handoff bits are excluded from the effective sector throustatistic.

Figure 9-22 illustrates a method to compute mean end user throughput per frame. Thisdepicts a short segment of data for a given subscriber. For this example, “ElapsedTime”seconds, “StateTime” is 0.220 seconds, and “BytesTX” is 508. Using these statistics, the staof the data burst, the start and end frame number, and the average end user throughput pefor the given data burst can be computed as follows:

StartTime ElapsedTime StateTime–=

StartFrameStartTime

0.02-------------------------- 1+=

EndFrameElapsedTime

0.02----------------------------------=

AverageTputPerFrameBytesTX 8×StateTime

-------------------------------=


9


ervedfile)bscribergivenat the

ratedings in thisframe

r eachle, the

t thef theeriod

allut perloade cansector

ngthth canmean

Figure 9-22: End User Throughput Per Frame

The average end user throughput for all the frames in the simulation and for all the best ssubscribers in the given sector (as identified in the “Srv1” column of the MobileTputStat_XXare computed as described above. The average end user throughput per frame for each suin the sector is then summed together to arrive at the effective sector throughput for theframe. The effective sector throughput per frame is then averaged across all frames to arrivemean effective sector throughput statistic.

Figure 9-23 illustrates the effective sector throughput computation. This figure was geneusing NetPlan data from the MobileTputStat_XX file. In this figure, the forward link burstframes for each subscriber are colored according to the data rate. There are 24 subscribersector, each bursting data according to its assigned call model. The bottom row contains theby frame effective sector throughput, which is the sum of the mean end user throughput foof the subscribers who were bursting data during the given frame. For this particular exampaverage effective sector throughput is 68,120 bps.

One potential concern with this procedure for computing effective sector throughput is thaMobileTputStat_XX file logs the data throughput at the end of a bursting period. If the end obursting period exceeds the end of the simulation time, then the throughput for that bursting pwill not be logged in the MobileTputStat_XX file. This issue will typically only introduce a smerror in the effective sector throughput computation by skewing the effective sector throughpframe toward lower values near the end of the simulation time. However, if the mean downtime is large in comparison to the simulation length, then the error associated with this issubecome large. This issue should be considered when interpreting the results of the effectivethroughput analysis. To mitigate the potential for error in this computation, simulation leshould be long as compared to the mean download time and, if need be, the simulation lengbe extended and the frames near the end of the simulation time can be excluded from theeffective sector throughput computation.


9


o werecribersrs areof the

ntee aratesm the

r bothare

Figure 9-23: Effective Sector Throughput

9.5.5.7 Data Rate Distribution

The data rate distribution statistic provides a measure of the fraction of data subscribers whassigned to each of the available data rates. For time-sliced simulations, only the data subswho are actively bursting data are included in this computation. Dormant data subscribeexcluded. Since all data subscribers in a non time-sliced simulation burst continuously, allsubscribers are included in the non time-sliced data rate distribution computation.

The data rate distribution is of interest to system designers since there is no way to guaraparticular data rate in an IS-2000 1X system. The only way to know the distribution of datathat are achievable for a given system design and load is to compute the distribution frosimulation data.

9.5.5.7.1 IS-2000 1X (non time-sliced) Data Rate Distribution

The raw statistics used in the non time-sliced simulation data rate distribution calculations fothe forward and reverse links are “FwdNumMob_X” and “RevNumMob_X”. These statisticsfound in the IS-2000 1X CellStat_XX file.


9


ctionhod toRadiod, them ther for

data

takinge datatotalta ratein thesector

th the,csingnnels.

The data rate distribution on the forward and reverse links is computed by determining the fraof data subscribers assigned to each data rate. The following equations provide a metcompute the data rate distribution on the forward and reverse links for all sectors and drops.configuration 3 and radio configuration 4 are combined together in these equations. If desireequations can be computed separately for each radio configuration by using statistics only froradio configuration of interest. The only data rate supported in the NetPlan CDMA SimulatoRC5 is 14.4 kbps, therefore, there is no data rate distribution for RC5.

where, “Y” is replaced by a particular data rate of interest and “X” is replaced by all of therates (Y and X= 9.6FCH, 9.6SCH (reverse only), 19.2, 38.4, 76.8, and/or 153.6 kbps).

As seen in these equations, the data rate distribution for the entire system is generated bythe ratio of the number of subscribers assigned to a given data rate to the sum of all of thsubscribers. This is equivalent to saying that the data rate distribution is the ratio of theErlangs per data rate divided by the total Erlangs for all data rates combined together. The dadistribution for a particular sector can be computed by removing the summation of sectorsabove equation and implementing the remaining summations using statistics from only theof interest (as identified in the “CellName” column of the CellStat_XX file).

9.5.5.7.2 IS-2000 1X (time-sliced) Data Rate Distribution

The raw statistics used in the time-sliced simulation data rate distribution calculations for boforward and reverse links are “FwdNumMob_X”, “RevNumMob_X”, “FwdNumMob_All”“RevNumMob_All”, “FwdBurstTot”, and “RevBurstTot”. The forward and reverse link statistiare found in the CellStatTS_XX and CellStatTSRev_XX files respectively. The followequations provide a method to compute the data rate distribution for the supplemental cha

FwdDist Y_

FwdNumMob Y RC3 FwdNumMob Y RC4_ _+_ _( )Sectors∑

Drops∑

FwdNumMob X RC3 FwdNumMob X RC4_ _+_ _( )AllRates

∑Sectors∑

Drops∑

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=

RevDist Y_

RevNumMob Y_Sectors∑

Drops∑

RevNumMob X_AllRates

∑Sectors∑

Drops∑

------------------------------------------------------------------------------------------=

FwdDist Y_

FwdNumMob Y RC3 FwdNumMob Y RC4_ _+_ _( )Time Slices–

∑Sectors∑

Drops∑


∑Sectors∑

Drops∑

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=


9


19.2,

signedarate

the

for the

where, “Y” is replaced by a particular SCH data rate of interest (Y= 9.6SCH (reverse only),38.4, 76.8, or 153.6 kbps).

The following equations can be used to compute the fraction of data subscribers that are asto only a FCH (i.e. no SCH assigned) for all radio configurations combined together. Sepstatistics can be computed per radio configuration by limiting the raw statistics used incomputation to the radio configuration of interest.

where,

X=9.6FCH_RC3, 9.6FCH_RC4, and 14.4FCH_RC5

where,

and,

In these equations, the data rate distribution is computed as the ratio of the bursting Erlangsgiven data rate to the bursting Erlangs for all data rates combined together.

RevDist Y_

RevNumMob Y_Time Slices–

∑Sectors∑

Drops∑


∑Sectors∑

Drops∑

----------------------------------------------------------------------------------------------------------------------------------------------=

FwdDist FCH_

FwdNumMob FCH FwdNumMobFCHIdle–_Time Slices–

∑Sectors∑

Drops∑


∑Sectors∑

Drops∑

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------=

FwdNumMobFCHIdle FwdNumMob All FwdBurstTot–_=

FwdNumMob FCH_ FwdNumMob X_AllFCH

∑=

RevDist FCH_

RevNumMob FCH RevNumMob FCH_ Idle–_Time Slices–

∑Sectors∑

Drops∑


∑Sectors∑

Drops∑

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=

RevNumMob FCH_ RevNumMob 9.6FCH RevNumMob 14.4FCH_+_=

RevNumMob FCH_ Idle RevNumMob All RevBurstTot–_=


9


datasignsif thetisticsto beent of

whoseive aettingshold).speedrequired

ratete was

tage”en thelist ofign is

” and

entire

(e.g.n canacross

drops,

tem ist failed

9.5.5.8 High Speed Channel Request Failure Probability

High speed channel request failure probability is a good metric for assessing forward link SCHrate assignments. The forward link SCH allocation algorithm in a time-sliced simulation asthe minimum data rate required to transmit the bearer bits over the next time-slice. As such,design goal is to provide high speed data service, then the data rate distribution sta(Section 9.5.5.7, "Data Rate Distribution") may be misleading since the data rates tendskewed towards lower speeds if the data subscriber call models do not require the assignmhigh speed channels. The “FailedSCHReqs_X” statistic is pegged every time a subscriber,data requirements merit a forward link supplemental channel of a given rate, fails to recesupplemental channel of a minimum user definable rate (refer to Chapter 6 for details on sthe “Fwd. Data Rate Outage” parameter, which is the high speed channel request failure threAs such, the “FailedSCHReqs_X” statistic distinguishes between the case where a highchannel was requested but not received and the case where a high speed channel was notto begin with. Note that the “FailedSCHReqs_X” statistic is not pegged if the requested SCHis lower than the “Fwd. Data Rate Outage”, regardless of whether or not the requested raassigned.

High speed channel request failure probability will be higher when the “Fwd. Data Rate Ouparameter is set high. High speed channel request failure probability will also increase whsystem is becoming forward link capacity or coverage constrained. Refer to Table 9-4 for adesign options that can be used to improve RF performance, in the event that the desbecoming capacity or coverage constrained.

The raw statistics used to calculate high speed channel request failure are “FwdNumMob_X“FailedSCHReqs_X”. These statistics are found in the CellStatTS_XX files.

The following equation illustrates the high speed channel request failure calculation for thesystem, all drops, and all time-slices.

In the above equation, the statistics can be taken from within one radio configurationFailedSCHReqs_RC3 or FailedSCHReqs_RC4) or the statistics for each radio configuratiobe summed together prior to the computation. The summations in the equation are takendrops, sectors and time-slices to arrive at the system-wide HSReqFailSys. High speed channelrequest failure can be computed per sector by taking the summations within sectors, acrossand across time-slices.

As seen in this equation, the high speed channel request failure probability for the entire syscalculated as a ratio where the numerator is the sum of all high speed channel requests tha

HSReqFailSys

FailedSCHReqs X_Time Slices–

∑Sectors∑

Drops∑

FailedSCHReqs X_ FwdNumMob X_X Outage=

153.6

∑+

Time Slices–∑

Sectors∑

Drops∑---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------=


9


of all

lg”.t arerovide

g the

ntryard

wasacity

verse

m thethink

overned

to receive a SCH at or above the “Fwd. Data Rate Outage” and the denominator is the sumof the high speed channel requests at or above the “Fwd. Data Rate Outage”.

9.5.5.9 SCH Limit Flag

The MobileStat_XX (IS-2000 1X) and MobileStatTS_XX files contain a statistic named “XsFThis is a useful statistic for investigating the factors that are limiting the SCH data rates thabeing assigned to a subscriber. If the assigned data rates appear to be low, this statistic will preasons for the low rates.

The “XsFlg” field is a concatenation of six possible codes that represent a reason for limitinSCH data rate. The code definitions are shown in Table 9-17.

A dash (“-”) is inserted in place of a code when the condition is not true, therefore, a typical ein the XsFlg column might be -C----, which indicates that the SCH data rate was limited by forwlink capacity (Ior/Ec). Multiple codes may be entered to signify that more than one limitexceeded. As an example, GC-M-- would indicate that the maximum SCH gain and Ior/Ec caplimits were exceeded on the forward link and the subscriber unit maximum power on the relink was exceeded during the request portion of the SCH assignment algorithm.

9.5.6 Data Call Model Characterization

A number of IS-2000 1X call model parameters can be either validated or characterized frotime-sliced simulation output statistics. The specific parameters that can be validated aretime, download size and time, and reverse request size and time. These parameters are g

Table 9-17: XsFlg Codes

Code Definition

G The maximum forward link SCH gain allowed for therequested data rate was exceeded.

C Ior/Ec exceeded the forward link “Ior/Ec CapacityThreshold” for the requested SCH data rate. “Ior/EcCapacity Threshold” is an input parameter (refer to Chapter6).

W No Walsh code available for the requested SCH data rate.N Noise rise exceeded the “Rise Capacity Threshold” for the

requested reverse link SCH data rate. “Rise CapacityThreshold” is an input parameter (refer to Chapter 6).

M Mobile transmit power exceeded the maximum allowed forthe requested SCH data rate during the request portion ofthe reverse SCH assignment algorithm.

S Saturated. Mobile power exceeded the maximum during thereverse link power convergence algorithm.

- For any of the above which is not True.


9


mparedsignters arerd datativethese0 1X

nextbutionution. Meanional

pute

en

rdte”

er,rst

y in

eachhen

and

by the call model inputs and, as such, the expected means can be readily computed and coto the actual mean values from the simulation results. Although it is not strictly a derequirement to validate these call model parameters, it is recommended since these paramebased on Pareto distributions. The call model parameters that can be characterized are forwaactivity factor, reverse data activity factor, probability of going dormant, and length of the acand dormant periods. Again, it is not an RF simulation design requirement to computeparameters. However, they are typically required as inputs to a number of further IS-200system design activities, such as equipment sizing.

9.5.6.1 Think Time

Think time is the amount of time between the end of a download on the forward link and thereverse request on the uplink. Think time is governed by a set of input truncated Pareto distriparameters (refer to Chapter 6 for additional information on setting the Pareto distribparameters) and, as such, the expected value of the think time is straight forward to computethink time is provided as an output on the NetPlan Call Models tab (refer to Chapter 6 for additinformation on the Call Models tab).

The “MobileID”, “MobileState”, “ElapsedTime”, and “StateTime” fields in theMobileTputStat_XX file are used to compute the mean think time statistic. A procedure to commean think time is as follows:

• Sort the MobileTputStat_XX file for a given drop according to the “MobileID” and thchronologically (“ElapsedTime”) within each “MobileID” (Note: sorting by “MobileID” should automatically result in the correct chronological order).

• For each “MobileID”, the start of a think time period is identified by an “FF” (forwaburst fundamental) or “FS” (forward burst supplemental) entry in the “MobileStacolumn. This indicates the end of a forward download.

• For each “FF” or “FS” entry in the “MobileState” column for the given subscribidentify the next reverse bursting period by locating the first “RF” (reverse bufundamental), “RS” (reverse burst supplemental), or “RD” (reverse burst DTX) entrthe “MobileState” column after the “FF” or “FS” entry.

• Compute the think time as:

• Use this equation to compute the think time associated with each forward burst forsubscriber and for all drops in the simulation. The resulting think times are taveraged together to compute the mean think time statistic for the simulation run.

• Note that this approach results in a mean think time that includes both active-idledormant time.

ThinkTime ElapsedTimeRevBurst

StateTimeRevBurst

– ElapsedTimeFwdBurst

–=


9


gedThis

creen.licedrent

(Fileshapteran behe

” dataS”mean

meanetPlan

m thetime:

e” for

As an example, Table 9-18 provides typical entries in a sorted MobileTputStat_XX file.

The following equation computes the think time for this example data.

seconds

The think time would be computed similarly for all mobiles and all think times, then averatogether across all drops to arrive at the mean think time statistic for the entire simulation.statistic can be compared to the mean think time that is displayed in the call model editor sGiven the relatively small number of think times that are generated in a typical time-ssimulation, the mean as computed from the simulation results will likely be somewhat diffethan the mean that is shown in the NetPlan Call Models tab.

9.5.6.2 Download Size and Time

Download size is governed by the “Fwd. Reference Size (bytes)” and “# Forward Referencesper Download)” Pareto parameters that are entered in the NetPlan Call Models tab (refer to C6 for additional information on setting Pareto distribution parameters). The download size ccomputed using the “BytesTX” and “MobileState” data from the MobileTputStat_XX file. Tequation to compute mean download size is as follows:

As seen in this equation, the mean download size is computed by averaging the “BytesTXfor all of the downlink bursting states (i.e. MobileState is “FF” - forward burst fundamental or “F- forward burst supplemental). The average is taken across all time-slices and drops. Thedownload size can be compared to the simulation input parameters by multiplying thenumber of references per download by the mean download size, which are provided in the NCall Models tab.

The mean download time can be computed using the “StateTime” and “MobileState” data froMobileTputStat_XX file. The following equation can be used to compute the mean download

As seen in this equation, the mean download time is computed by averaging the “StateTimall of the downlink bursting states. The average is taken across all time-slices and drops.

Table 9-18: Example Sorted MobileTputStat_XX File

MobileID MobileState ElapsedTime StateTime BytesTX CallModelIndex Srv1

138 FF 425.08 110.84 73678 0 51138 IN 428.70 3.60 0 0 51138 RF 428.92 0.22 112 0 51

ThinkTime 428.92 0.22– 425.08– 3.62= =

MeanDownloadSize Mean BytesTXMobileState FF FS||=

( )=

MeanDownloadTime Mean StateTimeMobileState FF FS||=

( )=


9


e isUser

that arettingtesTX”erse

X” forS” -time-reverse

tate”the

eTime”ps.

st time, "End

nd is. The

er 6.

Xtor.

.

It is instructive to note that the mean download size divided by the mean download timequivalent to the mean end user throughput on the forward link (refer to Section 9.5.5.4, "EndThroughput").

9.5.6.3 Reverse Request Size and Time

Reverse request size is governed by the “Rev. Request Size (bytes)” Pareto parametersentered in the NetPlan Call Models tab (refer to Chapter 6 for additional information on sePareto distribution parameters). The reverse request size can be computed using the “Byand “MobileState” data from the MobileTputStat_XX file. The equation to compute mean revrequest size is as follows:

As seen in this equation, the mean reverse request size is computed by averaging “BytesTall of the uplink bursting states (i.e. MobileState is “RF” - reverse burst fundamental, “Rreverse burst supplemental, or “RD” - reverse burst DTX). The average is taken across allslices and drops. The computed mean reverse request size can be compared to the meanrequest size that is provided in the NetPlan Call Models tab.

The mean reverse request time can be computed using the “StateTime” and “MobileSstatistics from the MobileTputStat_XX file. The following equation can be used to computemean reverse request time:

As seen in this equation, the mean reverse request time is computed by averaging the “Statdata for all of the uplink bursting states. The average is taken across all time-slices and dro

It is instructive to note that the mean reverse request size divided by the mean reverse requeis equivalent to the mean end user throughput on the reverse link (refer to Section 9.5.5.4User Throughput").

9.5.6.4 Forward Data Activity Factor

Forward data activity factor is a statistic that is unique to IS-2000 1X time-sliced simulation adefined as the fraction of active data subscribers who are bursting data on the forward linkforward data activity factor will vary as a function of the call model inputs described in Chapt

The “FwdNumMob_X”, “FwdBurstTot”, and “FwdNumMob_v” statistics from the IS-2000 1time-sliced simulation CellStatTS_XX file are used to compute the forward data activity fac

The following equation illustrates the computation of the forward data activity factor statistic

MeanReverseRequestSize Mean BytesTXMobileState RF RS RD|| ||=

( )=

MeanReverseRequestTime Mean StateTimeMobileState RF RS RD|| ||=

( )=


9


3.6).data

nd isk. Theter 6.

Xtivity

.

19.2,criberson the

g theheing

lly

inke”, or

In this equation, “X” is replaced by all of the data rates (X=9.6FCH, 19.2, 38.4, 76.8, and 15As seen in this equation, the forward data activity factor is the ratio of the number ofsubscribers who were bursting data to the total number of active data subscribers.

9.5.6.5 Reverse Data Activity Factor

Reverse data activity factor is a statistic that is unique to IS-2000 1X time-sliced simulation adefined as the fraction of active data subscribers who are bursting data on the reverse linreverse data activity factor will vary as a function of the call model inputs described in Chap

The “RevNumMob_X”, “RevBurstTot”, and “RevNumMob_v” statistics from the IS-2000 1time-sliced simulation CellStatTSRev_XX file are used in computing the reverse data acfactor.

The following equation illustrates the computation of the reverse data activity factor statistic

In this equation, the “AllRates” summation is taken over all data rates (X=9.6FCH, 9.6SCH,38.4, 78.6, and 153.6). The reverse data activity factor is the ratio of the number of data subswho were bursting data on the reverse link to the total number of active data subscribersreverse link.

9.5.6.6 Probability of Going Dormant

The probability of going dormant is a useful call model parameter that can be derived usin“MobileState” data from the MobileTputStat_XX file. The probability of going dormant is tratio of the number of dormant periods to the total number of think time periods. The followprocedure can be used to compute the probability of going dormant.

• Sort the MobileTputStat_XX file according the “MobileID” and then chronologica(“ElapsedTime”) within each “MobileID” (Note: sorting by “MobileID” shouldautomatically result in the correct chronological order).

• Identify each think time by analyzing the codes in the “MobileState” column. A thtime for a given subscriber (“MobileID”) begins with the “FF” or “FS” code in th“MobileState” column and ends when the subsequent reverse burst code (“RF”, “RS

FwdDataActivity

FwdBurstTot FwdNumMob v_–( )Time slices–∑

Sectors∑

Drops∑


Time slices–∑

Sectors∑

Drops∑

-------------------------------------------------------------------------------------------------------------------------------------------------=

RevDataActivity

RevBurstTot RevNumMob v_–( )Time slices–∑

Sectors∑

Drops∑


Time slices–∑

Sectors∑

Drops∑

----------------------------------------------------------------------------------------------------------------------------------------------=


9


deburstfor

the

or alllumn

e” forntified

ob”,s

s. Inct of a

“RD”) is reached for the given subscriber.

• Count the total number of think times.

• Identify the subset of think times that include dormant time by noting that a “DR” cohas appeared in the “MobileState” column between the forward burst and reverseentries. Note that the “IN” mobile state will precede the “DR” state and the state timethe “IN” state will equal the dormancy timer.

• Count the total number of dormant periods.

• The ratio of the number of dormant periods to the total number of think times isprobability of going dormant.

9.5.6.7 Length of the Dormant Interval

The mean length of the dormant interval can be computed by averaging the “StateTime” fdormant states. The dormant states are identified by the “DR” code in the “MobileState” coof the MobileTputStat_XX file.

9.5.6.8 Think Time While Active

The mean length of the think time while active can be computed by averaging the “StateTimall of the idle states where the subscriber unit has not gone dormant. The idle states are ideby the “IN” code in the “MobileState” column of the MobileTputStat_XX file.

9.5.6.9 Fraction of Data Subscribers Who are Dormant

The fraction of data subscribers who are dormant can be computed with the “NumDormantM“FwdNumMob_All”, and “FwdNumMob_v” statistics from the time-sliced CellStatTS_XX fileusing the following equation.

FractionOfDormantDataSubs =

9.5.7 Simulation Validation

Simulation validation is done to confirm that a simulation is producing consistent resultaddition to the call model validation statistics described above, there is one additional aspesimulation that can be readily validated, which is the subscriber speed distribution.

NumDormantMobTime slices–∑

Sectors∑

Drops∑

FwdNumMob All FwdNumMob v NumDormantMob+_–_( )Time slices–

∑Sectors∑

Drops∑

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


9


’ speedcriberion runfy thatatches

of roadected

ion

XXs toolplot is

9.5.7.1 Subscriber Speed Distribution

The system designer will not know the actual speed distribution when the subscriber classesdistributions are set to use a particular “Speed Map” (see Section 6.2.2.4.1, “Defining SubsClasses”). The actual per subscriber class speed distribution can be validated after a simulatthrough analysis of the output statistics. The speed distribution graphs can be used to verithe resulting simulation speed distributions across the system (for each class of subscriber) mthe expectations of the design engineer. The design engineer should revise the weightingspeeds and clutter speeds if the resultant speed distribution varies widely from the expdistribution. Refer to Chapter 5: “Traffic (Distribution) and Speed Maps” for further informaton setting the weighting of road speeds and clutter speeds.

9.5.7.1.1 IS-95 Subscriber Speed Distribution

The speed distribution is computed by filtering the MobileStat_All (combined MobileStat_files) file for each subscriber class and examining the “Speed (kph)” data. A statistical analysisuch as JMP can be used to plot the speed distribution. An example of a speed distributionshown in Figure 9-24: "Speed Distribution (JMP)"


9


istical

ectiontime-me-

e-weredata

Figure 9-24: Speed Distribution (JMP)

Note: Figure 9-24 was generated from JMP™. It also can be created via other statsoftware packages.

9.5.7.1.2 IS-2000 1X (non time-sliced) Subscriber Speed Distribution

The same method for evaluating the subscriber speed distribution described in the IS-95 s(Section 9.5.7.1.1, "IS-95 Subscriber Speed Distribution") is used for the IS-2000 1X nonsliced simulation evaluation. The “Speed (kph)” statistic is found in the IS-2000 1X non tisliced simulation MobileStat_All (combined MobileStat_XX files) file.

9.5.7.1.3 IS-2000 1X (time-sliced) Subscriber Speed Distribution

The “Speed (kph)” statistic is found in the MobileStatTS_XX output file for IS-2000 1X timsliced simulation. This file contains subscriber information for data subscribers only, whoactively bursting data in a given time-slice. Therefore, the speed distribution is only for the


9


ed doesthatp. Ifn thenotachethodswith

ouldtatistics

latorit maysofter ofo bectorcard

rheadill be

y beort thenel. Therier).nd,ments,

BTSmentto be

r ofroupsa sync

ector

one

subscribers and does not include the speeds of voice subscribers. Since the subscriber spenot change from time-slice to time-slice, it is necessary to filter the MobileStat_XX data soonly one instance of each subscriber, as identified by the “ID” column, remains per dromultiple instances of the same subscriber “ID” were included in the speed distribution, thedistribution would be weighted according to the subscriber data activity factor, which isdesirable. Once the MobileStatTS_XX file is filtered and only one instance (row) for esubscriber remains per drop, then the speed distribution can be analyzed using the same mdescribed in the IS-95 section (Section 9.5.7.1.1, "IS-95 Subscriber Speed Distribution"). Asthe IS-95 analysis, the speed distribution statistics from the filtered MobileStatTS_XX files wneed to be combined together so that the speed distribution analysis is conducted on the sfrom all of the simulation drops.

9.5.8 Channel Card Sizing

The number of channel elements (ChElem) per sector provided by the NetPlan CDMA Simuis the sum of best server links and soft handoff links at a particular sector. Defined as such,also be termed theactualtraffic and can be observed as the numerator in the calculation of thehandoff factor (Section 9.5.4.5.1). The ChElem statistic can be contrasted with the numbmobiles per sector (NumMob) which is the sum of best server links only. NumMob may alstermed theeffectivetraffic and can be observed as the denominator in the soft handoff facalculation. The ChElem statistic provides an indication of the channel element andrequirements at a site.

The BTS channel cards are boards within the BTS that support the traffic channels and ovechannels. Traffic channels consist of those supporting voice or data calls and their number wa function of traffic loading. For HSPD traffic, multiple supplemental channel elements maallocated in addition to a fundamental channel element. In addition, the channel cards suppoverhead channels that include the paging and access channels, as well as the sync chanquantity of overhead channels will typically be fixed (for example, 1 of each per sector-carNote that the pilot channel is typically provided by a different type of card within the BTS aconsequently, does not utilize a channel element. In generating BTS channel card requireboth traffic and overhead channel needs must be considered.

It is important to understand the channel card capabilities associated with the family ofproducts being deployed within a system. It is recommended that the specific BTS’s equipplanning guidelines be referenced. What follows are some of the considerations with whichfamiliar to properly size BTS channel cards:

• Minimum Number of Cards

• There may be overhead channel constraints which will drive a minimum numbechannel cards. For example, a MCC-24 can only support three overhead channel g(where an overhead channel group is composed of a paging/access channel andchannel) and, consequently, a minimum of one MCC-24 per carrier for a three ssite would be required based on overhead channel needs alone.

• The provisioning of overhead channel group redundancy will require planning for


9


roup

ardss or

beum of

field

ouldor thisn eachs nowowing

ls per

g softity.

additional channel card. Some BTS products do not permit for overhead channel gredundancy.

• Some BTS products may have a fixed number or a minimum number of channel cper sector, field replaceable unit (FRU), or BTS. This is especially true of microcellpicocells.

• Maximum Number of Cards

• All BTS products will have some maximum number of channel cards which cansupported. For example, the SC4812 and SCxx40 series can support a maximtwelve (12) channel cards in a cage.

• Some BTS products may have a fixed number of channel cards per sector,replaceable unit (FRU), or BTS. This is especially true of microcells or picocells.

The maximum card limit should not be an issue for most cases. However, this limit cpotentially be reached in a fixed wireless subscriber scenario consisting of only a few sites. Fscenario, the number of channel elements required may approach the Walsh code limit osector. In addition, for the BTS that can support multiple carriers in a cage, the channel cardneed to support up to 12 sectors worth of traffic and overhead channels. Consider the follexample:

Assume:

BTS SC 4812

12 sector-carriers (three sectors, four carriers)

Maximum number of physical channel elements is 288 (12 cards times 24 channecard)

Then:

Actual channel elements = Physical channel elements - Overhead channels(where overhead channel = 2 * number of sectors* number of frequencies)

= 288 - (2 * 3 * 4)= 264

Actual Erlangs = Erlang B lookup of actual channel elements= 249.8 for 264 channels @ 2% GOS in Erlang B

If the Erlang capability of each sector and frequency is greater than 20.8 Erlangs (includinhandoff), then this indicates that the number of channel elements will be limiting the capac


9


te the

lement

cross

r-site).

iteria)

rheadls aret two)rafficentshole

tion) toaller

e theethod

actualate theay be

theents.

ulate

9.5.8.1 General Approaches

In general, there are two methods for using the distribution of channel elements to calcularequired number of channel cards.

Method 1: Using the 98th-Percentile of ChElem

This approach takes the 98th percentile of the ChElem statistics to estimate the channel erequirements. The approach is described as follows:

1. For each Monte Carlo drop, sum the number of channel elements (ChElem) asectors at a site to produce a per-site distribution.

2. Create a histogram of the samples corresponding to each site (one histogram peCompute the cumulative distribution function for each site.

3. Choose the 98th-percentile point (as an approximation of a 2% grade of service crto determine the number of channel elements required for each site.

4. Once the number of channel elements is determined, add the number of ovechannels to it to arrive at the physical traffic channels required. (Overhead channecalculated by taking 2 times the number of sectors and carriers since at leaschannels are required for each sector and carrier: one for Page and one for Sync.

5. The number of required channel element cards is then the number of physical tchannels (not including the pilot channel) divided by the number of channel elemsupported by the specific channel element card (rounded up to the nearest wnumber).

This method requires a large number of drops (thousands, assuming non time-sliced simulaobtain a certain GOS with good confidence. Should this technique be employed with a smnumber of drops, it is advisable to inflate the 98th-percentile value by 10%. In order to reducnumber of drops required, and thus the time required to run the simulations, the following mof using the ChElem parameter was developed.

Method 2: Using the Mean of ChElem

The second method identifies the mean of the channel element distribution and, treating it asErlangs, applies an appropriate model (e.g. Erlang B) and grade-of-service (GOS) to estimchannel element requirements. The mean number of traffic channel elements (ChElem) mused as the carried traffic under the following conditions:

• Random distribution forms of subscriber positioning are used (no uniform grid).

• A minimum of 100 Monte Carlo drops, assuming non time-sliced simulation, ofoptimized system are performed to acquire the mean number of traffic channel elem

The obvious advantage of this method is that it only requires 100 Monte Carlo drops to accum


9


to ther theistical

an canhrough

load,ion ismMobe on ae drops

der toean andercisemean

arriersmentnt forannelementsessesarrierutiony thearrieras this

k-to-

5A iscards

s

sufficient data to produce results as compared to thousands of drops in Method 1. Duenumber of drops required for Method 1, Method 2 is the recommended approach fodetermination of channel element requirements based on NetPlan CDMA simulation statoutputs.

Under these conditions, ChElem should be a Poisson distribution and consequently, the mebe taken as an Erlang traffic load. The Poisson distribution of this data has been established tstudies, leaving verification of the distribution as an optional activity for the user.

To verify that the mean number of traffic channel elements can be used as the Erlang trafficit is necessary to look at the mean and the variance for ChElem to determine if the distributPoisson. This requires the user to determine the mean and variance for ChElem and Nuacross the drops. First, the sum of the ChElem and the sum of the NumMob must be maddrop and site basis. Then, the standard deviation and mean must be calculated across all thfor the cell sites. Next, the variance must be calculated [variance = (standard deviation)2]. Then, aplot can be made of the mean versus the variance to study the relationship of the two. In ormake the assumption that the mean ChElem can be used as the actual offered traffic, the mvariance data should be tightly grouped around the line y=x, or (variance = mean). This exwill demonstrate that the channel element load has a Poisson distribution, which permits thenumber of channel elements to represent the actual offered traffic in Erlangs.

Pooling Resources across Sectors and Multiple Carriers

Some BTS products, such as the SC4812, are capable of supporting up to 12 sector-c(4 carriers times 3 sectors or 2 carriers times 6 sectors) with one pool of channel eleresources.1 The sharing of channel element resources increases trunking efficiency. To accoutrunking efficiencies across sectors of one carrier (i.e. frequency) in the determination of chelement/card requirements, it is necessary to merge the per-sector-carrier channel elstatistics to produce a per-site-carrier distribution. Since the NetPlan CDMA Simulator procone carrier at a time, to account for trunking efficiencies across carriers, per-site-cdistributions are merged into per-site distributions. If there is an assumption of uniform distribof traffic across carriers, then the mean of the per-site-carrier distribution may be multiplied bnumber of carriers to obtain the site actual Erlangs. The 98th-percentile of per-site-cdistributions cannot be treated the same (i.e. summed to produce a per-site 98th-percentile)does not accurately reflect the trunking efficiency of the larger distribution (i.e. lower peamean ratio) and would lead to an over-estimation of channel element/card requirements.

9.5.8.2 IS-95A Channel Card Determination

Due to the number of drops required for Method 1, the recommended approach for IS-9Method 2. Using the mean ChElem as the actual offered traffic, the number of channelrequired is calculated as follows:

1. This capability requires the Multiple Carrier per Cage feature and may also require the Multiple Span Lineper CCP feature (both available since R9).


9


thatr ofg theite.)

, thethe

ource

rade

twor and

)

od 2,

en asircuittatisticalless oftion isThispacket

r with

Actual Erlangs = Sum of the mean values for ChElem for each sector at the site. Notethere will be one value for each sector based on summing the numbechannel elements in each sector of each site for each drop and then takinmean. (This value represents the offered traffic or actual Erlangs for the sThe Erlangs are summed due to the fact that for all of the BTS productschannel cards are a common resource for all sectors. In addition, forSC4812 and SCxx40 products, the channel cards are also a common resfor all frequencies within a CCP cage.

Actual Traf Chan = Number of channels found by looking up Actual Erlangs for a specific Gof Service in an Erlang B table (for instance Erlang B with 2% GOS).

Overhead Chan = 2 * (number of sectors) * (number of carriers) since a minimum ofchannels (one for Page and one for Sync) are required for each sectocarrier.

Fractional Cards = (Actual Traf Chan + Overhead Chan) / (Number Channels per card type# Channel Cards = Fractional Cards rounded up to next whole card.

An example of determining the number of channel cards, assuming IS-95A and using Methis provided below.

If:sector-1 mean ChElem = 10,sector-2 mean ChElem = 8,sector-3 mean ChElem = 12

Then:Actual Erlangs = 10 + 8 + 12 = 30Actual Traf Chan => 39 (Erlang B, 2% GOS, 30 actual Erlangs)Overhead Chan = 2 * 3 * 1 = 6Total Chan = 39 + 6 = 45

Number of MCC-8 channel cards = 45/8 = 5.625 -> 6Number of MAWI-16 channel cards = 45/16 = 2.8125 -> 3Number of MCC-24 channel cards = 45/24 = 1.875 -> 2

9.5.8.3 IS-2000 High Speed Packet Data Channel Card Determination

Prior to the introduction of High Speed Packet Data (HSPD), all traffic sources were sehomogenous with respect to channel element sizing. Specifically, voice services and cswitched data services each consumed one channel element. As a consequence, the soutput related to the distribution of channel elements could be treated as a whole, regardservice, and was directly correlated to the channel element requirements. This assumpessential for the application of a traffic model such as Erlang B to the actual traffic.assumption can no longer be held with respect to high-speed packet data calls. A high-speeddata call consumes multiple channel elements, the allocation of which may vary in numbeboth demand and RF conditions.


9


e beenration.tionkbpskbps.

hich.8, andbest

ed asand

nnel

-2000IS-95Bpportuch, itit for

n of

thesing a

5000and

versey, theulatorverse

o beC1Xeam,ed as

SCHd fromr data,verse

To properly account for IS-2000 high-speed packet data differences, the output statistics havexpanded to provide channel element information broken out by data rate and radio configuSpecifically, the ChElem_X_Y statistic [for a given data rate (X) and a given radio configura(Y)] provides separate values for voice, the 9.6 kbps fundamental channel, the 14.4fundamental, and forward supplemental channel data rates of 19.2, 38.4, 76.8, and 153.6Comparable information for the reverse link is available via the RevSCHElem_X statistics wprovide separate values for reverse supplemental channel data rates of 9.6, 19.2, 38.4, 76153.6 kbps. These new statistics retain their definition as actual traffic (i.e. containing bothserved links and soft handoff links), but, for supplemental channels, can no longer be viewdirectly representing the number of channel elements. Instead, the ChElem_X_YRevSCHElem_X statistics would need to be multiplied by the number of required chaelements (refer to tables A4-1, A4-2, and A4-3).

While the changes in statistical outputs, noted above, have been introduced to support IShigh-speed packet data, they do not apply to IS-95B high-speed packet data. In the case ofHSPD, the ChElem statistic includes a count of all physical channel elements required to suthe high-speed data call (including fundamental and all supplemental code channels). As saccurately reports the allocation of channel elements for IS-95B HSPD, but does not permtheir separation into multiple traffic streams. For further information on the determinatiorequired channel cards to support IS-95B HSPD, refer to Section A4.5.1.1.2.

9.5.8.3.1 MCC1X Capabilities

The Motorola Multi Channel Card for IS-2000 (MCC1X) has been designed to meetrequirements of Motorola systems that support IS-2000 Rev A for CBSC release R16.0 ucircuit backhaul approach, and packet backhaul in future releases. The board utilizes CSMchannel modem ASICs from Qualcomm, which implement the low level channel encodingdecoding for CDMA systems. Each MCC1X will contain two CSM5000 ASICs.

The CSM5000s are highly integrated devices that implement IS-2000 forward and rechannelization through a set of forward and reverse processing resources. SpecificallCSM5000 provides for a set of 64 forward modulator resources and 32 reverse modresources. Since the MCC1X contains two CSM5000 devices, a total of 128 forward and 64 reresources are available per MCC1X card.

The MCC1X channel card introduces a variety of traffic engineering constraints with which tfamiliar. Detailed information concerning the capabilities of these cards can be found in “MCCapabilities Overview”, Version 0.3, June 20, 2001 (available through the RF Technology TNetwork Planning & Design Department). Key traffic engineering constraints are summarizfollows:

1. Separate Pools or Caches of Channel Elements

The IS-2000 forward supplemental channels are allocated from a cache of forward-onlyresources on the MCC1X card. The IS-2000 reverse supplemental channels are allocatea cache of reverse-only SCH resources. The fundamental channels, whether for voice oare allocated from a cache of base channels composed of a pair of forward and re


9


er-cardantccess to

d to 3agingies one

y oneannel

pererse

X-48ental

resources. The size of each of these caches (or pools) of modulator resources on a pbasis is determined at the time of provisioning. For MCC1X card sizing, it will be importto engineer each of the separate caches and not assume that all traffic streams have aall modulator resources.

2. The following channel constraints exist for the CBSC release R16.0 MCC1X-48:

• All overhead channels (paging, access, sync, and quick paging channels) are limiteof each type per CSM and 6 of each type per card. The paging, sync, and quick pchannels each occupy one forward modulator resource. The access channel occupreverse modulator resource.

• In CBSC release R16.0, base channels are limited to 48 per card and occupforward and one reverse modulator resource. In CBSC release R16.1, base chconstraints will be removed and the maximum of 64 per card will be achievedassumingthe implementation of full packet backhaul at the site.

• Base channels are limited to a maximum of 32 per CSM.

• In CBSC release R16.0, a minimum of 62 forward supplemental channelsMCC1X-48 card are available. In CBSC release R16.0, a minimum of 10 revsupplemental channels per MCC1X-48 card are available.

Here is an example of how the modulator resources would be configured for a MCC1assuming the maximum base and overhead channel limits and minimum supplemchannel limits:


9


H ornt thefficll of the

CHdoesSCHest for

ementsthe

l beCH

F-SCHe intoorth

rmitting

eed toents

ack up), ther ofSMr-site

3. All F-SCH traffic for a data call must be placed on the same CSM chip to which the FCDCCH for the call has been assigned. Channelization estimates must take into accouinefficiency of splitting traffic among all chipsets and giving each chipset's worth of traaccess to only one chipset's supplemental channel resources as opposed to permitting atraffic to have access to all of the chipsets.

4. All R-SCH traffic for a data call must be placed on the same MCC1X card to which the For DCCH for the call has been assigned. In contrast with the F-SCH, the R-SCH trafficnot need to be on the same CSM chip as the FCH or DCCH; however, all of the R-resources do need to be allocated from the same CSM chip. For example, a R-SCH requ4 channel elements, to support a RC4 76.8 kbps data rate, must allocate 4 channel elfrom either CSM #1 or 4 channel elements from CSM #2 of the MCC1X card from whichFCH/DCCH allocation was made. At this time, it is not known how much impact there wilin allocating R-SCH resources from a CSM chip other than that to which the FCH or DCfor the call has been assigned. Therefore, it is advisable to treat R-SCH resources asresources from a traffic engineering perspective. Channelization estimates should takaccount the inefficiency of splitting traffic among all chipsets and giving each chipset's wof traffic access to only one chipset's supplemental channel resources as opposed to peall of the traffic to have access to all of the chipsets.

To account for the constraints discussed in items 3 and 4 above, the SCH traffic would nbe distributed across the CSM chips prior to determining the number of channel elemrequired on a per-CSM basis. The channel element requirements would then be scaled bto a per-site basis. When utilizing the actual Erlangs (i.e. the means of the distributiondistribution across CSM chips only requires dividing the actual Erlangs by the numbeCSM chips prior to sizing on a per-CSM basis and, conversely, multiplying the per-Cnumber of channel elements by the number of CSM chips when determining the perequirements.

Table 9-19: R16.0 MCC1X-48 Forward/Reverse Resources (Example Provisioning)

Channel TypeForward

ResourcesReverse

Resources

Base (or Fundamental) 48 48

Paging & Access 6 6

Sync 6 -

Quick Paging 6 -

Supplemental 62 10

Total 128 64


9


r-sitel the. Theic ofdrop,tion.terestn thatewl toneln it toe, ifmentsIf theis not.:

-SCHnmentort agest

When utilizing the 98th-percentile approach, the process is more complicated. The pedistribution must be randomly redistributed across CSM chips. This is done to modedecrease in trunking efficiency (i.e. higher peak-to-mean ratio) of the smaller distributionprocess begins with a set of bins that contain the per-site distribution for the statistinterest. This array will be termed bin[]. The array is sized to contain one value for eachof a non time-sliced simulation, or one value for each time-slice, of a time-sliced simulaThe value of each member, termed bin[i], equals the per-site value of the statistic of infor the particular drop or time-slice, as appropriate. The process creates a new distributioreflects the allocation of traffic to 1 of N CSM chips equipped at the BTS. The ndistribution will be contained in a set of bins, termed CSM_bin[] and will be sized identicabin[]. To populate CSM_bin[], each member of bin[] will be taken and for each chanelement represented by its value, a determination will be made whether or not to assigthe single CSM distribution. This assignment is made with probability 1/N. For examplthe value for one sample of a ChElem_19.2_RC3 was 4, then each of 4 channel elewould be tested against the random probability of generating a value of less than 1/N.test passes, then the channel element is placed into the single CSM distribution; else, itThe following pseudo-code describes the basic algorithm for the random re-distribution

Let N = the number of CSM chips over which the traffic will be distributed*** The number of bins associated with the distribution is:*** 1 per drop for non time-sliced simulation*** 1 per drop, per time-slice for time-sliced simulationFor i = 1 to number of drops (or time-slices){

Let bin[i] = value of statistic for member i of distribution bin[]If bin[i] = 0, then iterate*** For each of bin[i] channel elements, perform the following loopFor j = 1 to bin[i]{

*** Generate a random variable that is uniform on the range 0 to 1.RV = random()*** If the channel element passes the random test,*** place it in the per-CSM distributionIf RV < 1/N, then CSM_bin[i] = CSM_bin[i] + 1

} /* end j loop */} /* end i loop */

This process is applied in Section 9.5.8.3.3.

5. During provisioning, the F-SCH resources must be pre-configured into groups. The Rresources must also be pre-configured into groups. These groups will support the assigof a particular data rate. For example, in RC4, a group of 2 forward resources will supp38.4 kbps data rate. The allocation algorithm will permit for alternating to the next lar


9


datasearchoundd. Itcase,. For

e all ofng 2iringoup ofis

lyingX-64

andThere

(as

baseper-nddatamber

muminitial

r-site.annel8 or

provisioned group should no group of the appropriate size be available. For example, if arate of 38.4 kbps is desired, but no group of 2 resources (assuming RC4) is available, afor a group of 4 will be made (assuming they are provisioned) and should one be favailable, it will be utilized to service the allocation. Only one alternate choice is searcheshould be noted that using a group of 4 to serve the needs of a group of 2, as in thisintroduces some inefficiency. It is possible that some resource groups will be left emptyexample, 1 group of 2 resources and 1 group of 8 resources may be equipped to handlthe anticipated traffic. The group of 2 will serve as the primary choice for all rates requirior fewer resources. The group of 8 will serve as the primary choice for all rates requeither 4 or 8 resources and will serve as the alternate choice for allocations where the gr2 was the primary choice. Thisstatic allocation is present in CBSC release R16.0 andsupplanted in CBSC release R16.1 by adynamicallocation which will allow for the dynamicreconfiguration of high-speed channel resources.

9.5.8.3.2 IS-2000 Channel Determination employing Method 2

The steps involved in channel determination in the presence of IS-2000 HSPD traffic and appmethod 2 is outlined as follows (assumes a MCC1X-48 channel card for R16.0 or a MCC1channel card for R16.1 and a SC4812 BTS):

a. As input, obtain the means of the per-site distributions of ChElem_X_YRevSCHElem_X. This requires merging per-sector-carrier distributions, as appropriate.will be one mean value (or actual Erlang load) for each rate and radio configurationspecified by the X and Y suffixes, respectively) per-site.

b. Determine the minimum number of MCC1X-48 or MCC1X-64 cards per-site based onchannel requirements alone (voice and data fundamental traffic only). All calculations aresite. To calculate this, first sum the means for ChElem_v (for voice) aChElem_9.6FCH_RC3, ChElem_9.6FCH_RC4, and ChElem_14.4FCH_RC5 (forfundamental channels). Next, use Erlang B and a 2% GOS to determine the minimum nuof base channel elements required to support this traffic. Finally, determine the mininumber of cards required to support this number of base channels. This will serve as theestimate for the number of cards required.

base traffic = meanChElem_v + meanChElem_9.6FCH_RC3+ meanChElem_9.6FCH_RC4 + meanChElem_14.4FCH

base channels = ErlangB(base traffic,GOS=2%)

For CBSC release R16.0, cards = roundup(base channels / 48)For CBSC release R16.1, cards = roundup(base channels / 64)CSM chips = cards x 2

c. Determine the maximum number of F-SCH and R-SCH channel elements available peThis will be a function of the current assumed number of cards and the overhead chrequirements. The calculations are performed as follows, assuming the MCC1X-4


9


picallyquickchannel

alues

ta rate

diots. Forysical

thisthe

thisthe

ents

thetotal

MCC1X-64:

F-SCH available = (128 x cards) - base channels - forward overhead channelsR-SCH available = (64 x cards) - base channels - reverse overhead channels

The base channels were calculated in step (b). The forward overhead channels would tyconsist of 1 paging channel and 1 sync channel per sector-carrier. With IS-2000, apaging channel may also be provisioned. The reverse overhead channel is the accesswhich would typically consist of 1 access channel per sector-carrier.

d. Distribute the per data rate per radio configuration F-SCH and R-SCH actual traffic (vwere obtained in step a) across the CSM chips. This is calculated as follows:

F-SCH per-CSM traffic = F-SCH per-site traffic / CSM chips [per data rate]R-SCH per-CSM traffic = R-SCH per-site traffic / CSM chips [per data rate]

e. Determine the per-CSM F-SCH and R-SCH channel element requirements.

In performing this step, the number of channel elements required to implement each dais needed for weighting. (See Tables A4-1, A4-2, and A4-3 for weighting information.)

If multiple radio configurations are being employed, then the actual traffic for different raconfigurations may be merged if they share the same channel element requiremenexample, both Forward RC3 at 38.4 kbps and Forward RC4 at 76.8 kbps require 4 phchannel elements; therefore, their actual traffics may be merged.

For CBSC release R16.0, the “nw16.bas” Excel macro may be used to makedetermination. Refer to Section 9.5.8.3.4 for information on the technique employed inmacro to make this channel element sizing determination.

For CBSC release R16.1, the “kaufman.bas” Excel macro may be used to makedetermination. Refer to Section 9.5.8.3.4 for information on the technique employed inmacro to make this channel element sizing determination.

f. Determine whether the current number of cards is sufficient to satisfy all traffic requirem(i.e. FCH, F-SCH, and R-SCH).

If per-CSM F-SCH channels > (F-SCH available / CSM chips), or,per-CSM R-SCH channels > (R-SCH available / CSM chips),then increment the assumed number of cards by 1 and return to step c.

g. Calculate the total number of F-SCH and R-SCH (by multiplying the per-CSM values bynumber of CSM chips). This procedure yields the number of cards along with thenumber of FCH, F-SCH, and R-SCH channel requirements.


9


lyingX-64

hisutionutionime-

baseper-nddataof the

entsnflatet thisards

is willments.

synconed.access

9.5.8.3.3 IS-2000 Channel Determination employing Method 1

The steps involved in channel determination in the presence of IS-2000 HSPD traffic and appmethod 1 is outlined as follows (assumes a MCC1X-48 channel card for R16.0 or a MCC1channel card for R16.1 and a SC4812 BTS):

a. As input, obtain the per-site distributions of ChElem_X_Y and RevSCHElem_X. Trequires merging per-sector-carrier distributions, as appropriate. There will be one distribfor each rate (as specified by the X and Y suffixes, respectively) per-site. Each distribwill be across all drops for a non time-sliced simulation and across all time-slices for a tsliced simulation.

b. Determine the minimum number of MCC1X-48 or MCC1X-64 cards per-site based onchannel requirements alone (voice and data fundamental traffic only). All calculations aresite. To calculate this, first merge the distributions for ChElem_v (for voice) aChElem_9.6FCH_RC3, ChElem_9.6FCH_RC4, and ChElem_14.4FCH_RC5 (forfundamental channels). Next, use the 98th-percentile point (assuming a GOS of 2%)base channel distribution to determine the minimum number of base channel elemrequired to support this traffic. To compensate for small sample sizes, it is advisable to ithis value by 10%. Finally, determine the minimum number of cards required to suppornumber of base channels. This will serve as the initial estimate for the number of crequired.

base traffic distribution = distributionChElem_v + distributionChElem_9.6FCH_RC3+ distributionChElem_9.6FCH_RC4+ distributionChElem_14.4FCH_RC5

base channels = 98th-percentile of base traffic distribution

For CBSC release R16.0, cards = roundup(base channels / 48)For CBSC release R16.1, cards = roundup(base channels / 64)CSM chips = cards x 2

c. Determine the maximum number of F-SCH and R-SCH channel elements available. Thbe a function of the current assumed number of cards and the overhead channel requireThe calculations are performed as follows, assuming the MCC1X-48 or MCC1X-64:

F-SCH available = (128 x cards) - base channels - forward overhead channelsR-SCH available = (64 x cards) - base channels - reverse overhead channels

The forward overhead channels would typically consist of 1 paging channel and 1channel per sector-carrier. With IS-2000, a quick paging channel may also be provisiThe reverse overhead channel is the access channel which would typically consist of 1channel per sector-carrier.


9


SCHe for

s formentkbps

of thens of

and ay the2, andn of

Thels. To

ents

thetotal

just

leasees for

nt for a

d. Randomly re-distribute the per data rate per radio configuration F-SCH and R-distributions (distributions were obtained in step a) across the CSM chips. A procedurdoing this was provided in Section 9.5.8.3.1, "MCC1X Capabilities".

If multiple radio configurations are being employed, then the per data rate distributiondifferent radio configurations may be merged if they share the same channel elerequirements. For example, both Forward RC3 at 38.4 kbps and Forward RC4 at 76.8require 4 physical channel elements; therefore, their distributions may be merged.

e. Determine the per-CSM F-SCH and R-SCH channel element requirements.

For CBSC release R16.0, no method is outlined here. A technique comparable to that“nw16.bas” Excel macro, but based on utilizing the actual distributions (i.e. not the meathe distributions) would be used to make this determination.

For CBSC release R16.1, the per data rate distributions are merged to produce a F-SCHR-SCH distribution. In performing the summing, each data rate distribution is weighted bnumber of channel elements required to implement the data rate. (See Tables A4-1, A4-A4-3 for weighting information.) The resultant distribution now represents the distributioactual (i.e. physical) channel elements required to support the high speed traffic.98th-percentiles (assuming a 2% GOS) of these distributions are the required channecompensate for small sample sizes, it is advisable to inflate these values by 10%.

f. Determine whether the current number of cards is sufficient to satisfy all traffic requirem(i.e. FCH, F-SCH, and R-SCH).

If per-CSM F-SCH channels > (F-SCH available / CSM chips), or,

per-CSM R-SCH channels > (R-SCH available / CSM chips),

then increment the assumed number of cards by 1 and return to step c.

g. Calculate the total number of F-SCH and R-SCH (by multiplying the per-CSM values bynumber of CSM chips). This procedure yields the number of cards along with thenumber of FCH, F-SCH, and R-SCH channel requirements.

9.5.8.3.4 Scripts

The following scripts currently exist to perform some of the channelization calculationsdescribed. These scripts may prove useful as examples and templates.

The “canal.pl” perl script performs channel card calculations comparable to the CBSC reR16.1, 98th-percentile approach with the following exceptions. It accounts for separate cachfundamental channels and for forward supplemental channels, but does not currently accou


9


amongwithides aof the

iqueidth

ber ofade-of-an’smentse staticcro is

16.0tial fors. Tod by

servicen’sments

ourcesleaseesign

MAlimitsed ontions.n (oringelinesd the

ic be

reverse supplemental channel cache. It does not distribute the supplemental channel trafficCSM chips. Assuming that base channel requirements are limiting, which they most likely areCBSC release R16.0 and assuming low penetrations of high-speed data, this script provreasonable first approximation of channel card requirements. This script is included as partNetPlan software package.

The “kaufman.bas” Excel Visual Basic macro utilizes the generalized Erlang B techndescribed by Kaufman to handle multiple traffic streams, each with different bandwrequirements and assuming a common pool of channels.2 In this application, inputs include: theactual Erlangs associated with each data rate (i.e. the multiple traffic streams), the numchannel elements (i.e. bandwidth requirements) required to support each data rate, and a grservice (GOS) which will be applied to each traffic stream independently. The use of Kaufmtechnique serves as a good model for approximating the supplemental channel requireassuming CBSC release R16.1. In R16.1, dynamic allocation of SCH resources supplants thallocation, or pre-configured provisioning, of SCH groups in CBSC release R16.0. The maavailable through the RF Technology Team, Network Planning and Design Department.

The “nw16.bas” Excel Visual Basic macro attempts to model the CBSC release Rsupplemental channel element resource allocation mechanism. This includes the potenoverflowing from one-sized group of resources to the next larger sized group of resourcemodel the overflow, the macro utilizes the generalized Erlang B technique (first describeR. I. Wilkinson of Bell Labs) that computes the blocking for peaked or overflow traffic.3 In thisapplication, inputs include: the actual Erlangs associated with each data rate and a grade-of-(GOS) which will be applied to each traffic stream independently. The use of Wilkinsotechnique serves as a good model for approximating the supplemental channel requireassuming CBSC release R16.0. In CBSC release R16.1, dynamic allocation of SCH ressupplants the static allocation, or pre-configured provisioning, of SCH groups in CBSC reR16.0. The macro is available through the RF Technology Team, Network Planning and DDepartment.

9.5.9 Power Amplifier Considerations

It is important to account for the power requirements when designing and optimizing a CDsystem. Forward link power available from the base station will limit coverage and maycapacity. The goal of this section is to characterize the power requirements for each site basimulation results and compare these requirements to BTS power amplifier (PA) specificaThis is done to verify that the BTS product being considered will meet the needs of the desigvice versa). Additional (more detailed) information can be found in the “CDMA RF PlannGuide” (Version 2.1, December 18, 1998), Sections 5.4.1 and 6.2.1.1.4. Following are guidfor performing this evaluation. If the system design power requirements are found to exceePA specifications, then it is recommended that either pilot powers be reduced or traff

2. “Blocking in a completely shared resource environment with state dependent resource and residencyrequirements”, J. S. Kaufman, AT&T Bell Laboratories, 1992.

3. “Practical Traffic Engineering of Least Cost Routing Systems -- Part 5, “Peaked” Traffic: What it is andwhen you should worry about it”, BUSINESS COMMUNICATIONS REVIEW (July/August, ‘83),Michael T. Hills, Hills Telecommunications, Ltd.


9


r (ARP

Thisvarying

frompowerendedof the

fromrithmutputLPAalingunders this15,

.

andto asr”. A1.1 of

owers

the

rs

andrTot

redistributed.

9.5.9.1 PA Equipment Capabilities

In these guidelines, two PA parameters are frequently referred to: the Average Rated Poweor Steady State Rating) and the High Power Alarm Rating (HPAR).

The ARP represents the output power which the PA is capable of sustaining indefinitely.specification assumes a constant output power. It does not represent the average of aCDMA signal.

The HPAR represents the output power level at which the PA modules would be removedservice to protect against destructive overloading of the PA. Note that there are some PAmanagement strategies that mitigate taking a PA out-of-service unnecessarily or for extperiods of time. The first of these strategies requires that two distinct power surges in excessHPAR be detected within a brief period of time (~2 seconds) to remove the PA moduleservice such that remote manual intervention is required to restore the device. This algoprotects against a single spurious power surge triggering an outage. Additionally, when PA opower levels approach a threshold (either manually or automatically determined), theOverload Protection feature (Feature 1225A) limits PA output power through automatic scback of power and thus protects the PA from being overdriven and removed from serviceconditions of a traffic overload. Feature 1225A, introduced in CBSC release R9.2, providefunctionality for 4-digit single tone LPA products. Feature 415B, which is in CBSC release Rprovides this functionality for 3-digit single-tone LPA products and multi-tone LPA products

Please refer to B1 technical specifications for a particular BTS product to obtain the ARPHPAR for that particular BTS product. Within these specifications, the ARP may be referredthe “Total Power Output” and the HPAR may be referred to as the “Short Term Peak Powetable containing ARP and HPAR values for some BTS products can be found in Section 5.4.the “CDMA RF Planning Guide” (Version 2.1, December 18, 1998).

9.5.9.2 Simulator Power Statistics

The following power statistics are generated by NetPlan for each sector on each drop. (All pare in Watts.)

• PilotPwr - Pilot channel power• PagePwr - Page channel power• SyncPwr - Sync channel power• TCHPwrTot - Total forward traffic channel power transmitted by the sector. This is

sum of the individual forward traffic channel powers.• FwdPwrTot - Total forward power. This is the sum of all forward traffic channel powe

plus Pilot, Page and Sync.

With the exception of FwdPwrTot, all power statistics are available in CellStat_XX for IS-95IS-2000 non time-sliced and in CellStatTS_XX for IS-2000 time-sliced simulations. FwdPw


9


by

displayc ands thector.

ell orcrossBBN

areeristicshese

rrierapply

is only found in the CellStat_XX for IS-95, but, by definition, can be obtained for IS-2000summing the traffic channel and overhead channel powers as follows:

The NetPlan Data Graphing feature (accessed through Tools>Data Graph) may be used toFwdPwrTot for all of the sectors. This represents the total forward power (Pilot, Page, Synthe total forward traffic channel power) required for a sector. The graph in Figure 9-25 showaverage, maximum, and minimum total forward power values across the drops for each se

Figure 9-25: FwdPwrTot

Note: The Reports>CDMA Statistics feature concatenates the individual statistics files (cmobile) for all of the drops into one file. For some situations (e.g. to sum power statistics asectors for TrunkedPower BTS products), an external application (e.g. Excel, JMP,Cornerstone) will be necessary to post-process the statistics.

9.5.9.3 CDMA Signal Power Distribution Characteristics

The following sections provide four characteristics of the CDMA signal power distributionuseful in discussions on PA requirements. These sections define the signal power charactand shows their derivations based on NetPlan CDMA Simulator power statistics. Tcharacteristics are then compared with PA equipment capabilities in later sections.

For trunked PAs, all references to a power distribution may refer to an individual sector-caand/or to the set of sector-carriers over which the trunked PA is shared. Which distribution to

FwdPwrTot TCHPwrTot PilotPwr PagePwr SyncPwr+ + +=


9


d PAarrierssector-

.e. an

f the

terval

the

the

iod (i.e.ced in:

tivityused

(individual or set), for comparison with PA equipment capabilities, is made clear in the trunkediscussion under Section 9.5.9.4.2. To generate the power distribution for a set of sector-cassociated with the trunked PA resource, sum the TCHPwrTot statistics across the set ofcarriers within each drop.

9.5.9.3.1 Long Term Average

The Long Term Average (LT-AVG) represents the average power over the busy period (iinterval of 30 minutes or more). This is estimated as follows:

The LT-AVG can be inspected visually for all sector-carriers by plotting the average value oFwdPwrTot distribution using the Data Graph utility’s Average Plot.

9.5.9.3.2 Short Term Average

The Short Term Average (ST-AVG) represents the average power level over a 5 minute inwithin the busy period. This is estimated as follows:

An approximation of the ST-AVG can be inspected visually for all sector-carriers by plottingmaximum value of the FwdPwrTot distribution using the Data Graph utility’s Min Max Plot.

9.5.9.3.3 Very Short Term Average

The Very Short Term Average (VST-AVG) represents the average power level over a 2 secondinterval within the busy period. This is estimated as follows:

The scaling of the 98th-percentile of the TCHPwrTot distribution by 1.5 accounts for98th-percentile of voice activity variation.

9.5.9.3.4 Peak Power

The Peak Power or Frame Power (Peak) represents the power associated with a 20 ms perone frame). There is a probability of less than 10% that the Peak Power should be experien72 busy hours (given the LT-AVG). The Peak Power requirements are estimated as follows

The scaling of the maximum TCHPwrTot by 1.5 accounts for the 98th-percentile of voice acvariation. The additional scaling up by 10% compensates for the smaller sample size typically

LT-AVG 50th-percentile of TCHPwrTot distribution( ) PilotPwr PagePwr SyncPwr+ + +=

LT-AVG 50th-percentile of FwdPwrTot distribution( )=

ST-AVG 98th-percentile of TCHPwrTot distribution( ) PilotPwr PagePwr SyncPwr+ + +=

ST-AVG 98th-percentile of FwdPwrTot distribution( )=

VST-AVG 98th-percentile of TCHPwrTot distribution( ) 1.5× PilotPwr PagePwr SyncPwr+ + +=

Peak Max(TCHPwrTot distribution) 1.5× 1.1 PilotPwr PagePwr SyncPwr+ + +×=


9


ureh thehort

owerplifierower

TSre also

urcesand

PAR,nts for

BTS

pareBTS

in simulations (100 drops instead of 1000).

Historically, the Peak Power was compared with HPAR for PA sizing. The procedrecommended in the following section uses the VST-AVG in place of the Peak Power witunderstanding that any power fluctuations significantly higher than the VST-AVG are of very sduration and are managed by PA overload protection mechanisms.

9.5.9.4 Comparing Power Requirements to BTS Specifications

This section defines the comparison process for different BTS products in terms of prequirements based on simulation results. This is done in order to verify that the power amin the chosen BTS product is sufficient for the needs of the design, or to compare the prequirements for each site with the BTS specifications (ARP and HPAR values).

In the following sections, specific PA sizing requirements will be defined for different Bproducts in terms of power requirements and BTS specifications. Some general notes aprovided.

9.5.9.4.1 Conventionally Powered BTS Products

For conventionally powered BTS products (i.e. single tone PAs with no sharing of PA resoacross multiple sectors and/or carriers), it is only necessary to determine the LT-AVGVST-AVG requirements for the sector-carrier and then compare them with the ARP and Hrespectively. The PA ratings for the chosen BTS product must exceed the power requiremethe site.

[EQ 9-1]

[EQ 9-2]

9.5.9.4.2 TrunkedPower BTS Products

For TrunkedPower BTS products, there are two steps:

1. Determine the LT-AVG and VST-AVG requirementsfor the appropriate set ofsector-carriers over which the PA resource is sharedand then compare them with theARP and HPAR, respectively. The PA ratings for the chosen TrunkedPowerproduct must exceed the power requirements for the site.

[EQ 9-3]

[EQ 9-4]

2. Determine the LT-AVG requirement for each individual sector-carrier and then comthis with the ARP for a sector-carrier. The PA rating for the chosen TrunkedPowerproduct must exceed the power requirement for the site.

LT-AVG ARP≤

VST-AVG HPAR≤

LT-AVG set ARPset≤

VST-AVGset HPARset≤


9


rrier

ave atorsthat is

odef theowerhen

d bed prior

), oneteriammon

cts

to theTSas aEQriteria

eaturehort. Foralues

[EQ 9-5]

For example, the SC614T at 1.9 GHz is rated for 40 Watts ARP in any individual sector-ca(ARPsector). Across three sectors of one carrier, it is rated for 48 Watts ARP (ARPset) and 76 WattsHPAR (HPARset) worst case. Therefore, a system design using the SC614T product must hLT-AVG for each individual sector-carrier that is less than 40 Watts, a LT-AVG for three secof one carrier that is less than 48 Watts, and a VST-AVG for three sectors of the one carrierless than 76 Watts.

9.5.9.4.3 Multi-tone Powered BTS products

For multi-tone (i.e. ELPA) powered BTS products, the application typically involves mixed moperation (i.e. Analog and CDMA). The sizing procedure, described in Section 6.2.1.1.4 o“CDMA RF Planning Guide” (Version 2.1, December 18, 1998), determines an aggregate prequirement between both the analog (fixed) and CDMA (variable) power components. Wusing NetPlan CDMA simulation results as input, the ST-AVG of the power distribution shoulused to represent the CDMA component. The analog component will need to be aggregateto comparison to the ARP.

9.5.9.4.4 General Notes

Whenever a worst case analysis employs two or more criteria (in this case, ARP and HPARof the criteria will be found to be limiting. Procedures may specify comparing against both cri(as seen in Section 9.5.9.4.1 and Section 9.5.9.4.2), but experience will identify the most colimiting criteria.

Thermally limited products (i.e. those with no fans) tend to be ARP limited. All indoor produ(and outdoor products with fans) tend to be HPAR limited.

With respect to sizing the PA forindoor products (and outdoor products with fans), it is a rule ofthumb that the criteria that the ARP exceed the ST-AVG is equivalent, for sizing purposes,criteria that the HPAR exceed the VST-AVG. Therefore, for conventionally powered Bproducts, EQ 9-6 can replace EQ 9-2 and EQ 9-1 (since EQ 9-1 is not limiting) and servestandalone criteria (since EQ 9-1 is not limiting). Similarly, for TrunkedPower BTS products,9-7 can replace EQ 9-4 and EQ 9-3 (since EQ 9-3 is not limiting) and serve as a standalone cfor step 1 of Section 9.5.9.4.2.

[EQ 9-6]

[EQ 9-7]

A visual assessment of PA sufficiency may be possible using the NetPlan Data Graphing fby confirming that all maximum total forward power values (approximately equal to the STerm Average described in Section 9.5.9.3.2) fall below the ARP for the chosen PA(s)products that are thermally limited (i.e. do not have fans), the average total forward power v

LT-AVG sector ARPsector<

ST-AVG ARP≤

ST-AVGset ARPset≤


9


ith theightly. In thislue pere thatset ofeeredctors

toilot/

oweristion

ners)

annelhichnsporttor’s

rt asnel for.2 orls perDS0.

, prioricatedannel

ng was

high-

peedre still

(equal to the Long Term Average described in Section 9.5.9.3.1) are used for comparison wARP. In the case of TrunkedPower BTS products, visual assessment is still helpful, but slmore challenging since the power distribution across a set of carriers needs to be evaluatedcase, comparing each sector’s maximum total forward power values to an average ARP vasector may eliminate many sectors from consideration of being under-engineered. Thosremain, may be visually inspected to see if the sum of their maximum values across thesectors falls below the ARP for the set. Those that fail this visual inspection may still be engincorrectly, but it will require the creation and analysis of the power distribution for the set of seto determine this.

Finally, in addition to the power amplifier ARP and HPAR, other BTS product capabilitiesconsider may include any minimum or maximum limits on signalling channel powers (i.e. PPage/Sync). For example, some BTS transmitter specifications will refer to the “Pilot PAdjustment Range”, “Maximum Pilot Power” or the “Minimum Output Range”. In general, itimportant to be familiar with the BTS product capabilities and any particular site configuraconstraints.

Also, any omissions in the link budget (e.g. not accounting for external duplexers or combiwould lead to underestimating PA resource requirements.

9.5.10 IS-2000 Backhaul Sizing

With CBSC release R16.0, a BTS packet pipe is utilized to transfer IS-2000 supplemental chtraffic between the CBSC and the MCC1X cards. This section will outline the procedure by wChElem_X_Y and RevSCHElem_X statistics may be used to size the packet pipe. Packet tranetworks will achieve improved backhaul efficiency in an environment where the operabackhaul costs are becoming a significant concern.

Backhaul requirements for all other BTS traffic are engineered for circuit switched transpodone previously. For radio channel traffic, this corresponds to dedicating one sub-rate chaneach traffic channel element equipped (as determined in step b of Section 9.5.8.3Section 9.5.8.3.3). Clear-channel span line signalling (i.e. B8ZS) allows four sub-rate channeDS0 while non-clear channel span line signaling (i.e. AMI) allows three sub-rate channels perAlso, one DS0 is allocated for control channel signalling between the BTS and CBSC. Sinceto the introduction of packet backhaul in CBSC release R16.0, channel elements were dedon a 1 for 1 basis with sub-rate channels on the circuit backhaul, the exercise of sizing chelements fundamentally determined the size of the backhaul. For this reason, backhaul sizinot previously documented in this procedure.

In CBSC release R16.1, packet backhaul capabilities will be extended to include not onlyspeed supplemental channel traffic, but all traffic. The CBSC release R16.1full packet backhaulwill, therefore, include: voice, circuit-switched data, fundamental data traffic, and high-ssupplemental channel traffic. Procedures for sizing the backhaul for CBSC release R16.1 aunder development by the Performance Analysis Group.


9


basisradiohaul.ualitysportaders.and R-)ely.pipe

tile tong the

g thisC1X

t pipeomlynnelloyedBSCsis.

widthel

hisill beall

tion.ld beed in

e per-drop

(eachill ber that

e

9.5.10.1 General Approach

The ChElem_X_Y and RevSCHElem statistics provide data on a per drop or per time-sliceof the number of supplemental channels being supported at a given data rate (X) andconfiguration (Y). For each data rate, there is an implied payload being offered to the backThe payload corresponds to the size of the air frame for that data rate, but with the frame qbits (i.e. CRC) and encoder tail bits stripped away (refer to table A4-6 for details). For tranacross the backhaul, the payload is “wrapped” in a capsule composed of multiple protocol heThe overhead associated with the protocol headers is 41 and 43 Bytes per frame for F-SCHSCH, respectively. This corresponds to 16.4 kbps (= 41 Bytes x 8 bits/Byte x 50 frames/secondand 17.2 kbps (= 43 Bytes x 8 bits/Byte x 50 frames/second) for F-SCH and R-SCH, respectivFrom this information, it is possible to produce a distribution that represents the packetbandwidth requirements. Based on simulation studies, a GOS of 3% to 5% (97th-percen95th-percentile) provides a reasonable first approximation on packet pipe sizing by balancirequirements of efficiency with delay.

In CBSC release R16.0, packet pipes are dedicated on a per MCC1X basis. Modelinconstraint requires distributing the high-speed supplemental channel traffic across the MCcards prior to determining the packet pipe size on a per-card basis. The BTS packerequirements would then be scaled back up to a per-site basis. A method for randredistributing the per-site distributions into per-CSM distributions was described for chaelement sizing in Section 9.5.8.3.1, "MCC1X Capabilities". This same technique can be emphere. Note that here, the distribution is made over MCC1X cards instead of CSM chips. In Crelease R16.1, packet pipes are dedicated resources that are provisioned on a per BTS ba

9.5.10.2 IS-2000 Packet Pipe Size Determination

The packet pipe size will be provided in units of DS0s. A DS0 corresponds to 64 kbps of bandassuming clear channel signaling and 48 kbps4 of bandwidth assuming non-clear channsignaling. The procedure for determining the size of the packet pipe is detailed as follows:

a. As input, obtain the per-site distributions of ChElem_X_Y and RevSCHElem_X. Trequires merging per-sector-carrier distributions, as appropriate. For each site, there wone distribution per rate (X) and radio configuration (Y). Each distribution will be acrossdrops for a non time-sliced simulation and across all time-slices for a time-sliced simula

b. If the number of channel cards is greater than one, the per-site distributions shouconverted into per-card distributions. The number of channel cards was determinSection 9.5.8.3.2 or Section 9.5.8.3.3.

c. On a per-site basis, a determination of required packet pipe bandwidth is made for thcard distribution on a per drop or per time-slice basis. Each bin (each bin representing aor time-slice, as appropriate) of each of the per-card distributions obtained in step (b)distribution representing a high-speed data rate, X, for a given radio configuration, Y) wsummed across the drop or time-slice to obtain a per-site bandwidth requirement fo

4. For spans employing AMI and Rob Bit Signaling modes of operation, an implementation constraint aroswith the introduction of EGPROCs that has reduced throughput for the DS0 from 56 kbps to 48 kbps.


9


ld arately

.4]

The

links.

d to

tion

t

-card

particular drop or time-slice. This process, when performed across all of the bins will yieper-site distribution of bandwidth requirements. These calculations are performed sepafor the forward and reverse directions.

bandwidthFwd (kbps) = ChElem_19.2_RC3 x [ 18.0 + 16.4] + ChElem_19.2_RC4 x [ 18.0 + 16.4] +ChElem_38.4_RC3 x [ 37.2 + 16.4] + ChElem_38.4_RC4 x [ 37.2 + 16.4] +ChElem_76.8_RC3 x [ 75.6 + 16.4] + ChElem_76.8_RC4 x [ 75.6 + 16.4] +ChElem_153.6_RC3 x [ 152.4 + 16.4] + ChElem_153.6_RC4 x [ 152.4 + 16

bandwidthRev (kbps) = RevSCHElem_9.6 x [ 8.6 + 17.2] +RevSCHElem_19.2 x [ 18.0 + 17.2] +RevSCHElem_38.4 x [ 37.2 + 17.2] +RevSCHElem_76.8 x [ 75.6 + 17.2] +RevSCHElem_153.6 x [ 152.4 + 17.2]

Apply the following equations to convert the bandwidth requirements into units of DS0s.equations are applied separately for the forward and reverse links.

For clear channel signaling:bandwidth (DS0s) =roundup(bandwidth (kbps) / 64.0 kbps)

For non-clear channel signaling:bandwidth (DS0s) =roundup(bandwidth (kbps) / 48.0 kbps)

The following steps (d through g) are performed separately for the forward and reverse

d. Each bin of the per-site required bandwidth distribution, obtained in step (c), is useincrement a per-site histogram of DS0 requirements.

H = { H0, H1, H2, ..., HX, ...}

For each bin value, X, incrementHX (i.e.HX = HX + 1).

where:

X represents the number of required DS0s

HX is number of bins (e.g. drops or time-slices) of the per-site required bandwidth distributhat required X DS0s.

e. Calculate the 97th-percentile (assuming a GOS of 3%) ofH. This value represents the packepipe size in units of DS0s. DS0s =H97th-ile

f. It is currently recommended that no packet pipe contain fewer than 4 DS0s on a perbasis. IfH97th-ile < 4, then DS0s = 4.


9


quired

or thect thet mostl be

eachped.s (b)

justfiles;

gnt foring tortheributionsy (i.e.

reportment.

g. If step (b) was used to generate a per-card distribution, calculate the number of DS0s reper-site by multiplying the result from step (f) by the number of cards.

h. Steps (b) through (g) were used to yield separate per-site bandwidth requirements fforward and reverse directions. Between the forward and reverse link calculations, selelarger requirement to represent the per-site bandwidth requirement. It is anticipated thahigh-speed applications will be forward centric and, consequently, the forward link willimiting in most cases.

Note: As a rule of thumb, the trunking inefficiency associated with dedicating packet pipes toMCC1X card is on the order of requiring 1 to 2 additional DS0s for each card actually equipThis trunking inefficiency is accounted for in steps (b) and (g) of the procedure. Should stepand (g) be omitted, then the rule of thumb should be applied.

9.5.10.3 Scripts

The “backhaul.pl” script currently exists to perform some of the packet pipe calculationsdescribed. There is no guarantee that this script works with current versions of the outputnevertheless, this script may prove useful as an example and template.

The script generates the histogram,H, described in the procedure above with the followinexceptions. It accounts for forward supplemental channels, but does not currently accoureverse supplemental channels. It automatically produces three histograms correspondassumptions of one, two, and three MCC1X cards. It outputs these distributions for fuprocessing. The Performance Analysis Group produced a spreadsheet that took these distras input and explored techniques for quantifying the trade-offs between improved efficiencreduced bandwidth) with reduced throughput. The technique and results are documented in awhich is available through the RF Technology Team, Network Planning and Design Depart


NetPlan Cell/MobileAnalysis

Chapter

10
Table of Contents
0 - 3

- 3

0 - 50 - 5

10 - 6 - 6

0 - 7

0 - 8

10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

10.2 Cell/Mobile Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

10.3 Mobile Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110.3.1 Handoff Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110.3.2 Server Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10.3.3 Mobile Marker Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

10.4 Cell Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

10.5 Edit Coloring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1


10

Chapter 10: NetPlan Cell/Mobile Analysis

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


10


d datar with

tion oftPlaneteator

istics) areter 9,layted astainerever

dataThe

in

hich

10.1 Overview

It may be difficult for the user to connect the physical system being studied to the statistics anobtained from a simulation run. The need exists to correlate the performance of a cell/sectothe location of the cell/sector and with the surrounding cells/sectors. A graphical representathe information facilitates the analysis during the cell site parameter optimization efforts. Neprovides this graphical display via its Cell/Mobile Analysis feature (CMA). For complinstructions on using the CMA feature, refer to the “NetPlan CDMA Static System SimulUser’s Guide”.

10.2 Cell/Mobile Analysis

The Cell/Mobile Analysis feature is a graphical interface that displays the data and statavailable within the CellStat and MobileStat output files. These output files (one per dropcreated when the Cell/Mobile Statistics box is selected during a simulation run (see Chap“NetPlan CDMA Simulator Statistical Output and Analysis”). The feature may also dispnumeric data stored in an external file provided by the user. The external file must be presencell information and not subscriber information. The first column of the external file must conthe cell names to be accepted by the CMA feature. (A user created data file may be placed whconvenient.)

Note: Currently, the CellStatTS and MobileStatTS output files for the time-sliced packetsimulations are not accessible through the Cell/Mobile Analysis feature.functionality of the CMA feature will be enhanced to include these statisticssubsequent releases of NetPlan.

To access the CMA feature, the user clicks on the Cell/Mobile Analysis icon (shown above), wopens the Cell/Mobile Analysis window. See Figure 10-1:


10


tion

lected0-1.

Figure 10-1: Cell/Mobile Analysis

The Cell/Mobile Analysis window is divided into two primary areas with associated activabuttons:

• Mobile Data

• Cell Data

Both forms of simulation data may be displayed separately or simultaneously. They are sethrough the two buttons at the top of the Cell/Mobile Analysis window as shown in Figure 1


10


s) forplayedlation

time.gory.

yingre of thescribers

ites isbox”

rvinges the

,

10.3 Mobile Data

The Mobile Data sub-set of the CMA displays user defined markers (keyboard characterevery subscriber that meets the specified selection criteria. The subscriber markers are disin their proper geographic location. The subscribers from any number of consecutive simudrops may be displayed. Multiple selection criteria categories may be displayed at the sameThis is accomplished by allowing the user to assign a unique marker and color to each cate

10.3.1 Handoff Data

This subsection of the feature allows the user to define the selection criteria for displasubscribers based on the soft handoff state of the subscribers. The user selects one or mobuttons and defines the associated character and colors. See Figure 10-2. The displayed subwill be restricted to only those connected to previously selected cell sites. Selecting cell saccomplished using the mouse to either “click” on the sectors of interest or by dragging a “around the cell sites of interest.

Figure 10-2: Handoff Data

This sub-feature is most useful for locating regions of the simulation space that are semultiple-way soft handoffs, or are unable to support subscriber connections. It further isolatcell sites that are involved in supporting these regions.

These buttons activate the display of subscribersmeeting these soft handoff criteria.

The user defines a unique Color for the subscribersby clicking these boxes and selecting the desired color.

The user defines a unique marker character for eachhandoff criteria by typing a character into these fields.

If the Display Mobile Handoffs Exclusively button is selectedall sectors that a subscriber is linked to must be selectedin the graphical display for the mobile marker to appear.


10


yingond besttors isbox”aracter/

bestwhich

reating

scriber

o

2)

kers

10.3.2 Server Data

This subsection of the feature allows the user to define the selection criteria for displasubscribers based on whether the graphically selected sectors are the best servers, secservers or third best servers for the subscribers connected to them. Selecting secaccomplished by using the mouse to either “click” on the sectors of interest or by dragging a “around them.The user selects one or more of the buttons and defines the associated chcolors. See Figure 10-3.

Figure 10-3: Server Data

This sub-feature is most useful for locating regions of the simulation space that are beingserved by the cell sites of interest. By selecting sectors one at a time, the feature can illustratesectors are reaching too far into the coverage areas of surrounding cell sites, possibly cunnecessary interference.

10.3.3 Mobile Marker Display

These entry fields allow the user to define which drops and data to use for the displayed submarkers. See Figure 10-4.

Figure 10-4: Mobile Marker Display

These buttons activate the display of subscribersmeeting these best server criteria.

The user defines a unique color for the subscribersby clicking these boxes and selecting the desired color.

The user defines a unique marker character for each criteriaby typing a character into these fields.

The Display Drops fields define which consecutive drops tuse for displaying subscribers. The user enters thenumbers for the drops.

The Color By buttons/ellipsis specify what type ofinformation is to be displayed for each mobile marker.

The Handoff/Server button selects whether the mobileinformation will represent the mobile handoff data(Section 10.3.1) and the mobile server data (Section 10.3. - or -a column of data from the MobileStat output file.

The Marker Size ellipsis opens a pull down menu whichallows the user to select the font size of the character marselected for the subscribers.


10


inedEc/Io

yed for. The

etingf thee cell/

d

mn.

l

ed

e

10.4 Cell Data

The CMA feature can display cell data from either the CellStat output file or from a user defcell data file. This data can be displayed as numerical statistics, colored arcs, or the BestServer footprint colored to represent the value of the selected data. The data may be displaany one simulation drop or may be displayed as the mean value for all the simulation dropsuser selects which data column to display on the graphical interface. See Figure 10-5.

Figure 10-5: Cell Data

This sub-feature is very useful in determining which sectors are experiencing problems metheir performance goals. It also provides a graphical display of the relative performance oadjacent sectors, enabling the user to determine what action to take when re-adjusting thsector parameters.

These buttons activate whether numerical data, color codearcs or color coded Best Ec/Io Server footprints will bedisplayed showing the magnitude of the selected data colu

These two buttons select between internally generated celdata or a user defined data input file.

These two buttons select between displaying the data froma specified simulation drop or displaying the mean calculatvfor all the drops of the simulation run.

This ellipsis and data field select the file that contains thecell output data.

This ellipsis and data field select the data column within thcell data file to use for display purposes.


10


anddowneen

rs toin the

10.5 Edit Coloring

Displaying the cell/mobile data often utilizes applying sliding scale coloring to markers, arcsBest Ec/Io Server foot prints. The assignment of the coloring scales is made through the pullmenu under the “Edit” option within the Cell/Mobile Analysis window. The user selects betwcoloring mobile or cell data. See Figure 10-6.

Figure 10-6: Edit - Coloring

The Mobile Blanking option (also under the Edit pull down menu) forces all subscriber markethe forefront which prevents them from being obscured by any other displayed graphics withgraphical interface.


NetPlan CDMA SimulatorImages Output and

Analysis

Chapter

11
Table of Contents
1 - 311 - 31 - 7

1 - 81 - 9

1 - 11 - 12 - 13 - 14 - 15 - 17

1 - 19 - 20 - 22

1 - 231 - 24 - 26 - 271 - 28 - 31

11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1.1 Image Creation and the Image Probe . . . . . . . . . . . . . . . . . . . . .11.1.2 Image Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

11.2 Simulator Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.1 Best Ec/Io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.2 Best Ec/Io Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.3 Nth Best Ec/Io . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.4 Nth Best Ec/Io Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.5 Pilots > T-DROP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.6 Soft Handoff State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.7 Forward Required Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.8 Reverse Required Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.9 Forward TCH Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.10 Forward Achieved FER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.11 Reverse Achieved FER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.12 Forward F Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2.13 Mobile Received Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.14 Pilot Pollution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1111.2.15 Supplemental Channels (HSPD Supp Chnl) . . . . . . . . . . . . . . . . 111.2.16 IS-2000 Achieved Data Rate Image (Active Probe) . . . . . . . . . . 11


11

Chapter 11: NetPlan CDMA Simulator Images Output and Analysis

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


11


plainsroblemstem.tical

ode.nder

11.1 Overview

This chapter describes the available images created by the NetPlan CDMA Simulator and extheir use. Several of these images are used during the optimization process to determine pareas. These images alone do not determine the “coverage” provided by the CDMA syCoverage images will be addressed in Chapter 13, “NetPlan CDMA Composite & StatisImages”.

11.1.1 Image Creation and the Image Probe

CDMA Simulation Images can only be created when NetPlan is set in the Non Time-Sliced mThis mode is selected via the pull down menu Configure>Simulation Parameters>CDMA uthe Simulation Model tab as shown in Figure 11-1.

Figure 11-1: CDMA Parameters / Non Time-Sliced


11


m theenu

able

two11-3).seudo-

The NetPlan simulation is launched by selecting the desired images to be generated fro“Image Creator” window. The Image Creator window is accessed via the pull down mImages>Create as shown in Figure 11-2.

Figure 11-2: Create Images

By selecting the CDMA Simulator tab at the top of the Image Creator window, the list of availCDMA images is shown under three tabs, “Loaded”, “Unloaded” and “Active”.

The “Loaded” tab is used most often in the creation of images for CDMA simulations. All butof the available images created by the simulator are selected under this tab (refer to FigureThe images created under this tab show the effects the system load has on one additional psubscriber (the Image Probe).


11


(refer

s notd, thective

selectthelist byanyages

11-3).

MAped”withinrun

The “Unloaded” tab is used to create a Best Ec/Io Server plot for a system with no traffic loadto Sections 5.2.1.3.1 and 11.2.2 for more information).

The “Active” tab is used to create an IS-2000 Achieved Data Rate Image. (This image doepertain to IS-95B High Speed Packet Data). In addition to effects due to the system’s loaAchieved Data Rate Image utilizes an “Active Probe”. More details on this image and the aprobe are given in Section 11.2.16.

From the Image Creator window, the user can either select the specific images desired, orthe “All On” button (which selects all the images). The “Down” arrow is used to place all ofselected images into the list of images to be produced. An image can be deleted from theselecting it and clicking on the “Up” arrow. The user can make image selections fromcombination of the three tabs before moving on to the next step. When all of the desired imhave been selected and added, pressing “Create” will begin the simulation (refer to Figure

Figure 11-3: Image Selection

11.1.1.1 Image Creation Process

In order to correctly interpret the images, it is important to understand how the NetPlan CDSimulator creates these images. The distinction between the contribution of the “dropsubscribers and the images created with the “image probe” must be understood. Each dropa Monte Carlo simulation run can be thought of having two distinct steps which aresequentially.

}


11


thetics(Nopped

d andannelstatisticsentire

f theawareto thet the

hapterticalfrom

f therea isay be

indow.p.

data tost vann then on

agesriber.

flectr

Sectionte theseresentsystem: oneer withiewingts. Forned tounlessges inis not

s not

The first step in a simulation run is the actual placement of “dropped” subscribers intosimulation space. This step is always run even if the Cell/Mobile Statis(Images>Create>CDMA Simulator>Loaded>Cell/Mobile Statistics) button is not selected.statistical results are saved if the “Cell/Mobile Statistics” button is not selected.) Once the drosubscribers are placed, the simulator goes through iterations to arrive at all their forwarreverse link powers along with the soft handoff states and assignment of supplemental ch(for data users). It does not generate images, but rather creates the cell and subscriber unit swhich can be analyzed to illustrate the performance status of the system for each drop or theMonte Carlo run. The importance of this first step in the creation of images is the setting oenvironment into which the image probe will operate for the second step. The user should beof the impacts that dropped subscribers have on the resulting image. Almost all of the inputssimulator will impact the environment the image probe must deal with, and therefore, impacresulting images (see Chapter 6, “Setting Simulator Input Parameters - System Level” and C7, “Setting Simulator Input Parameters - Site”). Chapter 9, “NetPlan CDMA Simulator StatisOutput and Analysis”, contains further information concerning the use of statistics gatheredthe dropped subscribers.

Thesecond stepin a simulation run is the creation of the selected images through the use oimage probe. The image probe is placed in every bin within the image area. The image adefined in the Configure>Simulation Parameters>Geographic pull down menu. This area mfurther confined by selecting an exclusion mask from the same Geographic Parameters wThe image probe does not impact Cell/Mobile statistics information gathered in the first ste

The image probe establishes a new connection in each image bin and records the relevantthe selected images for each bin. It may be helpful to think of the image probe as being a te(subscriber unit) that is driven throughout the system while a specific traffic load is active osystem. Refer to Section 6.2.2.6, “CDMA Parameters - Images Tab”, for the discussioparameters to be set for the image probe.

Note: The Image probe must be defined as a voice subscriber when generating all imexcept for an Achieved Data Rate image when it must be defined as a data subsc

The implication of the image probe is that the images generated for a simulation run will rethe performance for onlyone specific user type(defined by the image probe’s subscribecharacteristics). If more than one subscriber class has been defined for the system (see6.2.2.4), a separate set of images may be desired for each subscriber class. To generaimages, the user will need to perform separate simulation runs using an image probe that repone specific subscriber class for each run. For example, in order to determine the sperformance for in-building users and for in-vehicle users, two simulation runs are requiredwith the image probe subscriber characteristics set to represent an in-building user, the oththe image probe subscriber characteristics set to represent an in-vehicle user. When revimages for this scenario, one needs to keep in mind the type of user the image represeninstance, poor coverage images in rural areas which result when the image probe is defirepresent an in-building user is not necessarily an indication of poor system performance (in-building penetration is desired in the rural areas). Conversely, very good coverage imaurban areas which result when the image probe is defined to represent an in-vehicle usernecessarily an indication of good system performance (unless in-building penetration irequired in the urban areas).


11


onstantrobetics”refermix ofrops”

e usingFirst(Pilotwhented to

roughpath:ata

The image probe does not make use of the Speed Map, but rather uses one fixed speed (Cspeed distribution method) in all bin locations (refer to Section 6.2.2.6). Typically, the image pwill operate with one fixed ray model. The ray model is selected in the “Probe Characterisportion of the Images tab as found in the Configure>Simulation Parameters>CDMA window (to Section 6.2.2.6). If, however, it is desired that the image probe subscriber use the samedelay spread models as that used by the dropped subscribers, then the “Vary Across Dselection should be made in this window.

11.1.2 Image Format

The number of images generated for each image type depends on the various settings madthe CDMA Parameters window - Simulation Model tab (Section 6.2.2.1, Restrict Images to__ Drops), and the CDMA Parameters window - Images tab [Section 6.2.2.6, Nth Best Ec/Ioand Server) Images]. Table 11-1, Quantity of Images, illustrates this further. For example,creating Forward Required Power images, a simulator run with 10 drops, and images restricthe first 3 drops, would produce three images named “Forward Required Power Drop 1" th“Forward Required Power Drop 3". These image files are placed in a sub-directory (Analysis_Name/CDMA_DROP/Image_Type). Simulator images are formatted as compressed din binary form.

Table 11-1: Quantity of Images

Image Type Number of Images Produced

Forward Achieved FERForward F Factor

Forward Required PowerForward TCH ThresholdMobile Received PowerPilots Above T-DROPReverse Achieved FER

Reverse Required PowerSoft Handoff State

HSPD Supplemental Channel

Number of images generated for eachimage type is set based on:

Restrict Images to First __ Drops parameter

Pilot PollutionBest Ec/Io

Best Ec/Io Server/SectorAchieved Data Rate

One

Nth Best Ec/IoNth Best Ec/Io Server/Sector

Number of images generated for eachimage type is set based on:

Quantity of Images Generated parameter


11


ers,drop.s the

dow,able

Each image file for each drop within a simulation run may be slightly different from the othreflecting the impact on the system from the subscriber distribution/connection status for thatNo one single plot exactly depicts the performance of the system, but rather depictperformance contingent on the position and status of the traffic load for that drop.

11.2 Simulator Images

Simulator images are displayed by selecting Images>Display. From the resulting Display winthe CDMA Simulator button is selected to list all of the CDMA simulator images that are availfor viewing. From the list of images, select the image to be displayed and click OK.

Figure 11-4: Display Images

} Select the image to bedisplayed then clickthe “OK” button.


11


tPlan

magep” oftingtionthe

The following sections provide a brief description of the available images produced by the NeCDMA Simulator and their usage during a system design.

11.2.1 Best Ec/Io

The Best Ec/Io image identifies the Ec/Io obtainable from the best serving cell site at each ibin location as determined by the image probe. This image is only generated for the first “droany CDMA Monte Carlo simulation run (regardless of the settings for restricting or not restricthe number of images to the first “N” drops - see Figure 6-3, “CDMA Parameters - SimulaModel”). The Ec/Io values are usually displayed for bins in which the Ec/Io is greater thanfinger locking threshold (as defined in Figure 6-16, “CDMA Parameters - Images”).

Figure 11-5: Best Ec/Io


11


cern.ofterred

as ofctivee of

intoand

a binand

value

ntial12,

The Best Ec/Io image provides a good indication of pilot signal strength in a given area.

• The areas of the plot which are below the T-ADD threshold represent areas of conIn these regions, the subscriber unit would not be able to initiate a new soft/shandoff connection and the reliability of the existing connection would be considemarginal.

• The areas on the plot which are below the T-DROP threshold also represent areconcern. In the real world, if the call transgresses from a state where all of the apilots are above T-ADD to the state where all pilots are less than T-DROP, all but onthe pilots will be dropped from the active list. At this point the subscriber may movean area of better signal quality or the call may end up loosing its connectiondropping. Within the simulation image, such a condition would be represented ashaving no pilots above T-DROP. In this region, the link between the subscriber unitcell system would be even more marginal than the preceding case.

• There is no coverage in areas that are below the finger locking threshold. A defaultof -120 dB will be generated in the bins for these areas.

• Extremely high values of Ec/Io throughout a system may be indicative of a potepilot pollution situation. Further investigation would be warranted. Chapter“Treating Pilot Pollution”, provides additional detail on analyzing pilot pollution.


11


serverited toshold

theted

ll beraffic

11.2.2 Best Ec/Io Server

The Best Ec/Io Server image identifies all the bins associated with a server which have thatas the dominant pilot. The Best Ec/Io Server bins that are displayed in the image can be limthose bins which have an Ec/Io value greater than a given cutoff threshold. This cutoff threcan be set at T-DROP or at a user defined Ec/Io level. This selection is made inConfigure>Simulation Parameters>CDMA>Images window with the “Server Not CompuWhen Ec/Io Below” settings (refer to Section 6.2.2.6). This image identifies what regions wiprimarily served by a particular server. This image may also be used in conjunction with the TEngineering Tool to help create a traffic distribution map (see Chapter 5, “Traffic (Distribution)and Speed Maps”).

Figure 11-6: Best Ec/Io Server Image


11


c/Ioagetion

ingere ofterggerg

ofe

idersd canot

11.2.3 Nth Best Ec/Io

The Nth Best Ec/Io images are similar to the Best Ec/Io image except they display the Eobtained from theNthbest serving cell site at each image bin location as determined by the improbe. These images are only generated for the first “drop” of any CDMA Monte Carlo simularun. The Ec/Io values are usually displayed for bins in which the Ec/Io is greater than the flocking threshold (as defined in Figure 6-16, “CDMA Parameters - Images”). A default valu-100 dB will be generated in bins of theNthBest Ec/Io images where the Best Ec/Io level is greathan the finger locking threshold but theNth Best Ec/Io level is less than the finger lockinthreshold. In areas of theNth Best Ec/Io image where the Best Ec/Io level is less than the finlocking threshold (which implies that theNth Best Ec/Io level is also less than the finger lockinthreshold), a default value of -120 dB will be generated.

The number of Nth Best Ec/Io images created are determined by the “QuantityImages Generated” parameter as defined in Figure 6-16, “CDMA Parameters - Images”. ThNthBest Ec/Io image gives a good indication of pilot signal strength for the 2nd and 3rd link provduring soft handoff for a given area. Areas of the plot which are below the T-DROP thresholnot be used to provide soft handoff links. TheNthBest Ec/Io images are also used in studying pilpollution problems, as addressed further in Chapter 12.

Figure 11-7: 2nd Best Ec/Io Image


11


thate

shold.madeNot

hatllution

11.2.4 Nth Best Ec/Io Server

TheNth Best Ec/Io Server image identifies all the bins associated with a server which haveserver as theNth most dominant pilot. TheNth Best Ec/Io Server bins that are displayed in thimage can be limited to those bins which have an Ec/Io value greater than a given cutoff threThis cutoff threshold can be set at T-DROP or at a user defined Ec/Io level. This selection isin the Configure>Simulation Parameters>CDMA>Images window with the “ServerComputed When Ec/Io Below” settings (refer to Section 6.2.2.6). This image identifies wregions will be served by a secondary server. These images are also used in studying pilot poproblems, as addressed further in Chapter 12.

Figure 11-8: 3rd Best Ec/Io Server Image


11


gionsinant

some

pilotesey thenoise.ower,

11.2.5 Pilots > T-DROP

The Pilots > T-DROP (also shown as Pilots Above T-DROP) image portrays geographic rewhere a subscriber unit would experience N pilots above T-DROP as defined by the domserver.

Figure 11-9: Pilots > T-DROP Image

Areas shown with 0 pilots represent regions where there are no links above T-DROP. Incases, adjustments to T-ADD/T-DROP and/or pilot power may reduce these regions.

Areas shown with 4 pilots or more represent regions which may suffer from a non-dominantcondition called “pilot pollution”. Pilot pollution is addressed in greater detail in Chapter 12. Thpilot pollution areas are of concern since only 3 fingers can be used simultaneously bsubscriber unit’s rake receivers. Anything greater than 3 pilots is perceived as additionalAttempts should be made to reduce the number of pilots in these regions (by adjusting pilot pdowntilting the antennas, etc.).


11


ould

temandoffandoff

r mustthisderedn or

ADD.-ADD

11.2.6 Soft Handoff State

The Soft Handoff State image portrays geographic regions where a subscriber unit wexperience a particular state of soft/softer handoff.

Figure 11-10: Soft Handoff State Image

The CDMA Simulator works with an instantaneous “static” representation of the CDMA sysand therefore can not emulate the hysteresis and motion aspects of determining soft/softer hstates. For this reason, the simulator takes a different approach to assigning soft/softer hstates.

For a bin within the image to be considered a one way connection to the system, the simulatoperceive a minimum of one pilot with an Ec/Io greater than or equal to T-ADD. The T-ADD incase is the T-ADD assigned by the best serving pilot. For a bin within the image to be consiin soft/softer handoff, the simulator must perceive two or three pilots with Ec/Io greater thaequal to T-DROP with the requirement that at least one pilot be greater than or equal to T-The assumption here is that the pilots which are above T-DROP would have been above Tat one time and would still be on the active list for the subscriber unit.


11


n to be

for a

engthl hasulator

binse then ofther

This approach is a necessary compromise in modeling how CDMA works and has been seea reasonable approach when compared to results obtained from trial systems.

Table 11-2, Soft Handoff State Criteria for Images, identifies the criteria which must be metbin location on the soft handoff image to be assigned a handoff state.

Table 11-2: Soft Handoff State Criteria for Images

In the real world, a subscriber may have a 1 Way connection with a pilot that has a signal strless than T-ADD. However, this connection may be of questionable reliability (e.g. the caltransgressed from a good signal area to the fringe of coverage). Since the CDMA Simrequires one pilot to be above T-ADD in order to be in a SHO state other than 0 Way, thesewould be shown as having 0 Way SHO in the Soft Handoff State image. In order to providuser with some insights as to which bins might actually result in a 1 Way connectioquestionable reliability in the real world, the Soft Handoff State image provides a furbreakdown of the 0 Way SHO state to show the number of links that are above T-DROP.

SHOState

# Links >T-DROP

# Links >T-ADD

Soft & PrimaryLinks

Softer LinksFrom One Site

0 Way 0,

1, 2, 3+

0 0 0

1 Way 1 1 1 0

2 Way Soft 2 > 1 2 0

3 Way Soft 3 > 1 3 0

2 Way Softer 2 > 1 0 2

2 Softer 1 Soft 3 > 1 1 2

3 Way Softer 3 > 1 0 3


11


ctor’sbin/n the

allx willnel

vered

11.2.7 Forward Required Power

The Forward Required Power image shows the forward power from the best serving seamplifier that is required to meet the image probe’s forward FER threshold at a particularlocation. For a bin to be populated with a value it must also have an Ec/Io which is greater thasystem finger locking threshold.

Figure 11-11: Forward Required Power Image

If the simulation is run using the same maximum traffic channel forward power (TCH Max) insectors, then any bin on the image that shows a required forward power in excess of TCH Manot be covered on the forward link. If the simulation is run using differing maximum traffic chanforward power (TCH Max) in the sectors, then there is no way to determine which bins are coon the forward link using only this image.


11


e andoluterward

ighests adinghave

Optimizing the performance of a design often requires varying the relative levels of Pilot, PagSync. As a result, TCH Max often varies from sector to sector. In this instance, an absdetermination of coverage holes can not be ascertained through the use of just the FoRequired Power image. Any region which shows a required forward power in excess of the hTCH Max for the immediate surrounding cells will not be covered. A region which showrequired forward power which is less than the highest TCH Max for the immediate surrouncells, yet higher than the least TCH Max for the immediate surrounding cells, may or may notcoverage. See Section 11.2.9,"Forward TCH Threshold" for a solution to this dilemma.


11


nit at acted.than

fore,versen theof the

11.2.8 Reverse Required Power

The Reverse Required Power image shows the reverse power required from a subscriber uparticular bin to meet the reverse FER threshold for the cells/sectors to which it is conneAdditionally, for a bin to be populated with a value, it must also have an Ec/Io which is greaterthe finger locking threshold of the best serving pilot.

Figure 11-12: Reverse Required Power Image

Often, simulations are run assuming subscriber units with 200 mW or 23 dBm of power. Thereany bin which shows required reverse power in excess of 23 dBm will not be covered on the relink. If more than one class of subscriber with differing subscriber unit powers is to be used isystem, a unique color can be assigned to an interval which represents the coverageassociated class of subscriber.


11


rwardx not

11.2.9 Forward TCH Threshold

The Forward TCH Threshold image shows the regions as either covered, or not, from a FoRequired Power perspective. The image displays either a “TCH max exceeded”, a “TCH maexceeded” or a “No Server” for each bin location.

Figure 11-13: Forward TCH Threshold Image


11


r then the

ts forMaxAreasward

MA

A “TCH max not exceeded” is assigned to a bin when the Forward Required Power value fobin is less than or equal to the TCH Max for the serving sector, and the Ec/Io is greater thafinger locking threshold of the best serving pilot. The Forward TCH Threshold image accounthe varying TCH Max values from sector to sector. The areas of an image that show “TCHexceeded” indicate regions that are not covered from a forward required power perspective.of “TCH Max not exceeded” indicate regions where coverage would be expected from a forrequired power perspective.

Note: The use of this image is covered in more detail in Chapter 13, “NetPlan CDComposite & Statistical Images (Coverage vs. Path Loss)”.


11


ink tot FERich areard link. The

ard linky the

11.2.10 Forward Achieved FER

The Forward Achieved FER image shows the FER performance achieved by the forward lthe image probe at a particular bin. The areas of the image which are below the targerepresent areas where the forward link target FER is achieved. The areas of the image whgreater than the target FER and less than the outage FER represent areas where the forwtarget FER is not achieved yet the forward link remained acceptably below the outage FERareas of the image which are greater than the outage FER represent areas where the forwperformance is not acceptable. This image gives a fair indication of the coverage offered bforward link for one simulation drop.

Figure 11-14: Forward Achieved FER Image


11


r unit’sw thee imagehere theoutageere the

erage

11.2.11 Reverse Achieved FER

The Reverse Achieved FER image shows the FER performance achieved by the subscribereverse link to the cell system from a particular bin. The areas of the image which are belotarget FER represent areas where the reverse link target FER is achieved. The areas of thwhich are greater than the target FER, and less than the outage FER, represent areas wreverse link target FER is not achieved yet the reverse link remained acceptably below theFER. The areas of the image which are greater than the outage FER represent areas whreverse link performance is not acceptable. This image gives a fair indication of the covoffered by the reverse link for one simulation drop.

Figure 11-15: Reverse Achieved FER Image


11


ation.

Factorwhich

11.2.12 Forward F Factor

The Forward F Factor image shows the calculated forward link F Factor at a particular bin locThe F Factor is a CDMA term which is defined as:

[EQ 11-1]

Where: Iin is the noise interference generated within a best serving sector andIout is the noise generated outside of the best serving sector from other sites

F Factor values are normally represented by a decimal number ranging from 0 to 1. The Fimage takes the normal F Factor value and multiplies it by one hundred to achieve a numberranges from 0 to 100.

Bin% = 100 xF [EQ 11-2]

Figure 11-16: Forward F Factor Image

FI in

I in I out+---------------------=


11


e cellThis

cells,

of thege ofativepping

fromeffectsf the

this

Image bin values near 100% represent areas in which the noise generated from within thdominates. This will occur close to the cell and in the direction of the antenna azimuth.condition is also indicative of a heavily loaded cell/sector being surrounded by lightly loadedor no cells at all.

Image bin values down around 10% represent areas in which the noise generated outsidesector is dominating the noise that is present within the sector. This will occur toward the eda cell where energy from many cells compete with the best server cell. This condition is indicof a lightly loaded cell/sector being surrounded by heavily loaded cells that also have overlacoverage with the serving cell’s coverage area.

The Forward F Factor image is important because it will identify areas where noise is highoutside of the sector. In these cases, one would expect coverage plots which include CDMAto suffer compared to path loss only plots. Conversely, when noise is lower from outside osector, coverage plots which include CDMA effects will perform better than path loss only.

Experience has shown that an accepted crossover point for the F Factor is:

F% > 33%

At this point, the energy from outside the cell is twice the energy from within the cell. Belowpoint is where out of cell interference becomes dominant.


11


in thetest

11.2.13 Mobile Received Power

The Mobile Received Power image displays the sum of all traffic channel energy presentsubscriber unit’s receiver IF for each bin location. This image may be compared with drivemeasurements.

Figure 11-17: Mobile Received Power


11


resetc/Io

tionbest

Pilotusedh arede to

Pilot

11.2.14 Pilot Pollution

The Pilot Pollution image displays the number of pilots which have an Ec/Io value within a pdB level of the best serving sector Ec/Io. This level is set with the “Count Pilots When EGreater Than” parameter as defined in Figure 6-16, “CDMA Parameters - Images”.

Figure 11-18: Pilot Pollution Image

The Pilot Pollution image is used to identify areas where multiple pilots meet the pilot polluthreshold criteria. If there are four or more strong pilots at the same location (including theserving Ec/Io), then these areas may suffer from a non-dominant pilot condition called “Pollution”. These pilot pollution areas are of concern since only 3 fingers can besimultaneously by the subscriber unit’s rake receivers. Any additional pilots (beyond 3), whicrelatively close in received Ec/Io are perceived as additional noise. Attempts should be mareduce the number of pilots in these regions (by adjusting pilot power, downtilting, etc.).pollution is addressed with greater detail in Chapter 12.


11


ere theentalental

uld beunctionoice-95B

robe’sthe

and the

mustmaden canf the

11.2.15 Supplemental Channels (HSPD Supp Chnl)

The High Speed Packet Data Supplemental Channels image portrays geographic regions whimage probe would be assigned forward link supplemental channels (in addition to a fundamchannel) if the image probe were an IS-95B HSPD subscriber. In addition to where supplemchannels will be assigned, this image also shows how many supplemental channels coassigned to the image probe. The number of supplemental channels assigned is largely a fof the underlying Ec/Io conditions. System adjustments intended to influence the vsubscriber’s Ec/Io will also impact the number of assigned supplemental channels for the ISHSPD subscriber.

A maximum of 7 IS-95B supplemental channels can be assigned regardless of the image psubscriber Radio Configuration (RS1 or RS2). The algorithm that is used to assignsupplemental channels is based on the image probe’s subscriber Radio Configuration valuemeasured Ec/Io.

11.2.15.1 Creating the High Speed Packet Data Supplemental Channels Image

In addition to the usual inputs which must be set for any simulation run, certain prerequisitesbe fulfilled prior to generating an IS-95B Supplemental Channels Image. A selection must befor the data rate at which the image probe will operate (9.6 kbps or 14.4 kbps). This selectiobe made from within the “IS-95B Supplemental Channel Image” portion of the “Images” tab o“CDMA Parameters” window (see Figure 11-19).


11


Figure 11-19: CDMA Parameters / Supplemental Channel Image


11


certain. The

annels

ns

The image in Figure 11-20 depicts the areas where the image probe would be assigned anumber of HSPD supplemental channels in the presence of the overall system traffic loadresulting data rate offered to subscribers is directly related to the number of supplemental chavailable at a given location.

Figure 11-20: HSPD Supp Chnl Image

The reader is directed to Appendix 4 - Data Services System Design for further discussioconcerning CDMA high speed packet data designs.


11


Lowercan beloadtest

arrantyscribersed dataound

ctivenots (seethe loade slight

may beeneralt data

em.

ageust beProbethewersusers).e staysses oftreatede and

probeeing

11.2.16 IS-2000 Achieved Data Rate Image (Active Probe)

The Achieved Data Rate Images can be generated as either a “Upper Bound Data Rate” or “Bound Data Rate”. They are geographical representations of the IS-2000 data rates thatrealized by the active packet data image probe at any given location under specific trafficconditions. The traffic load conditions created within NetPlan are not repeatable in a fieldsituation. Therefore, these images should not be used for coverage/system performance wpurposes. These images are created in the Non Time-Sliced mode and represent data subthat are in a constant data burst state, much like circuit switched data. The expected achievrate for a packet data probe would likely fall between the results presented in the Upper BData Rate and Lower Bound Data Rate images.

11.2.16.1 Active Probe

The Achieved Data Rate Image is the only image created by NetPlan that utilizes an “AProbe”. For all other CDMA Simulation Images, the “Image Probe” is not “Active” and doesplace a load on the system during the second step of the image creation procesSection 11.1.1.1). For these images (which use a Passive Image Probe), it is assumed thatthe Image Probe places on the system (or any one sector) is not significant, and therefore thinaccuracy this causes in the resulting image can be tolerated.

The load a single IS-2000 packet data subscriber places on the system (or any one sector)sufficiently large as to change the operation of the system and other subscribers in the gregion of the data subscriber. When the image probe is defined to be an IS-2000 packesubscriber, it becomes necessary to model its impact on the dropped subscribers and syst

This modeling is accomplished through the use of an “Active Probe”. The Active Probe (improbe) must have the characteristics of a packet data subscriber. Like all image probes, it massigned a constant speed. During the creation of the Achieved Data Rate Image, the Activeis moved from bin to bin within the simulation space. Each time it is located in a new bin,simulator goes through the iterations required to arrive at the forward and reverse link poalong with the soft handoff states and assignment of supplemental channel rates (for dataThis is done for all the dropped subscribers as well as for the image probe. The image probin a data transmission state for each bin location and does not go through the different phathe state model as do the dropped subscribers. Otherwise, the image probe is “active” andlike one of the dropped subscribers. This allows for the interaction between the image probthe rest of the system to be modeled.

Creating an image using an active probe is very time intensive. Each placement of the imageinto another bin is equivalent to another simulation drop (where only statistics are bgenerated).


11


e. Inst beeters -

ad w/ingsr in2000A

11.2.16.2 Creating the Achieved Data Rate Image

Certain prerequisites must be fulfilled prior to generating an Achieved Data Rate Imagaddition to the usual inputs which must be set for any simulation run, the image probe mudefined as an IS-2000 Packet Data Subscriber (see Section 6.2.2.4) and the CDMA ParamSimulation Model must be set in the Non Time-Sliced mode (see Figure 11-1).

A selection must be made between either generating an “Upper Bound Data Rate (Traffic LoFCHs only)” image or a “Lower Bound Data Rate (Traffic Load w/SCHs)” image. The meanof these two different Achieved Data Rate Image types will be described furtheSection 11.2.16.3 and Section 11.2.16.4. This selection is made from within the “IS-Achieved Data Rate Image (Active Probe)” portion of the “Images” tab of the “CDMParameters” window (see Figure 11-21).

Figure 11-21: CDMA Parameters / Achieved Data Rate Image

1

2


11


m the
The Achieved Data Rate image is created by selecting the Achieved Data Rate image froImages Creator’s CDMA Simulator Active tab (see Figure 11-22).
Figure 11-22: Image Create - Achieved Data Rate Image

The Achieved Data Rate image is only generated for the first drop of a simulation run.


11


allmentalthat theer this

riencedture.et datariber”

11.2.16.3 Upper Bound Data Rate Image (Traffic Load w/FCHs only)

The Upper Bound Data Rate Image (Traffic Load w/FCHs only) is created by restrictingdropped IS-2000 packet data subscribers to connect to the system using only their fundachannels. (Voice dropped subscribers behave normally.) The image shows the data ratesactive image probe is able to achieve while the remainder of the system is operating undconstraint (see Figure 11-23).

Figure 11-23: Upper Bound Data Rate Image(Traffic Load w/FCHs only)

This image is an optimistic representation of the actual achieved data rates that may be expein a system under similar traffic loads. It is called “Upper Bound” because of its optimistic naThe results are optimistic because the system load presented by the dropped packsubscribers is constrained to only assigning them fundamental channels. The only “subscallowed to operate at higher data rates is the image probe.


11


theze therobe isshowstem is

11.2.16.4 Lower Bound Data Rate Image (Traffic Load w/SCHs)

The Lower Bound Data Rate Image (Traffic Load w/SCHs) is created by allowing all ofdropped IS-2000 packet data subscribers that are connected to the system to fully utilisupplemental channel resources that are available before the active packet data image pallowed to connect to the system. (Voice dropped subscribers behave normally.) The imagethe data rates that the active image probe is able to achieve while the remainder of the sysoperating with both fundamental and supplemental channels assigned (see Figure 11-24).

Figure 11-24: Lower Bound Data Rate Image(Traffic Load w/SCHs)


11


riencedture.et dataprobe.s theet data

This image is a pessimistic representation of the actual achieved data rates that may be expein a system under similar traffic loads. It is called “Lower Bound” because of its pessimistic naThe results are pessimistic because the system load presented by the dropped packsubscribers is greater than would normally be experienced by the active packet data imageThe “Lower Bound” active packet data image probe is not given equal opportunity to accessystems resources. Instead, it must utilize the resources left over after the dropped packsubscribers have been fully supported.


Treating Pilot Pollution
Chapter
12
Table of Contents
2 - 3

- 3

2 - 52 - 52 - 712 - 8

- 8 - 9 - 10

14 - 15 - 16

12.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

12.2 The Pilot Pollution Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

12.3 NetPlan Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.1 CDMA Image Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 NPINIT File Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Creating Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12.4 Analysis of Output Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.4.1 Viewing the Pilot Pollution Image. . . . . . . . . . . . . . . . . . . . . . . . 1212.4.2 Data Query - Pilot Pollution Sites . . . . . . . . . . . . . . . . . . . . . . . . 12

12.5 Correcting Pilot Pollution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 -12.5.1 Pilot Pollution Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.5.2 Pilot Pollution Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12


12

Chapter 12: Treating Pilot Pollution

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


12


ree

ing” -

m

ven

blems

leunit

threets willTherapid

is theignals.

n pilotat thetion to

12.1 Overview

Pilot pollution is a problem that detracts from CDMA system coverage. The following thimages must be taken into account to analyze the potential for pilot pollution issues:

1. ThePilot Pollution image displays the number of pilots (in addition to the best servpilot) which have an Ec/Io value within a preset dB level (“Pilot Pollution Thresholdusually 6 dB) of the best serving sector Ec/Io.

2. TheBest Ec/Io(Nth Best Ec/Io) image displays the Ec/Io value which is obtained frothe best (Nth best) server.

3. TheBest Ec/Io Server(Nth Best Ec/Io Server) image displays the area where the gisector pilot is the best (Nth best) server.

This chapter describes how to use these images to investigate and correct pilot pollution prowithin a CDMA system design.

12.2 The Pilot Pollution Problem

Pilot pollution (also known as a “Non-Dominant Pilot” condition) is the condition where multippilots have similar signal strengths (Ec/Io levels) at a location (image bin). A subscriberreceiver at this location will attempt to use its three rake receiver fingers to lock onto the toppilots. Due to the ever changing system load, the signal strengths (Ec/Io levels) of these pilofluctuate with time causing the order of the strongest pilot signals to change with time.subscriber unit and cell system infrastructure may not be able to keep up with thesefluctuations which may result in a dropped call. A secondary detraction to the connectionprobable elevated interference energy from the uncorrelated channels of the additional sThis elevated interference energy can be seen in the Forward F Factor image.

If the same pilots are encountered but one to three are elevated in strength from the rest, thedominance is achieved and the subscriber unit connection is secured. This illustrates thabsolute signal strengths of the pilots are not the issue, but rather the magnitudes with relaeach other.


12


th ofotal ofan orr unitthree

ilot

6 dBllution

notts incriberrakeingleurcey links

s bypilots

f whetherto two

Figure 12-1: Pilot Pollution Threshold

The example given in Figure 12-1: "Pilot Pollution Threshold" shows the relative Ec/Io strengseven pilots. Three of the pilots are less than the 6 dB threshold of the best serving pilot (a tfour pilots are above the threshold including the best serving pilot). Three pilots are greater thequal to the threshold and do not pose a significant interference threat to the subscribeconnection. The three rake receiver fingers of the subscriber unit can make use of the toppilots. The fourth strongest pilot within the 6 dB threshold limit would be considered a ppollution contributor (a source of interference).

To correct this problem, the design should be adjusted so that only two pilots are within thethreshold of the best serving pilot. Design approaches that can be used to correct pilot powill be discussed later in this chapter.

The N-Way Complex Handoff Feature can help mitigate pilot pollution problems but it canreduce the available pilots in an area of pilot pollution. This feature allows for up to six pilothe active set, and provides for additional parameters to tailor handoffs. This allows the subsunit to choose the best three pilot signals from its active set (up to six pilots) to use for itsreceiver fingers. The Complex Handoff feature also allows for multiple adds or drops per a shandoff direction message which helps to improve the forward diversity and resomanagement. It may allow the subscriber unit to sustain a call by using the expanded diversitof the active set.

Although the N-Way Complex Handoff Feature may assist in diminishing pilot pollution issuekeeping the subscriber on the strongest three pilots, it cannot reduce the number of strongthat the subscriber sees in an area. Therefore, the design approach is the same regardless othis feature is used in a system or not. As mentioned before, the design approach is to limitthe number of pilots which are within the pilot pollution threshold of the best serving pilot.

Reference Level

6 dB Threshold

Best Serving Pilot2nd

3rd

4th

5th

6th7th


12


select

tion

Theages

n the

thee NthshownDMAtion

12.3 NetPlan Inputs

In order to generate and analyze Pilot Pollution images within NetPlan, one must properlyor specify the input parameters in three basic areas of NetPlan. These areas are:

• CDMA Parameters - Images windowThis window allows the user to specify parameters which are required for Pilot Polluimages.

• NPINIT ParametersThe analysis of Pilot Pollution images requires the use of the Data Query function.NPINIT file is used to set up sufficient memory space to review all the necessary imin Data Query.

• Image Creator windowThis window allows the user to select the proper images to generate for use ianalysis of pilot pollution.

The following subsections detail the inputs required in each of these NetPlan areas.

12.3.1 CDMA Image Parameters

The image generation input parameters that relate to pilot pollution are set inCDMA Parameters - Images window prior to running a simulation. These parameters are thBest Ec/Io (Pilot and Server) Images parameters and the Pilot Pollution Image parameter asbelow in Figure 12-2. These parameters are also covered in detail in Section 6.3.3. The CParameters - Images window is reached using the Configure>SimulaParameters>CDMA>Images menu selection.


12


tIo pilotatedPilot

tt dropd att the

d be

ldpted

Figure 12-2: CDMA Image Parameters Relating to Pilot Pollution

NOTES:

Note: 1. TheNth Best Ec/Io (Pilot and Server) Imagesparameters define specific criteria thaare used when these images are created. These image types show the best Ec/values (Nth Best Ec/Io Pilot Images) and the sector from which that value origin(Nth Best Ec/Io Server Images). Both of these image types are used along with thePollution image to investigate pilot pollution problems.

TheQuantity of Images Generated(N) field defines the number of Nth Best Ec/Io Piloand Server images to be produced. These images will only be produced for the firsof a Monte Carlo simulation run. The maximum number of pilots to be investigateany bin/location is equal to the value set for this parameter. It is recommended thatop nine (9) pilots be investigated for pilot pollution. Therefore, this parameter shoulset to 9.

TheServer Not Computed When Ec/Io Belowfield, when checked, applies a threshoto the Ec/Io Server image. This threshold defines the minimum pilot Ec/Io acce

1

3

2


12


rver

or at

to the).

endent

elect ation

dagethe

theP. A

lutionEc/Ioes and

ages

stemQueryIT

during the generation of this image. Resulting server images will not indicate a sefor any bin where the Ec/Io value is below this threshold.

There are two options available for specifying this threshold:T-Drop - which specifies the threshold as the T-Drop value for the best serving secteach image bin.User Defined Ec/Io- which specifies the threshold at a given user defined level.

Note: 2. The User Defined Ec/Io value shown in the figure above (-23.75 dB) correspondsfinger locking threshold (the value below which a subscriber cannot maintain a link

Note: 3. ThePilot Pollution Image field sets the threshold parameter that is used whgenerating Pilot Pollution images. The Pilot Pollution image generation is indepenfrom the Quantity of Images Generated (see previous note). It is not necessary to svalue of 2 or more in the Quantity of Images Generated in order to have Pilot Polluimages generated.

The Count Pilots When Ec/Io Greater Thanfield defines the threshold that is usewhen generating Pilot Pollution images. Each bin in the resulting Pilot Pollution imrepresents the number of pilots that have an Ec/Io value within this dB value ofstrongest pilot Ec/Io. The Ec/Io for all pilot pollution candidates must be withinthreshold value of the strongest pilot, though they do not need to be above T-DROtypical value used for this field is 6.

12.3.2 NPINIT File Parameters

The NetPlan Data Query function is used to analyze a system design for potential pilot polissues. This function is used to examine the Pilot Pollution image along with the 9 Bestimages, the 9 Best Ec/Io Server/Sector images, and the latitude/longitude layer (20 imaglayers). (Note that the value of 9 corresponds to the value assigned to the Quantity of ImGenerated for the Nth Best Ec/Io (Pilot and Server) Images in Figure 13-2.)

The NetPlan CDMA Simulator initialization file must be set up by the user or the computer syadministrator to allocate sufficient memory space to accommodate these images in the Datafunction. The following lines must be set in the NPINIT file as shown in Figure 12-3: "NPINEntry".

Figure 12-3: NPINIT Entry

! This defines how many images can be used in Data Query.

NetPlan.Cache.Number: 20


12


lems.

st be

ughe willmages

12.3.3 Creating Images

Three images must be generated during the simulation to fully investigate pilot pollution probThese three images are:

• Pilot Pollution

• Best Ec/Io (EcIo_1, . . ., EcIo_9)

• Best Ec/Io Server (EcIoServer_1,. . ., EcIoServer_9)

Figure 12-4: "Creating Images for Pilot Pollution Studies" identifies how these images muselected when initiating a simulation run.

Figure 12-4: Creating Images for Pilot Pollution Studies

12.4 Analysis of Output Images

The first step in analyzing pilot pollution is to display the Pilot Pollution image (accessed throthe Images>Display menu). (See Chapter 11 for more details on viewing images.) This imagbe the only image shown on the screen during the pilot pollution analysis process. The other iwill be accessed using the Data Query function.

Pilot Pollution imageBest (Nth Best) Ec/Io ServerBest (Nth Best) Ec/Io


12


theve noaryingcolors

tion tot show

12.4.1 Viewing the Pilot Pollution Image

When viewing the Pilot Pollution image, choose a color scheme that facilitates identifyingproblem areas. In the example below (Figure 12-5: "Pilot Pollution Image"), areas which hacoverage are colored black. Areas where there are only 1, 2 or 3 pilots present are colored vshades of gray. The remaining areas, where there are 4 or more pilots, are colored bright(with red representing the highest number of pilots). This approach draws the user’s attenthe areas where pilot pollution exists. The other images used to determine coverage may noan issue in these areas, however, the Pilot Pollution image will.

Figure 12-5: Pilot Pollution Image


12


xistance,age"

eralionEc/Io

mainelectData

A closer view of this example Pilot Pollution image shows areas where pilot pollution could ewithin a system. The Best Ec/Io image for this same area would indicate good pilot performnot revealing the possible existence of pilot pollution. (See Figure 12-5: "Pilot Pollution Imand Figure 12-6: "Pilot Pollution Image Close - Up").

Figure 12-6: Pilot Pollution Image Close - Up

12.4.2 Data Query - Pilot Pollution Sites

The Data Query feature of NetPlan allows a bin-by-bin numerical investigation of sevunderlying images while viewing a primary image. The next step in the pilot pollutinvestigation process is to load the Nth (1 - 9) Best Ec/Io images and the Nth (1 - 9) BestServer images into the Data Query feature of NetPlan.

To launch the Data Query feature, select the “Q” icon along the upper right edge of theNetPlan window (see Figure 12-7: "Launching Data Query"). In this Data Query window, sfrom the menu Configure>Data Query. This will open an image selector window, also titledQuery.

Pilot Pollution


12


ry (seeages

the

agendin

Figure 12-7: Launching Data Query

The second Data Query window allows the user to select which images to use for data queFigure 12-8: "Data Query Menu"). The last three image types in the select window are the imof interest to the pilot pollution study - Pilot Pollution, Nth Best Ec/Io, Nth BestEc/Io Server/Sector (19 images in this case).

1. An easy way to select them all is to first highlight the Pilot Pollution image in“BROWSER” box (see step 1a and 1b in Figure 12-8).

2. Scroll down to the end of the list in the “BROWSER” box and select the last imwhile holding down the < Shift > key. This will highlight all the necessary images aplace them below in the “SELECTED IMAGES/FILES” box (see step 2a and 2bFigure 12-8). Then click OK.


12


Figure 12-8: Data Query Menu

1a1b

2a

2b


12


f themes

. The

).

s in

The Data Query box will now show all the images that have been selected in the left half owindow. Adjust the window to minimize the amount of space it occupies while retaining the naand queried data in view.

While holding down the center mouse button move the cursor over the Pilot Pollution imageData Query window will display the following information for the selected bin:

• The Ec/Io and cell name of the best serving cell site.

• The number of pilots which are within the Pilot Pollution threshold parameter (6 dB

• The Nth Best Ec/Io values and site names for the eight remaining cell sitedescending order.

Figure 12-9: Data Query Example


12


D isthe

bestts is

6 dB

fault

e cell

esign.lutions goal

the

aches

h notarios.

.

In the example shown above (see Figure 12-9: "Data Query Example"), the value of T-AD-16 dB and the value of T-DROP is -18 dB. Examination of this above example revealsfollowing about the selected bin:

• The Pilot Pollution value shows that there are three (3) pilots (not including thepilot) within the 6 dB threshold of the best serving pilot. Therefore, one of these pilocausing pilot pollution.

• The best server is site 16 - sector 1 with an Ec/Io of -13 dB.

• Site 16 - sector 2 is the second best server with an Ec/Io of -14 dB.

• Site 15 - sector 2 is the third best server with an Ec/Io of -16 dB.

• Site 14 - sector 1 is the fourth best server with an Ec/Io of -18 dB.1

• Site 20 - sector 3, Site 11 - sector 2 and Site 11 - sector 3 are all at or below the -pilot pollution threshold.

• The 8th best pilot and 9th best pilot display an Ec/Io value of -100 dB. These are devalues that are used when a pilot does not exceed the finger locking threshold.

Being able to move the mouse around the Pilot Pollution image while gathering data on thsites involved gives the user insight to help choose a course of corrective action.

12.5 Correcting Pilot Pollution

There are two primary actions that are used to correct areas of pilot pollution in a system dThese actions are used to adjust the design so that only two pilots are within the pilot polthreshold of the best serving pilot. The two primary actions which are pursued to achieve thiare to:

1. Reduce the signal strength of the polluting pilots.2. Increase the signal strength of one or more pilots so that the fourth pilot is below

pilot pollution threshold level.

Either of these actions or a combination of both will achieve the desired result. Several approcan be used to enact the two actions.

Two examples will be given to illustrate approaches to correct areas of pilot pollution. Thougan exhaustive study, they will provide the most commonly encountered pilot pollution scen

1. It does not matter if a pilot is above or below T-DROP to be counted as a potential pilot pollution candidateIt only needs to be above the finger locking threshold and within 6 dB of the best serving pilot.


12


Thisme thatting to

andpilot

dinggs anddesignlem:

12.5.1 Pilot Pollution Example 1

Consider a system design that is laid out with fairly even cell spacing and placement.configuration does not implicitly lead to pilot pollution. If a cell site (one or two rings away frothe closest cluster of serving cells) is transmitting a very strong signal, it may have coveragfar over reaches its intended coverage area. A strong signal from a cell site may be contribupilot pollution in many areas. (See Figure 12-10: "Pilot Pollution Example 1".)

Using the Pilot Pollution image with the Data Query feature (loaded with the Nth Best Ec/IoNth Best Ec/Io Server images), the user can easily identify which cell site is contributing thepollution for a given area.

Figure 12-10: Pilot Pollution Example 1

The approach to removing the pilot pollution is to reduce the signal strength of the offensector. First, verify that the associated cell site input parameters, such as the power settinantenna parameters (bearings, downtilts, types, gains, etc.) are all set according toexpectations. Then, one or a combination of the following can be done to correct the prob

Serving Cells

1st Outer Ring

2nd Outer RingSector in Outer RingPropagating Too Far

An Area ofPilot Pollution


12


erage

of thenot betrengthtion

areas

ase, a" part

in asites

ts ass willure toing

ennamore

• Reduce Pilot, Page, Sync, TCH_Max and TCH_Min settings

• Downtilt the antenna

• Reorient the antenna to a different bearing

• Replace the antenna with a lower gain model2

• Reduce the height of the antenna

• Move or eliminate the cell/sector

Note: Care must be taken when implementing any of these actions to ensure that covholes are not created in areas serviced by the offending cell.

If these actions do not completely relieve the pilot pollution, then increasing the dominancebest serving cell sites may be pursued by increasing its power. Increasing power shouldtaken as a first corrective step (assuming there are no coverage holes due to poor signal sfrom these cells) because it will add to the system rise and may result in new pilot polluproblems for its neighboring cells.

Note: Care must be taken when increasing power to ensure that no new pilot pollutionhave been introduced into the system.

12.5.2 Pilot Pollution Example 2

Next, consider a system that is designed for a city with a reserved open space (in this cnational park) where no cell sites can be placed (see Figure 12-11: "Pilot Pollution Example 2A). Many factors in this example contribute to creating a pilot pollution problem:

• The reserved space can not host any cell sites to provide dominant pilots.

• The traffic load and propagation limits in the surrounding urban environment resultreduced cell range. This results in multiple cell sites surrounding the open space (7in this example).

• The clutter present in the reserved space (park) has low relative clutter heighcompared to the surrounding urban/dense urban clutter. The surrounding cell sitebe transmitting at elevated power levels and maximum antenna gain as a measprovide in-building coverage to the surrounding city. This results in all the surroundcells providing strong signals into the reserved space.

• In this example, the park serves as a dividing line between two different cell site antazimuth orientation patterns (not always the case). This results in cell sites havingsector boundaries which cross the park than would be optimal.

2. Be careful that lower gain does not equate to a wider horizontal beamwidth.


12


tionilotshesent

c/Iowhich

m is. A

Any or all of these factors can be present in such situations. In Figure 12-11: "Pilot PolluExample 2", part B shows the area where the pilot pollution would occur. The number of pwhich are within 6 dB of the best serving pilot for any location will vary widely throughout tproblem area. The arrows drawn in part C of Figure 12-11: "Pilot Pollution Example 2" reprepilots which are within the 6 dB threshold for three discreet locations.

When using the Pilot Pollution image with the Data Query feature (loaded with the Nth Best Eand Nth Best Ec/Io Server images), the user can identify which sectors will be dominant andsectors are more readily reduced or eliminated at a location.

Figure 12-11: Pilot Pollution Example 2

It would be impossible to completely eliminate all offending pilots. The solution to this probleto control which pilots are “dominant” in the area and limit that number of pilots to threecombination of the following steps can be taken to accomplish this:

An Area of

NationalPark

Part A

Part B

Part C

Pilot Pollution


12


rved

their

e that

theire thethe

ctorsent

es ofns aretion

utiongn isbe able.

w pilot

1. Reduce Pilot, Page, Sync, TCH_Max and TCH_Min settings.2. Downtilt many of the antennas, especially those which are furthest from the rese

space.3. Adjust the sector antenna to a different bearing.4. Replace antennas with very narrow horizontal beam width antennas (to control

coverage).5. Cell sites which have one sector that is only serving the problem area may requir

sector not be implemented. The cell site would then become a two sector site.6. An underlay/overlay approach may be useful where half of the cell sites adjust

antenna downtilt to keep their coverage close to the cell site base (underlaid) whilremaining cell sites have lesser downtilts to provide coverage in the middle ofproblem area.

7. Cell site orientation should be selected such that a minimum number of seilluminate the problem area (CDMA does not mandate an on-grid cell site placemwith all sectors aligned with all other cell site sectors in the system).

When designing a new system, the user will learn to predict which areas will have these typpilot pollution issues even before any cell placements are tried and before any simulation rumade. By employing the above solutions (especially item 7 above), controlling pilot pollubecomes much easier.

It should be noted that reorientation of the surrounding cell sites may cause new pilot pollareas one ring of cells further out. This effect can “ripple” throughout a design. If the desistarted, centered around the expected problem area, then all additional cell placements willto utilize the best orientation when first placed and not require extensive reorientation later

Note: Care must be taken when implementing any of these actions to ensure that no nepollution areas or coverage holes have been introduced into the system.


NetPlan CDMA Composite& Statistical Images

(Coverage vs. Path Loss)

Chapter

13
Table of Contents
3 - 3

- 43 - 63 - 93 - 18

- 193 - 213 - 21 - 22

3 - 24

- 29 - 29 - 30

31 38

13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

13.2 CDMA Composite Images & Coverage Plots . . . . . . . . . . . . . . . . . . . . 13 13.2.1 CDMA Composite Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Using the CDMA Composite Images Feature. . . . . . . . . . . . . . . 113.2.3 Simulator Coverage vs. Path Loss Coverage. . . . . . . . . . . . . . . . 1

13.3 CDMA Statistical Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.3.1 Uses For Average Statistical Images . . . . . . . . . . . . . . . . . . . . . . 113.3.2 Uses For Standard Deviation Statistical Images . . . . . . . . . . . . . 113.3.3 Using the CDMA Statistical Images Feature . . . . . . . . . . . . . . . 13

13.4 Composite Ec/Io and Subscriber Unit Transmit Power . . . . . . . . . . . . 13 - 213.4.1 Using the CDMA Composite Images Feature. . . . . . . . . . . . . . . 13

13.5 Useful Shell Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313.5.1 Pollution-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1313.5.2 Ec/Io-Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

13.6 Verifying Inter-Carrier Transition Zone Coverage . . . . . . . . . . . . . . . 13 - 3113.6.1 Verifying MAHHO Transition Zone Coverage . . . . . . . . . . . . . . 13 -13.6.2 Verifying DAHHO Transition Zone Coverage . . . . . . . . . . . . . . 13 -


13

Chapter 13: NetPlan CDMA Composite & Statistical Images (Coverage vs. Path Loss)

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


13


es thatn thatvidualcreateoducee andime-

es howmpareosite

verageulator

h loss)rage

lyses. The

of the

etimeshe Bestg drive

es for

rage isow toBestsectors

13.1 Overview

Chapter 11, NetPlan Simulator Images Output and Analysis, discussed all of the image typare available with the IS-95 and IS-2000 1X non time-sliced simulators. As was discussed ichapter, only one image type and only an individual drop can be viewed at a time. These indiimages are not sufficient to define system coverage. This chapter will address the ability toone composite image from several image types and drops, and will address the ability to pra statistical image of the results for all of the drops for a specific image type. The compositstatistical images apply to IS-95 and IS-2000 1X non time-sliced simulation. IS-2000 1X tsliced simulation does not produce images.

The first section of this chapter defines and discusses the simulator coverage plot. It discussto generate a coverage plot using the CDMA Composite Image feature, and then how to cothe simulator coverage plot to a coverage plot based only on path loss. The CDMA CompImages feature provides the ability to post-process the simulation images to produce the coplot (a composite image of several image types and drops). The comparison of these simcoverage plots versus the preliminary coverage plots (based only on maximum allowable patproduced earlier (refer to Chapter 4) will highlight areas where CDMA effects impact the coveprovided in a system.

The second section of this chapter will cover the CDMA Statistical Images feature. Most anaof simulator images are directed toward interpreting the “average” performance of the systemCDMA Statistical Image feature provides the ability to post-process numerous image dropssame image type to produce an image which is the “average” of a Monte Carlo run.

The third section of this chapter discusses the creation of a composite image that is somrequired to support system acceptance test activities. One such image is the composite of tEc/Io and the Reverse Required Power images. This composite image is useful for selectinroutes for collecting data for the system acceptance tests.

The fourth section of this chapter describes two UNIX shell scripts used to manipulate imaguse in preceding sections.

The fifth section of this chapter discusses the methodology used to ensure that proper covebeing provided by the cells/sectors in a inter-carrier handoff transition zone. It discusses huse the Data Query feature in conjunction with either the Pilots Above T-DROP image or theEc/Io Server/Sector image to make sure there are no coverage gaps associated with thosethat are responsible for invoking the handoff process between carriers.


13


le theges:

ns inr.

n notwardat ahold.ingever,ardyet

have

he& 2)0.5

vinge 12 is

re isctorin is

CHh binnotgood

rvingas a

ardsite

13.2 CDMA Composite Images & Coverage Plots

A location is considered covered if both forward and reverse links can be established whidesired FER targets are met. To verify this condition, collectively examine the following ima

• Forward TCH Threshold - This image represents the forward link coverage. The bithis image will contain a TCH max exceeded, TCH max not exceeded, or no serve

The Forward Required Power image can not be used directly in this process as it cabe determined from the image whether a bin location on the plot has a good forlink. The Forward Required Power image shows the forward power requiredparticular bin from the best serving sector of that bin to meet the forward FER thresIf the forward required power does not exceed the “TCH Max” for the best servsector, then that bin would be considered to have good forward link coverage. HowTCH Max can vary from sector to sector. A region which shows a required forwpower which is less than the highest TCH Max for the immediate surrounding cellshigher than the least TCH Max for the immediate surrounding cells may or may notcoverage.

An example of this would be as follows (see Figure 13-1: "TCH Max Example"). TForward Required Power image has a bin located between two cell sites (sites 1that contains a forward power value of 1 Watt. The assigned TCH Max for site 1 isWatts while the assigned TCH Max for site 2 is 1.5 Watts. If site 1 is the best sersector for the bin, there will be insufficient coverage on the forward link since sitdoes not have the required power (1Watt) to meet the target FER. However, if sitethe best serving sector for the bin, there will be coverage for the forward link. Theno way to discern from this image which of the two cell sites is the best serving sefor this bin location. Because of this, there is no way to determine whether the bsufficiently covered.

The Forward TCH Threshold image resolves this ambiguity. The Forward TThreshold image places a TCH Max not exceeded or TCH Max exceeded in eaclocation for each drop of the Forward Required Power image. The TCH Maxexceeded represents the condition where the best serving cell can establish aforward link and TCH Max exceeded represents the condition where the best secell can not establish a good forward link. This image can be used directlyrepresentation of forward link coverage or it can be used in place of the ForwRequired Power image when investigating overall coverage via the CDMA CompoImages feature.


13


bins intargett areas

tionse the

robe)scriberrminequiredn isan the

red

age

Figure 13-1: TCH Max Example

• Reverse Required Power - This image represents the reverse link coverage. Thethis image show the power required on the reverse link to meet the image probeFER. Powers greater than that which are achievable by the equipment represenwhere the equipment does not have enough power to meet the target FER.

The Reverse Required Power image can be used directly in determining bin locawith good reverse links. Determining the coverage of the reverse link does not havproblem associated with the Forward Required Power image.

The Reverse Required Power image is the result of one RF emitter (the image pand as such, depicts the performance of that one class of subscriber (speed, subunit antenna performance, multi-path ray model). This image can be used to detereverse coverage for that one class of subscriber by comparing the reverse repower per bin to the maximum transmit power for that class of subscriber. A biconsidered covered in the reverse direction if the reverse required power is less thmaximum subscriber unit transmit power.

• Forward Achieved FER - The bins in this image show the forward link FER measuby the image probe while subjected to the system load in a simulation drop.

Bins with FER values greater than the outage FER identify locations where the improbe could not maintain a viable connection to the system.

Site 1 Site 2Bin Value = 1W

FWD Required Power image

TCH Max = 0.5 W TCH Max = 1.5 W


13


FER.

age

are

aveof a

on theically

. Toen into

ure to

e plotat arage.

Plan1” forard or

wer

• Reverse Achieved FER - The bins in this image show the image probe reverse linkmeasured by the cell sites while subjected to the system load for a simulation drop

Bins with FER values greater than the outage FER identify locations where the improbe could not maintain a viable connection to the system.

• Pilot Pollution - The bins in this image show the number of pilot signals whichwithin X dB (usually 6 dB) of the strongest pilot.

Areas within a system which have pilot pollution can not be considered to hacceptable performance. The Pilot Pollution image is only created for the first dropMonte Carlo run.

Each drop of the forward and reverse images shows a coverage status which is contingentlocation and status of the traffic on the system for that drop. A single drop may reflect a statistanomalous traffic distribution and would incorrectly depict the mean coverage of the systembetter represent system coverage, all the drops of the forward and reverse images are takaccount. This is done through the use of theCDMA Composite Images feature.

13.2.1 CDMA Composite Images

The simulator coverage plots are created by using the NetPlan Composite Image featcombine the following simulator images:

• Forward TCH Threshold

• Reverse Required Power

• Forward Achieved FER

• Reverse Achieved FER

• Pilot Pollution

The image results for all the drops in a simulation run are required when producing a coverag(a minimum of 100 drops is recommended). If all the forward and reverse links are goodparticular bin for a particular drop, then the resulting location is considered to have good coveThis “good” coverage can be negated if pilot pollution is present at the location.

When generating CDMA Composite Images (Figure 13-2: "CDMA Composite Images"), Netcreates an internal intermediate image for each drop, inside of which a bin is marked with a “good coverage and “0” for bad coverage. The user defines the thresholds where a forwreverse value is considered “good”.

• For the Reverse Required Power link, “good” is usually set to the maximum poavailable from the subscriber unit (less than or equal to 23 dBm).

• For the Forward TCH Threshold link, “good” is defined to be “Max Not Exceeded”.


13


d tooice

the

drop.

plot isropsto theas a

t thetics).s of

• For the Forward Achieved FER and Reverse Achieved FER links, “good” is definebe less than or equal to the image probe “Outage” FER target (usually 3% for vsubscribers).

• For the Pilot Pollution state, no more than 2 additional pilots may be within 6 dB ofbest serving pilot.

If any of these conditions are not met, then a “0” is assigned to the intermediate image for that

Once all of the intermediate images are created for each drop, the simulator coveragegenerated. CDMA Composite Images adds up all the 1’s and 0’s for a bin location for all the dand calculates a percentage value for that location. This percentage value is equivalentpercentage of drops that contain a value of “1” for that location. The output plot is formattedNetPlan image containing coverage probability percentages for each bin location.

Note: Recall from Section 11.1.1 that the images generated for a simulation run reflecperformance for only one specific user type (defined by the image probe characterisTherefore, the composite images will only reflect the performance for the classubscriber portrayed by the image probe.


13


stemttingare

ciated

hiever-binhanability

Figure 13-2: CDMA Composite Images

A “Reliability File” can also be generated which correlates the area reliability for the entire syto a per-bin coverage probability cutoff threshold. This cutoff point can be used when seinterval colors in NetPlan. A plot which displays all the bins whose per-bin probability valuesgreater than or equal to the cutoff threshold will depict the system coverage with the assoarea reliability from the reliability file.

Experience has shown the per-bin probability cutoff threshold can be below 50% and still aca 97% area reliability. These same images result in an area reliability of 97% to 99% if a peprobability cutoff threshold of 90% is used. A per-bin probability cutoff threshold of greater tor equal to 90% is recommended, as a lower value has a negligible impact on the area relipercentage and avoids the inclusion of bins with extremely low coverage probability.

Rev Pwr

Rev FER

Fwd FER

Fwd TCH

Pollution

Rev Pwr

Rev FER

Fwd FER

Fwd TCH

Pollution

Drop #1

6159

9390

95100

6847

6659

8576

5747

8793

11

1

11 1

100

00

0 00 0

0

Coverage Plot

Intermediate image

Drop #100


13


wn in

ed forMA

13.2.2 Using the CDMA Composite Images Feature

The CDMA Composite Images feature is accessed through the pull down menus shoFigure 13-3: "CDMA Composite Images Window" below:

Figure 13-3: CDMA Composite Images Window

Once the CDMA Composite Images window is open, the images and thresholds to be uscreating the composite image are defined. Follow the notes provided for Figure 13-3: "CDComposite Images Window" to complete this step.

2

4

1

3

5


13


stem

e toosite

thetedmage.woe.

theit is

g the

Thesiblecess

in the

mage.

NOTES:

Note: 1. The “Analysis” field and ellipsis are used to select the proper analysis for the syunder study.

Note: 2. The “Output Image” field and ellipsis are used to specify the directory and filenamgive the resulting composite image file. It may be convenient to keep the compimage in the same directory area as the analysis (path:Analysis_Name/CDMA/filename).

Note: 3. The “Reliability File” button, field and ellipsis are used to select the creation ofreliability file, and specify the directory and filename to give the file. It is suggesthat this file be created and placed in the same sub-directory as the composite iThis file aids in selecting the cutoff point (per-bin% value) to set when viewing a tcolor composite image depicting a desired percent area reliability of RF coverag

Note: 4. The two “Drops” fields are used to select which consecutive drops to use fromsimulation run for the creation of the composite image. For RF coverage,recommended that the number of drops be greater than or equal to 100.(note - thisscreen capture only shows 3 drops)

Note: 5. The “Image Types” ellipsis is used to select the input images to use when creatincomposite image.

Note that the Pilot Pollution image can not be chosen directly at this point.following section (Section 13.2.2.1) describes the images that are directly accesand then explains how to access the Pilot Pollution image via an additional prostep.

13.2.2.1 Pilot Pollution Image Work-Around

The NetPlan Composite Images function allows the following simulator images to be usedcomposite image creation:

1. Forward Achieved FER2. Forward F Factor3. Forward Required Power4. Forward TCH Threshold5. HSPD Supp Chnl6. Mobile Received Power7. Pilots Above T-Drop8. Reverse Achieved FER9. Reverse Required Power

The Pilot Pollution image needs to be used in the creation of the composite coverage i


13


Pilotd forarlo

so that. Sinceimageutionas the

ning

surelows:

Pwr

ipt”

s nott can

However, it can not be selected from the Composite Images window. Additionally, for thePollution image to be included in the composite image, a Pilot Pollution image will be needeeach drop. In reality, the Pilot Pollution image is only created for the first drop of a Monte Crun.

The work-around process to address these issues is to rename the Pilot Pollution image fileit can appear as one of the nine image types that the Composite Image feature will acceptthe Mobile Received Power image is not used to create coverage images, the Pilot Pollutionfile can be renamed as multiple Mobile Received Power images. Also, since the Pilot Pollimage is only generated for the first drop, the image needs to be duplicated as many timesnumber of drops in the Monte Carlo run.

This work-around process requires some UNIX file manipulation as well as creating and runa short shell script. The steps are as follows:

1. Move (rename) the “real” Mobile Received Power directory with its contents to enthe Mobile Received Power images are not lost in the process. This is done as fol

Change directory <cd> to the following: <~~/Analysis-name/CDMA_DROP>. Fromthis directory, rename the MobRecPwr directory. Then create a new MobRecdirectory and change directory <cd> into the new “fake” MobRecPwr directory:

2. From within the new MobRecPwr directory, execute the shell script “Pollution-Scrthat is given in Section 13.5.1: "Pollution-Script".

3. The script will create links from the <~~/Analysis-name/CDMA/Pollution > image andcreate 100 relative file names in the new MobRecPwr directory. This process doeuse additional file storage space and does not repetitively copy the files. The scrip

$mv MobRecPwr Real-MobRecPwr

$mkdir MobRecPwr

$cd MobRecPwr

$sh Pollution-Script


13


s areames

ction

atedchosen

n theageshoseagearget

e

e

t

be used for any number of drops less than or equal to 100. If more than 100 dropcreated, the script should be modified to accept the higher drop count. The script nthe links:

MobRecPwr_1MobRecPwr_2MobRecPwr_3 • • •MobRecPwr_98MobRecPwr_99MobRecPwr_100

4. These new “fake” MobRecPwr files can now be used by the Composite Images funto incorporate the Pilot Pollution image into the coverage image.

13.2.2.2 Creating the Coverage Image

The following four figures illustrate the selection of five input images and their associthresholds to use when creating an RF coverage composite image. An explanation of eachthreshold is given.


Note: The Reverse Required Power image threshold (24 dBm) is set 1 dB higher thamaximum subscriber unit transmit power of 200 mW (23 dBm) because NetPlan imdo not support floating point data. Setting the threshold at 23 dBm would exclude tbins which have the value of 23 dBm. That would negatively impact the overall imas the subscriber unit is allowed to stay at the maximum transmit power once the tFER threshold is reached, until the outage FER threshold is reached.

The Reverse Required Power imagdefines which bins are able tocomplete a connection on the reverslink by setting its threshold to be lessthan the maximum subscriber unitransmit power. In this example, thesubscriber units have a 200 mWmaximum transmit power.


13


l

s

Figure 13-5: Forward TCH Threshold

Figure 13-6: Forward and Reverse Achieved FER

Figure 13-7: Pilot Pollution (Mobile Received Power)

The Forward TCH Threshold imagedefines which bins are able tocomplete a connection on the forwardlink by selecting the Maximum TCHThreshold Limits button for “TCHmax not exceeded”. This will selectthose bins where sufficient power isavailable from the best serving celsite to establish a good forward link.

The Forward and Reverse AchievedFER images have bins which containFER values achieved by the imageprobe for both links. Selecting a passcriterion of less than the outage FER(typically 3% for voice subscribers)will allow those bins where theachieved FER level is sufficient forboth forward and reverse links tomaintain a viable connection.

The Pilot Pollution (renamed as theMobile Received Power) imagedefines the number of pilots whichare within the prescribed dB level ofthe strongest pilot (usually 6 dB).Unacceptable call degradation occurwhen more than two additional pilotsare within this strength range of thebest pilot.


13


ontainshoutreas

tiren the

fromtheclick

Using these input selections generates an output coverage image. Each bin in this image cthe probability of the bin meeting both the forward and the reverse link thresholds witexperiencing pilot pollution interference. In this particular case, the bin probability indicates awhere the following five conditions are met:

1. The forward power does not exceed TCH Max.2. The reverse power is less than 24 dBm.3. The FER achieved on the forward link is less than the outage FER.4. The FER achieved on the reverse link is less than the outage FER.5. No more than two additional pilots are within 6 dB of the best serving pilot.

The resulting image is placed in the directory/file specified (path:Analysis_Name/CDMA/filename). The reliability file which contains data to correlate the area reliability for the ensystem to a per-bin coverage probability cutoff threshold (histogram information) is placed idirectory/file specified (path:Analysis_Name/CDMA/filename). Refer to notes 2 and 3 ofFigure 13-3.

13.2.2.3 Displaying the Coverage Image

The coverage image is displayed by first selecting Images>Display. Select the File ellipsisfrom within the Display window. From the File window, navigate to the directory/file whereoutput file was placed (refer to note 2 of Figure 13-3). Select the image to be displayed andOK to continue. See Figure 13-8.


13


nge ofutofftervals

Figure 13-8: Display Coverage Image

Figure 13-9 shows an example of a coverage image. The legend for this figure shows a ravalues from 0 to 100%. As mentioned earlier, it is recommended that the per-bin probability cthreshold be greater than 90%. Therefore, only the colors (areas) associated with the two inrepresenting data greater than or equal to 90% are considered to have coverage.


13


cificated forr more.

Figure 13-9: Composite Coverage Image

An example of a reliability file that was produced can be seen in Figure 13-10. For this speexample, there are only eleven percentile groupings shown because the images were generonly ten drops. As noted before, the recommended number of drops/images should be 100 oThe additional images would provide for more percentile groupings.


13


100%iteriamingce ofility offor thislessbility

Figure 13-10: Reliability File Example

From this information, one can see that 128,505 bins met the specified coverage criteria inof the drops/images (for a reliability factor of 100%), 180 bins met the specified coverage crin 90% of the drops/images (for a reliability factor of 99.99%) and so on. In this example, assua desired coverage reliability factor of 97%, one could include bins that have only 10% chanmeeting the coverage criteria. However, it is recommended that a per-bin coverage probabat least 90% be used when evaluating the composite coverage image (instead of the 10%case) to avoid including bins with extremely low coverage probability. Excluding bins withthan a 90% chance of meeting the coverage criteria will have a negligible impact on the reliafactor percentage.

RELIABILITY FACTOR DATA FOR ANDED-IMAGE OUTPUT FILEAnalysis_Name /CDMA/Comp-cov

This data indicates, for each percentile group, the numberof image elements that fell within that percentile groupand the reliability factor calculated for the imageelements of that percentile group in combination with theimage elements of all HIGHER percentile groups.

Percentile: Bin Count: Reliability Factor:

100.00 128505 100.00

90.00 180 99.99

80.00 196 99.96

70.00 122 99.93

60.00 109 99.89

50.00 103 99.85

40.00 59 99.83

30.00 49 99.80

20.00 78 99.75

10.00 111 99.68

0.00 81492 61.18


13


studyTheimum

e trueiformtors in

scalepparent

nted

nted

rencehichelop

rencenergyhavecellstheruce

th loss.nly onn of

13.2.3 Simulator Coverage vs. Path Loss Coverage

Comparing the coverage achieved with the simulator to that produced by the path loss onlywill serve to highlight the areas where “CDMA” effects impact the coverage environment.CDMA effects may result in increased or reduced coverage from predictions based on maxallowable path loss only.

It should be kept in mind that the path loss only model makes assumptions which may not bfor the simulator run. Most notably, the path loss only model assumes a fixed noise rise for untraffic loading on all the cells within the system where reality will not follow this. The simulashould have been run with the best estimate of traffic distribution which will cause variationthe results between the simulator coverage and maximum allowable path loss coverage.

The most convenient method for comparing the two plots is to produce them with the sameon transparent medium and overlay one upon another. Several scenarios may become awhen comparing the two plots:

• Increased areas of coverage from the simulator vs. path loss coverage.

• Reduced areas of coverage from the simulator vs. path loss coverage.

• Areas with the same coverage from the simulator vs. path loss coverage.

• Areas with ISI related coverage holes from the simulator which can not be represein the path loss coverage.

• Areas with pilot pollution related issues from the simulator which can not be represein the path loss coverage.

13.2.3.1 Increased Coverage

CDMA effects, as depicted by the simulator, may extend coverage in areas where interfefrom neighboring cells is reduced or isolated. This is usually the case for lightly loaded cells woften comprise the outer ring of sites for a system. Their coverage will “breath” out and envmore surface area than a model based only on path loss would predict.

13.2.3.2 Reduced Coverage

CDMA effects, as depicted by the simulator, may shrink coverage in areas where interfelevels are high. This interference can be caused by high traffic levels or from the presence of etransmitted from surrounding cells. This can be the case for cells within the system whichunusual propagation conditions that provide low path loss to other neighboring high trafficwithin the system. Physical topology may play a role in permitting interfering energy from ocells to negatively contribute to the interference levels at a given cell. This condition will redcoverage at that cell as compared to the coverage predicted by a model based only on paThe cause of this differentiation between the simulator coverage and the coverage based omaximum allowable path loss may be attributed to some combination of insufficient isolatioRF signal from other cell sites and uneven traffic distributions.


13


t to RFan

lationesentresultssedthisuality

oodis canon-

that alldesign

uringwing

hinnner.s. Asthents an

13.2.3.3 ISI Effects Upon Coverage

Inter-System Interference can only serve to reduce coverage in areas immediately adjacensites. The simulator currently models the degradation of the forward link by introducingincrease in the subscriber unit’s noise level resulting from internally generated intermoduproducts (IM) in the subscriber unit’s receiver. Receiver IM occurs when strong signals are prwhich are beyond the linear operating range of the receiver circuitry. Holes in coverage (as aof ISI) will likely appear as circular “dead” spots centered on the offending RF site. ISI is discuin greater detail in Appendix 7, “Modeling Inter-System Interference”. It is important to takeeffect into account when designing the CDMA system to ensure that proper coverage and qof service is offered where desired.

13.2.3.4 Pilot Pollution

In areas of pilot pollution, subscriber units may experience difficulties maintaining a gconnection to the system as no one pilot can dominate over the interference from others. Thbe verified by using the Pilot Pollution image to check for localized conditions with multiple ndominant pilots (see Chapter 12 “Treating Pilot Pollution”).

13.2.3.5 Coverage Acceptance

Finally, the simulator coverage results should be presented to the system operator to ensuresystem coverage expectations are being met. This may be conducted during one of thereview meetings.

13.3 CDMA Statistical Images

Examining an individual simulation image from one drop among the many drops produced da Monte Carlo simulation run may be misleading. Each image/drop is influenced by the follosubscriber characteristics which may change for all subscriber units from drop to drop:

• Subscriber placement

• Class of subscriber

• Subscriber speed

• Delay spread ray model assigned to the subscriber

One impact of this reality is that all simulation images will be different from all the others wita Monte Carlo run. The variation from image/drop to image/drop behaves in a statistical maThis means that most images/drops will closely resemble the majority of other images/dropwith statistical distributions, a few images will exhibit greater divergence from the “norm” ofimages. Unfortunately, it is not known which image, among the many, more closely represeaverage system performance image and not a divergent image.


13


alMonte. Thereating

ess, theimageslues for

n the

The CDMA Statistical Images post-processing feature (Figure 13-11: "CDMA StatisticImages") is able to produce two output images. One is the “average” of the image planes in aCarlo run. The second is the “standard deviation” between the planes in a Monte Carlo runselected image is processed by averaging the value in each bin through all the images and ca one plane output image which contains these average values in each bin. During this procfeature also calculates the standard deviation between the values in each bin through all theand creates a second, single plane output image which contains these standard deviation vaeach bin.

Figure 13-11: CDMA Statistical Images

The NetPlan Statistical Images function allows the following simulator images to be used istatistical image creation:

1. Forward Achieved FER 5. Mobile Received Power2. Forward F Factor 6. Reverse Achieved FER3. Forward Required Power 7. Reverse Required Power4. HSPD Supp Chnl

Drop-100

Drop-1

Drop-2

Drop-3

Drop-98

Drop-99

Input Image

Statistical Images

Average

Std. Dev.


13


r thehow an theMonteizeable

manceture ofit of thephic

ers ofyet isber ofmetermalies

tionsplayt intoed by

e binbin

nitudeagesility tocell

13.3.1 Uses For Average Statistical Images

When designing a CDMA system, it is usually desirable to gain a performance picture foaverage status of the system under a particular load. Sometimes it is interesting to evaluatesystem will react to anomalous subscriber conditions, but most design work is conducted oaverage system conditions/performance. As stated in Section 13.3, each image/drop of aCarlo run does not represent the average performance of the system and may exhibit a sdivergence from the “norm” of the system performance.

The NetPlan Average Statistical Image feature is used to obtain a view of the average perforfor those images accessible to the feature. It is used to gain a “smoothed” performance picthe system and make better decisions on system parameter adjustments. One useful traaverage image is the ability to observe the “roll-off” of the system performance in geogralocations where performance is degrading. This is less obvious with a single image/drop.

It is customary during the early stages of performing a system design to run smaller numbsimulation drops. This makes the process faster by reducing the run time for each simulationacceptable as only gross parameter adjustments are being made. With only a small numimages/drops to select from, a random anomalous image can heavily impact the paraadjustment process. Using the Average Statistical Image feature would smooth out the anoand make the adjustment more reliable.

13.3.2 Uses For Standard Deviation Statistical Images

Insight into the performance of a CDMA system can be gained by observing geographic locawhich exhibit high susceptibility to changes in the traffic load. The simulation process may disthese locations as having sufficient coverage to meet the design goal, yet offer little insighwhich locations will most likely experience performance problems once the system is stresshigh loads or unusual traffic distributions and speeds.

As stated in Section 13.3, each image/drop of a Monte Carlo simulation run is unique. Imaglocations which have high susceptibility to load changes will show sizeable differences invalues from drop to drop.

The NetPlan Standard Deviation Statistical Image feature is used to obtain a view of the magof bin value differences between the images/drops of a Monte Carlo run, for those imaccessible to the feature. It is used to gain a performance picture of the system susceptibchanges in the traffic load. This insight will allow for better decisions on system design anddeployment.


13


n in

ify thetical

13.3.3 Using the CDMA Statistical Images Feature

The CDMA Statistical Images feature is accessed through the pull down menus showFigure 13-12: "CDMA Statistical Images Window" below:

Figure 13-12: CDMA Statistical Images Window

Once the CDMA Statistical Images window is open, select the input image to use and specstatistical images to be created. Follow the notes provided for Figure 13-12: "CDMA StatisImages Window" to complete this step.

2

4

1

3

5


13


stem

g the

lege.

amethis

amekeep

theel bendard

s wille input

sist ine thatctiond the

eswertion

scribedrage

NOTES:


Note: 2. The “Image Type” ellipsis is used to select the input image to use when creatinstatistical images.

Note: 3. The “DropsX ThroughY out of Z” fields are used to specify what range of availabdrops will be used when creating the statistical images for the selected input ima

Note: 4. The “Average Image” field and ellipsis are used to specify the directory and filento give the resulting average statistical image file. It may be convenient to keepimage in the same directory area as the analysis (path:Analysis_Name/CDMA/filename).

Note: 5. The “Std Dev Image” field and ellipsis are used to specify the directory and filento give the resulting standard deviation statistical image. It may be convenient tothis image in the same directory area as the analysis (path:Analysis_Name/CDMA/filename).

Clicking on the “Create” button will start the process. The resulting images are placed indirectory/file specified (path:Analysis_Name/CDMA/filenames). The statistical average imagwill look similar to one of the image/drop input images in that the same type of units wilcontained in the image bins (for example, dBm in the case of the FwdReqPwr image). The stadeviation image will also contain the same units as the input image except the bin valuerepresent the amount of standard deviation experienced between the image planes of thimage type.

13.4 Composite Ec/Io and Subscriber Unit Transmit Power

Drive tests are run to define a perceived coverage performance for CDMA systems. To asdetermining the drive test routes, it is sometimes desirable to produce a simulation imagdefines the boundaries of Ec/Io and subscriber unit transmit power for a drive test. This sediscusses how to create one form of drive test image. A composite image of Best Ec/Io anReverse Required Power will serve this end.

Note: This image doesNOT fully define the coverage of the CDMA RF system design. It donot take into account the effects of traffic load and forward traffic channel poconstraints on the forward channel. It also avoids the negative effects of pilot polluon the system coverage. It is recommended that the coverage image process depreviously in this chapter (see Section 13.2: "CDMA Composite Images & CovePlots") be followed whenever possible.


13


wn in

13.4.1 Using the CDMA Composite Images Feature

The CDMA Composite Images feature is accessed through the pull down menus shoFigure 13-13: "CDMA Composite Images Window" below:

Figure 13-13: CDMA Composite Images Window

2

4

1

3

5


13


e usedosite

stem

e tomage

thee.

the

g the

ctionplains

in the

equirednally,ality,

Once the CDMA Composite Images window is open, define the images and thresholds to bfor creating the composite image. Follow the notes shown on Figure 13-13: "CDMA CompImages Window" to complete this step.

NOTES:


Note: 2. The “Output Image” field and ellipsis are used to specify the directory and filenamgive the resulting composite image. It may be convenient to keep the composite iin the same directory area as the analysis (path:Analysis_Name/CDMA/filename).

Note: 3. The “Reliability File” button (optional), field and ellipsis are used to selectcreation of the reliability file, and specify the directory and filename to give the fil

Note: 4. The two “Drops” fields are used to select which consecutive drops to use fromsimulation run for the creation of the composite image.

Note: 5. The “Image Types” ellipsis is used to select the input images to use when creatincomposite image.

Note: The Best Ec/Io image can not be chosen directly at this point. The following se(Section 13.4.1.1) describes the images that are directly accessible and then exhow to access the Best Ec/Io image via an additional process step.

13.4.1.1 Best Ec/Io Image Work-Around

The NetPlan Composite Images feature allows the following simulator images to be usedcomposite image creation:

1. Forward Achieved FER2. Forward F Factor3. Forward Required Power4. Forward TCH Threshold5. HSPD Supp Chnl6. Mobile Received Power7. Pilots Above T-Drop8. Reverse Achieved FER9. Reverse Required Power

The Best Ec/Io image needs to be used in the creation of the composite Ec/Io and Reverse RPower image. However, it can not be selected from the Composite Images window. Additiofor the Best Ec/Io image to be included, a Best Ec/Io image will be needed for each drop. In rethe Best Ec/Io image is only created for the first drop of a Monte Carlo run.


13


o that itte thatince,ge fileage isber of

ning

surelows:

Pwr

hat

The work-around process to address these issues is to rename the Best Ec/Io image file scan appear as one of the nine image types that the Composite Image feature will accept. (Nothis is the same approach used in Section 13.2.2.1: "Pilot Pollution Image Work-Around".) Sthe Mobile Received Power image is not used to create coverage images, the Best Ec/Io imacan be renamed as multiple Mobile Received Power images. Also, since the Best Ec/Io imonly generated for the first drop, the image needs to be duplicated as many times as the numdrops in the Monte Carlo run.

This work-around process requires some UNIX file manipulation as well as creating and runa short shell script. The steps are as follows:

1. Move (rename) the “real” Mobile Received Power directory with its contents to enthe Mobile Received Power images are not lost in the process. This is done as fol

Change directory <cd> to the following: <~~/Analysis-name/CDMA_DROP>. Fromthis directory, rename the MobRecPwr directory. Then create a new MobRecdirectory and change directory <cd> into the new “fake” MobRecPwr directory:

2. From within the new MobRecPwr directory, execute the shell script “EcIo-Script” tis given in Section 13.5.2: "Ec/Io-Script".

$ mv MobRecPwr Real-MobRecPwr

$ mkdir MobRecPwr

$ cd MobRecPwr

$ sh EcIo-Script


13


cess. The

100. The

ction

g a

n theageshoseagearget

e

e

r

3. The script will create links from the <~~/Analysis-name/CDMA_NTH/EcIo/EcIo_1>image and create 100 relative file names in the new MobRecPwr directory. This prodoes not use additional file storage space and does not repetitively copy the filesscript can be used for any number of drops less than or equal to 100. If more thandrops are created, the script should be modified to accept the higher drop countscript names the links:

MobRecPwr_1MobRecPwr_2MobRecPwr_3 • • •MobRecPwr_98MobRecPwr_99MobRecPwr_100

4. These new “fake” MobRecPwr files can now be used by the Composite Images funto incorporate the Best Ec/Io image into the drive test support image.

13.4.1.2 Creating the Drive Test Support Image

The following two figures illustrate the selection of two input images to use when creatincomposite image to support drive testing:


Note: The Reverse Required Power image threshold (24 dBm) is set 1 dB higher thamaximum subscriber unit transmit power of 200 mW (23 dBm) because NetPlan imdo not support floating point data. Setting the threshold at 23 dBm would exclude tbins which have the value of 23 dBm. That would negatively impact the overall imas the subscriber unit is allowed to stay at the maximum transmit power once the tFER threshold is reached, until the outage FER threshold is reached.

The Reverse Required Power imagdefines which bins are able tocomplete a connection on the reverslink by setting this threshold to beless than the maximum subscribeunit transmit power. In this example,the subscriber units have a 200 mWmaximum transmit power.


13


bin inuired

two

reatere

Figure 13-15: Best Ec/Io(Mobile Received Power)

Using these input selections will create a drive test support image (see Figure 13-13). Eachthis image will contain the probability of the bin meeting both the Ec/Io and the Reverse ReqPower thresholds. In this particular case, the bin probability would indicate areas whereconditions are met:

1. The reverse power is less than 24 dBm.2. The Ec/Io values received by the image probe from the best serving sector are g

than T-ADD (assuming T-ADD is set to -16 dB). (A setting of -17 is used becausNetPlan images do not support floating point values).

The resulting image is placed in the directory/file specified (path:Analysis_Name/CDMA/filename).

The Best Ec/Io (renamed as theMobile Received Power) imagecontains Ec/Io values received by theimage probe from the best servingsector.


13


ions.ges or

agesthe

geps.

13.5 Useful Shell Scripts

The following two subsections list the scripts which were referred to in the previous sectThese scripts are used when generating composite images which use the pilot pollution imathe Ec/Io images.

13.5.1 Pollution-Script

Below is the shell script used to gain access to the Pilot Pollution image with the composite imfeature. Enter these commands into an executable file named “Pollution-Script” and followinstructions1 given in Section 13.2.2.1:

1. If the number of Monte Carlo drops used to create images for the purpose of generating a “coverage” imaexceeds 100 - then the value (100) in the script must be increased to equal the number of simulation dro

#!/bin/ksh

# This shell script will make a virtual link to the one pilot pollution

# file and name it "MobRecPwr_X" 100 times into the directory from which it is

# launched. It is assumed that it will be run from inside the <analysis-name/

# CDMA_DROP/MobRecPwr> directory which had been previously emptied out.

# Once all the virtual links have been made, the new "fake" MobRecPwr images

# can be used by the CDMA Composite Images feature to show the influence of

# pilot pollution.

let "count = 1"

while ((count <= 100));

do

ln -s ../../CDMA/Pollution MobRecPwr_${count}

let "count = count + 1"

done


13


agesthe

etion

13.5.2 Ec/Io-Script

Below is the shell script used to gain access to the Best Ec/Io image with the composite imfeature. Enter these commands into an executable file named “EcIo-Script” and followinstructions2 given in Section 13.4.1.1:

2. If the number of Monte Carlo drops used to create images for the purpose of generating this form of drivtest image exceeds 100 - then the value (100) in the script must be increased to equal the number of simuladrops.

#!/bin/ksh

# This shell script will make a virtual link to the EcIo_1 file and name

# it "MobRecPwr_X" 100 times into the directory from which it is

# launched. It is assumed that it will be run from inside the <analysis-name/

# CDMA_DROP/MobRecPwr> directory which had been previously emptied out.

# Once all the virtual links have been made, the new "fake" MobRecPwr images

# can be used by the CDMA Composite Images feature to show the influence of

# the Best Ec/Io.

let "count = 1"

while ((count <= 100));

do

ln -s ../../CDMA_NTH/EcIo/EcIo_1 MobRecPwr_${count}

let "count = count + 1"

done


13


igner:esethodsrage oferage

arriersstyles

tors

red byRF

an noted tod the

does

HHOthe/Iouery

c/Io

13.6 Verifying Inter-Carrier Transition Zone Coverage

Two methods of invoking an inter-carrier hard handoff are available to the RF system desMobile Assisted Hard Handoff (MAHHO) and Database Assisted Hard Handoff (DAHHO). Thtwo methods can be used exclusively or in combination within a system design. Both merequire that continuous RF coverage be provided along the desired border between the covethe carriers. The need for an inter-carrier handoff transition zone presumes that the covprovided by the cells on at least one carrier is less than the coverage of the underlying c(otherwise no transition is needed). The methods for verifying the RF design for these twoof inter-carrier hard handoff are described in this section.

13.6.1 Verifying MAHHO Transition Zone Coverage

Mobile Assisted Hard Handoff (MAHHO) is implemented by deploying pilot beacons in secwhere the system designer desires a subscriber to handoff to an underlying carrier.

The inter-carrier hard handoff is triggered by the presence of a pilot beacon Ec/Io (as measuthe mobile receiver) that is at least T-COMP (usually 4 dB) greater than any Traffic pilot. Thesystem designer should verify that a subscriber that is active on the non-ubiquitous carrier ctravel out of the coverage area provided by the non-ubiquitous carrier without being directhandoff to the underlying carrier. A continuous “zone” of coverage must be provided arounnew carrier coverage area where MAHHO triggering pilot conditions exist.

NetPlan does not utilize the T-COMP parameter in determining a soft handoff state, butcalculate the Ec/Io values provided by each pilot in the system.

The method used to verify that the RF design provides adequate coverage in the MAtransition zone is to investigate MAHHO locations within the inter-carrier handoff “zone” forproper Ec/Io of MAHHO pilots. This can be done within NetPlan by displaying the “Best EcServer/Sector” image for the pilot beacon carrier (see Figure 13-16) while utilizing the Data Qwindow to display the bin-by-bin values of Nth (1-4) Best Ec/Io and the Nth (1-4) Best EServer images.


13


g the

Figure 13-16: Best Ec/Io Server/Sector for the Pilot Beacon Carrier

Note: The black polygon in Figure 13-16 represents the boundary used when creatinTraffic Map for the non-ubiquitous carrier.


13


mainelectuery.

To launch the Data Query feature, select the “Q” icon along the upper right edge of theNetPlan window (see Figure 13-17: "Launching Data Query"). In this Data Query window, sfrom the menu Configure>Data Query. This will open an image selector window titled Data Q

Figure 13-17: Launching Data Query


13


ure 13-terestc/Io

dowpace

ouse

The second Data Query window is used to select the images to use for data query (see Fig18: "Data Query Menu"). The last two image types in the select window are the images of infor validating MAHHO sector coverage. They are the Nth Best Ec/Io and the Nth Best EServer/Sector images (8 images in this case).

Figure 13-18: Data Query Menu

The Data Query box will now show all the images you have selected in the left half of the win(see Figure 13-19: "Data Query Example"). Adjust the window to minimize the amount of sit occupies while retaining the names and queried data in view.

Move the cursor over the Best Ec/Io Server/Sector image while holding down the center mbutton. The Data Query window will display the following information for the selected bin:

• The Ec/Io values for the 1st, 2nd, 3rd and 4th best serving cell sites.

• The cell names for the 1st, 2nd, 3rd and 4th best serving cell sites.


13


g the

.


NOTES:

1. The black polygon in Figure 13-19 represents the boundary used when creatinTraffic Map for the non-ubiquitous carrier.

2. In this example, the sector orientation is 90˚, 210˚, and 300˚ for sectors 1, 2, and 3


13


tweenhard

queryuery

ite 2hereithout

c/Io touitous

arrier,

arriereaconse thet the3-20.

Upon examination of the example above (Figure 13-19: "Data Query Example"), the area becell sites 01 and 15 can be determined not to have sufficient pilot beacon Ec/Io to trigger ahandoff to the underlying carrier. This condition was determined through the use of the datawindow while placing the cursor on the location in question. The Ec/Io values from the data qwindow are shown in Table 13-1.

The best pilot beacon (Site 15 Sector 2) Ec/Io is only 2 dB better than the best traffic pilot (SSector 3) Ec/Io. This value is less than the 4 dB T-COMP required to trigger a hard handoff. Tis a possibility that a subscriber could leave the coverage area of the non-ubiquitous carrier whanding off to the underlying carrier which would potentially result in a dropped call.

In this same example, the area between cell sites 09 and 15 has insufficient pilot beacon Eprovide best server dominance. A subscriber leaving the coverage area of the non-ubiqcarrier through the area between sites 09 and 15 would not handoff to the underlying cpotentially resulting in a dropped call.

Pilot powers can be adjusted to improve the pilot beacon carrier coverage in the inter-ctransition zone. For example, the RF designer might increase the power of some of the pilot bsectors in the areas that exhibit insufficient pilot beacon Ec/Io while at the same time, decreapower of some of the non-pilot beacons sectors. Following this approach would correcproblems pointed out in Figure 13-19. The resulting corrected coverage is shown in Figure 1

Table 13-1: Example Ec/Io

Cell / Sector Sector Type Ec/Io

Site 15 Sector 2 Pilot Beacon -9

Site 1 Sector 1 Pilot Beacon -10

Site 2 Sector 3 Traffic -11

Site 11 Sector 3 Traffic -12


13


Figure 13-20: Corrected Transition Zone Coverage


13


s toed.

t (astruthdoff:

er canto theitous

tigatendfor

y theer ofay

Nthll berving

13.6.2 Verifying DAHHO Transition Zone Coverage

Database Assisted Hard Handoff [DAHHO] is implemented by assigning the DAHHO statusectors along an inter-carrier border where hard handoffs to an underlying carrier are desir

The inter-carrier hard handoff is triggered when the number of DAHHO pilots in the active semeasured by the subscriber receiver) produces a dominant DAHHO condition. The followingtable (see Table 13-2) gives the combinations which result in triggering a DAHHO hard han

The RF system designer should verify that an active subscriber on the non-ubiquitous carrinot travel out of the non-ubiquitous carrier coverage area without being directed to handoffunderlying carrier. A continuous “zone” of coverage must be provided around the non-ubiqucarrier coverage area where DAHHO triggering pilot conditions exist.

The method used to verify that the RF design provides adequate DAHHO handoffs is to inveslocations within the inter-carrier hard handoff “zone” for the proper combination of DAHHO aTraffic pilots. This can be done within NetPlan by displaying the “Pilots Above T-Drop” imagethe non-ubiquitous carrier (see Figure 13-21) while utilizing the Data Query window to displabin-by-bin values of Nth Best Ec/Io and the Nth Best Ec/Io Server/Sector images. The numb“Nth Best” images included in the Data Query window should match the setting for N-Wcomplex soft handoff in the simulation. Without complex soft handoff, Nth Best Ec/Io and theBest Ec/Io Server/Sector images (1-3) are sufficient. When using NetPlan, a pilot wiconsidered part of the active list if it is above the T-DROP value defined for the strongest sesector.

Table 13-2: DAHHO Truth Table

1ActivePilot

2ActivePilotsDiffer-

entSites

2ActivePilotsSameSite

3ActivePilots

4ActivePilots

5ActivePilots

6ActivePilots

0 DAHHO Sector-Carrier Active Pilots N N N N N N N

1 DAHHO Sector-Carrier Active Pilots Y N Y N N N N

2 DAHHO Sector-Carrier Active Pilots Y Y Y N N N

3 DAHHO Sector-Carrier Active Pilots Y N N N

4 DAHHO Sector-Carrier Active Pilots N N N

5 DAHHO Sector-Carrier Active Pilots N N

6 DAHHO Sector-Carrier Active Pilots N


13


g the

.

sed toed pilotned as

are

ouse

Figure 13-21: Pilots Above T-Drop

NOTES:

1. The black polygon in Figure 13-21 represents the boundary used when creatinTraffic Map for the non-ubiquitous carrier.

2. In this example, the sector orientation is 90˚, 210˚, and 300˚ for sectors 1, 2, and 3

Following the same process as was used in Section 13.6.1, the Data Query window is udisplay the 1st, 2nd and 3rd best serving sites nth Best Ec/Io Server/Sector and the associatlevels (nth Best Ec/Io). The system designer should be cognizant of which sectors are defiDAHHO or Traffic. The designer should also be aware of what T-ADD and T-DROP valuesassociated with each sector.

Move the cursor over the Pilots Above T-DROP image while holding down the center mbutton. The Data Query window will display the following information for the selected bin:

• The Ec/Io values and cell names for the 1st, 2nd and 3rd best serving cell sites.

• The number of pilots above T-DROP.


13


D isf the(site 3ould

sitesnon-

being


In the example shown above (see Figure 13-22: "Data Query Example"), the value of T-AD-16 dB and the value of T-DROP is -18 dB. Examination of this example shows that two othree sectors (site 3 sector 3 and site 11 sector 2) are DAHHO sectors while the third sectorsector 1) is a Traffic carrying sector. By referring to Table 13-2, we see that this location wtrigger a handoff to the underlying carrier.

Moving the mouse around the Pilots Above T-Drop image while gathering data on the cellinvolved gives the system designer the information to verify that an active subscriber on theubiquitous carrier can not travel out of the non-ubiquitous carrier coverage area withoutdirected to handoff to the underlying carrier.


CDMA HandoffCandidates &

PN Offsets

Chapter

14
Table of Contents
4 - 3

- 3 - 3

4 - 9 - 9

- 10

- 10

- 11

14.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

14.2 CDMA Handoff Candidates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.2.1 Automatic Handoff List Generation . . . . . . . . . . . . . . . . . . . . . . 1414.2.2 Manual Handoff List Generation. . . . . . . . . . . . . . . . . . . . . . . . . 114.2.3 Manual Handoff List Editing. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.2.4 Applying a Handoff List to the Simulation . . . . . . . . . . . . . . . . . 14 14.2.5 Reviewing Candidate List Statistics in the

Operational Analysis Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

14.3 PN Offset Capabilities of NetPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14


14

Chapter 14: CDMA Handoff Candidates & PN Offsets

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


14


ghbor)arily,

mayes

listsit ise.

r softlreadyitude

(whichwill

t isesignuld be

thePN-14-

ticallyndoff

may

n theficant

mustlist inber ofd fromd (no

14.1 Overview

Static simulation output data can be processed to assist in the creation of a handoff (neicandidate list. The resultant list will primarily be used in the OMC-R database and, secondmay be used as an input back into the static simulation process to refine the design.

Crafting an optimal handoff candidate list is very important to good system operation andsignificantly reduce field optimization efforts. In CDMA, any strong signal not exploited becominterference. Additionally, in an effort to mitigate the impact of composite handoff candidate(those formed when in 2-way or 3-way handoff) being truncated to only 20 members,recommended that the lists be prioritized prior to implementing them in the system databas

Within the static simulation process, adding a handoff candidate list restricts candidates fohandoff to only those sectors which are neighbors to the best sector. If the system is agenerally optimized, the effect is always (and predictably) negative in its impact, but the magnof the shift tends to be only a 1% to 2% decrease in the percentage of good connectionstracks with the TCH FER outage criteria). Since it is not believed that dramatic differencesexist in the simulation optimization results by introducing a handoff candidate list, irecommended that its introduction be saved for use in the later stages of the CDMA RF dprocess (i.e. when the system design is generally optimized). Neighbor list generation shodone using non time-sliced simulation.

14.2 CDMA Handoff Candidates

The CDMA Handoff Candidate feature is a utility embedded within NetPlan which createshandoff list for the simulator. To access the tool, the user clicks upon the CDMA Handoff/Offset icon (shown above) which opens the CDMA PN Offset/Handoff dialog box (see Figure1). This section describes how this feature is used to generate a handoff list (either automaor manually). It also discusses how the user can manually edit a handoff list and how the halist is applied to the simulation.

Note: For IS-2000 simulations, the automatic generation of a CDMA Handoff Candidate listonly be performed with output files generated using the Non Time-Sliced simulation mode.

14.2.1 Automatic Handoff List Generation

NetPlan has the ability to automatically generate a CDMA Handoff Candidate list based omobile statistics accumulated from a previous run. This run must have a statistically signinumber of drops (100 drops or more are recommended for non time-sliced simulations) andhave been conducted without the use of a handoff list. The condition of not using a handoffthe previous run is necessary so that the auto-generator tool may have the largest numconnections to choose from. Since the handoff list is based on the mobile statistics generatethis previous run, it is essential that this previous run had mobile statistics files generateimages are required for this step).


14


rving

s willandoff

mte”see

The Automatic Generation tool algorithm evaluates the mobile links (i.e. connections to sesectors) in the mobile statistics file. Anysecondarysectors (i.e. serving sectors other than thebestserving sector) are considered handoff candidates to thebest(or primary) serving sector as long asthe overall connection is ‘good’ (i.e. both forward and reverse FER targets are met). Statisticbe accumulated on the occurrences of each neighbor relationship across all mobile drops. Hcandidates can be limited by specifying mobile link, handover and distance criteria.

To access the Automatic Generation tool, first pull down the “Edit” menu to “Handoff List” froinside the CDMA PN Offset/Handoff dialog box. Then pull down the “File” menu to “Generafrom inside the Edit Handoff List dialog box. This will open the Generate dialog box (Figure 14-1).


14


ng ang

Figure 14-1: CDMA Handoff Candidate Generator

The following fields in the Generate dialog box may be modified in the process of creatiCDMA handoff list. See Figure 14-2 for field definitions. For further information regardirecommended settings for neighbor list generation, please see Section 14.2.1.1.


14


dto the

1/2 theich

tionfromist.

ndoffsoft

lected,

e

f

o

Figure 14-2: Generate

TheDistance Criteria works on the principal of allowing only sites which fall into a calculateradius from each subscriber to be considered for the candidate list. This radius is the distancenearest serving site plus the offset value set here. It is recommended that the input value bepilot increment setting for the CDMA system. Typical pilot increments are 2, 3, or 4 whcorrespondingly result in the input values of 1, 1.5 or 2.

Once all the input fields have been completed, clicking the “OK” button will initiate the generaof the handoff candidate list. The list must then be saved by pulling down the “Save As” menuinside the Edit Handoff List dialog box and selecting a file name for the handoff candidate l

14.2.1.1 Recommended Settings for Neighbor List Generation

Fundamentally, this process for generating a neighbor list works by summarizing the soft harelationships discerned within the mobile output data. Every dropped mobile found to be inhandoff is analyzed against the criteria enabled in the Generate dialog box. If no criteria is se

A record of the statistics calculated duringthe handoff list generation should besaved by selecting theOutput Statisticsoption, and naming an output file.

Selecting Bi-directional Handoversensures that all neighbor relationships arcomplementary (i.e. if A is a neighbor toB, then B is a neighbor to A). This optionis normally selected.

Selecting Maximum Number ofHandover Candidates limits the totalnumber of neighbors which can beassigned to one sector.

The Avg. No. of Mobile Links defineswhat the minimum average number omobile links for the sector to beconsidered for the candidate list.

ThePercent of Mobile Links defines theminimum percentage of links that asecondary sector must achieve, relative tthe total links associated with the primarysector, for it to be considered for thecandidate list.


14


istics.callyaranteeoversry (i.e.t as as.

ation

f 8 tostemlowed

andg”

bileltantf the

or the2nd

dialog

tingthe

r unituilt

ayTheentialluteivethe700

then all soft handoff relationships will be represented in the resultant handover list and statAn exception to this rule is that an audit, being performed in the background, will automatidetect any softer neighbors (i.e. other sectors of the same site) that may be missing and gutheir presence in the handover list and statistics. In a similar fashion, the Bi-directional Handbutton activates an audit that will guarantee that all neighbor relationships are complementaif A is a neighbor to B, then B is a neighbor to A). When sectors are added to a neighbor lisresult of audits of this type, they are displayed in the statistics file with zero soft handoff link

The following are some general recommendations with regard to the handoff list generprocess:

• It is recommended that neighbor lists be sized generously large (e.g. an average o11 neighbors) so as to reduce the field optimization efforts associated with initial sydeployment. [Concern about the subscriber unit neighbor scanning rates being ssignificantly by too large a neighbor list does not appear warranted.]

• If the neighbor list is judged too small, atemporaryreduction in the T-ADD/T-DROPthresholds is recommended (under EDIT>Carrier, set the new values for T-ADDTDROP thresholds and then use the “Update All” button). This will permit “seeinmore neighbors.

• If the neighbor list is judged too large, it is recommended to apply the handover, molink or distance criteria. When a criteria is enabled, it can help to shape the resuneighbor relationships into a more appropriate set. Note that with the exception oBi-directional Handovers button, all criteria exist to limit the number of neighbors.

• It is recommended that an output statistics file always be generated. It is essential fproduction of any neighbor list where candidates are prioritized (i.e. 1st choice,choice, etc.).

The following are specific recommendations on the criteria associated with the Generatebox:

• It is recommended that Bi-Directional Handovers be enabled.

• The Maximum Number of Handover Candidates provides the means of limineighbors to a maximum number. Typically, it is set to 20 which corresponds toguaranteed maximum neighbor set size which may be transmitted to a subscribewith the Neighbor List Update Message. The database limit for the dynamically bneighbor list message is 45.

• The Mobile Link Criteria establishes minimum thresholds upon which neighbors mbe rejected. This is one way to remove statistically insignificant contributors. [overall sample size for the sector must be satisfactorily large, before these potneighbors would be discarded.] Both relative (Percent of Mobile Links) and absolimits (Average Number of Mobile Links) may be established. Typically, the relatPercent of Mobile Links criteria dominates. A value of 1% is recommended forPercent of Mobile Links criteria. For example, assuming a sector with a total of


14


e as ar of

reallue ofof 2

itse ortimed andin

PN

, thecan be

to

thethey

n beltantdedce ofAlso,ment

n helphbors?

the

hat is

links to neighbors, a criteria of 1% corresponds to a requirement that a sector servneighbor a minimum of 7 times (700 links x 1%). An absolute Average NumbeMobile Links criteria may also be established. This number is implemented as anumber and the recommended value is 0.02. For 100 drops, the recommended va0.02 corresponds to a requirement that a sector serve as a neighbor a minimumtimes (100 drops x 0.02 links per drop).

• The Distance Criteria will limit neighbors by not including any mobile drop that exhiba time differential greater than the threshold defined. [The time differential is the timdistance difference between one soft handoff link and the soft handoff link for thereference site (i.e. the closest site).] It is recommended that this criteria be enablethat it be set to 1/2 of the PILOT_INC value for the system. Any time differentialsexcess of this value will be identified incorrectly by the BSS which translates pilotphase to pilot PN offset using its knowledge of PILOT_INC.

14.2.1.2 Post-Processing

As an alternative to crafting the neighbor list using the criteria within the Generate dialog boxneighbor list can be generated with restrictions removed and then the resulting statistics filepost-processed. The advantage in following this process consists of the following:

• The post-processing of the “unrestricted” neighbor list allows for additional criteriabe applied that permits for greater flexibility in crafting the neighbor list.

• System statistics for the “unrestricted” neighbor list can provide an overview ofdistribution of the number of neighbors and the percentage of the links for whichaccount.

• By generating the neighbor list with restrictions removed, the potential neighbors careviewed more easily to judge whether or not they should be added into the resuneighbor list. Within NetPlan, any neighbor that doesn’t meet the criteria is exclufrom both the neighbor list and the statistics file. Consequently, there is no evidentheir existence. Through post-processing, all of the potential neighbors are seen.potential neighbors can be classified into groups that may help with the assessprocess.

• Sector statistics can permit assessing neighbor lists more quickly. The statistics caanswer questions such as the following. Does a sector appear to have too few neigIs the sample size too small? How many neighbors were trimmed away due tominimum thresholds?

Scripts or tools can be written to assist with the post-processing of the neighbor list data tgenerated without restrictions.


14


N-1 &on akingiginalnewly

et4-3).

Edittonrs areoredn on

nce the

14.2.2 Manual Handoff List Generation

The CDMA Handoff Candidate List may be manually created while in the CDMA Handoff/POffset mode. This is done by opening the Edit Handoff List dialog box (see Figure 14-Figure 14-3). Within the NetPlan workspace window, clicking with the left mouse button upsector will graphically show all the neighbors associated with that sector (none initially). Clicwith the right mouse button on any other sector will add the sector as a neighbor to the orsector. Neighbors are highlighted with colored arcs. Once the process is completed, save thecreated Handoff List (File>Save As).

The procedure of manually generating a Handoff Candidate List will seldom be used.

14.2.3 Manual Handoff List Editing

A CDMA Handoff Candidate List may be manually edited while in the CDMA Handoff/PN-Offsmode. This is done by opening the Edit Handoff List dialog box (see Figure 14-1 & Figure 1Select a previously generated Handoff Candidate List by choosing File>Open from theHandoff List window. Within the NetPlan workspace window, clicking with the left mouse butupon a sector will graphically show all the neighbors associated with that sector. Neighbohighlighted with colored arcs. Clicking with the right mouse button on a sector without a colarc will add the sector as a neighbor to the original sector. Clicking with the right mouse buttoa sector that has a colored arc will subtract the sector as a neighbor to the original sector. Oprocess is completed, save the edited Handoff List (File>Save or File>Save As).

Figure 14-3: Edit Handoff List


14


ecification(seeoff.g textoff

rom aidateal filesinghborcolorederical

14.2.4 Applying a Handoff List to the Simulation

To apply a handoff list to a simulation, simply enable the use of this function and select the sphandoff list. To enable the use of a handoff list in a simulation, choose Configure>SimulParameters>CDMA...>Radio Access Network>Configuration from the main NetPlan windowSection 6.2.2.2.1). The “Apply Handoff List” check box enables this function. The default isWhen enabled, this function requires that the handoff list be specified in the accompanyinfield. The “Handoff List” ellipsis button opens a dialog box to facilitate selection of the handlist.

14.2.5 Reviewing Candidate List Statistics in the Operational Analysis Mode

The Operational Analysis mode enables the NetPlan user to display statistics collected fvariety of sources. The neighbor statistical data produced through the CDMA Handoff Candfeature is provided in the Operational Analysis mode’s Sector-Pair format. Open the statisticfor viewing by clicking on the Operational Analysis mode button (shown above) and then chooFile>Open. Once open, selecting a source sector will geographically display all of the neigstatistics. These statistics may be displayed as numbers or may be represented visually asarcs. The use of colored arcs, where the palette has been correlated to meaningful numthresholds, permits for easier comprehension of the information.


14


fsetimplegion/limited.

sis.plan.ogffsetpriatethethemenu

ector

e orion of

lined

14.3 PN Offset Capabilities of NetPlan

Through the CDMA PN Offset/Handoff dialog box (see Figure 14-1 & Figure 14-5), the PN ofplan for a system can be displayed. First, create a file that contains the PN offset plan in a sformat with one line for each sector, and each line containing a sector identifier (i.e. system/resite/sector) and its associated PN offset assignment. These fields may be space or tab deAn example file is shown below in Figure 14-4.

Figure 14-4: Example PN Offset File

To display this PN offset plan in NetPlan, this input file must first be imported into the analyFigure 14-5: "Import PN Offset Plan" describes the procedure for importing the PN offsetFirst click on the CDMA PN Offset/Handoff icon to display the CDMA PN Offset/Handoff dialbox. Select Edit>PN Offset Plan to open the Edit PN Offset Plan dialog box. In the Edit PN OPlan dialog box, select File>Import to open the Import dialog box, and then select the approfile from which to import. Check the “Use NetPlan’s Region” checkbox, and then selectappropriate system and region to receive the import. Click on OK to import the file intoanalysis. Once the file is imported into the analysis, it must be saved using the File>Save Asselection from the Edit PN Offset Plan window.

The CDMA PN Offset/Handoff dialog box, provides options for:

• highlighting, with colored arcs, all PN offset reusers for the selected sector

• highlighting, with colored arcs, all adjacent PN offset assignments for the selected s

• viewing all the PN offset assignments simultaneously

Various colors can be used for highlighting PN offsets. If the highlighting of PN offset reusadjacencies is performed simultaneously with the highlighting of neighbors, then the selectcolors should be made carefully to avoid ambiguities.

The interface also allows for manually editing the PN offset plan. A similar approach as outin Section 14.2.3 would be followed.

** NetPlan - PN offset plan* Copyright (s) by Motorola Inc.* All rights Reserved.* PN offset plan: test1*Joliet-PCS/Joliet_Central/01/1 3Joliet-PCS/Joliet_Central/01/2 6Joliet-PCS/Joliet_Central/01/3 9Joliet-PCS/Joliet_Central/02/1 12Joliet-PCS/Joliet_Central/02/2 15Joliet-PCS/Joliet_Central/02/3 18


14


Figure 14-5: Import PN Offset Plan


Tower Top Amplifiers -Design Considerations

Appendix

A1
Table of Contents
- 3

- 81 - 91 - 9

- 9

A1.1 Impact of a Tower Top Mounted Amplifierto the RF Link Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1

A1.2 Incorporating a Tower Top Amplifier into theNetPlan CDMA Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1 A1.2.1 Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA1.2.2 Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A1.3 Benefits and Drawbacks of TTAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A1

A1 - 1CDMA RF System Design ProcedureApr 2002

A1

Appendix A1: Tower Top Amplifiers -Design Considerations

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

A1 - 2 CDMA RF System Design Procedure Apr 2002

A1


dget isgetfigureselesst andF isgroupeach

a when

n

tageall,

ded

A1.1 Impact of a Tower Top Mounted Amplifier to the RF Link Budget

This appendix describes how the reverse path (subscriber to base station) of the RF link buimpacted by the addition of a Tower Top mounted Amplifier (TTA). One of the link budparameters that is affected by the use of a TTA is the noise figure (NF) parameter. The noiseof a network is a value used to compare the noise in a network with the noise in an ideal or noinetwork. It is a measure of the degradation in signal-to-noise ratio (SNR) between the inpuoutput ports of the network. Noise factor (F) is the linear representation of NF, where Nexpressed in dB. For some situations, it may be necessary to calculate the noise figure of aof amplifiers that are connected in series. This can be accomplished if the noise figure ofindividual amplifier is known.

The equation for determining the cascaded noise factor referenced at the base of the antennusing a tower top mounted amplifier is:

[EQ A1-1]

Where:Fc is the cascaded noise factor referenced at the base of the antenna

F1 is the noise factor of the TTA

F2 is the noise factor of the components between the TTA and base statio

F3 is the noise factor of the base station

G1 is the gain of the TTA

G2 is the gain of the components between the TTA and base station

Note: The parameter values are linear and not in dB.

The equation for converting Noise Figure to Noise Factor is:

[EQ A1-2]

The equation for converting Gain in dB to linear Gain is:

[EQ A1-3]

One important point to be made with respect to Equation A1-1 is that if the gain of the first s(G1) is sufficiently high, the denominators of the last two terms will force those terms to be sm

leaving onlyF1. Therefore, the NF of the first stage will typically determine the NF of the casca

configuration.

Fc F1

F2 1–

G1---------------

F3 1–

G1G2---------------+ +=

F 10 NFdB( ) 10⁄( )=

Gl 10 GdB( ) 10⁄( )=


A1


in dB)pers,ain

dB.

n beer topTArationbasether to

d onationnoisetoplossy

The NF of two or more cascaded lossy networks can be found by simply adding the losses (of each network element. Examples of a lossy network element are: transmission lines, jumduplexers, filters and mixers. If a duplexer with an insertion loss of 0.5 dB is followed by a mtransmission loss of 3 dB, the combined noise figure of this cascaded lossy network is 3.5

Typically, the noise figure value to be used in determining the receiver sensitivity value caobtained from the specification sheet for the particular product. In some instances, a towamplifier (TTA) may be installed to improve the level of the received signal at the BTS. The Tincludes an amplifier, therefore, a new noise figure needs to be determined since the configunow has cascaded amplifiers. A TTA will only benefit the reverse RF path (subscriber tostation). Since the TTA is only improving the reverse link, the forward link may becomelimiting RF path. It may be that a larger power amplifier is needed in the forward link in ordebalance both paths.

The following figure (Figure A1-1) shows two different sites, one site has an amplifier locatethe top of the tower and the other site is a conventional site that has no additional amplificbeyond the base station. This diagram will be used to run through an example showing thefigure improvement with the TTA. In this diagram, stage 2 in the configuration with a toweramplifier, and stage 1 in the configuration without a tower top amplifier, represent cascadednetwork elements which are able to be summed together.


A1


Figure A1-1: Example of Two Different Receive Path Configurations

Antenna

Jumper to Antenna

Main Transmission Line

Antenna Surge Protector

Jumper to Directional Coupler

Directional Coupler

Jumper to Duplexer

Jumper to TX and RX Antenna Port

BTS

Waveguide Entry Port

Duplexer

Tower Top Amplifier

BTS

Jumper

12 dBd

0.5 dB

3 dB

NF = 2.5 dB, Gain 12 dB

0.5 dB

12 dBd

0.5 dB

3 dB

A

B

C

D

With Tower TopAmplifier

Without TowerTop Amplifier

NF = 9.5 dB NF = 6 dB

Stage1

Stage2

Stage1

Stage2

Stage3


A1


above

point

nce

tagey.

oiseise

The following table lists the noise figures, noise factors, and gains for each stage in thefigure.

Table A1-1: Receive Path Noise Figures and Gains

Based upon the information in Table A1-1 and Equation A1-1, the noise factor at referenceB in Figure A1-1 for the receive path with the TTA can be calculated as follows:

[EQ A1-4]

FB = 2.97

The equation for converting Noise Factor to Noise Figure is:

[EQ A1-5]

Using Equation A1-5, the cascaded Noise Figure would be:

NFB = 4.73 dB

The design without the tower top amplifier would result in the following noise factor at referepointD shown in Figure A1-1:

[EQ A1-6]

FD = 7.96

NFD = 9.0 dB

The noise figure at pointD could have also been determined by just adding the noise figure of s1 to the noise figure of stage 2 because the elements which made up stage 1 were all loss

From the above calculations, the low noise figure and the gain of the TTA will result in a nfigure of 4.73 dB at reference pointB. This is a 4.77 dB improvement as compared to the no

With Tower Top Amplifier Without Tower Top Amplifier

NF1 2.5 dB F1 1.78 NF1 3.0 dB F1 2.0

NF2 3.5 dB F2 2.24 NF2 6.0 dB F2 3.98

NF3 9.5 dB F3 8.91

G1 12.0 dB G1 15.85 G1 -3.0 dB G1 0.5

G2 -3.5 dB G2 0.45

FB 1.78 2.24 1–15.85

------------------- 8.91 1–15.85 0.45×------------------------------+ +=

NFdB 10 F( )log=

FD 2 3.98 1–0.5

-------------------+=


A1


ith the

ould

wasoise

gain

d aBTS

C) ofcard852R

52R

figure at pointA. Point D, in the non-TTA case, can be compared to pointB to show theimprovement to the noise figure, and thus the reverse link RF path, that can be achieved wTTA. The reverse link RF path has improved 4.27 dB (9 - 4.73) with the TTA.

If the impact of the TTA is to be applied to an RF reverse link budget, the following values wbe used:

Table A1-2: Link Budget Inputs

Note: For the example in Figure A1-1, the base station product which includes a TTAmodified to have a higher noise figure than the typical base station. The higher nfigure for the base station with the TTA configuration was implemented so that theof the TTA would not overdrive the front-end of the base station.

The only Motorola BTS product that included a TTA was the SC4852R and it hahigher noise figure than the typical SC4852 BTS. The SC4852 and SC4852R areproducts that are no longer manufactured. The multicoupler preselector card (MPthe SC4852 was replaced with a tower top amplifier multicoupler preselector(TMPC) in the SC4852R. This module change reduced the noise figure of the SC4base station.

The noise figure specification for the SC4852R base station was:Noise Figure: 6.9 dB (Typical), 9.5 dB (Maximum)

The TTA specifications for the SC4852R were:Noise Figure: 2.0 dB (Typical), 2.5 dB (Maximum)Gain: 12 dB +/- 1 dB

The noise figure specification for the SC4852 base station was:Noise Figure: 4.5 dB (Typical), 6 dB (Max.)

To compensate for the improvement of the reverse link due to the TTA, the SC48was capable of providing 40 watts per sector on the forward link.

Parameter With TTA Without TTA

Base RX Line Loss 0.5 dB 3.5 dBBase Noise Figure 4.73 dB 6 dBRX Sensitivity @ point B C


A1


verseto be

ut anoisentennand the

th aB forthe(3 +of linen pathce thefigurereversers the

theTA.NF

rward

r the

dget

A1.2 Incorporating a Tower Top Amplifier into the NetPlan CDMASimulator

The NetPlan CDMA Simulator does not allow for separate link budgets for the forward and reRF paths. Since the TTA will only impact the reverse link, parameters within NetPlan needproperly set so as not to misrepresent the forward link.

In comparing the information provided in Table A1-2 and Figure A1-1 for the scenario withoTTA, both the forward and reverse links’ reference points are the same (location C). Since thefigure is representing the value at location C, the line loss between the base station and the awould be the same for both the forward and reverse RF paths. The total line losses (3.5 dB) abase noise figure (6 dB) would be used within NetPlan for the case without a TTA.

In comparing the information provided in Table A1-2 and Figure A1-1 for the scenario wiTTA, the forward and reverse links’ reference points are not at the same location (locationthe reverse link and location A for the forward link). Thus, the total line losses would not besame for the forward and reverse RF paths. The forward link would be impacted with 4 dB0.5 + 0.5) of line loss between the base station and the antenna. Table A1-2 shows 0.5 dBloss for the reverse RF link. However, since the line loss represents a common transmissiofor both the forward and reverse links, it needs to be the same value (4 dB). Therefore, sinreverse link line loss is being increased by 3.5 dB to match the forward link, the base noisewould need to be decreased by the same amount (4.73 -3.5 dB) so that the net effect to thelink is the same (4.73 + 0.5 compared to 1.23 + 4.0). The difference lies in which parameteeffects are captured.

In NetPlan, the Cell Noise Figure field (Cell NF (dB)) should be used to account forimprovement in the noise figure of the reverse RF link budget due to the addition of the T(Refer to Chapter 7 concerning the Edit>Site editor window for the location of the Cellparameter.) The Cell NF only impacts the reverse link, so by altering this parameter, the folink remains unchanged.

The following table shows the values that would be used in NetPlan in the calculation foeffective gain and in the cell NF parameter for the previous example.

Table A1-3: NetPlan CDMA Simulator Parameter Inputs

The following are two possible scenarios which illustrate the incorporation of the link buimprovements into NetPlan simulations due to the use of tower top amplifiers.

Parameter With TTA Without TTABase RX Line Loss (to be includedin the effective gain calculation)

4.0 dB 3.5 dB

Cell Noise Figure 1.23 dB 6 dB


A1


n withtenna.the6 dBor thed the

(seented foronly

versees the0 dBes are

(forNoise

hasFigure

r thee Edit

areap withore, for

ble toNF

Thisugh ifor anyement

A1.2.1 Scenario #1

The first scenario expands upon the previous example. From this example, the configuratiothe TTA has a noise figure value of 4.73 dB and a 0.5 dB jumper between the TTA and the anThe configuration without the TTA has a noise figure of 6 dB and 3.5 dB of line loss. Forscenario without the TTA, simulations would be performed with the Cell NF parameter set atfor all sectors and 3.5 dB of base receive line loss utilized in the effective gain calculations. Fsimulations assuming the TTA, the Cell NF parameter would be reduced to 1.23 dB aneffective gain calculations would use 4 dB.

The Cell NF parameter is located in the Edit>Site window under the Antennas/Carriers tabChapter 7) and can be altered on a per sector basis. The reverse link improvement is accouin the Cell NF and not by removing the line loss from the effective gain. This is done so thatthe reverse link will be affected (improved).

A1.2.2 Scenario #2

For this scenario, assume a site configuration where the addition of the TTA improves the reRF link budget by greater than 6.0 dB. For the sake of discussion, assume the TTA improvreverse RF link budget by 7 dB. Within NetPlan, the Cell NF parameter would be reduced tofrom 6 dB, but there is an additional dB that needs to be accounted for (negative cell NF valunot valid).

This additional dB can be obtained by improving the subscriber unit antenna gain by 1 dBexample, modifying a -2 dBd antenna gain to -1.0 dBd) and increasing the subscriber unitFigure by 1 dB (for example, from 10 dB to 11 dB). The net effect then is that the reverse linkbeen increased by 1 dB but the forward link has remained unchanged. The Subscriber Noiseparameter is located within the Configure>Simulation Parameters>CDMA window undeSubscribers tab. The subscriber unit’s Antenna Gain parameter is accessed by clicking thbutton under Subscriber Classes in this window.

Any modification to the subscriber unit’s antenna gain and noise figure applies to the entirewithin the system that this subscriber can be placed (e.g. dependent upon the traffic mawhich the subscriber is associated) and not on a site by site or sector by sector basis. Therefthis scenario, it is assumed all of the cells being simulated have tower top amplifiers.

If some of the sites being simulated do not have tower top amplifiers, then it may be desiraonly reflect a 6 dB improvement (instead of 7 dB) that can be accounted for in the Cellparameter.

A1.3 Benefits and Drawbacks of TTAs

The main benefit of the TTA is that of improving the system noise figure at the BTS location.improved noise figure can potentially allow for an increased reverse coverage range. Thothere are terrain obstructions, the improvement to the reverse path loss may not provide fincrease in range. If the improvement is not accounted for by an increased range, this improv


A1


attery

ed, the

asedAs.be

werpaths.TA,Forentthe

wer

ning,

may allow the subscriber unit to operate at a lower transmit power and thus have a longer blife. The improvement could also allow for an improvement for in-building coverage.

Though the above scenario shows a reverse link RF budget advantage when a TTA is installfollowing lists some of the potential drawbacks of TTAs:

• Increased susceptibility to reverse interference noise. Due to the incresusceptibility to noise, Motorola does not typically recommend the use of TTHowever, in some scenarios (for example in rural applications), TTAs maybeneficial.

• Since the TTA only improves the reverse RF link, an increase to the forward pomay be required to maintain a balanced paths between the reverse and forwardThe RF link budget improvements in the reverse path, with the addition of a Twill need to be matched with a similar improvement on the forward path.instance, if the TTA improves the reverse link by 3 dB, then the PA requiremwould need to provide twice the power. The forward power is dependent onreverse link improvements that are included in the link budget.

In rural and suburban areas, where the carrier will not be fully loaded, pootherwise needed for capacity can be used for coverage.

• Active electronics at the top of the antenna structure (more susceptible to lightmore difficult to get to for maintenance, etc.)


Atypical CellSite Configurations

Appendix

A2
Table of Contents
32 - 42 - 62 - 8

A2.1 Implementation of an Omni Site as a pseudo two-sector Highway Site A2 - A2.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA2.1.2 Antenna Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA2.1.3 NetPlan Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A


A2

Appendix A2: Atypical Cell Site Configurations

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


A2


theways.velingeekingr may

the

se to

A2.1 Implementation of an Omni Site as a pseudo two-sector Highway Site

As the footprint for CDMA coverage expands, operators are looking for ways to reducequantity of sites, and the subsequent cost, to provide for CDMA coverage along remote highThe operators desire to provide coverage of the highway to support the users which are trafrom one populated area to the next. Along these stretches of road, the operator often is not sto provide coverage to areas off the road. Various options exist which the system designewish to consider. Each option also lists some of the benefits and drawbacks:

• Install a sector site with only two sectors equipped (one sector directed uphighway and the other sector directed down the highway)

• Minimal coverage off the highway

• Utilize high gain highly directional antennas

• Only two sectors of equipment

• Install the site antenna on a tall antenna support structure

• Potentially greater line loss

• Governmental regulations concerning heights

• Potential of causing additional interference to populated areas if done too clopopulated areas

• Install tower top amplifiers

• Improves only the reverse link

• May need additional forward PA power

• Active electronic devices at the top of antenna support structure

• Increased susceptibility to reverse interference noise

• Install a conventional omni site

• Requires less BTS equipment than a sector site (lower BTS cost)

• Omni antennas often have lower gain and therefore will provide less range


A2


t theuld beidingwith

efit ifreater

BTSnna

ationsparate A1).

, to arationrationtwo

nnas.

w thetruly

(one-do two-

TheC611,

anytwo

t BTSy bed by

wo-

• Install omni site with split transmission paths

• Requires less BTS equipment than a sector site (lower BTS cost)

• Instead of having omni antennas, the site is configured with splitters to direcsignal to two separate sets of directional antennas. One set of antennas woproviding service up the road and the other set of antennas would be provthe service down the road. This essentially would resemble a two-sector siterespect to the antenna configuration and would only provide a coverage benthe difference in gain between the omni antenna and directional antenna is gthan the loss of the splitter.

• This configuration can be thought of as a pseudo two-sector site in that thehardware requirements are for an omni configuration but the anterequirements resemble that of a sector site.

It is this pseudo two-sector site that will be further discussed herein, due to special considerthat are required when simulating and interpreting the results of the system design. A seappendix discusses the unique considerations for the tower top amplifier (refer to Appendix

A2.1.1 Overview

An omni BTS product can be connected to an omni antenna or, with additional RF plumbingpseudo two-sector antenna configuration. The hardware requirements for an omni configu(RF energy to one antenna) are different than the hardware requirements for the configuwhere the same RF signal will be split between two antenna. Basically, the site usingdirectional antennas will require the use of a splitter to divide the signal between the two anteAlso, additional antennas are required.

The following paragraphs provide a detailed procedure for using NetPlan and describes hostatistical data from the pseudo two-sector antenna configuration should be combined torepresent the final result. Figure A2-1 represents the hardware configuration of an omni sitesector) based on the SC611 product and Figure A2-2 represents its counter part, the pseusector antenna implementation, where the signal is split between two sector antennas.

Note: As of August 2001, Motorola has cancelled the production of the SC611 BTS.replacement BTS is the SC300. Though this appendix makes references to the Sthe approach and concerns presented would apply to any omni BTS frame or toscenario where a given RF signal coming out of the BTS is to be delivered toantennas instead of only one. Though, differences that exist between the differenproducts would need to be adjusted for accordingly. For instance, there madifferences in the available PA power and the number of channel elements offerethe BTS product.

Also note that the CBSC database entry for an omni BTS implemented with tdirectional antennas should be equipped as an omni site.


A2


Figure A2-1: SC611 Omni Configuration

Figure A2-2: SC611 Pseudo Two-Sector Configuration

Tx

SC611

Tx/RxRx

Rx Rx

SectorAntennaSystem

Duplexer/Dir. Coupler


Tx/RxTx/Rx RxRx

splittersplitter

Sector #2AntennaSystem


SC611

Rx Rx TxRx Rx




A2


signale is theimizetionalighway

widezontal

beam

s in theere the

tively,re willeratedter the

not

A2.1.2 Antenna Considerations

One important consideration that system designers should keep in mind when splitting abetween two antennas is the chosen antenna type. The main concern with the antenna typpotential for interference due to overlapping coverage areas of the two sectors. In order to minthis potential for interference between antennas, it is recommended to use highly direcnarrow beam antennas. Let us use an example where a designer attempts to provide hcoverage on a road with a 90 degree turn. Figure A2-3 displays the coverage area from twohorizontal beam antennas. Figure A2-4 illustrates the coverage area from two narrow horibeam antennas. It can be seen that there is less overlapping coverage area with narrowantennas.

Based on the fact that the same signal is transmitted by both antennas, there will be instanceoverlapping coverage area where the two signals will be in-phase (peaks), and instances whtwo signals will be out-of-phase (nulls). In other words, when the signals are added constructhere will be areas with high signal power and when the signals are added destructively, thebe areas with low signal power. The interference will appear due to the nulls and peaks genin the overlapping coverage area. The greater the overlap in coverage area, the greainterference from the simulcast signal coming from the neighboring co-located antenna.

Another advantage of narrowing the beamwidth is an increased gain. Typically, thoughnecessarily, the narrower beamwidth antennas have higher gain.


A2


Figure A2-3: Wide Beam Antenna Pattern for a Two-Sector Coverage

Figure A2-4: Narrow Beam Antenna Pattern for a Two-Sector Coverage

Overlapping coverage area

Sector #1

Sector #2

Highway road

Antenna

Antennacoverage

coverage

Overlapping coverage area

Sector #1

Sector #2

Highway road

Antenna

Antennacoverage

coverage


A2


sectornnas,ectortwo

: thesticalent that

ximumt takeare:

e BTSitional

losse cablewn inline

er to

A2.1.3 NetPlan Procedure

The NetPlan propagation tool can model two-sector sites and provide output results on a perbasis. However, in a configuration where an omni site has its signal split between two antethe site is not actually a two-sector site. If the site is modeled with the NetPlan tool as a two-ssite, the statistical outputs will be given for two individual sectors rather than combined for theantennas.

The NetPlan procedure for this site configuration will be composed of three different partsReverse Link Coverage, the NetPlan CDMA Simulator Input and the NetPlan Output StatiResults. These three parts are the only sections of the RF system design procedure documrequire changing for this particular site configuration.

A2.1.3.1 Reverse Link Coverage Based On Maximum Allowable Path Loss

There are two aspects of the reverse link coverage generation process (based on maallowable path loss only) that need to be modified in order to account for the changes thaplace during the conversion from the true omni site into the pseudo two-sector site. These

• RF link budget changes

• ERP calculations.

A2.1.3.1.1 Changes to the Link Budget

When configuring an omni site as a pseudo two-sector antenna system, the signal from thmust be divided between the two sets of directional antennas. This requires the use of an addsplitter in the transmission line path. With the addition of the splitter, approximately 3 dB ofis added to each sector’s transmission line in the link budget. These changes are shown in thloss portion of the SC611 Base Receive Link Budget (see Table A2-1). The numbers shoTable A2-1 are an example of a link budget from a highway study with a main transmissionloss of 3.5 dB and a jumper loss of 0.5 dB. It is the responsibility of the system designdetermine the appropriate line loss corresponding to the cable length used in their design.

Table A2-1: Example Link Budget Changes for Voice Path Uplink

Configuration Configuration

Omni Base Rx Cable Loss 4.0 dBPseudo 2-sector Base Rx Cable Loss

Splitter Loss4.0 dB3.0 dB


A2


theon an

ion”ectors (see

ased

done

A2.1.3.1.2 ERP Calculations

The NetPlan reverse link ERP calculations for both a typical omni site configuration andpseudo two-sector configuration are presented below. The parameters used are basedexample IS-95 link budget of a highway study utilizing the SC611 BTS. The “omni configuratassumes a typical configuration of an omni site (see Figure A2-5). The “pseudo two-sconfiguration” assumes an omni site where the signal is split between two sets of antennaFigure A2-6).

Note: For further details regarding link budgets and how to calculate the NetPlan “ERP” bon link budget parameters, please refer to Chapter 2.

Table A2-2: Example NetPlan ERP CalculationsBased on Receive Voice Link Budgets (13 Kbps Vocoder)

NOTES:

1. The antenna gain values are in dBd since NetPlan requires all calculations to beusing antenna values in dBd. (dBd = dBi - 2.14)

2. Line Loss for an omni configuration is given by:Cable Loss + Jumper = 3.5 + 0.5 = 4 dB1

3. Line Loss for a pseudo two-sector configuration is given by:Cable Loss + Jumper + Splitter = 3.5 + 0.5 + 3 = 7 dB2

Reverse LinkParameter

Unit Notes OmniConfiguration

pseudo 2-sectorConfiguration

Portable Tx power dBm a 23 23

Portable Ant Gain dBd b Note 1 -2.14 -2.14

Body Loss dB c 2 2

Vehicle Loss dB d 6 6

Building Loss dB e 0 0

Base Ant Gain dBd f Note 1 11 20

Line LossSplitter Loss

dB g Note 2&3 40

43

Interference Margin dB n 0.5 0.5

Ambient Noise Rise dB p 0 0

Shadow Fade Margin dB r 5.6 5.6

NetPlan Rv “ERP”= a+b-c-d-e+f-g-n-p-r

dB 13.76 19.76

1. These values are from the example given in Figure A2-5.2. These values are from the example given in Figure A2-6.


A2


ed intoct RF

nto aseudoectors.oving

s areighway by:

2-1]

A2.1.3.1.3 NetPlan ERP Entries

Refer to Chapter 2 for entering the NetPlan ERP value. This ERP value needs to be populattwo NetPlan sectors. Populating two NetPlan sectors allows the site to resemble the correfootprint for the deployed system.

A2.1.3.2 NetPlan CDMA Simulator Inputs

The one NetPlan CDMA Simulator input parameter that is affected when splitting an omni ipseudo two-sector site is the Effective Gain parameter. NetPlan can not directly model a ptwo-sector site. Simulations can be run by entering the site data using two separate sFigure A2-6 shows the BTS as being split in this manner. Caution must be exercised when mbetween the real site configuration and the “split” configuration entered into NetPlan.

The Effective Gain calculations for both the omni and the pseudo two-sector configurationshown below. The parameters used are based on the previous example link budget of a hstudy utilizing the SC611 product (see Table A2-2). The Effective Gain expression is given

Eff Gn (dBd) = Sector Antenna Gain - Cable Loss - Lognormal Fading Margin [EQ A

Omni Configuration:

Omni Antenna Gain: 11.0 dBd

Cable Loss = Line Loss + Jumper = 3.5 + 0.5 = 4.0 dB

Lognormal Fading Margin: 5.6 dB

Eff Gn = 11.0 - 4.0 - 5.6 = 1.4 dBd

Pseudo Two-Sector Configuration:

Sector Antenna Gain: 20.0 dBd

Cable loss = Line Loss + Jumper = 3.5 + 0.5 = 4.0 dB

Splitter Loss = 3.0 dB

Lognormal Fading Margin: 5.6 dB

Eff Gn = 20.0 - 4.0 - 3.0 - 5.6 = 7.4 dBd


A2


Figure A2-5: NetPlan CDMA Simulator View of an Omni Configuration

Figure A2-6: NetPlan CDMA Simulator View of a Pseudo Two-Sector Configuration

Duplexer

Tx/Rx Rx

Sector #1

4.0 dB loss from main

Rx Tx

Rx

OmniAntennaSystem

TxRx

PA Power

transmission line plusJumperspecific tothe site

Tx/Rx Tx/RxRx


Sector #1

3.0 dB

Rx


Rx

Rx

Sector #2

TxRx Rx Tx

Splitter

1/2 PA Power

0.5 dBJumper

loss

loss 7 dBtotallineloss

1/2 PA Power

The base station isenvisioned as beingsplit in half.

specific tothe site3.5 dB

maintransmissionline lossDuplexer

Rx Tx

Duplexer

Rx Tx


A2


MAshownennas,n thed in ane Highhese

BTSmentower

usingrs and

]

ARPwill

ns”.n, ther.

]

PAR

A2.1.3.3 NetPlan CDMA Simulator Output Statistical Results

In general, the NetPlan CDMA Simulator output statistics, as well as, the NetPlan CDSimulator output images for a pseudo 2-sector configuration are analyzed the same way asin earlier chapters of this procedure. However, since one signal is being split between two antthere are a few differences in how the data is used. The following paragraphs contaiprocedures on how to compute and analyze the results of two parameters that are affecteomni configuration where a signal is split between two antennas. These parameters are thPower Alarm Rating (HPAR) and the Average Rated Power (ARP). More details on tparameters are found in Chapter 9 of this document.

A2.1.3.3.1 Average Rated Power (ARP) Calculations using NetPlan Cell Statistics

In order to determine if the system design falls within the specifications for the chosenproduct, the designer must calculate the ARP for the site and compare it to the equipspecifications. The procedure for determining the site ARP is described in Section 9.5.9, “PAmplifier Considerations”. However, this determination is based on only one sector. Whena pseudo 2-sector configuration, the system designer must compute the ARP for both sectoadd the two results together.

ARP (total) = ARP(sector#1) + ARP(sector#2) [EQ A2-2

The total ARP result can be compared to the given product specific ARP value. The totalresult should be lower. If not, the forward power will be limiting the design. Either fewer usersbe supported or the sites should be spaced closer together.

A2.1.3.3.2 High Power Alarm Rating (HPAR) Calculations using NetPlan Cell Statistics

Determining the HPAR for a site is described in Section 9.5.9, “Power Amplifier ConsideratioThe HPAR result is based on only one sector. When using a pseudo 2-sector configuratiosystem designer must compute the HPAR for both sectors and add the two results togethe

HPAR (total) = HPAR(sector#1) + HPAR(sector#2) [EQ A2-3

The total HPAR result can be compared to the given product specific HPAR value. The total Hresult should be lower.


A2


is thebilityrry theing

ductwill beoduct

lowerperbeuct.

. Sincectors (2ge and

g B

611.

uld bets forwill be

A2.1.3.3.3 Channel Element Calculations

Another important issue when using an omni BTS in a pseudo two-sector configuration,availability of channel elements in contrast to the traffic carried by the site. It is the responsiof the system designer to determine if enough channel elements (per site) are available to catraffic proposed by the output statistical results of the NetPlan simulations. The followprocedure will guide one on how to calculate the primary traffic based on the availability of prospecific physical channels. For this example, the SC611 product is assumed. The resultscompared with output statistical results from a highway study performed using the SC611 prin a pseudo two-sector configuration.

The SC611 product has the ability to support 16 Physical Traffic Channels (PTCH) as thelimit and 36 PTCH as the upper limit. The computations of the primary traffic for both the upand lower limits are provided below. Only the results of the upper limit (36 PTCH) willcompared against the output statistical results from a highway study using the SC611 prod

Step 1: Calculate Actual Channels (ATCH) using equation A2-4.

[EQ A2-4]

Where:

OH stands for overhead channels. The OH channels are the page and sync channelsthis is a pseudo two-sector site, the same page and sync channels will be sent out to both seoverhead channels). In a true two-sector configuration, each sector would have its own pasync channels for a total of four overhead channels.

ATCH = 16 - 2 = 14 based on 16 PTCH

ATCH = 36 - 2 = 34 based on 36 PTCH

Step 2:Convert the ATCH number into the corresponding traffic in Erlangs using the Erlantable.

14 ATCH, yields 8.2 Erlangs at 2% Grade Of Service (GOS)

34 ATCH, yields 25.53 Erlangs at 2% GOS

Note: The 25.53 Erlangs is the maximum channel element hardware capacity of the SC

The statistical results regarding the number of channel elements per sector (ChElem) shocompared to the maximum capability of the BTS equipment. If the sum of channel elementhe two sectors exceeds the maximum supported by the SC611, then either another siterequired or capacity should be limited. See Chapter 9 for further details.

ATCH PTCH OH–=


A2


_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


WiLL System Design
Appendix
A3
Table of Contents
3 - 3

- 3 - 43 - 4

53 - 53 - 5

3 - 53 - 53 - 63 - 73 - 73 - 73 - 7

3 - 73 - 8 - 9 - 9

- 11 - 12

- 1314- 14

1415- 15

5 - 16 - 17 - 17

A3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A3.2 Subscriber Unit (FWT) Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 A3.2.1 In-Building FWT Antenna Placement. . . . . . . . . . . . . . . . . . . . . A3A3.2.2 External FWT Antenna Placement . . . . . . . . . . . . . . . . . . . . . . . A

A3.3 Link Budget Differences for a Fixed System Versus a Mobile System A3 - A3.3.1 Frequency Band. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.2 Vocoder Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.3 Subscriber Unit Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.4 Subscriber/FWT Antenna Gain . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.5 Subscriber Unit Line Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.6 Body Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.7 Vehicle Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.8 Building Loss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.9 Base Station Antennas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.10 Base Station Sensitivity - Eb/No . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.11 Interference Margin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA3.3.12 Fade Margin/Reliability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.3.13 Example Fixed Subscriber Link Budget . . . . . . . . . . . . . . . . . . . A3

A3.4 Determining NetPlan Inputs from Link Budgets . . . . . . . . . . . . . . . . . A3 - 11

A3.5 NetPlan Coverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.5.1 Propagation Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3

A3.6 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.6.1 CDMA WiLL Call Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 - A3.6.2 Impact of System Configuration on Capacity . . . . . . . . . . . . . . . A3

A3.7 Traffic Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 -A3.7.1 Uniform Versus Non-Uniform Distribution . . . . . . . . . . . . . . . . A3 - A3.7.2 Generating a Traffic Distribution Map . . . . . . . . . . . . . . . . . . . . A3

A3.8 Simulator Input Parameter Differences . . . . . . . . . . . . . . . . . . . . . . . . A3 - 1A3.8.1 Antenna Gain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.2 Penetration Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.3 Fading Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3


A3

Appendix A3: WiLL System Design

- 17 - 17- 18 - 18 - 18

- 20

A3.8.4 Maximum Reverse Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.5 Speed Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.6 Traffic Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3 A3.8.7 Subscriber Unit Noise Figures. . . . . . . . . . . . . . . . . . . . . . . . . . . A3A3.8.8 Probe Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3

A3.9 NetPlan CDMA Simulator Statistical Output for Fixed Systems . . . . A3 - 19

A3.10 NetPlan CDMA Simulator Images Output for Fixed Systems . . . . . . A3 - 19

A3.11 WiLL Design Cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A3


A3


fixede-or in

viewcesses

rkn besuch,

essused in

WiLLDMAk. For

dowto the

a, isit itselfDMAon ofor and

onalxternalince thee than

tennaase

A20-

A3.1 Overview

A WiLL system is a wireless system that provides telephony service to subscribers that have alocation (not mobile). Typical applications of CDMA WiLL technology are to provide “wirelinlike” service in countries that do not have the infrastructure to support landline phonescountries where rapid phone deployment is necessary.

In July 2000, Motorola’s Fixed Wireless Systems Group underwent a product portfolio reresulting in a corresponding refocus of strategic direction. As a result, the Wireless AcSystem’s Division (WASD) product portfolio will no longer be marketed or sold. This includproducts in the IS-95 Wireless Local Loop portfolio (including the WAM, NetwoCommunications Unit (FWT) and, Terminal Management Center). WiLL services, though, caprovided using the A+ interface (data connection between the CBSC and an MSC) and asthis appendix is being provided to address the RF aspects of a WiLL system design.

The basic network elements of Motolola’s CDMA WiLL architecture are similar to the wirelmobile system architecture. The base stations used in WiLL systems are the same as thosemobile systems. The subscriber unit, however, is not the same and is referred to within asystem as a fixed wireless terminal (FWT). The FWT has similar RF characteristics as the Cmobile subscriber unit, however it is connected to a typical desktop phone via an RJ-11 jacthis reason it is sometimes referred to as a “wireless RJ-11 jack”.

A3.2 Subscriber Unit (FWT) Placement

The FWT is equipped with an omni antenna which is typically placed indoors, near a winfacing the serving cell site. Alternatively, an external directional antenna may be connectedFWT unit in place of the omni antenna for better signal reception in fringe coverage areas.

The FWT antenna type, omni-directional whip antenna or external directional antenndependent on the design for the specific market in question. (Please note that the FWT unis always placed indoors, it is only the antenna that can be placed outdoors.) Typically, CWiLL systems deployed by Motorola use either 100% indoor FWT antennas or a combinatiindoor and outdoor antennas (such as 90% indoor and 10% outdoor antennas or 80% indo20% outdoor antennas). Before determining which FWTs (if any) will have external directiantennas, the benefits and drawbacks as well as a cost analysis of using FWTs with eantennas need to be understood. Deployment costs need to be factored into the analysis stime and materials for deploying FWTs with external antennas make them more expensivFWTs with indoor whip antennas.

The next two sections will address some of the benefits and drawbacks of the two FWT anplacement options: indoor (in-building) and outdoor (external). (For further information, plesee the “Network Communications Unit Description and Installation” document - 68P64113B)


A3


xternaluiredance

ildinguildingrding

reforeh on

ding).

lossFWT

moremays alsoadded,again.

fits thatsed ingood

so, theeforeng theease inuce the

al. Theso, it isted byvides

ternalr more. Notenother

A3.2.1 In-Building FWT Antenna Placement

In general, the indoor whip antennas are easier, cheaper and quicker to install than eantennas. The fact that they are easier and quicker to install will reduce the overall time reqto deploy a WiLL system. However, proper placement of the antenna is critical to the performof the system. An optimal placement of the antenna near the outside wall or window of the bu(on the same side of the building as the base station that serves it) can reduce the bpenetration loss. (Please refer to Section A3.3.8, "Building Loss" for more information regabuilding loss.)

The placement or mounting of the FWT antenna affects the system performance and it is theimperative to locate the FWT antenna in an optimum location. Mounting the FWT antenna higthe wall improves the performance over a desktop mounting (both in average power and in faFading is less severe if the antenna is placed in an optimum position.

Another performance benefit of an indoor antenna placement is that there is no cableassociated with the FWT unit. This is due to the fact that the antenna is attached directly to theunit.

A3.2.2 External FWT Antenna Placement

The use of an external antenna at the FWT location is not needed for most applications. It isdifficult, more costly and requires more time to install than indoor whip antennas. (It alsorequire additional equipment such as mounting kits and lightning arrestors.) External antennaneed to be sighted (pointed) to their serving site. As the system grows and more cell sites arethe external antenna FWT locations may need to be revisited to have their antennas sighted

Although the external antennas are not recommended for most applications, they have benemake them useful in some circumstances. The higher gain directional antennas that are uexternal placements provide for a larger cell radii. Therefore, external antennas may be achoice for outlying fringe coverage areas or in rural areas to extend the coverage range. Aldirectionality of the antennas reduces the potential system interference which will therincrease the capacity of the site and reduce the required soft handoff overhead (reducinumber of channel elements required and the costs associated with them). Due to the incrcapacity and coverage, external antennas may be recommended at some locations to redtotal number of sites in the system.

As in the case of indoor antennas, proper placement of the external antennas is essentiantennas should be placed on the same side of the building as the serving base station. Albeneficial if the antennas are placed in line-of-sight to the serving base station (unobstrucmetal signs, dense foliage, traffic, and other buildings). A line-of-sight external antenna progreater capacity than a non line-of-sight antenna.

Unlike the indoor antenna installations which have no cable loss associated with them, the exantenna installations have a significant cable loss which must be factored into the design. Fodetails on subscriber unit line loss, please see Section A3.3.5, "Subscriber Unit Line Loss"also that the transmission line associated with the external antenna installations adds a


A3


createe linknes theh a

obileem. Inrs fore link

tem.n the

esignerstem

esignng the

unitsystem.

ationsign of

r unit.tenna

element to the system which can degrade with time or be physically damaged.

A3.3 Link Budget Differences for a Fixed System Versus a Mobile System

As in a mobile system design, the first step in designing a system for fixed subscribers is toa link budget to model the RF path between the fixed subscriber and the base station. Thbudget establishes the design parameters which are used in NetPlan and also determimaximum allowable path loss. This maximum allowable path loss, in conjunction witpropagation model, is used to estimate the coverage of the cell.

The process for creating a link budget for a fixed subscriber system is the same as for a msystem. However, the values used for some of the parameters are different for a fixed systsystems that are comprised of only fixed subscribers, a link budget with specific parametefixed subscribers should be used. In systems with a mix of mobile and fixed subscribers, thbudget that represents the limiting case should be used (typically, the mobile link budget).

The following subsections highlight the link budget parameters for a fixed subscriber sys[Further details regarding link budgets can be found in Chapter 2 of this document and i“CDMA/CDMA2000 1X RF Planning Guide” (March 2002), Chapter 4.]

A3.3.1 Frequency Band

Some of the link budget parameters are dependent on the given frequency band, so the dmust know what frequency band the system will be operating in before beginning the sydesign.

A3.3.2 Vocoder Rate

Another factor that affects the parameters in the link budget is the vocoder rate. Again, the dengineer needs to know the vocoder rate(s) that will be used in the system before beginnidesign. Since the FWTs can be purchased from different vendors, the vocoding rate for thethat will be used in the particular market should be obtained and used in the design of the s

A3.3.3 Subscriber Unit Transmit Power

Again, since the FWTs can be purchased from different vendors, the transmit power specificfor the units that will be used in the particular market should be obtained and used in the desthe system.

A3.3.4 Subscriber/FWT Antenna Gain

The antenna gain for the FWT is different than that typically assumed for a mobile subscribeThe antenna gain will also vary depending upon whether an indoor omni-directional whip anor an external directional antenna is used. Typical values for FWT antenna gains are:


A3


na gainused

s thatllows:

e baseell astione lossed tondoors,ectedt 800

, and

therFWT

ups or% ofe loss

h oneudget,idea of

losses.metersscriberuld alsoat is setat is set

indoor omni whip antenna gain: -1.04 dBd (1.1 dBi)

external directional antenna gain: 5.36 or 6.86 dBd (7.5 or 9 dBi)(depending on the chosen antenna andfrequency spectrum)

Since the antennas used with the FWT can be purchased from different vendors, the antenspecifications for the units that will be used in the particular market should be obtained andin the design of the system.

(As mentioned in the link budget section, Chapter 2, Section 2.4.2, the NetPlan tool requirethe antenna gains be entered in dBd values. The conversion between dBi and dBd is as fodBi = dBd + 2.14)

A3.3.5 Subscriber Unit Line Loss

The line loss associated with the subscriber unit is similar to the line loss associated with thstation in that it is dependent upon the size and length of the chosen transmission line as wthe frequency band that it will be operating in. The FWT line loss will also depend on the locaof the FWT antenna relative to the actual subscriber terminal. Therefore, a subscriber unit linwill be different for a location where the FWT antenna is placed inside the building as opposwhere the antenna is placed externally. For the cases where the FWT antenna is placed ithere is usually no line loss included in the link budget since the antenna is usually conndirectly to the FWT. However, for external antennas, a line loss is required. For example, aMHz, the cable loss for the 10 m cable is approximately 2.6 dB while that of the 3 m cable isroughly 1.7 dB. (The cable loss will vary depending on the frequency, the length of the cablethe type (diameter) of cable.)

The NetPlan tool does not allow the designer to model each individual FWT specifically. In owords, one does not specify parameters such as subscriber unit line loss for each of thelocations in the system. Instead, FWT parameters such as line loss are specified for grocategories of FWTs within the subscriber class information. For example, in a design with 90the FWTs using omni indoor antennas and 10% of the FWTs using external antennas, the linwould be factored into the subscriber classes by associating the indoor antennas witsubscriber class and the external antenna FWTs with another subscriber class. For the link bone may wish to use the limiting case but also show the other case so that one can get anthe possible range for the non-limiting case.

Subscriber classes can also be used to further define areas that may be using different lineFor example, assume that some of the FWT locations using external antennas are using 3of transmission line and the rest are using 10 meters of transmission line. Separate subclasses could be used to define the 3 meter case and the 10 meter case. However, one coassume a more conservative approach to this example by using only one subscriber class thto the more conservative case (10 meters). A third approach could use a subscriber class thto the value that represents the majority of the installations.


A3


tenna

ot be

ildingis usedsidetenna

na. Thena isation,e: The. andetteroutside

A/

criberect the

.4.2.)

ceiver

A3.3.6 Body Loss

In contrast to a mobile system, body loss does not apply in fixed system designs. The FWT anis connected directly to the FWT or installed outdoors.

A3.3.7 Vehicle Loss

Similarly, vehicle loss does not apply when designing a fixed system since the FWTs will noperating in a vehicle.

A3.3.8 Building Loss

Building penetration loss is applicable in a fixed system design. The value assumed for buloss is dependent on several factors. First, it is dependent upon whether an external antennawith the FWT or if the antenna is placed inside the building. It is also dependent upon whichof the building the antenna is located with regards to the serving base station. Finally, if the anis placed indoors, the building penetration loss also depends on the placement of the antenfurther into the building that the antenna is placed, the greater the loss. If the FWT antenoptimally placed (i.e. near a window on the side of the building closest to the serving base stmounted above desk height) then the building loss value could be reduced to 3 to 6 dB. (Notbuilding penetration loss is a function of the construction of the building, type of windows, etctherefore, the building penetration loss may vary from this value. In order to obtain a bknowledge of the building loss, one can compare signal strength measurements taken rightof and then inside of typical building structures in the area.)

[For further information regarding building loss, please refer to Chapter 4 of the “CDMCDMA2000 1X RF Planning Guide” (March 2002).]

A3.3.9 Base Station Antennas

WiLL systems may require very localized coverage from the base site due to the subsdistribution. In these cases, antennas with narrow horizontal beamwidths may be used to dirsignal to the location where the subscribers are concentrated.

(For information regarding base station antenna gains, please refer to Chapter 2, Section 2

A3.3.10 Base Station Sensitivity - Eb/No

As was mentioned in the section regarding link budgets for mobile systems, the base resensitivity is calculated using the following equation:

Base Rx Sensitivity (dB) = kTB + Eb/No + NF - PGwhere the processing gain PG = 10log(B/R)


A3


d and

f theystems,

Withinmentcatedenna.ding

ay beixedvoicergetwith

s areEb/No

plied in

sitivity

ervingpon thee cellshavecase

he fact

ets,

However, the values may not be the same since the Eb/No values may differ between a fixea mobile system.

(For further details on receiver sensitivity and these calculations, including the definition oterms used, please see the section of this document that discusses link budgets for mobile sChapter 2, Section 2.4.5.)

For mobile systems, the Eb/No target varies dynamically as the subscriber moves around.a fixed system, the Eb/No target may also vary. Although the FWTs are fixed, the environsurrounding them is changing. For example, people may be moving near FWTs that are lowithin a building and buses or pedestrians may be moving close to an outdoor FWT antOptimized FWT deployment may significantly reduce the Eb/No target by avoiding the facaused by the surrounding environment.

The Eb/No value assumes a certain type of fading environment. The fading environment mdifferent for a fixed system than it is for a mobile system. The Eb/No requirement for a fsystem may therefore be different than for a mobile environment. The Eb/No target value forservice can range from 4 dB to 8 dB for CDMA WiLL systems. In a link budget, the Eb/No tavalue should be set to 8 dB for isolated cells using indoor omni FWT antennas or for cellslittle soft handoff benefits in the fringe areas. However, if external directional FWT antennaused and a line-of-sight path exists between the base station and the FWT antenna, then antarget value of 4 dB may be used. For other cases, it is recommended to use the values supSection 2.4.5 as an approximation for the Eb/No.

(Please refer to Chapter 2, Section 2.4.5 for more information regarding base receiver senand Eb/No.)

A3.3.11 Interference Margin

The interference margin is an estimate of the impact that interference generated from the scell and the surrounding cells have on the coverage. The interference margin is dependent uamount of loading (number of users) assumed in the system. It is also dependent upon how thin the system are deployed. For example, in a fixed system, if the cells are isolated orrelatively little soft handoff benefits, then the interference margin would not be as high as in awhere the cells are clustered together (even if the loading is the same in both scenarios). Tthat the cells are isolated reduces the impact of interference from the surrounding cells.

(For further information regarding interference margin, including the impact of different chipsplease refer to Chapter 2, Section 2.4.6.)


A3


adowsigherin is

ty offixed

ect ine fadeers and

ld befixed

d of afoundhe softndoff dB.

in.)

at alle linkquency

A3.3.12 Fade Margin/Reliability

The shadow fade margin corresponds to the variation in mean signal level caused by the shof hills or buildings. The desired system reliability is used to select the fade margin, where a hlevel of desired system reliability requires a larger margin. Since the shadow fade margestimated by a log-normal distribution of signals, adding fade margin to improve the reliabilithe system requires that additional margin is added to all users. However, for a system ofsubscribers, this may not be efficient nor cost effective since placement has a large effdetermining the worst percentage of users. The cost of increasing the reliability (increasing thmargin) should instead be focused on improving the coverage for the worst percentage of usthus not penalize the average user by the additional X dB of fade margin.

For a fixed system, the fade margin, building penetration margin, and soft handoff gain shouconsidered together to provide for the best achievable link budget. The soft handoff gain in asystem may or may not be different than in a mobile system. If the fixed system is compriselarge number of sites arranged in a cluster, then the soft handoff gain may be similar to thatin a mobile system. However, if the sites are isolated or are arranged in small clusters, then thandoff gain will not be as large. For example, in the case of an isolated omni site, the soft hagain would be 0 dB, however, for a large cluster of cells, the soft handoff gain would be 3.5

(Please refer to Chapter 2, Section 2.4.8 for more information regarding shadow fade marg

A3.3.13 Example Fixed Subscriber Link Budget

The following table gives an example of a fixed subscriber IS-95 link budget. It assumes thof the FWTs are deployed with indoor omni-directional antennas. The values chosen for thbudget parameters depend upon the particular system that is being designed and the frespectrum of operation. Therefore, the values may vary from what is shown in the table.


A3


Table A3-1: Fixed Subscriber Link Budget

* These values are used as input into the CDMA simulator.

Parameter Unit Reference Example 13Kbps Link

Budget

Example 8Kbps Link

BudgetNote 1

Subscriber Tx PowerNote 2 dBm a * Section A3.3.3,"Subscriber UnitTransmit Power"

23 23

Subscriber Antenna Gain dBd b * Section A3.3.4,"Subscriber/FWTAntenna Gain"

-1 -1

Subscriber Line LossNote 3 dB c * Section A3.3.5,"Subscriber Unit

Line Loss"

0 0

Body Loss dB d * Section A3.3.6,"Body Loss"

0 0

Vehicle Loss dB e * Section A3.3.7,"Vehicle Loss"

0 0

Building Loss Note 4 dB f * Section A3.3.8,"Building Loss"

6 6

Base Antenna Gain dBd g * Section A3.3.9,"Base Station An-

tennas"

14.5 14.5

Line LossNote 5 dB h * Section 2.4.4 2 2

kTB dBm j Section 2.4.5.1 &Section 2.4.5.2

-113.1 -113.1

Noise Figure (NF) dB k * Section 2.4.5.3 6 6

Eb/No dB l Section A3.3.10,"Base Station Sen-sitivity - Eb/No"

7.3 7.0

Processing Gain (PG) dB m Section 2.4.5.5 19.3 21.1

Base Rx Sensitivity= j+k+l-m Note 6

dBm n Section A3.3.10,"Base Station Sen-sitivity - Eb/No"

-119.1 -121.2

Interference MarginNote 7 dB p Section A3.3.11,"Interference Mar-

gin"

0 0

Ambient Noise Rise dB r * Section 2.4.7 0 0

Shadow Fade Margin dB s * Section A3.3.12,"Fade Margin/Re-

liability"

5.6 5.6

Max. Allowable Path Loss= a+b-c-d-e-f+g-h-n-p-r-s

dB 142 144.1


A3


unit

FWT

n the).

ratinglossandssion, and

ForA/

n is thefer to

etPlanate is

tion oftifyingd effort

quiredorwarddingwersze theudies

Note:1. An 8 Kbps EVRC vocoder uses the parameters presented in this column.

2. Maximum subscriber unit transmit power is typically 23 dBm. The subscribertransmit power may vary depending on the FWT vendor.

3. This link budget assumes the FWT antennas are mounted indoors. Therefore, noline loss is included.

4. If external FWT antennas are used, this field is set to 0 dB. The value specified itable above assumes optimum placement of the FWT antenna (near the window

5. This value is an example line loss value that assumes the base station will be opeat 1.9 GHz and that 100 feet of 1-5/8” heliax transmission line is used (~1.25 dBper 100 feet @1.9 GHz). An additional 0.75 dB is assumed for jumpersconnectors. These values will vary due to operating frequency, length of transmiline, type and diameter of transmission line, number of connectors and jumpersother losses that exist between the BTS and antenna.

6. Base Rx Sensitivity is calculated using the formula kTB + Eb/No + NF - PG.further details, refer to Section 2.4 of this document and to Chapter 4 of the “CDMCDMA2000 1X RF Planning Guide” (March 2002).

7. Path Loss values shown assume an unloaded CDMA system.

Refer to Chapter 2, Section 2.4 for further details on Link Budget Parameters.

A3.4 Determining NetPlan Inputs from Link Budgets

The process of using these link budget values to determine the input parameters for NetPlasame regardless of whether the system is comprised of mobile or fixed subscribers. ReChapter 2, Section 2.5.

A3.5 NetPlan Coverage

As was the case in designing mobile systems, the next step after determining the inputs to Nfrom the link budget is to estimate the system coverage. At this stage, the coverage estimbased only on the maximum allowable path loss. This step is used to get a quick determinamajor coverage issues such as cell placement problems or terrain obstruction issues. By identhese issues early in the process, some of them can be resolved before spending the time anon running simulation studies.

In general, this stage of the design uses a reverse link budget to assist in determining the repropagation path loss to be used in NetPlan. However, to complete a system design, the flink must also be analyzed. The forward link budget consists of many variables inclusubscriber speed, location, soft handoff, noise figure, voice activity, and forward channel po(pilot, page, sync, and traffic channels). It is recommended that simulations be used to analyforward link by accounting for the statistical variation in these parameters. Such simulator stare part of the final design phase.


A3


as for agineero with

or theis notquire aa, andifferent

et thedel to

to theodel

it>Site

nna.tionalwever,t applyate

ystem,tennasuiredle pathstimate

wableis path

ing the

A3.5.1 Propagation Modeling

The propagation or coverage of a fixed subscriber system is generated in the same mannermobile system. However, when using NetPlan to design a fixed subscriber system, the enmust be aware of a few issues that are specific to the NetPlan tool. These issues have to dthe antenna height and directionality of the FWT.

A3.5.1.1 FWT Antenna Height

Within NetPlan, if the Xlos propagation model is used, a height of 1.5 meters is assumed fsubscriber units in a mobile system. In a fixed subscriber system, the height of the FWTnecessarily 1.5 meters. However, a change in the antenna height of the subscriber may rechange in propagation model parameters such as propagation slope, intercept, sigmcorrelation. Since these changes need to be investigated further, NetPlan does not support dantenna heights for the subscriber unit when using the Xlos propagation model.

NetPlan does however contain a Custom Path Loss Model (CPM) which allows the user to scoefficients in a path loss equation. The CPM can be used to change the propagation moaccount for the different subscriber heights. (For further details on the CPM, please refer“NetPlan RF Engineering User’s Manual” and to the “NetPlan Custom Path Loss MApplication Note”.)

The propagation model (Parameter Set) can be set on a per antenna basis within the Edwindow of NetPlan. Refer to Chapter 7 for further details.

A3.5.1.2 FWT Antenna Directionality

Similarly, the NetPlan CDMA Simulator does not model the directionality of a subscriber anteAs in the case for mobile systems, it assumes that all subscriber units utilize omni-direcantennas. With NetPlan Version 5.0, a directional subscriber antenna feature was added. Hothis feature can only be used for analog propagation and interference studies, and does noto the NetPlan CDMA Simulator. The next section will give some guidelines on how to estimwhere an external directional antenna will be required.

A3.5.1.3 Estimating Where External Directional Antennas Will Be Required

If the system operator desires to deploy external antennas at the FWT locations in their sthen the system designer must determine the FWT locations where the use of external anwould be beneficial. A first approximation of where external directional antennas may be reqin a system can be based on the coverage prediction generated from the maximum allowabloss estimate. Simulation studies are used later in the design process to further refine this eof where external directional antennas are needed.

The first step in this process is to generate a coverage prediction based on the maximum allopath loss. This is done in the same manner as was done for a mobile system. In generating thloss prediction, it should be assumed that all sites have indoor whip antennas. When analyz


A3


veragentennalosstheithiner internaladded

basedternal

If theionaln thisould

betorss notesign

o theparedof a

resulting path loss coverage plot, one should determine if there are any coverage holes. If coholes exist, the designer can analyze the area to see if the increase in gain of a directional aover an omni-directional whip antenna (7 dB for example including building penetrationdifferences and line loss differences) will likely fill the coverage hole. When analyzingcoverage plots to determine if an external antenna gain is required, the Query function wNetPlan or a multi-colored best signal strength plot is useful in determining how much strongdB the signal needs to be in order for the hole to be covered. If the increase in gain of an exantenna appears that it would assist in filling the holes, then a directional antenna should beto the design.

As an example, consider the following figure:

Figure A3-1: Estimating Where External Directional Antennas Would be Useful

Assume that the “extent of coverage” in the figure above is at X dB and that this coverage ison the use of omni-directional whip antennas at all FWT locations. Further assume that an exdirectional antenna provides 7 dB additional gain over an omni-directional whip antenna.worst signal strength in the coverage “hole” region is (X-6) dB, then placing an external directantenna at this FWT location may provide coverage. However, if the worst signal strength iregion is (X-10) dB, then placing an external directional antenna at an FWT at this location wnot provide adequate coverage.

Not only would the directional antenna give the benefit of additional gain but it would likelyinstalled at a higher location and with a higher probability of being line-of-sight. These facincrease the confidence in the ability of a directional antenna to fill in coverage holes. If it doeappear that the increased gain will assist in filling the holes, then additional sites or dmodifications will be required.

A3.6 Traffic

As in mobile system designs, the traffic input for a fixed subscriber system design is critical taccuracy of the design. There is a significant difference in the traffic of a fixed system as comto that of a mobile system. The call model for a fixed WiLL system is not the same as that

"extent of coverage area"

coverage "hole"


A3


erent

dline, andribers

ade of

they. For

fromty thansites orble.

ystembiletage of

as aorld

tomapthe

a. Inodel.

stingneedsold

mobile system. Also, the location of the subscribers distributed throughout the area is difffrom a mobile distribution for the same area.

A3.6.1 CDMA WiLL Call Models

Since the FWT is generally used in residential or office buildings as a replacement for lanphones, there is usually a higher traffic value (Erlangs per subscriber), a higher BHCA valuea better grade of service associated with a fixed system. In other words, the fixed subscgenerally use the phone more often, have a longer holding time, and expect a higher grservice than a mobile subscriber. Typical call model values are:

• 0.050 to 0.150 erl/sub

• 0.1% to 5% Grade of Service

A3.6.2 Impact of System Configuration on Capacity

As mentioned in previous sections, the configuration of the FWT unit has an impact oncapacity. Also, where the sites are located in relation to each other affects the capacitexample, the capacity is the greatest in a single isolated cell since the site is isolatedinterference from other cells. Sites that are arranged in small clusters have greater capacisites which are part of larger clusters for the same reason. In some cases of isolated singlesmall cluster of sites, the site capacity may be limited to the number of Walsh codes availa

A3.7 Traffic Distribution

The process for generating a traffic distribution map is the same whether a mobile or a fixed sis being designed. However, the traffic distribution in a fixed system is different than in a mosystem. One obvious difference is that in a mobile system, roads often have a higher percentraffic. However, in a system with fixed subscribers, the traffic would not be on the roads.

In all simulations, whether the subscribers are fixed or mobile, the traffic distribution map hgreat impact on the simulation results. Therefore, it is important to try and match the real-wtraffic distribution as closely as possible.

The Traffic Distribution Map section of this document (Chapter 5) describes in detail howgenerate a traffic distribution map using the NetPlan tool. It describes how to generate thisusing either polygons or existing system traffic data. For an initial mobile CDMA system,CDMA traffic can be estimated using traffic data from an existing cellular system in the arethe case of an expanding CDMA system, the existing CDMA traffic data can be used as the mIn a fixed subscriber system, however, it is not as likely that the designer will have any exifixed traffic data to use as a model for creating the traffic distribution map. The designer willto work closely with the system operator to gain an appreciation for where the FWTs will be(business areas, high income areas, etc.).


A3


ribersilar

rm.rmly

stingesethree

inen

ings

beoodbe

a are

ne

to onlyscribers

of theame as

ixed

A3.7.1 Uniform Versus Non-Uniform Distribution

When a designer has no existing traffic data to use as the model for where the CDMA subscare likely to be, it is sometimes tempting to assume a uniform traffic distribution. However, simto mobile subscriber distribution, the distribution of fixed subscribers is not likely to be unifoFWTs are usually deployed inside buildings and these buildings are not likely to be unifodistributed within the cell coverage area.

A3.7.2 Generating a Traffic Distribution Map

Typically, a traffic distribution map for a fixed system is generated using polygons since exifixed traffic data is usually not available. The weighting assigned to the traffic within thpolygons depends on the particular fixed system that is being designed. To illustrate this,different fixed subscriber scenarios are considered.

1. In-building Fixed Subscribers- When the subscribers are assumed to be locatedbuildings, then the weighting of the traffic distribution map should reflect this. Whgenerating the traffic distribution map, the clutter types which do not contain buildshould be excluded (for example, roads, bodies of water, etc.).

2. Fixed Subscribers in Rural Areas- Although the subscribers are still assumed tolocated in buildings, the clutter data does not usually give the designer a gindication of where buildings are located in a rural area. Therefore, it mayadvantageous to place the traffic on the roads since the buildings in a rural areusually found along the roads.

3. Payphone Systems- Similarly, roads are not excluded when designing a payphosystem in which the payphones are along the roadsides.

In cases where the exact locations of the subscribers are known, the polygons can be drawninclude these regions or an exclusion mask can be used to exclude the areas where the subare not expected.

(Please refer to Chapter 5 for further details on creating a traffic distribution map.)

A3.8 Simulator Input Parameter Differences

As in all simulations, the accuracy of the results is dependent upon the proper settingsimulation input parameters. Many of the parameters in a fixed subscriber system are the sin a mobile subscriber system. However, there are some parameters that are different.

This section will discuss the simulation input variables that may have different values for fsubscriber systems than for mobile systems. These variables include:


A3


ssible, trafficgh themeters

ssesFor

er classber classtype,fixed

fielde gain

WT.lassesloss isomni

eters.)

• Subscriber Antenna Gain

• Penetration Loss

• Fading Type

• Maximum Reverse Power

• Speed Distribution

• Traffic Distribution

• Subscriber Noise Figure

• Image Probe Characteristics

All of these parameters are part of the CDMA Parameters interface. Most of them are accethrough the Subscribers Tab (antenna gain, penetration loss, fading type, speed distributiondistribution, and subscriber noise figure). Of these parameters that are accessible throuSubscribers Tab, many are set through the Subscriber Class Editor. The remaining para(image probe characteristics) are accessible through the Images Tab.

By utilizing the Subscriber Class Editor within NetPlan, the designer can define different clato represent the different types of FWT installations that they have within their system.example, one class can be set up to represent FWTs that have indoor antennas while anothcan represent outdoor antennas. As in the case of mobile subscriber systems, these subscridefinitions include information such as antenna gain, line loss, building penetration, fadingand speed distribution. This section will discuss these input parameters as they relate towireless system designs.

(Chapter 6 discusses all of these parameters in detail.)

A3.8.1 Antenna Gain

The Antenna Gain field defines the net gain of the subscriber antenna system (in dBd). Thisis defined for each subscriber class within the subscriber class editor. It incorporates both thof the FWT antenna and any line loss associated with the subscriber unit.

Antenna Gain Value = [Subscriber Unit Ant. Gain (dBd)] - [Subscriber Unit Line Loss (dB)]

Whether this value includes a subscriber unit line loss will depend on the installation for the FA subscriber unit line loss would be included in the antenna gain value for those subscriber cthat represent FWT subscribers with external antennas. However, a subscriber unit lineusually not included for subscriber classes that represent FWT subscribers with indoorantennas.

(Refer to Section 6.2.2.4.1 for further information regarding setting subscriber class param


A3


as in-f theld benot be

ssibleiberirelessclass ofe Wallselects

, theas awouldriberb/Noscriber

r in

Planding

our,

owerr for

basedr class

A3.8.2 Penetration Loss

As seen in Section 6.2.2.4.1, the Penetration Loss field accounts for signal loss factors suchvehicle, in-building and body loss. This value also varies depending upon the installation oFWT antenna. In the case of an indoor omni antenna, a building penetration loss wouincluded. However, for an external antenna, the building penetration loss parameter wouldincluded (i.e. the field would contain a value of 0).

(Further information regarding setting this parameter can be found in Section 6.2.2.4.1.)

A3.8.3 Fading Type

The Fading Type parameter, which is also part of a subscriber class definition, has three posettings: Mobile, Wall FWT, or Table FWT. The Mobile setting is used for simulating subscrclasses where the subscribers are mobile. The remaining two types are used for fixed wterminals and are selected based upon how the subscriber units are deployed for a specificsubscriber. If the subscriber class represents wall mounted FWTs, then the user selects thFWT fading type. If the subscriber class represents the table mounted FWTs, then the userthe Table FWT.

As was mentioned in a previous section regarding link budget parameters for a WiLL systemEb/No targets for a fixed system may differ from that of a mobile system. Eb/No values varysubscriber moves around. However, since a fixed subscriber is stationary, the Eb/No targetslikely be different than for a mobile subscriber. Therefore, when designing a fixed subscsystem, the proper Eb/No curves must be utilized. Within NetPlan, the fixed subscriber Ecurves are selected by choosing the proper Fading Type parameter when defining the subclass.

(IS-95 Eb/No curves specific to WiLL were incorporated into the NetPlan CDMA Simulatorelease 3.3.1.)

Note: IS-2000 1X Eb/No curves specific to WiLL have not been incorporated into the NetCDMA Simulator. In the absence of these curves, it is recommended to set the fatype to Mobile and assign the WiLL subscribers with a speed of 1 Kilometer per hthus utilizing the same Eb/No curves as a mobile subscriber.

A3.8.4 Maximum Reverse Power

As in the case of mobile subscribers, the “Max Power” field defines the maximum transmit p(in dBm) for each class of mobile or subscriber in the system. The maximum transmit powethe specific FWT should be entered into this field.

A3.8.5 Speed Distribution

Similar to the Traffic Map, a Speed Map can be generated to specify the speed of subscriberson their geographic area. A different Speed Map can be defined for each different subscribe


A3


ass thatferent

ed to

se seecriber

A3.7,

for theof the

ation

tch theent. Inprobe

scriber.criberof fixednnas,images

as, theber withuld beprobennas.

speed.

ation

that is used in the system. In general, a constant speed (0 km/h) is used for a subscriber clrepresents fixed subscribers. In systems with a mixture of fixed and mobile subscribers, a difSpeed Map would be used for the mobile subscribers.

Note: In the absence of the WiLL Eb/No curves for 1X, it is recommended to set the spe1 Kilometer per hour.

(For more information regarding speed distribution maps and how to generate them, pleaChapter 5. For further information regarding setting the speed distribution map for a subsclass, please see Section 6.2.2.4.1.)

A3.8.6 Traffic Distribution

The Traffic Map that was generated specifically for the fixed subscriber system (see Section"Traffic Distribution") should be selected as the simulation input parameter.

A3.8.7 Subscriber Unit Noise Figures

Since the subscriber units (FWTs) can be purchased from different vendors, the noise figureunits that will be used in the particular market should be obtained and used in the designsystem.

(Please refer to Chapter 6 regarding system level simulator parameters for more informregarding noise figure settings.)

A3.8.8 Probe Characteristics

When generating images for a system simulation, the probe characteristics need to masubscriber class characteristics for the desired class of subscriber that the image will represa fixed subscriber system (or a system with some percentage of fixed subscribers), thecharacteristics need to represent a fixed subscriber when generating images for a fixed subIf more than one subscriber class is defined to represent different types of fixed subsinstallations, then separate images would be required to analyze the coverage for each typesubscriber. For example, if the system contained FWTs with both indoor and external antetwo separate subscriber classes would be set up to represent each of these cases. Thenwould be generated separately for each case. For the case of the FWTs with indoor antenncoverage images would be generated using probe characteristics that represent a subscrithe same parameters as an FWT with indoor antennas. Similarly, another set of images wogenerated to show the results for the FWTs with external antennas by setting thecharacteristics to match the parameters of the subscriber class of FWTs with external ante

Keep in mind that the subscriber class chosen for the probe must be defined with a constant

(Please refer to Chapter 6 regarding system level simulator parameters for more informregarding mobile probe characteristic settings.)


A3


ets allshouldand 10ile

e thatmore

at are

allytweenells

ensure

noisend the

zed foretPlanAwill

at will

er andight be

le pathill helperageing all

uirednas atpportrence

A3.9 NetPlan CDMA Simulator Statistical Output for Fixed Systems

In general, the simulation results must be analyzed to ensure that the system design meexpectations and the minimum system performance standards. The same statistical outputsbe analyzed for a fixed subscriber system as for a mobile system (Please refer to Chapters 9regarding “NetPlan CDMA Simulator Statistical Output and Analysis” and “NetPlan Cell/MobAnalysis”). One should look closely at the number of links or channels per sector to be surthe number of Walsh codes has not been exceeded. This is especially important for theisolated cells since they have a higher potential for running out of Walsh codes than sites thsubject to more interference.

Also, the soft handoff factor and percent of links in soft handoff may vary from what one typicsees in a mobile environment. The soft handoff level is dictated by the amount of overlap becells. For isolated cells, the soft handoff level may be very low. However, it will be higher for cthat are surrounded by other cells.

As was the case in mobile systems, the statistics for a fixed system need to be checked tothat the power required at a site is within the LPA specifications for that BTS.

The isolation of the cells will also affect such results as the number of mobiles and the cellrise. If the cells are more isolated, the number of mobiles served by a sector will increase aother cell noise will decrease.

A3.10 NetPlan CDMA Simulator Images Output for Fixed Systems

As was the case for simulator statistical outputs, the same simulator images should be analya fixed system as for a mobile system. (Please refer to Chapters 11, 12 and 13 regarding “NCDMA Simulator Images Output and Analysis”, “Treating Pilot Pollution”, and “NetPlan CDMComposite & Statistical Images (Coverage vs. Path Loss)”.) The cell layout of the systemaffect the images as well. For example, the more isolated the sites, the less soft handoff thbe seen in the images.

As one looks at the coverage of the sites (the composite image of the Reverse Required PowForward TCH Threshold images), one needs to also evaluate whether external antennas museful in some circumstances. Again, as was discussed in analyzing the maximum allowabloss prediction plots, one needs to determine if the increase in gain of the external antenna win covering desired locations. For this analysis, two images are useful: one to show the covassuming all FWTs have indoor omni antennas, the other image to show the coverage assumof the FWTs have external directional antennas.

Keep in mind that this is only an estimate of whether external antennas might provide the reqcoverage. The simulator portion of NetPlan does not take into account the external antenFWT locations. One needs to ensure that there is sufficient BTS PA power available to suthese users. In addition, these FWTs with external directional antennas will be creating interfethat will impact the performance of the system.


A3


tionsto be

tionsge

ereere

0 1X

criber

Planmni-willnalards

) willts ofthan

LossFWTr basisWT

CPM,). Forunitsnd toWTs

notnna ish anrvings intooulduld

A3.11 WiLL Design Cautions

When designing a WiLL system, one needs to keep in mind that there are certain limitainherent in the NetPlan design tools. The following is a list of some of the issues that needkept in mind when designing a fixed system using NetPlan.

• NetPlan should not be used to warranty any CDMA RF system coverage predicfor a fixed system. There is not enough certainty with in-building coverapredictions to justify associating a warranty to such predictions.

• Earlier versions of the NetPlan CMDA Simulator (Version 3.2 and earlier) wbased on Eb/No curves for mobiles. IS-95 Eb/No curves for fixed systems wincorporated into the tool in the general release, NetPlan Version 3.3.1. IS-200Eb/No curves for fixed systems have not been incorporated.

• NetPlan does not depict the exact locations for each FWT. Instead, the subs(FWT) locations are determined from the Traffic Map.

• Directional antennas at the FWT location are not accounted for in the NetCDMA Simulator. NetPlan assumes that all subscriber antennas are odirectional. Therefore, the amount of interference generated in the systemappear worse than it actually would be in reality since the benefits of directioFWT antennas are not taken into account. For example, the interference towother sites (especially the sites on the back side of the FWT directional antennaappear greater than one would expect if the design accounted for the effecdirectional FWT antennas. Also, the interference at the FWT will seem greaterit would be if the design accounted for the effects of directional FWT antennas.

• The actual height of the FWT antenna is not considered unless the Custom PathModel is used to create a propagation model that accounts for the actualantenna heights. The Custom Path Loss Model can be specified on a per sectoand thus all FWTs within a given sector would be associated with an average Fantenna height for that sector. When using propagation models other than theNetPlan assumes that all subscribers are at a fixed height (generally 1.5 metersbuilding applications, this does not accurately represent how the subscribercould be deployed. One can improve the link budget by several dB to correspoan average improvement based on the height of the building. However, some Fwill be worse than this average improvement and some will be better.

• The directionality caused by installing an omni FWT antenna inside a building isconsidered. In reality, the building penetration loss depends on where the anteplaced within the building. There is less building penetration loss associated witindoor FWT antenna that is located on the side of the building closest to the sesite than on a side opposite the serving site. However, the tool does not take thiaccount. Therefore, in simulations, the amount of interference that the FWT wexperience from sites located on the far side of the building (downlink path) wo


A3


or ther sideitesone

theForot behoughworld

be greater than one would expect in reality since the design does not account fadditional building penetration loss associated with the antenna being on the faof the building. Similarly, the amount of interference generated toward the s(uplink path) on the far side of the building would be greater in simulations thanwould expect in reality.

• The capacity results from the simulations may be optimistic sinceimplementation of the system may differ quite a bit from what was simulated.example, the FWT heights may actually be above 1.5 meters, the FWTs may noptimally placed, or in some cases, the FWTs may be used as portables (even tthey are supposed to remain FIXED). In these cases, the capacity in the realmay be considerably less than what is shown in simulations.


A3


_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


Data ServicesSystem Design

Appendix

A4
Table of Contents
4 - 34 - 4

4 - 8 - 10- 13

14- 14 - 17 - 18 23 - 23

- 24- 254 - 30- 3335

43- 43- 44- 44 - 45

- 45- 46

46- 46 - 5254 - 56

A4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA4.1.1 Fundamental and Supplemental Channels. . . . . . . . . . . . . . . . . . AA4.1.2 Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA4.1.3 Supplemental Channel Allocation. . . . . . . . . . . . . . . . . . . . . . . . A4A4.1.4 RF Channel Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4

A4.2 Link Budget Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 -A4.2.1 IS-95B Link Budget Considerations . . . . . . . . . . . . . . . . . . . . . . A4 A4.2.2 IS-2000 Link Budget Considerations . . . . . . . . . . . . . . . . . . . . . A4A4.2.3 General HSPD Design Considerations . . . . . . . . . . . . . . . . . . . . A4A4.2.4 Determining NetPlan Inputs from Link Budgets. . . . . . . . . . . . . A4 -A4.2.5 NetPlan Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4

A4.3 Call Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4A4.3.1 General Attributes of the Data Call Model . . . . . . . . . . . . . . . . . A4 A4.3.2 Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA4.3.3 Example Call Model for a Given Data Service . . . . . . . . . . . . . . A4 A4.3.4 Translation of Call Model Information into Simulation ParametersA4 -

A4.4 Simulation Input Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 -A4.4.1 Radio Access Network - Configuration. . . . . . . . . . . . . . . . . . . . A4 A4.4.2 Radio Access Network - Supplemental Channels [IS-2000 only] A4 A4.4.3 Data Services - Call Models [IS-2000 only] . . . . . . . . . . . . . . . . A4 A4.4.4 Subscribers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4A4.4.5 Supplemental Channel Image Parameter [IS-95B only] . . . . . . . A4A4.4.6 IS-2000 Achieved Data Rate Image [IS-2000 only] . . . . . . . . . . A4

A4.5 Simulation Output Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A4 -A4.5.1 IS-95B Statistical Output and Analysis. . . . . . . . . . . . . . . . . . . . A4 A4.5.2 IS-2000 Statistical Output and Analysis . . . . . . . . . . . . . . . . . . . A4A4.5.3 IS-95B HSPD Images Output and Analysis . . . . . . . . . . . . . . . . A4 - A4.5.4 IS-2000 Images Output and Analysis (HSPD) . . . . . . . . . . . . . . A4


A4

Appendix A4: Data Services System Design

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


A4


ed onHigh

erfaceSPD

sive.

refersitted.

n theThere

Highircuit

ta pullates oflity tocriberusedt 3Gased

ging,ds ofand

of this

oredioMHz

dwidthV-DV

k dataobile

ts of

Simulation of mixed voice and data systems is possible in NetPlan. This appendix is focusexplaining the incorporation of data services into a system design, especially as it relates toSpeed Packet Data (HSPD) services. HSPD services were introduced with the IS-95B air intand enhanced with the IS-2000 air interface. The appendix includes a brief overview of Hfunctionality, link budget and call model considerations, and simulation inputs and outputs.

It should be noted that the simulation of IS-95B HSPD and IS-2000 HSPD are mutually exclu

In this appendix, some text has been highlighted through the use of italics. In most cases, thisto newer IS-2000 material. When an entire section is related to IS-2000, the use of italics is om

A4.1 Overview

A data services network can be viewed as a gateway for offering wireless applications ointernet. This essentially provides a wireless extension to the land based packet networks.are three phases to the evolution of CDMA data service offerings: Circuit Switched data,Speed Packet Data as specified by IS-95B and IS-2000 (2.5G), and Third Generation (3G). CSwitched Data can support data rates up to 14.4 kbps and is targeted primarily for simple daservices and fax support. IS-95B and IS-2000 HSPD services can support peak bearer rapproximately 64 kbps and 144 kbps, respectively. They provide subscribers with the abiaccess the Internet, Intranet, E-mail, or private packet data networks with a wireless subsdevice. They also support the Wireless Application Protocol (WAP) data service that is beingin WAP-capable subscriber units equipped with a microbrowser. The evolution of currenCDMA proposals claim peak data rates ranging from 153.6 kbps to over 2 Mbps. The incredata rates will allow additional applications to be deployed, such as real time video, still imagaming, etc., in addition to improving the end user experience by delivering quicker downloadata. Although this appendix will provide some CDMA RF system design guidelinesprocedures that can be used for circuit switched data system design, the major focusappendix is on HSPD system design utilizing the IS-95Bor the IS-2000 air interface.

With regard to the evolution toward 3G capabilities, operators using CDMA have pushed for mmigration-friendly solutions leading to higher data rates. Consequently, IS-2000 raconfigurations associated with Spreading Rate 3 (i.e. those utilizing three times the 1.23bandwidth of IS-95A/B) have been abandoned in favor of solutions that share the same banas IS-95A/B, namely: 1XEV-DO (a data-only solution based on Qualcomm’s HDR) and 1XE(a data and voice solution based on Motorola’s 1XTREME).1 NetPlan 6.0 will deliver the abilityto simulate IS-2000 Phase 1 (peak data rate of 153.6 kbps). IS-2000 Release A with a pearate of 307.2 kbps will most likely also be bypassed by the industry (Qualcomm’s initial mstation chipsets do not support this data rate).

The following sections will provide an introduction to some of the various RF related aspecHSPD functionality.

1. 1XEV-DO stands for 1X Evolution - Data Only. Similarly, 1XEV-DV stands for 1X Evolution - Data &Voice.


A4


nnelst data,tion.

annel ise tod IS-

RFverse

tion ofin an

hannel, whichditionaland fivee dataof up

rrentlys) andrencessigned.

amentalfferentl.

lingnels aredatas tonot

under

lse

A4.1.1 Fundamental and Supplemental Channels

To realize high-speed data rates, both IS-95B and IS-2000 provide for fundamental cha(FCH) and supplemental channels (SCH). Fundamental channels, when applied to packeprovide basic connectivity for signalling as well as a low-speed packet data connecSupplemental channels provide high-speed packet data connections. One fundamental chrequired for each packet data call. The following sections will provide additional detail relativthe functionality of fundamental and supplemental channels for IS-95B (Section A4.1.1.1) an2000 (Section A4.1.1.2), respectively.

A4.1.1.1 IS-95B Fundamental and Supplemental Channels2

IS-95B HSPD, in the Motorola implementation, is achieved by concatenating multiplechannels on the forward link (Walsh codes). IS-95B HSPD was not implemented on the relink, thus only one RF channel is supported on the reverse link. To enable the concatenamultiple channels, new IS-95B compatible subscriber units are required to be deployed withexisting IS-95A system. The channels on the forward link are designated as a fundamental cor a supplemental channel. For each packet data call, there is only one fundamental channelis supported by one channel element. Higher data rates are achieved by concatenating adchannel elements, called supplemental channels. For rate set one (RS1), one fundamentalsupplemental channels are currently supported, which produces a maximum raw air interfacrate of 57.6 kbps (6 x 9.6 kbps) and can potentially achieve throughput or bearer data ratesto 48 kbps. For rate set two (RS2), one fundamental and four supplemental channels are cusupported, which produces a maximum raw air interface data rate of 72.0 kbps (5 x 14.4 kbpcan potentially achieve throughput or bearer data rates of up to 64 kbps. [Note: NetPlan refethe data rates according to the raw air interface data rate for the total number of channels asSee Section A4.3.2: "Data Rates" for more information regarding data rate definitions.]

For a worst case scenario of channel element usage, one RS1 data call can occupy 1 fundand 5 supplemental channel elements as well as being in three way soft handoff with three dibase stations. This scenario will occupy a total of 18 channel elements for the one data cal

For IS-95B HSPD calls, all power control (via the Power Control Bit, PCB) and signalmessages to the subscriber are sent on the fundamental channel. The supplemental chanonly used for data transmission. During times of no data activity on the forward link (while thesession is still active), the fundamental channel will still transmit eighth (1/8) rate framemaintain the RF link (similar to a voice call), but the supplemental channels will be idle andtransmit any frames at all (thus no power will be transmitted by the supplemental channelsthose conditions).

2. With IS-2000, IS-95B Supplemental Channels (SCH) were renamed Supplemental Code Channe(SCCH). Throughout this document, reference to Supplemental Channels in the context of IS-95B will bsynonymous with IS-95B Supplemental Code Channels.


A4


Thesed dataA4-1

te by

s (i.e.ctionxity.ize itses).

ionsarablepoorloseductionipated

res inte to

her aH).

to athisCCH

thetrol

, willthisthe

eon

A4.1.1.2 IS-2000 Fundamental and Supplemental Channels

IS-2000 HSPD is achieved through the use of newly defined Supplemental Channels (SCH).SCH attain high data rates by reducing the Walsh code chip length in response to increaserates thereby maintaining a constant symbol and chip rate. Consider, for example, Equationand Equation A4-2 which show that, in the forward direction, for every increase in the data raa factor of N, there is a compensatory decrease in the Walsh length by this same factor.

[EQ A4-1]

[EQ A4-2]

The IS-2000 SCH, both forward and reverse, benefits from turbo-coding at higher data ratedata rates of 19.2 kbps or greater). Turbo-coding improves the forward error correperformance when compared to normal convolutional encoding of similar overall compleBecause turbo-coding requires interleaving over more than several hundred bits to realpotential, it is only suitable for higher data rates (where it interleaves over multiple framAdditionally, the forward Fundamental and Supplemental Channels for Radio Configurat3

RC3 and higher have incorporated a Fast Forward Power Control (FFPC) mechanism compto the reverse link. The incorporation of FFPC goes some distance to mitigating theperformance of the forward link under slow speed conditions. Conversely, since FFPC is a cloop mechanism, there is an interference burden absorbed by the reverse link with the introdof the new Reverse Pilot Channel with its embedded Power Control sub-channel.It is anticthat FFPC will also reduce the soft and softer handoff factors.

A variety of sources are available to study the forward and reverse IS-2000 channel structudetail. What follows is a brief list that highlights significant aspects of the technology that relaRF system design and the sizing of BTS components.

• The base or “fundamental” channel for an IS-2000 packet data call may be eitFundamental Channel (FCH) or a Dedicated Common Control Channel (DCCOne of the significant advantages in using the DCCH is that it transitions inmode of operation termed Discontinuous Transmission (DTX) when idling. Inmode, instead of transmitting eighth-rate frames, as the FCH does, the Dtransmits only the Forward Power Control Sub-channel; thereby reducinginterference generated by the channel while idling. Within NetPlan, the ConChannel Mode parameter, accessed while in the time-sliced simulation modepermit for selecting between the use of FCH or DCCH. (In the balance ofdocument, the term FCH will be used generically to refer to both the FCH andDCCH.)

3. The IS-2000 term Radio Configuration (RC) is comparable to the IS-95 term Rate Set (RS). It defines thtraffic channel transmission formats that are characterized by physical layer parameters (e.g. modulaticharacteristics and transmission rates).

N Data Rate (bps)9600 bps

-------------------------------------=

Walsh LengthFwd RC 4128N

---------= Walsh LengthFwd RC 364N------=,


A4


D,

ard). Forthreeentedt” ofthe

ducess andversehich

-95Bg theents.g theore2.

andationsrted

• Although Motorola’s implementation of IS-95B did not include reverse link HSPthe implementation of IS-2000 will include reverse link HSPD.

• IS-2000 permits for defining a Reduced Active Set (RAS) for both the forwsupplemental channel (F-SCH) and the reverse supplemental channel (R-SCHexample, a personal station may be employing an active set composed ofsectors. If a supplemental channel assignment were made, it could be implemin the same active set of three sectors, but it may employ a “reduced active seonly 1 or 2 of the sectors. The decision to exclude one or more sectors fromactive set is based on measurements and optimized thresholds. RAS reprocessing and equipment overhead by minimizing the connections to sectorsites required to support high speed data transmissions. Forward and ReSupplemental Channel parameters permit for specifying a RAS Pilot Offset wwill be used to limit which sectors will be included.

• The IS-2000 F-SCH and R-SCH are shared resources as opposed to the ISimplementation which dedicates the SCH resources to one user. Schedulinresources into time-slices leads to a more efficient use of the channel elemForward and Reverse Supplemental Channel parameters permit for specifyintime-slice interval as well as other parameters which impact SCH allocation. Minformation concerning IS-2000 SCH allocation will be found in Section A4.1.3.

• In Table A4-1, Table A4-2, and Table A4-3, the encoding rate, Walsh length,number of channel elements needed for various data rates and radio configurare provided. NetPlan will support the simulation of all data rates initially suppoby Motorola infrastructure.

Table A4-1: Forward RC3 and RC4

DataRates(kbps)

Forward RC 3 Forward RC 4

Conv.Encoding

Rate

WalshLength

ChannelElements

Conv.Encoding

Rate

WalshLength

ChannelElements

9.6 1/4 64 1 1/2 128 1

19.2 1/4 32 2 1/2 64 1

38.4 1/4 16 4 1/2 32 2

76.8 1/4 8 8 1/2 16 4

153.6 1/4 4 16 1/2 8 8

307.2a

a. A data rate of 307.2 kbps is not initially supported by the Qualcomm mobile stationchipset. Consequently, neither the infrastructure nor NetPlan will support this featureinitially.

- - - 1/2 4 16


A4


Table A4-2: Forward RC5a

a. This table assumes 20 ms frames. The use of 5 ms frames (an option for forward RC5 per IS-2000) is not supported.

Data Rates(kbps)

Forward RC 5

Conv. EncodingRateb

b. This includes the deletion of 1 of 3 repeated symbols to achieve the proper modulationsymbol rate.

Walsh Length Channel Elements

14.4c

c. For Forward RC5, only a FCH or DCCH at 14.4 kbps is supported (initially in NetPlanVersion 6.0.3). No RC5 F-SCH is implemented.

1/4 64 1

28.8 1/4 32 2

57.6 1/4 16 4

115.2 1/4 8 8

230.4 1/4 4 16

Table A4-3: Reverse RC3 and RC4a

a. This table assumes 20 ms frames. The use of 5 ms frames (an option forreverse RC 4 per IS-2000) is not supported.

DataRates(kbps)

Reverse RC 3 DataRates(kbps)

Reverse RC 4

Conv.Encoding

Rate

ChannelElements

Conv.Encoding

Rateb

b. This includes the deletion of 1 of 3 repeated symbols to achieve the propermodulation symbol rate.

ChannelElements

9.6 1/4 1 14.4c

c. For Reverse RC4, only a FCH or DCCH at 14.4 kbps is to be supported(initial in NetPlan Version 6.1). No RC4 R-SCH is implemented.

1/4 1

19.2 1/4 1 28.8 1/4 1

38.4 1/4 2 57.6 1/4 2

76.8 1/4 4 115.2 1/4 4

153.6 1/4 8 230.4 1/4 8


A4


romps orradioanneloteds (oreedte of4 is

ents.

onending

cationn ofkbps,hipair of

rwarddata

alsh2000

) inCDMAet data(RLP)twork

lectortion) andh thelower

) canrwardsed to

• With respect to channel elements, IS-2000 is comparable to, but different fIS-95B. Whereas IS-95B achieves higher data rates by concatenating 9.6 kb14.4 kbps supplemental channels onto a fundamental channel, IS-2000configurations 3 and higher can modulate one high-speed supplemental chcapable of rates up to 153.6 kbps and higher. Although this is true, it should be nthat from a physical channel element perspective, multiple channel element“modulator resources”) are still required to implement the single high-spsupplemental channel. For example, in Table A4-1, it is shown that a data ra153.6 kbps is supported with 16 channel elements in RC3. Note, also, that RCmore efficient in that it can support the same data rate with only 8 channel elem

• With respect to Walsh codes (forward channels only), IS-2000 will assignWalsh code per F-SCH. These Walsh codes may be shorter than 64 chips depeon the data rate. The higher the data rate, the shorter the Walsh code. The alloof one shorter length Walsh code will, effectively, be the same as the allocatioseveral contiguous 64 chip Walsh codes. For example, one RC3 F-SCH at 38.4will be assigned a 16 chip Walsh code which will effectively consume four 64 cWalsh codes. RC4 uses 128 chip length Walsh codes. The assignments of a p128 chip Walsh codes is equivalent to one 64 chip Walsh code.

• Forward RC3, with an encoding rate of 1/4, generates less interference than FoRC4, with an encoding rate of 1/2. Nevertheless, it is believed that the potentialcapacity of Forward RC3 is Walsh code limited. Consequently, due to its Wcode and channel element efficiencies, Forward RC4 is recommended for IS-data applications.

A4.1.2 Power Control

The introduction of a Packet Inter-Working Unit (IWU) [Packet Data Serving Node (PDSNG16.0+ architecture], connected to the XC subsystem, serves as a gateway between thecellular network and the land side IP packet networks. The successful transmission of packover-the-air in the presence of frame erasures is brought about by the Radio Link Protocolwhich retransmits data when errors are detected. The RLP function is implemented on the neside in the Data XCDR card for IS-95B HSPD and on the Packet Subrate Interface - SeDistribution Unit (PSI-SDU) for IS-2000 HSPD in G16.0. The personal subscriber staterminates the RLP on the subscriber side. As a result of the Power Control Bits (PCBsignalling messages being transmitted only on the fundamental channel combined witfunctionality of the RLP, supplemental data channels can tolerate a higher FER target (orEb/No targets), when compared to a voice channel.

A4.1.2.1 IS-95B Power Control

For IS-95B, some of the forward power control parameters (StepUp, MaxGain, and NomGainnow be set on a per service option basis allowing data and voice channels to have different fopower control parameters and thereby establish different FER targets. Scale factors are u


A4


r theh Ratereduces of aTCHnt inctivity

bother thee, the

-95Brue alsotionsieldsbility

S-95n theCH/d the, usedpilot

2000ata,is

n 7,ure

ds thecriber

everse-FCH

s willH andannel

scale down the Maximum and Nominal Traffic Channel (Max and Nom TCH) gain settings fofundamental channel and supplemental channels for various different service options. BotSet 1 and Rate Set 2 supplemental channels have default scale factors which significantlythe Max and Nom TCH gain settings as compared with the Max and Nom TCH gain settingvoice channel. As a result of the RLP function, higher FER targets, and the scaled downgains, an individual supplemental channel should produce a lower power requiremecomparison to a voice channel under the same environment and equivalent voice/data afactor conditions. [Note: For IS-95B HSPD, NetPlan applies a single FER target forfundamental and supplemental channels. Consequently, it should be set to reflect eithweighted combination of fundamental and supplemental channel targets or, best cassupplemental channel target alone.]

A4.1.2.2 IS-2000 Power Control

For IS-2000, the key observation made in Section A4.1.2.1 above, with regards to ISsupplemental channels being able to tolerate higher FER as a consequence of the RLP, is tfor IS-2000 supplemental channels. It should be noted that IS-2000 forward radio configura3 and up employ an improved Fast Forward Power Control (FFPC) mechanism which yreduced interference and improved capacity especially with regards to pedestrian or low motraffic. FFPC includes closed loop operation with inner and outer loops comparable to Ireverse power control. Forward link power control inner loop operation is performed betweesubscriber unit and Base Transceiver Station (BTS) for the forward link traffic channel (F-FDCCH, and F-SCH). The subscriber unit sends forward link power control bits to the BTS, anBTS adjusts its transmission power accordingly. The reverse link power control subchannelsto convey the forward power control bits, are embedded in the newly implemented reversechannel (R-PICH), where 1/4 of the R-PICH bandwidth is allocated for this purpose. For IS-voice, FPC_MODE = 000 will provide a 800 Hz PCB for the F-FCH. For IS-2000 packet dprotocol revision 6, FPC_MODE = 001 will provide a 400 Hz PCB for the F-DCCH whichmultiplexed with a 400 Hz PCB for the F-SCH. For IS-2000 packet data, protocol revisioFPC_MODE = 110 will provide a 400 Hz PCB for the F-DCCH multiplexed with a 50 Hz ErasIndicator Bit (EIB) for the F-SCH.

The forward link power control outer loop resides on the subscriber unit, but the network sentarget FER as well as outer loop initial, minimum, and maximum thresholds down to the subsunit through the Extended Channel Assignment Message (ECAM).

The reverse link power control mechanism undergoes less change than the forward. For RRC3 and up, the channel element will measure chip energy on the R-PICH rather than the Ras is done with IS-95. The feedback provided on the forward link power control subchannelbe used by the subscriber unit to adjust powers on all reverse traffic channels (R-FCH/DCCR-SCH). The outer loop setpoint will be established by the PSI-SDU and sent down to the chelement in every forward packet frame (i.e. once every 20 msec).


A4


users.apacity, only a

rithm

ce andess RFs beingy varymental

ents ass) or

ded RFnnel.SPDitted).

entation

maysivelyn a perand

settingrce thennelslocatedthe

ce andusers,

or therticularradationon for

A4.1.3 Supplemental Channel Allocation

The algorithms that manage supplemental channel allocation seek to protect voice and dataThe allocation strategy attempts to assign supplemental channels only if excess RF carrier cis detected as being available. When excess RF capacity is assessed as being unavailablefundamental channel will be assigned. Section A4.1.3.1 will discuss the SCH allocation algofor IS-95B. Section A4.1.3.2 will discuss the SCH allocation algorithm for IS-2000.

A4.1.3.1 IS-95B Supplemental Channel Allocation

The algorithm that manages IS-95B supplemental channel allocation seeks to protect voidata users. The allocation strategy attempts to assign supplemental channels only if exccarrier capacity is detected as being available. When excess RF capacity is assessed aunavailable, only a fundamental channel will be assigned. As a result, a HSPD request mabetween zero and four RS2 supplemental channels or between zero and five RS1 supplechannels.

The determination of excess RF capacity is based on an analysis of Pilot Ec/Io measuremreported by the personal station in either Pilot Strength Measurement Messages (PSMMOrigination/Page Response messages (IS-95B subscribers only). For example, a heavily loacarrier is likely to honor the request for HSPD service but only assign the fundamental chaConversely, during lightly loaded periods in areas with good Ec/Io conditions, a request for Hservice is likely to receive some number of supplemental channels (up to the maximum perm

A detailed description of the Ec/Io allocation mechanism will not be provided in this documexcept to mention an important parameter that highly influences the results of the Ec/Io allocmechanism. This offset parameter is termed, within the infrastructure, “CBSCPKTECIO”. Italso be known as the “Aggressiveness Knob”. This parameter affects how aggressupplemental channels are allocated. Within the infrastructure, the offset parameter is set oCBSC level. [Note: NetPlan identifies this parameter by the term “IS-95B Packet Ec/Io Offset”implements it to be set on a per system design or system analysis level. It does not allow theof this parameter on a per CBSC level.] Extreme adjustments of the offset parameter can foEc/Io allocation mechanism to produce the maximum number of supplemental cha(parameter is set too high) or zero supplemental channels (parameter is set too low) being alall of the time. An extreme setting can basically disable the functionality and intent ofallocation mechanism. Since the mechanism is intended to protect the performance of voidata users from being affected by a bulk of supplemental channels from one or more dataadjustments to the offset parameter should be made cautiously. Too high of a setting fparameter may cause an overly aggressive allocation of supplemental channels for a paarea, which may produce an excessive amount of interference and cause performance degfor the local voice users, in addition to causing self interference and performance degradatithe data user as well.

Note: For more details regarding the functionality of the Ec/Io allocation mechanism, referto the Cellular Application Note on High Speed Packet Data FR1145.


A4


d may

ervice(e.g.rted,

r RS2

nelsstem

ectorntaln a

rrierof

or dataanyannels

onorlightly

ith ariencen justental

ed in

annelcket

e

In addition to the Ec/Io allocation mechanism, the number of supplemental channels assignealso depend upon the following:

• Number of supplemental channels as determined by such factors as the soption (e.g. applications such as voice, data, or facsimile) and multiplex optiondefining frame format, the maximum number of supplemental channels suppoand the rate decision rules)

• No more than 5 supplemental channels for RS1 or 4 supplemental channels fo

• Per CBSC, operator configurable maximum number of supplemental chan[Note: NetPlan sets the maximum number of supplemental channels at a sylevel. It does not allow the setting of this maximum limit on a per CBSC level.]

• Per Sector/Carrier maximum number of supplemental channels for each sinvolved in the call [Note: NetPlan sets the maximum number of supplemechannels at a system level. It does not allow the setting of this maximum limit oper CBSC level.]

• Maximum number of channel elements available for allocation to that Sector/Cafor all sectors involved in the call [Note: NetPlan does not limit the allocationchannel elements.]

All sectors active in the data call must have the same number of supplemental channels. Fcalls that are in soft handoff with multiple cells/sectors, the system will allocate as msupplemental channels as it can while maintaining the same number of supplemental challocated to each sector involved in the call.

A4.1.3.2 IS-2000 Supplemental Channel Allocation

The determination of excess RF capacity is based on an analysis of Pilot Ec/Ior4 measurements asreported by the BTS RF Load Manager. For example, a heavily loaded RF carrier is likely to hthe request for HSPD service but only assign the fundamental channel. Conversely, duringloaded periods, a request for HSPD service is likely to receive a supplemental channel whigher data rate (up to the maximum permitted). As a result, a IS-2000 HSPD call may expedata bursts that vary in over-the-air data rates of between 9.6 kbps or 14.4 kbps, whetransmitting via the fundamental channel, and 153.6 kbps, when the maximum supplemchannel data rate is assigned.

A detailed description of the supplemental channel allocation mechanism will not be providthis document. The following highlights key elements of the allocation process:

1. The SDU is responsible for determining whether to request a supplemental chand, if so, at what rate. The SDU monitors the total buffer (SDU plus PCF [Pa

4. Pilot Ec/Ior is the ratio of the pilot power (Pilot Ec) to the total transmit power (Ior) as measured at the basstation antenna connector.


A4


fterrm ahave

ufferte atend,rate

iberion isssibleof thethe

ardtheced

leg).it fore

theatingithin

adrate,fy thearrier.nelverse

singCH

thect ofestedthein (ordingisthe

an or

Control Function]). If the total buffer size exceeds a minimum threshold, acompensating for any pending assignments, then the SDU scheduler will perforate calculation and generate a SCH request to the BTS. The rate calculation willthe goal of determining a supplemental channel data rate which will clear the bwithin one time-slice while accounting for the base channel throughput and the rawhich data is flowing into the buffer. Please note that whenever there is data to sthe SDU keeps transmitting on the base channel (i.e. FCH/DCCH). The datacalculation will be limited by some maximum value determined from the subscrdatabase or as a result of service negotiation. This process of rate determinattermed Rate Matching. It does not automatically seek to assign the highest porate; rather, it seeks to determine what rate is required given the characteristicsspecific download. When using the time-sliced simulation mode within NetPlan,user can specify the minimum threshold used to trigger a SCH request.

2. Another task performed by the SDU is RAS determination. The SDU will use forwlink Ec/Io data (from PMRMs) or reverse pilot Ec/Io and RSSI estimates (fromMCC) to identify those legs which are strong and should be included in the reduactive set (i.e. whose signal strengths fall within an offset threshold of the bestWithin NetPlan, Forward and Reverse Supplemental Channel parameters permspecifying a RAS Pilot Offset which will be used to limit which sectors will bincluded in the reduced active set.

3. In contrast to the Per-Handoff SCH allocation technique employed with IS-95B,IS-2000 On-Demand SCH allocation technique shares the SCH resource by allocbandwidth upon demand, as resources are available and within time-slices. Wboth the infrastructure and NetPlan, the time-slice interval can be user specified.

4. At the BTS, the time-slice manager (TSM) works in conjunction with the RF LoManager (RFLM) and the Cache Manager (CM) to determine whether, or at whatthe request may be handled. A number of resources must be available to satisrequest. The RF Load Manager gauges the most important resource, the RF cThe Cache Manager will verify the availability of all other resources; namely, chanelements, backhaul, Walsh codes (forward only), and decoder resources (reonly).

The RF Load Manager reports periodically on the current loading of the carrier uforward pilot Ec/Ior and reverse noise rise metrics while subtracting out any Sloading. These measurements come from the BBXs (BTS transceivers) andchannel elements. At the TSM’s request, the RFLM also estimates the impaimplementing a supplemental channel for a particular base channel at the requrate and all possible lower rates. The RFLM reports this in the form of a delta toEc/Ior measurement. The estimate is based on a rolling average of the forward gareverse power) of the DCCH as well as the radio configuration, data rate, and cotype (turbocoding or convolutional). An admission policy for the RF carrierestablished based on loading thresholds for both the forward pilot Ec/Ior andreverse noise rise. A SCH allocation is made for the highest possible rate, less th


A4


re isiredodes, or

thatersonaleleasen mustof the

stationta to

en it

eachn ofo thed in

a callto beental

mentaletes its

entaluiringervedcurrentbursty

thenefitsources

equal to the requested rate, given that the admission policy is met (i.e. thesufficient RF carrier capacity) and the CM is able to allocate all other requresources. Within NetPlan, the CM is modeled only with regards to Walsh cassignments. There is no blocking of channel elements, decoder resourcebackhaul.

Within NetPlan, the Ec/Ior and reverse noise rise thresholds are inputs.

A4.1.4 RF Channel Utilization

With HSPD, the efficiency of RF channel utilization exceeds that of circuit switched data inthe fundamental channel and supplemental channels are released when inactivity of the pstation is detected and the data session is placed into a “dormant” mode. As part of the rprocedure, the base station sends the personal station a minimum time the personal statiowait before attempting to access the system to transfer packet data again. The transitionpacket data session from dormant to active mode can be initiated from either the personalor the network. The personal station will initiate packet data active mode when it has datransfer or when it needs to perform a registration. Conversely, the network will initiate whhas data to send to the subscriber.

A4.1.4.1 IS-95B RF Channel Utilization

For IS-95B HSPD, RF channel utilization efficiency is also affected by handoff events. Withhandoff event during the life of a mobile data call, the system will reevaluate the allocatiosupplemental channels, via the supplemental channel allocation algorithm according tnew Ec/Io conditions at the time of the handoff (as well as the other factors mentioneSection A4.1.3.1: "IS-95B Supplemental Channel Allocation").

Once the system has allocated the supplemental channel resources for a call (i.e. fromorigination, a dormant to active mode transition, or from a handoff event), and data is readysent, the system has the ability to gradually increase (ramp up) the number of supplemchannels that are actually being used to send the data, up to the maximum number of supplechannels for which resources have been previously allocated. Once the buffer of data compltransmission, the system will also gradually decrease (ramp down) the number of supplemchannels being reserved for use (i.e. immediately available for data transmission and not reqramp up). In the event that additional data is received in the buffer before the number of ressupplemental channels goes to zero, the system will begin the ramp up process at thenumber of reserved channels. If enabled, this feature may be used to help minimize theeffects of supplemental channel usage on other users.

A4.1.4.2 IS-2000 RF Channel Utilization

For IS-2000 HSPD, the efficiency of RF channel utilization benefits from transitions intodormant state as has been stated for IS-95B HSPD. Additionally, the IS-2000 functionality befrom superior channel efficiency due to both the time shared use of supplemental channel res


A4


s of the

packetber andand alsoction

em. Infor thehe linke sites.

usefulodeled, FERdow in

thed thus

arious

f this

-95B, and

ed. Ithat arelinko, the

and the on-demand nature of the allocation process which serves the high-speed data needsubscriber as those needs transpire.

A4.2 Link Budget Considerations

As in a voice subscriber system design, the first step in designing a system for high speeddata subscribers is to create the RF link budget to model the path between the data subscrithe base station. The link budget establishes the design parameters that are used in NetPlandetermines the maximum allowable path loss. This maximum allowable path loss, in conjunwith a propagation model, can be used to estimate the coverage of the cell.

The process for creating a link budget for a data system is the same as for a voice systsystems that are comprised of only data subscribers, a link budget with specific parametersdata subscribers should be used. In systems with a mix of voice and data subscribers, tbudget that represents the limiting case should be used in determining the separation of th

When adding HSPD users to an existing system designed for voice, the RF link budget isfor capturing the differences that exist between the various subscriber classes that will be mwithin the NetPlan simulation. These subscriber class differences include the activity ratecriteria, and penetration losses. These values are set within the Subscriber Class Editor winNetPlan.

If the design is for a new system, then the RF link budget will be useful in determiningmaximum allowable path loss, which can then be used to estimate the range of the cell site anprovide an initial estimate of the separation distance between sites.

Differences between a RF reverse link budget for voice and one for data may exist due to vreasons. The following subsections highlight the link budget differences that could exist.

(Further details regarding the RF link budgets parameters can be found in Chapter 2 odocument and in the “CDMA/CDMA2000 1X RF Planning Guide”, Chapter 4.)

A4.2.1 IS-95B Link Budget Considerations

In the following subsections, differences in link budget considerations between voice and ISdata will be highlighted in the following categories: subscriber unit, base receive sensitivityinterference margin.

A4.2.1.1 Subscriber Unit

In order to take advantage of HSPD, new subscriber units that support IS-95B will be requiris assumed that the subscriber units’ physical characteristics will be the same as those tcurrently used for voice. If a different device is used for data than for voice, the followingbudget parameters would need to be visited to determine if there are differences, and if sappropriate values to use.


A4


rrieritivityieve ain more

e set(s)set istPlanyond,differion one forpacketer Rate

on oneave thea RS2e RS2

rs. Thegether

ay beay bemore

udget.itivitydule,

00.

• subscriber transmit power

• subscriber antenna gain

• subscriber antenna line loss

This information concerning subscriber differences is equally applicable to IS-2000 HSPD.

A4.2.1.2 Base Rx Sensitivity

The base receiver sensitivity is comprised of the thermal noise level for the RF ca(-113.1 dBm), and the noise figure of the base station. Additionally, the base receiver sensused for a CDMA system design is adjusted to take into account the required Eb/No to achparticular FER and the processing gain afforded by the rate set. These factors are discusseddetail below.

A4.2.1.2.1 Rate Set5

A factor that affects the values of several parameters in the link budget is the rate set. The ratthat will be used in the system will need to be known before beginning the design. The ratementioned here, not because it is different for data than for voice, but because prior to NeVersion 4.0 only one rate set could be simulated at a time. With NetPlan Version 4.0 and beone is able to model various subscriber classifications in which one of the parameters that canbetween subscriber classes is the rate set. (Refer to Section 6.2.2.4.1 for further discusssubscriber class definitions.) All of the currently available service options, whether they arvoice, fax, or data, have as their basis either Rate Set 1 or Rate Set 2. For IS-95B high speeddata, the fundamental data channel and supplemental channel(s) could be based upon eithSet 1 (9.6 kbps) or Rate Set 2 (14.4 kbps).

For a mixed voice and data system, the operator could potentially have voice service basedrate set and data service based upon a different rate set. For instance, the operator may hvoice service provided by RS1 EVRC (9.6 kbps), whereas the data service could be based on(14.4 kbps) channel. If a new system was being designed for this case, one should use thvalues in generating the RF reverse link budget to minimize coverage holes for the data useRS1 voice users would have extra margin since the sites would have been placed closer toto accommodate the RS2 design.

If there is an existing RS1 voice system to which one wishes to add RS2 data, then there mcoverage holes and the performance/capacity of the data user may be diminished. This macceptable to the operator if there is very little expected data traffic, as opposed to addingsites to improve the performance for the few data users.

The rate set choice impacts the processing gain and Eb/No parameters within the RF link b(Refer to Section 2.4.5 of this procedure for more information regarding base receiver sensand Eb/No.) More detailed design phases, which use the NetPlan CDMA Simulator mo

5. Rate Set 1 and Rate Set 2 are referred to as Radio Configuration 1 and Radio Configuration 2 in IS-20


A4


rate set,led.

e valueing thersions

s thend datad alongtagef 10%

e (%)"nded

o byld bebudget

ouldte site

essaryetailedctivitycan be

needcertainals and

la did), theverse

atedill be

incorporate Eb/No values. These are obtained from a set of curves based upon the speed,delay spread, and FER outage criteria that are characteristic of the subscriber being mode

Since the processing gain is tied to the selected rate set, there is no difference between ththat would be used for voice and the value that would be used for data, assuming both are ussame rate set. It is only mentioned here due to the fact that NetPlan Version 4.0 and later veallow individual subscriber classes to be assigned as either RS1 or RS2.

A4.2.1.2.2 FER Outage Criteria

For voice systems, the power required to achieve the Eb/No target varies dynamically asubscriber moves around. There may be a difference between the Eb/No targets for voice abecause the data user may be able to sustain more errors and thus allow the call to proceeat a higher FER criteria. For instance, the target FER for voice is typically set to 1% with an ouof 3%. For data, a target FER of 3% and an outage of 6% or a target of 5% and an outage omay be used by the designer. (Refer to Section A4.3.4.3, "FER Target (%) and FER Outagand Note 3 for Section 6.2.2.4.1, Figure 6-12, for more information concerning the recommeFER levels for various service options.)

By changing the FER outage from 3% to 6%, one could reduce the required Eb/Napproximately 1 dB. To further reduce the FER outage to 10% (from 6%), the Eb/No coureduced by another 1 dB. These are only approximations to be used in the RF reverse linkto arrive at a maximum path loss value. A propagation model, along with the path loss value, wthen be used to approximate the radius of a cell site and from this determine the approximaseparation initially anticipated. The detailed design using NetPlan would determine the necEb/No to meet the FER requirement based upon the subscriber environment. From the ddesign, which takes into account the various subscriber characteristics (speed, location, afactor, etc.), a more accurate representation of the site radius and separation between sitesfound.

Selecting the FER criteria is not just for determining the Eb/No value to use, other factors alsoto be considered. For instance, there may be some contractual issues involved that require aFER level or a certain data throughput requirement. One needs to appreciate their design goset their FER criteria accordingly.

This information concerning FER outage criteria is equally applicable to IS-2000 HSPD.

A4.2.1.3 Interference Margin

The interference margin is based on the amount of users on the reverse link. Since Motoronot implement high speed packet data on the reverse link (only a single channel is utilizedimpact due to higher data rates will have minimal, if any, effect on the interference margin (rerise).

The reverse data activity factor that is chosen will have an impact upon the approximinterference margin. As the data activity factor increases towards 100 percent, there w


A4


voicedataser isdata

pe of, then

ear tortherdel

tivityd beto thef thedata

e ther (for

. Theseunning

cedakes-95A/mmusen,hanwill

n (thection

mustnels.et.

additional noise on the system and thus the interference margin would be greater. Forsystems, the voice activity factor is typically selected to be 40%. With a data system, theactivity factor may be greater or less depending upon the data application and how the uutilizing the application. For instance, if the data user is uploading a file, it is possible that theactivity factor may appear as 100% for the duration the file is being transferred. Another tyapplication may see the user requesting a piece of information, then waiting for a responsedeciding what to do next, and then requesting another piece of information. This would appbe more like a conversation in that one person talks, then listens, then will talk again. Fudiscussion on the activity factor will be provided in Section A4.3.4: "Translation of Call MoInformation into Simulation Parameters".

For the initial RF reverse link budget, the interference margin can be reduced if the data acfactor is less than the typical voice activity factor of 40%. The interference margin shoulincreased for data activity factors that are greater than 40%. The actual dB changeinterference margin is difficult to predict, since the interference margin is also a function oamount of traffic. As a starting point, if one assumed 3 dB interference margin for voice, auser with less than a 40% activity factor (for instance, between 20% to 40%) could havinterference margin reduced by 0.5 dB. For a data user with greater than a 40% activity factoinstance, between 40% to 80%), the interference margin should be increased by about 2 dBare crude estimates. Rise statistics for a specific design scenario can be obtained by rNetPlan simulations.

A4.2.2 IS-2000 Link Budget Considerations

The key differences associated with a IS-2000 link budget are the following:

• reverse link Eb/NoThe reverse link Eb/No requirements for a IS-2000 voice or data call are influenby several factors. The introduction of the Reverse Pilot Channel (R-PICH) mpossible a coherent detection that reduces the Eb/No requirement relative to ISB (Qualcomm CSM chipset). The improvement for IS-2000 using the QualcoCSM5000 chipset is comparable to what was achieved with IS-95A/B with theof Motorola’s EMAXX chipset. In addition to the benefits of coherent detectiosupplemental channels will benefit from the use of turbo-coding, rather tconvolutional coding, and the application of higher FER targets. Both of thesereduce Eb/No requirements.

• processing gainHigh-speed supplemental channels will experience a reduced processing gairatio of bandwidth to data rate). For 19.2, 38.4, 76.8, and 153.6 kbps, the reduin processing gain will be 3, 6, 9, and 12 dB, respectively.

• subscriber unit transmit powerWhenever supplemental channel transmission is occurring, the subscriber unitnow distribute the power among both the fundamental and supplemental chanThis reduction in subscriber unit transmit power will also impact the link budg


A4


to thethe

ents,or

gain,t theowerbps,

Since itwardEb/Nond low

a (e.g.tions.

ct therationsmentalstated,etershich

meter,designd and

The amount of power needed to support the supplemental channel is relatedoverall impact of changes in the processing gain and Eb/No betweenfundamental and supplemental channels. The delta in the Eb/No requiremrelative to the fundamental channel, is on the order of a 3 dB reductionimprovement. When this is applied as an offset to the delta in the processingwhich itself is a reduction (and not an improvement), it can be observed thasupplemental channel requires approximately 0, 3, 6, and 9 dB additional prelative to the fundamental channel to support 19.2, 38.4, 76.8, and 153.6 krespectively. Or, as a linear factor, 1, 2, 4, and 8 times, respectively.

In general, as the data rate increases, the maximum path loss and cell radius will decrease.is anticipated that high speed data applications will be forward link centric and since the forlink has a link budget advantage over the reverse link (e.g. greater average power, reducedrequirements), a design strategy could balance reverse link coverage assuming only voice aspeed data (e.g. 9.6 kbps or 19.2 kbps) while still achieving good forward link high speed dat76.8 kbps). Refer to Chapter 2 of this document for greater detail on the link budget considera

A4.2.3 General HSPD Design Considerations

The following lists some simulation input parameters and how altering their values can impasimulation statistics (CellStat and MobileStat). These items relate to general design consideand are not specific to HSPD. However, each can have an impact upon the number of supplechannels that may be assigned to a HSPD user. It should be pointed out that the impacts, asonly apply if the specified parameter is the only parameter being modified. If several paramare being modified concurrently, then the resulting statistics may vary based upon wparameters were altered and upon the specific scenario under investigation.

Note that the impacts listed below are general expectations of changing a specific input parawhile holding other variables constant. There may be various characteristics of a systemwhich will produce results opposite to these. It is up to the system designer to understanjustify the results.


A4


ved.and

mandFERthe

usernnelsSupp

, on

w, on

ved.e lesss PAeby

), thes but

pportpacityater

95Bandbeing

gs

Number of Erlangs:

• An increasein the number of Erlangs implies that there are more users to be serThe increased number of users will generate more reverse link noise risedemand more PA power from the BTS. Due to the increase of noise rise and defor more PA power, there will be more instances where the target/outagecriteria will not be met, thereby resulting in a lower PcntMobGood statistic inCellStat files.

Since more resources are required to support the additional users, the HSPDmay be assigned less than the maximum allowable number of supplemental chain more areas of the system as the number of Erlangs increases. Thus, the Numstatistic in the MobileStat files for IS-95B HSPD subscriber class(es) may showaverage, fewer supplemental channels being assigned.For IS-2000 HSPDsubscriber class(es), the FwdDataRateSCH and RevDataRateSCH may shoaverage, fewer supplemental channels being assigned.

• A decreasein the number of Erlangs implies that there are fewer users to be serThe reduced number of users will create less reverse link noise rise and requirPA power from the BTS. Due to the decrease of noise rise and demand for lespower, it is more likely that the target/outage FER criteria can be met, therresulting in a larger PcntMobGood statistic in the CellStat files.

For some situations (for example, coverage holes or small number of ErlangsPcntMobGood value may not increase with a decrease in the number of Erlangmay actually decrease.

With a decrease in the number of Erlangs, resources can now be used to susupplemental channels instead of other users (assuming the system is not calimited). For this situation, the NumSupp statistic may show, on average, a grenumber of supplemental channels (up to the maximum allowed) for the IS-HSPD user.For IS-2000 HSPD subscriber class(es), the FwdDataRateSCHRevDataRateSCH may show, on average, greater supplemental channelsassigned.

• Parameter is set inConfigure>Simulation Parameters>CDMA>Subscribers>Total Number of Erlan


A4


henoisese tondtagein

portwableSuppow,

hee andse towd.et,

), themay

pportr this

er ofr.

oveichn the

r to

Voice Activity Factor (%), Fwd. and Rev.:

• An increase in the activity factor implies that the users are transmitting on tchannel resource longer. This increased use will generate more reverse linkrise (increase to the Rev. Activity Factor) and demand more PA power (increathe Fwd. Activity Factor) from the BTS. Due to the increase of noise rise ademand for more PA power, there will be more instances where the target/ouFER criteria will not be met, thereby resulting in a lower PcntMobGood statisticthe CellStat files.

With an increase to the Fwd. Activity Factor, more resources are required to supthe user and the HSPD user may be assigned less than the maximum allonumber of supplemental channels in more areas of the system. Thus, the Numstatistic in the MobileStat files for the IS-95B HSPD subscriber class(es) may shon average, fewer supplemental channels being assigned.

• A decreasein the activity factor implies that the users are transmitting on tchannel resources less. This reduced use will create less reverse link noise risrequire less PA power from the BTS. Due to the decrease of noise rise (decreathe Rev. Activity Factor) and demand for less PA power (decrease to the FActivity Factor), it is more likely that the target/outage FER criteria can be mthereby resulting in a larger PcntMobGood statistic in the CellStat files.

For some situations (for example, coverage holes or small number of ErlangsPcntMobGood value may not increase with a decrease in the activity factor butactually decrease.

With a decrease in the Fwd. Activity Factor, resources can now be used to susupplemental channels instead of supporting the longer resource usage. Fosituation, the NumSupp statistic may show, on average, a greater numbsupplemental channels (up to the maximum allowed) for the IS-95B HSPD use

• It should be noted that the activity factor should not just be changed to imprsimulation statistic results. The activity factor is a function of the time during whthe user’s signal is present and therefore the activity factor should be based ocharacteristic of the specific subscriber class being modeled.

• Parameter is set inConfigure>Simulation Parameters>CDMA>Subscribers>Subscriber ClassesEdit>Voice Activity Factor (%), Fwd. and Rev.

• This parameter is not applicable to IS-2000 HSPD subscriber classes. (RefeSection A4.3.4.1 and Section A4.3.4.2).


A4


theEb/Noowerwer,met,

ed itsstem.iberbeinge

eater

TSmentTS.

kelywer

), thetage

ve a

omemeet

be

FER (%), Target and Outage:

• An increaseto the target and outage FER criteria (less stringent) implies thatusers and BTS require less power to achieve the targeted Eb/No. The reducedrequirement will generate less reverse link noise rise and demand less PA pfrom the BTS. Due to the decrease of noise rise and demand for more PA pothere will be less instances where the target/outage FER criteria will not bethereby resulting in a larger PcntMobGood statistic in the CellStat files.

Since less power is required to support the user, the HSPD user may be assignmaximum allowable number of supplemental channels in more areas of the syThus, the NumSupp statistic in the MobileStat files for the IS-95B HSPD subscrclass(es) may show, on average, a greater number of supplemental channelsassigned (up to the maximum allowed).For IS-2000 HSPD subscriber class(es), thFwdDataRateSCH and RevDataRateSCH may show, on average, grsupplemental channels being assigned.

• A decreasein the FER criteria (more stringent) implies that the users and Bdemand more power to achieve the target Eb/No. The increased Eb/No requirewill create more reverse link noise rise and require greater PA power from the BDue to the increase of noise rise and demand for more PA power, it is more lithat the target/outage FER criteria will not be met, thereby resulting in a loPcntMobGood statistics in the CellStat files.

For some situations (for example, coverage holes or small number of ErlangsPcntMobGood value may not increase with an increase in the target and ouFERs but may actually decrease.

• Depending on the values selected, it is possible that the activity factor may hagreater impact on the PcntMobGood statistic than the FER outage level.

• It should be noted that the FER criteria are not to be changed just to meet ssimulation statistic performance levels. The FER values should be set toquality levels of operation and/or to ensure contractual requirements canachieved.

• Parameter is set inConfigure>Simulation Parameters>CDMA>Subscribers>Subscriber ClassesEdit>FER (%), Target and Outage


A4


b/Nogainstemimilar

ionaler ofstic inge, a

users,s the

ch as

ch as

, andsed

FERthe

oodilotowermay

erated

Radio Configuration:

• To achieve similar FER targets, RS1 (9.6 kbps) users require a lower target Ethan RS2 (14.4 kbps) users. This is mainly due to the 1.8 dB processingdifference between the two rate sets. The lower Eb/No target for a RS1 syallows more users to be supported than for a RS2 system, assuming a sPcntMobGood statistic.

• In a RS1 system, instead of using the lower processing gain to support additRS1 users, the HSPD user may be assigned its maximum allowable numbsupplemental channels in more areas of the system. Thus, the NumSupp statithe MobileStat files for the HSPD subscriber class(es) may show, on averagreater number of supplemental channels being assigned.

• If a system starts out with the site placement based on RS1 and then adds RS2the RS2 users (voice or data) will not achieve the same level of performance aRS1 users.

• Depending upon the load, the RS1 reverse good link performance may be as muapproximately 2 dB better than RS2 link performance.

• Depending on the load, the RS1 forward good link performance may be as muapproximately 3 to 5 dB better than RS2 link performance.

• Parameter is set inConfigure>Simulation Parameters>CDMS>Subscribers>Subscriber ClassesEdit>Radio Configuration

Pilot (W):

• An increase in the pilot power (with corresponding increases to the page, syncTCH powers) implies that there is more forward link energy to be used for increacoverage range or to improve the power allocated to meet a given forwardcriteria. Due to the increased PA power, there will be more instances wheretarget/outage FER criteria will be met, often resulting in a higher PcntMobGstatistic in the CellStat files. The available PA size will restrict how much the ppower can be increased, since the increase of power will demand more PA pfrom the BTS. It is also true that in some areas, increasing the power too muchactually cause more harm than good (where too much interference may be genby the increase of power).

• Parameter is set in Edit>Site>Sector/Carrier>Pilot (W)


A4


is theSection

p aftert thisis usedterrainsolved

systemtioncriber.2.4.1

usersto createles thataboutd RS2.

ld forfectivecribercable

e to the

quiredorwarddingSPD,ain datarnings, it is

or thephase.led atthe

A4.2.4 Determining NetPlan Inputs from Link Budgets

The process of using the link budget values to determine the input parameters for NetPlansame regardless of whether the system is comprised of voice or data subscribers. (Refer to2.5 of this procedure for further information.)

A4.2.5 NetPlan Coverage

For a new system design, as was the case in designing voice systems, the next stedetermining the inputs to NetPlan from the link budget is to estimate the system coverage. Astage, the coverage estimate is based only on the maximum allowable path loss. This stepto get a quick determination of major coverage issues such as cell placement problems orobstruction issues. By identifying these issues early in the process, some of them can be rebefore spending the time and effort on running simulation studies.

For an existing system design, this step may be bypassed. Coverage holes from the existingdesign will still be present. Therefore, one could go directly from the link budget to the simulastage. Within the simulation stage, the link budget difference between the various subsclasses would be accounted for in the Subscriber Class Editor window. (Refer to Section 6.2for further details.)

For IS-95A/B, if the existing system was based on RS1 users and now includes RS2(regardless of whether these users are voice or data users), then the designer may desirea coverage estimate based on maximum allowable path loss for the RS2 users. Coverage hoexisted in the RS1 design will likely be increased. In addition, new coverage holes may comedue to the approximately 2.5 dB degradation in the base receiver sensitivity between RS1 an

The link budget is also required to determine the values to be used in the effective gain fieeach sector. For an existing system, the effective gain value would not change, unless the efgain has accounted for some of the differences that would exist between the different subsclasses. Typically, the effective gain only includes the gains and losses for the base stationsystem, base station antennas and the lognormal fade margin. The differences that exist duvarious subscriber characteristics would be included in the subscriber parameters.

In general, this stage of the design uses a reverse link budget to assist in determining the repropagation path loss to be used in NetPlan. However, to complete a system design, the flink must also be analyzed. The forward link budget consists of many variables inclusubscriber speed, location, soft handoff, noise figure, voice activity, and pilot range. With Hanother variable is added, that being additional channels (supplemental) that are used to obtrates higher than 14.4 kbps. A reverse only coverage plot will not provide information concethe average data rate that could be supported in the system. To model all of these variablerecommended that NetPlan simulations be used to analyze the forward link by accounting fstatistical variation in these parameters. Such simulator studies are part of the final designAn additional benefit of the NetPlan simulation is that various subscriber types can be modethe same time. This, in effect, provides the ability to have multiple link budgets modelingvarious subscriber types.


A4


efineian, in-efer to" for

stemons of, theciating(e.g.

eed toEditor,

e Airetersies:

The different RF link budgets are achieved by giving the RF system designer the ability to da different subscriber class for each unique subscriber characteristic (for instance, pedestrvehicle, in-building, low speed packet data user, high speed packet data user, etc.). (RSection A4.4, "Simulation Input Parameters" and Section A4.5, "Simulation Output Analysisfurther discussion on NetPlan simulations.)

A4.3 Call Model

In this section, data calls will be characterized to provide the necessary inputs for CDMA sysimulation. Each such characterization, representing different service options and applicatiwireless data, will become associated with a subscriber class within NetPlan. Additionallypenetration of the various data subscriber classes into the market will be represented by assoa load with each subscriber class. While only some parameters are truly peculiar to dataMaximum Data Rate), all of the parameters will have aspects associated with data which nbe appreciated. The relevant subscriber class parameters, found in the Subscriber Classinclude:

• Forward Activity Factor (%)

• Reverse Activity Factor (%)

• FER Target (%)

• FER Outage (%)

• Air Interface

• Radio Configuration

• Maximum Forward Data Rate

• Call Model

The Call Model inputs are applied when the user is performing time-sliced simulations, thInterface indicates IS-2000 and the Radio Configuration is RC4 data. The Call Model paramare supplied under CDMA Parameters>Data Services>Call Models in the following categor

• Service Type

• Reverse Request Size

• # (Number of) Forward References (Files per Download)

• Forward Reference Size

• Think Time

• Server Delay

• Dormant-to-Reverse Request Delay


A4


screen,

Input

is saidstatea userIn

wsingsmissionebbewill be

ad andsre not

1,

The relevant loading parameters, found under the Subscribers tab of the CDMA Parametersinclude:

• %Erlangs per class & Total ErlangsOR

• Erlangs/Subscriber per class & Number of Subscribers per classOR

• Erlangs per class

For further discussion of the subscriber class parameters, refer to Section A4.4: "SimulationParameters" and Section 6.2.2.4.

A4.3.1 General Attributes of the Data Call Model

When a data user is registered with the IWU/PDSN, the call or session state is said to beOpen.Conversely, when a data user is de-registered with the IWU/PDSN, the call or session stateto beClosed. For the purpose of system simulation using NetPlan Version 6.1, only the Openis pertinent. Within the Open state, there are two modes: Active and Dormant. When the datis on-channel, the mode isActive. In the figure below, the Active mode is depicted as “ChannelUse”. Conversely, when the data user is off-channel, the mode isDormant.6

Figure A4-1: Packet Data Call

To introduce some attributes of the data call model, consider a simple model of a web-brosession. A user requests a web page. The actual request represents a reverse link data tran(i.e. anupload) and will be small. A brief server delay ensues, followed by reception of the wpage (i.e. adownload) in the form of a downlink data transmission. The download may, in fact,a series of tightly coupled downloads all related to the same web page and in the aggregatelarge. The user will now take some time to consider the information (i.e.think time ) beforemaking the next request. A series of such scenarios (including uploads, server delay, downlothink time) would form a packet data call orsession. The figure above shows four data downloadand accompanying think times (i.e. the inactive periods where supplemental channels a

6. The terms Open, Closed, Active, and Dormant are defined in IWF Link Layer Connection States, §1.4.3.of IS-707-A.5, Data Service Options for Spread Spectrum Systems: Packet Data Services.

Channel In Use Dormant DormantChannel In Use

Supplemental Power Off Supplemental Power OffSupp. On On

On

On

Off

Off

Data Data

Packet

Time

20 SecondsInactivity

20 SecondsInactivity


A4


e SCHthe

annel

sizes.e, byhanneldata

ll notntlyeriod(e.g.ad of

erizedtivity

d inficd by

ates".

for ae time

le rate

ket

transmitting and their power is turned off).

In IS-2000, the supplemental channels are shared resources; therefore, the allocation of theschannel element resources to an individual user will be made within time-slices duringdownloading state. This is in contrast to the IS-95B HSPD user, which has dedicated SCH chelement resources allocated to it (as available) even when it is not transmitting.

Within an active period, there may be multiple data transmissions and think times of varyingThe implementation of packet data exploits the think times, which can be appreciable in sizentering into the dormant mode and releasing the channel resources, which improves data cusage efficiency. This active to dormant transition is controlled with a timer that measuresinactivity (currently recommended to be 20 seconds).

The use of terms like “call”, “session”, or “use” permits for ambiguity.7 It is difficult to determinewhen a call/session is ended, with think times varying in length. It is possible that the user wiexplicitly initiate the closure of a session (i.e. a closure of the link layer connection). To efficieuse resources, the infrastructure (IWU/PDSN) will terminate a session when the dormant pexceeds some inactivity timer. In this case, the session close timer is likely to be fairly large10 minutes). A user perspective would characterize the call as ended with the last downlointerest, and for the purposes of simulation, this perspective is most appropriate.

From a data call model perspective, there are two attributes which need to be charactcarefully to serve as inputs into the simulation. The first is the forward and reverse data acfactors. The second is the traffic loading. These two attributes will be discusseSection A4.3.1.1: "Data Activity Factor (IS-95A/B only)" and Section A4.3.1.2: "TrafLoading", respectively. For IS-2000 time-sliced simulations, the data activity is characterizedata call model parameters as discussed in Section A4.3.4.5: "IS-2000 Data Call Model St

A4.3.1.1 Data Activity Factor (IS-95A/B only)

The activity factor (for voice or data) can be defined as the actual data volume transmittedtime period versus the total data that would have been transmitted at full-rate for the samperiod.

[EQ A4-3]

The equation can be expressed in terms of the percent of time spent in each of the variabstates (full rate, half rate, quarter rate, and eighth rate) as follows:

7. Contrary to the practice described here, some parties in the industry refer to each active period as a “paccall”. The fact that each “packet call” generates its own CDL and CDR makes this perspective attractive.

Activity Factor Bits TransmittedMax. Bit Rate Time×----------------------------------------------------=


A4


ludeo theong

nevermentalentalk istinginedale thatthe

ghtedumingwould

mumduresthatdoes

ore

[EQ A4-4]

where %TF = percent of time at full rate, %TH = percent of time at half rate, etc.

Although the activity factor could be defined relative to the entire session (which would incthe dormant periods), it is more immediate and useful to define the activity factor relative tactive period. For voice, the ~40% activity factor was characterized by a distribution amvariable rates specified in the Markov service option.

Data activity may be characterized in a similar fashion. Note that supplemental channels willoperate in half-rate, quarter-rate, or eighth-rate. When there is data to transmit, the supplechannel(s) will burst data at full-rate and when no data is to be transmitted, the supplemchannel(s) will not transmit (although, in IS-95B, they are still allocated). When the downlinidle, connectivity will be maintained only by the fundamental channel which will be transmiteighth-rate frames.When using an IS-2000 DCCH as the base channel, connectivity is maintain the DTX mode (effectively, zeroth-rate frames).In the table above, the IS-95B supplementchannels experience a data activity factor of 36% (which corresponds to the percentage of timit was transmitting). The fundamental channel’s activity factor is slightly higher due totransmission of eighth-rate frames when idle. The composite data activity factor is the weisum of the activity factor for the fundamental channel and any supplemental channels. Asstwo IS-95B supplemental channels for the example above, the composite data activity factorbe 38.7% [i.e. (2 x 36% + 44%)/3].

In IS-95B HSPD, the number of supplemental channels may vary from zero to the maxipermissible during the active period according to the supplemental channel allocation proce(described in Section A4.1.3.1: "IS-95B Supplemental Channel Allocation"). Keep in mindwithin the simulation, the allocation of IS-95B supplemental channels is a static decision andnot vary.

In Section A4.3.4: "Translation of Call Model Information into Simulation Parameters", mdetail relative to the definition of the Data Activity Factor will be provided.

Table A4-4: Voice & Data Activity Factors

Distribution of Time in Variable Rate States

VoiceSupplemental Channel

(example)Fundamental Channel

(example)

Full-Rate 29% 36% 36%

Half-Rate 4% - -

Quarter-Rate 7% - -

Eighth-Rate 60% - 64%

Idle - 64% -

Activity Factor 40.25% 36% 44%

Activity Factor 1 %TF×( ) 0.5 %TH×( ) 0.25 %TQ×( ) 0.125 %TE×( )+ + +=


A4


Callodeltime-the

fd

wouldof the

to theon) oner ofmesntiatey theirmongeted asr). Withcouldith thet callxactlyrlangs

erage

o

When performing time-sliced simulations, IS-2000 data activity will be characterized by theModel inputs and not activity factor inputs. Refer to Section A4.3.4.5, "IS-2000 Data Call MStates" for greater detail concerning these inputs. When performing simulations in the nonsliced mode, the activity factors for IS-2000 data calls are currently hard-coded to 100% inforward and reverse directions.

A4.3.1.2 Traffic Loading

The call load may be defined relative to the entireuseor session or it may be defined in terms othe active period. Please note that it isrequired that the activity factor and the load be definerelative to the same period. For IS-95Band for non time-sliced simulation of IS-2000, it isrecommendedthat the definition be made relative to the active period.For time-sliced simulationsof IS-2000, it isrecommendedthat the definition be made relative to the use or session.Ultimately,the simulation requires that load be represented as Erlangs per subscriber class.

[Note: The Erlang load defined here is a call load and not a channel load. The channel loadbe more appropriate to channelization estimates, but not as an input that defines the loadingdata service.]

Alternatively, the load may be provided as the penetration of a particular subscriber class inmarket, in which case the load is defined as a percent of the total Erlangs (i.e. the penetratia subscriber class basis. Within NetPlan, this load would be defined using the “Mean NumbErlangs” and “% of Class” fields. However, with the introduction of data, this perspective becomore complicated. In the past, the most likely use of subscriber classes was to differesubscribers by either their personal station characteristics (e.g. mobile versus portable) or benvironment (e.g. outdoor versus indoor). There was no implied difference in the call model athe various subscriber classes. Fundamentally, the subscriber classes could be interprmaintaining the same average hold time and call rates (i.e. the same Erlangs per subscribethesevoice onlyassumptions, the penetration of a particular subscriber class into the marketbe characterized equally by referring to either attempts, Erlangs, or subscribers. However, wcurrent intention of defining new classes to represent various data services with differenmodels, it is no longer possible to accept a penetration number without understanding ewhether it is calculated relative to attempts, Erlangs, or subscribers. Anything other than Ewill require translation into Erlangs. These translations are simple.

Penetration relative to attempts is converted into penetration relative to Erlangs via the avhold times8 as follows:

; [EQ A4-5]

8. The average hold time is the appropriate conversion factor since it is the ratio of traffic (i.e. Erlangs) tattempts.

ΓD

βD HD×βD HD× βV HV×+------------------------------------------------= ΓV

βV HV×βD HD× βV HV×+------------------------------------------------=


A4


erator

rlangs

ile the

lsotraffic

g aentireuiredis thatta pers basislume

where:

ΓD, ΓV = fraction of total Erlangs for data and voice, respectively (ΓD + ΓV = 1)

βD, βV = fraction of total attempts for data and voice, respectively (βD + βV = 1)

HD, HV= average hold times for data and voice, respectively

The denominator represents the composite (data and voice) average hold time, while the numrepresents that portion attributable to data or voice.

Penetration relative to subscribers is converted into penetration relative to Erlangs via the Eper subscriber rates as follows:

; [EQ A4-6]

where:

ΓD, ΓV = fraction of total Erlangs for data and voice, respectively (ΓD + ΓV = 1)

SD, SV = fraction of total subscribers for data and voice, respectively (SD + SV ≥ 1)

EPSD = data Erlangs per data subscriber

EPSV = voice Erlangs per voice subscriber

The denominator represents the composite (data and voice) Erlangs per subscriber, whnumerator represents that portion attributable to data or voice. Note that (SD + SV = 1) is not arequirement. SV may equal 100% and SD may represent the fraction of voice subscribers that ause data services. Under these conditions, the data subscribers would have only their datarepresented by EPSD.

If the Erlangs refer to the entireuse, then they are converted to active period Erlangs by usinratio representing the percentage of time that the call was in the active mode relative to theuse. All conversion factors must be specified for each data subscriber class. If the reqconversion factors are not provided, the call model is not complete. One last considerationdata load may now be provided in terms of data volume (e.g. 500 Kilobytes of download dadata subscriber in the busy hour). If the data volume were defined on a per subscriber clasand the Kilobyte-per-Erlang conversion factor for that class were known, then the data voexpressed as bytes or bits can be converted to a load in terms of active period Erlangs.

ΓD

SD EPSD×SD EPSD× SV EPSV×+------------------------------------------------------------= ΓV

SV EPSV×SD EPSD× SV EPSV×+------------------------------------------------------------=


A4


er rate,mit

d userThised in

ental)kbps.it at a

A4-3.ental

missiondue toafficnd vianelsnation

hichlities.iatedA4-6

ectiveo thees thehput,ted toed the

A4.3.2 Data Rates

There are various ways of referring to the rate of transmission. These include: data rate, beareffective throughput, and good-put. A knowledge of these different definitions will pertranslating data volumes (in kilobits or kilobytes) into estimates of load in Erlangs.

Data Rate

The data rate is sometimes referred to as the “raw” data rate and includes both signalling andata bits. The signalling bits include the Radio Link Protocol (RLP) and framing overhead.may also be viewed as the physical link layer rate. It will be the largest of the rates discussthis section. IS-95B RS1 (or IS-2000 RC1) traffic channels (either fundamental or supplemtransmit at a raw data rate of 9.6 kbps and, via concatenation, up to some multiple of 9.6IS-95B RS2 (or IS-2000 RC2) traffic channels (either fundamental or supplemental) transmraw data rate of 14.4 kbps and via concatenation up to some multiple of 14.4 kbps.

The data rates achievable with IS-2000 were outlined in Table A4-1, Table A4-2, and TableThe actual data rate achieved during a particular time-slice will be the composite of fundamchannel and supplemental channel rates.

Bearer Rate

The bearer rate (sometimes referred to as the total throughput) represents the optimal transrate for user data after accounting for RLP and framing overhead (but not retransmissionserrors). This may be viewed as the data link layer rate. IS-95B RS1 (or IS-2000 RC1) trchannels (either fundamental or supplemental) transmit at a bearer rate of 8.0 kbps aconcatenation up to some multiple of 8.0 kbps. IS-95B RS2 (or IS-2000 RC2) traffic chan(either fundamental or supplemental) transmit at a bearer rate of 12.8 kbps and via concateup to some multiple of 12.8 kbps.

The IS-2000 specification incorporates a Medium Access Control (MAC) sublayer wencompasses previous RLP functionality and introduces multiplexing and QoS functionaCalculating the bearer rates for IS-2000 data calls will need to account for overhead assocwith the multiplex sublayer in addition to that associated with the RLP sublayer. See Tablefor details.

Effective Throughput or Wireline Equivalent Throughput

Retransmission, due to errors, further reduces the throughput to a level which is termed effthroughput. Accounting for frame erasures is a function of the type of RLP being applied tcall. In the absence of any significant transmission errors, the effective throughput approachbearer rate. The following table shows how FER can be correlated to degraded througdependent upon the RLP scheme in use. Notice that, in terms of throughput, HSPD is impaca greater degree than LSPD by frame erasures. The effective throughput may also be termwireline equivalent throughput.


A4


at RLP

ficant,

ed for

to aat

ation

ery 1

“w/ons”).

Table A4-5: Approximation of Throughput

These equations represent first order approximations of throughput based on FER. Given thType 1 responds to a NACK with a retransmission of only asingle copyof the missing or corruptedframe and assuming that the probability of subsequent NACKs and retransmissions is insigni

the equation corresponds to an average of 1+FER frames being actually transmitt

every 1 frame of original user data. Similarly, given that RLP Type 2 and Type 3 respondNACK with a retransmission oftwo copiesof the missing or corrupted frame and assuming ththe probability of subsequent NACKs and retransmissions is insignificant, the equ

corresponds to an average of 1+2xFER frames being actually transmitted for ev

frame of original user data.

Table A4-6 gives an example for IS-2000 that includes data rate (“Air Frame”), bearer rate (RLP overhead”), and effective throughput (“w/o RLP overhead and excluding retransmissio

Table A4-6: IS-2000 Data Rates (base rate = 9.6 kbps)

RLP Scheme EquationThroughput (% of Ideal)

FER = 1% FER = 2% FER = 3% FER = 5%

IS-95A/B LSPD Type 1 - “1,1,2,3” 99% 98% 97% 95%

IS-95B HSPD Type 2 - “1,2,3” 98% 96% 94% 91%

IS-2000 HSPD Type 3 - “1,2,3” 98% 96% 94% 91%

Data Rate

153.6 76.8 38.4 19.2 9.6

Rates (bits)

Air Frame (bits)(information bits, frame quality indicator, and encoder tail bits) 3072 1536 768 384 192

IS-2000 SCH Data or Payload Size (bits)(information bits only) 3048 1512 744 360 172

IS-2000 SCH Data or Payload Size (Bytes) 381 189 93 45 22

Number of Mux PDU or LTU per Payload 8 4 2 1 1

RLP frame bits per Mux PDU or LTU 346 346 346 346 171

RLP frame bits (w/RLP overhead)(information bits w/o Mux overhead) 2768 1384 692 346 171

RLP Header bits per RLP Frame 10 10 10 10 11

RLP frame bits (w/o RLP overhead)per IS-2000 Data frame 2688 1344 672 336 160

Rate (kbps)

Air Frame 153.6 76.8 38.4 19.2 9.6

Payload 152.4 75.6 37.2 18.0 8.6

RLP (w/RLP overhead) 138.4 69.2 34.6 17.3 8.6

RLP (w/o RLP overhead)per IS-2000 Data frame 134.4 67.2 33.6 16.8 8.0

RLP (w/o RLP overhead and excluding retransmissions) 122.2 61.1 30.5 15.3 7.3

11 FER+--------------------=

11 2 FER×+-----------------------------=

11 2 FER×+-----------------------------=

11 FER+--------------------=

11 2 FER×+-----------------------------=


A4


ectionramp(and

ediatestedievingnload.on thetimes

n onayer

s thatucesation.time-deled.

IS-2000 Data Rates (base rate = 14.4 kbps)

Good-put

TCP, the Transmission Control Protocol (Layer 4), is processed in the end points of a connand is responsible for a reliable virtual circuit and flow control. The method that TCP uses toup to the optimum data rate is termed “slow start”. It avoids what would be unnecessarysometimes continuous) retransmissions, which may result from overwhelming some intermrouter or slower link, which can significantly degrade throughput. While little bandwidth is waon retransmissions with this technique, there are a couple of seconds of delay prior to achthe optimum data throughput. This occurs with each new end-to-end transmission or dowLarger downloads are impacted less than smaller downloads. Overall, the impact can beorder of an additional 7% to 15%. Throughput that takes this impact into account are sometermed “Good-put”. It should be noted that the impact of TCP slow start is not a reflectioIS-95B, IS-2000 or wireless data. It is present with every transmission utilizing TCP as the L4 protocol.

With this description of slow start, it can be seen that the concatenation of several small filemake up a web page into one larger file, as is done in HTTP v1.1, is beneficial in that it redthe number of times that slow start is invoked and thereby mitigates the throughput degradHTTP v1.0, which does not perform this concatenation of files, provides no such benefit. Forsliced simulations of IS-2000 data calls, the user may specify the version of HTTP to be mo

Data Rate

230.4 115.2 57.6 28.8 14.4

Rates (bits)

Air Frame (bits)(information bits, frame quality indicator, and encoder tail bits) 4608 2304 1152 576 288

IS-2000 SCH Data or Payload Size (bits)(information bits only) 4584 2280 1128 552 267

IS-2000 SCH Data or Payload Size (Bytes) 573 285 141 69 33

Number of Mux PDU or LTU per Payload 8 4 2 1 1

RLP frame bits per Mux PDU or LTU 538 538 538 538 266

RLP frame bits (w/RLP overhead)(information bits w/o Mux overhead) 4304 2152 1076 538 266

RLP Header bits per RLP Frame 10 10 10 10 10

RLP frame bits (w/o RLP overhead)per IS-2000 Data frame 4224 2112 1056 528 256

Rate (kbps)

Air Frame 230.4 115.2 57.6 28.8 14.4

Payload 229.2 114.0 56.4 27.6 13.4

RLP (w/RLP overhead) 215.2 107.6 53.8 26.9 13.3

RLP (w/o RLP overhead)per IS-2000 Data frame 211.2 105.6 52.8 26.4 12.8

RLP (w/o RLP overhead and excluding retransmissions) 192.0 96.0 48.0 24.0 11.6


A4


em isand

s areserill,with

o be

ng onection

For time-sliced simulation of IS-2000 data calls, the transfer of data through the RF sub-systmodeled at a low level. This includes a TCP model that incorporates both slow startcongestion control. The model is termed a “half-stack” TCP model, in that acknowledgmentimplied after a fixed time has passed.9 As a consequence of this detailed modeling, end-uthroughput statistics will reflect the impact of TCP slow start. The sector throughput wtheoretically, remain unchanged by slow start since the effect is to trade out fewer usershigher end user throughput for more users with somewhat derated end user throughput.

In NetPlan’s initial implementation of IS-2000 data simulation, all applications are assumed tusing TCP. In future releases, other protocols will be modeled (e.g. WAP, UDP, W-TCP).

A4.3.3 Example Call Model for a Given Data Service

The table below represents a simple, yet sufficient, call model for high-speed web browsiwhich discussions may be based to reinforce an understanding of material introduced in SA4.3.1 and Section A4.3.2.

9. For more information on TCP modeling, refer to chapters 20 and 21 inTCP/IPIllustrated,Volume1, Ri-chard W. Stevens, Addison Wesley Longman Inc., 1994.

Table A4-7: High-Speed Web Browsing Call Model Example

High SpeedWeb Browsing

Derivation

Mean Number of Walsh codes per Call(fundamental + supplemental channels)

3 E

Mean Forward Bearer Rate (kbps)a 38.4 H

Reverse Bearer Rate (kbps)a 12.8 I

Per DownloadMean Upload Size (in kbytes) 3 JMean Upload Time (seconds) 1.9 K = (8 x J) / I

Server Delay (seconds)b 4 L

Mean Download Size (in Kbytes) 32 MMean Download Time (seconds) 6.7 N = (8 x M) / HMean Think Time (seconds) 30 O

Mean Think Time (seconds)c

(for t < T=20 seconds)7.3 µ = µ(t<20) =

Probability of Think Time > T=20 secondsc 28% P20 = Prob(t>20) =

Mean Active Period Think Time (seconds)c 10.9 OActive =

a b×( ) θ a b+T b+-------------

θ 1–1–

××

1 θ–( ) 1a b+T b+-------------

θ–

×--------------------------------------------------------------------------- b–

T b+θ 1–------------- T+

P20 T× 1 P20–( ) µ×+


A4


riodused to

ds perattemptsytes

ed todata

ende peakughputughputd must

ek

g..

ate

Enough information is provided to give an intuitive feel for the call interaction. The active pehold time is 352 seconds per session attempt (98 mErlangs per session attempt) and can beconvert session attempts into FCH (or Active) Erlangs. The session hold time is 638 seconsession attempt (177 mErlangs per session attempt) and can be used to convert sessioninto Session Erlangs. The data volume was 4200 kilobits (i.e. 3840 + 360) or 525 kilob(downlink and uplink). A conversion factor of 98 FCH mErlangs per 525 kilobytes can be usconvert kilobytes to FCH Erlangs. The forward data activity factor is 31.4% and the reverseactivity factor is 19.5%.

Note that although this call represented an IS-95B HSPD call, anaverageof 3 forward links wasassumed and not themaximum of 5 RS2 Walsh codes. The bearer rate must reflect a realisticuser experience consistent with the load. It is not realistic to assume that users will experiencdata rates consistently when the carrier is under any significant load. Load and end user throare inversely related. Should simulation results indicate that the assumed end user throcannot be realized, then either the throughput expectations must be lowered or the traffic loabe reduced (i.e. redistribute the traffic across more sites or carriers).

Mean Downloads per Session 15 PPer Session

Mean Session Time (seconds) 638 Q = P x (K + L + N + O)Active Time (seconds, % of session) 352 (55.2%) R = P x (K + L + N + OActive)

R% = R/QDormant Time (seconds, % of session) 286 (44.8%) S = Q - R; S% = S/QAverage Kilobits Downloaded per Session 3840 T = 8 x P x MAverage Kilobits Uploaded per Session 360 U = 8 x P x J

Forward Data Activity Factord 31.4% V =

Reverse Data Activity Factord 19.5% W =

a. The bearer rate may be adjusted to compensate for RLP retransmissions.b. The server delay may be adjusted to compensate for TCP Slow Start.c. The calculation of the average think time within the active period (OActive) is based on modeling think timeas a Pareto random variable. Based on this assumption,OActive is calculated based on the mean of thedistribution, truncated at 20 seconds (the inactivity timer threshold), and the probability of going dormant. Thparametersa andθ were set to 1 and 1.5, respectively, based on call model input from the Packet NetworTechnology Group. The parameterb is a function ofa, θ, andO as follows:b = θ (O - a) - O.d. The Forward Data Activity Factor calculation assumes a FCH which uses eighth-rate frames when idlinWhen modeling a DCCH, the second component can be eliminated and the calculation reduces to:Similarly, for the Reverse Data Activity Factor, the calculation reduces to : . The use of field E inthe forward calculation represents a weighting factor based on the ratio of the mean forward bearer r(fundamental and supplemental channels) to the fundamental bearer rate.

Table A4-7: High-Speed Web Browsing Call Model Example

P N×R

-------------R P N×–

R-----------------------

18 E×------------

×+

P K×R

-------------R P K×–

R-----------------------

18---

×+

P N×( ) R⁄P K×( ) R⁄


A4


es, the

than

Just asrafficrafficin the

n then ist datamay

into

rizedDatan the% in

mete foracrosselative

it isasedTP iswedery

Some general trends with data traffic show a correlation to data rates. For higher data rattrend is characterized as follows:

• larger download file sizes

• more downloads per use

• reduced think time

• reduced download/upload times

• reduced activity factor (because download/upload times are more sensitivethink time to changes in link speed)

• more demanding use (or user)

Some aspects of call modeling that will not be discussed in detail deserve some mention.the hold times for data services do not need to mirror voice services, other important tperspectives also may be different. One consideration is that the daily distribution of data tand its busy hour need not be the same as that of voice. Given the example of internet trafficland network, much of the traffic occurs in the evening hours. It is possible that data traffic iwireless arena will also be distributed differently than voice traffic. Another consideratiogeographic distribution. Although it will be convenient to assume (as many have already) thaloading will be distributed in a manner comparable to voice, it is still possible that its patternbe significantly different for reasons not anticipated.

A4.3.4 Translation of Call Model Information into Simulation Parameters

The following will address the relevant call model information that is required to be enteredNetPlan in order to perform a simulation.

A4.3.4.1 Forward Activity Factor (%) [IS-95A/B only]

When performing simulations in the time-sliced mode, IS-2000 data activity will be characteby the Call Model inputs and not activity factor inputs. Refer to Section A4.3.4.5, "IS-2000Call Model States" for greater detail concerning these inputs. When performing simulations inon time-sliced mode, the activity factor for IS-2000 data calls is currently hard-coded to 100the forward direction.

The Forward Activity Factor was defined earlier to be the actual forward link data volutransmitted for a time period versus the total data that would have been transmitted at full-rathe same time period (i.e. Equation A4-3). The bit rate used would be the aggregate bit ratethe fundamental and any supplemental channels. It is required that this factor be defined rto the time period over which the Erlangs per subscriber class is defined. For IS-95B,recommended that this be the active period. The data activity factor may vary significantly bon the service options and applications involved. For example, performing a download via Fa procedure that may be characterized as only involving 1 download of significant size folloby an idle period prior to going dormant. The data activity factor for this type of call could be v


A4


anttivityice),e datathanntlyare also52 x

lectsplink.s.

rizedDatan the% in

mittedsameannelfactord. Forvarytivity

nd sendg real

lay andhigherreduceutagervices.cture

erent-mail

asses;sent the

high (~90%). Alternatively, LSPD WAP use may involve many downloads but with significthink times such that the data activity factor could be quite low. Under the assumption of an acfactor lower than voice, but with comparable hold time, and only one traffic channel (like voLSPD calls will generate less interference and yield greater RF capacity. Finally, consider thactivity factor for the HSPD web browsing call model discussed earlier. It is somewhat lowerthe voice activity factor (31.4% vs. 40%), however, given that the call hold time is significalarger (352 seconds vs. an assumed 98 seconds for voice) and the bandwidth requirementsgreater (3 vs. 1 channel), the overall traffic load is much larger than that of voice [(31.4% x 33)/(40% x 98 x 1) = ~8.5 times greater!].

Finally, the decision for IS-95B to support supplemental channels only on the forward link refthe fact that much more data is expected to be transmitted in the downlink direction than the uConsequently, forward activity factors, generally, will be greater than reverse activity factor

A4.3.4.2 Reverse Activity Factor (%) [IS-95A/B only]

When performing simulations in the time-sliced mode, IS-2000 data activity will be characteby the Call Model inputs and not activity factor inputs. Refer to Section A4.3.4.5, "IS-2000Call Model States" for greater detail concerning these inputs. When performing simulations inon time-sliced mode, the activity factor for IS-2000 data calls is currently hard-coded to 100the reverse direction.

The reverse activity factor was defined earlier to be the actual reverse link data volume transfor a time period versus the total data that would have been transmitted at full-rate for thetime period (i.e. Equation A4-3). The bit rate used would be for the reverse fundamental ch(and not that of the forward fundamental plus supplemental channels). It is required that thisbe defined relative to the time period over which the Erlangs per subscriber class is defineIS-95B, it is recommended that this be the active period. The data activity factor maysignificantly based on the service options and applications involved. Generally, forward acfactors will be greater than reverse activity factors.

A4.3.4.3 FER Target (%) and FER Outage (%)

Data services are more robust than voice services since the RLP can detect frame erasures aretransmissions, and the data service is not typically sensitive to these delays (not includintime transmissions). This increased reliability comes at the expense of some increased dereduced throughput (refer to Section A4.3.2: "Data Rates"). Since data calls can tolerate atarget FER, it is an appropriate design strategy to target a higher FER and, consequently,the average power and increase RF capacity. Within NetPlan, select FER Target and Oparameter settings to be used with data services that are higher than settings for voice seEach data service option may have a different FER target, however, since the infrastrucorrelates the FER target to a service option, it is not practical, within NetPlan, to consider diffFER targets for different uses of the same service option. For example, two uses of HSPD, Eand web browsing, may be modeled separately within NetPlan using distinct subscriber clnevertheless, they must employ the same FER Target/Outage parameters since they represame service option (i.e. HSPD).


A4


n theentalntaltargether thee, thes” forote 3

three

lass.

ntireing thetime-or

For HSPD calls, the forward power control parameters are set to achieve a similar FER ofundamental channel as for circuit calls (2.5%). Remember that the integrity of the fundamchannel is important due to responsibility for control functions. However, the supplemechannel is set to run at a higher FER (~5%). For IS-95B HSPD, NetPlan applies a single FERfor both fundamental and supplemental channels; consequently, it should be set to reflect eitweighted combination of fundamental and supplemental channel targets or, best cassupplemental channel target alone. Refer to Section 6.2.2.4.1, “Defining Subscriber Classespecific recommendations. Information specific to the FER parameters can be found in Nfollowing Figure 6-12: “Subscriber Class Editor - middle portion of the sliding screen.”

A4.3.4.4 Erlangs per Class Calculation

NetPlan provides three different options for inputting the Erlang load per subscriber class. Allof the options are described below and reference Figure A4-8 as an example.

Table A4-8: Example of Erlang Calculations

Option 1 - Erlangs per Subscriber Class

The most direct format in which to receive loading input is in terms of Erlangs per subscriber cFor IS-95B and for non time-sliced simulation of IS-2000, it isrecommendedthat the Erlangs bedefined relative to the active period. If, for example, the Erlang load is defined relative to the ecall or use, then the load may be converted to an active period base via a ratio representpercentage of time that the call was in the active mode (i.e. value R% from Table A4-7). Forsliced simulations of IS-2000, it isrecommendedthat the definition be made relative to the usesession.

Total Subscribers 100,000

Percent subscribing to Voice Services 100%

Voice Subscribers 100,000

Percent subscribing to Data Services 5%

Data Subscribers 5000

BHCA per Voice Subscriber (voice services only) 0.6

BHCA per Data Subscriber (data services only) 1.0

with respect to Active Period Only

Class CA%CA

wrt Data%CA

wrt Total

HoldTime(sec)

%Erlwrt Total

%Erlwrt Data

mErl/Sub(per type) Erlangs

Web Browsing 110 2.2% 0.2% 352.0 0.6% 20.1% 2.2 10.8E-mail 4800 96.0% 7.4% 30.0 2.4% 74.8% 8.0 40.0

Fax 90 1.8% 0.1% 110.0 0.2% 5.1% 0.6 2.8Total Data 5000 100.0% 7.7% 38.5 3.2% 100.0% 10.7 53.5

Voice 60000 92.3% 98.0 96.8% 16.3 1633.3Total 65000 100.0% 93.4 100.0% 1686.8


A4


nd 2.8into

angsstatedfullypts or, it isive as

2.4%,These

de, aso data96%,

thate data

classything

rs arebly allsmall

langs oftes 0.5

mple,ewedthat(which

rs ford Fax

In Figure A4-8, three data subscriber classes are defined with Erlang loads of 10.8, 40.0, afor Web Browsing, E-mail, and Fax, respectively. For purposes of inputting Erlang loadsNetPlan, these values would be rounded to the nearest integer.

Option 2 - %Erlangs per Subscriber Class & Total Erlangs

This method of inputting data is useful for growing the system by scaling total system Erlwhile the penetration of subscriber classes remains constant. In addition to everythingrelative to Erlangs per subscriber class, this option of inputting the load will require careestablishing that penetration levels are, in fact, based on Erlangs and not call attemsubscribers. Any other basis for penetration would require some form of conversion. Againcritical that the Erlang load results from this option maintain the same time period perspectthe Data Activity Factor that is entered.

In Figure A4-8, three data subscriber classes are defined with Erlang penetrations of 0.6%,and 0.2% for Web Browsing, E-mail, and Fax, respectively, and 1687 total system Erlangs.values would be used as NetPlan inputs if option 2 were used.

If call attempt penetration were provided, the conversion to Erlang penetration could be mathe average hold times are known. In this example, 7.7% of the total call attempts pertain tservices. The distribution of these call attempts for web browsing, E-mail, and fax are 2.2%,and 1.8%, respectively. Using Equation A4-5, the Erlang penetrations are derived. Notealthough web browsing only represents ~2% of the data attempts, it represents ~20% of thErlangs. This is due to its large hold time.

Option 3 - Erlangs/Subscriber per Class & Number of Subscribers per Subscriber Class

This method of inputting data is useful for growing the system by scaling subscribers in eachwhile the Erlang/subscriber attribute of each subscriber class remains constant. Everpreviously stated in this section concerning Erlangs applies here as well.

Data loading is frequently normalized to a data subscriber. In Figure A4-8, 5% of subscribedata subscribers. It is possible to normalize relative to the total subscriber base (presumavoice users), but the traffic and call attempt numbers may be too small to appreciate due topenetration. For example, the observation that the average data user generates 10.7 mErdata traffic might be appreciated more than the observation that the average user generamErlangs of data traffic (53.5 Erlangs/100,000 Subscribers).

The penetration of data services may be provided simply as a distribution of their use. For exa96% of the data calls are E-mail and 2.2% are HSPD Internet Web Browsing. This may be vias the mix of data services for a “typical data user”. [This is a little more intuitive than saying96% of the data subscribers are E-mail users and 2.2% are HSPD Internet Web Browsersinvites associating smaller groups of data subscribers with each service).]

Based on Figure A4-8, for option 3, the NetPlan Erlang inputs would be 5000 data subscribeeach of the three data subscriber classes with the contribution of web browsing, E-mail, anof 2.2 mErl/sub, 8.0 mErl/sub, and 0.6 mErl/sub, respectively.


A4


odelbursty

w the, the

odelby an

re firstd inthe

A4.3.4.5 IS-2000 Data Call Model States

In simulating IS–2000 packet data, using the time–sliced simulation mode, data call mparameters are specified to characterize the behavior of a packet data call. Because of thenature of data transmissions, modeling of the simulation in greater detail is required to shoimpact of the variability upon the end user throughput and sector throughput. Additionallydistribution of subscribers between active and dormant states is characterized.

Figure A4-2: Call Model States

Dropped subscribers cycle through the different states as shown in Figure A4-2: "Call MStates". For each of the five states, transition times and file sizes/quantities are determinedassociated set of parameters which characterize their distribution. These parameters wedescribed in Section A4.3.1, "General Attributes of the Data Call Model". The example founTable A4-7, “High-Speed Web Browsing Call Model Example,” on page A4-33, incorporatesmean value for each element of the state machine as follows:

TableA4-7 <=> FigureA4-2

Mean Upload Size <=> Upload State (Reverse Request State)

Server Delay <=> Server Wait State (Server Delay State)

Mean Download Size <=> Download State (Forward Reference State)[# Forward References x Forward Reference Size]

Mean Active Period Think Time <=> Think State (Think Time)

Mean Think Time <=> Think Time + Dormant

Dormant

ReverseRequest

ServerDelayState

ForwardReference

Think

Inactivity timerexpires beforethink time expires

Think time expires

Think Time - Inactive Time+ Dormant-to-Reverse

ReverseRequestpacket

State

ForwardReference

Serverresponded

State

State

State

packet(s)

Start Call,InitialInactiveTimer

Request Delay time expires

was sentwas sent


A4


ity iswingall

endentine the

to an

g theversehe call

er ofspentfit fornearn themean

fully.d byll tot forand

With this low level simulation, there is no need to supply a data activity factor. The data activfully characterized as dropped subscribers transition through the call states. The folloequations show the calculation of the activity factors relative to the active period (withcomponents representing time spent in each state). The Upload and Download times are depupon RF carrier conditions and, consequently, the simulation results are needed to determrelationship of end user experience to the particular system load being offered.

[EQ A4-7]

[EQ A4-8]

Because the call model states include the Dormant state, the Erlang load submittedapplication should correspond to the Use or Session Erlangs.

An additional parameter, the Dormant-to-Reverse Request Delay, permits for specifyinamount of additional setup time that is required to transition from the dormant state to the rerequest (upload) state. Also, the Dormancy Timer, which was hard-coded to 20 seconds in tmodel example, is user definable in NetPlan.

A4.3.4.6 Pareto Distributions

When performing time-sliced simulations, the Pareto distribution is used to model the numbfiles and/or the file size for the Upload and Download states. It also is used to model the timein the think state. Several industry studies support the conclusion that it provides the bestfile size and think time distributions. A Pareto distribution has a Gaussian–like distributionthe mean, but is characterized by a “heavy-tailed” distribution for values much larger thamean. The effect is a small, but finite, probability that a number considerably larger than thewill result.

Within NetPlan, a Truncated Pareto distribution will be employed that uses four parameters tocharacterize the distribution. The parametersa and T define the minimum and maximum (i.etruncation) values for the distribution, respectively. The spread of the distribution is governetheb andθ parameters. Theθ parameter, found in the classic Pareto equation, correlates wethe slope of the Pareto distribution in its ‘tail’. Yet, the classic Pareto equation is insufficiencharacterizing the entire distribution (note its discrepancy with the field data in Figure A4-3)has been extended to a generalized form. In the general Pareto equation, theb term modifies the‘head’ of the distribution to better match the field data.

Forward Data Activity Factor DownloadUpload + Server Wait + Download + Think---------------------------------------------------------------------------------------------------------=

Reverse Data Activity Factor UploadUpload + Server Wait + Download + Think---------------------------------------------------------------------------------------------------------=


A4


f data

uouss:

n of a

Figure A4-3: Pareto Distribution

NetPlan has provided a default set of parameters that permit for characterizing a variety oapplications. In Table A4-9, the mean value for each parameter along with thea, b,θ, andT valuesis provided. The reverse request size, forward file size, and think time all approximate contindistributions. The mean of a continuous truncated pareto distribution is calculated as follow

[EQ A4-9]

The forward files per download (# Forward References) is a discrete distribution. The meadiscrete truncated pareto distribution is calculated as follows:

[EQ A4-10]

Hold Times(Log-Log plot of Inverse Cummulative Distribution Function)

-1.5

-1

-0.5

0 0 1 2 3

Log(HoldTime)

Log(

1-C

um.%

)

Field Data

Classic Pareto (b=0)

Generalized Pareto (b=40)

Better fit with b in the “head”

θ provides good fit in “tail”

Meana b+( ) θ a b+

T b+-------------

θ 1–1–

××

θ 1–( ) a b+T b+-------------

θ1–

×--------------------------------------------------------------------------- b–=

Mean

ya b+y b+------------

θ a b+y 1+( ) b+

-------------------------- θ

– ×

y a=

T

∑

1a b+

T 1+( ) b+---------------------------

θ–

-------------------------------------------------------------------------------------------=


A4


TTPs anthinks (i.e.nt,smallmeterion of

, theat anledgefferent

term

Table A4-9: Service Type Default Parameters

Web Browsing may represent downloads composed of the concatenation of multiple files (Hv1.1) or without the concatenation (HTTP v1.0). “E-mail without Attachments” representinteractive process where individual E-mails are downloaded with accompanying reading ortime. “E-mail with Attachments” is modeled as a single download of several concatenated fileits TCP behavior is similar to HTTP v1.1 although the actual protocol involved will be differee.g. SMTP). WAP is represented as a interactive series of single file downloads, each fairlyin size, followed by a reading or think time. Although FTP has no default parameters, its parasettings are considered to be comparable to “E-mail with Attachments”, but no concatenatmultiple files is assumed (i.e. its TCP behavior is similar to HTTP v1.0).

If field data was available to establish the distribution for any of the call model parameterspareto distribution parameters could be adjusted to match the distribution. It is likelier thoperator expectation exists of either a higher or lower mean, without any greater knowconcerning the distribution. In these cases, adjustments could be made in a couple of diways. First, the adjustment of the b term alone may yield the desired shift in the mean. The b

Parameter

Application

Web Browsing E-mail w/oAttach.

E-mail w/Attach.

TextBrowsing/

WAP

ReverseRequest Size

(Bytes)

abθT

Mean

6410001.2

1000002832

6410001.2

1000002832

6410001.2

1000002832

501

1.2800134

ForwardFiles perdownload

abθT

Mean

16.12.4375

5.16 1.00

12

1.280

6.43 1.00

ForwardFileSize (Bytes)

abθT

Mean

10004001.2

10000005746

6500

1.11700003059

65070001.1

17000016425

503501.2

2500511

DownloadSize (Bytes) Mean 29647 3059 105669 511

Think Time(secs)

abθT

Mean

1141.5

4680030.19

1141.5

4680030.19

1141.5

4680030.19

111.81.5800

21.84


A4


thod,ich cang are

y 1000cel,either

luesthe

in the...).

peedet dataon aetting

hey

nd

".

ction

is proportional to the mean; increases to b will yield increases to the mean. An alternative mewould be to scale the values of a, b, and T simultaneously. These parameters form a set whbe scaled readily. For example, the Forward File Size default parameters for Web Browsinselected such that a mean of 5746 bytes is provided. Dividing the a, b, and T parameters all bwould yield a mean of 5.746. Using Equation A4-9 and the Goal Seek function within Exadjustments to the parameters to achieve the desired mean is easily accomplished bytechnique.

Modifying the θ parameter is not justified unless there are studies supporting it. The vacurrently provided as defaults forθ represent a synthesis of the current understanding byindustry and Motorola.

A4.4 Simulation Input Parameters

Simulation parameters that are used in high speed packet data simulations are definedCDMA Parameters window of the NetPlan GUI (Configure>Simulation Parameters>CDMA

This section provides a listing of the simulation input variables that are specific to high spacket data subscribers or whose values may need to be set differently for high speed packusers than for voice users. Where additional information is available within this appendixspecific parameter, a reference is provided. The appropriate sections within Chapter 6, “SSimulator Input Parameters - System Level”, are also referenced.

A4.4.1 Radio Access Network - Configuration

The following parameters pertain to the configuration of the Radio Access Network (RAN). Tare located under the CDMA Parameters window: Radio Access Network>Configuration.

• IS-95B Packet Ec/Io Offset [IS-95B only]Refer to Section A4.1.3.1, "IS-95B Supplemental Channel Allocation".

• Dormancy Timer [IS-2000 only]Refer to Section A4.3.1, "General Attributes of the Data Call Model" aSection A4.3.4.5, "IS-2000 Data Call Model States".

• Control Channel Mode [IS-2000 only]Refer to Section A4.1.1.2, "IS-2000 Fundamental and Supplemental Channels

• RLP Throughput Degradation [IS-2000 only]Refer to Section A4.3.2, "Data Rates".

Further information regarding the setting of configuration parameters can be found in Se6.2.2.2.1 of this document.


A4


er theadio

ntalnnel

They

oughnd inons".nd in

A4.4.2 Radio Access Network - Supplemental Channels [IS-2000 only]

The following parameters pertain to management of IS-2000 supplemental channels undRadio Access Network (RAN). They are located under the CDMA Parameters window: RAccess Network>Supplemental Channels.

• Time-Slice Interval (forward/reverse)

• Scheduling Threshold (forward/reverse)

• Reduced Active Set Pilot Offset (forward/reverse)

• Ior/Ec Capacity Threshold (forward only)

• Rise Capacity Threshold (reverse only)

For further information within this appendix, refer to Section A4.1.3.2, "IS-2000 SupplemeChannel Allocation". Further information regarding the setting of IS-2000 supplemental chaparameters can be found in Section 6.2.2.2.2 of this document.

A4.4.3 Data Services - Call Models [IS-2000 only]

The following parameters pertain to definition of IS-2000 packet data service call models.are located under the CDMA Parameters window: Data Services>Call Models.

• Server Delay

• Dormant-To-Reverse Request Delay

• Service Type

• Initial Inactive Time

• Rev. Request Size

• # Forward References (Files per Download)

• Fwd. Reference Size

• Think Time

Within this appendix, general data call model information can be found in Section A4.3.1 thrSection A4.3.3. More detailed information on the data call model parameters can be fouSection A4.3.4.5: "IS-2000 Data Call Model States" and Section A4.3.4.6: "Pareto DistributiFurther information regarding the setting of IS-2000 data call model parameters can be fouSection 6.2.2.3.1 of this document.


A4


B andsed via

n

und in

hanneltPlan

B hightenatedhannels

eter. ThisWhenin the

systemeling and Rateoth rate

A4.4.4 Subscribers

The following parameters impact the definition of subscriber classes that represent IS-95IS-2000 packet data subscribers. They are set in the Subscriber Class Editor window (accesthe CDMA Parameters window: Subscribers>Subscriber Classes Edit...).

• Air Interface

• Radio Configuration

• Max. Fwd Data RateRefer to Section A4.1.1: "Fundamental and Supplemental Channels".

• Fwd. Data Rate Outage [IS-2000 only]

• Voice Activity Factor [IS-95B only]Refer to Section A4.3.1.1: "Data Activity Factor (IS-95A/B only)", SectioA4.3.4.1, and Section A4.3.4.2.

• Call Model [IS-2000 only]

• FCH FER (%) - Target and OutageRefer to Section A4.3.2 and Section A4.3.4.3.

Further information regarding the parameters used to define subscriber classes can be foSection 6.2.2.4.1 of this document.

A4.4.5 Supplemental Channel Image Parameter [IS-95B only]

A parameter that is used in IS-95B high speed packet data simulations is the Supplemental CImage parameter. This parameter is set in the CDMA Parameters window of Ne(Configure>Simulation Parameters>CDMA) within the Images tab.

The Supplemental Channel Image is generated when designing systems that include IS-95speed packet data subscribers. Within these systems, multiple channels can be concatogether to achieve higher data rates. This image represents the number of supplemental cat the specified rate set that can be assigned to a subscriber at a particular bin location.

The Images tab within the CDMA parameters window allows the user to set the paramspecifying the rate set that will be used in generating the Supplemental Channel Imagespecific parameter is titled “Image Represents Quantity of Supp. Channels With Rate Set”.setting this rate set parameter, it is important to match the rate set of the data subscribersSubscriber Class Editor. The parameter should be set to Rate Set 1 when modeling acontaining Rate Set 1 data subscribers. Similarly, it should be set to Rate Set 2 when modsystem containing Rate Set 2 data subscribers. For systems that contain both Rate Set 1 aSet 2 data subscribers, Supplemental Channel images should be generated separately for bsets so that the system performance for each rate can be analyzed.


A4


inpute seeental

Rate

Lower

andd thes Tab”

ulationecific

95Bssed95BNewutput

ction,

oughct thet good

For further details regarding the Supplemental Channel Image and the correspondingparameter “Image Represents Quantity of Supp. Channels With Rate Set”, pleasSection 6.2.2.6, “CDMA Parameters - Images Tab” Note 4 and Section 11.2.15, “SupplemChannels (HSPD Supp Chnl)”.

A4.4.6 IS-2000 Achieved Data Rate Image [IS-2000 only]

The following input parameters pertain to the generation of the IS-2000 Achieved DataImage. They are located under the CDMA Parameters window: Images.

• Upper Bound Data Rate (Traffic Load w/FCHs only)

• Lower Bound Data Rate (Traffic Load w/SCHs)

The Achieved Data Rate Images can be generated as either a “Upper Bound Data Rate” or “Bound Data Rate”. These images are created in the non time-sliced mode only.

For further information within this appendix, refer to Section A4.5.4, "IS-2000 Images OutputAnalysis (HSPD)". For further details regarding the IS-2000 Achieved Data Rate Image ancorresponding input parameters, please see Section 6.2.2.6, “CDMA Parameters - ImageNote 5 and Section 11.2.16, “IS-2000 Achieved Data Rate Image (Active Probe)”.

A4.5 Simulation Output Analysis

In assessing a system design to determine whether the design criteria have been met, simoutputs, consisting of both statistics and images, are reviewed. In this section, HSPD spoutputs and issues unique to HSPD will be addressed.

New output statistics specific to IS-95B HSPD will be addressed in Section A4.5.1: "IS-Statistical Output and Analysis". New output statistics specific to IS-2000 HSPD will be addrein Section A4.5.2: "IS-2000 Statistical Output and Analysis". New images specific to IS-HSPD will be addressed in Section A4.5.3: "IS-95B HSPD Images Output and Analysis".images specific to IS-2000 HSPD will be addressed in Section A4.5.4: "IS-2000 Images Oand Analysis (HSPD)".

A4.5.1 IS-95B Statistical Output and Analysis

The simulation of IS-95B HSPD users results in both new and modified statistics. In this sestatistics pertaining to IS-95B HSPD will be reviewed.

A4.5.1.1 CellStat_XX [IS-95B]

No new statistics specific to IS-95B HSPD have been added to the CellStat_XX file. Even ththere are no new statistics, the presence of IS-95B HSPD users within a system will impaexisting cell statistics (for example, an increase in the power requirement, a change in percenconnects and how a specific statistic should be interpreted).


A4


usageer hasbut atfeweratistics,

criberinto

o soft-95Bsolely

ental) in actor”. In thisfor

SPD

ata ratesible

ctiond data,traffic

ersely,ers oflowithnlySPD

te

usyhe RFd. As

A4.5.1.1.1 Soft Handoff Factor

The premise for using the soft handoff factor during a system design process was to monitorof channel resources based on a ratio of actual traffic to effective traffic. The system designto balance the trade-offs between a high soft handoff factor that improves system statisticsthe expense of additional channel elements and a low soft handoff factor that requiredchannel elements but at the expense of degraded statistics. (To improve the degraded stadditional sites may be required.)

Prior to the introduction of IS-95B HSPD, the number of channel elements assigned to a subswas a direct reflection of its soft handoff state. With the introduction of IS-95B HSPD usersthe system, supplemental channel allocation provides for another method, in addition thandoffs, for allocating multiple channel elements to a subscriber. Consequently, with ISHSPD users present in a simulation, the number of channel elements allocated no longerreflects the level of soft handoff and the soft handoff factor calculation becomes invalid.

It is not uncommon for a minority portion of IS-95B HSPD users to be assigned supplemchannels. If there is a low penetration of IS-95B HSPD users (for instance, less than 5%predominantly voice market, the impact of the IS-95B HSPD users on the “Soft Handoff Fastatistic may be small compared to these same statistics if there was no IS-95B HSPD userscase, it may still be useful to review the “Soft Handoff Factor” statistic when lookingperformance trends and discounting absolute result values.

For the same reasons, the “Soft + Softer Handoff Factor” statistic is also invalid for IS-95B Hsimulations.

For IS-2000 HSPD, the set of channel element statistics has been expanded to include per dinformation. By categorizing the channel element allocation information by data rate, it is posto extract an accurate soft handoff factor. Refer to Section 9.5.4.5 for details.

A4.5.1.1.2 BTS Channel Cards Sizing

For a mixed voice and data system, it is recommended to follow the steps outlined in Se9.5.8.2 to determine a base number of BTS Channel Cards to support voice, circuit switcheand low speed packet data. All of these services have the same bandwidth requirement (1channel per call per site); consequently, their traffic streams may be treated as one. ConvIS-95B HSPD calls have larger bandwidth requirements and will be served by varying numbsupplemental channels.It is assumed that, initially, penetration of IS-95B HSPD will be(≤ 1%). One consequence of this is that it will be difficult to obtain the mean traffic wconfidence for IS-95B HSPD traffic (either mobile traffic or channel element traffic) given o100 drops. A policy of adding 5 channel elements to each site is sufficient to support IS-95B Hwhile penetration of IS-95B HSPD is still low (≤ 1%). This is designed to maintain a composigrade-of-service below 2%.

To illustrate this concept further, consider the following example. In Figure A4-4, site A’s bhour voice traffic (and other low data rate services) already approaches the capacity of tcarrier and it is assumed that the site is already equipped to support this maximum RF loa


A4


ls arenarriernnel

ls arem RFloitedrt theSPDnnel

thodsy beerate

parablese, a.5.8.9)

.5.8.4

9.5.9ionalcalls

in thePD

discussed in Section A4.1.3.1: "IS-95B Supplemental Channel Allocation", IS-95B HSPD calallocated bandwidth based on the availability ofexcessRF carrier capacity where the allocatioalgorithm is biased in favor of protecting voice services. Since there is little or no excess RF ccapacity during the busy hour, IS-95B HSPD calls will receive little or no supplemental chabandwidth. However, during lower traffic periods when excess capacityis available in site A,IS-95B HSPD calls will receive supplemental channel bandwidth, but no additional channerequired to support this IS-95B HSPD traffic since the site is already channelized for maximucarrier capacity. Site B’s busy hour voice traffic leaves excess RF carrier capacity to be expby IS-95B HSPD traffic. Assuming that site B has been channelized appropriately to suppoexisting voice traffic, additional channels should be added to support any additional IS-95B Htraffic during the busy hour. To reiterate, the recommendation is to add a minimum of 5 chaelements per site for such conditions while penetration of IS-95B HSPD is still low (≤ 1%).

Figure A4-4: IS-95B HSPD Channelization

Should the penetration of IS-95B HSPD traffic exceed 1%, then the channel sizing meoutlined in 10.5.8.1.2 may still be used with the understanding that the approximation maunder-engineered. Alternatively, it is possible to post-process the MobileStats file and genchannel element statistics on a per sector, per data rate basis. This would yield statistics comto the expanded set of channel element statistics now available for IS-2000; in which catechnique such as that employed in the Excel macro kaufman.bas (described in Section 9may be used for sizing.

For further information on HSPD considerations for channel card sizing, refer to Sections 9and 9.5.8.5.

A4.5.1.1.3 Power Amplifiers

For a mixed voice and data system, it is recommended to follow the steps outlined in Sectionto determine the sufficiency of the BTS PA subsystem. It is expected that minimal additpower will be required to support the integration of HSPD. This is due to the fact that HSPDare allocated bandwidth based on the availability ofexcessRF capacity where the allocationalgorithm is biased in favor of protecting voice services.

In a set of IS-95B HSPD simulation studies, it was observed that the worst case increase90th-percentile of the total traffic channel power distribution due to the introduction of HS

voice load(channelized

appropriately)

excessexcess

HSPDexcess capacity in thebusy hour permits fornew HSPD traffic andrequires someadditional channels

HSPDlimited excess capacity in the busyhour does not permit for HSPDtraffic

at times when HSPD can beaccommodated (i.e. during lowervoice traffic periods), no additionalchannels will be required

RF CarrierCapacity

SITE ASITE B


A4


f 1 orwer,

the

2 andfinedmakes

n bein the

to the

tisticsan be

ntalp), thept ors(es)ers,

e mean-6 for

corresponded to less than 50% of the pilot power. The difference is therefore on the order o2 additional traffic channels. While lightly loaded cells exhibited greater relative shifts in pothe magnitude of the increase in the 90th-percentile was still less than the pilot power.

A4.5.1.2 MobileStat_XX [IS-95B]

With the implementation of IS-95B HSPD, two new data columns have been added toMobileStat output file and another column has changed. These columns are:

• Class [changed]

• MaxRate (kbps) [new]

• NumSupp [new]

The Class column has changed from previous versions of NetPlan (NetPlan Version 3.earlier). It now identifies the class of each dropped subscriber in the output file by the name defor the given subscriber class and not by an assigned consecutive number. This changeviewing the data file much clearer.

The MaxRate (kbps) column identifies the maximum forward link packet data rate that caachieved by the dropped subscriber. This value is fixed by the input parameters definedsubscriber class.

The NumSupp column identifies the number of supplemental channels that were assigneddropped subscriber.

The MobileStat file can be sorted and filtered based on the Class column, leaving only the stafrom one class of subscriber. In this way, the performance of the IS-95B HSPD subscribers cexamined separately from all of the other subscriber classes.

A4.5.1.2.1 IS-95B HSPD Supplemental Channel Distribution

A useful statistic for the designer to review is the distribution of the number of supplemechannels that are assigned. From all of the MobileStat files (one is generated per each drostatistics for only the IS-95B HSPD users can be filtered out (either through some scristatistical tool) via the “Class” column by extracting only the data for the given subscriber clasof interest. Working with a statistical utility and just the statistics for the IS-95B HSPD subscribthe number of supplemental channels (NumSupp column) can be analyzed to determine thdata rate throughput for IS-95B HSPD users in the system (see Figure A4-5 and Figure A4an example).


A4


e meanentalA4-5)

S-95Bof the

mental

Figure A4-5: IS-95B HSPD Supplemental Channel Distribution (JMP)

Figure A4-6: IS-95B HSPD Supplemental Channel Distribution (JMP)

The mean assigned IS-95B HSPD data rate for the system can be determined by taking thvalue from the distribution of supplemental channels, adding 1 (to account for the fundamchannel) and multiplying this sum by the base rate set. From the above example (see Figureand assuming Rate Set 2, the mean assigned IS-95B HSPD data rate would be:

(0.68182 + 1) * 14.4 kbps = 24.2 kbps

The second set of results (see Figure A4-6) gives an indication of the percentage of the IHSPD users that are being served at any given data rate. From the above example, 4.5%IS-95B HSPD users are being served at 72 kbps (i.e. (1 fundamental channel + 4 supple

NumSupp

0 1 2 3 4 5

Quantiles

maximum

quartile

median

quartile

minimum

100.0%

99.5%

97.5%

90.0%

75.0%

50.0%

25.0%

10.0%

2.5%

0.5%

0.0%

4.0000

4.0000

4.0000

3.0000

1.0000

0.0000

0.0000

0.0000

0.0000

0.0000

0.0000

Moments

Mean

Std Dev

Std Error Mean

Upper 95% Mean

Lower 95% Mean

N

Sum Weights

0.68182

1.21052

0.25808

1.21853

0.14511

22.00000

22.00000

NumSupp

0 1 2 3 4

0 1 2 3 4

Frequencies

Level

0

1

2

3

4

Total

Count

15

3

1

2

1

22

Probability

0.68182

0.13636

0.04545

0.09091

0.04545

Cum Prob

0.68182

0.81818

0.86364

0.95455

1.00000

5 Levels


A4


ilesber ofeet thehave 0ibutionendeded theer to

leStatSPD

revioused 0

ia and-95B

ld alsowould

pactmanceulationsed forribers.

ion of

ardlessa):

s mayulationin the

parate

channels) * 14.4 kbps) on the forward link.

It should be noted that filtering the IS-95B HSPD users’ information out of the MobileStat fextracts data for all IS-95B HSPD users, independent of their achieved FER level. The numusers that are assigned 0 supplemental channels will include users that did and did not mspecified outage FER. However, users that do not meet the specified outage FER wouldsupplemental and 0 fundamental channels assigned and should not be included in the distrof supplemental channels. Based upon the design’s specified FER outage level, it is recommthat the data be filtered a second time to remove those IS-95B HSPD subscribers that exceoutage FER criteria. The total number of IS-95B HSPD users is still required, however, in ordproperly determine the distribution of supplemental channels.

For example, assume that the first pass at filtering out IS-95B HSPD users from the Mobifiles yielded 22 (as shown in the previous figure). Next assume that there were 2 IS-95B Husers that exceeded the design’s specified outage FER for the IS-95B HSPD users. The pfigure showed 15 out of the possible 22 IS-95B HSPD subscribers as being assignsupplemental channels. Of these 15 IS-95B HSPD, 2 did not meet the FER outage criterwould not even be allocated a fundamental channel. Therefore, instead of 15 out of 22 ISHSPD users having a fundamental channel, there would only be 13. FER outage criteria wouhave an impact upon the mean IS-95B HSPD data rate. The 24.2 kbps value shown aboveonly be valid if all 22 IS-95B HSPD users met the FER outage criteria.

A4.5.1.2.2 FWD & REV Mobile Class FER Distribution

With the introduction of IS-95B HSPD users into an existing system, one must study the imon the performance of the existing voice user base. To examine this, the voice users’ perforfrom a baseline simulation can be compared to the voice users’ performance in a second simwhich has HSPD users introduced. One benchmark of voice user performance that can be uthis comparison is the mean achieved forward and reverse FER for all the dropped subscRefer to Section 9.5.4.4 in this document for specific calculations.

One may also filter out the HSPD users information separately and review the FER distributthis subscriber class separately.

A4.5.1.2.3 Percentage of Good Connections (PcntMobGood) and Mixed Rate

The overall minimum requirement for acceptable system performance remains the same regof whether the system contains IS-95B HSPD or not (i.e. voice only or mixed voice and dat

• resulting mean value of PcntMobGood≥ 95% for the entire system

• no individual sector should have a mean value of PcntMobGood < 90%.

Introducing 14.4 kbps services into a system originally designed and operated at 9.6 kbpleave coverage/performance gaps between cell sites for the 14.4 kbps users. Separate simimages based on each rate set will illustrate these areas but the impact may also show upPcntMobGood statistics. Further validation of such a condition can be gained through a se


A4


scribed

newtistics

ss RFDMATablethe

2000havee SCHs, thes for

oiseact of

datasure of

SPD.8.4

ement

9.5.9ionalcalls

comparison of subscriber FER performance between the 9.6 kbps and 14.4 kbps users as deabove in Section A4.5.1.2.2, "FWD & REV Mobile Class FER Distribution".

A4.5.2 IS-2000 Statistical Output and Analysis

The simulation of IS-2000 HSPD users results in both new and modified statistics. Twostatistical output files were created: SectorTputStat and MobileTputStat. In this section, stapertaining to IS-2000 HSPD will be reviewed.

Chapter 9 of this document describes the most significant calculations needed to asseperformance and capacity. Guidelines are also provided for equipment sizing. Table 9-2, “CStatistics”, provides a listing of system metrics that can be derived from the raw statistics.9-3, “Raw statistics definitions”, provides a listing of every “raw” statistic required to producederived metrics.

A4.5.2.1 CellStat_XX [IS-2000]

With the introduction of IS-2000, the CellStat_XX file has been expanded. When running IS-non time-sliced simulations, the modified CellStat_XX file provides several statistics thatseparate entries for the fundamental channel (FCH) and supplemental channels (SCH). Thstatistics are further subdivided by data rate. When running IS-2000 time-sliced simulationnew CellStatTS_XX and CellStatTSRev_XX files provide information on a per time-slice basiboth the forward and reverse links, respectively.

Analysis of the CellStat files is still basic in assessing RF reliability, forward power, reverse nrise, Walsh code and channel element utilization, and soft handoff factor. To assess the impIS-2000 HSPD, it will also be important to review the data rate distribution and Ior/Ec. Therate distribution is compared to operator expectations. The Ior/Ec provides a secondary meaachieving RF carrier capacity limits.

A4.5.2.1.1 BTS Channel Cards Sizing

For information concerning the sizing of BTS channel cards in the presence of IS-2000 Htraffic, refer to Section 9.5.8, “Channel Card Sizing”, with special attention to Sections 9.5through 9.5.8.8. In these sections, there is information concerning the new channel elstatistics and the new Motorola Multi Channel Card for IS-2000 1X (MCC1X).

A4.5.2.1.2 Power Amplifiers

For a mixed voice and data system, it is recommended to follow the steps outlined in Sectionto determine the sufficiency of the BTS PA subsystem. It is expected that minimal additpower will be required to support the integration of HSPD. This is due to the fact that HSPDare allocated bandwidth based on the availability ofexcessRF capacity where the allocationalgorithm is biased in favor of protecting voice services.


A4


fic to/n anectionpacket

itherdesannelof theasis.

tisticsrs can

henused

-2000ationtime-

e.

heno bee endd endtraffic

low, itition

ctionctione end

A4.5.2.1.3 IS-2000 Backhaul Sizing

With R16.0, a BTS packet pipe is supported to transfer IS-2000 supplemental channel traffrom MCC1X cards. Packet transport networks will achieve improved backhaul efficiency ienvironment where the operator’s backhaul costs are becoming a significant concern. S9.5.10 outlines the procedure by which channel element statistics may be used to size thepipe.

A4.5.2.2 MobileStat

With the introduction of IS-2000, the MobileStat_XX file has been expanded. When running etime-sliced or non time-sliced IS-2000 simulations, the modified MobileStat_XX file proviforward and reverse FER for both the fundamental channel (FCH) and supplemental ch(SCH), separately. The forward and reverse SCH data rates are also provided. AnalysisMobileStat files is still basic to assessing forward and reverse FER on a subscriber class b

The MobileStat file can be sorted and filtered based on the Class column, leaving only the stafrom one class of subscriber. In this way, the performance of the IS-2000 HSPD subscribebe examined separately from all of the other subscriber classes.

A4.5.2.3 SectorTputStat

With the introduction of IS-2000, the SectorTputStat_XX statistical output file was created. Wrunning IS-2000 time-sliced simulations, SectorTputStat_XX provides statistics that are to bein the derivation of the sector throughput (i.e. the data load or capacity). In designing an ISHSPD system, the sector throughput is compared to operator expectations. For informconcerning the derivation of the sector throughput, refer to Section 9.5.5.5. Note that for nonsliced simulations, the sector throughput is derived using statistics from the CellStat_XX fil

A4.5.2.4 MobileTputStat

With the introduction of IS-2000, the MobileTputStat_XX statistical output file was created. Wrunning IS-2000 time-sliced simulations, MobileTputStat_XX provides statistics that are tused in the derivation of the effective sector throughput (i.e. the data load or capacity) and thuser throughput. In designing an IS-2000 HSPD system, the effective sector throughput anuser throughput are compared to operator expectations. The end user throughput and theload are inversely related; therefore, should end user throughputs appear unsatisfactorilywill be important to lower the load per sector-carrier (either through cell splitting or the addof new carriers).

For information concerning the derivation of the effective sector throughput, refer to Se9.5.5.6. For information concerning the derivation of the end user throughput, refer to Se9.5.5.4. Note that for non time-sliced simulations, both the effective sector throughput and thuser throughput are derived using statistics from the MobileStat_XX file.


A4


SPD.

ere theentalill be

e imagengl also

HSPDed as a

ce the

H Raterwardutilizemit thedataing theused

ametersimage

A4.5.3 IS-95B HSPD Images Output and Analysis

The “Supplemental Channels” image is the only new image added to NetPlan for IS-95B H

The High Speed Packet Data Supplemental Channels image portrays geographic regions whimage probe would be assigned forward link supplemental channels (in addition to a fundamchannel) if it were a IS-95B HSPD subscriber. In addition to where supplemental channels wassigned, this image also shows how many supplemental channels could be assigned to thprobe. The number of supplemental channels assigned is largely a function of the underlyiEc/Io conditions. System adjustments intended to influence the voice subscriber’s Ec/Io wilimpact the number of assigned supplemental channels for the HSPD subscriber.

The creation of the Supplemental Channels image does not require the inclusion of IS-95Bsubscribers amongst the dropped subscribers. The image probe does not need to be definIS-95B HSPD subscriber either, though certain image probe specific parameters will influenresults. These image probe parameters, defined in the Subscriber Class Edit window, are:

1. Antenna Gain (dBd)

2. Penetration Loss (dB)

3. Air Interface

4. TCH Rate Set

5. Fading Type

A maximum of 7 supplemental channels can be assigned regardless of the image probe TCSet (9.6 kbps or 14.4 kbps). For dropped subscribers, it is recommended that the maximum fodata rate be set to reflect product capabilities (refer to Section A4.1.1.1). Image probes maythe same maximum forward data rate as the dropped subscribers or, alternatively, may permaximum to exceed product limits (up to 7). If the image probe utilizes a maximum forwardrate that exceeds the product limits, then an appropriate color scheme is chosen when viewimage so that the results can be interpreted in terms of the product limit. The algorithm that isto assign the supplemental channels is based on the image probe TCH Rate Set value (par3 and 4 from the list above) and the measured Ec/Io. The measured Ec/Io is influenced by theprobe parameters 1, 2 and 5 listed above.


A4


certainload.

erefores RS2r is usede dataable ativene an

mental

Figure A4-7: HSPD Supplemental Channel Image

The image in Figure A4-7 depicts the areas where the image probe would be assigned anumber of IS-95B HSPD supplemental channels in the presence of the overall system trafficThe IS-95B HSPD service in this example was simulated as a Rate Set 2 subscriber and thwould not be assigned more than 4 supplemental channels (Motorola’s implementation limitto 4 supplemental channels). This color scheme has been chosen such that the same colofor all supplemental channels 4 through 7 to avoid confusion when examining the image. Thrate offered to subscribers is directly related to the number of supplemental channels availa given location. Additionally, the data rate is directly related to the Ec/Io conditions at a glocation. The value of the “IS-95B Packet Ec/Io Offset” parameter used in the design will havimpact upon the number of supplemental channels available at a location.

If the above figure was simulated based on Rate Set 1, then one would want to look at supplechannels up to 5 (Motorola limits RS1 to 5 supplementals).


A4


d in theage

users.sses.to ther each

possiblys for thescriberuld be

ared touded in

eforeis not

l haveHSPDDMA

Lowercan beration.tion,rposes.are in a

te for aRate

ataage

Images

Note that the Supplemental Channel image created will be based upon the rate set selecteCDMA Parameters - Images window. Refer to Section A4.4.5, "Supplemental Channel ImParameter [IS-95B only]".

A4.5.3.1 NetPlan CDMA Composite Images (HSPD)

The NetPlan CDMA Composite images feature is used to provide coverage images for voiceA given system design will provide differing amounts of coverage for different subscriber claIn-Building voice users will not be provided as much coverage as on-street voice users dueadditional building penetration loss. It may be necessary to produce a coverage image focustomer class to verify that satisfactory system coverage performance is being offered.

Separate coverage images may be necessary for the various classes of HSPD users (andall the other unique subscriber classes). The process of creating these images is the same avoice users. The image probe should have the same definition as the class of HSPD subunder investigation with the exception that the image probe requires a constant speed. It shonoted that different values for the outage FER are used for HSPD (as high as 10%) as compvoice. The High Speed Packet Data Supplemental Channels image does not need to be inclthe creation of the coverage image.

An IS-95B HSPD user will be allotted different numbers of supplemental channels (and therdifferent data rates) dependent on location and system load. Even if an IS-95B HSPD userallotted sufficient supplemental channels to realize a desired data rate, the user may stilcoverage. The user will be serviced at a slower data rate. It is for this reason that the IS-95BSupplemental Channel image is not included when creating a coverage image using the CComposite images feature.

A4.5.4 IS-2000 Images Output and Analysis (HSPD)

The Achieved Data Rate Images can be generated as either a “Upper Bound Data Rate” or “Bound Data Rate”. They are geographical representations of the IS-2000 data rates thatrealized by the active packet data image probe with the existing dropped subscriber configuThe traffic load conditions created within NetPlan are not repeatable in a field test situatherefore, these images should not be used for coverage/system performance warranty puThese images are created in the non time-sliced mode and represent data subscribers thatconstant data burst state, much like circuit switched data. The expected achieved data rapacket data probe would likely fall between the results presented in the Upper Bound Dataand Lower Bound Data Rate images.

For further information within this appendix, refer to Section A4.4.6, "IS-2000 Achieved DRate Image [IS-2000 only]". For further details regarding the IS-2000 Achieved Data Rate Imand the corresponding input parameters, please see Section 6.2.2.6, “CDMA Parameters -Tab” Note 5 and Section 11.2.16, “IS-2000 Achieved Data Rate Image (Active Probe)”.


Application Data DeliveryService Considerations

Appendix

A5
Table of Contents
- 3

- 45 - 5 - 6

- 8

10

A5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5

A5.2 ADDS Over the Traffic Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5 A5.2.1 ADDS Subscriber Class Erlangs . . . . . . . . . . . . . . . . . . . . . . . . . AA5.2.2 ADDS Subscriber Class Activity Factors . . . . . . . . . . . . . . . . . . A5

A5.3 ADDS Over the Traffic Channel (during an active call) . . . . . . . . . . . A5 - 8A5.3.1 ADDS Activity Factor Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . A5

A5.4 Evaluating the ADDS load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A5 -


A5

Appendix A5: Application Data Delivery Service Considerations

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


A5


cific. Shortsuch

c datagivenulate

to aon ofer thee thesed), indiatem thenels. Itin text

gingant indata tor leveles arean RF

alsosult, no

gingtraffic

A5.1 Introduction

Application Data Delivery Service (ADDS) provides for the exchange of short application spedata messages between the subscriber and a network element supporting that applicationMessage Service (SMS) and Over-The-Air Service Provisioning (OTASP) are examples ofapplications. The ADDS name will be used in a general sense to refer to any of the specifimessaging applications that may be available. Although a lot of focus and attention will beto the specific SMS application, the simulation methods in this appendix can be applied to simwithin NetPlan any of the ADDS applications of a CDMA system.

Initially, the SMS feature was the only method available to deliver short text messagessubscriber. The initial deployment of the SMS feature could only allow a one-way transmissia text message to the subscriber and was limited to utilizing only the paging channel to delivmessage to a subscriber in idle mode. The current SMS feature enhancements overcomlimitations by enabling two-way text messaging to occur (subscriber originated or terminateaddition to allowing the delivery of the messages to occur on the traffic channel. An immebenefit of these feature enhancements is that it allows a shift in the text messaging load froresource limited control channels (paging and access), to the resource abundant traffic chanis easier to manage the traffic channel resources in order to accommodate an increasemessaging load as the text messaging applications become more popular.

From an RF perspective, the initial deployment of the SMS feature primarily impacted the pachannel (the acknowledgement messaging on the access channel was fairly insignificcomparison). Since the paging channel sends null messages (in the absence of realtransmit), the power level of the paging channel remains constant. The paging channel poweis typically set to a fixed percentage of the pilot channel power. Thus, the SMS text messagdelivered in the overhead bandwidth that the null messages would otherwise occupy. Fromsystem design perspective, simulating the fixed power level of the paging channel wasadequate to simulate any SMS messages being delivered on the paging channel. As a respecial simulation requirements were needed to handle this scenario.

With the introduction of new ADDS feature enhancements, which allow delivery of text messaon the traffic channel, there are basically four methods for delivering text messages on thechannel.

• Subscriber originated ADDS over the traffic channel

• Subscriber terminated ADDS over the traffic channel

• Subscriber originated ADDS over the traffic channel during an active call

• Subscriber terminated ADDS over the traffic channel during an active call


A5


or thesimilarver asmit

annel,on the

an towill

d (inidered

nel inthes. One

usingo calltraffics the

createdr voicelassesthe

urrentlyy two

xistingad to

st caseoose,

sagingagingfactorhese

For all of the scenarios listed above, the text messaging is occurring on the traffic channel. Ffirst two scenarios above, additional resources are required. The resource requirements areto that of an origination or termination of a regular voice call. Text messages that are sent otraffic channel will require a channel element resource along with some level of power to tranthe message. If there is a significant amount of text messaging occurring over the traffic chthere may be a need to consider simulating the impact that the text messaging load has upRF system design. This appendix will provide a recommended method for using NetPlsimulate the ADDS traffic channel load upon the RF system design. The following sectionsalso provide an approach to determine the significance of the ADDS traffic channel loacomparison to the voice traffic load), which can be used to evaluate if the load should be consin the NetPlan simulation of the RF system design.

A5.2 ADDS Over the Traffic Channel

Since a subscriber originated or terminated ADDS text message delivered on a traffic chanidle mode is similar to that of an origination or termination of a regular voice call,recommended approach to simulate this type of load is to create two new subscriber classesubscriber class is for ADDS originations and the other is for terminations. The purpose fortwo subscriber classes is to simulate the forward and reverse link differences between the twtypes. Creating two new subscriber classes to simulate this text messaging load on thechannel provides the most accurate method for simulating the real world scenario and allowgreatest flexibility in the implementation.

As with any new subscriber class, the subscriber parameters need to be set for the newlyADDS subscriber classes. The same subscriber parameters (settings) that are used fosubscribers (except for the activity factors) can also be applied to the new ADDS subscriber c(refer to Section 6.2.2.4, “CDMA Parameters - Subscribers Tab”, for more information onsetup and recommendations for these parameters). If multiple voice subscriber classes are cbeing simulated that utilize various settings of these parameters, then there are typicalloptions to choose from.

The first option is to create a duplicate set of ADDS subscriber classes that correlate to the evoice subscriber classes. This may only be a viable option if there is enough ADDS traffic lojustify the distribution of the load amongst multiple subscriber classes.

The second option is to create just two ADDS subscriber classes and use average or worvalues for the individual parameter settings. This second option is the more likely one to chsince the ADDS traffic load will most likely be too low to justify option one.

There are two primary subscriber parameters that need to be considered from a text mesperspective in order to properly simulate the ADDS subscribers. The Erlangs of text messusage (or the ADDS subscriber usage) need to be estimated along with the data activitywhich correlates to this usage. The following sections will describe how to estimate tparameters.


A5


S textlangs,5.2.2

inedcationed toneral

videdhour.

lculatedod ofate Setdel.

A5.2.1 ADDS Subscriber Class Erlangs

The first parameter that will be discussed is the Erlangs of usage according to a specific ADDmessaging call model. If the amount of ADDS text messaging usage is already provided in Erthen the next step is to determine the associated activity factors (see the following Section Afor more information on activity factors). The activity factor and the Erlang load must be defrelative to the same time period. It may be necessary to characterize the specific ADDS applicall model by breaking down the Erlang usage into the individual amount of time that is ustransmit full rate, half rate, eighth rate, and quarter rate frames. For information about geattributes of the data call model, see Section A4.3.1 of Appendix A4.

For an SMS application, the amount of SMS text messaging to simulate may typically be proin the form of the average quantity and size of the text messaging that occurs during the busyIf this is the case, then an estimate of the Erlangs of text messaging usage needs to be caaccording to an SMS call model. The following set of examples show a recommended methhow to estimate the Erlangs for an SMS text messaging application for a Rate Set 1 and a R2 system. For these SMS examples, a 100% activity factor is assumed for the SMS call mo

SMS Example #1 - Rate Set 1

Given Assumptions:Rate Set 1 (8,600 bits per second)500,000 busy hour subscriber terminated SMS messages (average)120 busy hour Bytes per message (average)8 bits per Byte

Erlang Calculation:

full rate SMS bits for the busy hour

seconds of SMS usage for the busy hour

SMS Erlangs for the busy hour


Given Assumptions:Rate Set 2 (13,350 bits per second)500,000 busy hour subscriber terminated SMS messages (average)120 busy hour Bytes per message (average)8 bits per Byte

500000 120 8×× 4.88×10=

4.88×10

8600------------------- 55813.95=

55813.953600

---------------------- 15.5=


A5


ing the00%riber

rd andpauseson a

thatan beor forughitted,

onity on

thisand

mountationtivityctivityd to100%

set ofx A4riateDS

th thee theingdels.

Erlang Calculation:

full rate SMS bits for the busy hour

seconds of SMS usage for the busy hour

SMS Erlangs for the busy hour

Both of the examples above estimated the subscriber terminated SMS Erlangs by calculatamount of time required to transmit all of the text messaging data at full rate (i.e. using a 1activity factor). This same type of calculation can be performed to estimate the subscoriginated SMS Erlangs.

A5.2.2 ADDS Subscriber Class Activity Factors

Voice calls have a duty cycle of alternating the transmission of voice data between the forwareverse link, which correlates to one side talking and the other side listening. There are alsobetween words and sentences when neither link is transmitting voice data. All of this activityvoice call produces the voice activity factor. The typical voice activity factor is around 40%.

From a text messaging perspective, the activity factor for data will need to be different fromof a voice call. For example, an SMS text message being delivered on a traffic channel cconsidered as a short duration call with a burst of data being sent at full rate. The activity factthis SMS call should be fairly high for the specific link that experiences the burst of data. Althothere is some messaging activity on the opposite link to acknowledge the data being transmthe activity factor for the opposite link should be fairly low. In an effort to simplify the simulatiof SMS calls on a TCH, one approach is to ignore any idle and/or acknowledgement activboth links and focus the simulation on just the delivery of the text messaging data. Usingapproach for subscriber terminated SMS calls, an activity factor of 100% for the forward link0% for the reverse link would be an acceptable set of values to use.

For the two examples in the previous section, the Erlangs were estimated by calculating the aof time required to transmit all of the text messaging data at full rate. Since there is no estimof any idle and/or acknowledgement activity, this type of calculation correlates to a 100% acfactor. Since these examples estimated subscriber terminated SMS Erlangs, the 100% afactor would only be applied to the forward link. The same calculations can be performeestimate the subscriber originated SMS Erlangs. For subscriber originated SMS Erlangs, theactivity factor would only be applied to the reverse link.

For a more detailed SMS approach or for any other ADDS text messaging application, aforward and reverse activity factors will need to be estimated. The equations in Appendi[EQ A4-1] and [EQ A4-2] can be used to estimate the activity factors to correlate the appropactivity factor to the specific Erlang usage. If the Erlang usage call model for a specific ADapplication includes a mixture of full rate, half rate, quarter rate, and eighth rate data for boforward or reverse links, then equations [EQ A4-1] or [EQ A4-2] should be used to calculatactivity factors. The following is an example of how to calculate the activity factors us[EQ A4-2] given an ADDS Erlang load and the associated forward and reverse link call mo

500000 120 8×× 4.88×10=

4.88×10

13350------------------- 35955.06=

35955.063600

---------------------- 10.0=


A5


DDSor thereatecribering

ld beandto the

Activity Factor Example #1

Given Assumptions:75 subscriber terminated ADDS Erlangs for the busy hourForward Link Call Model: 75% Full, 0% Half, 0% Quarter, 25% EighthReverse Link Call Model: 15% Full, 0% Half, 0% Quarter, 85% Eighth

Forward Link Activity Factor: (using [EQ A4-2])AF = = 78.13%

Reverse Link Activity Factor: (using [EQ A4-2])AF = = 25.63%

For multiple ADDS applications deployed in a system, the call model data from the various Aapplications can be combined together to simplify the simulation process, if the call models fforward and reverse links are relatively similar. For this situation, it may still be necessary to cat least two subscriber classes, one for subscriber originated ADDS and one for substerminated ADDS, since these call types will typically produce similar call models. The followis an example of how to combine multiple ADDS call models.

Activity Factor Example #2

Given Assumptions:Use the results from the Activity Factor Example #1

ADDS #2 call model50 subscriber terminated ADDS #2 Erlangs for the busy hourForward Link Call Model: 70% Full, 0% Half, 0% Quarter, 30% EighthReverse Link Call Model: 10% Full, 0% Half, 0% Quarter, 90% Eighth

Forward Link Activity Factor: (using [EQ A4-2])AF = = 73.75%

Reverse Link Activity Factor: (using [EQ A4-2])AF = = 21.25%

Combined call modelCombined Erlangs = 75 + 50 = 125 ErlangsForward Link AF = = 0.76375 = 76.38%Reverse Link AF = = 0.23875 = 23.88%

For the combined call model in Example #2, an ADDS terminated subscriber class woucreated with a forward link activity factor of 76.38%, a reverse link activity factor of 23.88%,simulated with 125 Erlangs of usage. Since there are several implementation options, it is upsystem designer to choose the appropriate option for a particular system simulation.

1 75×( ) 0.5 0×( ) 0.25 0×( ) 0.125 25×( )+ + +

1 15×( ) 0.5 0×( ) 0.25 0×( ) 0.125 85×( )+ + +

1 70×( ) 0.5 0×( ) 0.25 0×( ) 0.125 30×( )+ + +

1 10×( ) 0.5 0×( ) 0.25 0×( ) 0.125 90×( )+ + +

75 0.78125×( ) 50 0.7375×( )+[ ] 125⁄75 0.25625×( ) 50 0.2125×( )+[ ] 125⁄


A5


uringte thee are

tingable ofoice

whichvoicetivityides. The

eringatingrringtextaddedDDS

y dataload.versendedging

A5.3 ADDS Over the Traffic Channel (during an active call)

For subscriber originated or terminated ADDS text messaging delivered on a traffic channel dan active voice call, the recommended approach to simulate this type of load is to estimaincrease of the voice activity factor created by the ADDS traffic load for this scenario. Thertwo basic options that can be used to implement this approach.

The first option is to distribute the ADDS traffic load proportionately across all of the exisvoice subscriber classes. If the percentage of ADDS enabled subscribers, which are capreceiving ADDS text messaging, is fairly high when compared to the total population of vsubscribers, then this is the preferred option.

The second option is to create a new subscriber class (or a set of subscriber classes),correlates to the ADDS enabled subscribers in the system. A proportionate amount of thetraffic load is then distributed to this new ADDS subscriber class and an adjusted voice acfactor is used to correlate to the ADDS traffic load for this scenario. The following section prova method to estimate the voice activity factor impact of the additional ADDS text messagingmethod can be used for both of the options mentioned above.

A5.3.1 ADDS Activity Factor Impact

The following approach can be used for any ADDS application that has the capability of delivtext messages to or from a subscriber unit during an active voice call. The first step to estimthe ADDS activity factor impact is to characterize the amount of text messaging that is occuon the forward and reverse links. If there are multiple ADDS applications that can delivermessaging during an active voice call, the text messaging impact for each application can betogether for a total text messaging load for the forward and reverse links. Regardless of the Aapplication or whether it is a subscriber originated or a subscriber terminated call type, the kethat is required is an estimate of the total forward and the total reverse link text messagingOnce the forward and reverse link text messaging load is known, a new set of forward and revoice activity factors can be calculated. The following set of examples show a recommemethod of how to estimate the voice activity factor impact due to an SMS text messaapplication for a Rate Set 1 and a Rate Set 2 system.


Given Assumptions:Rate Set 1 (8,600 bits per second)5,000 current busy hour voice Erlangs40.0% current Voice Activity Factor (VAF) for forward & reverse links375,000 busy hour subscriber terminated SMS messages (average)75,000 busy hour subscriber originated SMS messages (average)120 busy hour Bytes per message (average)8 bits per Byte


A5


Forward Link VAF Calculation:

total bits for the busy hour

total full rate voice bits for the busy hour

total SMS full rate bits for the busy hour

total voice + SMS full rate bits for the busy hour

= 40.23% new forward link VAF

Reverse Link VAF Calculation:





= 40.05% new reverse link VAF


Given Assumptions:Rate Set 2 (13,350 bits per second)5,000 current voice Erlangs40.0% current Voice Activity Factor (VAF) for forward & reverse links375,000 busy hour subscriber terminated SMS messages (average)75,000 busy hour subscriber originated SMS messages (average)120 busy hour Bytes per message (average)8 bits per Byte

Forward Link VAF Calculation:





= 40.15% new forward link VAF

Reverse Link VAF Calculation:





5000 8600 3600×× 1.54811×10=

0.40 1.548× 11×10 6.19210×10=

375000 120 8×× 3.68×10=

6.19210×10 3.6

8×10 6.22810×10=+

6.22810×10 1.548

11×10⁄ 0.4023=

5000 8600 3600×× 1.54811×10=

0.40 1.548× 11×10 6.19210×10=

75000 120 8×× 7.27×10=

6.19210×10 7.2

7×10 6.199210×10=+

6.199210×10 1.548

11×10⁄ 0.4005=

5000 13350 3600×× 2.40311×10=

0.40 2.403× 11×10 9.61210×10=

375000 120 8×× 3.68×10=

9.61210×10 3.6

8×10 9.64810×10=+

9.64810×10 2.403

11×10⁄ 0.4015=

5000 13350 3600×× 2.40311×10=

0.40 2.403× 11×10 9.61210×10=

75000 120 8×× 7.27×10=

9.61210×10 7.2

7×10 9.619210×10=+


A5


activitye only

ing on

rafficmay

ouldloador therth

ll inationADDSe toolatedot of

= 40.03% new reverse link VAF

For both of the examples above, the subscriber terminated SMS messages were the onlythat was considered for the forward link and the subscriber originated SMS messages were thactivity that was considered for the reverse link. Acknowledgement messaging that is occurrthe opposite links for both call types was not considered.

A5.4 Evaluating the ADDS load

If the feature allowing subscriber originated and subscriber terminated ADDS over the tchannel has just recently been deployed in a system, the amount of ADDS traffic in the systemnot be large enough to justify the effort of simulating this load. The system designer shevaluate the ADDS traffic load against the voice traffic load and determine if the ADDS trafficis significant enough to include in the simulation. The same evaluation should be performed fADDS traffic load delivered over the traffic channel during a voice call to determine if it is woadjusting the voice activity factor of the voice calls to account for the ADDS traffic load.

If new ADDS subscriber classes are created and the ADDS traffic load is relatively smacomparison to the voice traffic load, then it should be known that a large number of simuldrops may be necessary in order to achieve adequate subscriber statistics for thesubscribers. Depending upon the amount of ADDS traffic load, the number of drops may bexcessive to even consider. As a result, a small amount of ADDS traffic load can still be simuwith a typical number of drops, but the ADDS subscriber statistics should not be given a lrelevance due to the statistically small sample size.

9.619210×10 2.403

11×10⁄ 0.4003=


Running canal.pl
Appendix
A6
Table of Contents
- 3

- 3

- 36 - 36 - 56 - 5

- 5

A6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6

A6.2 Loading canal.pl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6

A6.3 Running canal.pl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6A6.3.1 Command Line Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA6.3.2 Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA6.3.3 Output files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A6.4 canal.pl Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A6


A6

Appendix A6: Running canal.pl

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


A6


rocessch as

on onDMAd by

ry.n thet be

by

ption,of the

. Thecellample,g thesticalcell

A6.1 Introduction

The program named canal.pl is a script written in the Perl language that is used to post pIS-2000 1X time-sliced simulation output files into the desired RF system design statistics susector throughput, end user throughput, and RF reliability. This appendix provides informatihow to run canal.pl and how to interpret the canal.pl outputs. Refer to Chapter 9 “NetPlan CSimulator Statistical Output and Analysis” for additional information on the procedures usecanal.pl to compute the output statistics.

A6.2 Loading canal.pl

The canal.pl script is located relative to $NETPLANHOME in the ./admin/utilities directoTherefore, the default location would be /usr/NetPlan/admin/utilities. Perl 5 must be loaded oUNIX workstation and be available for use in the /usr/bin/perl directory. The canal.pl file musmade executable so that it can be run from the command line.

A6.3 Running canal.pl

The canal.pl script is run from the UNIX command line of any directory with write permissionentering the following:

canal.pl --ignore_file <ignore file path name> --mindatarate <2-6>--warmup <time> --path <analysis path name> --rc <radioconfiguration RC3, RC4, or RC5>

Example:

canal.pl --ignore_file /home/engineer/cells_to_ignore--mindatarate 3 --warmup 110 --path /home/engineer/NPProjects/cdma20001X --rc RC3,RC4

A6.3.1 Command Line Options

There are several command line options that can be used in running canal.pl. To invoke the othe option name is preceded by a double dash (--) and followed by the option value. Eachcanal.pl command line options is described in further detail below.

A6.3.1.1 ignore_file

It may be of interest to complete a statistical analysis on a subset of cells in the simulation“ignore_file” option can be used to specify the path to a file that contains a list of NetPlannumbers that are to be excluded from the canal.pl statistical analysis post processing. For exif only the performance for the core cells in the system is of interest, then all of the cells alonedge of the system can be listed in the “ignore_file” so as to be eliminated from the statianalysis. The “ignore_file” is a plain ASCII file with one column that contains a NetPlan


A6


file,nal.the

nteredtherate.

n the

imumilureo thehapter

. Thef all

ered,Time-red

. Forname

gineer/sed by

number to be ignored per row. A list of the valid cell numbers can be found in the SectorMapwhich is located in the CDMA directory of the NetPlan analysis. Use of an ignore_file is optioIf no ignore_file is specified, then the statistical processing is completed for all cells insimulation.

A6.3.1.2 mindatarate

The minimum data rate used in the high speed channel request failure computations is eusing the “mindatarate” command line option. Table A6-1 provides a mapping betweennumber entered in the “mindatarate” command line option and the actual IS-2000 1X dataThis option only corresponds to RC3 and RC4, since the current implementation of RC5 oforward link is only for the 14.4 kbps FCH.

If the “mindatarate” command line option is not entered, then the script uses the default mindata rate of 153.6 kbps (“mindatarate” = 6). In order to receive valid outputs for the HSreqfastatistics (refer to Section A6.4, "canal.pl Outputs"), the “mindatarate” option must be set tsame value that was used for the “Fwd. Data Rate Outage” parameter in NetPlan (refer to C6 for additional information on setting the “Fwd. Data Rate Outage” parameter).

A6.3.1.3 warmup

The simulation warm-up time in seconds is entered using the “warmup” command line optionwarm-up time specifies the amount of simulation time that is removed from the beginning othe statistics files, prior to computing the RF performance metrics. If no warm-up time is entthe script uses the default warm-up time of 100 seconds. Refer to Section 9.5.2, “IS-2000 1XSliced Simulation Warm-up Time”, for additional information on determining the requisimulation warm-up time.

A6.3.1.4 path

The path to the NetPlan analysis directory is entered using the “path” command line optionexample, if the project directory were located at /home/engineer/NPProjects and the analysiswere cdma20001X, then the path to enter at the canal.pl command line would be /home/enNPProjects/cdma20001X. The path specifies the location of the input files to be post procescanal.pl.

Table A6-1: IS-2000 1X Data Rate to “mindatarate” Mapping

mindatarate IS-2000 1X Data Rate2 9.6 kbps3 19.2 kbps4 38.4 kbps5 76.8 kbps6 153.6 kbps


A6


radioy theduce

C4, orusinge the

XX,veralMA

onced from

o toing thed to

f theides

on. The.

er toon

A6.3.1.5 rc

The cdma2000 1X CellStatTS_XX file contains a number of statistics that are logged on a perconfiguration basis (RC3, RC4, and RC5). The "rc" command line option is used to specifradio configuration for the statistics that are to be included in the canal.pl processing to prothe output statistics. The radio configurations are entered on the command line as RC3, RRC5. If multiple radio configurations are desired, then they are entered on the command linea comma separator. If no radio configuration is entered using this option, then canal.pl will usstatistics from all radio configurations.

A6.3.2 Input Files

The input statistics files required to run canal.pl are CellStatTS_XX, CellStatTSRev_MobileTputStat_XX, and SectorTputStat_XX. The canal.pl script also makes use of sesystem files, namely SectorMap, CallModelMap, and SimStat which are located in the CDdirectory of the simulation analysis. The canal.pl script locates all of the files automaticallythe analysis path name is entered at the command line. The canal.pl script can be executeany directory as long as the user has write permissions to the directory.

A6.3.3 Output files

The canal.pl output goes directly to the standard output; therefore, the output will typically gthe screen unless otherwise redirected. To save the output to a file, redirect the output usstandard unix redirect operator (“>”). As an example, the following command would be usesave the canal.pl output to a file named “canal_output” in the current directory.

canal.pl --ignore_file /home/engineer/cells_to_ignore--mindatarate 3 --warmup 110 --path /home/engineer/NPProjects/cdma20001X > canal_output

A6.4 canal.pl Outputs

The canal.pl output is a tab delimited ASCII file that contains a summary of a number opertinent IS-2000 1X time-sliced RF performance statistics. The top row of the output file provthe column header. This header depends on the number of sites and sectors in the simulatifirst column provides the statistic name and the remaining columns contain the output data

Table A6-2 provides a brief description of each of the entries in the canal.pl output file. RefChapter 9 “NetPlan CDMA Simulation Statistical Output and Analysis” for further informationhow canal.pl computes each of the output statistics.


A6


itsnd

ts.tts.tts.nall

is

l

4)ted

4)ted

desndhs

d

d

d

Table A6-2: canal.pl Output Statistics

Statistics Name Statistics Definitionmean_sector_pwr(W) Mean value of the total sector power at the BTS antenna port in un

of Watts. The mean value is computed over all simulation drops atime-slices.

pilot_pwr(W) Sector pilot channel power at the BTS antenna port in units of Watpage_pwr(W) Sector page channel power at the BTS antenna port in units of Wasync_pwr(W) Sector sync channel power at the BTS antenna port in units of Wamean_sect_TCH_pwr(W)Mean value of the sector traffic channel power at the BTS anten

port in units of Watts. The mean value is computed over asimulation drops and time-slices.

FCH_97% The 97th-percentile forward link FCH channel element usage. Thstatistic includes both 9.6 kbps FCH’s and 14.4 kbps FCH’s.

9.6FCH_97% The 97th-percentile forward link 9.6 kbps (RC3 and RC4) FCHchannel element usage.

14.4FCH_97% The 97th-percentile forward link 14.4 kbps (RC5) FCH channeelement usage.

FSCH_97% The 97th-percentile forward link SCH channel element usage.num_9.6fund_WC The mean value of the number of 9.6 kbps (RC3 and RC

fundamental channel Walsh codes used. The mean value is compuover all simulation drops and time-slices.

num_14.4fund_WC The mean value of the number of 14.4 kbps (RC3 and RCfundamental channel Walsh codes used. The mean value is compuover all simulation drops and time-slices.

num_supp_WC The mean value of the number of supplemental channel Walsh coused. The mean value is computed over all simulation drops atime-slices. Note that the SCH Walsh codes are of varying lengtwhich correspond to the various SCH data rates.

Fwd_BurstErl_all Forward link bursting Erlangs for voice and all data rates combinetogether.

Fwd_TotErl_all Forward link total Erlangs for voice and all data rates combinetogether.

Fwd_ActErl_all Forward link active Erlangs for voice and all data rates combinetogether.

Fwd_ActErl_voice Forward link active Erlangs for voice subscribers only.Fwd_ActErl_9.6k Forward link active Erlangs for 9.6 kbps FCH only.Fwd_ActErl_19.2k Forward link active Erlangs for 19.2 kbps SCH only.Fwd_ActErl_38.4k Forward link active Erlangs for 38.4 kbps SCH only.Fwd_ActErl_76.8k Forward link active Erlangs for 76.8 kbps SCH only.Fwd_ActErl_153.6k Forward link active Erlangs for 153.6 kbps SCH only.


A6


d

ofmnee”

ed

ed

ed

Fwd_ActErl_data Forward link active Erlangs for all data subscribers combinetogether.

Fwd_ActErl_14.4k Forward link active Erlangs for 14.4 kbps FCH only.Dormant_mob Number of Erlangs associated with the dormant subscribers.Blocking_WC Fraction of subscribers who experienced Walsh code blocking.HSreqfailure The fraction of data subscribers who requested a high speed SCH

a given rate but failed to receive a SCH of a user definable minimurate. The minimum rate is set using the “mindatarate” command lioption, and also corresponds to the “Fwd. Data Rate Outagparameter in NetPlan.

Fwd_Rel_all Forward link RF reliability for all voice and data subscriberscombined together.

Fwd_Rel_voice Forward link RF reliability for voice subscribers only.Fwd_Rel_9.6k Forward link RF reliability for 9.6 kbps FCH only.Fwd_Rel_19.2k Forward link RF reliability for 19.2 kbps SCH only.Fwd_Rel_38.4k Forward link RF reliability for 38.4 kbps SCH only.Fwd_Rel_76.8k Forward link RF reliability for 76.8 kbps SCH only.Fwd_Rel_153.6k Forward link RF reliability for 153.6 kbps SCH only.Fwd_Rel_data Forward link RF reliability for all data subscribers.Fwd_Rel_14.4k Forward link RF reliability for 14.4 kbps FCH only.RevRise(dB) Reverse link noise rise in dB.RevFr Reverse link F-Factor.RevIo(dBm) Reverse link Io in units of dBm.RevIt(dBm) Reverse link It in units of dBm.RSCH_97% 97th-percentile reverse link SCH channel element usage.Rev_BurstErl_all Reverse link bursting Erlangs for voice and all data rates combin

together.Rev_TotErl_all Reverse link total Erlangs for voice and all data rates combin

together.Rev_ActErl_all Reverse link active Erlangs for voice and all data rates combin

together.Rev_ActErl_voice Reverse link active Erlangs for voice subscribers only.Rev_ActErl_fundamentalReverse link active Erlangs for 9.6 kbps FCH only.Rev_ActErl_9.6k Reverse link active Erlangs for 9.6 kbps SCH only.Rev_ActErl_19.2k Reverse link active Erlangs for 19.2 kbps SCH only.Rev_ActErl_38.4k Reverse link active Erlangs for 38.4 kbps SCH only.Rev_ActErl_76.8k Reverse link active Erlangs for 76.8 kbps SCH only.Rev_ActErl_153.6k Reverse link active Erlangs for 153.6 kbps SCH only.


Statistics Name Statistics Definition


A6


ed

er

er

CH

9.6

inkink.inkink.inkink.inkrse

inkink.ed

s

d

Rev_ActErl_14.4k Reverse link active Erlangs for 14.4 kbps FCH only.Rev_ActErl_data Reverse link active Erlangs for all data subscribers combin

together.Rev_Sat_all The fraction of all data and voice subscribers who experienced pow

saturation on the reverse link.Rev_Sat_voice The fraction of all voice subscribers who experienced pow

saturation on the reverse link.Rev_Sat_fundamental The fraction of data subscribers who were assigned a 9.6 kbps F

only and experienced power saturation on the reverse link.Rev_Sat_9.6k The fraction of data subscribers who were assigned a reverse link

kbps SCH and experienced power saturation on the reverse link.Rev_Sat_19.2k The fraction of data subscribers who were assigned a reverse l

19.2 kbps SCH and experienced power saturation on the reverse lRev_Sat_38.4k The fraction of data subscribers who were assigned a reverse l



153.6 kbps SCH and experienced power saturation on the revelink.

Rev_Sat_14.4k The fraction of data subscribers who were assigned a reverse l14.4 kbps FCH and experienced power saturation on the reverse l

Rev_Sat_data The fraction of data subscribers (all data rates) who experiencpower saturation on the reverse link.

Rev_Rel_all Reverse link RF reliability for all voice and data subscribercombined together.

Rev_Rel_voice Reverse link RF reliability for voice subscribers only.Rev_Rel_fundamental Reverse link RF reliability for 9.6 kbps FCH only.Rev_Rel_9.6k Reverse link RF reliability for 9.6 kbps SCH only.Rev_Rel_19.2k Reverse link RF reliability for 19.2 kbps SCH only.Rev_Rel_38.4k Reverse link RF reliability for 38.4 kbps SCH only.Rev_Rel_76.8k Reverse link RF reliability for 76.8 kbps SCH only.Rev_Rel_153.6k Reverse link RF reliability for 153.6 kbps SCH only.Rev_Rel_14.4k Reverse link RF reliability for 14.4 kbps FCH only.Rev_Rel_data Reverse link RF reliability for all data subscribers combine

together.Chan_cards_97% 97th-percentile MCC-1X channel card usage.




A6


ll4.2

ll4.2

horor

thoror

Fwd_EUtput_XX(bits/sec)End user throughput on the forward link. “XX” is replaced by the camodel name and service type. With reference to Section 9.5.5.“IS-2000 1X (time-sliced) End User Throughput”, this statistic iscomputed using the “average end user experience” approach.

Rev_EUtput_XX(bits/sec)End user throughput on the reverse link. “XX” is replaced by the camodel name and service type. With reference to Section 9.5.5.“IS-2000 1X (time-sliced) End User Throughput”, this statistic iscomputed using the “average end user experience” approach.

Fwd_Sect_tput(bits/sec) Forward link sector throughput in units of bits per second. Witreference to Section 9.5.5.5.2 “IS-2000 1X (time-sliced) SectThroughput”, this statistic is computed using the “average of sectthroughput” approach.

Rev_Sect_tput(bits/sec) Reverse link sector throughput in units of bits per second. Wireference to Section 9.5.5.5.2 “IS-2000 1X (time-sliced) SectThroughput”, this statistic is computed using the “average of sectthroughput” approach.




A6


by aciated

The canal.pl script provides several variations of each statistic, with each being identifiedunique column heading. Table A6-3 provides a description of the statistic types and assocolumn headings.

Table A6-3: Statistics Column Headings

Column Heading Descriptionsystem The system statistics provide a summation of all the sector

statistics. In some cases, for example Rise(dB), thesummation of all sector statistics is of little interest;however, for consistency the summation is provided.

mean/cell The mean/cell statistics provide the mean value of all of theindividual cell statistics.

high_cell The high_cell column provides the cell number thatproduced the highest value for the particular statistic.

high_value The high_value statistics that are located adjacent to thehigh_cell number provide the highest value of the givenstatistic across all cells in the simulation.

low_cell The low_cell column provides the cell number thatproduced the lowest value for the particular statistic.

low_value The low_value statistics that are located adjacent to thelow_cell number provide the lowest value of the givenstatistic across all cells in the simulation.

mean/sect The mean/sect statistics provide the mean value of all of theindividual sector statistics.

high_sect The high_sect column provides the sector number thatproduced the highest value for the particular statistic.

high_value The high_value statistics that are located adjacent to thehigh_sector number provide the highest value of the givenstatistic across all sectors in the simulation.

low_sect The low_sect column provides the sector number thatproduced the lowest value for the particular statistic.

low_value The low_value statistics that are located adjacent to thelow_sector number provide the lowest value of the givenstatistic across all sectors in the simulation.

Cell The statistics that are in the “Cell” columns are either a sumor mean value, as appropriate, of the statistics that arecomputed for each individual sector at the given cell site.

Sect Statistics for each individual sector in the simulation areprovided in the “Sect” columns.


Modeling Inter-SystemInterference

Appendix

A7
Table of Contents
A - 3

- 3

- 4

5

6

- 11- 11- 12 - 14 - 15

A7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A7.2 Inter-System Interference Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A7.3 Generate CDMA ISI Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A

A7.4 Inter-System Interference Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . A -

A7.5 Interpreting Simulator Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A -

A7.6 Analysis of System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A A7.6.1 Drive Test Data - New AMPS ERP. . . . . . . . . . . . . . . . . . . . . . . A A7.6.2 AMPS Channelization - Kavg - Samps . . . . . . . . . . . . . . . . . . . . A A7.6.3 Additional Images Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . AA7.6.4 Corrective - Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A


A7

Appendix A7: Modeling Inter-System Interference

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

_______

NOTES

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________

__________________________________________________________________________________________________


A7


MPShen

tion.MAPS-

MA/

atednalog

e toergy

lsonalog

tion:

MAMPS-1.1 of

e aivenstem

A7.1 Overview

There are several forms of inter-system interference (ISI). This chapter will concentrate on Abase site to CDMA subscriber interference at 800 MHz. This form of interference occurs wstrong AMPS signals force the CDMA subscriber receiver into a non-linear region of operaThese AMPS signals then mix together producing odd order products which fall within the CDsignal bandwidth and contribute to the background noise. A procedure for modeling AMCDMA ISI using the NetPlan CDMA simulator is presented here.

Further information regarding inter-system interference can be found in Chapter 9 of the “CDCDMA2000 1X RF Planning Guide” (March 2002).

A7.2 Inter-System Interference Overview

The worst case of AMPS to CDMA interference occurs when a CDMA subscriber unit is locfar enough away from its serving cell(s) yet close enough to an AMPS analog site such that aenergy is strong relative to the incoming CDMA signal, causing the CDMA call to drop. Duthe intermodulation (IM) characteristics of the subscriber unit’s receiver, the analog enappears within the CDMA frequency band in the form of noise (interference).

In addition to the subscriber’s proximity to the analog and CDMA sites, ISI intensity is aaffected by analog and CDMA signal strengths, and the quantity and frequencies of the asignals.

Based on studies of interference conditions, ISI can be quantified using the following equa

[EQ 1-1]

where:

IAMPS =Subscriber generated IM (dBm)

SAMPS =AMPS signal strength at subscriber unit’s antenna (dBm)

IP3 =Subscriber unit’s third order intercept point (dBm)

Kavg =Factor based on quantity and frequency of AMPS carriers, typically 24 dB

The IS-98 fix for this phenomenon is the use of a 20 dB attenuation pad inside the CDsubscriber unit that takes effect under strong AMPS signal conditions. The result is that the AISI signal gets attenuated 60 dB versus only 20 dB for the CDMA signal. [See Chapter 9.2.the “CDMA/CDMA2000 1X RF Planning Guide” (March 2002).]

For the CDMA RF system designer, the condition for which AMPS-CDMA ISI should bconcern is when CDMA is not anticipated to be co-located at every analog site within a gcoverage area. However, there will still be a chance of ISI resulting from the other cellular syoperating in the area.

I AMPS 3SAMPS 2IP3– Kavg+=


A7


tPlantemntial

ure alsod total

ape to

er IM,tivate

irst, aMPSl loss

PSAMPS

To assist the CDMA system designer in assessing potential AMPS-CDMA ISI issues, the NeCDMA simulator has the ability to produce an ISI File which is then used in the Inter-SysInterference Modeling feature of NetPlan. This feature allows the user to highlight any potenegative effects on system performance, such as capacity and coverage issues. This featgives the user the ability to select the loss value for the subscriber unit attenuation pad ansignal strength at which the pad should begin to take effect.

A7.3 Generate CDMA ISI Feature

The “Generate CDMA ISI” feature is responsible for producing the ISI File. The ISI File is a mof the resultant IM interference energy created within the CDMA subscriber unit which is dustrong local AMPS energy. As AMPS signals must be relatively strong to cause the subscribthe region of ISI problems is confined to the immediate area around each AMPS site. To acthe Generate CDMA ISI feature, see Figure A7-1: Generate CDMA ISI below:

Figure A7-1: Generate CDMA ISI

The Generate CDMA ISI feature calculates the IM energy through several internal steps. Fsimple internal straight line propagation prediction model is used to arrive at near-site Adownlink signal levels. The prediction model slope and intercept are set up for near-celconditions. All the AMPS cell sites (sites operating in both the A band and B band of the AMspectrum) must be added to the NetPlan analysis prior to this step. Only a subset of the usualcell site information is required:


A7


r into

ulatedMA

s seent beselectede bysion”n the

• cell site name

• location

• antenna height

• antenna bore-site angle

• ERP of each sector

This propagation prediction model does not take antenna pattern, terrain elevation or clutteaccount.

The second internal step calculates the resultant IM energy by using equation 1-1. Each calcvalue is placed into the map which is the ISI File. This file is then used by the NetPlan CDsimulator during each simulation run.

A7.4 Inter-System Interference Modeling

Activating the ISI feature is done through the CDMA Parameters - RF Environment screen, ain Figure A7-2. First, the “Enable ISI Modeling” button must be checked, an ISI File musselected, and a suppression value must be entered. Next, a method and threshold must befor determining when each subscriber unit will activate its internal attenuator. This is donselecting the “When Subscriber (IF) Received Power Exceeds” button in the “Apply Suppressection of the window and entering its threshold value. Refer to Chapter 6 for more details osettings of the ISI modeling system parameters.


A7


andblishtablish.) is at

Figure A7-2: Inter-System Interference Modeling

A7.5 Interpreting Simulator Results

The effects of ISI can be viewed in the NetPlan CDMA simulator results, both graphicallystatistically. It is recommended that a system be run initially with ISI turned off in order to estaa baseline (see Figure A7-3). Whether or not the system should be optimized in order to esthis baseline (final sites selected and the pilot, page, and sync power levels determined, etcthe discretion of the designer.


A7


Figure A7-3: Baseline Ec/Io Image

AMPS-only sites

Co-LocatedCDMA & AMPS


A7


ining. Thisr as a

by eachch ashangeg thethan

agende willly touator

As AMPS signals must be relatively strong to cause subscriber unit receive IM, regions contapotential ISI problems are typically confined to the immediate area around each AMPS sitecan be evident upon review of a simulator image, such as Best Ec/Io, as ISI can appeacoverage hole around the AMPS sites. Each hole representing the interference generatedAMPS cell site. The radius of the holes is proportional to the AMPS cell site parameters, suantenna height and ERP. A hole will usually appear as a round pronounced color/value cwhen this image is viewed. The values found in the image bins immediately surroundineffected area will be less than T-DROP. The values within the ISI affected area will be lessthe finger locking threshold (< -23.75 dB).

Not all areas of ISI interference will be readily apparent, due to the fact that the Best Ec/Io imis not a function of the AMPS-CDMA ISI alone, but also a function of CDMA interference apilot signal strength. In general, subscribers landing in areas that have strong pilot coveragnot be as badly affected, often times maintaining good links. Coverage holes are not likeappear in these areas. If subscriber units which do not have the built-in ISI protection attenare used in the system, poorer performance could result as seen in Figure A7-4.


A7


-in ISI

Figure A7-4: Ec/Io with ISI and no Attenuation Pad

The same system achieves better performance when subscriber units do have the builtprotection attenuator as seen in Figure A7-5.


A7


Figure A7-5: Ec/Io with ISI and Attenuation Pad


A7


ct ofhave

whye after

aboveions

erages, and

outeter

there

d byetPlan

g ISI

uses

a (withD).

When reviewing statistics, parameters like PcntMobGood will reflect the negative impaAMPS-CDMA ISI. The PcntMobGood is a measure of the percentage of subscribers thatgood best serving cell links. Adding AMPS-CDMA ISI tends to lower this percentage. This isit is important to have a baseline of non-ISI performance so that a comparison can be madISI is added. Thereby, the impact of ISI can be assessed.

If ISI is strong enough, it can turn cells that had a high percentage of good connections (90%) into serious under-performers. These cells will likely be located in heavily-loaded regwhere connections are being made with subscriber units at the fringe of their individual covareas. It is likely that these subscriber units would just barely be reaching their Eb/No targetwould be the first to fail their connections when introducing AMPS-CDMA ISI.

A7.6 Analysis of System Performance

As alluded to above, there are ways to reduce the impact of AMPS-CDMA ISI withunderestimating it. In other words, there is a lot of margin built into the suggested paramsettings. If the AMPS-CDMA ISI impact for a given system is determined to be too severe,are acceptable ways of reducing it while still being conservative in its estimate.

The accuracy of the ISI File created using the Generate CDMA ISI feature may be improveincorporating data gathered during drive tests of the AMPS systems and readjusting the NAMPS cell site ERP.

The factor Kavg can be used to readjust the AMPS cell site ERP and thus reduce the resultinfrom the site.

Adjusting these parameters can have a dramatic impact on the simulation results.

A7.6.1 Drive Test Data - New AMPS ERP

The straight line propagation prediction tool imbedded within the Generate CDMA ISI featurethe following equation for 800 MHz systems:

PL = 43.4 + 22 * log [D] [EQ 1-2]

where:

PL = Path Loss (dB) from the base site antenna to the subscriber position.

D = Distance, in meters, from the base site antenna center line to the subscriber antennsuch small cell radii, the base site antenna height becomes significant in determining


A7


wing

by thegth inminedulatedrencesignal

r. The

e. The

odd-ers.ctor.cribern 1-Theis at of ISI

annelcingould

The signal strength predicted for the subscriber location is then determined using the folloequation:

Mobile_RX_PwrdBm = Base_ERPdBm - PLdB [EQ 1-3]

Drive test data for the AMPS system can be used to calculate power offsets to the ERP usedGenerate CDMA ISI feature. These ERP offsets, in effect, make the predicted signal strenthe ISI file more accurately reflect the measured data. Several data points should be exawithin a 400 meter radius of the AMPS site. The predicted signal strength should then be calcfor each data point location using equations equation 1-2 and equation 1-3. A delta dB diffecan then be determined for each of the data point locations by subtracting the predictedstrength from the measured signal strength.

∆_Mob_PwrdB = Measured_RX_PwrdBm - Mobile_RX_PwrdBm [EQ 1-4]

All of the ∆_Mob_Pwr values for the data points being examined should be averaged togetheaveraged value, Avg_∆_Pwr, should then be added to the AMPS cell/sector base ERP.

New_Base_ERPdBm = Base_ERPdBm+ Avg_∆_PwrdB [EQ 1-5]

The new base ERP value can then be placed into the NetPlan AMPS cell site data basGenerate CDMA ISI feature would be re-run and a more accurate ISI file would result.

A7.6.2 AMPS Channelization - Kavg- Samps

The quantity and frequency of AMPS carriers in each AMPS cell site (inputs to determiningorder intermodulation [IM] products) impact the resultant induced ISI for the CDMA subscribThis is handled by the Generate CDMA ISI feature by entering the AMPS ERP for each seInternally, the Generate CDMA ISI feature uses equation 1-1 to calculate the resultant subsunit internal ISI level from the signal level at positions close to the AMPS cell site. In equatio1, the value Kavg(dB) is derived from the quantity and frequency of AMPS carriers in a sector.value for Kavg (24 dB) is hard coded into the NetPlan Generate CDMA ISI feature. Thisconservative value and depicts a highly channelized sector (13 channels/sector). The amounencountered near an AMPS site may be lower if the site has fewer channels than 13.

NOTE:Figure A7-6: Kavg vs. AMPS Channels/Sector shows the relationship of Kavg versus the numberof AMPS traffic channels per sector. It should be noted that this graph is based on the chgrouping/spacing used in a 7 cell, 3 sector reuse pattern. This is significant as the channel spadirectly impacts the resultant intermodulation products and thus the ISI levels. This graph wnot be valid for other channel spacings.


A7


er sitenew

tly byhisbase.

Figure A7-6: Kavg vs. AMPS Channels/Sector

If AMPS channelization data is available which shows a lower average channel usage p(including the heavily loaded cells), then the graph in Figure A7-6 may be used to select avalue for Kavg for each sector.

Since Kavg can not be entered on a per-sector basis, an adjustment can be made indireccalculating the impact a unique Kavg/sector value would have upon the sector ERP value. Tupdated ERP value (ERP_new) could then be entered into the NetPlan AMPS cell site dataSee equation 1-6 and equation 1-7 below:

∆_ERP = (24 dB - Kavg_new)/3 [EQ 1-6]

ERP_new = ERP_old -∆_ERP [EQ 1-7]

where:

Kavg_new = value of Kavg/sector taken from Figure A7-6 (dB)ERP_old = current AMPS sector ERP (dBm)∆_ERP = differential used to adjust ERP_old (dB)ERP_new = new ERP value to be entered for the AMPS Sector (dBm)

2 4 6 8 10 12 14 16AMPS Channels

-5

30

25

20

15

10

5

0

Kav

g.

Based on a 7 cell, 3 sector reuse pattern


A7


n the

e. The

o dueationcinga 40

whengins)itched

(for in-imagesis noted tos maye ISI

sIn this(Please

whichTCH

Although the resulting changes in AMPS ERP may seem small, their reduction impact uporesulting ISI levels in the ISI file will equal three times the∆_ERP value.

Example:

AMPS ERP = 50 dBmNo. channels = 6Kavg_new = 12.5 (taken from Figure A7-6)

using equation 1-6:

∆_ERP = (24 dB - 12.5dB) / 3 = 3.8 dB

using equation 1-7:

ERP_new = 50 dBm - 3.8 dB = 46.2 dBm

The new sector ERP value can then be placed into the NetPlan AMPS cell site data basGenerate CDMA ISI feature would be re-run and a more accurate ISI file would result.

A7.6.3 Additional Images Required

The approach taken by the industry to counter the reduction of achievable forward link Eb/Nto ISI is to activate a 20 dB attenuator in the front end receive path of the subscriber unit. Equequation 1-1 shows that this attenuation would reduce the CDMA signal by 20 dB while reduthe intermodulation [IM] products by 60 dB. The difference between these two new levels isdB improvement in Eb/No. The NetPlan CDMA simulator behaves in the same manneradditional loss is added to the penetration loss (for in-vehicle, in-building, and body loss marfor a given subscriber class. The additional penetration loss acts in the same way as the swattenuator in that they improve ISI performance.

The images produced from a probe subscriber which has losses added at the subscriber unitvehicle, body loss, etc.) will represent “best-case” ISI performance images because theseshow the additional protection provided by the additional loss. However, a subscriber whoin-vehicle, in-building, or subject to body loss, will endure elevated ISI problems as comparthe images. It is therefore prudent to examine the reduction in performance such userencounter if they are located close to an ISI trouble region by generating a conservativperformance image.

By defining the probe subscriber tonot include losses for in-vehicle, in-building and body losmargins, images can be generated which reflect a more conservative performance result.case the probe subscriber would use a subscriber class that has no penetration loss (0 dB).see Chapter 6 for further details regarding setting parameters for the probe subscriber.)

In systems where ISI is being analyzed, the recommended procedure for producing imagesare used when examining system coverage (e.g. Forward Required Power, Forward


A7


as the, andhich

non-erage

lossesd toity toey are

these

PSratorse leastsites.nce and

ence isthemonesusing

pilot,les thecreasee rise

r thanosesmalltisticalnts thepresent

Threshold, Best Ec/Io and CDMA Composite coverage images) is to producetwo sets of images:

• The first set requires that the probe subscriber has the same characteristicsdropped subscribers (i.e. penetration loss includes losses for in-vehicle, in-buildingbody loss margins). This set of images will be used to show coverage problems ware due to high path loss, high F-factor interference and regions of multipledominant pilots. These images can not be used to study the impacts of ISI upon covas they are overly optimistic.

• The second set requires the probe subscriber not include any penetration loss (i.e.for in-vehicle, in-building, and body loss margins). This set of images will be useexamine ISI related coverage problems which are encountered within close proximAMPS cell sites. These images can not be used to represent overall coverage as thoverly optimistic in areas of high path loss.

Note: Chapters 11 through 13 describe the production of images. The same process inchapters are followed for producing both sets of images.

A7.6.4 Corrective - Actions

As stated earlier, AMPS-CDMA ISI is of little concern when CDMA is co-located at every AMcell (1:1 deployment). However, this approach is not followed by all systems. System opedesire to have the best coverage and best quality of service for a given subscriber load with thamount of cell sites. This leads to system designs which have a reduced overlay of CDMASome systems are designed with an AMPS to CDMA deployment ratio of 2:1 or greater. Opreliminary design yields the number of CDMA sites required, introducing AMPS-CDMA ISI amaintaining the same number of sites, load, and quality of service can be a challenge.

Besides adjusting parameters discussed above, another way of addressing the interfersimply to add more CDMA sites by dropping them into ISI induced coverage holes (co-locatewith AMPS). If this is not an option, cell swapping can help. Sites in lightly loaded areas orwith relatively low interference levels can be swapped out for ones in areas where the ISI is cahigh subscriber drop-out.

Another approach to improving system performance in the presence of ISI, is to increasepage, and sync power levels (assuming that the P.A.’s have enough headroom). This enabCDMA signals to overcome the interference. This must be balanced against an excessive inin pilot pollution and system operating power levels. The associated additional system noiswould ultimately result in lower system capacity.

It may be prudent to pay particular attention to the location of high interference zones rathefocusing only upon the negative statistical impacts of ISI. AMPS-only cell sites (particularly thof the competitor/other side operator) located along heavily traveled highways may producecoverage holes. These coverage holes may not introduce a significant reduction in the staperformance results from the simulator. Keep in mind that the simulator is static and represeinstantaneous status of a CDMA system’s performance. These same coverage holes may re


A7


l whileverage

drastic system performance problems if large numbers of users experience a dropped caldriving through these holes. Appropriate actions would be necessary to alleviate such a coproblem.


Date post:	28-Apr-2015
Category:	Documents
Upload:	mohammed-rafi-ahmed-shareef
View:	102 times
Download:	4 times

Cdma Rf Design v 6 1

Documents